Avoiding line cut-off in a multipage printout

Graham Samuel 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...


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" <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
>>> thing.

Graham Samuel / The Living Fossil Co. / UK and France

More information about the Use-livecode mailing list