Printing multiple pages

[Graham Samuel]

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. Maybe your snapshot idea is key  
(I've never noticed anyone using that approach before). I haven't  
worked my way through this yet, but I wonder if you have any tips  
before I start?

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).

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

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? 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?

Sorry that I am starting from such a point of ignorance - don't waste  
too much time on your reply!

TIA

Graham

On Sun, 18 Jan 2009 21:20:21 -0600, "J. Landman Gay" <jacque at hyperactivesw.com 
 > wrote:
> [snip...]
>
> I know it's more work up front, but I recommend the separate printing
> stack approach, especially since you want to implement a print  
> preview.
> I just finished writing one of those. Having a separate stack made it
> easier because I didn't have to worry about the initial stack size;  
> the
> printing stack was already laid out to accomodate the right paper  
> size.
> For a print preview, I ran my printing script normally, but added a
> parameter to my printing handler that indicated whether this was going
> to a preview or a printer. If printer, the script implemented "open
> printing", etc. If preview, it put a snapshot of the loaded page  
> into a
> variable and sent it back to the calling handler.
>
> I then created (yet another) substack for showing print previews. This
> is the stack that actually calls the printing command in the print
> stack. This one-card preview stack had "next" and "previous" buttons  
> and
> a few other controls. The snapshot the printing handler returned was
> loaded into an empty image object in the preview stack. The image was
> then resized according to the size of the preview window. Sometimes it
> looked fuzzy at certain sizes, but it was adequate. If it doesn't  
> matter
> for you app, I think I'd remove the resizing ability and lock the
> preview to the size of the paper. That way snapshots wouldn't distort,
> they would always be at 100%.
>
> -- 
> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com