RE: [REDESIGN] Line layout manager discussion

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

Discussion follows below.

> -----Original Message-----
> From: karen@club-internet.fr [mailto:karen@club-internet.fr]On Behalf Of
> Karen Lease
> Sent: April 29, 2002 5:39 PM
> To: fop-dev@xml.apache.org
> Subject: [REDESIGN] Line layout manager discussion
>
> Keiron Liddle wrote:
> > So why flatten the inline layout managers?
> > If we have an example like this:
> >
> > <block>Some text <basic-link>a paragraph of text<block>with a
> > block</block>and more text</basic-link> and <inline
> background="blue">blue
> > background<inline color="green"> green text <block>a block</block> more
> > green</inline></inline></block>
> >
> > The basic link produces/returns both inline areas and a block
> area, so it
> > is not possible to say that the basic-link element or its layout manager
> > would produce inline areas. So how should this be handled. If it is
> > flattened things are easier. The layout manager can then keep range
> > information like: starts link, ends link.

I think this FO snippet is sufficiently complex as to be a good
Gedankenexperiment. I prepared a PNG which illustrates the area tree as _I_
interpret the spec applying to this FO.

You'll have to view the image in colour. I have taken liberties with WS,
border colours, spaces, padding etc etc. I threw in one page break to make
things interesting. Also, I have shown runs of texts as combined inlines,
where we know in fact that they are really containers for a bunch of glyph
areas.

Here's some of the main principles I am keeping in mind:

1. An area must have its child areas all of the same type (inline or block);
2. No area may have more than one normal block area returned by the same
fo:block;
3. No area may have more than one normal inline area returned by the same
inline (fo:inline, fo:basic-link);
4. A block generates normal block areas. If a child FO returns a block area
this becomes a direct child of one of those block areas. If a child returns
a sequence of inline areas, these become children of line areas which are in
turn children of a normal block area;
5. An inline generates normal inline areas. Each such may contain a sequence
of inline areas or a single block area.

Absolutely nobody else is going to agree 100% with my interpretation, but I
think if we can hash this out it will allow us to really move forward with
confidence.

a) There are no block-level children of the top block, only inlines, so we
know that the one or more block areas generated by the top-level block are
going to contain line areas. Because of the page break there are 2 normal
block areas generated by the top-level block;

b) "some text" is simple - the inline goes neatly into the first line area
as its first child;

c) Now we hit the basic link. This generates one or more normal inlines,
which are outlined in orange. The "a paragraph of text" is the first inline
child of the first normal inline area generated by the basic-link;

d) we hit the nested block. OK, this is where the anguish starts. :-) It
produces at least one normal block area, by definition. I have given this a
pale green background. This _cannot_ occupy the first normal inline area
generated by the basic-link, because that already contains an inline area
(rule 1). So it must be in a second normal inline area generated by the
basic-link. By rule 3, the first line area may not contain 2 areas generated
by the same inline, so that's why we terminate line aea 1 and start another;

e) In the second line area (outlined in dark blue), we have the second
normal inline area generated by the basic-link, outlined in orange. This
contains a single block area generated by the nested block (rule 5). In
order for the block area to handle the contained text ("with a block") it
must itself have a line area with inline children (one or more - I've shown
one);

f) we encounter "and more text". The same argument applies as in 'd' - the
second inline area generated by the basic link cannot accept the inline area
this text results in because it already contains a block area. So, a third
inline area gets generated by the basic link, and by rule 3, this results
yet again in another line area;

g) the third line area, now graced by the presence of the last normal inline
generated by the basic-link (and its children), is able to handle more line
areas, and so "and" and ""blue background" and "green text" certainly are
allowed. I chose to insert a line break after the "green". I hope the
colours help distinguish what is what - the inline child of the top-level
block ends up creating 4 normal inline area which have blue backgrounds;

h) the doubly-nested inline produces inline areas that in fact have a
transparent background and so everything should be blue, but I thought this
would lack clarity. The normal inline areas produced by the doubly-nested
inline have a thicker brown border. The same argument applies to the block
which is nested in _this_ inline; the combination of rules 1 and 3 require
different line areas. Again, the normal block area generated by the
doubly-nested block has a pale green background;

_If_ there were blocks nested inside the top-level block these would produce
normal block areas that are single children of normal block areas produced
by the top-level block. My reading of Line-Building is that normal block
areas generated by a fo:block have either _single_ block areas _or_ one or
more line areas as children, not a mixture.

Final comment: it is the close intermingling of inlines and blocks in this
example that causes so much line breaking. Clearly each of the 2 nested
blocks could be wrapped in inlines (fo:inline or whatever), and as a result
everything in the example, in theory, could be in _one_ line area.

Anyhow, please critique away. :-)

Regards,
Arved

RE: [REDESIGN] Line layout manager discussion

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

Comments inline.

> -----Original Message-----
> From: Peter B. West [mailto:pbwest@powerup.com.au]
> Sent: May 1, 2002 2:19 AM
> To: fop-dev@xml.apache.org
> Subject: Re: [REDESIGN] Line layout manager discussion
>
[ SNIP ]
> Look at
>
> <basic-link>a paragraph of text <block>with a block</block> and more
> text</basic-link>
>
> What about the restriction that a given area's children must all be of
> the one type (4.2.1 Area Types)?  Doesn't that oblige us to wrap the
> block within an inline?  Then that inline wrapper can sit in sequence
> with the inline-areas 't', 'e', 'x', 't', ' ', as indeed the basic-link
> inline-area already sits in sequence with 'S','o','m','e','
> ','t','e','x','t',' '?
>
> What's your take on this?

There were many discussions last year, as I recall, that espoused this
viewpoint, that the area rules precluded a number of FO-level combinations
and juxtapositions. This school of thought, and I belong(ed) to it, held
that a block or inline contains either block FO children _or_ inline FO
children, but not both.

I am no longer convinced that this needs to be the case. It is certainly
safe to ensure that all the children of a given FO are either block-level
FOs _or_ inline-level FOs. In these cases we have area generation and layout
which is (I think) well understood. But this treatment shows, I think, that
the area rules can be satisfied without having to homogenize the type of FO
children.

4.2.1 is a restriction on areas, as you know. Certainly the areas that I
have diagrammed do not violate this constraint.

> N.B.  I have attached the SVG generated by Dia.  I don't know what the
> quality is like, but if the quality of the generated PNG is anything to
> go by, probably not too good.  If we can all get access to a reasonable
> SVG vector editor that will write PNGs, we will be able to pass the
> editable file around as well, which will greatly facilitate this sort of
> discussion.  Any candidates for a linux-enabled SVG editor?

I'll have to take a look around. I happened to use Visio because it's on the
machine and I'm familiar with it, plus it's a nice piece of gear. The most
recent Visios do SVG, I believe, but I don't have a copy at home.

We could use Postscript as well.

Arved



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

["Peter B. West" <pb...@powerup.com.au>]

Arved,

Firstly, thanks for taking the trouble to do this.  Your diagrams make 
your argument beautifully clear, and facilitate discussion for everyone, 
even XSL spec novices.  Even me, who struggles to follow text-only 
arguments.  I haven't followed all of the posting yet, but one question 
has come up for me already.

Look at

<basic-link>a paragraph of text <block>with a block</block> and more 
text</basic-link>

What about the restriction that a given area's children must all be of 
the one type (4.2.1 Area Types)?  Doesn't that oblige us to wrap the 
block within an inline?  Then that inline wrapper can sit in sequence 
with the inline-areas 't', 'e', 'x', 't', ' ', as indeed the basic-link 
inline-area already sits in sequence with 'S','o','m','e',' 
','t','e','x','t',' '?

What's your take on this?

N.B.  I have attached the SVG generated by Dia.  I don't know what the 
quality is like, but if the quality of the generated PNG is anything to 
go by, probably not too good.  If we can all get access to a reasonable 
SVG vector editor that will write PNGs, we will be able to pass the 
editable file around as well, which will greatly facilitate this sort of 
discussion.  Any candidates for a linux-enabled SVG editor?

Peter

Arved Sandstrom wrote:
...

>a) There are no block-level children of the top block, only inlines, so we
>know that the one or more block areas generated by the top-level block are
>going to contain line areas. Because of the page break there are 2 normal
>block areas generated by the top-level block;
>
>b) "some text" is simple - the inline goes neatly into the first line area
>as its first child;
>
>c) Now we hit the basic link. This generates one or more normal inlines,
>which are outlined in orange. The "a paragraph of text" is the first inline
>child of the first normal inline area generated by the basic-link;
>
>d) we hit the nested block. OK, this is where the anguish starts. :-) It
>produces at least one normal block area, by definition. I have given this a
>pale green background. This _cannot_ occupy the first normal inline area
>generated by the basic-link, because that already contains an inline area
>(rule 1). So it must be in a second normal inline area generated by the
>basic-link. By rule 3, the first line area may not contain 2 areas generated
>by the same inline, so that's why we terminate line aea 1 and start another;
>  
>

Re: [REDESIGN] Line layout manager discussion

[Karen Lease <kl...@club-internet.fr>]

Peter,

Here's my point of view on where line-breaking (perhaps including
hyphenation) happens.

The end result of layout is a sequence of nested areas. However while
layout is happening, line-breaking logic has to "pretend" that it's only
working on a flat row of characters and other inline leaf nodes like
external graphics.

Keiron and I took different approaches to this, but the idea is about
the same: lower level layout managers return information to the Line
Layout Manager which allows it to make a decision about where to break
the line. Once that decision is made, the appropriate areas can be
created, depending on where the break occurs.

Although it's possible to send information about IPDim down to lower
level inline layout managers, I think it's simpler and clearer to
concentrate knowlege (and strategy) about line-breaking in a single
layout manager: the one actually creating Line Areas.

There's a strong analogy with block-direction layout, where the Flow
level (or perhaps the Page level?) LM is responsible for determining
column/page breaks based on information provided by the lower level
layout managers. The Flow and Line level LM are also responsible for
"justifying" in either the inline or block progression dimensions and
deciding how much stretch or shrink should be done. They either pass
this information down to lower level layout managers (that was my plan)
or do it directly on the flattened areas (Keiron's approach, at least at
the line level).

-Karen

"Peter B. West" wrote:
> 
.......

> This leaves a question about where hyphenation is decided. In 4.7.2
> point 5, there is a discussion about glyph substitution, insertion and
> deletion which seems to assume that the sequences of inline-areas being
> built into line-areas are in fact fo:characters. The corresponding
> sequences bubbling up from fo:inline and fo:basic-link are already
> wrapped as integral inline-areas and presented as a fait accompli to the
> parent line-builder.
> 
> The fo:inline/fo:basic-link fo must obviously receive IPDim and BPDim
> information in order to present sane integral inline-areas to its
> parent, and to allow for the layout of nested fo:blocks. (This is pure
> hierarchical galley stuff.) In any case, there should be a correspondent
> in 4.7.3 to the discussion of substitution, insertion and deletion in
> 4.7.2, just to make it clear what the responsibilities of the
> inline-builder are. That's if I have this right, this time. What do you
> think?

> Peter



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

["Peter B. West" <pb...@powerup.com.au>]

Arved,

My apologies. I was just taking the opportunity to think aloud about 
aspects of the interaction between inline-areas and block-areas. Trying 
to make sense of the various elements of the spec leaves your ears buzzing.

Peter

Arved Sandstrom wrote:

>>>For the record, I disagree with Arved's reading of Line-Building. I read
>>>4.7.2, point 5 as saying that a block area generated by an fo:block can
>>>contain a mixture of block areas and line areas.
>>>
>>>      
>>>
>>Agreed. In fact, it seems to me that the line-area is a pseudo-block
>>designed to maintain the condition that the all of the children of an
>>area must be of the same type, in the circumstance where there will
>>clearly be block children of an fo:block, and to allow for simple block
>>stacking in the BPDir. There is no need to wrap block areas in a
>>line-area.
>>    
>>
>
>On that last point let me clarify and point out that I never suggested that.
>By definition a line area is a block area that contains only inline areas as
>children.
>
>The quibble was over whether block areas returned/generated by by FO
>children, and line areas that wrap inline areas returned/generated by FO
>children, can/must/shouldn't co-exist in a single normal block area
>generated by the top-level block FO. I was suggesting the "shouldn't"
>viewpoint; Karen reads it differently.
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: [REDESIGN] Line layout manager discussion

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

> -----Original Message-----
> From: Peter B. West [mailto:pbwest@powerup.com.au]
> Sent: May 2, 2002 11:26 PM
> To: fop-dev@xml.apache.org
> Subject: Re: [REDESIGN] Line layout manager discussion
>
> Karen Lease wrote:
>
[ SNIP ]
> >For the record, I disagree with Arved's reading of Line-Building. I read
> >4.7.2, point 5 as saying that a block area generated by an fo:block can
> >contain a mixture of block areas and line areas.
> >
> Agreed. In fact, it seems to me that the line-area is a pseudo-block
> designed to maintain the condition that the all of the children of an
> area must be of the same type, in the circumstance where there will
> clearly be block children of an fo:block, and to allow for simple block
> stacking in the BPDir. There is no need to wrap block areas in a
> line-area.

On that last point let me clarify and point out that I never suggested that.
By definition a line area is a block area that contains only inline areas as
children.

The quibble was over whether block areas returned/generated by by FO
children, and line areas that wrap inline areas returned/generated by FO
children, can/must/shouldn't co-exist in a single normal block area
generated by the top-level block FO. I was suggesting the "shouldn't"
viewpoint; Karen reads it differently.

I am off to work so cannot comment more at the moment, on anything. :-)

Arved


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

["Peter B. West" <pb...@powerup.com.au>]

Karen,

Comments below.

Karen Lease wrote:

>Arved, Keiron et. al.
>
>I guess logically it's true that the blocks nested in inlines should be
>wrapped in inline areas, but it makes me nervous :-)
>At least they cause line breaks, that much seems sure. I still think
>that we should put pressure on the spec editors to either get rid of
>structure or clarify it in the next version (ha, ha). If people need
>blocks in inlines, they have inline-container.
>
>In fact, I'd like to think that the possibility of including block-level
>FOs in inline-level FOs is purely for convenience or "semantic nesting"
>and should not really affect the area tree, except to cause line breaks
>before and after the block areas.
>
>The most legitimate use I can see for this kind of semantic nesting is
>basic-link, because it could spread the link semantics over several
>areas; kind of a link-wrapper.
>
>-------------
>
>For the record, I disagree with Arved's reading of Line-Building. I read
>4.7.2, point 5 as saying that a block area generated by an fo:block can
>contain a mixture of block areas and line areas.
>
Agreed. In fact, it seems to me that the line-area is a pseudo-block 
designed to maintain the condition that the all of the children of an 
area must be of the same type, in the circumstance where there will 
clearly be block children of an fo:block, and to allow for simple block 
stacking in the BPDir. There is no need to wrap block areas in a line-area.

>Also, if we look at 4.7.3 (inline-building), I find it curious that it
>starts by saying TWICE that an inline FO places inline areas and anchor
>inline areas returned by its child FOs in inline areas which it
>generates, and then suddenly throws a block-area into the condition
>described in point 1. Looks more like a hasty copy/paste from the list
>for Line-building!
>
It's not just curious, it's contradictory. I have come around to Arved 
way of thinking on the behaviour of blocks in inline-areas, but the only 
way that I can see to do it is to change the relevant part of 4.7.3 to read:

An inline-level formatting object F which constructs one or more 
inline-areas does so by placing normal inline-areas *and/or normal block 
areas* and/or anchor inline-areas returned to F by its child formatting 
objects as children of inline-areas which it generates.

Then what seems to me to be the *intention* that layout within fo:inline 
and fo:basic-link proceed as though these wrappers were 
layout-transparent, would be made clear. That is, blocks bubbling up 
from below will be stacked in the BPDir without IPDir attachments from 
surrounding inline-areas. This will be guaranteed by the partitioning 
arrangements of 4.7.3. The difference from 4.7.2 will be that these 
blocks will be wrapped in an inline-area generated by the fo:inline, 
which will in turn be wrapped in a line-area, exactly as per Arved's 
diagram.

However, as far as I can tell, this last level of wrapping is done by 
the parent fo:block in the process of laying out the inline-areas that 
are being returned by the the fo:inline. The decision to return a 
separate inline-area wrapping a block-area is made entirely by the 
fo:inline (or fo:basic-link). By the time the block gets to the parent 
block for layout, it is an inline area, and the only reason it is laid 
out in its own line-area is the constraint (from 6.6.7 fo-inline) that 
"no area may have more than one normal child area returned by the same 
fo:inline formatting object." The same constraint applies to fo:basic-link.

This leaves a question about where hyphenation is decided. In 4.7.2 
point 5, there is a discussion about glyph substitution, insertion and 
deletion which seems to assume that the sequences of inline-areas being 
built into line-areas are in fact fo:characters. The corresponding 
sequences bubbling up from fo:inline and fo:basic-link are already 
wrapped as integral inline-areas and presented as a fait accompli to the 
parent line-builder.

The fo:inline/fo:basic-link fo must obviously receive IPDim and BPDim 
information in order to present sane integral inline-areas to its 
parent, and to allow for the layout of nested fo:blocks. (This is pure 
hierarchical galley stuff.) In any case, there should be a correspondent 
in 4.7.3 to the discussion of substitution, insertion and deletion in 
4.7.2, just to make it clear what the responsibilities of the 
inline-builder are. That's if I have this right, this time. What do you 
think?

>As Keiron says, if the spec writers had been clearer, we wouldn't have
>to spend hours chasing our tails like this!
>
Or, alternatively, if they would clarify these questions in a timely manner.


Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

[Karen Lease <kl...@club-internet.fr>]

Hi Keiron,

I think this is a good start. I especially like the illustration which
covers all aspects of the problem.

I have some suggestions for the proposed text (see below).

-Karen

Keiron Liddle wrote:
> 
> Hi devs,
> 
> I have attached a picture of how I think this process should work (in
> principle not necessarily with actual areas or code).
> 
> The spec should say something like:
> 
> 4.7.2
> A block level formatting object which contains inline level formatting
> objects that will create inline areas will create lines.

"A block level formatting object may contain both other block-level and
inline level formatting objects. The block level FO creates and returns
a block area or several block areas if it is split across more than one
column or page."

> Any block level areas that are return[ed] by child formatting objects will
> be placed as direct children of this block area.
> Any inline level areas which are[a] return[ed] by child formatting objects
> will be placed into line areas.
> Consecutive inline areas will be placed into line areas.

Minor corrections in "[]" above.

> The sequence of child areas returned to this block area will be handled
> so that a sequence of inline areas will be placed into a sequence of
> line areas and block areas will be placed in the correct order.
 
Not sure this is quite clear enough; it also needs to express the idea
that the ordering between the intermingled blocks and inlines is
correct.

> (part 5. point 1 then says that any child fo that returns a block area
> means that the block area is a direct child of the current block area)
> 
> 4.7.3
> An inline level formatting object creates and returns inline areas and
> returns any block areas. Each line area can contain only one inline area
> created by the inline level formatting object. This inline area is
> created by adding child inline areas that are allowed in the parent line
> area (it is not required to fit, eg. no wrap).

I'm not sure this is the right place to mention linebreak and overflow
issues. The main idea is that an inline-level FO creates at least one
inline area which holds inline areas generated and returned by any
inline level child FOs. It might generate several inline areas, each one
being placed in a new line area, if all its content doesn't fit in a
single line. If the inline has any block-level FO descendants the block
areas which they generate are directly returned by the inline FO.
 
> 6.6.7 (and other inline fo's)
> Areas:
> The fo:inline returns these areas, any block areas, any
> page-level-out-of-line ...
> 
> ----------------
> 
> So does that make more sense?
> I think some of the confusion is that a block area can create multiple
> block areas but this only occurs at page/column breaks.

I assume you mean a "block level FO can create multiple block areas".
And similarly, an inline level FO can create multiple inline areas if it
is broken into several lines.
 
> Regards,
> Keiron.
> 
>   ------------------------------------------------------------------------
>                Name: line.svg
>    line.svg    Type: image/svg
>            Encoding: base64
> 
>                Name: line.gif
>    line.gif    Type: GIF Image (image/gif)
>            Encoding: base64
> 
>   ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: [REDESIGN] Line layout manager discussion

[Keiron Liddle <ke...@aftexsw.com>]

On Sat, 2002-05-04 at 18:07, Arved Sandstrom wrote:
> I couldn't tell from the SVG source what you prepared the file with. I would
> like to use SVG myself. There is no way I am going to handcode it, though
> (just as with FO).

I actually wrote it by hand.
I tried using an editor but gave up, instead I just edit by hand and
view it using batik. In this case it was fairly easy since everything is
placed in a definite position.


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

["J.Pietschmann" <j3...@yahoo.de>]

Arved Sandstrom wrote:
> I couldn't tell from the SVG source what you prepared the file with. I would
> like to use SVG myself. There is no way I am going to handcode it, though
> (just as with FO).

Tell me what you need and i design a diagram description
language and an XSL to transform it into SVG. :-)

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: [REDESIGN] Line layout manager discussion

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

> -----Original Message-----
> From: Keiron Liddle [mailto:keiron@aftexsw.com]
> Sent: May 3, 2002 9:31 AM
> To: fop-dev@xml.apache.org
> Subject: Re: [REDESIGN] Line layout manager discussion
>
> Hi devs,

Be careful with the abbreviations. :-) One small slip of the keys and we'll
all be referred to as debutantes.

> I have attached a picture of how I think this process should work (in
> principle not necessarily with actual areas or code).

I couldn't tell from the SVG source what you prepared the file with. I would
like to use SVG myself. There is no way I am going to handcode it, though
(just as with FO).

Arved


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

[Keiron Liddle <ke...@aftexsw.com>]

Hi devs,

I have attached a picture of how I think this process should work (in
principle not necessarily with actual areas or code).

The spec should say something like:

4.7.2
A block level formatting object which contains inline level formatting
objects that will create inline areas will create lines.
Any block level areas that are return by child formatting objects will
be placed as direct children of this block area.
Any inline level areas which area return by child formatting objects
will be placed into line areas.
Consecutive inline areas will be placed into line areas.

The sequence of child areas returned to this block area will be handled
so that a sequence of inline areas will be placed into a sequence of
line areas and block areas will be placed in the correct order.

(part 5. point 1 then says that any child fo that returns a block area
means that the block area is a direct child of the current block area)

4.7.3
An inline level formatting object creates and returns inline areas and
returns any block areas. Each line area can contain only one inline area
created by the inline level formatting object. This inline area is
created by adding child inline areas that are allowed in the parent line
area (it is not required to fit, eg. no wrap). 


6.6.7 (and other inline fo's)
Areas:
The fo:inline returns these areas, any block areas, any
page-level-out-of-line ...


----------------

So does that make more sense?
I think some of the confusion is that a block area can create multiple
block areas but this only occurs at page/column breaks.

Regards,
Keiron.

Re: [REDESIGN] Line layout manager discussion

["Peter B. West" <pb...@powerup.com.au>]

Karen,

Comments below.

Karen Lease wrote:

>Keiron Liddle wrote [06 May 2002 10:21:28 +0200]:
>  
>
>>>>From a practical viewpoint it makes sense to wrap the block in an inline
>>area with the traits and treat the block normally in layout terms but it
>>still feels uncomfortable. It also introduces a whole lot of other
>>questions about line height, padding etc.
>>
>
>I believe another consequence is that the block-area embedded in the
>inline can't be broken, since it would mean splitting a "line" (ie, the
>line containing the inline-area which is wrapping the block-area). I
>don't feel very comfortable about that, but I suppose it's kind of like
>a table-row with keep-together=always, or a big inline-container.
>However, since users can always use those mechanisms, why should the
>spec provide another, particularly ill-defined way, of achieving the
>same effect?
>  
>

[WARNING: talking without re-reading the spec.]

I thought for a while that the expansion of a fo:inline-contained fo:block
(<fo:block>..<fo:inline>..<fo:block.../>..</fo:inline>..</fo:block>)
would invoke the overflow conditions if the content BPDim of the 
contained block exceeded a page-full. If you take that approach, of 
course, you must first create a new page when the consumed BDDir of the 
contained block-area exceeds the BPDir available on the current page, 
because that - all other things being equal - is the way the outer 
fo:block would handle an overflowing inline-area.

Thinking about that and The Five Points of 4.7.3 has induced me to 
consider the following creative interpretation.

Considering this in terms of recursive galleys - yummm! my favourite - 
the outer fo:block provides a certain BPDim (and IPDim) to the child 
fo:inline. It starts generating and returning inline-areas within the 
constraints provided. When the fo:block is encountered, the fo:inline 
passes the remaining BPDim, etc., to the fo:block. The fo:block starts 
generating line-areas within the constraints provided. When the BPDim 
constraint is encountered, the inner fo:block stops. The fo:inline wraps 
the result in an inline-area and passes it back. The outer fo:block 
wraps that in a line-area which it places as the last component of the 
block-area which fills the page.

Page alert! A new page is generated, and all of these galleys, after 
suitable area initialisation, resume where there left off, acting like 
co-routines, sort of.

I don't think that this operational interpretation is contradicted, even 
if it is not blessed, by the spec. Re your following comment, I have no 
embarassment about recursive area wrapping. I have a taste for such things.

>I do think however, that we should just settle on the approach to use
>and then go on to handling issues which are less fuzzy. Although I
>personally prefer not wrapping the block-areas in inline-areas, I tend
>to think Arved is right that the spec implies that they are to be
>wrapped.
>
>At any rate, I see Peter has asked the XSL spec editors to clarify this.
>I'm sure we already asked them when we were discussing this last year,
>but it doesn't hurt to try again.
>  
>

I thought that a pretty picture and a deceptively simple request might 
bring this one back to the top of the attention pile.

Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

[Karen Lease <kl...@club-internet.fr>]

Kerion,

Comments below with my readings of these issues.

-Karen

Keiron Liddle wrote [06 May 2002 10:21:28 +0200]:
> 
> Hi All,
> 
> What it boils down to seems to be if the inline fo returns the block
> area or generates an inline area that contains the block area. If it
> generates an inline area then it will set traits on that area (border,
> background, link, padding etc.).

Yes, I think that's the main question as well.
 
> If that is the case why is a footnote inline not allowed to have a block
> level child. Since this is effectively the same as using an
> inline-container.

I would think it's because of the usual semantics of footnote
references, meaning some text to which the "anchor" is attached. On the
other hand, the explanation (6.10.3) doesn't explicitly say the the
inline child of an fo:footnote only returns one normal inline and one
anchor, which would make it perfectly clear.

The discussion of fo:leader has a similar restriction, but it says a
leader returns a _single_ inline area. Therefore, it can't have any kind
of embedded block-level child, because it would have to return at least
two areas. Not to mention that trying to format a block as the content
of a leader doesn't make much conceptual sense.
 
> Here is another confusing statement, that makes sense for
> inline-container.
> 4.6
> "The dimensions of the content-rectangle for an inline-area without
> children is computed as specified by the generating formatting object,
> as are those of an inline-area with block-area children."
> 
> Does "computed as specified" mean specified on the fo or derived from
> the context.

I think it generally means specified on the fo, either by its intrinsic
content in the case of glyphs or graphics which have no children, or
with explicit properties on the FO, such as width or height which
override the intrinsic content size in the case of graphics. If the
inline-area has only inline-area children, it just grows to hold its
children and the total size is defined by line-breaking constraints. If
it has block-area children like inline-container, then it is stacking
them in the block-progression-dimension, and the content size can't
define the IPD, so it should be specified on the FO.

 
> >From a practical viewpoint it makes sense to wrap the block in an inline
> area with the traits and treat the block normally in layout terms but it
> still feels uncomfortable. It also introduces a whole lot of other
> questions about line height, padding etc.
> 

I believe another consequence is that the block-area embedded in the
inline can't be broken, since it would mean splitting a "line" (ie, the
line containing the inline-area which is wrapping the block-area). I
don't feel very comfortable about that, but I suppose it's kind of like
a table-row with keep-together=always, or a big inline-container.
However, since users can always use those mechanisms, why should the
spec provide another, particularly ill-defined way, of achieving the
same effect?

I do think however, that we should just settle on the approach to use
and then go on to handling issues which are less fuzzy. Although I
personally prefer not wrapping the block-areas in inline-areas, I tend
to think Arved is right that the spec implies that they are to be
wrapped.

At any rate, I see Peter has asked the XSL spec editors to clarify this.
I'm sure we already asked them when we were discussing this last year,
but it doesn't hurt to try again.


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: [REDESIGN] Line layout manager discussion

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

Comments down under...

> -----Original Message-----
> From: Keiron Liddle [mailto:keiron@aftexsw.com]
> Sent: May 7, 2002 4:40 AM
> To: fop-dev@xml.apache.org
> Subject: RE: [REDESIGN] Line layout manager discussion
>
>
> On Tue, 2002-05-07 at 03:56, Arved Sandstrom wrote:
> > > >From a practical viewpoint it makes sense to wrap the block
> in an inline
> > > area with the traits and treat the block normally in layout
> terms but it
> > > still feels uncomfortable. It also introduces a whole lot of other
> > > questions about line height, padding etc.
> > >
> > The use of "line-height" for inlines is as a synonym for
> "height"; one _can_
> > use "height" but only for replaced inline-level FOs. So for an original
> > "inline", say, we'd ignore a "height" but use "line-height"
> instead, which
> > more often than not is just going to inherit from the block
> containing it. I
> > think this is pretty straightforward.
> >
> > I don't know if this is what you were getting at, though.
> Because I figure
> > you're on top of this already.
>
> I was referring to the line-stacking-strategy. If it is font-height then
> "It has the same block-progression dimension for each line-area child of
> a block-area."
>
> This means that if we embedd the block within a line area then the line
> is still the same height as other lines. So even if the block is big
> enough to fill a page it will be placed in a line area that has the same
> height as as other lines with only text.

"font-height" has the same effect on other things also, though, where a
person may have some expectation that the element has a larger size. Like
external-graphic, for example. Which is why a note in Section 6.6.5 even
says that one normally uses "max-height" (the default) or "line-height" for
this FO.

I think this is a situation that would be cause for a runtime warning, using
some kind of heuristics - the user has imposed conditions on the FO that
really don't go well together. Something that big they should maybe think of
doing a float. But the spec itself is reasonably clear on what we can expect
from "font-height", I think.

Arved


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: [REDESIGN] Line layout manager discussion

[Keiron Liddle <ke...@aftexsw.com>]

On Tue, 2002-05-07 at 03:56, Arved Sandstrom wrote:
> > >From a practical viewpoint it makes sense to wrap the block in an inline
> > area with the traits and treat the block normally in layout terms but it
> > still feels uncomfortable. It also introduces a whole lot of other
> > questions about line height, padding etc.
> >
> The use of "line-height" for inlines is as a synonym for "height"; one _can_
> use "height" but only for replaced inline-level FOs. So for an original
> "inline", say, we'd ignore a "height" but use "line-height" instead, which
> more often than not is just going to inherit from the block containing it. I
> think this is pretty straightforward.
> 
> I don't know if this is what you were getting at, though. Because I figure
> you're on top of this already.

I was referring to the line-stacking-strategy. If it is font-height then
"It has the same block-progression dimension for each line-area child of
a block-area."

This means that if we embedd the block within a line area then the line
is still the same height as other lines. So even if the block is big
enough to fill a page it will be placed in a line area that has the same
height as as other lines with only text.


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: [REDESIGN] Line layout manager discussion

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

Interleaved commentary...

> -----Original Message-----
> From: Keiron Liddle [mailto:keiron@aftexsw.com]
> Sent: May 6, 2002 5:21 AM
> To: fop-dev@xml.apache.org
> Subject: Re: [REDESIGN] Line layout manager discussion
>
>
> Hi All,
>
> What it boils down to seems to be if the inline fo returns the block
> area or generates an inline area that contains the block area. If it
> generates an inline area then it will set traits on that area (border,
> background, link, padding etc.).

>From 4.7.3 my understanding is that any (normal) areas returned by children
of the inline formatting object always become children of normal inline
areas that the FO generates. Similarly for a block, by 4.7.2. So the inline
FO can never _return_ a normal block area.

I guess it depends on one's understanding of "return". I take this not to
include any nested areas. The normal block area comes back, sure, but as a
child of a normal inline area.

> If that is the case why is a footnote inline not allowed to have a block
> level child. Since this is effectively the same as using an
> inline-container.

Probably just the semantics of what the "inline" does for a footnote, rather
than any technical reason.

> Here is another confusing statement, that makes sense for
> inline-container.
> 4.6
> "The dimensions of the content-rectangle for an inline-area without
> children is computed as specified by the generating formatting object,
> as are those of an inline-area with block-area children."
>
> Does "computed as specified" mean specified on the fo or derived from
> the context.

I'm thinking, as specified on the FO.

> >From a practical viewpoint it makes sense to wrap the block in an inline
> area with the traits and treat the block normally in layout terms but it
> still feels uncomfortable. It also introduces a whole lot of other
> questions about line height, padding etc.
>
The use of "line-height" for inlines is as a synonym for "height"; one _can_
use "height" but only for replaced inline-level FOs. So for an original
"inline", say, we'd ignore a "height" but use "line-height" instead, which
more often than not is just going to inherit from the block containing it. I
think this is pretty straightforward.

I don't know if this is what you were getting at, though. Because I figure
you're on top of this already.

Regards,
Arved


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

[Keiron Liddle <ke...@aftexsw.com>]

Hi All,

What it boils down to seems to be if the inline fo returns the block
area or generates an inline area that contains the block area. If it
generates an inline area then it will set traits on that area (border,
background, link, padding etc.).

If that is the case why is a footnote inline not allowed to have a block
level child. Since this is effectively the same as using an
inline-container.

Here is another confusing statement, that makes sense for
inline-container.
4.6
"The dimensions of the content-rectangle for an inline-area without
children is computed as specified by the generating formatting object,
as are those of an inline-area with block-area children."

Does "computed as specified" mean specified on the fo or derived from
the context.

>From a practical viewpoint it makes sense to wrap the block in an inline
area with the traits and treat the block normally in layout terms but it
still feels uncomfortable. It also introduces a whole lot of other
questions about line height, padding etc.


Keiron.

On Mon, 2002-05-06 at 03:52, Peter B. West wrote:
> Arved,
> 
> Again, I agree that, in the conceptual area tree described in the spec, 
> blocks embedded in inline-area generating FOs in the fo tree (e.g., 
> fo:inline and fo:basic-link), themselves embedded in a parent fo:block, 
> do not bubble up to the same level as the parent fo:block.  Going back 
> to your diagram, I am talking about the fo:block embedded in the 
> basic-link.  I have attached another diagram describing a subset of your 
> original example.
> 
> Let me clarify what I meant by the term "bubble up" in the reply to Karen.
> 
> "Then what seems to me to be the *intention* that layout within 
> fo:inline and fo:basic-link proceed as though these wrappers were 
> layout-transparent, would be made clear. That is, blocks bubbling up 
> from below will be stacked in the BPDir without IPDir attachments from 
> surrounding inline-areas."
> 
> This refers to the spec's conceptual area tree.  It arises out of my 
> misapprehension that the nesting of fo:blocks within inline-area 
> generators would involve a nesting of the layout within the generated 
> inline-area.  The fo:inline inline-area in the area tree would grow 
> within the bounds of the containing line-area and block area, but 
> limited by it.
> 
> It doesn't work that way, though, as we have all discussed.  These block 
> areas "bubble-up", not in terms of their containment within the 
> appropriate set of line-area->inline-area->block-area, bu in terms of 
> their layout consequences.  Apart from any layout-altering properties 
> defined on the containing inline-area generator, e.g.font or border 
> changes, the text and any nested blocks are treated for layout as though 
> they had occurred as direct children of the outer fo:block.  That's what 
> the term "layout-transparent" means.
> 
> That, at least, is what I take the *intention* of the authors to be. 
>  And that is why I want to see some clarification of the relationship 
> between 4.7.2 Line-building and 4.7.3 Inline-building.  It seems to me 
> that the spec decrees that the initial text of the basic-link ("In 
> basic-link " in my example) is constructed into an inline-area by the 
> Inline-building process of 4.7.3.  In order to do this, it has to know 
> about the constraints that it inherits from the already partially 
> constructed line-area which contains "Text in block ".  It seems to me 
> that, conceptually at least, in the conceptual area tree model of the 
> spec, the inline-building process needs to take account of all of the 
> glyph substitution, insertion and deletion considerations that apply to 
> 4.7.2, because it is now the responsibility of the inline-area generator 
> to generate a *single* inline-area to complete the pending line-area of 
> the parent.  To do that, it will have to be able to do its own 
> line-breaking.
> 
> Clarifying this is a matter of the coherence and consistency of the 
> spec.  It is also important if you are tempted, as I am, by the idea of 
> mimicking this conceptual model and procedure in actual code.
> 
> All of the above may just mean that, while I thought I had been brought 
> around to your way of thinking on this aspect of the spec, I may still 
> be thinking about it very differently.



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

["Peter B. West" <pb...@powerup.com.au>]

Arved,

Again, I agree that, in the conceptual area tree described in the spec, 
blocks embedded in inline-area generating FOs in the fo tree (e.g., 
fo:inline and fo:basic-link), themselves embedded in a parent fo:block, 
do not bubble up to the same level as the parent fo:block.  Going back 
to your diagram, I am talking about the fo:block embedded in the 
basic-link.  I have attached another diagram describing a subset of your 
original example.

Let me clarify what I meant by the term "bubble up" in the reply to Karen.

"Then what seems to me to be the *intention* that layout within 
fo:inline and fo:basic-link proceed as though these wrappers were 
layout-transparent, would be made clear. That is, blocks bubbling up 
from below will be stacked in the BPDir without IPDir attachments from 
surrounding inline-areas."

This refers to the spec's conceptual area tree.  It arises out of my 
misapprehension that the nesting of fo:blocks within inline-area 
generators would involve a nesting of the layout within the generated 
inline-area.  The fo:inline inline-area in the area tree would grow 
within the bounds of the containing line-area and block area, but 
limited by it.

It doesn't work that way, though, as we have all discussed.  These block 
areas "bubble-up", not in terms of their containment within the 
appropriate set of line-area->inline-area->block-area, bu in terms of 
their layout consequences.  Apart from any layout-altering properties 
defined on the containing inline-area generator, e.g.font or border 
changes, the text and any nested blocks are treated for layout as though 
they had occurred as direct children of the outer fo:block.  That's what 
the term "layout-transparent" means.

That, at least, is what I take the *intention* of the authors to be. 
 And that is why I want to see some clarification of the relationship 
between 4.7.2 Line-building and 4.7.3 Inline-building.  It seems to me 
that the spec decrees that the initial text of the basic-link ("In 
basic-link " in my example) is constructed into an inline-area by the 
Inline-building process of 4.7.3.  In order to do this, it has to know 
about the constraints that it inherits from the already partially 
constructed line-area which contains "Text in block ".  It seems to me 
that, conceptually at least, in the conceptual area tree model of the 
spec, the inline-building process needs to take account of all of the 
glyph substitution, insertion and deletion considerations that apply to 
4.7.2, because it is now the responsibility of the inline-area generator 
to generate a *single* inline-area to complete the pending line-area of 
the parent.  To do that, it will have to be able to do its own 
line-breaking.

Clarifying this is a matter of the coherence and consistency of the 
spec.  It is also important if you are tempted, as I am, by the idea of 
mimicking this conceptual model and procedure in actual code.

All of the above may just mean that, while I thought I had been brought 
around to your way of thinking on this aspect of the spec, I may still 
be thinking about it very differently.

Peter

Arved Sandstrom wrote:

>My last post was motivated by one thing - the statement that a block area
>"bubbles up". Well, it does not, not in the conceptual area tree described
>in the XSL spec. As a result I thought it worth our time to ask for some
>specificity when the area tree being referred to is not immediately obvious.
>
>I agree with your sentiments, particularly the last sentence. As such I
>think it is very important to establish exactly what area tree we are
>talking about in any given context. In theory there are at least 2 - the XSL
>1.0 conceptual area tree, and the real "tree" (really, whatever structure we
>happen to use). There could be more.
>
>  
>

RE: [REDESIGN] Line layout manager discussion

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

> -----Original Message-----
> From: Peter B. West [mailto:pbwest@powerup.com.au]
> Sent: May 5, 2002 12:55 AM
> To: fop-dev@xml.apache.org
> Subject: Re: [REDESIGN] Line layout manager discussion
>
>
> Arved,
>
> I agree that there is no need to tie the rendering to any particular
> model, as long as the results are equivalent.  The discussions that span
> this list and the Xslfo-proc-devel list testify that there are many
> approaches to process of layout.  However, if I am reading this
> correctly, the proposal is to clarify the text of the spec.  In that
> context, the treatment of the area tree and its relationship to the fo
> tree must be coherent and consistent, or we will be in even deeper
> difficulties.
>
> Peter

My last post was motivated by one thing - the statement that a block area
"bubbles up". Well, it does not, not in the conceptual area tree described
in the XSL spec. As a result I thought it worth our time to ask for some
specificity when the area tree being referred to is not immediately obvious.

I agree with your sentiments, particularly the last sentence. As such I
think it is very important to establish exactly what area tree we are
talking about in any given context. In theory there are at least 2 - the XSL
1.0 conceptual area tree, and the real "tree" (really, whatever structure we
happen to use). There could be more.

Regards,
Arved


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

["Peter B. West" <pb...@powerup.com.au>]

Arved,

I agree that there is no need to tie the rendering to any particular 
model, as long as the results are equivalent.  The discussions that span 
this list and the Xslfo-proc-devel list testify that there are many 
approaches to process of layout.  However, if I am reading this 
correctly, the proposal is to clarify the text of the spec.  In that 
context, the treatment of the area tree and its relationship to the fo 
tree must be coherent and consistent, or we will be in even deeper 
difficulties.

Peter

Arved Sandstrom wrote:

>> From what I see here you are changing the shape of the tree.  The
>>motivation seems to be to make it explicit that block areas contained
>>within an inline area must bubble up to become direct children of the
>>containing block area.  I can't see that that is feasible, given the
>>basic design principle of the spec that the area tree follows the fo
>>tree.
>>
>[ SNIP ]
>
>With respect to the second sentence of the above, I think we should be very
>clear at all times about exactly which area tree we are talking about - the
>conceptual area tree as described in the spec, or the real one constructed
>by Fop.
>



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

AW: [REDESIGN] Line layout manager discussion

["J.U. Anderegg" <ha...@bluewin.ch>]

By writing renderer code with FOP 0.20.1 I observed :

A basic link

<fo:basic-link internal-destination="dest0">link wordst</fo:basic-link>

arrives 3 times in the PDFrenderer asynchronously, without any connection
between each other.

1. as word "link"
2. as word "words"
3. as annotation rectangle

This is OK with PDF. But there is an assumption on the operation of the
output device. Other document formats: link rendering needs access to all
related data. How about FOP extensions, new versions of xsl:fo? Deep area
tree, linear sequential representation, semantics - I cannot tell. It has to
be device independent.


Fetching info randomly from the area tree?

Some document formats need a list of fonts used at the beginning of the
document or each page. Can the renderer retrieve this info from the the area
tree in advance?  Elimination of intermediate storage makes renderer
programming straight forward.

Hansuli Anderegg



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: [REDESIGN] Line layout manager discussion

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

Comments below.

> -----Original Message-----
> From: Peter B. West [mailto:pbwest@powerup.com.au]
> Sent: May 3, 2002 10:42 PM
> To: fop-dev@xml.apache.org
> Subject: Re: [REDESIGN] Line layout manager discussion
>
[ SNIP ]
>  From what I see here you are changing the shape of the tree.  The
> motivation seems to be to make it explicit that block areas contained
> within an inline area must bubble up to become direct children of the
> containing block area.  I can't see that that is feasible, given the
> basic design principle of the spec that the area tree follows the fo
> tree.  Specifically, by doing that, you lose what Karen called, iirc,
> the semantic markers of the enclosing inline-area, e.g., fo:inline or
> fo:basic-link.  So how does that semantic information get to the
> once-but-no-longer enclosed fo:block?  It is possible to arrange the
> transfer of such information to the block-area in the area tree, but
> then the inheritance becomes a purely algorithmic thing, and the
> structural link between the fo tree and the area tree is broken.

[ SNIP ]

With respect to the second sentence of the above, I think we should be very
clear at all times about exactly which area tree we are talking about - the
conceptual area tree as described in the spec, or the real one constructed
by Fop. Because in the conceptual tree block areas have a well-defined
location and there is no "bubbling up" at all. Whereas in the real "tree" we
can flatten completely and not have a tree at all, so we could have maximal
"bubbling".

As far as semantic information, are we talking about during layout or once
the area is passed off for rendering? Because it seems to me that if we have
managers then they can take care of retaining the semantic information (e.g.
all areas generated or returned in this manager belong within a link). Once
the areas are passed off to the renderer practically all the information
needed to properly render any area can be expressed as traits on that area -
one main exception is that areas need to know their nearest ancestor
reference area for positioning.

I am not discounting an area tree per se - with my xslfo-proc project I find
an area structure (partial in my SAX implementation) to be the most
convenient way of recording current layout information. That is, manager X
needs to store certain information and it may as well use Area objects to do
it. But I lean strongly towards a viewpoint where the areas have no
knowledge of original semantics.

Regards,
Arved


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

["Peter B. West" <pb...@powerup.com.au>]

Keiron et al.,

Just a quick reaction to this - I'm off to sit next to the footpath 
reading the newspapers and drinking tea.

 From what I see here you are changing the shape of the tree.  The 
motivation seems to be to make it explicit that block areas contained 
within an inline area must bubble up to become direct children of the 
containing block area.  I can't see that that is feasible, given the 
basic design principle of the spec that the area tree follows the fo 
tree.  Specifically, by doing that, you lose what Karen called, iirc, 
the semantic markers of the enclosing inline-area, e.g., fo:inline or 
fo:basic-link.  So how does that semantic information get to the 
once-but-no-longer enclosed fo:block?  It is possible to arrange the 
transfer of such information to the block-area in the area tree, but 
then the inheritance becomes a purely algorithmic thing, and the 
structural link between the fo tree and the area tree is broken.

It seems to me that one reason for the murkiness in this area of the 
spec is that the authors are at pains to preserve this structural 
relationship, while at the same time ensuring that the actual layout is 
determined in the way you propose.  I think that it's possible to do 
this by clarifying the particular issues about line-building and 
inline-building in this context.

The bottom line is that I think we have to clarify the text so that it 
comprehensibly expresses the situation laid out in Arved's original 
diagram of the handling of the fo:block within an fo:basic-link within 
the text of an fo:block.

Peter



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

[Keiron Liddle <ke...@aftexsw.com>]

Hi devs,

I have attached a picture of how I think this process should work (in
principle not necessarily with actual areas or code).

The spec should say something like:

4.7.2
A block level formatting object which contains inline level formatting
objects that will create inline areas will create lines.
Any block level areas that are return by child formatting objects will
be placed as direct children of this block area.
Any inline level areas which area return by child formatting objects
will be placed into line areas.
Consecutive inline areas will be placed into line areas.

The sequence of child areas returned to this block area will be handled
so that a sequence of inline areas will be placed into a sequence of
line areas and block areas will be placed in the correct order.

(part 5. point 1 then says that any child fo that returns a block area
means that the block area is a direct child of the current block area)

4.7.3
An inline level formatting object creates and returns inline areas and
returns any block areas. Each line area can contain only one inline area
created by the inline level formatting object. This inline area is
created by adding child inline areas that are allowed in the parent line
area (it is not required to fit, eg. no wrap). 


6.6.7 (and other inline fo's)
Areas:
The fo:inline returns these areas, any block areas, any
page-level-out-of-line ...


----------------

So does that make more sense?
I think some of the confusion is that a block area can create multiple
block areas but this only occurs at page/column breaks.

Regards,
Keiron.

Re: [REDESIGN] Line layout manager discussion

[Karen Lease <kl...@club-internet.fr>]

Arved,

I'm definitely in favor of deciding how we think things are supposed to
be laid out. Of course it would be nice if we were on the same
wavelength with the majority of FO users and implementors... but I'm not
too worried about that.

Besides the stuff we're talking about currently, we need to agree on
line-stacking issues (Keiron's already worked on vertical alignment, so
he's probably up on that) and space specifier handling (but there I
think the spec is fairly clear once one has read it 50 times or so :-).

Arved Sandstrom wrote:

> Good...if we all agree with that then I think it is the main point gotten
> out of the way, because every other situation has to do with child FOs all
> being inline or block-level, for which the results are less dubious.
.....
> The main thing is, let's make sure that we have agreement (codified through
> use of these diagrammed examples) on all matters that affect placement. I
> understand that we want to have a warm fuzzy about our understanding of the
> spec, but that's not going to happen with everything.
> 
> To be precise, if I can get a number of these examples created, what we can
> do is identify situations where we can say, this one is 100% solid (we know
> this is right, there is no uncertainty in the spec), this one is iffy (there
> may be small inconsistencies between our placement and what the spec authors
> intended), or this one is problematic (contradictions, for example).
> 
> Once we have classified the examples, we can do damage control on the
> uncertain ones. Namely, let's do it this way, but let's be aware that things
> could be interpreted another way, and if so, how heavily committed are we in
> our code?
> 
> On a related matter when it comes right down to brass tacks I am really only
> concerned about placement (accuracy of rendering). Both with Fop and with my
> other project I find it easier to use the conceptual areas, and I get the
> sense that others also feel this way, but let's face it, as long as our
> final result is consistent it doesn't really matter if our internal
> structures deviate.
> 
In general yes. So long as the extra levels of area "wrappers" we might
or might not add in any given situation don't bring along border,
padding, space-* etc.

-Karen



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: [REDESIGN] Line layout manager discussion

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

Comments inline...actually, no, they're not, they are really block-stacking,
but you get the drift. :-)

> -----Original Message-----
> From: karen@club-internet.fr [mailto:karen@club-internet.fr]On Behalf Of
> Karen Lease
> Sent: May 2, 2002 7:21 PM
> To: fop-dev@xml.apache.org
> Subject: Re: [REDESIGN] Line layout manager discussion
>
> Arved, Keiron et. al.
>
> I guess logically it's true that the blocks nested in inlines should be
> wrapped in inline areas, but it makes me nervous :-)
> At least they cause line breaks, that much seems sure.

Good...if we all agree with that then I think it is the main point gotten
out of the way, because every other situation has to do with child FOs all
being inline or block-level, for which the results are less dubious.

> I still think
> that we should put pressure on the spec editors to either get rid of
> structure or clarify it in the next version (ha, ha). If people need
> blocks in inlines, they have inline-container.
>
> In fact, I'd like to think that the possibility of including block-level
> FOs in inline-level FOs is purely for convenience or "semantic nesting"
> and should not really affect the area tree, except to cause line breaks
> before and after the block areas.
>
> The most legitimate use I can see for this kind of semantic nesting is
> basic-link, because it could spread the link semantics over several
> areas; kind of a link-wrapper.

The main thing is, let's make sure that we have agreement (codified through
use of these diagrammed examples) on all matters that affect placement. I
understand that we want to have a warm fuzzy about our understanding of the
spec, but that's not going to happen with everything.

To be precise, if I can get a number of these examples created, what we can
do is identify situations where we can say, this one is 100% solid (we know
this is right, there is no uncertainty in the spec), this one is iffy (there
may be small inconsistencies between our placement and what the spec authors
intended), or this one is problematic (contradictions, for example).

Once we have classified the examples, we can do damage control on the
uncertain ones. Namely, let's do it this way, but let's be aware that things
could be interpreted another way, and if so, how heavily committed are we in
our code?

On a related matter when it comes right down to brass tacks I am really only
concerned about placement (accuracy of rendering). Both with Fop and with my
other project I find it easier to use the conceptual areas, and I get the
sense that others also feel this way, but let's face it, as long as our
final result is consistent it doesn't really matter if our internal
structures deviate.

> -------------
>
> For the record, I disagree with Arved's reading of Line-Building. I read
> 4.7.2, point 5 as saying that a block area generated by an fo:block can
> contain a mixture of block areas and line areas.

On this particular point I think we are fortunate insofar as it is not going
to affect placement.

> Also, if we look at 4.7.3 (inline-building), I find it curious that it
> starts by saying TWICE that an inline FO places inline areas and anchor
> inline areas returned by its child FOs in inline areas which it
> generates, and then suddenly throws a block-area into the condition
> described in point 1. Looks more like a hasty copy/paste from the list
> for Line-building!
>
> As Keiron says, if the spec writers had been clearer, we wouldn't have
> to spend hours chasing our tails like this!

I find the transitions from relatively formal set-oriented treatments to
casual prose disconcerting. As soon as I see formal then my Pedant-O-Meter
cranks way up, and I find it hard to switch off. :-)

> Regards,
> Karen
>
> Arved Sandstrom wrote:
> >
> [SNIP]
> >
> > _If_ there were blocks nested inside the top-level block these
> would produce
> > normal block areas that are single children of normal block
> areas produced
> > by the top-level block. My reading of Line-Building is that normal block
> > areas generated by a fo:block have either _single_ block areas
> _or_ one or
> > more line areas as children, not a mixture.
> >
> > Final comment: it is the close intermingling of inlines and
> blocks in this
> > example that causes so much line breaking. Clearly each of the 2 nested
> > blocks could be wrapped in inlines (fo:inline or whatever), and
> as a result
> > everything in the example, in theory, could be in _one_ line area.
> >
> > Anyhow, please critique away. :-)
> >
> > Regards,
> > Arved


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

[Karen Lease <kl...@club-internet.fr>]

Arved, Keiron et. al.

I guess logically it's true that the blocks nested in inlines should be
wrapped in inline areas, but it makes me nervous :-)
At least they cause line breaks, that much seems sure. I still think
that we should put pressure on the spec editors to either get rid of
structure or clarify it in the next version (ha, ha). If people need
blocks in inlines, they have inline-container.

In fact, I'd like to think that the possibility of including block-level
FOs in inline-level FOs is purely for convenience or "semantic nesting"
and should not really affect the area tree, except to cause line breaks
before and after the block areas.

The most legitimate use I can see for this kind of semantic nesting is
basic-link, because it could spread the link semantics over several
areas; kind of a link-wrapper.

-------------

For the record, I disagree with Arved's reading of Line-Building. I read
4.7.2, point 5 as saying that a block area generated by an fo:block can
contain a mixture of block areas and line areas.

Also, if we look at 4.7.3 (inline-building), I find it curious that it
starts by saying TWICE that an inline FO places inline areas and anchor
inline areas returned by its child FOs in inline areas which it
generates, and then suddenly throws a block-area into the condition
described in point 1. Looks more like a hasty copy/paste from the list
for Line-building!

As Keiron says, if the spec writers had been clearer, we wouldn't have
to spend hours chasing our tails like this!

Regards,
Karen

Arved Sandstrom wrote:
> 
[SNIP]
> 
> _If_ there were blocks nested inside the top-level block these would produce
> normal block areas that are single children of normal block areas produced
> by the top-level block. My reading of Line-Building is that normal block
> areas generated by a fo:block have either _single_ block areas _or_ one or
> more line areas as children, not a mixture.
> 
> Final comment: it is the close intermingling of inlines and blocks in this
> example that causes so much line breaking. Clearly each of the 2 nested
> blocks could be wrapped in inlines (fo:inline or whatever), and as a result
> everything in the example, in theory, could be in _one_ line area.
> 
> Anyhow, please critique away. :-)
> 
> Regards,
> Arved
> 
>   ------------------------------------------------------------------------
>                         Name: complex_block.png
>    complex_block.png    Type: PNG Image (image/png)
>                     Encoding: base64
> 
>   ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

["Peter B. West" <pb...@powerup.com.au>]

Keiron,

Keiron Liddle wrote:

> I'm almost thinking of going a step further.
> Maybe we could add annotations to the spec to clarify these things 
> with our understanding and then present this information. 

Yes indeed.  And an index, including especially a concept index.

>
> It seems to me that the spec writers are not as involved as they 
> should be. 


Peter



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

[Keiron Liddle <ke...@aftexsw.com>]

On 2002.05.03 04:56 Peter B. West wrote:
> What would be even more generally useful would be to get the spec 
> editors to put up a site, possibly with disclaimers plastered all over 
> it, to which they post FAQs on the spec. They must get a lot of 
> repeating questions from the various parties who are trying to 
> implement. I'm not subscribed to the xsl-editors mailing list (which I 
> suppose I should be.) Is anyone else subscribed? If so, have requests 
> like this been made before?

I'm not subrscibed either.
Looking at the archives it seems most discussions are about xslt.

I'm almost thinking of going a step further.
Maybe we could add annotations to the spec to clarify these things with 
our understanding and then present this information.
It seems to me that the spec writers are not as involved as they should be.

I just ran the spec through FOP. It seems to work okay (along with a 
number of unimplemented features and large memory usage).


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

["Peter B. West" <pb...@powerup.com.au>]

Arved,

This is a good idea. I half-heartedly suggested as much to Matthew 
Huggett when he asked what a non-programming technical writer might 
contribute. It requires too deep an insight into the spec, but he (or 
Cyril) may of some assistance to you.

What would be even more generally useful would be to get the spec 
editors to put up a site, possibly with disclaimers plastered all over 
it, to which they post FAQs on the spec. They must get a lot of 
repeating questions from the various parties who are trying to 
implement. I'm not subscribed to the xsl-editors mailing list (which I 
suppose I should be.) Is anyone else subscribed? If so, have requests 
like this been made before?

Peter

Arved Sandstrom wrote:

>Hi, Keiron
>
>I think what I should do is establish a section on the website with all the
>other design notes that is a central location for these kinds of studies.
>This could be the first one. I can undertake to start churning these out on
>a fairly regular basis - I think we need them.
>
>Once they are in CVS then it would be easier for others to annotate them,
>modify them, and what have you. We'll have to settle on a mutually agreeable
>figure format so as not to unduly restrict access.
>
>As far as the spec goes, absolutely, I agree. That's why I think that these
>diagrams help so much - in order to draw them you must work your way through
>the spec in detail. The process also exposes any gotchas before too much
>code has been written based on different assumptions.
>
>I'll proceed on the above basis and set up a place for these
>diagrams/studies, and crank out some more. I am somewhat reluctant to do any
>coding at the moment until such a time (hopefully not far away) where I am
>satisfied that I understand the new design well.
>
>Arved
>
>  
>
>>-----Original Message-----
>>From: Keiron Liddle [mailto:keiron@aftexsw.com]
>>Sent: May 2, 2002 6:18 AM
>>To: fop-dev@xml.apache.org
>>Subject: Re: [REDESIGN] Line layout manager discussion
>>
>>I agree with you (except for the last statment about one line).
>>
>>I found this statement interesting:
>>6.6.7. fo:inline
>>
>>"An fo:inline that is a child of an fo:footnote may not have block-level
>>children. An fo:inline that is a
>>descendant of an fo:leader or of the fo:inline child of an
>>fo:footnote may
>>not have block-level children,
>>unless it has a nearer ancestor that is an fo:inline-container."
>>
>>It suggests that what you are saying is correct and that block-level
>>elements create a block area outside the immediate line area. So
>>to have a
>>block area inside a line area you must use the inline-container, a block
>>is never automatically embedded.
>>
>>
>>Also in this section, reading between the lines (it's amazing how they
>>manage to contradict themselves in such a short section)
>>
>>4.7.3. Inline-building
>>
>>An inline fo element with a block element as a child will create inline
>>areas and return the block area.
>>It will create a single inline area that can fit consecutive child inline
>>areas on a single line. So the child inline areas are put into parent
>>inline areas that are separated by line breaks and block areas.
>>
>>So Karen's approach is looking better.
>>
>>I really wish this spec would say relevant things in the right places and
>>mention how everything is handled rather than being so vague.
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
>For additional commands, email: fop-dev-help@xml.apache.org
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

RE: [REDESIGN] Line layout manager discussion

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

Hi, Keiron

I think what I should do is establish a section on the website with all the
other design notes that is a central location for these kinds of studies.
This could be the first one. I can undertake to start churning these out on
a fairly regular basis - I think we need them.

Once they are in CVS then it would be easier for others to annotate them,
modify them, and what have you. We'll have to settle on a mutually agreeable
figure format so as not to unduly restrict access.

As far as the spec goes, absolutely, I agree. That's why I think that these
diagrams help so much - in order to draw them you must work your way through
the spec in detail. The process also exposes any gotchas before too much
code has been written based on different assumptions.

I'll proceed on the above basis and set up a place for these
diagrams/studies, and crank out some more. I am somewhat reluctant to do any
coding at the moment until such a time (hopefully not far away) where I am
satisfied that I understand the new design well.

Arved

> -----Original Message-----
> From: Keiron Liddle [mailto:keiron@aftexsw.com]
> Sent: May 2, 2002 6:18 AM
> To: fop-dev@xml.apache.org
> Subject: Re: [REDESIGN] Line layout manager discussion
>
> I agree with you (except for the last statment about one line).
>
> I found this statement interesting:
> 6.6.7. fo:inline
>
> "An fo:inline that is a child of an fo:footnote may not have block-level
> children. An fo:inline that is a
> descendant of an fo:leader or of the fo:inline child of an
> fo:footnote may
> not have block-level children,
> unless it has a nearer ancestor that is an fo:inline-container."
>
> It suggests that what you are saying is correct and that block-level
> elements create a block area outside the immediate line area. So
> to have a
> block area inside a line area you must use the inline-container, a block
> is never automatically embedded.
>
>
> Also in this section, reading between the lines (it's amazing how they
> manage to contradict themselves in such a short section)
>
> 4.7.3. Inline-building
>
> An inline fo element with a block element as a child will create inline
> areas and return the block area.
> It will create a single inline area that can fit consecutive child inline
> areas on a single line. So the child inline areas are put into parent
> inline areas that are separated by line breaks and block areas.
>
> So Karen's approach is looking better.
>
> I really wish this spec would say relevant things in the right places and
> mention how everything is handled rather than being so vague.


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: [REDESIGN] Line layout manager discussion

[Keiron Liddle <ke...@aftexsw.com>]

I agree with you (except for the last statment about one line).

I found this statement interesting:
6.6.7. fo:inline

"An fo:inline that is a child of an fo:footnote may not have block-level 
children. An fo:inline that is a
descendant of an fo:leader or of the fo:inline child of an fo:footnote may 
not have block-level children,
unless it has a nearer ancestor that is an fo:inline-container."

It suggests that what you are saying is correct and that block-level 
elements create a block area outside the immediate line area. So to have a 
block area inside a line area you must use the inline-container, a block 
is never automatically embedded.


Also in this section, reading between the lines (it's amazing how they 
manage to contradict themselves in such a short section)

4.7.3. Inline-building

An inline fo element with a block element as a child will create inline 
areas and return the block area.
It will create a single inline area that can fit consecutive child inline 
areas on a single line. So the child inline areas are put into parent 
inline areas that are separated by line breaks and block areas.

So Karen's approach is looking better.

I really wish this spec would say relevant things in the right places and 
mention how everything is handled rather than being so vague.


On 2002.05.01 04:00 Arved Sandstrom wrote:
> Discussion follows below.
> 
> > -----Original Message-----
> > From: karen@club-internet.fr [mailto:karen@club-internet.fr]On Behalf
> Of
> > Karen Lease
> > Sent: April 29, 2002 5:39 PM
> > To: fop-dev@xml.apache.org
> > Subject: [REDESIGN] Line layout manager discussion
> >
> > Keiron Liddle wrote:
> > > So why flatten the inline layout managers?
> > > If we have an example like this:
> > >
> > > <block>Some text <basic-link>a paragraph of text<block>with a
> > > block</block>and more text</basic-link> and <inline
> > background="blue">blue
> > > background<inline color="green"> green text <block>a block</block>
> more
> > > green</inline></inline></block>
> > >
> > > The basic link produces/returns both inline areas and a block
> > area, so it
> > > is not possible to say that the basic-link element or its layout
> manager
> > > would produce inline areas. So how should this be handled. If it is
> > > flattened things are easier. The layout manager can then keep range
> > > information like: starts link, ends link.
> 
> I think this FO snippet is sufficiently complex as to be a good
> Gedankenexperiment. I prepared a PNG which illustrates the area tree as
> _I_
> interpret the spec applying to this FO.
> 
> You'll have to view the image in colour. I have taken liberties with WS,
> border colours, spaces, padding etc etc. I threw in one page break to
> make
> things interesting. Also, I have shown runs of texts as combined inlines,
> where we know in fact that they are really containers for a bunch of
> glyph
> areas.
> 
> Here's some of the main principles I am keeping in mind:
> 
> 1. An area must have its child areas all of the same type (inline or
> block);
> 2. No area may have more than one normal block area returned by the same
> fo:block;
> 3. No area may have more than one normal inline area returned by the same
> inline (fo:inline, fo:basic-link);
> 4. A block generates normal block areas. If a child FO returns a block
> area
> this becomes a direct child of one of those block areas. If a child
> returns
> a sequence of inline areas, these become children of line areas which are
> in
> turn children of a normal block area;
> 5. An inline generates normal inline areas. Each such may contain a
> sequence
> of inline areas or a single block area.
> 
> Absolutely nobody else is going to agree 100% with my interpretation, but
> I
> think if we can hash this out it will allow us to really move forward
> with
> confidence.
> 
> a) There are no block-level children of the top block, only inlines, so
> we
> know that the one or more block areas generated by the top-level block
> are
> going to contain line areas. Because of the page break there are 2 normal
> block areas generated by the top-level block;
> 
> b) "some text" is simple - the inline goes neatly into the first line
> area
> as its first child;
> 
> c) Now we hit the basic link. This generates one or more normal inlines,
> which are outlined in orange. The "a paragraph of text" is the first
> inline
> child of the first normal inline area generated by the basic-link;
> 
> d) we hit the nested block. OK, this is where the anguish starts. :-) It
> produces at least one normal block area, by definition. I have given this
> a
> pale green background. This _cannot_ occupy the first normal inline area
> generated by the basic-link, because that already contains an inline area
> (rule 1). So it must be in a second normal inline area generated by the
> basic-link. By rule 3, the first line area may not contain 2 areas
> generated
> by the same inline, so that's why we terminate line aea 1 and start
> another;
> 
> e) In the second line area (outlined in dark blue), we have the second
> normal inline area generated by the basic-link, outlined in orange. This
> contains a single block area generated by the nested block (rule 5). In
> order for the block area to handle the contained text ("with a block") it
> must itself have a line area with inline children (one or more - I've
> shown
> one);
> 
> f) we encounter "and more text". The same argument applies as in 'd' -
> the
> second inline area generated by the basic link cannot accept the inline
> area
> this text results in because it already contains a block area. So, a
> third
> inline area gets generated by the basic link, and by rule 3, this results
> yet again in another line area;
> 
> g) the third line area, now graced by the presence of the last normal
> inline
> generated by the basic-link (and its children), is able to handle more
> line
> areas, and so "and" and ""blue background" and "green text" certainly are
> allowed. I chose to insert a line break after the "green". I hope the
> colours help distinguish what is what - the inline child of the top-level
> block ends up creating 4 normal inline area which have blue backgrounds;
> 
> h) the doubly-nested inline produces inline areas that in fact have a
> transparent background and so everything should be blue, but I thought
> this
> would lack clarity. The normal inline areas produced by the doubly-nested
> inline have a thicker brown border. The same argument applies to the
> block
> which is nested in _this_ inline; the combination of rules 1 and 3
> require
> different line areas. Again, the normal block area generated by the
> doubly-nested block has a pale green background;
> 
> _If_ there were blocks nested inside the top-level block these would
> produce
> normal block areas that are single children of normal block areas
> produced
> by the top-level block. My reading of Line-Building is that normal block
> areas generated by a fo:block have either _single_ block areas _or_ one
> or
> more line areas as children, not a mixture.
> 
> Final comment: it is the close intermingling of inlines and blocks in
> this
> example that causes so much line breaking. Clearly each of the 2 nested
> blocks could be wrapped in inlines (fo:inline or whatever), and as a
> result
> everything in the example, in theory, could be in _one_ line area.
> 
> Anyhow, please critique away. :-)
> 
> Regards,
> Arved

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org