You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Victor Mote <vi...@outfitr.com> on 2003/06/17 17:42:07 UTC
alt-design merits (WAS: Nomination of Glen Mazza as committer)
Peter B. West wrote:
> Which modules? I'm not sure what you mean. The modularity of area
> processing? The Rec gives an utterly spurious view of this. It has
> been misleading developers since the drafts were first published, and
> giving the impression that things can be neatly modularised. Some of
> the persistent difficulties of design arise from this misunderstanding.
> However, I may be misreading you here. What modules do you
> have in mind?
All right, educate me please. (I have read your doc and don't get it). In as
simple terms as possible (for my simple mind), why can't markers defer the
resolution of their properties until layout time?
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
alt-design merits
Posted by "Peter B. West" <pb...@powerup.com.au>.
Peter B. West wrote:
>
> If I have not answered your question, yell out. I am quite happy to
> keep on at this until you at least understand my thinking on this, even
> if you don't agree with it.
But I will be keeping on with it tomorrow, as it is very late here.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: alt-design merits (WAS: Nomination of Glen Mazza as committer)
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor,
Trying to answer your latest questions on this topic has absorbed a deal
of my time, exposed a contradiction in my thinking, and made me think
through in more detail some of the fuzzy bits. I am still working on
it, and I will get back to you. Thanks for the interrogation.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
RE: alt-design merits (WAS: Nomination of Glen Mazza as committer)
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> They can. They must. But then what happens to the idea that the FO
> tree can be processed and refined before the layout occurs? If you are
The pieces that can be processed are. The pieces that cannot are deferred.
> tree can be processed and refined before the layout occurs? If you are
> going to defer the resolution, why not defer the parsing as well?
Because to simple minds like mine, they seem like easily separable tasks for
which there is no benefit to mixing. More to the point of this conversation,
if you can complete the parsing before starting layout, why not?
> Marker resolution requires the merging of the fo:static-content subtree
> (encountered *before* the corresponding fo:flow) with fo:marker subtrees
> which can only be determined as pages are laid out. Furthermore, this
> process may repeat with *different* fo:marker subtrees being attached at
> the same fo:retrieve-marker point in the static-content.
OK, but this doesn't help me understand how pull parsing is superior to
building an FO Tree.
> With pull parsing, events are extracted from a parsing event buffer *as
> required*. In general, this will occur "synchronously", but need not.
By way of comparison, with the FO Tree, information is extracted from the
tree *as required*. Again, I don't see the benefit.
> The stream of static-content parsing events can be stashed away, the
> stream of fo:marker subtree events can be stashed away somewhere else,
Why not "stash away" in an FO Tree?
> and the process of resolving the FO tree need never know that it is in
> fact reading an "asynchronous" stream of parser events in which
> fo:marker streams are attached by sleight-of-hand in place of the
> fo:retrieve marker dynamically and transparently, and that this parsing
> is happening after the event - well after the static-content was first
> encountered, and after the region-body has been laid out. Furthermore,
> it can be "rewound" and repeated for as long as new pages with new
> fo.marker retrievals are required.
I do not see the advantage of using sleight-of-hand events over a data
structure.
> "Synchronous" and "asynchronous" are relative terms here. It's all
> asynchronous, in the sense that the SAX component simply creates parse
> events and sticks them in a producer/consumer buffer.
>
> The other problem is percentage lengths, where the percentage is defined
> against an enclosing area dimension. Doesn't it make sense to create
> the area before you even look at the FOs which will fill it? Creating
Not to my way of thinking (although I have struggled with this a bit). In
general, XSL-FO 1.0 content drives the layout, not the other way around. (If
you have Dave Pawson's book, see the last section of Chapter 2.) IMO, the
percentage problem that you mention is an exception to this rule that can be
handled without a redesign of the whole system. How can you create an area
for a block without knowing its "span" attribute? (BTW, I think the redesign
stumbles here as well).
> the area also creates the context for the resolution of percentages. In
> the difficult cases where the area dimension is initially indeterminate,
> the unresolvable percentage can at least be immediately "attached" to
> the area dimension whose resolution will in turn, resolve the
> percentage. In most cases, however, the resolution will be immediate.
Is this not implemented/implementable in redesign?
> This approach, of having the containing area in place before parsing the
> contained FO subtree, is easy to implement with pull parsing, driven by
> the *areas*.
If it were a good thing, it seems at least as easy to implement using the FO
Tree.
> If I have not answered your question, yell out. I am quite happy to
> keep on at this until you at least understand my thinking on this, even
> if you don't agree with it.
In addition to not following the benefits, I see the following apparent
drawbacks, which I would be glad to have you address:
1. Less modularity
2. More complex design
I wanted to add "less flexible", because it would seem to restrict our
ability to make the layout pluggable. However, that is probably not true,
but that line of thinking led to an interesting thought. If pluggable layout
works, then perhaps your whole pull-parsing logic could be implemented
entirely as an implementation of LayoutStrategy. For this purpose, it would
work similarly to our Structured output concepts (MIF, RTF), in that no FO
Tree would be built, but the SAX events are passed through. You could then
do with them whatever you wish, sychronously or asynchronously,
right-brained or left-brained, Northern Hemisphere or Southern :-) Is that
worth exploring? Can your stuff use the general Area Tree model?
Victor Mote
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: alt-design merits (WAS: Nomination of Glen Mazza as committer)
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor Mote wrote:
> Peter B. West wrote:
>
>
>>Which modules? I'm not sure what you mean. The modularity of area
>>processing? The Rec gives an utterly spurious view of this. It has
>>been misleading developers since the drafts were first published, and
>>giving the impression that things can be neatly modularised. Some of
>>the persistent difficulties of design arise from this misunderstanding.
>> However, I may be misreading you here. What modules do you
>>have in mind?
>
>
> All right, educate me please. (I have read your doc and don't get it). In as
> simple terms as possible (for my simple mind), why can't markers defer the
> resolution of their properties until layout time?
They can. They must. But then what happens to the idea that the FO
tree can be processed and refined before the layout occurs? If you are
going to defer the resolution, why not defer the parsing as well?
Marker resolution requires the merging of the fo:static-content subtree
(encountered *before* the corresponding fo:flow) with fo:marker subtrees
which can only be determined as pages are laid out. Furthermore, this
process may repeat with *different* fo:marker subtrees being attached at
the same fo:retrieve-marker point in the static-content.
With pull parsing, events are extracted from a parsing event buffer *as
required*. In general, this will occur "synchronously", but need not.
The stream of static-content parsing events can be stashed away, the
stream of fo:marker subtree events can be stashed away somewhere else,
and the process of resolving the FO tree need never know that it is in
fact reading an "asynchronous" stream of parser events in which
fo:marker streams are attached by sleight-of-hand in place of the
fo:retrieve marker dynamically and transparently, and that this parsing
is happening after the event - well after the static-content was first
encountered, and after the region-body has been laid out. Furthermore,
it can be "rewound" and repeated for as long as new pages with new
fo.marker retrievals are required.
"Synchronous" and "asynchronous" are relative terms here. It's all
asynchronous, in the sense that the SAX component simply creates parse
events and sticks them in a producer/consumer buffer.
The other problem is percentage lengths, where the percentage is defined
against an enclosing area dimension. Doesn't it make sense to create
the area before you even look at the FOs which will fill it? Creating
the area also creates the context for the resolution of percentages. In
the difficult cases where the area dimension is initially indeterminate,
the unresolvable percentage can at least be immediately "attached" to
the area dimension whose resolution will in turn, resolve the
percentage. In most cases, however, the resolution will be immediate.
This approach, of having the containing area in place before parsing the
contained FO subtree, is easy to implement with pull parsing, driven by
the *areas*.
If I have not answered your question, yell out. I am quite happy to
keep on at this until you at least understand my thinking on this, even
if you don't agree with it.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org