xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Sargent <rsarg...@xmission.com>
Subject Re: Content spanning multiple pages issue
Date Sun, 31 Jul 2011 03:11:44 GMT
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

View raw message