Screen Captures Exposed

What Is Your Deliverable?

What a graphic looks like in FrameMaker is absolutely irrelevant, unless FrameMaker is your deliverable. Put another way, unless you are giving somebody a FrameMaker file as the end product, how FrameMaker displays a particular image is largely unimportant. For that matter, how your graphic displays in Microsoft Word, Corel Ventura, or any other intermediate tool is unimportant.

What is important is how the screen capture displays in the deliverable.

And, yes, reviewing the image in FrameMaker can give you a clue about how the image will display in the deliverable, just remember how unimportant the exact FrameMaker display is.

Why do I mention this? Because Microsoft Office products rely heavily on anti-aliasing to affect how images display inside them. Thus, a screen capture in Microsoft Word will likely be softer and smoother than the same image displayed in FrameMaker. This is irrelevant, even if you prefer one over the other. What you need to consider is the PDF, online help, or printed output. Microsoft's smoothing and anti-aliasing, and FrameMaker's lack thereof, has no effect on the output.

What is a screen capture? The Nature of the Beast

A screen capture is a picture, it is not dynamic. That is, if you have a program window open on screen, you can resize it. And, after you resize it, the window displays perfectly. It is important you remember that the window displays perfectly because there is a software application resizing the window dynamically and refreshing the display of that window to the screen.

Let me say again, a screen capture is a picture. It is static. A screen capture is a picture of a window at a particular resolution, say 96 dpi, *and* at a particular dimension, say 600x600 pixels.

Now, consider that programs are often not written with documentation in mind. That is, programmers seldom consider the need to use pictures of their work in online help, PDFs, and other documentation when designing their programs. Thus, the 600x600 pixel dialog box is displayed at 96 dpi and has an effective size of 6.25 inches square.

6.25-inches is wider than most of our columns.

Consider, too, for online display, the viewer we use has real estate or space requirements. Thus, in its native program, the window we capture is the only object, but the screen capture has the added baggage of the space and pixels used by the viewer, be it a browser or Acrobat Reader. The viewer you use to display your documentation uses space on-screen, for toolbars and the like, and that space makes less space available for your document and the screen capture that lives within your document.

Now, consider screens have a fixed resolution, and that resolution is 96dpi. So, what happens when you resize that 600x600-pixel image at 96dpi to 400x400 pixels? Well, you reduce the size of the capture from 360,000 pixels to 160,000 pixels. That means you lose 200,000 pixels. At 96 dpi, the 400x400 image occupies 4.2-inches square.

If you remove 200,000 pixels from an image, you are forced--your software is forced--to redefine the relationships between the pixels that are left. In a photograph, where changes are subtle across the entire image, this can be done with little fuss. In a screen capture, with its sharp edges of boxes, buttons, and the like, the redefinition of these relationships is quite noticeable and shows as anti-aliasing, or fuzziness, or jaggies.

On the other hand, you can avoid losing any pixels by resampling the resolution from 96 dpi to something else. For example, if we take the 600x600-pixel screen capture at 96 dpi and resample it to 150 dpi, the image becomes 4-inches square, without losing a single pixel.

That is, a 600x600-pixel, 96-dpi image comprises 360,000 pixels and occupies a 6.25-inch square.

A 400x400-pixel, 96-dpi image comprises 160,000 pixels, and occupies a 4.2-inch square.
A 600x600-pixel, 150-dpi image comprises 160,000 pixels and occupies a 4-inch square.

The problem with resampling the resolution of the image from 96 dpi to 150 dpi is that our screen display is 96 dpi. Since the dpi of our image is not 96 dpi, and because our screen display is 96dpi, then the screen capture will not display crisply on-screen. The screen has to render a 150-dpi resolution at 96-dpi and it does so by smoothing, or anti-aliasing the image. Thus, a resized screen capture will display with some fuzziness and jaggies to the screen.

Finally, this is aggravated, a bit, because Adobe Acrobat does not provide smoothing and anti-aliasing to the same degree and with the same success as Microsoft Office. Remember, if you have resized the screen capture by removing pixels or by changing the resolution, there *is* going to be a display issue.

What Resolution is Best for Screen Captures?

The answer depends on what your deliverable is.

Choose a resolution for your screen captures that is evenly divisible into or by the resolution of your output device.

I mean, if your document is only going to screen, then the resolution of your output device is 96 dpi. Thus, 96 dpi and 192 dpi are good resolutions for screen captures that only have the screen as their output.

If your document is only going to print, then 100, 120 dpi, and 150 dpi are good resolutions for a 600, 1,200, or 2,400 dpi printer (because 600, 1,200, and 2,400 are evenly divisible by 100, 120, and 150).

If your document is going to both print and screen, you have to compromise. You can create two sets of screen captures, one for each medium, or you can pick a resolution that will not be the best for one or both output types. In general, printers are more forgiving than your screen is. Thus, 96 dpi will print to a 600-dpi printer better than a 120-dpi image will display to the screen . . . even though 600 is not evenly divisible by 96.

So, 96 dpi is a good compromise. The caveat is that 96 dpi is too low a resolution for high-resolution printers, such as 1,200- and 2,400-dpi ones. Using too low a resolution will result in ugly jaggies.

Also, 96-dpi resolution will not reduce the size of your screen capture. This is fine for screen captures that are small, but larger windows and dialog boxes will be way too big at 96 dpi for your online Help, PDFs, and other documents. Consider getting your software folks to create programs that use smaller dialog boxes or suck it up and use 120- or 150-dpi which will create excellent printer output but which will look fuzzy on screen at 100% resolution.

Note: in PDF, you can zoom-in to magnify and clarify a 120- or 150- or other image.

What About Color?

The color of your screen capture is fully dependent on the color depth that is defined for your desktop.

Your opinion might differ, but I find the expense of printing color outweighs any possible benefit of printing screen captures in color for a post-sale audience. I prefer to print screen captures as greyscale and use callouts to identify any are of the capture in which color matters.

Your opinion might differ, but I find the fact that color display to the screen being free makes the online display of color in screen captures nice eye candy. I prefer to output screen captures as color to the screen.

Screens are RGB. Converting screens to CMYK is an art, more than a science. Only convert to CMYK for output from an offset press, or the like. For office laser and inkjets, leave any color as RGB. Remember, FrameMaker (and Word, and Publisher, et al.) use the Windows GDI to print PostScript . . . so all CMYK colors except those in imported EPS files get converted to RGB anyway.

Adding color depth increases file size significantly. 36-bit color files are larger than 24-bit, which are larger than 8-bit, which are larger than 1-bit.

24-bit color adds nothing to a screen capture of a software element. I recommend you downsample 24-bit color to 8-bit color. Because screen captures of software use few colors, this downsampling can be done without display problems. Downsampling the 24-bit color in the screen capture of a color photograph could affect the display, because the photograph probably uses a lot of colors that would have to be approximated during the downsampling.

8-bit color and 8-bit greyscale files are the same size. 8-bit color prints off a greyscale laser printer just as well as an 8-bit greyscale image does. 8-bit color displays on screen as color, and color is free on-screen. The only need I see to create an 8-bit greyscale screen capture is if you are going to print using a color process and you don't want to spend for printing color screen captures. Otherwise, I recommend you use 8-bit color.

I dislike how 1-bit screen captures display. Check it out for yourself.

What Is the Best File Format for a Screen Capture?

JEPG is a lossy format. Unless your screen capture is of a photograph, you might not want to use it. The sharp edges of buttons and boxes in captures of windows can visibly suffer from using the JPEG format. If you do use JPEG, you should use a high-quality or no-compression setting.

GIF is a good choice. GIF is browser-friendly and has fairly small file sizes. GIF is limited to 8-bit color. One drawback to 8-bit color is that it does not support some bitmap editing features, such as anti-aliasing text. Thus, if you had to creatively edit a GIF in a photo or bitmap editor, you might have to convert it to another format to do so.

PNG is a good choice. PNG is not supported by older browsers, if that is important, but PNG has better compression than GIF and, like GIF, is not lossy. PNG supports 24-bit RGB color + transparency.

BMP is a good choice, especially if you have to edit your bitmaps. BMP supports 24-bit RGB color and so offers you the full-range of editing tasks of your bitmap or photo editing software. BMP is only supported on the Windows platform, others may want to use TIFF, but BMP is widely supported in Windows and converts via FrameMaker or third-party utilities such as WebWorks Publisher to web friendly formats. Like TIFF, BMP files tend to be large. Being in Windows, I use BMPs because I can edit them and then convert the BMPs to web-friendly formats as needed (my software supports this automatically, the conversion is nothing manual I have to do).

TIFF is a good choice for non-Windows users or those using 4-color. TIFFs support CMYK color. TIFFs are widely supported for conversion to web-friendly formats. TIFF files tend to be large.

EPS is a good choice if you need to preserve CMYK colors in your screen capture and if you are using an offset-print process, or the like, to output your document.

What Is the Best Way to Take a Screen Capture?

I apologize for the Windows focus of this section. If you use UNIX or Mac, consider the intent of what is said.

If capturing screens is part of your job and you are using Windows' Print Screen and Alt+ Print Screen commands, you are wasting your time and doing yourself a disservice.

If capturing screens is part of your job, and if you are not documenting hypothetical screens that do not yet exist, then if you are using a bitmap or photo editor on a regular basis, you are wasting your time and doing yourself a disservice.

I, and you, can capture a specific Windows element, resample the resolution, change the color depth, and automatically save the name of the screen capture with one key-combination. There is no masking, no editing, no resampling, no saving, needed. In short, USE A SCREEN CAPTURE PROGRAM.

Use any screen capture program. They all seem to have demo versions available for download. Pay attention to those that have more features in specific Windows versions, versus those that provide the same feature set across all Windows versions. I use SnagIt from http://www.techsmith.com, but there are other good screen capture programs available. These typically cost $40 or less. There is no reason at all not to use such a tool. Search the Web.

<b>Dov Isaacs on Screen Captures</b><br /><br />Dov Isaacs had this to write about screen captures:<br /><br />***************<br /><br />Date: Wed, 23 May 2001 10:23:22 -0700<br />From: "Dov Isaacs" <isaacs@Adobe.COM><br />Subject: Imported / Placed Images - MORE (You Asked for It!)<br /><br />All:<br /><br />Some additional issues were raised yesterday both on-list and in some private emails to me about me postings with regards to screen capture images specifically and images in general.<br /><br />Issue #1 - UNIX<br />===============<br /><br />UNIX is not my specialty and Adobe no longer provides a version of Photoshop for any flavour of UNIX. Thus, my advice for UNIX users of FrameMaker are effectively to capture the raw image as TIFF, process the image on Windows or Macintosh to obtain the EPS file with the image interpolation option, and then move the resultant EPS file back to your UNIX-based system for use with FrameMaker.<br /><br />Issue #2 - File Size - Screen Captures<br />======================================<br /><br />There is no question that the binary EPS files that result from the procedures I outlined yesterday are somewhat bloated compared to other files holding the same content. The resultant PDF files at the end of the process, though, are exceptionally compact.<br /><br />To show what is going on, I captured an image showing one of the PSCRIPT driver dialog windows. I saved the resultant RGB image in a number of different formats. The following are the files, sizes, and explanations:<br /><br />Printer Properties.bmp - 899 KBytes<br /><br />        RGB and K only, no CMYK option, no compression option,<br />        no display/print-time interpolation,<br />        limited cross-platform interoperability,<br />        application/driver resampling problems<br /><br />Printer Properties.gif - 20 KBytes<br /><br />        RGB only, no CMYK option, 24 bit color reduced to 8 bit color,<br />        no display/print-time interpolation,<br />        application/driver resampling problems<br /><br />Printer Properties.tif - 61 KBytes<br /><br />        no display/print-time interpolation,<br />        application/driver resampling problems<br /><br />Printer Properties Direct ASCII.eps - 2735 KBytes<br /><br />        no compression, enormous size (includes TIFF preview)<br /><br />Printer Properties Direct Binary.eps - 1462 KBytes<br /><br />        no compression, large size (includes TIFF preview)<br />        care must be taken in setting Windows PostScript printer driver<br />        to correct binary option (most often TBCP if not AppleTalk printer)<br /><br />Clearly, you are indeed paying an on-host penalty in file size by using<br />the EPS approach that I outlined. The resultant PDF generated from this<br />content most often is SMALLER than the PDF generated from TIFF equivalents<br />and has higher quality, but you will pay in terms file size of the on-host<br />"content" files with the images.<br /><br />(You may ask "why are the EPS files from Photoshop so bloated?" The answer<br />is two-fold. Part of the problem comes from the fact that Photoshop does<br />not have a compression option for non-JPEG EPS export, although it has a<br />ZIP compression option for non-JPEG PDF export. The other part of the problem is the TIFF preview header, which surprising enough, takes at least as much space as the "base" uncompressed image in PostScript. Yucck!)<br /><br />But alas, I did find a way of fixing this problem enough to be quite a<br />bit more tolerable. (If local disk space is not a problem, then you need<br />not worry about trying this stuff out!)<br /><br />Instead of saving the image as EPS with the interpolation option in either<br />Photoshop 6 or Photoshop Elements 1, save the image as Photoshop PDF with<br />the interpolation option and ZIP compression (not JPEG!!) using either<br />one of those programs. THEN, in Acrobat 5, save the PDF file as binary EPS, <br />TIFF header, language level 3. (In Acrobat 4.05a, export the PDF file <br />similarly!)<br /><br />Resultant files (both ASCII and binary flavours):<br /><br />Printer Properties.pdf - 23 KBytes<br /><br />        Most compact format for this image type<br />        Not appropriate for FrameMaker import/placement.<br /><br />Printer Properties from Acro5 ASCII.eps - 400 KBytes<br /><br />        Slightly larger than binary equivalent,<br />                much larger in the general case, though<br />        (includes TIFF preview)<br /><br />Printer Properties from Acro5 Binary.eps - 396 KBytes<br /><br />        Slightly smaller than ASCII equivalent,<br />                much smaller in the general case, though<br />        (includes TIFF preview)<br />        care must be taken in setting Windows PostScript printer driver<br />        to correct binary option (most often TBCP if not AppleTalk printer)<br /><br />With the replacement step of generating PDF instead of EPS and then the extra steps of running Acrobat and saving/exporting PDF, you save over two thirds of the disk space for the EPS files.<br /><br />There is no quality loss in this process. The savings in disk space is<br />due to the fact that unlike non-JPEG EPS export from Photoshop/Photoshop<br />Elements, PDF export from the same program can ZIP compress images as<br />well. Screen captures do exceptionally well with non-lossy ZIP compression.<br />The EPS save/export from Acrobat maintains the images' ZIP<br />compression. The remaining "bloat" in these Acrobat-generated EPS files is the<br />result of Acrobat's PostScript procedures in the EPS file as well as the TIFF header.<br /><br />Bottom line is that I think the extra steps are worth it if you want to<br />conserve disk space. If you want to re-edit THESE EPS files in Photoshop,<br />unlike the EPS files directly saved from Photoshop, extreme care must<br />be taken in opening them to avoid weird resampling.<br /><br />Issue #3 - Non-Screen Capture Images<br />====================================<br /><br />I would still recommend EPS as a better means of importing/placing images<br />into FrameMaker such that resampling does not occur in the application or driver.<br /><br />Likewise, I would not recommend ever resampling any such images to a higher resolution. Turn on the image interpolation option and let either<br />Acrobat or the ultimate PostScript printing device do the hard lifting<br />for you. You gain nothing by carrying around the extra data which really<br />contains no real new data.<br /><br />This is most likely contrary to what your service bureaus and printers<br />will tell you as gospel and what their pre-flight software will advise you to "correct," but resampling here buys nothing at all. (If they still don't believe you, have them contact me!)<br /><br />I have revised the recommendations from yesterday based on the above ...<br /><br />        - Dov<br /><br />========================================================================<br /><br />Based on our experience at Adobe, there is one way that easily yields the highest quality computer screen shots for both display and printing.<br /><br />(1) Grab the image with whatever your favorite tool is. Under Windows, the easiest thing to do is Alt-PrintScrn which puts the RGB bits onto the pasteboard. On the Mac, Shift-Command-4 followed by CapsLock yields an image file.<br /><br />(2a) Under Windows with Photoshop 6, create a new document. It will automatically be the size of the image on the pasteboard. CTRL-V will then paste the screen capture into that new image. Then, flatten that image.<br /><br />(2b) Under MacOS with Photoshop 6, open the generated image file (a PICT <br />file with a name of the form "Picture x" where "x" is an integer).<br /><br />(3) Convert the screen shot image to CMYK or grayscale to suit your needs.<br />Not all service bureaus require CMYK! If you are displaying the PDF file<br />and printing to laser printers, CMYK buys you nothing other than potentially<br />a larger file.<br /><br />(4) Flatten the image. Layers buy you nothing here and may cause problems<br />later in saving the file.<br /><br />(5) Do not resize or change resolution of the image!!!!!!<br />(Why? Because you generally don't know at this time exactly what the magnifications and resolutions are that you will be viewing and printing<br />with! In fact, zooming in and out with Acrobat or Acrobat Reader changes<br />those requirements on the fly. Better to simply just have the captured<br />data. Upsampling or downsampling at time of need to exact specifications<br />yields much better results than multiple such transformations!)<br /><br />(6a) Re-editable by Photoshop, but "bloated" EPS file size option!<br />Save the image using File=>Save As using the "Photoshop EPS" option. In the "EPS options" screen, you should use the TIFF (8bits/pixel) preview option (yields an EPS file that can be used both on Mac and Windows), <br />Encoding "binary" (ASCII can be twice the size and JPEG is totally inappropriate for screen shots). Check "PostScript color management" if you are using color management in your workflow. The key though is that you MUST check "Image Interpolation". This sets a image dictionary key that Adobe<br />PostScript Level 2, Adobe PostScript 3, Acrobat, and Acrobat Reader use to do<br />very high quality image interpolation and/or downsampling appropriate to the<br />device's actual resolution and technology at the time the image is viewed or printed. (Distiller passes this key along from PostScript or EPS in a PostScript stream into the equivalent PDF image key!) Close Photoshop 6.<br /><br />                        OR<br /><br />(6b) Compact EPS file size option!<br /><br />        (i) Save the image using File=>Save As using the "Photoshop PDF" <br />option.<br />        In the "PDF options" screen, you should use the ZIP encoding<br />(lossless<br />        compression) option. The key though is that you MUST check <br />        "Image Interpolation". This sets a image dictionary key that Adobe <br />        PostScript Level 2, Adobe PostScript 3, Acrobat, and Acrobat<br />Reader use<br />        to do very high quality image interpolation and/or downsampling <br />        appropriate to the device's actual resolution and technology<br />at the time<br />        the image is viewed or printed. (Distiller passes this key along from <br />        PostScript or EPS in a PostScript stream into the equivalent<br />PDF image <br />        key!)<br /><br />        (ii) Close Photoshop 6.<br /><br />        (iii) Open the resultant PDF file in Acrobat 5 or 4.05a. Save the PDF<br />        file as an EPS file using the export function in Acrobat 4.05a or<br />        the Save As function in Acrobat 5. Set the options for binary EPS, <br />        TIFF header, and language level 3.<br /><br />        (iv) Close Acrobat.<br /><br />(7) Import the resultant EPS file into whatever application you have in which you wish to include the screen print. Obviously you will only see the EPS preview in those applications (except for InDesign), but your resultant printed output (via PostScript or PostScript=>PDF) or display via Acrobat / Acrobat Reader will be of exceptionally high quality. During distillation, do not downsample any of these images. Downsampling of the screen shots can be avoided by having a high enough threshold for downsampling; 300dpi or higher will do!<br /><br />Working on a budget? It turns out that you can replace Adobe Photoshop 6<br />with Adobe Photoshop Elements 1.0 if you do not need to convert to CMYK<br />and don't need any other advanced image handling. This could save you $500 a copy if your image handling needs are more limited.<br /><br />NO, as far as I know, neither JASC nor Corel PhotoPaint nor any of the other budget image edit programs offer the EPS export image interpolation<br />option, assuming they even offer the EPS format. Furthermore, none of the nifty screen capture utilities that we know of offer either EPS or EPS with the image interpolation option.<br /><br />We know of NO better means of producing high quality printed or displayed<br />screen shots in an output device independent manner. Forget GIF, TIFF,<br />BMP, and especially JPEG. Forgetting the issue of the image interpolation<br />feature for the time being, use of any of these formats results in the "host"<br />program (such as FrameMaker or Microsoft Word, etc.) doing their own <br />resizing of the image in conjunction with the PostScript drivers based<br />on the device resolution selected. The bottom line is that by the time Acrobat gets to display the image or the PostScript RIP gets the image data,<br />the image data will have been upsampled, downsampled, resampled, i.e.<br />overmangled!<br /><br />Also, note that for purposes of placing other images in FrameMaker or similar applications, EPS with the image interpolation also is the preferred<br />means of image placement for exactly the same reasons. In terms of image<br />resolution, you may choose to leave as-is and let the Distiller do the heavy lifting, if necessary or downsample in Photoshop if the original image is grossly over-endowed, so to speak. Remember, you cannot later reconstruct what you downsample now.<br /><br />With regards to the "resolution" that you set the Acrobat Distiller printer to, that resolution primarily affects non-EPS image handling. As long as you set the resolution to 600 dpi or greater, character and vector artwork placement will be fine and not affected. You don't need to use the resolution of the final device (in fact, don't go over 1200 dpi under Windows or you might hit a nasty bug in FrameMaker's interface with the driver).<br /><br />For distillation job options, always use "compress text and line art". This is non-lossy compression and you gain nothing by not using it other than a larger PDF file size.<br /><br />I know that this information is very much at odds with what your service<br />bureaus, printers, or Kinkos will tell you, but it is authoritative and<br />Adobe Systems Incorporated stands behind it completely when used in<br />conjunction with Adobe Acrobat and RIPs with Adobe PostScript Level 2 or Adobe PostScript 3.

<b>Dov Isaacs Clarification</b><br /><br />Dov Clarified his statements about the PS process resampling non-EPS images:<br /><br />Date: Thu, 24 May 2001 15:28:40 -0700 To: framers@frameusers.com, framers@omsys.com From: "Dov Isaacs" <isaacs> Subject: Imported / Placed Images - >Even MORE Mishagoss! Cc: sofpasuk <br /><br />Further clarification (of course): <br /><br />From what I can best tell, FrameMaker under Windows (and hopefully also the versions on other platforms) as well as the Microsoft Office programs are fairly good about not resampling non-EPS image formats during output to the PostScript driver. GDI and the driver under Windows 2000 seem not to do any resampling of such image data, either. In the case of FrameMaker, this is even true when you scale a non-EPS image within FrameMaker. The number of pixels are not increased or decreased.<br /><br />There are some applications that do resample on the way out to GDI and the driver. Lotus WordPro (the former AmiPro) for example, does do resampling (and sometimes screws it up on the way to the driver). WordPerfect 10 (from WordPerfect Office 2002) seems to totally barf-up the creation of PostScript image data somehow. <br /><br />It is also true that FrameMaker and the combination of GDI and the driver under Windows will convert grayscale images to 8-bit indexed RGB color and CMYK images to regular 24-bit RGB color. <br /><br />Thus, disregarding the high quality interpolation flag feature of Photoshop EPS, there are still good reasons to use EPS to avoid any possibility of applications mucking around with the image, less likely with pixel resampling, more likely color munging!

More screen capture info: "Screen Captures 102.pdf, "here: .