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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
