DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33555.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
nasty effects.
If you find anything wrong (not just fpr markers) PLEASE write a test
case and check it in even if it doesn't work ATM and you have to add it
to the disabled-testcases.txt. You don't have to write the XPath checks
yourself. We can always do that later.
[1] http://issues.apache.org
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
[The Web Maestro]
I don't know how the spec deals with this, but I doubt the
spec cares which algorithm is used. That said, would it be a
good idea to determine which algorithm to use based on
something in userconfig.xml or something? If the Knuth system
is more 'expensive' in terms of
Finn Bock wrote:
Not at all. It is a rather trivial change to knuth to pick a
page break when there is N pages of lookahead.
If we assume that finished page knuth element arrive one at
time to the KnuthPage algorithm, the main loop becomes:
addKnuthElement(element) {
if
Finn Bock wrote:
I would pass the element on the immidiate parent, which recursively
passes them on the top-level LM in the direction. For inline, the
toplevel would be LineLM and for blocks it would be the PageLM.
Ok, I misunderstood what you wrote, now I think we were saying the same
thing
engine I don't have a quick answer to that although I'm making progress
in understanding. Here's what I found out so far:
The reason for the bad markers is the addMarkers call, for example in
BlockLayoutManager.addAreas(). When the LM finds out that the next area
won't fit on the current
[Luca]
I'm not sure it is always possible to do this: sometimes the
representation of a block depends on the properties of a higher level
block. For example:
outer block
|
-
| |
innerinner
blockblock
12
In order to decide whether there
On Feb 7, 2005, at 7:21 AM, Luca Furini wrote:
Finn Bock wrote:
Using your description as a jumping point, here is my ideas for page
breaking. I suppose it is even more pie-in-the-sky since I haven't yet
written anything about it.
As I have been doing a few experiments about page breaking, I'm
The Web Maestro wrote:
I don't know how the spec deals with this, but I doubt the
spec cares which algorithm is used. That said, would it be a
good idea to determine which algorithm to use based on
something in userconfig.xml or something? If the Knuth system
is more 'expensive' in terms
On Feb 7, 2005, at 11:57 AM, Victor Mote wrote:
The Web Maestro wrote:
I don't know how the spec deals with this, but I doubt the
spec cares which algorithm is used. That said, would it be a
good idea to determine which algorithm to use based on
something in userconfig.xml or something? If the
The Web Maestro wrote:
e-mail... I suspect there may be another 'side' to the
story--there always is--and that there's may be other
contributing factors... but this helps me understand much
more than I understood before. Your explanation below also
Yes, there is another side, and I
stacking dimension. Therefore its BreakPoss doesn't have the
nextBreakOverflows() return true. But the row in which that block and
its parent cell are found has an overflow because of the first two cells
which don't fit. If isBogus() doesn't check the parentLM the markers for
row 5 are added to page
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
of getting to know the layout
engine I don't have a quick answer to that although I'm making progress
in understanding. Here's what I found out so far:
The reason for the bad markers is the addMarkers call, for example in
BlockLayoutManager.addAreas(). When the LM finds out that the next area
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
what I found out so far:
The reason for the bad markers is the addMarkers call, for example in
BlockLayoutManager.addAreas(). When the LM finds out that the next area
won't fit on the current page it creates a BreakPoss signalling that
state. The problem now is that addAreas() also gets
in the process of getting to know the layout
engine I don't have a quick answer to that although I'm making progress
in understanding. Here's what I found out so far:
The reason for the bad markers is the addMarkers call, for example in
BlockLayoutManager.addAreas(). When the LM finds out
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
Moving this issue to bugzilla.
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
(Reporting this here, since for some reason can't connect to
nagoya.apache.org... is it just me or does anyone else have this problem
too?)
On Sun, Nov 14, 2004 at 10:11:01PM +0100, Andreas L. Delmelle wrote:
Hi,
(Reporting this here, since for some reason can't connect to
nagoya.apache.org... is it just me or does anyone else have this problem
too?)
While running some tests after updating to include Luca's latest patch
-Original Message-
From: Simon Pepping [mailto:[EMAIL PROTECTED]
On Sun, Nov 14, 2004 at 10:11:01PM +0100, Andreas L. Delmelle wrote:
While running some tests after updating to include
Luca's latest patch (bugzilla 31206),
I get a ClassCastException in LineLM.getNextBreakPoss()
Hi,
(Reporting this here, since for some reason can't connect to
nagoya.apache.org... is it just me or does anyone else have this problem
too?)
While running some tests after updating to include Luca's latest patch
(bugzilla 31206), I get a ClassCastException in LineLM.getNextBreakPoss()
line
,true); )
addMarkers( true, true ); translates to
parentLM.addMarkerMap( markers, true, true ); (see
AbstractLayoutManager.java line 360 )
This latter stops at page-level, in PageLayoutManager, it becomes:
curPage.addMarkerMap( markers, true, true );
So, IIC, this makes it conceivable that a marker
FOP Devs,
I'm currently trying to get Markers working. The problem I have is that the
first marker on page 2 is actually being added to the markers on Page 1.
the markers are added to pageViewport in the BLM.addAreas method. Now my
understanding is that addAreas are called once the BPs have
-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
-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
pbwest 2003/07/08 05:58:30
Added: examples/fo/markers Tag: FOP_0-20-0_Alt-Design hide.fo
glossary.xml glossary.xsl
Log:
Copied from HEAD.
Revision ChangesPath
No revision
No revision
1.2.2.1
meaning. It's an example of the
impossibility of resolving FO property expressions independently of area
tree construction.
I have attached a diagram illustrating my thinking about processing
markers in the context of alt.design.
Fig 1) illustrates the general flow of control in alt.design's pull
!
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
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
not directly generate any area. It is
(conceptually) replaced by the children of the fo:marker that it retrieves.
Considering all the retrieve positions refer to areas in the containing page then
these markers transposed from a previous page are not attached to areas in the
containing page.
Are you
with top of 0cm will precede
the first on the page, it follows the first in the area tree. This
interpretation would help with the case in which the markers are defined
in both absolutely positioned and normal areas.
--
Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/
Lord, to whom
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
think. An FO
is generating and returning areas on the containing page, and the first one
is...well, the first one. :-) So it is the optimal candidate if its parent
FO has qualifying markers. With reference to your [2], return to the def'n
of qualifying area: name-matching, period. I assume last
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
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
intuitive definition of geometrically. Odd things may happen
if the marker is attached to a footnode body of a footnote broken
across several pages...
I think whoever wrote this portion (markers) made the spec too abstruse. I
finally just broke my rule of adhering to the law, and considered the use
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,
... but markers will continue to work as per the XSLFO spec, correct?
We depend on markers for dynamic page headings.
-- Mark C. Allman
-- Allman Professional Consulting, Inc.
-- www.allmanpc.com, 617-947-4263
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
Sent
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 support, so I
am only
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
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
for. In
fact, I can't see any theoretical use for the idea either.
Arved
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
Sent: February 16, 2003 8:14 PM
To: [EMAIL PROTECTED]
Subject: Markers in areas
Hi,
does somebody need the markers attached to an area? I just
Hi,
does somebody need the markers attached to an area? I just canned them,
as well as another array atteched to areas (lineage pairs). Markers
were only used in the XML renderer. They ought to have uses to implement
retrieve-positions first-include-carryover and last-ending-within-page
jeremias2003/01/13 10:08:52
xml-fop/examples/fo/markers - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Tue, 2002-12-10 at 17:26, Arved Sandstrom wrote:
Incidentally, I still think that the way markers are described in the spec
is vague and confusing. Perhaps we should hammer this out.
Agreed.
I still have figured out what it really means
[EMAIL PROTECTED] wrote:
The markers work fine
except in one instance: if ROW4 and ROW5 overflow into the next page, the
retrieve marker will pull ROW5MARKERDATA1 and ignore ROW4MARKERDATA1 even
though ROW 4 is a distinctly new row. If more than two rows overflow, it
seems to work OK (i.e
J.Pietschmann:
Let me restate the line:
but I thought these were a function of markers in 20.2.
as
but I thought these were a function of the unfinished markers in 20.2.
Sorry if I offended. Thanks for the info.
-Lou
J.Pietschmann [EMAIL PROTECTED] on 08/01/2002 09:30:29
Please
/show_bug.cgi?id=6741
markers are completely broken (as far as I can tell)
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
/show_bug.cgi?id=6741
markers are completely broken (as far as I can tell)
Summary: markers are completely broken (as far as I can tell)
Product: Fop
Version: 0.20.3
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Normal
Is there a version of FOP that works with markers?
__
Do You Yahoo!?
Get email alerts NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com
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
arved 01/07/26 19:13:24
Added: docs/examples/markers glossary.xml glossary.xsl
Log:
AHS: fo:marker examples
Revision ChangesPath
1.1 xml-fop/docs/examples/markers/glossary.xml
Index: glossary.xml
with some of the values of retrieve-position). But it isn't intentional at
this point that any of it really _works_; consider it pre-alpha and untested.
I am focusing on a nucleus of supporting markers inside fo:block (the lazy
but useful approach) initially. I plan to gradually expand that out
76 matches
Mail list logo
