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
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: > > > > blah blah > font-style="italic">blahblahblah > > > > Output: > > > > blah blah > font-style="italic">blah > > > > > font-style="italic">blahblah > > > > or: > > > > > > blah blah blah > > > > blahblah > > > > > > 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
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 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: > > blah blah font-style="italic">blahblahblah > > Output: > > blah blah font-style="italic">blah > > font-style="italic">blahblah > > or: > > > blah blah blah > > blahblah > > > 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
