We use PDFs instead of PostScript files for a variety of reasons, such as the compact file size, a sense of security (a PDF is like a program that compiled successfully), and fonts that are included in the file. Text and graphics will be printed with the same quality we had in the PostScript output (as long as distilling parameters are set appropriately).
However, when distributing PDFs designed to be displayed as well as printed, or exclusively displayed, a different set of issues arises.
PostScript viewers were available before Acrobat, but these interpreted the PostScript data directly, which was time-consuming. Results were not great either — but these tools were meant to be used mainly for occasional diagnostic purposes (such as the ‘Preview’ function that is now almost obsolete).
Acrobat’s display function, on the other hand, was designed as one of the main product features, so we have the right to be more demanding. A program that advertises itself as a tool designed (among other things) to ease on-screen viewing of documents and even replace paper cannot be compared to a generic viewer.
In this article, I will discuss some of the main display problems of Acrobat 4.x (all applicable to Acrobat 3.x as well), with the hope that these will be addressed in future versions of Acrobat.
Anti-aliasing of Vector and Bitmap Graphics
Today’s print devices have excellent resolution — an office laser printer is usually 600 dpi, professional output devices start with 2400 dpi. However, when it comes to screen display, resolution is still extremely limited. This will change in a number of years, but currently the screen is a low-resolution device (typically in the range of 72 or 96 dpi). As a result, faithful on-screen rendering text and graphics is difficult.
To improve the appearance, anti-aliasing techniques generally have been in use for several years. Pixels on the margin of objects are rendered at an appropriate level of gray, instead of being either black or white,
(For more information on anti-aliasing, I recommend the following articles:
- ‘CoolType, ClearType: The Eyes Have It,‘ by James Felici, Seybold Report
- ‘Sub-Pixel Font Rendering Technology,‘ by Steve Gibson, Gibson Research Corporation
In Acrobat and Acrobat Reader, anti-aliasing is referred to as the ‘Smooth Text and Monochrome Images’ option (i.e. smoothing edges, to minimize the contrast between the background and the text or image). There are some differences between the way this is implemented in Acrobat 3 and 4, but in both cases anti-aliasing is applied only to text and some bitmap images (depending on their resolution and color depth). Vector graphics objects (including text converted to outlines, often used in logos) are not anti-aliased in Acrobat, so that the same vector graphics may appear in Acrobat at a lower quality than in your graphics program — e.g. Illustrator, another Adobe product — on the same monitor.
How about anti-aliasing for bitmap images? Office 97 applications (Word, PowerPoint, Excel), for example, include an anti-aliasing feature that automatically smooth on-screen images (regardless of their resolution). Acrobat/Reader, however, only smooth images that are 200 dpi or higher (additional restrictions may apply, so you may have images that are 200 dpi but are nevertheless not anti-aliased by Acrobat). Thus, as strange as it may sound, screen captures — and possibly other bitmap images — will look better in Word than in Acrobat.
Inconsistent Line Thickness
Acrobat frequently displays lines of the same weight at varying widths. You may have a table with uniform rules, or an illustration with objects created with identical thin lines, but when displayed in Acrobat, some of the identical lines will look thicker. Zoom in or out, and what ever was thin may now appear thicker and vise versa. Worse than that, various lines may disappear altogether at some zoom levels (this typically happens with thin lines in scanned images and with HTML tables converted by Acrobat’s Web Capture function).
By comparison, the same table or illustration displays as expected, on the same screen, when viewed in the authoring application.
For more information about this problem, see section 7.5.2, ‘Automatic Stroke Adjustment,’ pages 503-504 in the PostScript Language Reference, Third Edition, [PDF: 7.5 MB/912 pages]. PostScript Language (starting at level 2) supports an automatic stroke adjustment feature, designed to compensate for the rasterization effect that produces non-uniform strokes, but it is not implemented in Acrobat.
There is no workaround to the problem of non-uniform lines other than sticking to magnifications that are multiples of 50% (including 100%, of course). Notice that a higher zoom level is not necessarily better. The distortion may appear at 228% and 232% zoom levels, but will disappear at 200%.
Most patterns and hatches (such as those available in FrameMaker, Word or Excel) are substituted with shades of gray, or disappear altogether, when displayed in Acrobat.
There are variations, related to applications, the printer drivers used and specific Acrobat releases. (In some cases, Type 3 bitmap fonts were used to simulate patterns — with gray stripes at normal magnifications , correct display at large magnifications, and slow rendering.) Even PostScript patterns are not displayed correctly at lower magnifications — sometimes looking like a solid black or white box.
Semi-transparent fills from Microsoft Office documents are not displayed correctly either. Such fills are opaque if the PDF is created with Acrobat Distiller (and do not appear at all if PDFWriter creates the PDF).
Acrobat 4 Highlight Annotations
You would expect Acrobat Reader to display PDFs in a way that is identical to the way it is the displayed in Acrobat. This is pretty much the case, with one exception: Highlight annotations inserted in the full version of Acrobat are displayed as hollow rectangles in Acrobat Reader.
Bitmaps at Variable Zoom Levels
Bitmaps display well only at the resolution in which they were created or captured. Zooming in and out is great, but with bitmap images this will degrade the image quality; text and vector graphics, on the other hand, can be zoomed in or out without inherent loss of quality (leaving aside the issue of inconsistent thickness of lines).
Acrobat internally uses a 72-dpi resolution for display purposes. For a bitmap to display well at 100% zoom, it has to be integrated into the source page at 72 dpi (or 144 dpi if it is to be displayed well at 200% zoom). However, for print purposes, images at 72 dpi are too large in most cases. This issue is not addressed properly in many PDFs, resulting in bitmaps that are displayed at poor quality (even when the Distiller parameters are appropriate). Arbitrary resolutions used in the source files (used with printed result in mind), yield a situation where to be able to view the screen capture without distortion, one has to use trial and error to reach ‘random’ magnifications such as 131.5%. The notion of a PDF with bitmap images that will be equally useful for print and display purposes leads to compromises in quality.
Drawing Speed of Vector Graphics: Render or Surrender?
Acrobat draws vector graphics, made up of a series of lines, curves and mathematical instructions, as stroked/filled paths (similar to the way graphics are drawn in Adobe Illustrator or Freehand). Complex vector graphics may challenge Acrobat’s drawing functions, resulting in a painfully slow painting process that involves many hundreds or thousands of segments, which is repeated each time you zoom in/out or move in the page.
Acrobat does not cache the results of the digitization of vector graphics, so that even if you scroll vertically or horizontally back and forth, revealing the same portions of the drawing without changing the zoom level — Acrobat works hard to render the graphics time and time again. Likewise, even in an optimized PDF where a specific vector graphics is repeated on many pages but stored only once, Acrobat has to build the display each time you page up or down. This is especially noticeable with PowerPoint presentations using complex backgrounds (such as fountain-fills); in many cases, redrawing the screen is accompanied by disturbing visual effects.
A feeble workaround is to convert such complex vector graphics to bitmaps, which display much faster (and possibly anti-aliased). However, you lose scalability without degradation, and text objects will not be searchable any more; print quality may be affected too.
So the display of graphics leaves much to be desired. But what about text, the prime component of documents?
With smaller font sizes and serif fonts, Acrobat’s digitization of letters often produces inferior results, compared to the digitization performed natively by operating systems (with or without ATM). Acrobat’s anti-aliasing of text may somewhat compensate for this, but with text that uses thin or italic fonts, results are often blurry, and in such cases text may be more readable with anti-aliasing turned off (Smooth Text and Monochrome Images de-selected).
You can see this with your own eyes by creating a PDF which uses a common font and size combination: Times 12. View it once with anti-aliasing turned on, and once with anti-aliasing turned off, and compare the two.
To see the difference on ‘live’ text, you can create a text form field with the same text, and then edit its text (after clicking it with the Hand tool). When you edit the text, Acrobat does not anti-alias it; as you click elsewhere in the page, the text is anti-aliased again.
You can also compare the results to text with the same properties displayed in browsers and editors. (Note: if your workstation has an anti-aliasing feature which affects screen fonts, turn it on and off to see its effect).
As you use larger font sizes, the degradation of quality diminishes.
Note: While this does not seem to directly affect results of digitization, font sizes shown in Acrobat are in many cases slightly different than the sizes specified in the authoring application. When distilling a hand- coded PostScript file, a font size of 11 was reported accurately as 11 in Acrobat (text highlighted with the TouchUp Text tool, then Tools -> TouchUp -> Text Attributes). An 11-point text in Microsoft Word 97 resulted in 11.04 in Acrobat, while an 11-point text in FrameMaker 6 was reported as 10.92 in Acrobat. With both applications, font sizes that are multiples of 3 are precisely registered in Acrobat.
One cannot escape the notion that Acrobat’s display mechanisms have been sorely neglected during the first four major releases of the software.
My wish as an Acrobat user (well … one of my wishes) is that Acrobat’s display quality will improve significantly in Acrobat 5. This should also be in Adobe’s best interest. As the display of documents becomes widespread, user and developers alike will be more discerning, and may adopt competing technologies if the current sorry display state is left unchanged.
The following comparison graphics illustrate specific points in the article.
Vector Graphics Comparison
Left – vector graphics in Adobe Illustrator 8; Right – same graphics
displayed in Acrobat 4, with ‘smooth text & images’ option turned on (vector graphics are not anti-aliased by Acrobat)
Bitmap Graphics Comparison
Left – image displayed in Word97; Right – same image displayed in Acrobat
4. Even though Acrobat’s anti-aliasing is activated, it does not affect images that are below 200 dpi. Lack of anti-aliasing is particularly noticeable where two contrasting colors meet.
Line Thickness Comparison
The same grid displayed in Acrobat at 100% – 140% magnifications. All lines
were created with the same thickness, yet they are displayed non-uniformly.
Font Rendering Comparison
Fritz Quadrata and URW Antiqua, 12 points: Top – in Word, Bottom – in Acrobat
(Anti-aliasing is turned off in both). Notice how letter thickness is distorted in Acrobat’s display.
Same as previous, but enlarged to show character digitization.
Anti-aliasing of Times 12 in Acrobat 4
Phrase in Times 12 as rendered by the operating system (top) and by Acrobat
(bottom). (NT4, ‘smooth edges of screen fonts’ option activated)
Same as previous, but enlarged to show character digitization.