More on Windows printing...

[James Steiner]

[ 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.