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" <[email protected]
> 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 | [email protected]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
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
