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 n
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 fo
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
handling
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 a
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
> bec
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 s
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
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 po
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.
I
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: addMarkers(true,t
> -Original Message-
> From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
>
> 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
> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]
>
Hi Chris,
> 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 t
> 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
>
>
>
>
> ...
>
>
> Does last-ending-within-page retr
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
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 d
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"
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 defi
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
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 anyway
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 direc
> 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 transpo
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 contain
> 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 containi
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 w
> -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
> > cont
> 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
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 a
Arved Sandstrom wrote:
Comments below.
-Original Message-
From: Keiron Liddle [mailto:[EMAIL PROTECTED]
Sent: February 24, 2003 10:59 PM
Exactly. All definitions regarding retrieve-position exclusively
refer to the "current page". There is not a single word on what should
happen if there
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
> > refe
> 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
> o
> 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 absolutel
> 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 t
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
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 reasonabl
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 be
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
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
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 t
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 similarl
te this portion (markers) made the spec too abstruse. I
finally just broke my rule of adhering to the law, and considered the use
cases, and decided what made sense. :-)
Arved
> -Original Message-
> From: Keiron Liddle [mailto:[EMAIL PROTECTED]
> Sent: February 23, 2003 6:49 PM
>
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 bo
a good
document, or a good implementation. Or both. 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
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 s
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 im
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 PROTECTED]
cised, 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 XSL
: 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.Pietschm
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, e-ma
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. I
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
50 matches
Mail list logo
