Does V.6 help with screen shots?

[ChrisBrewster]

I need info about the screenshot feature in version 6, because I use many screenshots. I reduce them in size and add circles, arrows, etc. I'm wondering if RH's feature can do both size reduction and added graphics. More important: I need to produce both online help and a paper manual. My employer is satisfied with RH's paper formatting except the way my screen shots look. To print well, they would need to be saved in a different format. I won't go into detail because most readers here probably know what I mean. The obstacle is that every screen shot would need two separate files, plus conditional code to use one set of images for online and the other set for printing. If my employer ever feels like paying for about three months of my labor to do this, I could, but I'm wondering if RH 6 has any better way to do it.

[Peter Grainge]

I don't know why you need to maintain two sets of screenshots. I have found that whatever is in my online help comes out well in the printed documentation, sometimes it actually improves.

There's a topic on my site that may help so that only one set is needed. Take a look at that and then post back with some details of your process if that doesn't improve things.

http://www.grainge.org/pages/authoring/images/images.htm

[ChrisBrewster]

I'm surprised that you get satisfactory results. I tried RH's Resize tool, which I didn't know about, but am getting the same result I get with other methods I've used. The problem is that, for online use, the image must be "truly" resized-- that is, a 100x100px image must become a 70x70 image to display correctly at 70%. If I simply resize a larger image within RH, it becomes illegible when displayed online (it appears that the necessary percentage of pixels are just omitted). With any good resizing, such as the RH tool, original pixels aren't randomly omitted but are instead approximated within the fewer pixels of the new image. This is the most legible result I can get online. But for printing, the print operation uses all the original pixels, because a printer's resolution is much finer-- so the original image works the best even if it's reduced in display size. In contrast, the image I made for online use, with fewer actual pixels, looks really bad when printed.

Please tell me if I've missed something. Summary: in my results, reduced-size online display requires an image of fewer pixels that dither over the original pixels. Printing requires all the original pixels, but packed closer by the printer.

[Peter Grainge]

I guess it is a question of just how high a quality image you want or need when printing.

As you can see on my site, the reduced size images are pretty clear online and seem to print pretty well, indeed my experience is often that when printed you get what seems to be a better result than you see online.

I've covered what I found in terms of which file types gave the best online result and best printed results and which are best on balance. I am not sure what else I can add. Can you get something into a single topic test project so that I can see what the issue is?

[HKabaker]

When you resize a .gif image, quality suffers because it has only 256 colors.

I always resize images in .jpeg (or other millions of colors format) and usually sharpen the reduced image before saving as .gif. This is before importing to RH.

I haven't seen what RH6 does.

Harvey

[ChrisBrewster]

I suspect you're right that we have different standards. I should have referred to images on your own site. An example of a good online screen shot is Method 3 on the GIF page. This does the dithering I described, in which one grid of pixels approximates the image in another, finer, grid. Even at 50% I can easily read the text. The example above it reduces the image by just tossing every other pixel in the original (or some equally crude solution). But if the good image (Mth. 3) is printed, it's far inferior to using the original screen shot (even if the original is resized on the page), which any current printer can reproduce with all the original pixels sharp. So I think I'm back to the two-file solution.

Here's my real pipe-dream: when an image is reduced, the *browser* does the dithering instead of just crunching the image and losing a percentage of pixels. Then I could use the original shots the way I would in a printed manual.