Avoiding line cut-off in a multipage printout
livfoss at mac.com
Mon Mar 27 12:38:53 EST 2006
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...
> Thanks to Ken Ray and Dave Cragg for pointing out the existence
> 'the pageHeights'. I had missed this. Although somewhat eccentric,
>> 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" <livfoss at mac.com> 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
Graham Samuel / The Living Fossil Co. / UK and France
More information about the Use-livecode