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
