handling inline-container (was:Re: Handling of block-level FOs inside fo:inline and related)
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:blockfoo 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
Handling of block-level FOs inside fo:inline and related
fo:inline, fo:bidi-override and fo:inline-container are all inline-level FOs and all allow block-level content. Currently, they are not implemented. See, for example, inline1.xml which fails with a ClassCastException. The FO I skipped here is fo:wrapper which in the current implementation doesn't really wrap its content and therefore avoids an important problem: Inline FOs return element lists processed by the line breaker. They don't have a way to return elements for the page breaker. I've been asked to do a time estimate for implementing fo:inline. fo:inline is particularly important since a lot of people use empty fo:blocks, for example, to mimic newlines. Now I wonder about how to implement fo:inline. The only way I came up with was to try normalizing the FO tree and to let fo:inline be what it currently is: Input: fo:block color=blueblah blah fo:inline font-style=italicblahfo:block/blah/fo:inlineblah/fo:block Output: fo:block color=blueblah blah fo:inline font-style=italicblah/fo:block fo:block color=blue font-style=italic/ fo:block color=blue fo:inline font-style=italicblah/fo:inlineblah/fo:block or: fo:block color=blue fo:blockblah blah fo:inline font-style=italicblah/fo:block fo:block font-style=italic/ fo:blockfo:inline font-style=italicblah/fo:inlineblah/fo:block /fo:block Replicating the properties of an fo:inline to a copy shouldn't be much of a problem. Replicating the properties for the contained block might already me a little more difficult because of the whole inheritance stuff. Is there another way? A better way? Any ideas? For fo:bidi-override, the same approach would be used. For fo:inline-container this whole thing is easier since it generates a viewport/reference pair, so it will ultimately need its own breaker (like absolutely positioned block-containers). Jeremias Maerki
Re: Handling of block-level FOs inside fo:inline and related
I have been working on that, rather slowly, as I do not have much time. My solution for the Knuth Elements is that each inline level LM returns a list of Knuth sequences, inline or block. This part works well. The code works well for fo:inline with inline or block content. I have not yet implemented it in other LMs except BasicLinkLM. I have done some work for rendering. But I am not very familiar with that part of FOP, and have not yet paid attention to details. I will post a patch on Bugzilla. The present state of the code breaks other inline level LMs as they do not yet return the correct data structure for the next Knuth elements. Therefore I cannot commit it to HEAD. I could commit it into a branch. For the next few weeks I will also spend a lot of time on other things. So, if I am progressing too slowly, someone else should feel free to take this further. Regards, Simon On Wed, Aug 03, 2005 at 08:30:56PM +0200, Jeremias Maerki wrote: fo:inline, fo:bidi-override and fo:inline-container are all inline-level FOs and all allow block-level content. Currently, they are not implemented. See, for example, inline1.xml which fails with a ClassCastException. The FO I skipped here is fo:wrapper which in the current implementation doesn't really wrap its content and therefore avoids an important problem: Inline FOs return element lists processed by the line breaker. They don't have a way to return elements for the page breaker. I've been asked to do a time estimate for implementing fo:inline. fo:inline is particularly important since a lot of people use empty fo:blocks, for example, to mimic newlines. Now I wonder about how to implement fo:inline. The only way I came up with was to try normalizing the FO tree and to let fo:inline be what it currently is: Input: fo:block color=blueblah blah fo:inline font-style=italicblahfo:block/blah/fo:inlineblah/fo:block Output: fo:block color=blueblah blah fo:inline font-style=italicblah/fo:block fo:block color=blue font-style=italic/ fo:block color=blue fo:inline font-style=italicblah/fo:inlineblah/fo:block or: fo:block color=blue fo:blockblah blah fo:inline font-style=italicblah/fo:block fo:block font-style=italic/ fo:blockfo:inline font-style=italicblah/fo:inlineblah/fo:block /fo:block Replicating the properties of an fo:inline to a copy shouldn't be much of a problem. Replicating the properties for the contained block might already me a little more difficult because of the whole inheritance stuff. Is there another way? A better way? Any ideas? For fo:bidi-override, the same approach would be used. For fo:inline-container this whole thing is easier since it generates a viewport/reference pair, so it will ultimately need its own breaker (like absolutely positioned block-containers). Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl
Re: Handling of block-level FOs inside fo:inline and related
Jeremias Maerki wrote: fo:inline, fo:bidi-override and fo:inline-container are all inline-level FOs and all allow block-level content. I think an inline-container should create a single area as a first approximation, unless the content fills a whole page. Therefore it shouldn't pose a real problem in this context. I have no idea how an inline container whose content overflows the page bpd should be handled. Fortunately, in the case of changing the write mode e.g. from lr-tb to tb-lr, the ipd of the content in the inline container has to be fixed, which translates to a fixed bpd in the context of the ancestor block of the inline container. Unless I misunderstood the spec, of course. The real headache is caused by the anticipation that the most common use case for inline container will be embedding tables inline, for all kind of purposes... J.Pietschmann
Re: Handling of block-level FOs inside fo:inline and related
I'd appreciate if you'd take this to a branch (or I can do it for you with the patch you posted). That way everybody can help and branches are really easy with SVN now. ATM I only have to do an estimate not necessarily the actual implementation. My next scheduled task is the PS Renderer. So I don't know when I will have time to work on it, but I'll definitely have a closer look. Thanks for making the patch! On 03.08.2005 22:00:27 Simon Pepping wrote: I have been working on that, rather slowly, as I do not have much time. My solution for the Knuth Elements is that each inline level LM returns a list of Knuth sequences, inline or block. This part works well. The code works well for fo:inline with inline or block content. I have not yet implemented it in other LMs except BasicLinkLM. I have done some work for rendering. But I am not very familiar with that part of FOP, and have not yet paid attention to details. I will post a patch on Bugzilla. The present state of the code breaks other inline level LMs as they do not yet return the correct data structure for the next Knuth elements. Therefore I cannot commit it to HEAD. I could commit it into a branch. For the next few weeks I will also spend a lot of time on other things. So, if I am progressing too slowly, someone else should feel free to take this further. Regards, Simon On Wed, Aug 03, 2005 at 08:30:56PM +0200, Jeremias Maerki wrote: fo:inline, fo:bidi-override and fo:inline-container are all inline-level FOs and all allow block-level content. Currently, they are not implemented. See, for example, inline1.xml which fails with a ClassCastException. The FO I skipped here is fo:wrapper which in the current implementation doesn't really wrap its content and therefore avoids an important problem: Inline FOs return element lists processed by the line breaker. They don't have a way to return elements for the page breaker. I've been asked to do a time estimate for implementing fo:inline. fo:inline is particularly important since a lot of people use empty fo:blocks, for example, to mimic newlines. Now I wonder about how to implement fo:inline. The only way I came up with was to try normalizing the FO tree and to let fo:inline be what it currently is: Input: fo:block color=blueblah blah fo:inline font-style=italicblahfo:block/blah/fo:inlineblah/fo:block Output: fo:block color=blueblah blah fo:inline font-style=italicblah/fo:block fo:block color=blue font-style=italic/ fo:block color=blue fo:inline font-style=italicblah/fo:inlineblah/fo:block or: fo:block color=blue fo:blockblah blah fo:inline font-style=italicblah/fo:block fo:block font-style=italic/ fo:blockfo:inline font-style=italicblah/fo:inlineblah/fo:block /fo:block Replicating the properties of an fo:inline to a copy shouldn't be much of a problem. Replicating the properties for the contained block might already me a little more difficult because of the whole inheritance stuff. Is there another way? A better way? Any ideas? For fo:bidi-override, the same approach would be used. For fo:inline-container this whole thing is easier since it generates a viewport/reference pair, so it will ultimately need its own breaker (like absolutely positioned block-containers). Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl Jeremias Maerki
Re: Handling of block-level FOs inside fo:inline and related
On 03.08.2005 22:26:51 J.Pietschmann wrote: Jeremias Maerki wrote: fo:inline, fo:bidi-override and fo:inline-container are all inline-level FOs and all allow block-level content. I think an inline-container should create a single area as a first approximation, unless the content fills a whole page. Therefore it shouldn't pose a real problem in this context. That's what I thought. I have no idea how an inline container whose content overflows the page bpd should be handled. Well, if it simply generates a single box, that box is broken as a whole. If it doesn't fit the page: Mep! :-) I've no idea if an inline-container is supposed to be broken at all and if yes, how. Fortunately, in the case of changing the write mode e.g. from lr-tb to tb-lr, the ipd of the content in the inline container has to be fixed, which translates to a fixed bpd in the context of the ancestor block of the inline container. Unless I misunderstood the spec, of course. The real headache is caused by the anticipation that the most common use case for inline container will be embedding tables inline, for all kind of purposes... J.Pietschmann Jeremias Maerki
