Well, so far my experiments have been somewhat unsatisfactory. My
surmise that you can't scroll beyond the bottom of the last page was
correct: if say 60 lines fit on the first page and you have a total
of 80 lines, scrolling the pixel equivalent of 60 lines won't make
line 61 come to the top of the field: in fact AFAIK line 21 or
thereabouts will come to the top of the field, so I will have to deal
with the last page in a different way (for example by deleting all
the lines except the ones that are meant to be on the last page, and
printing what remains). The other odd thing that happened is that
when I scrolled by the amount suggested in the pageHeights, the last
line of page n was repeated at the top of page n+1. Probably my
error, but so far I don't see how. A further point is that the RR
docs (dictionary) suggests you print the field the text is in, but
actually you can't print a field, only a card: so first you have to
get the field to be the right size to fill the printable area on the
page (to which there is no general solution) and then you have to
print the card.
I'll carry on experimenting. Haven't tried it on the PC yet (with the
stack opened in FormatForPrinting mode). But it all seems a lot more
complicated than I had hoped. I'd really like to save a text file and
get the user to print it using the local text editor, but I don't
think that's in the spec...
Graham
I wrote:
Thanks to Ken Ray and Dave Cragg for pointing out the existence
'the pageHeights'. I had missed this. Although somewhat eccentric,
i.e.
Comments:
The value reported by the pageHeights property is a list of
numbers separated by returns. Each number is the height in pixels
of a page full of text.
You can use the pageHeights property to print the entire contents
of a field by printing the field, setting the field's scroll to
the first line of the pageHeights, printing the field again,
setting the scroll to the current scroll plus line 2 of the
pageHeights, and so on.
The computations used by the pageHeights property assume the
field's borderWidth property is set to zero and its margins is set
to 6.
it does look like the answer. Thanks to you both. There does at
first sight seem to be one problem, which is that if the last page
isn't full of text, then AFAIK scrolling won't work, because the
scroll will include stuff from the previous page... but as I've
been wrong about everything else I'm probably wrong about this too.
Also I'm not sure what the implications of the margins being set to
6 are... nor if this works when the formatForPrinting is set (I
suppose so, otherwise what would be the use of it?). I'll experiment.
On 3/27/06 12:36 AM, "Graham Samuel" <[EMAIL PROTECTED]> wrote:
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.
----------------------------------------
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
