Ken reports his experience... . . . . . . . . . First try. "Test Doc_FH8.gif" (above) gave me fairly accurate color, but every color component R, B or G value that was originally over 153 was clipped to 153. This was of course wrong, but not in a manner that would indicate a general failure of FreeHand to preserve the web palette colors. Some investigation was in order. These as you can see are accurate. Click and save these GIFs and see if they match your browser-safe palette. If they don't let us know the conditions in effect.

"I opened the supplied file "Test Doc FH7.eps" with Freehand 8 and checked the colors. Colors were set properly, according to the values listed below each lettershape. __ To ensure accurate color exports, I made the following changes to the FreeHand 8 configuration: In the Output Options dialog box, I disabled "Convert RGB to process." The settings in this dialog box will affect all of FreeHand's output - either printed or exported - and this setting in particular would have invited disaster. __ For all examples, I exported from FreeHand 8 as: GIF, Interlaced, Antialiased (2 on a scale of 0 to 4), Web-Safe Palette, No Dither Results: Since FreeHand 8 was brand new to my system, I had not taken the time to set it up for production, and so I looked through the Preferences dialog box for clues. Under the Color tab, I found that the Color Management settings had defaulted to "Kodak Color Tables." Since the influence of color management was consistent with the way that the colors had been clipped, I disabled it. __ I made one more GIF file, "Test Doc_FH8_NCM.gif" and opened it up with Photoshop. That took care of the problem, now I had perfect web-safe color output from FreeHand. __ I then re-saved that image from Photoshop 4 as "Test Doc_FH8_NCM_PS4.gif" and reopened it. Colors were unchanged. continues...

Design & Publishing . / . WEB . / . Pixelsmith

Got some good inside information? Send email to: reviews@graphic-design.com