[ Re: differences in text rendering on screen vs. on printer in windows, and the absense of differences in macintosh ]
The main reason there's a difference is the huge difference in resolution on the two surfaces. Screens are around 90 dots per inch (my 17" LCD is about 105 dpi). Printers now-a-days are from 300 to 1200 dpi. That means scaling happens, and that means rounding "choices" in the rendering can make a big difference. The underlying source of the problem is the code that reports the height and width of a rendered chunk of text, allowing other code to decide where the word-wrap point is, or what the size of the bounding box is, or whatever. If the code "cheats", it might be rounding results to the nearest pixel, or integer pixel, or something, rather than returning some more precise value. Since on-screen text generally requires at least a 1 pixel gap between characters, whereas a printer does not have that limitation (rather, it's pixels are much, much smaller), differences are almost certain, at some point. Likewise, depending on the interlocked layers of api and other code used, there may be multiple conversions from pixels to twips to inches or centimeters and back again. Firther, when a printer (or printer driver) renders the same text using it's own rendering engine (or whatever printer rendering api or home-grown solution the application uses), it may get different results. Another source of error is in the defined thicknesses of elements like field borders, bounding boxes, and the like: on screen, they may be rounded up or down to whole pixels, but on printer, they are drawn more precisely. It's probable that the Mac text rendering API is more precise, and more closely tied to the printing renderer -- thus the consistancy between media. It's also probable that Microsoft does NOT use the standard text rendering API or printing API (or, at least, not the same one that revolution uses) in MS Word, but rather a more precise one, likewise tuned for consistancy. Though, I'll note that I have seen Word, Excel, Access AND Powerpoint butcher carefully laid out text in the translation to printer on many occaisions. So, if all this rationalizing and conjecture is true, the most reliable solution would be to give up trying to precisely fill text fields. Leave slack. Do your own wrapping or clipping, and tend to wrap or clip sooner, rather than later. If rev has it, use a function/method that returns the size of rendered text, and scale the results. Some applications actually use a seperate form for composing the printed version of the page, optimized to reduce errors in rendering for print. I hope there is a better answer out there than that. ~~James. _______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
