I'm using FullShot 9 to capture screens/windows within a software program, saving my captures as JPEGs, and then copying them into anchored frames in FM 12. When I save my FM file as a PDF, the images aren't clear until I zoom to 150%. I've tried changing the "PDF Job Options" under the PDF Setup Settings to both Press Quality and High Quality Print.
The images are still legible at 100%, but they make me feel like I'm not wearing my glasses. My team says they're good to go as-is, but I'd like to learn how to make them better if I can. They'll ultimately be appearing both in print and online.
If there are any workarounds that would make these full-window screen shots stay sharp even at 4x6", please send them my way!
Capture and save images without using JPG. Use PNG and you'll be much happier.
fwiw, I import .png by reference at 150 dpi and haven't had any complaints … The reason for not using .jpeg for screenshots is that it's designed to soften sharp transitions by adding blur: that may often be what you want in a photo, but it's exactly what you don't want in a screenshot.
Our lives would be much easier if monitors used vector graphics – as seen, I seem to remember, in Jurassic Park :-}
re: I import .png by reference at 150 dpi and haven't had any complaints …
Importing screenshots at native res works great, as long as you have full control over the workflow, and can prevent any damage from further sub-sampling and/or compression.
re: The reason for not using .jpeg for screenshots is that it's designed to soften sharp transitions by adding blur
Adding blur wasn't the intent. It's just a side effect of the compression. When rendering images into documents, we usually have 3 choices at import:
1. no compression (typical for EPS)
2. lossless repeat-count compression (e.g. RLE in BMP, CCITT or LZW in TIF)
3. lossy curve-matching compression (e.g. DCT in JPG)
On output, FM and/or distiller and/or the XML/HTML workflow engine may perform further transforms, so attention must be paid to "print" settings, as well as PDF job settings.
Curve-matching compressions tend to deal poorly with discontinuities, and screenshots of dialogs tend to be made of sharp transitions. What curve coefficients accurately model a square wave?
When some curve-matching compression ends up getting applied anyway, one hack to minimize the damage is to start by upscaling, using "by-nearest-neighbor", to some high value, like 4x the native res, then importing that. This tends to shrink the ringing artifacts at edges when later reduced to some curve coefficients.
re: Our lives would be much easier if monitors used vector graphics
Some early monitors were. The problems included the expense of memory for the display list, and ultimately, lack of processing power and beam deflection speed for complex graphics. Stroked text could easily overwhelm this approach to data display.
But people do need to be aware of the benefits of keeping vector data in vector space, just like we keep text as text, and avoid the data itself becoming raster images of glyphs. Historically, EPS was the way to preserve vector in FM. PDF came later, and now we have SVG support. Exploit 'em.
Thanks for that interesting correction about why .jpg introduces artefacts! of course, I should have hoped that no-one would deliberately design an algorithm that makes certain types of picture worse :-}
As for resolution, I vaguely remember there used to be quite frequent discussions here in the forum about the mathematics involved in going from a screenshot of resolution x to an image referenced at resolution y with a view to crisp output on a printer with resolution z … which helps explain why I was relieved to discover by experiment a simple approach that works for me.
As for vector monitors, apart from the (presumably) unix kit in Jurassic Park, I remember some of the early games machines. It would be interesting to see whether or not a newer device could come up with the all-round performance of a modern flat-screen.
As for vector graphics, my hardware documentation uses only .eps or .svg. I don't, unfortunately, have the time to assemble a library of interface components and replace the screenshots in the software documentation … or the chance to use something like Axure and include "artist's impressions" instead of actual illustrations.
Thanks for reaching out. I saw this when you posted it yesterday, and actually did a little research early this morning to see if I could contribute anything helpful. I went to the Inbit site looking for any advice they had to offer, and/or a support option. I didn't find anything of value which is why I didn't step in earlier.
That said, I also prefer png files over jpgs, but I noticed that the standard edition supports other formats beyond those two, including PDF, which might be worth experimenting with. (The professional version supports other formats as well.)
Thinking out loud, this may well come down to resolution :
If you want to send a screen shot for me to look at, I'd be happy to play around with it and see if I can offer anything more concrete.
Thanks so much for your response!
The PDF format didn't seem to work any better for me
My display resolution is 1920 x 1080, and my image resolution is 300dpi. However, I can change it to 600dpi and see if that does the trick.
In order to disable the distiller downsampling settings, do I simply set each of the 3 downsample settings shown below to “Off?”
I'll send you a message with one of my screenshots so that you can see what I'm working with.
More resolution for color images won't help. That generally only affects line-art scans.
Here's what usually I do...
If capturing a dialog box, if possible, place in Frame at 100%.
If you do need to change the resolution to 300 ppi or change the size of the image, do it in Photoshop using Nearest Neighbor, not the default. (Resize first with resampling turned off.)
If the screen size is too high for the page size (i.e., the menus are too small to read), you need to adjust your screen resolution before capture.
As discussed, use PNG (or possibly TIFF with LZW compression). JPEG is the worst format for screen captures.
Y'all are working too hard.
In a previous career I was responsible for image quality in commercial printing.
While this method will not hold up for high quality graphics, it's perfect for low resolution images like screen captures.
Do this and tell me if you find a higher quality result using any other workflow.
If in doubt, place an image this way, and place the same image using whatever other workflow you like and compare the resulting PDF. If you find the images of different quality, then we can discuss conversion settings to remedy.
This is for screenshots, not for other graphics. This workflow doesn't work if you have extensive reuse, but works beautifully for all other workflows.
I had the chance to play with your file this morning, and am getting the same results. I think it is coming down to scaling the large image to fit in a relatively small frame. If I bring it in at the original size, it's clear in Acrobat and FrameMaker.
I'd give FieryPantone's advice a shot—fwiw, I import .png by reference at 150 dpi and haven't had any complaints—or just recognize that the user will have to zoom in to see the details on these images.