Questions to XSL WG about Inlines etc.

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

Howdy,

Karen, this is mostly to you, but doubtless everyone will want to contribute.

Unless I had a bad day it seems to me that portions of the spec that pertain to
what areas are contained by others are ambiguous or conflicting.

What I suggest is that we prepare a submission that contains a number of FO
examples, point out our resulting best-guess area tree, and then indicate why
we think it's right (common-sense and some portions of the spec) and what parts
of the spec conflict with this interpretation.

For my part, I'd like to hear how

<fo:block>
Some normal text followed by <fo:inline font-weight="bold"
>heavy stuff</fo:inline>
</fo:block>

is OK when this calls for mixing LineAreas and InlineAreas, and no area can
have different types of child areas.

Regards,
Arved

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

Re: Questions to XSL WG about Inlines etc.

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

 From my reading of the spec it seems we are mixing up formatting 
objects and areas.

in 4.7.3 it says that an inline area can be created with a sequence of 
inline areas or a single block area.
in 4.7.2 it says a line area can be created with a sequence of inline 
areas or a single block area

So it seems that if we want to place a block area inline then it should 
be placed inside its own fo:inline
(not automatically) thereby creating a sequence of inline areas for the 
line area. This block area is placed as any other inline area inside the 
line.
Well thats my thoughts.

On a related note I think we should look at a way that formatting 
objects should return all the appropriate areas generated (or returned 
by children). eg. an inline area returns the page-level-out-of-line 
areas, and any reference-level-out-of-line areas from its children.

And does anyone know what concatenating an area means eg. for table 
cells rows. The table body returns a sequence of areas by concatenating 
its child areas and a row also returns a sequence of areas by 
concatenating its child areas. So if all we do is concatenate areas what 
defines their placement, direction etc. The result of this concatenation 
is placed in a block area (representing the table), it says that it is 
free to specify other methods of positioning child areas for tables. 
Shouldn't a row create its own block area otherwise there is nothing to 
distinguish rows from cells.

Arved Sandstrom wrote:

> Howdy,
> 
> Karen, this is mostly to you, but doubtless everyone will want to contribute.
> 
> Unless I had a bad day it seems to me that portions of the spec that pertain to
> what areas are contained by others are ambiguous or conflicting.
> 
> What I suggest is that we prepare a submission that contains a number of FO
> examples, point out our resulting best-guess area tree, and then indicate why
> we think it's right (common-sense and some portions of the spec) and what parts
> of the spec conflict with this interpretation.
> 
> For my part, I'd like to hear how
> 
> <fo:block>
> Some normal text followed by <fo:inline font-weight="bold"
> 
>> heavy stuff</fo:inline>
> 
> </fo:block>
> 
> is OK when this calls for mixing LineAreas and InlineAreas, and no area can
> have different types of child areas.
> 



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

Re: Questions to XSL WG about Inlines etc.

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

Arved,

I have been struggling to read section 4 of the spec as part of my FO
education.  I'm pleased to see that I'm not the only one struggling.

It seems to me that the constraint on a single type of children for a
given area "as determined by the generating formatting object" is
determined by the stacking constraints, which are literally at cross
purposes for block and for inline-areas.

If a given area can only have child areas of a single type, and at the
outermost level (whatever that is) the area is a block, how can inline
areas ever be generated?  Aren't they, by and large, generated as
children of a line-area block?

4.7.2 (Line-building) says (2nd para):
A block-level formatting object F which constructs lines does so by
constructing block-areas which it returns to its parent formatting
object, and placing normal areas and/or anchor areas returned to F by
its child formatting objects as children of those block-areas or of
line-areas which it constructs as children of those block-areas.

In discussing the areas returned to a block formatting object (such as
your example block) by its child formatting objects, 4.7.2 seems to
define a correspondence between the "ordered subsets S1, S2, ..., Sn of
the normal areas and anchor areas returned by the child formatting
objects" and the set "B1, B2, ..., Bp" of "normal child areas of the
area or areas returned by F" (where F is the formatting object under
discussion).  Note that S is a subset, and B is an area.  The subsets
come from the child FO(s), the B areas are returned to the parent.

When the subset is a block-area, it is identical to the area returned to
the parent.  That is, there is no transformation by the FO under
consideration.

When the subset is a sequence of inline areas, it corresponds to the
line-area B returned to the parent; i.e., the FO converts the subset S
of inline-areas into a line-area block B.

The block you have below constructs lines; so it must construct block
areas which it returns to its parent FO.  Into those block areas it
places, as children, those areas which it receives, or it constructs as
necessary line areas to contain, as children, the areas it receives. 

In your example, an fo:block contains a number of (implicit)
fo:character nodes and an fo:inline, itself containing a sequence of
fo:character nodes.  In terms of section 4.7.2, the child formatting
objects of the fo:block are a sequence of inline areas containing
individual glyphs, and an inline area containing the results of
recursively formatting the fo:inline FO.  This set of inline areas
returned to the fo:block is partitioned into subsets, where each subset
corresponds to one line-area returned to the parent of the fo:block FO.

Is this a reasonable understanding?

In any case, Section 3, Introduction to Formatting, contains:
[4 Area Model] will describe the area tree and define the default
placement-constraints on stacked areas. However, this is an abstract
model which need not be actually implemented in this way in a formatter,
so long as the resulting tangible form obeys the implied constraints.

Peter


Arved Sandstrom wrote:
> 
> Howdy,
> 
> Karen, this is mostly to you, but doubtless everyone will want to contribute.
> 
> Unless I had a bad day it seems to me that portions of the spec that pertain to
> what areas are contained by others are ambiguous or conflicting.
> 
> What I suggest is that we prepare a submission that contains a number of FO
> examples, point out our resulting best-guess area tree, and then indicate why
> we think it's right (common-sense and some portions of the spec) and what parts
> of the spec conflict with this interpretation.
> 
> For my part, I'd like to hear how
> 
> <fo:block>
> Some normal text followed by <fo:inline font-weight="bold"
> >heavy stuff</fo:inline>
> </fo:block>
> 
> is OK when this calls for mixing LineAreas and InlineAreas, and no area can
> have different types of child areas.

-- 
Peter B. West  pbwest@powerup.com.au  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

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

Re: Questions to XSL WG about Inlines etc. [2]

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

At 10:38 PM 1/14/01 -0400, I wrote:
>For my part, I'd like to hear how
>
><fo:block>
>Some normal text followed by <fo:inline font-weight="bold"
>>heavy stuff</fo:inline>
></fo:block>
>
>is OK when this calls for mixing LineAreas and InlineAreas, and no area can
>have different types of child areas.

After a good night's sleep I see that at least here we are in fact OK. I 
missed the forest for the trees, the trees being LineAreas. :-)

This made me think of a way out, at least logically. We expect (by 
common-sense, by habit) that

<fo:block>
Some normal text followed by <fo:inline font-weight="bold"
>heavy stuff</fo:inline>
</fo:block>

results in a paragraph (block-level area) containing lines (block-level 
areas). The LineArea autogeneration by BlockArea (well, actually by 
fo:block) takes _any_ inlines (the inlines corresponding to characters and 
the explicit inlines) and feeds them into LineAreas, which are in turn 
stacked block-wise. So far so good, nothing new; and if a block-level area 
is a child of fo:block we still have no problems - all child areas of 
BlockArea (for fo:block) remain block-level areas.

So why not this same kind of idea for fo:inline? Symmetry suggests that we 
simplify our picture of fo:inline if we posit an area corresponding to 
LineArea, that is inline-level, and is autogenerated by fo:inline as a 
child of the primary InlineArea, as required, to handle returned 
block-levels. This is the wrapping problem (we need the German term for this 
to be suitably academic) I alluded to before. But now I think there is a 
nice symmetrical argument for doing so.

This counterpart to LineArea, an inline that contains only block-level 
children, needs a name, and would be a pure FOP construct. Right now I'll 
call it a BarArea, for want of a better term. Nothing stopping us from using 
InlineArea for this as double-duty, though.

Example:

<fo:inline>
Some normal text followed by <fo:inline font-weight="bold"
>heavy stuff</fo:inline> and several blocks:
<fo:block>Hello,</fo:block>
<fo:block> World!</fo:block>
</fo:inline>

would see one or more BarAreas generated to hold the BlockAreas. The 
InlineArea from fo:inline has only inlines (straight InlineAreas and also 
BarAreas) as children.

Expected result: by symmetry, for the above example I expect to see 'Hello,' 
stacked on top of ' World!', the whole functioning like a character, and 
laid out inline into a parent LineArea (ultimately).

I stress that BarArea is a hypothetical construct. InlineArea would serve 
just as well. Is there a counterpart to line-breaking? Probably not - just 
usage and common sense. Still, consider

<fo:inline>
<fo:block>A</fo:block>
<fo:block>B</fo:block>
<fo:block>C</fo:block>
</fo:inline>

Without even looking at the spec I expect to see this stack A on top of B, 
and B on top of C, with the whole thing being an inline. So there is no 
individual wrapping of block-level children, because this seems to defeat 
the whole purpose. Not sure that I can justify this with the spec, though.

In other words,

<fo:block>
A
<fo:inline>
<fo:block>B</fo:block>
<fo:block>C</fo:block>
<fo:block>D</fo:block>
</fo:inline>
E
</fo:block>

gives us something like

 B
 C
ADE

Thoughts?

Regards,
Arved

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


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