Hi, Keiron
I interpret 6.11.4 as follows. Number one, the names have to match -
marker-class-name and retrieve-class-name. This is straightforward. It
defines qualifying areas.
Number two, qualifying areas are excluded if they follow the page being
formatted, regardless of retrieve-boundary. So
Keiron Liddle wrote:
Hi all,
Is it correct that it should look for markers on the current page and if page
boundary is current page then stop there. If boundary is page-sequence then
keep going backwards on each page until a marker is found or reaches the start
of the page-sequence and
Comments below.
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
Sent: February 24, 2003 6:53 AM
To: [EMAIL PROTECTED]
Subject: Re: markers in redesign
[ SNIP ]
It seems to me that the hierarchy is not the same as the area tree or
fo tree hierarchy. It is a
Arved Sandstrom wrote:
...
That means, to me, first, that we use the naming to identify qualifying
areas.
Two, we use retrieve-boundary to filter out qualifying areas. I make that
distinction, because qualifying areas are defined by the naming alone.
Three, we use retrieve-position coupled
Arved Sandstrom wrote at 24 Feb 2003 08:01:40 -0400:
Comments below.
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
Sent: February 24, 2003 6:53 AM
To: [EMAIL PROTECTED]
Subject: Re: markers in redesign
[ SNIP ]
It seems to me that the
Comments inline.
-Original Message-
From: Tony Graham [mailto:[EMAIL PROTECTED]
Sent: February 24, 2003 10:26 AM
To: [EMAIL PROTECTED]
Subject: RE: markers in redesign
Arved Sandstrom wrote at 24 Feb 2003 08:01:40 -0400:
Comments below.
-Original Message-
Arved Sandstrom wrote:
I assume last in this context
means last geometrically, as opposed to some other last.
I'd think it's the last area generated and inserted in the area
tree by the parent FO of the marker, if applicable. This is of
course usually the last, geometrically, for some reasonably
Arved Sandstrom wrote:
The thing that bugs me is, when there is no qualifying area in the
containing page (Note to spec editors: try saying currently-formatted
page), after filtering, then it becomes anarchy. It seems like user
preferences based on retrieve-position lose all relevance. In other
pietsch 2003/02/24 11:55:46
Modified:src/org/apache/fop/image Tag: fop-0_20_2-maintain
FopImageFactory.java
Log:
provide a protected constructor to FopImageFactory so that
it can't be instantiated (all methods are static).
Revision ChangesPath
pietsch 2003/02/24 12:42:20
Modified:src/org/apache/fop/fo/flow Tag: fop-0_20_2-maintain
RetrieveMarker.java
Log:
Fixed thinko regarding check for retrieve-boundary=PAGE
Revision ChangesPath
No revision
No
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13289.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Keiron,
I haven't looked at markers too closely, but I would tend to think that,
in the first case, block c is the last-starting-within-page. Blocks a,
b and c all qualify; they all have an is-first trait of true. So
which one follows all others in the area tree, *in pre-order
Exactly. All definitions regarding retrieve-position exclusively
refer to the current page. There is not a single word on what should
happen if there is no matching marker on the current page but several
on the previous page which are eligible. FOP picks the last, but there
is absolutely
I haven't looked at markers too closely, but I would tend to think that,
in the first case, block c is the last-starting-within-page. Blocks a,
b and c all qualify; they all have an is-first trait of true. So
which one follows all others in the area tree, *in pre-order traversal
order*?
Comments below.
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]
Sent: February 24, 2003 10:59 PM
To: [EMAIL PROTECTED]
Subject: Re: markers in redesign
Exactly. All definitions regarding retrieve-position exclusively
refer to the current page. There is not a
15 matches
Mail list logo