Re: Markers added to the wrong page

[Jeremias Maerki]

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 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/bugzilla/show_bug.cgi?id=33555

On 13.02.2005 12:26:27 Simon Pepping wrote:
> 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 for last-ending-within-page.
> 
> A correct implementation of the retrieve-position logic requires that
> the traits is-first and is-last are correctly set. These find a place
> in BreakPoss, but not all LMs set the traits correctly. A bogus area
> would again upset the markers, because it would falsely take the trait
> is-first.
> 
> If you create markers5c such that block 4 takes two lines (and change
> the region before to: retrieve-position="first-including-carryover"),
> you have another failing test case.
> 
> BPs for bogus areas can be recognized by their position:
> BP.getPosition().getPosition() == -1. Probably it is a good idea to
> suppress BPs for bogus areas altogether: if (over &&
> childBreaks.size() == 0) return null.
> 
> Note that for empty blocks also a BP without areas is returned, with
> position = -2. I am not sure whether they make sense. They do not
> generate an area due to a special condition in addAreas. If it is
> possible to add markers to an empty block, such BPs are necessary,
> although the position of the markers around a page break is undefined.
> 
> This is a nasty case:
> 
> Several lines of text
> 
> when the text 'Several...' starts on the new page. There would again
> be an empty area on the previous page. It would again be recognized by
> !BP.generatesAreas(), but it would again falsely take the trait
> is-first.
> 
> On Thu, Feb 03, 2005 at 06:19:29PM +0100, Jeremias Maerki wrote:
> > Team, 
> > 
> > I've just checked in markers5a and markers5b which look very closely
> > which marker is added to which page for every block.
> > 
> > As I'm still somewhat 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 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 these BreakPoss
> > instances which aren't visible in the generated document but are still
> > generating an (empty) Area (on the page preceeding the one where the
> > Area will really come to rest). That causes one marker too many to be
> > added to a page.
> > 
> > The same BTW applies to addID() calls which also remembers IDs on the
> > wrong pages.
> > 
> > What I'm currently doing is trying to really (!) understand the whole
> > BreakPoss mechanism so I can figure out a reliable way to find out how
> > to avoid this bug. Two possibilities:
> > 1. Don't generate bogus areas at all.
> > 2. Just suppress addMarkers() and addID().
> > 
> > I'm currently wondering if the generated BreakPoss instances should get
> > an additional flag (or two) which controls the generation of the area
> > and the addMarkers()/addID() calls. addMarkers()/addID() may be
> > necessary in certain circumstances while on the other side no area is
> > generated (empty block with only markers).
> > 
> > You can easily see these bogus areas when you output to the area tree
> > renderer or in build/test-results/layoutengine when running the Ant
> > build.
> > 
> > I'll continue investigating but would appreciate any ideas you might
> > have.
> > 
> > Jeremias Maerki
> > 
> 
> -- 
> Simon Pepping
> home page: http://www.leverkruid.nl



Jeremias Maerki

DO NOT REPLY [Bug 33555] - Markers: Current implementation has bugs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33555


[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|[EMAIL PROTECTED] |fop-dev@xml.apache.org




--- Additional Comments From [EMAIL PROTECTED]  2005-02-15 09:36 ---
Reassigning to fop-dev because it seems that the list doesn't get notified if 
I directly assign an issue to myself.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: Markers added to the wrong page

[Simon Pepping]

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 for last-ending-within-page.

A correct implementation of the retrieve-position logic requires that
the traits is-first and is-last are correctly set. These find a place
in BreakPoss, but not all LMs set the traits correctly. A bogus area
would again upset the markers, because it would falsely take the trait
is-first.

If you create markers5c such that block 4 takes two lines (and change
the region before to: retrieve-position="first-including-carryover"),
you have another failing test case.

BPs for bogus areas can be recognized by their position:
BP.getPosition().getPosition() == -1. Probably it is a good idea to
suppress BPs for bogus areas altogether: if (over &&
childBreaks.size() == 0) return null.

Note that for empty blocks also a BP without areas is returned, with
position = -2. I am not sure whether they make sense. They do not
generate an area due to a special condition in addAreas. If it is
possible to add markers to an empty block, such BPs are necessary,
although the position of the markers around a page break is undefined.

This is a nasty case:

Several lines of text

when the text 'Several...' starts on the new page. There would again
be an empty area on the previous page. It would again be recognized by
!BP.generatesAreas(), but it would again falsely take the trait
is-first.

On Thu, Feb 03, 2005 at 06:19:29PM +0100, Jeremias Maerki wrote:
> Team, 
> 
> I've just checked in markers5a and markers5b which look very closely
> which marker is added to which page for every block.
> 
> As I'm still somewhat 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 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 these BreakPoss
> instances which aren't visible in the generated document but are still
> generating an (empty) Area (on the page preceeding the one where the
> Area will really come to rest). That causes one marker too many to be
> added to a page.
> 
> The same BTW applies to addID() calls which also remembers IDs on the
> wrong pages.
> 
> What I'm currently doing is trying to really (!) understand the whole
> BreakPoss mechanism so I can figure out a reliable way to find out how
> to avoid this bug. Two possibilities:
> 1. Don't generate bogus areas at all.
> 2. Just suppress addMarkers() and addID().
> 
> I'm currently wondering if the generated BreakPoss instances should get
> an additional flag (or two) which controls the generation of the area
> and the addMarkers()/addID() calls. addMarkers()/addID() may be
> necessary in certain circumstances while on the other side no area is
> generated (empty block with only markers).
> 
> You can easily see these bogus areas when you output to the area tree
> renderer or in build/test-results/layoutengine when running the Ant
> build.
> 
> I'll continue investigating but would appreciate any ideas you might
> have.
> 
> Jeremias Maerki
> 

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Page breaking [was: Markers added to the wrong page]

[Luca Furini]

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 using different words! :-)

Regards
Luca

RE: Page breaking [was: Markers added to the wrong page]

[Victor Mote]

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 element.isBox():
>  totalWidth += element.width
>  else if element.isGlue():
>  if (previous element is box):
>  considerLegalBreak()
>  totalWidth += element.width
>  totalStretch += element.stretch
>  totalShrink += element.shrink
>  else if element.isPenalty():
>  if element.penalty < INFINITE:
>  considerLegalBreak()
>  if activeList.startLine > currentPage + lookahead:
>  // In the activeList, find the node with the best demerit.
>  bestNode = findBestDemerit()
>  // Remove all nodes in activeList which does not 
> have bestNode
>  // in their parentage.
>  clearActiveList(bestNode)
>   makePageBreak(bestNode)
> 
> Here it is only clearActiveList() which does not have a fast 
> implementation when using the usual implementation of 
> ActiveNode. It will require a scan over all the active node 
> and for each node a scan back thru the previous links to the 
> node at currentPage+1.
> 
> clearActiveList(bestNode):
>  for node in activeList:
>  // jump back thru previous (node.page-currentPage) times.
>  while i++ < node.page - currentPage
>  previous = node.previous
>  if previous != bestNode:
>  activeList.remove(node)
>   
> 
> The rest of the methods called are similar to the methods in 
> my knuth line breaking patch (which is quite similar the 
> current implementation).

Hmmm. I guess it depends on where the N in "N pages of lookahead" comes
from. If that can be set to include the entire page-sequence, then you can
call it a Knuth-style algorithm. Otherwise, I think you have something less,
which is OK for those who don't want the performance hit.

> My own insecurity comes from figuring out which penalty values and 
> demerit algorihtm to use to get keeps and orphans right.

Yes. Fortunately, the XSL-FO standard provides some guidance here, but I
agree that this part will be a challenge.

Good luck. I am glad to see you guys heading down this path. Let me know if
there is anything I can do to help.

Victor Mote

Re: Page breaking [was: Markers added to the wrong page]

[Finn Bock]

[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 resources, we could make 
non-Knuth the default, and enable Knuth via a config file.
Yes indeed. But without measurements I would guess that knuth page 
breaking would be far less expensive than the knuth line breaking. The 
line breaking has to deal with far more elements and because of that a 
far larger set of active nodes.

But clearly a choice will be good, both for page and for line breaking.
[Victor]
The good news is that this is an excellent idea. The bad news is that FOP's
determination to not even tolerate more than one algorithm is what drove FOP
and FOray apart. So you have stumbled in to a somewhat sensitive area, which
might explain the absence of responses (so far).
BTW, since it is relevant here, thanks for your kind comments last week in
another thread. You are ever the peacemaker, a very useful role. As long as
the differences remain as great as they are, we *need* more than one FO
implementation. In the meantime, I am much more useful and productive
outside of FOP than I am in it, and, the FOP developers probably are also.
To my perhaps still naive mind, layout consists of exactly two tasks: 1)
finding line-breaks within logical blocks (nested blocks consisting of a new
logical block), and 2) finding page-breaks between and within logical
blocks. All other tasks can be conveniently handled within the two data
structures, not being dependent on any strategy. The Knuth-style algorithm
is by definition a total-fit algorithm. The scope of such an algorithm for
the first task is the logical block itself. The scope of the second task is
the page-sequence. So, to implement a Knuth-style algorithm (itself a good
idea) for item 2, requires the ability to see an entire page-sequence in the
AreaTree at one time.
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 element.isBox():
totalWidth += element.width
else if element.isGlue():
if (previous element is box):
considerLegalBreak()
totalWidth += element.width
totalStretch += element.stretch
totalShrink += element.shrink
else if element.isPenalty():
if element.penalty < INFINITE:
considerLegalBreak()
if activeList.startLine > currentPage + lookahead:
// In the activeList, find the node with the best demerit.
bestNode = findBestDemerit()
// Remove all nodes in activeList which does not have bestNode
// in their parentage.
clearActiveList(bestNode)
makePageBreak(bestNode)
Here it is only clearActiveList() which does not have a fast 
implementation when using the usual implementation of ActiveNode. It 
will require a scan over all the active node and for each node a scan 
back thru the previous links to the node at currentPage+1.

clearActiveList(bestNode):
for node in activeList:
// jump back thru previous (node.page-currentPage) times.
while i++ < node.page - currentPage
previous = node.previous
if previous != bestNode:
activeList.remove(node)

The rest of the methods called are similar to the methods in my knuth 
line breaking patch (which is quite similar the current implementation).

My own insecurity comes from figuring out which penalty values and 
demerit algorihtm to use to get keeps and orphans right.

regards,
finn

RE: Page breaking [was: Markers added to the wrong page]

[Victor Mote]

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 respect that. The point is that the
differences are hard-wired at a pretty low-level (think silicon instead of
Java). I am constitutionally unable to make myself work on a project that
*can* be broken up into smaller pieces and isn't. Others appear to be
constitutionally unable to allow that to happen. Most can probably live with
it either way. OK, not every problem is solvable, and not every difference
is reconcilable. We go on. You guys pull east, I'll pull west, and as long
as we're pulling *different* wagons, we each have a shot at making some
progress.

> Might these links help:

I think those are the "other" books, but, to tell the truth, after looking
at the links, I can't tell. I'll have to go dig out my old notes to see
which book I was wanting. I'll check into it further. Thanks.

Victor Mote

Re: Page breaking [was: Markers added to the wrong page]

[The Web Maestro]

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 Knuth system
is more 'expensive' in terms of resources, we could make
non-Knuth the default, and enable Knuth via a config file.
Hi Clay:
The good news is that this is an excellent idea. The bad news is that 
FOP's
determination to not even tolerate more than one algorithm is what 
drove FOP
and FOray apart. So you have stumbled in to a somewhat sensitive area, 
which
might explain the absence of responses (so far).
Thanks for the heads up, and also for the 'clue'... I never completely 
understood what happened, as it occurred before I was committed. ;-) I 
understand a bit more, thanks to this 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 helps! I probably 
just need to ask for help when I don't understand something... but I've 
got enough going in my head anyway...

FOP-DEV... Please don't take this as griping (it's not!), but I get 
lost in thee BP/BPD/IPD/AT speak now and again, which is one reason I 
tend to stay out of the fray on that stuff. If I get confused--and 
choose to attempt to contribute to a discussion--I'll speak up about 
anything that strikes my fancy. If there's something I don't get... 
I'll search Google first.

BTW, since it is relevant here, thanks for your kind comments last 
week in
another thread. You are ever the peacemaker, a very useful role. As 
long as
the differences remain as great as they are, we *need* more than one FO
implementation. In the meantime, I am much more useful and productive
outside of FOP than I am in it, and, the FOP developers probably are 
also.

To my perhaps still naive mind, layout consists of exactly two tasks: 
1)
finding line-breaks within logical blocks (nested blocks consisting of 
a new
logical block), and 2) finding page-breaks between and within logical
blocks. All other tasks can be conveniently handled within the two data
structures, not being dependent on any strategy. The Knuth-style 
algorithm
is by definition a total-fit algorithm. The scope of such an algorithm 
for
the first task is the logical block itself. The scope of the second 
task is
the page-sequence. So, to implement a Knuth-style algorithm (itself a 
good
idea) for item 2, requires the ability to see an entire page-sequence 
in the
AreaTree at one time. I am a little confused about whether FOP's 
design will
even allow that to happen right now. I understood both Keiron's and 
Finn's
design ideas (and Peter West's also) to be releasing pages from the 
AreaTree
long before a page-sequence was even completely parsed. However, I may 
have
misunderstood, especially Finn's, which I am especially fuzzy on.

I read somewhere that Peter Karow was going to try to implement a
Knuth-style algorithm for URW, and I have tried desperately and
unsuccessfully to get a copy of his book on the topic. If anybody 
knows that
status of that effort or how to find his out-of-print books, please 
let us
know.
Might these links help:
http://www.google.com/search?hl=en&q=Peter+Karow+book&spell=1
http://www.amazon.com/exec/obidos/ISBN%3D0387572236/102-3161708-3958541
http://www.amazon.com/exec/obidos/ISBN%3D0387565094/102-3161708-3958541
The general approach that FOray hopes to take eventually is a first-fit
algorithm for the initial pass through a page-sequence, then a second
optimization look that I hope to make do a Knuth-style evaluation. 
That may
be sub-optimal, but it is my best guess right now about a reasonable 
way to
proceed.

Victor Mote
Thanks again for the explanation! Cheers!
Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

RE: Page breaking [was: Markers added to the wrong page]

[Victor Mote]

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 of resources, we could make 
> non-Knuth the default, and enable Knuth via a config file.

Hi Clay:

The good news is that this is an excellent idea. The bad news is that FOP's
determination to not even tolerate more than one algorithm is what drove FOP
and FOray apart. So you have stumbled in to a somewhat sensitive area, which
might explain the absence of responses (so far).

BTW, since it is relevant here, thanks for your kind comments last week in
another thread. You are ever the peacemaker, a very useful role. As long as
the differences remain as great as they are, we *need* more than one FO
implementation. In the meantime, I am much more useful and productive
outside of FOP than I am in it, and, the FOP developers probably are also.

To my perhaps still naive mind, layout consists of exactly two tasks: 1)
finding line-breaks within logical blocks (nested blocks consisting of a new
logical block), and 2) finding page-breaks between and within logical
blocks. All other tasks can be conveniently handled within the two data
structures, not being dependent on any strategy. The Knuth-style algorithm
is by definition a total-fit algorithm. The scope of such an algorithm for
the first task is the logical block itself. The scope of the second task is
the page-sequence. So, to implement a Knuth-style algorithm (itself a good
idea) for item 2, requires the ability to see an entire page-sequence in the
AreaTree at one time. I am a little confused about whether FOP's design will
even allow that to happen right now. I understood both Keiron's and Finn's
design ideas (and Peter West's also) to be releasing pages from the AreaTree
long before a page-sequence was even completely parsed. However, I may have
misunderstood, especially Finn's, which I am especially fuzzy on.

I read somewhere that Peter Karow was going to try to implement a
Knuth-style algorithm for URW, and I have tried desperately and
unsuccessfully to get a copy of his book on the topic. If anybody knows that
status of that effort or how to find his out-of-print books, please let us
know.

The general approach that FOray hopes to take eventually is a first-fit
algorithm for the initial pass through a page-sequence, then a second
optimization look that I hope to make do a Knuth-style evaluation. That may
be sub-optimal, but it is my best guess right now about a reasonable way to
proceed.

Victor Mote

Re: Page breaking [was: Markers added to the wrong page]

[The Web Maestro]

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 happy 
to
join in this conversation.
I rarely find myself feeling the urge to enter these conversations 
(it's not really my forte), but every now and then, I find I might 
offer an idea or two I think (hope) will be constructive...

The algorithm that the PageLM uses are a slightly modified knuth (no
need to maintain fitnessclass, and with the ability to decide on a 
break
when there is N pages of lookahead). The elements return from the LMs
are boxes (for lines), spaces and penalties.
Note that using the box - penalty - glue representation does not
necessarily involve using Knuth's algorithm.
A first-fit (or best-fit) algorithm could be enough in most situations;
and if there are no adjustable elements in the fo document (for exaple,
lots of paragraphs without adjustable spaces between them) Knuth's
algorithm becomes a best-fit.
Given its higher cost, maybe it could be used only when it could really
produce a better output.
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 
resources, we could make non-Knuth the default, and enable Knuth via a 
config file.

The elements are not
returned from the LMs but pushed from the LM into the pageLM:
   parent.generateElement(new Space(resolveBefore());
   parent.generateElement(new Box(lineHeigth);
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 can be a page break between the lines
generated by innerBlock1 and innerBlock2, we must know:
- if inner block 1 has keep-with-next
- if inner block 2 has keep-with-previous
- if outer block has keep-together
This can be done if the outer BlockLM calls receives the elements 
created
by its child, looks at them and adds / removes / corrects; could this 
be
done if the inner BlockLMs directly give their element to the top-level
LM?

BTW, what about your great refactoring of all the knuth code?
Regards,
Luca
Cheers!
Web Maestro Clay
--
<[EMAIL PROTECTED]> - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Re: Page breaking [was: Markers added to the wrong page]

[Finn Bock]

[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 can be a page break between the lines
generated by innerBlock1 and innerBlock2, we must know:
- if inner block 1 has keep-with-next
- if inner block 2 has keep-with-previous
- if outer block has keep-together
This can be done if the outer BlockLM calls receives the elements created
by its child, looks at them and adds / removes / corrects; could this be
done if the inner BlockLMs directly give their element to the top-level
LM?
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.

BTW, what about your great refactoring of all the knuth code?
I do not have the time atm to do the followup and bugfixes, so it will 
have to wait. If anyone also wants to commit it, feel free.

regards,
finn

Re: Page breaking [was: Markers added to the wrong page]

[Luca Furini]

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 happy to
join in this conversation.

>The algorithm that the PageLM uses are a slightly modified knuth (no
>need to maintain fitnessclass, and with the ability to decide on a break
>when there is N pages of lookahead). The elements return from the LMs
>are boxes (for lines), spaces and penalties.

Note that using the box - penalty - glue representation does not
necessarily involve using Knuth's algorithm.
A first-fit (or best-fit) algorithm could be enough in most situations;
and if there are no adjustable elements in the fo document (for exaple,
lots of paragraphs without adjustable spaces between them) Knuth's
algorithm becomes a best-fit.
Given its higher cost, maybe it could be used only when it could really
produce a better output.

>The elements are not
>returned from the LMs but pushed from the LM into the pageLM:
>
>parent.generateElement(new Space(resolveBefore());
>parent.generateElement(new Box(lineHeigth);
>

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 can be a page break between the lines
generated by innerBlock1 and innerBlock2, we must know:
- if inner block 1 has keep-with-next
- if inner block 2 has keep-with-previous
- if outer block has keep-together
This can be done if the outer BlockLM calls receives the elements created
by its child, looks at them and adds / removes / corrects; could this be
done if the inner BlockLMs directly give their element to the top-level
LM?

BTW, what about your great refactoring of all the knuth code?

Regards,
Luca

Page breaking [was: Markers added to the wrong page]

[Finn Bock]

Simon Pepping wrote:
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 page
while they do not really end an area. Your hack is a hack indeed, but
from a quick inspection I would say that it properly marks the
overloaded nature of BPs.
I have written down a proposal for a different strategy of page break
decision. I put my description on the wiki,
http://wiki.apache.org/xmlgraphics-fop/PageLayout. I believe it serves
two goals:
1. Enabling smarter page break algorithms.
2. Simplifying the addAreas calls, and esp. its iteration over the
collected BPs.
I have not had time to implement this, and therefore also no time to
detect the flaws in my proposal. I would not mind if someone else
would implement it.
Hi Simon,
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.

The algorithm that the PageLM uses are a slightly modified knuth (no 
need to maintain fitnessclass, and with the ability to decide on a break 
when there is N pages of lookahead). The elements return from the LMs 
are boxes (for lines), spaces and penalties. The elements are not 
returned from the LMs but pushed from the LM into the pageLM:

   parent.generateElement(new Space(resolveBefore());
   parent.generateElement(new Box(lineHeigth);
The LMs also push start and end markers so that the order list of 
elements in the pageLM is actually a flattened tree and can be used 
directly for creation of areas (so no more Position tree). The exact 
same flattened tree is applied to inline.

The element are pushed to the pageLM during a non-recursive traversal of 
the LM-tree. The areas are created during a non-recursive traversal of 
the flattened elements tree. During area creation the parent LMs is kept 
in a external stack, at the end of page the stack represent the areas 
that is continued on the next page and stack is used as the starting 
point for creatin

A significant drawback is that a knuth based page break algorithm is 
difficult to explain and justify, just like it is difficult to explain 
why line breaking knuth do as it do by looking at individual lines in 
the output.

regards,
finn

Re: Markers added to the wrong page

[Jeremias Maerki]

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 and intrusion. Your approach seems to create BPs in advance of
which some might be discarded because of later decisions. These will
then be rebuilt based on different circumstances.

I'm somewhat torn between a project plan I have to follow and doing
things right the first time. So I'll apply my changes for now and I'll
keep the whole thing on my todo list with a big exclamation mark. It
could very well be that because of my next tasks (tables and keeps) I
will get back to this sooner rather than later. Another aspect here: I'd
like to have some well visible improvements to the code quickly so it
shows to the outside that the project's not dead like many users think.

We'll see what happens. Thanks for your input and I hope you'll find
some time soon to do some coding yourself.

On 06.02.2005 22:08:40 Simon Pepping wrote:
> 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 page
> while they do not really end an area. Your hack is a hack indeed, but
> from a quick inspection I would say that it properly marks the
> overloaded nature of BPs.
> 
> I have written down a proposal for a different strategy of page break
> decision. I put my description on the wiki,
> http://wiki.apache.org/xmlgraphics-fop/PageLayout. I believe it serves
> two goals:
> 1. Enabling smarter page break algorithms.
> 2. Simplifying the addAreas calls, and esp. its iteration over the
> collected BPs.
> 
> I have not had time to implement this, and therefore also no time to
> detect the flaws in my proposal. I would not mind if someone else
> would implement it.
> 
> Regards, Simon
> 
> On Thu, Feb 03, 2005 at 06:19:29PM +0100, Jeremias Maerki wrote:
> > Team, 
> > 
> > I've just checked in markers5a and markers5b which look very closely
> > which marker is added to which page for every block.
> > 
> > As I'm still somewhat 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 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 these BreakPoss
> > instances which aren't visible in the generated document but are still
> > generating an (empty) Area (on the page preceeding the one where the
> > Area will really come to rest). That causes one marker too many to be
> > added to a page.
> > 
> > The same BTW applies to addID() calls which also remembers IDs on the
> > wrong pages.
> > 
> > What I'm currently doing is trying to really (!) understand the whole
> > BreakPoss mechanism so I can figure out a reliable way to find out how
> > to avoid this bug. Two possibilities:
> > 1. Don't generate bogus areas at all.
> > 2. Just suppress addMarkers() and addID().
> > 
> > I'm currently wondering if the generated BreakPoss instances should get
> > an additional flag (or two) which controls the generation of the area
> > and the addMarkers()/addID() calls. addMarkers()/addID() may be
> > necessary in certain circumstances while on the other side no area is
> > generated (empty block with only markers).
> > 
> > You can easily see these bogus areas when you output to the area tree
> > renderer or in build/test-results/layoutengine when running the Ant
> > build.
> > 
> > I'll continue investigating but would appreciate any ideas you might
> > have.
> > 
> > Jeremias Maerki
> > 
> 
> -- 
> Simon Pepping
> home page: http://www.leverkruid.nl



Jeremias Maerki

Re: Markers added to the wrong page

[Simon Pepping]

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 page
while they do not really end an area. Your hack is a hack indeed, but
from a quick inspection I would say that it properly marks the
overloaded nature of BPs.

I have written down a proposal for a different strategy of page break
decision. I put my description on the wiki,
http://wiki.apache.org/xmlgraphics-fop/PageLayout. I believe it serves
two goals:
1. Enabling smarter page break algorithms.
2. Simplifying the addAreas calls, and esp. its iteration over the
collected BPs.

I have not had time to implement this, and therefore also no time to
detect the flaws in my proposal. I would not mind if someone else
would implement it.

Regards, Simon

On Thu, Feb 03, 2005 at 06:19:29PM +0100, Jeremias Maerki wrote:
> Team, 
> 
> I've just checked in markers5a and markers5b which look very closely
> which marker is added to which page for every block.
> 
> As I'm still somewhat 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 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 these BreakPoss
> instances which aren't visible in the generated document but are still
> generating an (empty) Area (on the page preceeding the one where the
> Area will really come to rest). That causes one marker too many to be
> added to a page.
> 
> The same BTW applies to addID() calls which also remembers IDs on the
> wrong pages.
> 
> What I'm currently doing is trying to really (!) understand the whole
> BreakPoss mechanism so I can figure out a reliable way to find out how
> to avoid this bug. Two possibilities:
> 1. Don't generate bogus areas at all.
> 2. Just suppress addMarkers() and addID().
> 
> I'm currently wondering if the generated BreakPoss instances should get
> an additional flag (or two) which controls the generation of the area
> and the addMarkers()/addID() calls. addMarkers()/addID() may be
> necessary in certain circumstances while on the other side no area is
> generated (empty block with only markers).
> 
> You can easily see these bogus areas when you output to the area tree
> renderer or in build/test-results/layoutengine when running the Ant
> build.
> 
> I'll continue investigating but would appreciate any ideas you might
> have.
> 
> Jeremias Maerki
> 

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Markers added to the wrong page

[Glen Mazza]

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 it checks the
> parent LM. 

Re: Markers added to the wrong page

[Jeremias Maerki]

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 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 1 which is wrong.

I think I'll commit my patch as is tomorrow. This will solve the problem
for now, but I have a feeling that I might have to do some additional
work on the BreakPoss part quite soon when I get to tasks such as keeps
which is quite soon now. The isBogus() method is easily removed if it
turns up later that it can be handled differently and in a better way.

On 06.02.2005 04:43:48 Glen Mazza wrote:
> 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
> instead--perhaps just commenting the conditional that
> bogus areas are being ignored--and we can worry about
> getting rid of the actual bogus areas later (when
> overall team grokkage in this part of the code
> improves).
> 
> Glen
> 
> --- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> 
> > 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.
> > 
> > IMO it would be nicer if these "bogus" areas as I
> > call them wouldn't be
> > constructed at all. I experimented with such an
> > approach but the code
> > got far too complicated with too much
> > copy/paste/modify. And I also
> > didn't manage to make it work. On the other side
> > these special areas
> > are not a big problem since there are relatively few
> > of them.
> > 
> > Still interested in opinions and ideas Thanks!
> > 



Jeremias Maerki

Re: Markers added to the wrong page

[Glen Mazza]

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
instead--perhaps just commenting the conditional that
bogus areas are being ignored--and we can worry about
getting rid of the actual bogus areas later (when
overall team grokkage in this part of the code
improves).

Glen

--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> 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.
> 
> IMO it would be nicer if these "bogus" areas as I
> call them wouldn't be
> constructed at all. I experimented with such an
> approach but the code
> got far too complicated with too much
> copy/paste/modify. And I also
> didn't manage to make it work. On the other side
> these special areas
> are not a big problem since there are relatively few
> of them.
> 
> Still interested in opinions and ideas Thanks!
> 

Re: Markers added to the wrong page

[Glen Mazza]

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 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.
> 

Re: Markers added to the wrong page

[Jeremias Maerki]

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.

IMO it would be nicer if these "bogus" areas as I call them wouldn't be
constructed at all. I experimented with such an approach but the code
got far too complicated with too much copy/paste/modify. And I also
didn't manage to make it work. On the other side these special areas
are not a big problem since there are relatively few of them.

Still interested in opinions and ideas Thanks!


On 03.02.2005 18:19:29 Jeremias Maerki wrote:
> Team, 
> 
> I've just checked in markers5a and markers5b which look very closely
> which marker is added to which page for every block.
> 
> As I'm still somewhat 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 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 these BreakPoss
> instances which aren't visible in the generated document but are still
> generating an (empty) Area (on the page preceeding the one where the
> Area will really come to rest). That causes one marker too many to be
> added to a page.
> 
> The same BTW applies to addID() calls which also remembers IDs on the
> wrong pages.
> 
> What I'm currently doing is trying to really (!) understand the whole
> BreakPoss mechanism so I can figure out a reliable way to find out how
> to avoid this bug. Two possibilities:
> 1. Don't generate bogus areas at all.
> 2. Just suppress addMarkers() and addID().
> 
> I'm currently wondering if the generated BreakPoss instances should get
> an additional flag (or two) which controls the generation of the area
> and the addMarkers()/addID() calls. addMarkers()/addID() may be
> necessary in certain circumstances while on the other side no area is
> generated (empty block with only markers).
> 
> You can easily see these bogus areas when you output to the area tree
> renderer or in build/test-results/layoutengine when running the Ant
> build.
> 
> I'll continue investigating but would appreciate any ideas you might
> have.
> 
> Jeremias Maerki



Jeremias Maerki


MarkerFixProposal.diff.txt
Description: Binary data

Markers added to the wrong page

[Jeremias Maerki]

Team, 

I've just checked in markers5a and markers5b which look very closely
which marker is added to which page for every block.

As I'm still somewhat 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 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 these BreakPoss
instances which aren't visible in the generated document but are still
generating an (empty) Area (on the page preceeding the one where the
Area will really come to rest). That causes one marker too many to be
added to a page.

The same BTW applies to addID() calls which also remembers IDs on the
wrong pages.

What I'm currently doing is trying to really (!) understand the whole
BreakPoss mechanism so I can figure out a reliable way to find out how
to avoid this bug. Two possibilities:
1. Don't generate bogus areas at all.
2. Just suppress addMarkers() and addID().

I'm currently wondering if the generated BreakPoss instances should get
an additional flag (or two) which controls the generation of the area
and the addMarkers()/addID() calls. addMarkers()/addID() may be
necessary in certain circumstances while on the other side no area is
generated (empty block with only markers).

You can easily see these bogus areas when you output to the area tree
renderer or in build/test-results/layoutengine when running the Ant
build.

I'll continue investigating but would appreciate any ideas you might
have.

Jeremias Maerki

RE: Absent markers throw a ClassCastException in LineLM

[Andreas L. Delmelle]

> -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()
> > line 409:

>
> All LMs which are a child of LineLM should implement
> InlineLevelLM. LineLM collects all child LMs of a block which generate
> inline areas, and indeed, generating inline areas should be synonym
> with implementing InlineLevelLM. This presumes that there is a strict
> separation between block and inline area generating LMs.
>
> For RetrieveMarkerLM that separation is not so clear. I think it has
> to implement InlineLevelLM, otherwise it cannot act as a child of
> LineLM, at the penalty that you noticed.
>

Thanks for the pointer. It sure is a very interesting puzzle... since in
essence it is replaced by the children of the fo:marker, which can be
inlines as well as blocks (theoretically even one or more fo:table
structures :-/)

Greetz,

Andreas

Re: Absent markers throw a ClassCastException in LineLM

[Simon Pepping]

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
> (bugzilla 31206), I get a ClassCastException in LineLM.getNextBreakPoss()
> line 409:
> 
> while((curLM = (InlineLevelLayoutManager) getChildLM()) != null)
> 
> This seems to be due to an fo:retrieve-marker that cannot find a
> corresponding fo:marker in the current page, since I get the message
> 
> found no marker with name: {marker-class-name}
> 
> immediately before the Exception is thrown.

Before committing Luca's patch I noticed the same problem with
BasicLinkLM. There the solution was to make BasicLinkLM extend
InlineLM, so that it implements InlineLevelLM.

All LMs which are a child of LineLM should implement
InlineLevelLM. LineLM collects all child LMs of a block which generate
inline areas, and indeed, generating inline areas should be synonym
with implementing InlineLevelLM. This presumes that there is a strict
separation between block and inline area generating LMs.

For RetrieveMarkerLM that separation is not so clear. I think it has
to implement InlineLevelLM, otherwise it cannot act as a child of
LineLM, at the penalty that you noticed.

Regards, Simon
 
-- 
Simon Pepping
home page: http://www.leverkruid.nl

RE: Absent markers throw a ClassCastException in LineLM

[Andreas L. Delmelle]

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?)
> 

Absent markers throw a ClassCastException in LineLM

[Andreas L. Delmelle]

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 409:

while((curLM = (InlineLevelLayoutManager) getChildLM()) != null)

This seems to be due to an fo:retrieve-marker that cannot find a
corresponding fo:marker in the current page, since I get the message

found no marker with name: {marker-class-name}

immediately before the Exception is thrown.

Example FO in attach (minimized version with a fo:retrieve-marker, without
fo:marker)

(In the complete version of my test, indirectly this is caused by the
break-before/break-after properties that aren't working, but this is besides
the point...)

Anybody have an idea on how to fix this? Just a warning would be more than
enough (certainly preferable to FOP crashing over it :-) )


Greetz,

Andreas

http://www.w3.org/1999/XSL/Format"; xmlns:fox="http://xml.apache.org/fop/extensions";>
   
 
 
 
 
  
  
 
  
  
 
  
   
   
  
 
   
 
  
  
 
   Blabla
 
  
   

Re: Markers

[Chris Bowditch]

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,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 is added to page 1, then
subsequently the childLMs signal a BP, maybe breaking the page, but
certainly leaving the marker where it was initially added.
No, because as you say above addAreas is being called and this doesnt not 
generate BPs, BPs are generated by the getNextBreakPoss method on each LM. 
This is why I am puzzled, the page boundaries are decided when the 
getNextBreakPoss methods are called. By the time, addArea methods are called, 
the page boundaries have already been decided


Chris

RE: Markers

[Andreas L. Delmelle]

> -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 mistaken, but looking at the code, it seems the break-before
property is broken as well ...?


Greetz,

Andreas

RE: Markers

[Andreas L. Delmelle]

> -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 this possible?
>
> Any thoughts will be appreciated?
>

Just gathering my thoughts here...

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,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 is added to page 1, then
subsequently the childLMs signal a BP, maybe breaking the page, but
certainly leaving the marker where it was initially added.

Maybe sheds some light on the situation. As to what needs to be done to fix
it... no particular idea for the moment.


Cheers,

Andreas

Markers

[Chris Bowditch]

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 been processed and 
the areas are about to be rendered. So how is this possible?

Any thoughts will be appreciated?
Thanks,
Chris

cvs commit: xml-fop/examples/fo/markers hide.fo glossary.xml glossary.xsl

[pbwest]

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   +0 -0  xml-fop/examples/fo/markers/hide.fo
  
  Index: hide.fo
  ===
  RCS file: /home/cvs/xml-fop/examples/fo/markers/hide.fo,v
  retrieving revision 1.2
  retrieving revision 1.2.2.1
  diff -u -r1.2 -r1.2.2.1
  
  
  
  1.2.2.1   +0 -0  xml-fop/examples/fo/markers/glossary.xml
  
  Index: glossary.xml
  ===
  RCS file: /home/cvs/xml-fop/examples/fo/markers/glossary.xml,v
  retrieving revision 1.2
  retrieving revision 1.2.2.1
  diff -u -r1.2 -r1.2.2.1
  
  
  
  1.2.2.1   +0 -0  xml-fop/examples/fo/markers/glossary.xsl
  
  Index: glossary.xsl
  ===
  RCS file: /home/cvs/xml-fop/examples/fo/markers/glossary.xsl,v
  retrieving revision 1.2
  retrieving revision 1.2.2.1
  diff -u -r1.2 -r1.2.2.1
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Thoughts on design - FO expressions in markers

[Peter B. West]

Fopdevs,

Further to this topic.

Peter B. West wrote:
Yes, and this whole post was a bit of a disaster. The point I had 
fuzzily in mind was that the resolution of marker properties can only 
occur as the area tree (of the fo:flow) is being constructed.  Only then 
does "current page" have any 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 
parsing.  FoXMLEvents are pulled from buffer on demand, and processed 
into the FO Tree.

2) shows my original vague idea for handling fo:markers.  Because there 
is no context for resolving fo:marker properties where they are 
encountered in the fo:flow, I was intending to divert the FoXMLEvents 
into named buffers for later processing in a manner parallel to the 
mainstream XML event processing.

3) represents the problem of reconciling a pre-built FO static-content 
sub-tree with a buffer of FoXMLEvents representing the fo:marker, within 
the overall context of the construction of the static region area sub-trees.

4) represents a solution in conjunction with 2).  Viz., divert not only 
the fo:marker subtrees from the fo:flows into FoXMLEvent buffers, but 
also the whole of each fo:static-content subtree.  As Joerg pointed out, 
the size of the static regions is fixed, so they have no impact on the 
layout of the region-body.  (Let me know if I'm missing something here.) 
 Furthermore, if they contain an fo:retrieve-markers, the resolution of 
the static content region is "dymanic" to the extent of the markers 
being retrieved.

The general solution is represented by 5).  The whole of the 
static-content subtree is processed as the area tree for that region is 
being built, and after the region-body has been laid out.  As 
fo:retrieve-markers are encountered in the stream of events, they are 
resolved with reference to the current and previous pages, and the 
appropriate fo:marker buffer becomes the reference for events.  The 
existing mechanism for obtaining events can readily be generalised to 
query the appropriate buffer.  Where a static-content sub-tree has no 
fo:retrieve-markers, the optimisation is obviously to resolve the 
sub-tree once.

The most interesting point here is that the processing of the FO 
sub-tree is driven from within the construction of the relevant area 
sub-tree.  I am increasingly of the opinion that such should be the 
general approach to all FO tree handling - that it should be 
demand-driven by the construction of the area tree.  I haven't 
considered thsi in enough detail to be more definite that that yet.

Peter
--
Peter B. West  http://www.powerup.com.au/~pbwest/resume.html
<>-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Keiron Liddle]

> 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 retrieve m1 or m2?
> I'd think m2.

The area from block A will always be a parent of the area from block B. So surely 
that after block B ends then the containing block A will end. The forced break only 
tells us that we should force a break at that position otherwise it is the same as a 
normal break.

>   
> 
> 
>   
>   ...
> 
>   
> Does last-ending-within-page retrieve m1 or m2?
> Probably m1, but where in the spec can I find backing for this
> opinion?

Look in 4.2.5 Stacking constraints.
In the diagram case 2, A is before B. So that in your example the after edge of 
block A is after the after edge of block B, so m1.

Keiron

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Tony Graham]

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
 >   
 > 
 > 
 >   
 >   ...
 > 
 >   
 > Does last-ending-within-page retrieve m1 or m2?
 > I'd think m2.

So do I.

 >   
 > 
 > 
 >   
 >   ...
 > 
 >   
 > 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 3x(70)19708

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[J.Pietschmann]

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
 
   
   
 
 ...
   
 
Does last-ending-within-page retrieve m1 or m2?
I'd think m2.
 
   
   
 
 ...
   
 
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Peter B. West]

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:
 
   
   
 
 ...
   
 
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  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[J.Pietschmann]

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:
 
   
   
 
 ...
   
 
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
 
   
   
 
 ...
   
 
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Peter B. West]

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 that much code any-way, it is mainly a 
matter of getting the logic right.

When we know how it definitely should work then we can adjust it if necessary.
Keiron,

I have a couple of notes concerning markers in my posting on alt.design 
integration.  What helped me in coming to terms with them was 
considering the simple usage of dictionary headings.  The static-content 
will be the same on every page, extracting the first and last words 
defined on the page.  On every page, though, the result will be different.

I don't have the imagination for use cases for other situations, but one 
can easily envisage a case where page n and page n+1 retrieve the same 
marker; page n from the containing-page, and page n+1 from the previous 
page.
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Keiron Liddle]

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, it is mainly a 
matter of getting the logic right.

When we know how it definitely should work then we can adjust it if necessary.


Keiron.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Peter B. West]

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 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 agreeing then that if it cannot find it on the current page it should look an 
the previous page and so on, or does this transposing do something else.
I agree.  In that case, the transposition is from the fo:marker subtree 
on a previous page.


Another point, why have this statement:
"A qualifying area within a page is better than any qualifying area within a 
preceding page,"
Unless it is possible that if there is no qualifying marker on the current page 
then it 

is possible to retrieve a marker from a preceding page.
Yes, it is possible, but again, the qualifying marker on a previous page 
will be transposed to the containing page - the page whose 
fo:retrieve-marker started all the trouble.

The rest of the above-quoted sentence, following the comma, is:
"...except that areas do not have a position in the hierarchy if they 
are within pages that follow the containing page."  In my reading, the 
implication is that the containing page is an absolute point of 
reference - the page in which the fo:retrieve-marker accurs.


Yes, one of the many contradictions. I presume you mean where the fo:retrieve-
marker is replaced with the retrieved marker (since it occurs on every page with 
that static content).
Yes.  It occurs on every page, but for every page the replacement 
fo:marker has to be recalculated.  The process is particular to each 
fo:retrieve-marker on each page.

--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Keiron Liddle]

> 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 from a previous page are not attached to areas in the 
containing page.

Are you agreeing then that if it cannot find it on the current page it should look an 
the previous page and so on, or does this transposing do something else.

> > Another point, why have this statement:
> > "A qualifying area within a page is better than any qualifying area within a 
> > preceding page,"
> > Unless it is possible that if there is no qualifying marker on the current page 
then it 
> > is possible to retrieve a marker from a preceding page.
> 
> Yes, it is possible, but again, the qualifying marker on a previous page 
> will be transposed to the containing page - the page whose 
> fo:retrieve-marker started all the trouble.
> 
> The rest of the above-quoted sentence, following the comma, is:
> "...except that areas do not have a position in the hierarchy if they 
> are within pages that follow the containing page."  In my reading, the 
> implication is that the containing page is an absolute point of 
> reference - the page in which the fo:retrieve-marker accurs.

Yes, one of the many contradictions. I presume you mean where the fo:retrieve-
marker is replaced with the retrieved marker (since it occurs on every page with 
that static content).





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Peter B. West]

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 containing page is the page where the first, and indeed all areas
generated by the marker after such a retrieval will occur.


Do you mean the page where the current retrieve-marker will retrieve the current 
marker and add the area(s). Which we could call the current page for 
convenience.
Yes.  But really we should call it the "containing page".  Conceptually, 
the fo:marker and its children replace the invoking fo:retrieve-marker. 
 The point of a particular fo:retrieve-marker is fixed, so the point of 
expansion of the retrieved fo:marker is fixed, whereas the actual 
fo:marker that will be retrieved is not fixed.

So what happens if there is no marker on the current page but there was a 
marker on the previous page. This marker on the previous page generated or 
retruned the first area from the retrieved marker and therefore is the "containing 
page" in some context.

But the marker subtree from the previous page is tranposed into the same 
"containing page".

Another point, why have this statement:
"A qualifying area within a page is better than any qualifying area within a 
preceding page,"
Unless it is possible that if there is no qualifying marker on the current page then it 
is possible to retrieve a marker from a preceding page.
Yes, it is possible, but again, the qualifying marker on a previous page 
will be transposed to the containing page - the page whose 
fo:retrieve-marker started all the trouble.

The rest of the above-quoted sentence, following the comma, is:
"...except that areas do not have a position in the hierarchy if they 
are within pages that follow the containing page."  In my reading, the 
implication is that the containing page is an absolute point of 
reference - the page in which the fo:retrieve-marker accurs.
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Keiron Liddle]

> 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 where the first, and indeed all areas
> generated by the marker after such a retrieval will occur.

Do you mean the page where the current retrieve-marker will retrieve the current 
marker and add the area(s). Which we could call the current page for 
convenience.
So what happens if there is no marker on the current page but there was a 
marker on the previous page. This marker on the previous page generated or 
retruned the first area from the retrieved marker and therefore is the "containing 
page" in some context.

Another point, why have this statement:
"A qualifying area within a page is better than any qualifying area within a 
preceding page,"
Unless it is possible that if there is no qualifying marker on the current page then 
it 
is possible to retrieve a marker from a preceding page.

> There is no such concept of a page where a certain FO occurs, in particular
> if static content is involved, which is necessarily the case if the FO
> is a retrieve-marker.
> 
> > I vote for a clarification and a re-write, the containing page is defined by the 
> > retrieved marker, the marker to retrieve is defined by the containing page.
> The formulation is indeed most contrived, but there is only one reasonable
> possibility to get out of the circle.
> 
> I admit I have no really good idea how to reformulate the whole mess.
> 
> BTW there are attempts on EXSLFO to muddy this issue further by
> allowing retrieve-marker in the normal flow...
> 
> J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[J.Pietschmann]

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 where the first, and indeed all areas
generated by the marker after such a retrieval will occur.
There is no such concept of a page where a certain FO occurs, in particular
if static content is involved, which is necessarily the case if the FO
is a retrieve-marker.
I vote for a clarification and a re-write, the containing page is defined by the 
retrieved marker, the marker to retrieve is defined by the containing page.
The formulation is indeed most contrived, but there is only one reasonable
possibility to get out of the circle.
I admit I have no really good idea how to reformulate the whole mess.

BTW there are attempts on EXSLFO to muddy this issue further by
allowing retrieve-marker in the normal flow...
J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: markers in redesign

[Arved Sandstrom]

> -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 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 re-layout.
>
> 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.

That's now my opinion also, after my re-read. I made the other assumption
based on the obfuscated language.

> I vote for a clarification and a re-write, the containing page is
> defined by the
> retrieved marker, the marker to retrieve is defined by the
> containing page.

I think we can all agree on asking for a rewrite. :-)

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Keiron Liddle]

> 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 re-layout.

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.

I vote for a clarification and a re-write, the containing page is defined by the 
retrieved marker, the marker to retrieve is defined by the containing page.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Peter B. West]

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 relevance. In other 
words,
there is an elaborate set of definitions based on the current page, 
with a
hierarchy defined by "retrieve-position", but as soon as one establishes
that there is no such qualifying area on the current page, than it's just
the first qualifying area one can find, moving back in the document.


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 nothing in the spec which backs this, and I searched
thoroughly last weekend.
It's a worry.  I think the decision is a sensible extrapolation from the 
fact that, where pages are concerned, nearer is better.  However, it is 
clearly an oversight by the editors.  Has anyone written to them on this 
point?

BTW for the page sequence retrieving scope there is a "current page
sequence" casually mentioned but definition of the term is left to
imagination, in contrast to the meticulous definition of "current page".
Additionally, some oddball examples for discussion and fun:


 
   stuff
 


   stuff

Which one is the last?
Because the relevant context is the area tree, I would think that the 
footnote would be the last.
Similarly for
stuff

stuff

This one is trickier. It seems to me that the fact that out-of-line 
areas are defined to have no impact on the layout of normal areas might 
imply that such areas occupy a position in the area tree which is 
independent of their eventual position on the page.  That aspect is 
determined by the particular positioning properties of the fo, 
independently of the normal layout flow.  In that case, it would be 
tempting to assume that such areas are regarded as occurring in the area 
tree at the point of their definition.

If so, then, even though the second area 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 shall we go?"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Peter B. West]

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 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 nothing in the spec which backs this, and I searched
thoroughly last weekend.
For the current page or containing page I take it to mean like so
(assuming doc or
page-sequence boundary):
If we are on the third page of a document and we want to retrieve
a "first-starting-
within-page" then it will look on page 3, if it finds the marker
then fine. If not then
there is no such area (on the current page) and it should look at
page 2. Page 2 is
now the containing page and it looks for a marker that is
"first-starting-within-
page" on page 2. Then page 1...
Admitedly it doesn't actually say that, but I can't interpret the
wording otherwise.


[ SNIP ]

I re-read the spec so exhaustively that my eyes are burning. :-) I think
Keiron is right.
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 re-layout.

--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: markers in redesign

[Arved Sandstrom]

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 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 nothing in the spec which backs this, and I searched
> > thoroughly last weekend.
>
> For the current page or containing page I take it to mean like so
> (assuming doc or
> page-sequence boundary):
> If we are on the third page of a document and we want to retrieve
> a "first-starting-
> within-page" then it will look on page 3, if it finds the marker
> then fine. If not then
> there is no such area (on the current page) and it should look at
> page 2. Page 2 is
> now the containing page and it looks for a marker that is
> "first-starting-within-
> page" on page 2. Then page 1...
> Admitedly it doesn't actually say that, but I can't interpret the
> wording otherwise.

[ SNIP ]

I re-read the spec so exhaustively that my eyes are burning. :-) I think
Keiron is right.

Boy, it would be cool if they could rewrite that section, though. :-)

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Keiron Liddle]

> 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*?  Pre-order traversal gives us a, b, c.  So c "follows in the 
> area tree any other similarly constrained area.
> 
> Then the column break would have no impact on the selection.

I re-read that part and what you say makes sense now. It's all very confusing.

> It seems to me that the "hierarchy" is not the same as the area tree or 
> fo tree hierarchy.  It is a unique hierarchy constructed by applying the 
> constraints on the qualifying areas.  The boundary conditions impose 
> absolute constraints - violate one and you are out.  But the other 
> conditions are not absolute, and they, along with actual page for 
> multi-page boundaries, are used to construct the hierarchy.
> 
> I think.
> 
> Peter


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Keiron Liddle]

> 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 nothing in the spec which backs this, and I searched
> thoroughly last weekend.

For the current page or containing page I take it to mean like so (assuming doc or 
page-sequence boundary):
If we are on the third page of a document and we want to retrieve a "first-starting-
within-page" then it will look on page 3, if it finds the marker then fine. If not 
then 
there is no such area (on the current page) and it should look at page 2. Page 2 is 
now the containing page and it looks for a marker that is "first-starting-within-
page" on page 2. Then page 1...
Admitedly it doesn't actually say that, but I can't interpret the wording otherwise.

> BTW for the page sequence retrieving scope there is a "current page
> sequence" casually mentioned but definition of the term is left to
> imagination, in contrast to the meticulous definition of "current page".
> 
> Additionally, some oddball examples for discussion and fun:
> 
> 
>   
> stuff
>   
> 
> 
> stuff
> 

Isn't the footnote in an area that is after the main-reference area and hence last.

> Which one is the last?
> 
> Similarly for
>width="5cm" height="5cm>
>   stuff
> 
>width="5cm" height="5cm>
>   stuff
> 

Ordering stays, regardless of where it is drawn.


> J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Keiron Liddle]

> 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 traversal 
> order*?  Pre-order traversal gives us a, b, c.  So c "follows in the 
> area tree any other similarly constrained area.

So does b and c "follow" a, what is the definition of follows.
I agree with your reasoning but we are talking about the spec. Just that off-hand 
statement about every area being better than an area "below".
I think they need to explain the implications of what the definitions are.

If you think of last-starting as sort of the opposite of first-including-carryover 
(which doesn't need to have an is-last), then the parent "a" actually comes first. 
But that is only wild speculation.

> Then the column break would have no impact on the selection.
> 
> It seems to me that the "hierarchy" is not the same as the area tree or 
> fo tree hierarchy.  It is a unique hierarchy constructed by applying the 
> constraints on the qualifying areas.  The boundary conditions impose 
> absolute constraints - violate one and you are out.  But the other 
> conditions are not absolute, and they, along with actual page for 
> multi-page boundaries, are used to construct the hierarchy.
> 
> I think.
> 
> Peter


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[J.Pietschmann]

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 words,
there is an elaborate set of definitions based on the current page, with a
hierarchy defined by "retrieve-position", but as soon as one establishes
that there is no such qualifying area on the current page, than it's just
the first qualifying area one can find, moving back in the document.
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 nothing in the spec which backs this, and I searched
thoroughly last weekend.
BTW for the page sequence retrieving scope there is a "current page
sequence" casually mentioned but definition of the term is left to
imagination, in contrast to the meticulous definition of "current page".
Additionally, some oddball examples for discussion and fun:


 
   stuff
 


   stuff

Which one is the last?

Similarly for
stuff

stuff

J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[J.Pietschmann]

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
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
cases, and decided what made sense. :-)
Heresy! :-)

If we are discussing odd stuff, is it really true that the
blocks in a footnote body inherit the start-indent of the
block which contains the footnote? Actually, FOP does
this, and I can't find anything in the spec providing for
the contrary.
Same applies to side floats, thereby perhaps leading to
nice circularity problems...
J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: markers in redesign

[Arved Sandstrom]

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-
>  > > 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 unique hierarchy constructed by
> applying the
>  > > constraints on the qualifying areas.  The boundary conditions impose
>  > > absolute constraints - violate one and you are out.  But the other
>  > > conditions are not absolute, and they, along with actual page for
>  > > multi-page boundaries, are used to construct the hierarchy.
>  >
>  > Yes, that's my interpretation. Precisely so. It is tempting to confuse
>  > "hierarchy" for "tree". But the language of the spec in regard
> of markers
>  > defines a different hierarchy, one which happens to map
> closely to the area
>  > tree, but is highly filtered.
>
> It's not just areas.  fo:wrapper 'does not generate any areas', but
> also 'may always have a sequence of zero or more fo:markers as its
> initial children.'

No, you're quite right, Tony, fo:wrapper does not generate areas. But it
_returns_ areas, assuming that its children do (there are presumably some
pathological cases), and those areas are what markers act on. "wrapper" is
transparent.

I may have missed your point on this.

> ...
>  > 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
>
> I wasn't there when the spec was written, but it seems to me that
> 'currently-formatted page' presupposes making pages on the fly and
> doesn't quite describe pages that are unbounded in one or both
> directions (i.e. where there is only ever one page) and also doesn't
> describe the possible processing model of making all the pages from
> the fo:flow and then going back and fixing up the static content.

OK, you've got me here. :-) I fall into the trap of ignoring "media-usage"
too frequently. So the point is well taken.

Regarding the second point, that processing model ignores an
"error-if-overflow" value for "overflow"; process a thousand pages and then
only afterwards find out that you ought to have aborted with a message?

Regards,
Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: markers in redesign

[Tony Graham]

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 "hierarchy" is not the same as the area tree or
 > > fo tree hierarchy.  It is a unique hierarchy constructed by applying the
 > > constraints on the qualifying areas.  The boundary conditions impose
 > > absolute constraints - violate one and you are out.  But the other
 > > conditions are not absolute, and they, along with actual page for
 > > multi-page boundaries, are used to construct the hierarchy.
 > 
 > Yes, that's my interpretation. Precisely so. It is tempting to confuse
 > "hierarchy" for "tree". But the language of the spec in regard of markers
 > defines a different hierarchy, one which happens to map closely to the area
 > tree, but is highly filtered.

It's not just areas.  fo:wrapper 'does not generate any areas', but
also 'may always have a sequence of zero or more fo:markers as its
initial children.'

...
 > 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

I wasn't there when the spec was written, but it seems to me that
'currently-formatted page' presupposes making pages on the fly and
doesn't quite describe pages that are unbounded in one or both
directions (i.e. where there is only ever one page) and also doesn't
describe the possible processing model of making all the pages from
the fo:flow and then going back and fixing up the static content.

Regards,


Tony Graham

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Peter B. West]

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 with area traits (and the traits
are easy to establish) to figure out the best qualifier on the _current_
page.
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 words,
there is an elaborate set of definitions based on the current page, with a
hierarchy defined by "retrieve-position", but as soon as one establishes
that there is no such qualifying area on the current page, than it's just
the first qualifying area one can find, moving back in the document.
I suppose that one way of looking at this is that retrieve-position is 
inherently this-page based, and that to try to extend the 
retrieve-position logic in a consistent way to, say, previous page, 
would add a layer of some complication.  The easy solution is to declare 
that, if you blew it with the retrieve-position properties, all bets are 
off, and we go into emergency mode.

--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: markers in redesign

[Arved Sandstrom]

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 unique hierarchy constructed by applying the
> constraints on the qualifying areas.  The boundary conditions impose
> absolute constraints - violate one and you are out.  But the other
> conditions are not absolute, and they, along with actual page for
> multi-page boundaries, are used to construct the hierarchy.

Yes, that's my interpretation. Precisely so. It is tempting to confuse
"hierarchy" for "tree". But the language of the spec in regard of markers
defines a different hierarchy, one which happens to map closely to the area
tree, but is highly filtered.

I re-assert that in the case of this particular section of the spec, we can
fall back on common sense, although normally I am loath to do so (it may
sound funny to hear that, but I am a professional software developer, and
I'd rather follow the letter than the spirit. That approach usually assures
better code, and better specs). That means to me that in this case we use
the use cases in the spec to identify what makes sense. Markers are amenable
to this, as opposed to "reference-orientation", because the latter is an
artificial concept, and several interpretations may apply.

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 with area traits (and the traits
are easy to establish) to figure out the best qualifier on the _current_
page.

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 words,
there is an elaborate set of definitions based on the current page, with a
hierarchy defined by "retrieve-position", but as soon as one establishes
that there is no such qualifying area on the current page, than it's just
the first qualifying area one can find, moving back in the document.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Peter B. West]

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 similarly for the document boundary.

I'm trying to work out exactly how the markers should work.
For the first starting within page and last ending I am fine with. First including 
carry-over seems okay.

Last starting within page is a bit confusing. A statement [1] in the spec suggests 
that it shouldn't really find the last starting in the page but rather find the closest 
node to the root in the area tree that is the last starting area. Another statement [2] 
seems confusing but maybe this is if it is searching previous pages.

So if this was in a page then block "a" would be the last starting in the page.

-start--
...

  
  
---pos1-
  
  

end---
But if there is a column break in pos1 the last starting in page will become 
block "c" as block "a" is not starting in that part of the area tree.
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 traversal 
order*?  Pre-order traversal gives us a, b, c.  So c "follows in the 
area tree any other similarly constrained area.

Then the column break would have no impact on the selection.

It seems to me that the "hierarchy" is not the same as the area tree or 
fo tree hierarchy.  It is a unique hierarchy constructed by applying the 
constraints on the qualifying areas.  The boundary conditions impose 
absolute constraints - violate one and you are out.  But the other 
conditions are not absolute, and they, along with actual page for 
multi-page boundaries, are used to construct the hierarchy.

I think.

Peter

If this is the case then there are two possible cases when starting an area: isfirst 
and other. When finishing an area there are: islast, (had) isfirst and both. This will 
supply enough information to add only the needed markers to the area tree. These 
markers can then be kept for later retrieval.

[1] "Every area in the hierarchy is considered preferential to, or "better" than, any 
area below it in the hierarchy."

[2] "If there is no such area, then the last qualifying area in the containing page is 
better than any other area."
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: markers in redesign

[Arved Sandstrom]

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 "retrieve-boundary"
essentially defines the backward limits. Finally, "retrieve-boundary" also
restricts qualifying areas in the backward direction: "page" says that if
it's not on the currently being-formatted page, it isn't up for
consideration.

For "last-starting-within-page", "is-first" is clear enough I 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" in this context
means last geometrically, as opposed to some other "last". Eg, immediately
preceding as one normally reads a document.

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
cases, and decided 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 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 boundary.
>
> I'm trying to work out exactly how the markers should work.
> For the first starting within page and last ending I am fine
> with. First including
> carry-over seems okay.
>
> Last starting within page is a bit confusing. A statement [1] in
> the spec suggests
> that it shouldn't really find the last starting in the page but
> rather find the closest
> node to the root in the area tree that is the last starting area.
> Another statement [2]
> seems confusing but maybe this is if it is searching previous pages.
>
> So if this was in a page then block "a" would be the last
> starting in the page.
>
> -start--
> ...
> 
>   
>   
> ---pos1-
>   
>   
> 
> end---
>
> But if there is a column break in pos1 the last starting in page
> will become
> block "c" as block "a" is not starting in that part of the area tree.
>
> If this is the case then there are two possible cases when
> starting an area: isfirst
> and other. When finishing an area there are: islast, (had)
> isfirst and both. This will
> supply enough information to add only the needed markers to the
> area tree. These
> markers can then be kept for later retrieval.
>
> [1] "Every area in the hierarchy is considered preferential to,
> or "better" than, any
> area below it in the hierarchy."
>
> [2] "If there is no such area, then the last qualifying area in
> the containing page is
> better than any other area."
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: markers in redesign

[Keiron Liddle]

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 boundary.

I'm trying to work out exactly how the markers should work.
For the first starting within page and last ending I am fine with. First including 
carry-over seems okay.

Last starting within page is a bit confusing. A statement [1] in the spec suggests 
that it shouldn't really find the last starting in the page but rather find the 
closest 
node to the root in the area tree that is the last starting area. Another statement 
[2] 
seems confusing but maybe this is if it is searching previous pages.

So if this was in a page then block "a" would be the last starting in the page.

-start--
...

  
  
---pos1-
  
  

end---

But if there is a column break in pos1 the last starting in page will become 
block "c" as block "a" is not starting in that part of the area tree.

If this is the case then there are two possible cases when starting an area: isfirst 
and other. When finishing an area there are: islast, (had) isfirst and both. This will 
supply enough information to add only the needed markers to the area tree. These 
markers can then be kept for later retrieval.

[1] "Every area in the hierarchy is considered preferential to, or "better" than, any 
area below it in the hierarchy."

[2] "If there is no such area, then the last qualifying area in the containing page is 
better than any other area."

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Markers in areas

[Arved Sandstrom]

Well, Peter, no, I haven't written something this direct - yet. My trust in
their responsiveness is at an ebb; they don't answer much communication, of
any nature, quickly, so I doubt that they will answer a more critical email
at all.

FWIW I consider all of the editors to be way more experienced than me, when
it comes to documents, and publishing, and so forth. I don't equate that
with expertise in math, or programming, or technical writing. Number one,
trained technical writers should write technical docs - a whole bunch of W3C
recommendations prove that. _I_ am not very good at writing technical docs;
I get windy and abstruse. That's why I don't get paid to write docs. :-)

Every XSL-FO implementation has a different treatment of
"reference-orientation". I keep harping on this, I know. In fact, I think
_my_ interpretation is correct, and almost everyone else is wrong. I think
that because I read the English in the spec. I know that sounds arrogant,
but I have told the editors before that I'll implement according to the
letter, not the spirit. If they wish to argue that the language says
differently than what I think, that's their prerogative.

There is a better procedure for turning out specs. The W3C hasn't twigged.
Good companies in the industry already know it. It's invite the
customers/clients in, get them to hash things out with the programmers and
technical writers, and then let the latter two groups turn out 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 22, 2003 8:23 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Markers in areas
>
>
> 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
> support, so I
> > am only commenting from the viewpoint of my knowledge of the spec.
> >
> > I made a few comments in my reply to Joerg. I have a degree in
> physics, and
> > most of a Masters in physical oceanography. I see considerable
> mathematical
> > anarchy in the XSL spec, some degree of mathematical naivete,
> and lots of
> > confusion. My forte is not logic, based on my background, but
> even a physics
> > guy can dissect the pseudo-logic in that spec. I think plenty of other
> > people have also separated the wheat from the chaff as far as
> that document
> > is concerned...I think we are due for a rewrite, with lots of the
> > pretentious math excised, and replaced with plain language.
>
> Arved,
>
> Hear, hear.  Arved, have you told the editors this directly?  If not,
> please do.
>
> --
> Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
> "Lord, to whom shall we go?"
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Markers in areas

[Peter B. West]

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 support, so I
am only commenting from the viewpoint of my knowledge of the spec.
I made a few comments in my reply to Joerg. I have a degree in physics, and
most of a Masters in physical oceanography. I see considerable mathematical
anarchy in the XSL spec, some degree of mathematical naivete, and lots of
confusion. My forte is not logic, based on my background, but even a physics
guy can dissect the pseudo-logic in that spec. I think plenty of other
people have also separated the wheat from the chaff as far as that document
is concerned...I think we are due for a rewrite, with lots of the
pretentious math excised, and replaced with plain language.
Arved,

Hear, hear.  Arved, have you told the editors this directly?  If not, 
please do.

--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Markers in areas

[Peter B. West]

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 implementation use for. In
fact, I can't see any theoretical use for the idea either.
Arved,

I'm glad that I am not the only one who could see no purpose in the 
discussion of "lineage".  However, I'd like your comments on a couple of 
aspects of lineage.

The first of the two parts of the definition:

A set of nodes in a tree is a lineage if:
*  there is a node N in the set such that all the nodes in the set 
are ancestors of N, and


This seems a strange.

Normal areas represent areas in the "normal flow of text"; that 
is, they become area children of the areas generated by the formatting 
object to which they are returned. Normal areas have a returned-by 
lineage of size one.

I wondered about the point of all this, but in looking at the Errata, I 
found a series of modifications for the description of 'Areas' in the 
description of fo:bidi-override, fo:inline and fo:basic-link as follows:

Section 6.6.2

Replace:

in the "Areas:" portion "returns these areas, any page-level-out-of-line 
areas, and any reference-level-out-of-line areas returned by the children"

with

"returns these areas, together with any normal block-areas, 
page-level-out-of-line areas, and reference-level-out-of-line areas 
returned by the children"

It seesm to me that these changes create normal block areas with a 
lineage with size greater than one.

What do you think?

--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

markers in redesign

[Keiron Liddle]

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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Markers in areas

[J.Pietschmann]

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]
For additional commands, email: [EMAIL PROTECTED]

RE: Markers in areas

[Arved Sandstrom]

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 commenting from the viewpoint of my knowledge of the spec.

I made a few comments in my reply to Joerg. I have a degree in physics, and
most of a Masters in physical oceanography. I see considerable mathematical
anarchy in the XSL spec, some degree of mathematical naivete, and lots of
confusion. My forte is not logic, based on my background, but even a physics
guy can dissect the pseudo-logic in that spec. I think plenty of other
people have also separated the wheat from the chaff as far as that document
is concerned...I think we are due for a rewrite, with lots of the
pretentious math excised, 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 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: 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
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Markers in areas

[Mark C. Allman]

... 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: 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


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Markers in areas

[J.Pietschmann]

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-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Markers in areas

[Arved Sandstrom]

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. 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 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,
> but they didn't get used for this.
>
> Objections?
>
> J.Pietschmann
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Markers in areas

[J.Pietschmann]

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,
but they didn't get used for this.

Objections?

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

[Fwd: Questions about markers]

[Peter B. West]

FYI

Peter

 Original Message 
Subject: Questions about markers
Date: Fri, 07 Feb 2003 02:11:16 +1000
From: Peter B. West <[EMAIL PROTECTED]>
To: xsl-editors <[EMAIL PROTECTED]>

Background:

Processing of large FO documents is both cpu and memory intensive.
The volume of property information is partly responsible for the
memory requirement.  In order to minimise this demand, I want to
be able to divide the property construction into two phases with
different requirements.

1. The construction of individual branches of the FO tree.  During
this phase, as tree building proceeds down a particular branch
towards a leaf node, the ancestor nodes of that leaf are constructed
without knowledge of the requirements of descendants.  Therefore,
no optimisaton is possible of the set of properties which must be
maintained at each ancestor node.  Whether a particular specified
or inherited property is required by an individual ancestor node,
a full set of properties must be developed and maintained (at
least conceptually) until the inheritance and functional reference
requirements of the last descendant have been determined.  These sets
are constructed as control descends down the tree, making the set
available to each child and its descendants.

2. As control retreats back up the tree, having constructed the
property sets of each of its descendants, there is no further need
for any but the actual properties pertaining to each individual node.
This allows for considerable space (and subsequent performance)
optimisations, by, e.g., reducing the applicable property set to
the minimum required by the FO, and maintaining that set in an
array of predetermined length, whose elements can be accessed by
a mapping array, whose length and contents are predetermined.

This neat and compact arrangement may be disturbed by the presence
of markers. Markers do not inherit from their FO tree ancestors, but
from their ancestors determined in the Area tree.  The properties of
retrieved marker subtrees are necessarily resolved in the context
of the Area tree; the marker retrieved at a certain point is
determined by the status of the Area tree construction.  Given this
close connection with the Area tree, I wish to have clarified the
environment of expression resolution for markers, in particular as it
affects inheritance and the from-nearest-specified-value() function.

Questions:

Is this environment conceptually akin to that which would obtain
were the fo:marker subtree transposed to the position in the FO
tree occupied by the fo:retrieve-marker during phase 1 of FO tree
construction?

In this case, all properties specified and inherited are available to
"normal" inheritance and to the core functions.

Is it akin to that which would obtain were the fo:marker subtree
transposed to the same position in the FO tree following phase 2,
as described above?

In this case, only properties which were relevant to particular
FOs would be retained.  The point at which a property was specified
would be lost if it were not relevant at the point of specification.

Is it rather the environment which derives from the traits of the
Area tree at the point of attachment?

This case is similar to the one above, in that information about
properties which had no prior point of application would be lost
before the fo:marker subtree properties were resolved.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop/examples/fo/markers - New directory

[jeremias]

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]

Markers (was: RE: Redesign issues)

[Keiron Liddle]

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.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: table overflow and markers on 20.2

[J.Pietschmann]

[EMAIL PROTECTED] wrote:
>  but I thought these were a function of the unfinished markers in 20.2.

I still don't know what "these" refers to, and
what function is meant.

J.Pietschmann



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: table overflow and markers on 20.2

[Louis . Masters]

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 respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:

Subject:  Re: table overflow and markers on 20.2

[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. if ROW3,ROW4 and ROW5 overflow, it pulls from
ROW3).

This could have something to do with the spilling
algorithm. The ROW4 is added to a page, with markers,
then it is discovered not to fit, the layout is undone
and the row goes onto the next page. It is quite
possible that markers aren't handled properly in this
case.
There *could* be problems with rendering areas if
the marker isn't the first child of the FO it marks,
though I was unsuccessful so far to construct one.


> I do get several "ERROR  [fop]:fo:marker
> must be an initial child,and 'marker-class-name' must be unique for same
> parent" messages,

Markers which cause the latter message are ignored. You should
fix these errors.
The first message can already be caused by whitespace preceding
the marker, like
   
 
(you see the whitespace, don't you?)
This is usually not a real pressing problem, though it is
always advisable to fix error messages as well as warnings,
lest you ignore something important.

 > but I thought these were a function of markers in 20.2.
Duh?

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]









-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: table overflow and markers on 20.2

[J.Pietschmann]

[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. if ROW3,ROW4 and ROW5 overflow, it pulls from ROW3).

This could have something to do with the spilling
algorithm. The ROW4 is added to a page, with markers,
then it is discovered not to fit, the layout is undone
and the row goes onto the next page. It is quite
possible that markers aren't handled properly in this
case.
There *could* be problems with rendering areas if
the marker isn't the first child of the FO it marks,
though I was unsuccessful so far to construct one.


> I do get several "ERROR  [fop]:fo:marker
> must be an initial child,and 'marker-class-name' must be unique for same
> parent" messages,

Markers which cause the latter message are ignored. You should
fix these errors.
The first message can already be caused by whitespace preceding
the marker, like
   
 
(you see the whitespace, don't you?)
This is usually not a real pressing problem, though it is
always advisable to fix error messages as well as warnings,
lest you ignore something important.

 > but I thought these were a function of markers in 20.2.
Duh?

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

table overflow and markers on 20.2

[Louis . Masters]

I just experienced some bizarre marker/table behavior that I hope someone
can shed some light on.  I am using fop 0.20.2.  Here is the scenario:

Say I have a table that has rows of data and marker data:

ROW1DATA1ROW1DATA2ROW1DATA3ROW1MARKERDATA1
ROW2DATA1ROW2DATA2ROW2DATA3ROW2MARKERDATA1
ROW3DATA1ROW3DATA2ROW3DATA3ROW3MARKERDATA1
ROW4DATA1ROW4DATA2ROW4DATA3ROW4MARKERDATA1
ROW5DATA1ROW5DATA2ROW5DATA3ROW5MARKERDATA1

The marker data is being used for running headers on each page
(retrieve-position=first-starting-within-page).  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. if ROW3,ROW4 and ROW5 overflow, it pulls from ROW3).

Am I doing something wrong here?  I do get several "ERROR  [fop]:fo:marker
must be an initial child,and 'marker-class-name' must be unique for same
parent" messages, but I thought these were a function of markers in 20.2.

-Lou



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6741] - markers are completely broken (as far as I can tell)

[bugzilla]

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=6741>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6741

markers are completely broken (as far as I can tell)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-04-22 09:07 ---


*** This bug has been marked as a duplicate of 6009 ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

DO NOT REPLY [Bug 6741] New: - markers are completely broken (as far as I can tell)

[bugzilla]

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=6741>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/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
  Priority: Other
 Component: general
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


[INFO]: FOP 0.20.3rc
[INFO]: building formatting object tree
[ERROR]: null

Here is the simple test case. All it contains is a marker tag


http://www.w3.org/1999/XSL/Format";>








One
this is a test this is a test this is a test this is a test this is a test this
is a test this is a test this is a test



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop/docs/examples/markers hide.fo

[keiron]

keiron  01/09/21 02:11:21

  Added:   docs/examples/markers hide.fo
  Log:
  an example to demonstrate another use of markers
  
  Revision  ChangesPath
  1.1  xml-fop/docs/examples/markers/hide.fo
  
  Index: hide.fo
  ===
  
  http://www.w3.org/1999/XSL/Format";>

  



  

  

  
  
  


  
  
  


  
  
  
  
  
Page ( / )

  
  
  
  
  
  WARNING: Page sequence contains:   pages.

  

  

  This example shows how it is possible to have a message that appears
  only on the first page (in a page sequence) only if there is more
  than one page.

  

  This page sequence only has one page so you will not see the message.

  
  
  
  http://www.w3.org/2000/svg"; width="15cm" height="1cm" 
xml:space="preserve">
   
  
  
  

  
  

  

  
  


  
  


  
  
  
  
  
Page ( / )

  
  
  
  
  
  WARNING: Page sequence contains:   pages.

  

  

  This page sequence has more than one page so you will see the message
  only at the top of the first page.

  

  Some text.

  

  Some text.


  Some more text on last page.

  
  
  
  http://www.w3.org/2000/svg"; width="15cm" height="1cm" 
xml:space="preserve"> 
  
  
  

  
  

  
  
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Markers

[Arved Sandstrom]

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 rendered that completely 
unusable.

This is my number one priority, to get markers working. Initially not every 
FO that can have markers will actually support them, that will likely take 
until FOP 0.21 or 0.22 to complete.

Regards,
Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Markers

[david nyakundi]

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

cvs commit: xml-fop/docs/examples/markers glossary.xml glossary.xsl

[arved]

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
  ===
  
  
  
basic-link
The fo:basic-link is used for representing the start resource
of a simple link.
  
  
bidi-override
The fo:bidi-override inline formatting object is used where
it is necessary to override the default Unicode-bidirectionality
algorithm direction for different (or nested) inline scripts in
mixed-language documents.
  
  
block
The fo:block formatting object is commonly used for formatting
paragraphs, titles, headlines, figure and table captions, etc.
  
  
block-container
The fo:block-container flow object is used to generate a
 block-level reference-area.
  
  
character
The fo:character flow object represents a character that is
 mapped to a glyph for presentation.
  
  
color-profile
Used to declare a color profile for a stylesheet.
  
  
conditional-page-master-reference
The fo:conditional-page-master-reference
 is used to identify a page-master that is to be used when the conditions
 on its use are satisfied.
  
  
declarations
Used to group global declarations for a stylesheet.
  
  
external-graphic
The fo:external-graphic flow object is used for a graphic
 where the graphics data resides outside of the XML result tree in the
 fo namespace.
  
  
float
The fo:float serves two purposes. It can be used so that during the
 normal placement of content, some related content is formatted into a
 separate area at beginning of the page (or of some following page) where
 it is available to be read without immediately intruding on the reader.
 Alternatively, it can be used when an area is intended to float to one
 side, with normal content flowing alongside.
  
  
flow
The content of the fo:flow formatting object is a sequence
of flow objects that provides the flowing text content that is distributed
into pages.
  
  
footnote
The fo:footnote is used to produce a footnote citation and the
corresponding footnote.
  
  
footnote-body
The fo:footnote-body is used to generate the content of the
footnote.
  
  
initial-property-set
The fo:initial-property-set specifies formatting properties
for the first line of an fo:block.
  
  
inline
The fo:inline formatting object is commonly used for
formatting a portion of text with a background or enclosing it in a
border.
  
  
inline-container
The fo:inline-container flow object is used to generate an
inline reference-area.
  
  
instream-foreign-object
The fo:instream-foreign-object flow object is used for an
inline graphic or other "generic" object where the object data resides
as descendants of the fo:instream-foreign-object.
  
  
layout-master-set
The fo:layout-master-set is a wrapper around all masters used
in the document.
  
  
leader
The fo:leader formatting object is used to generate leaders
consisting either of a rule or of a row of a repeating character or
cyclically repeating pattern of characters that may be used for connecting
two text formatting objects.
  
  
list-block
The fo:list-block flow object is used to format a 
list.
  
  
list-item
The fo:list-item formatting object contains the label and the
body of an item in a list.
  
  
list-item-body
The fo:list-item-body formatting object contains the content
of the body of a list-item.
  
  
list-item-label
The fo:list-item-label formatting object contains the content
of the label of a list-item; typically used to either enumerate, identify,
or adorn the list-item's body.
  
  
marker
The fo:marker is used in conjunction with fo:retrieve-marker
to produce running headers or footers.
  
  
multi-case
The fo:multi-case is used to contain (within an fo:multi-switch)
each alternative sub-tree of formatting objects among which the parent
fo:multi-switch will choose one to show and will hide the rest.
  
  
multi-properties
The fo:multi-properties is used to switch between two or more
property sets that are associated with a given portion of content.
  
  
multi-property-set
The fo:multi-property-set is used to specify an alternative

cvs commit: xml-fop/docs/examples/markers - New directory

[arved]

arved   01/07/26 19:12:33

  xml-fop/docs/examples/markers - New directory

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Markers; Other Stuff

[Arved Sandstrom]

The rudiments of fo:marker and fo:retrieve-marker support are appearing. 
Consider this a true "commit early, commit often" kind of endeavour; FOP 
doesn't break, the marker support should be transparent, and parts of it even 
work after a fashion ("retrieve-boundary" with a value of 'page', combined 
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 to other 
legal parents of fo:marker. You will have noticed other stuff appear; this 
not only supports markers but should support other stuff also:

1) AreaClass.java in 'layout': this is a utility class, basically. It 
supplies a verification method. I have never discovered a nice way of doing 
enums in Java, so I don't (we'll have to wait for 1.4 or 1.5, I guess).

2) Areas now have isFirst, isLast, generatedBy and returnedBy traits. Using 
them properly, or at all, is more a matter of Scout's honour than anything 
else, because of the way FOP is. Block.java shows how I am using them there.

Finishing off marker support should actually not require that much more 
effort; I'm hoping to have it done within the week. If you happen to be 
working in a particular FO that can have markers, please add the support code 
if you like. More the merrier. Making sure that the traits listed in (2) are 
properly set on all areas we generate/return is much more of a task, but we 
have to start somewhere.

As I say, everything should build, and existing stuff shouldn't notice any of 
this. Please let me know if that is not the case.

Regards,
Arved Sandstrom
-- 
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Halifax, Nova Scotia
Wireless * B2B * J2EE * XML

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]