You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Keiron Liddle <ke...@aftexsw.com> on 2003/02/18 23:42:47 UTC

markers in redesign

Hi all,

Since the topic is being discussed why don't we look at implementing markers in 
the redesign.

I'll try to do what is obvious, getting the markers from the fo, adding when adding 
areas and retrieving when needed.
I think some areas need changing so that the layout manager type is resolved 
after resolving markers, for example with tables it shouldn't make any 
assumptions about the type of child.

I don't understand the boundaries etc. so I might need some help there.

Keiron.



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


Re: markers in redesign

Posted by Tony Graham <To...@Sun.COM>.
J.Pietschmann wrote at  3 Mar 2003 21:58:55 +0100:
 > This still leaves the question: Does a block with a
 > break-before="page" or a break-after="page" span two pages,
 > or will it always be the first/last area on the page its
 > content is rendered on?

One page (assuming it fits within one page).

7.19.1, "break-after"

   Specifies that the first normal area generated by formatting the
   next formatting object, if any, shall be the first one placed in a
   particular context (e.g., page-area, column-area).

7.19.2, "break-before"

   Specifies that the first area generated by this formatting object
   shall be the first one placed in a particular context (e.g.,
   page-area, column-area).

 > Examples
 >   <fo:block id="A">
 >     <fo:marker marker-class="I" id="m1"/>
 >     <fo:block id="B" break-after="page">
 >       <fo:marker marker-class="I" id="m2"/>
 >       ...
 >     </fo:block>
 >   </fo:block>
 > Does last-ending-within-page retrieve m1 or m2?
 > I'd think m2.

So do I.

 >   <fo:block id="A" break-after="page">
 >     <fo:marker marker-class="I" id="m1"/>
 >     <fo:block id="B">
 >       <fo:marker marker-class="I" id="m2"/>
 >       ...
 >     </fo:block>
 >   </fo:block>
 > Does last-ending-within-page retrieve m1 or m2?
 > Probably m1, but where in the spec can I find backing for this
 > opinion?

I think m2, since B follows A in a pre-order traversal order.

7.23.3. "retrieve-position"

   last-ending-within-page

      Specifies a preference for retrieving the children of an
      fo:marker attached to an area that is within the containing page
      whose "is-last" trait is set to "true" and that follows in the
      area tree any other similarly constrained area that is attached
      to an identically named fo:marker, using pre-order traversal
      order.

Regards,


Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3            x(70)19708

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


Re: markers in redesign

Posted by "J.Pietschmann" <j3...@yahoo.de>.
Peter B. West wrote:
> More heart-in-the-mouth stuff for me, as I have coded the pre- and 
> post-order iterators in Node according to another interpretation, and I 
> have just had a mad search to try to justify it.
> 
>  From the DOM Level 2 Traversal and Range spec glossary:
> 
> document order
>     The term document order has the same meaning as depth first, 
> pre-order traversal, which is equivalent to the order in which the start 
> tags occur in the text representation of the document.
> 
Ouch, I mistakenly used in-order traversal, instead of
pre-order traversal. This clears up quite a few mysteries!
Does spec reading cause temporary brain damage?

This means if there are FOs generating nested areas with
markers with the same marker-class in nested FOs, the
outermost marker will be retrieved unless a isFirst()
or isLast() preference kicks in.

This still leaves the question: Does a block with a
break-before="page" or a break-after="page" span two pages,
or will it always be the first/last area on the page its
content is rendered on?
Examples
  <fo:block id="A">
    <fo:marker marker-class="I" id="m1"/>
    <fo:block id="B" break-after="page">
      <fo:marker marker-class="I" id="m2"/>
      ...
    </fo:block>
  </fo:block>
Does last-ending-within-page retrieve m1 or m2?
I'd think m2.

  <fo:block id="A" break-after="page">
    <fo:marker marker-class="I" id="m1"/>
    <fo:block id="B">
      <fo:marker marker-class="I" id="m2"/>
      ...
    </fo:block>
  </fo:block>
Does last-ending-within-page retrieve m1 or m2?
Probably m1, but where in the spec can I find backing for this
opinion?

J.Pietschmann


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


Re: markers in redesign

Posted by "Peter B. West" <pb...@powerup.com.au>.
J.Pietschmann wrote:
> Hello,
> I reexamined the marker problematic again.
...
> "When comparing two areas to determine which one is better, the
>  terms "first" and "last" refer to the pre-order traversal order
>  of the area tree."
...
> 
> The quote above shows another problem: I'm used to the term
> "pre-order" in context of binary trees, where it means that
> first the "first"/"left" subtree is visited, then the node
> itself, then the "last"/"right" subtree. Unfortunately, the
> area tree is hardly a binary tree. How should the term be
> interpreted in this context?
> 
> Let's take an example:
>  <fo:block id="A">
>    <fo:marker marker-class="I" id="m1"/>
>    <fo:block id="B">
>      <fo:marker marker-class="I" id="m2"/>
>      ...
>    </fo:block>
>  </fo:block>

Joerg,

More heart-in-the-mouth stuff for me, as I have coded the pre- and 
post-order iterators in Node according to another interpretation, and I 
have just had a mad search to try to justify it.

 From the DOM Level 2 Traversal and Range spec glossary:

document order
     The term document order has the same meaning as depth first, 
pre-order traversal, which is equivalent to the order in which the start 
tags occur in the text representation of the document.

In such an ordering, A precedes B.


> Block B is, according to my interpretation of "pre-order"
> before block A, therefore retrieving class I with
> first-starting-within-page would get marker 2. Also,
> retrieving with either last-starting-within-page or
> last-ending-within-page should return marker m1.

-- 
Peter B. West  pbwest@powerup.com.au  http://www.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: markers in redesign

Posted by "J.Pietschmann" <j3...@yahoo.de>.
Hello,
I reexamined the marker problematic again.
There are a few issues not yet mentioned. First some odd wording:
"The properties of the fo:retrieve-marker impose a hierarchy of
  preference on the areas of the area tree..."
Unfortunately, they don't define this hierarchy directly but
instead define how preferences are derived from this hierarchy.
"Every area in the hierarchy is considered preferential to, or
  "better" than, any area below it in the hierarchy."
I suppose the 'hierarchy' mentioned here is the marker preference
hierarchy rather than the area tree hierarchy. Further:
"When comparing two areas to determine which one is better, the
  terms "first" and "last" refer to the pre-order traversal order
  of the area tree."
It's hard to see what purpose the marker preference hierarchy
serves, as the real definition of the preferences is still done
in terms of the area tree hierarchy.

The quote above shows another problem: I'm used to the term
"pre-order" in context of binary trees, where it means that
first the "first"/"left" subtree is visited, then the node
itself, then the "last"/"right" subtree. Unfortunately, the
area tree is hardly a binary tree. How should the term be
interpreted in this context?

Let's take an example:
  <fo:block id="A">
    <fo:marker marker-class="I" id="m1"/>
    <fo:block id="B">
      <fo:marker marker-class="I" id="m2"/>
      ...
    </fo:block>
  </fo:block>
Block B is, according to my interpretation of "pre-order"
before block A, therefore retrieving class I with
first-starting-within-page would get marker 2. Also,
retrieving with either last-starting-within-page or
last-ending-within-page should return marker m1.

A "common sense" approach should probably yield
first-starting-within-page: m1
last-starting-within-page: m2
last-ending-within-page: m1
The last one is of course debatable, there are arguments
(using a "glossary" example) in favor of resulting in m2.

If "hierarchy" in
"Every area in the hierarchy is considered preferential to, or
  "better" than, any area below it in the hierarchy."
is interpreted as "area tree hierarchy", always m1 would be
retrieved, because the area generated by block A has both
isFirst() and isLast() and is always "above" the area from
block B. This interpretation is a bit better than the "to
the letter" interpretation for first-starting-within-page
and last-ending-within-page but doesn't really fit well for
last-starting-within-page.

Another interesting example
  <fo:block id="A">
    <fo:marker marker-class="I" id="m1"/>
    <fo:block id="B" break-after="page">
      <fo:marker marker-class="I" id="m2"/>
      ...
    </fo:block>
  </fo:block>
I interpret this that the area block A creates two areas,
one of the first and one zero size area on the second page.
Mind you, this is not at all clear from the spec, I more or
less grabbed this out of the blue.
The "common sense" result for the first page would mean
last-ending-within-page returns m2.
On the second page, every retrieve-position retrieves m1,
of course.

J.Pietschmann


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