xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <dev.jerem...@greenmail.ch>
Subject Re: handling inline-container (was:Re: Handling of block-level FOs inside fo:inline and related)
Date Mon, 08 Aug 2005 07:32:27 GMT
Woah. I was afraid of something like that. So good inline-container is
not (yet) on my project plan. Thanks for writing this up. I've added a
link in the Wiki on it so this doesn't get lost.

On 05.08.2005 23:30:26 J.Pietschmann wrote:
> Jeremias Maerki wrote:
> > I've no idea if an inline-container is supposed to be broken at all and
> > if yes, how.
> If the ipd in the inline container is changed to be orthogonal to
> the ipd of the containing area, the inline-container may be broken
> across lines:
>   <fo:block>
>     ..... <fo:inline-container write-mode="tb" height="2cm">..
>            ...
>           </fo:inline-container>
>     .....
>   </fo:block>
> may result in a layout like (container border simulation added for
> clarity)
>        +----------
>        |..........
>   .... |..........
>        |..........
>        +----------
>   --+
>   ..|
>   . | ......
>   . |
>   --+
> The container may generate multiple areas similar to a fo:inline
> with font-size="4cm".
> Note that the height property on the inline container is mandated by
> the spec in this case (and maps to the ipd value of the container area).
> Setting the reference orientation to 90 or 270 instead of the writing
> mode should result in a similar layout.
> Trouble starts if the writing-mode resp. reference-orientation doesn't
> change the inline progression direction. There is still some relief if
> the inline container only contains a fixed width table, which thereby
> determines the width of the container itself nicely. From the questions
> on the FOP lists I gather this will be the most often utilized use case
> for inline containers, at least until people really start mixing
> classical chinese with western scripts in a single line.
> Something like
>   <fo:block width="11em">
>     qoz <fo:inline-container>
>             <fo:block>foo bar baz</fo:block>
>           </fo:inline-container>
>     quz
>   </fo:block>
> is going to be tricky, I'd say it is legal to render is as
>   qoz foo bar
>   baz quz
> (no line breaks in the block within the container, container broken
> across lines) as well as
>       foo
>   qoz bar quz
>       baz
> (block in container broken into 3 lines, container not broken).
> Unless I missed some restrictions mentioned in the spec, of course.
> We could probably get away with the following strategy:
> 1. start with ipd for the container = available space on line
> 2. if the container overflows in ipd (because a descendant generated
>   an area which is wider than the tentative ipd), undo the layout,
>   create a linebreak before the container, and continue with
>   ipd of the container = line ipd)
> 3. adjust the container ipd to the maximum ipd of the areas created
>   by the container's children.
> The example above would be laid out roughly as
>   qoz foo bar
>       baz
>   quz
> (use you imagination to center the container vertically).
> The case where the container content causes the line height to grow
> until the available space in bpd is exhausted could be added, but
> creates more layout choices, if this happens in step 1, there is
> a choice between restarting at step 2 or creating a page break before
> the line (possibly leaving a lot of ugly empty block space at the end
> of the previous page). And so on :-/ I'd like to see real use cases
> for this before I maltreat my brain by further thinking about layout
> strategies.
> J.Pietschmann

Jeremias Maerki

View raw message