You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@greenmail.ch> on 2005/08/03 20:30:56 UTC
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="blue">blah blah <fo:inline font-style="italic">blah<fo:block/>blah</fo:inline>blah</fo:block>
Output:
<fo:block color="blue">blah blah <fo:inline font-style="italic">blah</fo:block>
<fo:block color="blue" font-style="italic"/>
<fo:block color="blue" ><fo:inline font-style="italic">blah</fo:inline>blah</fo:block>
or:
<fo:block color="blue">
<fo:block>blah blah <fo:inline font-style="italic">blah</fo:block>
<fo:block font-style="italic"/>
<fo:block><fo:inline font-style="italic">blah</fo:inline>blah</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
Posted by Jeremias Maerki <de...@greenmail.ch>.
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="blue">blah blah <fo:inline font-style="italic">blah<fo:block/>blah</fo:inline>blah</fo:block>
> >
> > Output:
> >
> > <fo:block color="blue">blah blah <fo:inline font-style="italic">blah</fo:block>
> > <fo:block color="blue" font-style="italic"/>
> > <fo:block color="blue" ><fo:inline font-style="italic">blah</fo:inline>blah</fo:block>
> >
> > or:
> >
> > <fo:block color="blue">
> > <fo:block>blah blah <fo:inline font-style="italic">blah</fo:block>
> > <fo:block font-style="italic"/>
> > <fo:block><fo:inline font-style="italic">blah</fo:inline>blah</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
Posted by Simon Pepping <sp...@leverkruid.nl>.
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="blue">blah blah <fo:inline font-style="italic">blah<fo:block/>blah</fo:inline>blah</fo:block>
>
> Output:
>
> <fo:block color="blue">blah blah <fo:inline font-style="italic">blah</fo:block>
> <fo:block color="blue" font-style="italic"/>
> <fo:block color="blue" ><fo:inline font-style="italic">blah</fo:inline>blah</fo:block>
>
> or:
>
> <fo:block color="blue">
> <fo:block>blah blah <fo:inline font-style="italic">blah</fo:block>
> <fo:block font-style="italic"/>
> <fo:block><fo:inline font-style="italic">blah</fo:inline>blah</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 inline-container
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeremias Maerki wrote:
> Woah. I was afraid of something like that.
Don't worry, it'll get worse! :-)
>>The container may generate multiple areas similar to a fo:inline
>>with font-size="4cm".
^
Should have been 2cm of course.
J.Pietschmann
Re: handling inline-container (was:Re: Handling of block-level FOs inside fo:inline and related)
Posted by Jeremias Maerki <de...@greenmail.ch>.
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
handling inline-container (was:Re: Handling of block-level FOs inside
fo:inline and related)
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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
Re: Handling of block-level FOs inside fo:inline and related
Posted by Jeremias Maerki <de...@greenmail.ch>.
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: Meeeeep! :-)
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
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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