[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-user
Subject:    Re: Content spanning multiple pages issue
From:       Rob Sargent <rsargent () xmission ! com>
Date:       2011-07-31 3:11:44
Message-ID: 4E34C7F0.8080609 () xmission ! com
[Download RAW message or body]

OP might also be interested in calculating the required offset on the 
second page (end of the table) at which to place (absolutely??) the 
follow-on text. If so follow the (ill-named) thread "breakpoint 
suggestions please".

One is tempted to ask why the WYSIWYG editor doesn't open a second page...



Andreas L. Delmelle wrote:
> On 30 Jul 2011, at 21:13, Fernando Israel wrote:
> 
> Hi Fernando,
> 
> 
> > <snip />
> > So I now have to rephrase the question. Can I have a table within an absolute \
> > postioned block container go over to a second page it its length requires so ?. I \
> > guess that the answer is no, but I better ask. 
> 
> You guess correct.
> 
> BTW, it just occurred to me, while re-examining the FO you sent, that the \
> 'position' property does not apply to fo:block, so it actually serves no purpose \
> there. Specifying the property can almost be seen as wasteful, because it \
> 'overburdens' the property parser. Big word, because it does not matter _that_ \
> much, but "less is more". :-) 
> 
> > If the answer is no, given my description of the objective, can you think of a \
> > different way of trying to achieve the objective ?. 
> 
> Let's see...
> 
> The block-container will only be broken if its top/left positioning is relative, \
> which FOP does not support. Never mind, because that is not what you want anyway. \
> You would get a page-break, sure enough, but it would still cause _some_ of the \
> content to be clipped. In fact, what would happen if FOP were to implement it, is \
> that the block-container would be broken using the full available page-height, as \
> it does not interact with the absolute-positioned ones. Then, the generated areas \
> on each page are offset by the specified amount. Hardly surprising that nobody has \
> ever even asked questions about this on the user-list (at least AFAIK).  It doesn't \
> look useful --but I'm straying... 
> Given the above, and assuming that, in the example you sent, you would only need to \
> see that one block flowing to the next page, you could try using space-before \
> (instead of "top") and start-indent (instead of "left") to create the displacement \
> effect. 
> Something like:
> 
> <fo:block-container space-before="8.3cm" start-indent="1cm" width="auto" \
> height="auto"> <fo:block start-indent="0" font-family="Comic Sans MS,cursive" \
> font-size="16px" font-weight="700" font-style="normal" text-align="left" \
> color="rgb(0,0,0)" padding="4px"> <fo:block>TEXT 9</fo:block>
> <fo:block> Here is some sample code </fo:block>
> <fo:block> Here is some sample code </fo:block>
> ...
> 
> That way, at least that block-container will be split over multiple pages, if \
> necessary.  Any absolute-positioned content following it, will have its single area \
> on the last page spanned by the preceding, relative-positioned content. Since it is \
> likely not known in advance how many lines will end up on that last page, figuring \
> out the right value for 'top' in such cases would be quite a challenge. Using \
> 'bottom' displacement may offer a way out, here, but still... If there is then yet \
> more following relative-positioned content, it becomes increasingly difficult to \
> manage, since there is no clue as to what the initial offset should be. You would \
> have to resort to using forced breaks to make it a bit easier. 
> It all really depends on how complex the eventual result can become. If it's only a \
> single block that should flow to the next page, and it is not itself \
> interrupted/followed by absolute-positioned content, the above would suffice: use a \
> regular block-container with space-before for the initial displacement on the first \
> page, or even leave that block-container out entirely, and just insert the block. 
> Not sure if this will help, but it's very difficult to say, generically, how best \
> to address this, without actually having seen some of the more complex cases. 
> 
> 
> Regards,
> 
> Andreas
> ---
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]