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

Reply via email to