It gets worse! I see now that the script can't know the exact number
of lines that will be printed without clipping on a properly
formatted page under Windows! What I can't understand (as with other
aspects of printing) is why so few developers seem to care about
this. Not everybody reads stuff on the screen: for example teachers,
I find, want to carry bits of paper away with them (such as student
reports) even if the actual app is a highly interactive screen-based
thing.
It seems to me that in principle we can't know how much wiggle room
to leave, because we can't know how different the screen and printer
versions of Windows fonts might be. I haven't any real experience of
this, but I guess that for some unusual fonts they might be very
different indeed. And I want my printing handler to be sufficiently
generalised to allow it to print a text in any available font, chosen
by the user and therefore not predictable by me. After all that's
what even the most elementary text editors do. Come to that, what
does the RR IDE do?
Is there nobody out there who has developed a rock-solid solution to
this?
Puzzled
Graham
On Sun, 26 Mar 2006 16:57:51 -0800, Scott Morrow
<[EMAIL PROTECTED]> wrote:
Graham,
This is what I do, also and I agree that using the formattedHeight of
characters seems more convoluted than one would like. Or perhaps I
don't understand things well enough. I've found that when I switch
to < formatForPrinting > the heights of things change enough to cause
problems with any exact calculation I might have done (last line may
be partially clipped) unless I leave some wiggle room in my
calculations. Using lines would be nice.
On Mar 26, 2006, at 5:36 AM, Graham Samuel wrote:
I have a print routine adapted from something Hugh Senior put in
The Scripter's Scrapbook (thanks Hugh). I may well have done
something stupid to it, but I am making heavy weather of making
sure that if I'm printing more than a single page of text, the last
line on any given page is not cut off so that only part of the line
shows.
The issue is that AFAIK, RunRev thinks only in terms of pixels and
not in terms of lines of type. In these circumstances the only way
I can think of to avoid the cutoff is to add up all the formatted
heights of the successive lines until I find I've overflowed my
page area, then backtrack one whole line and print that (I'm
thinking of a generalised routine which will handle lines in
different fonts and of different heights, so I can't simply look at
the height of the first line and work from there).
This works but it seem incredibly clunky. I assume that this
problem has been solved many times, and that maybe there is even a
way of telling RR that you want to print in whole lines but I've
somehow missed it.
I'd be grateful for any advice.
Graham
----------------------------------------
Graham Samuel / The Living Fossil Co. / UK and France
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
----------------------------------------
Graham Samuel / The Living Fossil Co. / UK and France
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
