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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution