More on Windows printing...

[Lynch, Jonathan]

I am trying to figure out if the definitions for printer fonts can be
used like an image, or translated into an image, and then set the image
of a character, as it is typed or pasted in, to the image of the printer
font.

It sounds like torture to me, and like it would evoke all sorts of
kerning problems - but maybe...

I was also wondering if there was a way to create a high-rez image,
piece-meal - that is, creating a direct translation of each object, and
each character, to a single image with very high resolution, and then
print the image. That sounds even more difficult - but maybe.

My other thought was to create a custom font - or custom set of fonts,
fully defined within Rev rather than in the O.S. -  and to set the
imagedata for each character to the appropriate image of the character
in the custom font (with fontsize accomplished by adjusting the size of
the image. It might work better to do such a thing in an image rather
than a field - or in a group rather than a field.

I was also wondering if there is a way to condense or expand the kerning
between characters in microscopic steps. Then, for printing, a script
could adjust the kerning as needed to keep the width the same as on the
screen.

The last sounds easiest - but I don't know if kerning is possible.


-----Original Message-----
From: use-revolution-bounces at lists.runrev.com
[mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of James
Steiner
Sent: Thursday, January 06, 2005 5:10 PM
To: How to use Revolution
Subject: Re: More on Windows printing...

[ 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
use-revolution at lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution