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