Printing multiple pages

[J. Landman Gay]

Graham Samuel wrote:
> Jacque - I'm very interested in your approach because I'm just going to 
> tackle the same thing (including the preview), the first time I've tried 
> anything like this in Rev 3. One issue that has bothered me in earlier 
> versions of Rev is the formatForPrinting thing - the problem of working 
> out exactly where the line and page breaks will be on Windows and then 
> how to simulate them in a Preview which looks OK on screen. I have 
> always found the Rev docs very difficult to follow here: there seem to 
> be restrictions which make it impossible to modify a stack with 
> formatForPrinting set, so it seems that it's impossible to show the user 
> an accurate representation of what will be printed and allow them to 
> modify it - something that the crudest word processor can do on any 
> platform.

It isn't that you can't modify a stack with formatForPrinting set to 
true, it's that manual editing may throw off the display. I set the 
formatForPrinting of the stack to true when I created it and forgot 
about it. The user never sees it, and therefore can't manually change 
it. Dumping new text into the fields isn't a problem with this property set.

> Re-reading what I've just written, perhaps I should clarify the things 
> I'm trying to do:
> 
> 1. Allow a Rev standalone to print multiple pages on Windows or Mac, the 
> app itself making sensible decisions based on what will fit on a page 
> (avoiding widowed lines etc).

I was lucky in that we had one fixed page per item in a database, 
printed in a pre-formatted report layout where everything fit, so I 
didn't have to calculate field pagination. However, I've done that 
before and having formatForPrinting set to true is actually required in 
that case because it affects line wrap. So again, setting it once on an 
invisible printing stack and forgetting about it should work fine. When 
you get the pageheights, they will be accurate if that property is true 
(but they may not be the same as what your users see if you allow 
editing in a stack without the property set.) Another advantage is that 
stacks are not automatically set to resize to the monitor when this 
property is set; that allows you to open a tall (paper-sized) stack on a 
small monitor without the engine trying to squeeze it into the screenrect.

> 
> 2. Allow the user to see an exact preview of what will be printed, with 
> our without scaling.

Once you have the layout stack populated with data, a snapshot gives you 
the exact printout appearance -- with one caveat. To accomodate 
printmargins, the layout stack must start its object placements at the 
far left and top edges. This will give accurate placement when 
printmargins are added later by both the printing script and the default 
printer margins. When displaying a snapshot preview, you'll have to take 
printmargins into account so that the snapshot is placed accurately on 
your preview stack. If you intend to just dump the snapshot into the 
center of a card, no problem, but I wanted the outline of a piece of 
paper so that users could see how it would actually look when placed on 
a page.

What I did for this was create a rectangular button at layer 1 that was 
intended to be a representation of a piece of paper. (I used a button 
rather than a graphic because button shading gives a slightly raised, 3D 
appearance. Make the borders really small, like 1 pixel, with a white 
fill. A graphic would work too. It doesn't matter what you use, it's a 
visual aid only and is never used for anything else.) When I loaded the 
snapshot into the image, I calculated the number of pixels to offset the 
position of the snapshot, scaled to the proportion of the current 
preview size. In other words, if the printmargins were to be 1 inch 
around (72 px) and the current preview was at 50%, then the snapshot 
image needed to be placed 36 px down and to the right of the topleft of 
the button.

> 
> 3. Allow the user to tweak the layout if the preview doesn't meet 
> his/her requirements (revisiting the widowed lines etc and maybe the 
> margins - I'm not looking for complete editing facilities).
> 
> I think your approach covers part of (1), all of (2) and none of (3) - 
> is this right?

Right. I'm not sure how I'd handle manual editing. Editing with 
formatForPrinting set to true won't always produce accurate results, and 
editing without it may not create an accurate representation of what 
will be printed.

> In the operation of your app prior to (1), do you allow 
> your user to choose a font or fonts and/or variable type sizes, or is 
> all that fixed? If you do allow this flexibility, does this add to the 
> complexity of the printing stage?


The printout was predetermined and fixed, so I set all the font and size 
properties while creating the printing stack. But in other projects I've 
had no problems setting font and size properties in fields when 
formatForPrinting is true. I'm not sure whether setting the properties 
of individual text chunks would be a problem, but I can't think why it 
wouldn't work. It could affect text wrap though. Bold text is wider than 
plain text, etc.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com