Simon, thanks for looking into this. I'm not quite sure I got your
instructions for a markers5c right. I'd appreciate if you'd check in the
test case you created.
I've added a Bugzilla item [1] for this. I intend to revisit this later.
It would really be good to have test cases for all those
Jeremias,
I have looked into the problem in more depth. The wrong retrieved
marker is not only due to the bogus area, but also to the flawed logic
of dealing with retrieve-position for the markers in
PageViewport.addMarkers. Even if block 5 adds a bogus area to page 1,
block 5 would not qualify
Simon,
I'm sorry that I missed your plan. I didn't remember your posting this.
I think your plan would be a good start into refactoring the breaking in
block progression direction. I think it'll need to be clarified WRT
resets/backtracking in case of final decisions on page break, column
Glen,
no, I'm afraid the isBogus() method is necessary because it checks the
parent LM. In the markers6a.xml example (for which I still have to write
the checks, I just found out), the block in the third cell of the fifth
row has an effective BPD of 0 and therefore fits nicely into the
available
OK...I see its purpose now. But please put in a
descriptive comment for isBogus() in
AbstractLayoutManager so others down the road
understand what it means and what it is for.
Glen
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
Glen,
no, I'm afraid the isBogus() method is necessary
because
Jeremias,
I do not have much time to look into your problem, so I will just try
to give a quick answer.
In my view the current BP setup is not able to generate good page
break decisions. It only can do a first-fit algorithm. From your
account, BPs are also overloaded to signal the completion of
Jeremias,
I don't see the need for the bBogus variable/isBogus()
method, because in the three or four places where the
value of this variable is actually *being used*, it is
just set to :
bBogus = !bp1.generatesAreas();
So it appears you can just rely on
!bp1.generatesAreas() in these places
I've got a possible fix for the problem. But I don't know if it's not
too much of a hack. At least it somehow feels like a hack. Any comments
about the attached patch? Obviously, some javadocs are missing and the
naming could probably be improved but this is just an idea how this
could be fixed.
Can't add much here, but I do remember noticing the
bogus areas being created when I was trying to fix
spacing about a year ago. And, yes, I do agree it
would be better if our algorithms did not need them to
be created.
Thanks,
Glen
--- Jeremias Maerki [EMAIL PROTECTED] wrote:
I've got a
Andreas L. Delmelle wrote:
Just gathering my thoughts here...
Thanks for your feedback. I need all the help I can get!
If I interpret the related code in BLM correctly, then the childLMs are all
created (and call their addAreas() ) after the first marker has been added
( line 265:
-Original Message-
From: Chris Bowditch [mailto:[EMAIL PROTECTED]
Hi Chris,
snip /
the markers are added to pageViewport in the BLM.addAreas method. Now my
understanding is that addAreas are called once the BPs have been
processed and the areas are about to be rendered. So how is
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
snip /
Maybe sheds some light on the situation. As to what needs to be
done to fix it... no particular idea for the moment.
Just ran a few tests of my own, with FOP's examples/fo/markers/hide.fo, and
I could be
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
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).
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
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
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
Hi all,
I think I am getting an idea of the markers with Peter's and others points but I don't
fully understand how it should work or be implemented.
Anyway I have committed the code of how it might roughly work and hopefully it
is correct for the containing page. It isn't that much code
Keiron Liddle wrote:
Hi all,
I think I am getting an idea of the markers with Peter's and others points but I don't
fully understand how it should work or be implemented.
Anyway I have committed the code of how it might roughly work and hopefully it
is correct for the containing page. It isn't
Keiron Liddle wrote:
How do you jump from the first sentance to the second one. The containing
page refers to the page where the marker is first formatted not where the
retrieve-marker occurs.
A marker generates areas after being retrieved by a retrieve-marker.
The containing page is the page
Keiron Liddle wrote:
Keiron Liddle wrote:
How do you jump from the first sentance to the second one. The containing
page refers to the page where the marker is first formatted not where the
retrieve-marker occurs.
A marker generates areas after being retrieved by a retrieve-marker.
The
But the marker subtree from the previous page is tranposed into the same
containing page.
Where do you get that from, how is it transposed, I have not seen any information
about this?
Considering all the retrieve positions refer to areas in the containing page then
these markers transposed
Keiron Liddle wrote:
But the marker subtree from the previous page is tranposed into the same
containing page.
Where do you get that from, how is it transposed, I have not seen any information
about this?
I was thinking of
6.11.4 fo:retrieve-marker
Areas:
The fo:retrieve-marker does not
J.Pietschmann wrote:
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
Looking at it again, I disagree. The containing page is the page
containing the first area generated or returned by the children of the
retrieved fo:marker. That is, the page on which the fo:retrieve-marker
occurs in the static-content. This will only vary if the retrieval
forces a
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]
Sent: February 25, 2003 9:16 PM
To: [EMAIL PROTECTED]
Subject: Re: markers in redesign
Looking at it again, I disagree. The containing page is the page
containing the first area generated or returned
what made sense. :-)
Arved
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]
Sent: February 23, 2003 6:49 PM
To: [EMAIL PROTECTED]
Subject: Re: markers in redesign
Hi all,
Is it correct that it should look for markers on the current page
and if page
boundary
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
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
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
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
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 similarly for the document
Arved Sandstrom wrote:
Joerg, you can freely get rid of that stuff. I originally introduced it when
I had more faith in the spec, and thought that the authors knew what they
were talking about when it came to to their math. Specifically, the lineage
pairs is an abstract concept that I can see no
Arved Sandstrom wrote:
They are not connected concepts, Mark. I originally put in the code for
lineage pairs, and also started the implementation for markers. So I can
assure you that they are completely unrelated. For what it's worth,
subsequent contributors have significantly improved on marker
. In this case the experts are
the customers; we have a confused spec because they thought they were the
programmers and writers as well.
Arved
-Original Message-
From: Peter B. West [mailto:[EMAIL PROTECTED]
Sent: February 22, 2003 8:23 AM
To: [EMAIL PROTECTED]
Subject: Re: Markers in areas
Arved Sandstrom wrote:
Joerg, you can freely get rid of that stuff.
Great!
Anybody out there bothering to profile the new code? Two
objects less created per Area, this should be noticable!
J.Pietschmann
-
To unsubscribe,
: Tuesday, February 18, 2003 4:09 PM
To: [EMAIL PROTECTED]
Subject: Re: Markers in areas
Arved Sandstrom wrote:
Joerg, you can freely get rid of that stuff.
Great!
Anybody out there bothering to profile the new code? Two
objects less created per Area, this should be noticable!
J.Pietschmann
, and replaced with plain language.
Arved
-Original Message-
From: Mark C. Allman [mailto:[EMAIL PROTECTED]]
Sent: February 18, 2003 5:16 PM
To: [EMAIL PROTECTED]
Subject: RE: Markers in areas
... but markers will continue to work as per the XSLFO spec, correct?
We depend
Mark C. Allman wrote:
... but markers will continue to work as per the XSLFO spec, correct?
There are restrictions (and have always been). Look into the CHANGES
file.
J.Pietschmann
-
To unsubscribe, e-mail: [EMAIL
Joerg, you can freely get rid of that stuff. I originally introduced it when
I had more faith in the spec, and thought that the authors knew what they
were talking about when it came to to their math. Specifically, the lineage
pairs is an abstract concept that I can see no implementation use for.
At 06:55 AM 8/30/01 -0700, David Nyakundi wrote:
Is there a version of FOP that works with markers?
Well, there should be quite soon, maybe FOP 0.20.2. I had marker support
sketched out in CVS but some other (more important and more mature) code
that we put in just prior to the last release
48 matches
Mail list logo
