[reportlab-users] Dynamic page sizes

[Glenn Linderman]

On 10/21/2011 1:57 AM, Robin Becker wrote:

> On 21/10/2011 00:53, Glenn Linderman wrote:

>> On 10/19/2011 1:45 AM, Robin Becker wrote:

>>> Glen

>> ............

>>

>> OK, this sounds like a reasonable prospect. Let's see if I grasp the 

>> concept:

>>

>> 1. create an empty list of templates for each page

>> 2. process each item (poem), creating a flowable, and use the wrap 

>> method,

>> pretending that it has an 8.5x11 page when calling it, and 

>> discovering the

>> actual size. At that point, append a template that has a page of that 

>> size to

>

> OK there is an issue here in that paragraphs will always occupy the 

> full width of the space they're given. You can get round this 

> (approximately at least) by assuming that the total area occupied by 

> the paragraph is constant. Of course if you intend always to have a 

> page width of 8.5 (minus indents and decorations etc) then you're home 

> already. generally unless you force otherwise frames have automatic 

> margins of 6 points so take that into account as well.


Thanks.  This might have confused me.  So tell me if the following 
algorithm would work, or could be optimized:

Call wrap with 8.5 width, and obtain height.  Use "binary search" on 
widths (try 4.25 width next) until locating the minimum width that 
preserves the same height as 8.5 inches.  This would call wrap 
repeatedly on the same flowable, presuming that the height returned 
reflects the actual widths used (increasing when lines are broken to fit 
the width), even though the width returned is the same as passed in.  Of 
course, I may choose a narrower maximum width as a starting point 
because of the small screens on these mobile devices.


>> the template list, and append the flowable to the set of flowables.

>> 3. create a document, using the list of templates, and the list of 

>> flowables

>> 4. build the document

>>

>> Questions that come to mind,

>>

>> A. is the flowable still reusable for the document after doing the

>> pre-processing wrap method? I guess the worst case is that I discard 

>> it and

>> create a new one without calling wrap on it.

>

> It should be.

>

>> B. margins: I'm not clear on whether the wrap size includes the 

>> margins or not,

>> I would guess not, but it seems that with a 3-column layout I did for 

>> something

>> else, that each frame may have had a bit of margin, even though I 

>> tried to

>> specify none. But that layout was using tables inside the frames, so 

>> maybe there

>> was interaction with that as well.

> The template contains a frame whose size if fixed by the construction. 

> Frames have padding in general of 6 points (top and bottom 

> left/right). When the doctemplate processes a flowable it will use the 

> frames add method and that takes the padding current position 

> spaceBefore/After etc etc into account to poisiton the flowable in the 

> frame or to reject and ask for a split etc etc.

>

> The frame's size and padding can be controlled explicitly, (not in the 

> simple doc template though unless you get creative and override the 

> build method).


Hmm.  OK, another compensation would be to increase the height and width 
of the frame by 12 points, and reduce the position by 6 points in each 
direction.  This would hard code these numbers: of course, it would be 
nicer if they could be overridden.  But that would explain why a table 
with no padding or margins) specified to be the same width as the frame 
consumed more space (slightly) than plain text in the same frame 
consumed... using the further assumption that a table inserted into a 
frame is centered on the space in the frame when it is wider than the 
frame can hold... this last assumption also seems to apply to inserting 
wide pictures in a frame... ?


>> Anyway, I suspect I can get something working with a bit of 

>> experimentation.

>> I'll look into the document object APIs a bit more for page number 

>> info, etc.

>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20111021/7ad453f2/attachment.htm>