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 "Peter B. West" <pb...@powerup.com.au> on 2003/12/15 08:55:51 UTC
FOs and Areas
Herewith some notes on the tortured relationship between the two. As I
don't know much about layout in HEAD, I am hoping that differences and
(hopefully) correspondences between my ideas and the HEAD redesign can
be pointed out by wiser HEADs than mine.
As I recall, in the original original version, the complete FO tree was
built before the Area tree construction was started. When Mark
Lillywhite looked at the code, his most important contribution was to
realize that the FO tree could be broken up into page-sequences, and the
construction of the page-sequence Area subtree could be commenced at the
end of each page-sequence.
In my original design, I intended to run parsing, FO tree building and
Area tree building in parallel, linked together by producer/consumer
buffers. I've done that for parsing and FO tree building, but my
concepts of how to link FO tree and Area tree have been in a state of
flux for some time.
It seems to me, however, that the key to 1) solving the layout
dependencies of FO property expressions, and 2) reducing footprint,
particularly for those long documents which are naturally expressed with
very large fo:flow trees in a few page-sequences, is to have the areas
generated by the FOs as soon as the FOs are parsed and entered into the
FO tree.
If this were done, then there would *always* exist a reference area for
the percentage expressions, even if that area could not always be
dimensioned. Having a reference for the expression makes it
straightforward to resolve the expression as soon as the referent is
dimensioned, and also makes feasible the re-dimensioning of the
referring areas if the referent is required to change (e.g., by virtue
of being forced onto a new page with different margins.)
Some of my other preoccupations I have mentioned before. Line-areas
should be filled from the bottom-up, while dimensions filter down from
the top. E.g. my procedure for resolving footnotes implies that
individual line-areas are passed up to the page level (region-body, at
least) along with any impacts (footnotes, before-floats) associated with
the line area. When side-floats occur, the line, and its impact (which
is, I think, the entire side-float, which must therefore be resolved
when encountered) are passed back to the ancestor reference area.
My focus in this is on the *page*-area-tree, which establishes a subtree
of containers. These containers are then filled from the bottom up by
line-areas, themselves filled from the bottom up by the atoms of the
flow. While the page-area-tree is structured, and dimension issues can
be resolved within it, there remains a close connection with the
corresponding FO subtree, which itself is a subtree of the fo:flow
subtree. Both the page-area-tree and the flow subtree can be very
complex. Think of multi-column layout including tables with footnotes,
and a list or two thrown in for good measure.
The containers of the page-area-subtree are filled from bottom-level FO
nodes. The bottom-level FO nodes must be able to sensibly construct
line-areas, including all of the line-breaking logic that is required.
They know nothing of pages, however. When the page-area-tree fills, a
page is ready for rendering or intermediate storage, so the
page-area-tree "goes-away". That leaves the flow subtree in a suspended
state, with the low-level FO nodes demanding space for the next
line-area. (Note that blocks aren't "broken" - instead, areas are
filled until a line-area comes along which would cause overflow. The
offending line-area and its components are conceptually pushed back for
reprocessing on the next page. It is this pushed-back line-area which
generates the initial demand for more space.)
This demand percolates up through the flow active ancestry until it
results in a demand for a new page. The page factory associated with
the page-sequence and the layout-master-set through the page-sequence
master-reference, generates a new page container set, and the relevant
area and its dimensions are passed to the flow FO. From here the
container availability percolates back down the active flow descendants,
with the FO nodes generating new sub-areas, and attaching percentage
expressions to their reference areas as control descends. At the
bottom, the line-area generators are given new dimensions to deal with,
and the bottom-up filling process begins again.
I want to diagram this, and look more closely at the nasty cases as I
do, but comments are, as always welcome. Victor will be upset, I know,
but I can't see the separation of FO tree building and Area tree
building. Keiron may be screaming, "That's what I was doing," in which
case my apologies.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
RE: Going away (was: FOs and Areas)
Posted by Victor Mote <vi...@outfitr.com>.
Jeremias Maerki wrote:
> On 17.12.2003 15:25:37 Victor Mote wrote:
> > I would rather go away than to be the guy that everyone wishes would
> > go away.
>
> Ok, Victor, until that happens I'd like you to stay. I don't see *any*
> indication that *anyone* wishes that *anybody* should go away. Well, our
> moderators would surely like to get rid of all spammers. But seriously,
> please reconsider your decision, maybe take a break from the mailing
> list to clear your head. Consensus is sometimes hard to find especially
> over such an problematic medium such as this mailing list. Intentions
> are always difficult to transmit. Mails take a long time to write, time
> we usually don't have and would rather spend programming. I think we all
> share that frustration. Maybe we should all buy a webcam so we can
> occasionally chat together face to face as we're all a long way from
> each other.
It is true enough that "consensus is sometimes hard to find", but that is
not the point. The point is that, as practiced by FOP, it is impossible to
find. And not because of technical difficulty.
WRT the slowness of the medium of email, I actually perceive that to be a
benefit. The time it takes to draft an email is a useful cooling-off period,
at least for me.
> Now the following is not only directed to you, Victor, but to everyone
> else as well. Just personal opinions:
>
> I followed the wars on the Avalon mailing list which at one time even
> produced a victim in form of a partial expulsion from the ASF. I would
> be very sad to have to see similar things here, especially in the
> project's present state.
>
> I told Glen this summer that it's better to fire away with changes than
> letting himself block by myself who, at that time, only injected his
> ideas and opinions but without code to back them. What this project
> needs is people who simply do it (tm). A good design is useful but
> obviously it's not so simple to find in our case. We can't live without
> some sort of design that gives use some direction but things like
> Victor's pluggable LayoutStrategy may really help, if we need to
> investigate different approaches. I'd rather have two or three
> half-completed layout approaches with lots of things learned than not a
> single working one with a community at total stand-still. We failed to
> integrate Peter's branch into HEAD but maybe that's also because it was
> too big a bundle at one time.
>
> Everyone should accept that another person has a different opinion. That
> shouldn't block us in our work. We all look forward to the same goal.
> That much I know or else we wouldn't be here.
>
> So, I mostly agree with Joerg's and Andreas' recent comments. Please
> let's focus on coding even if we may have to throw away little parts
> again in the process. (This doesn't mean I don't want to see anymore
> threads on design.) I think one of the most important points we learned
> since the redesign decision is to better split up the whole thing so
> it's easier (and less painful) to change if we run into a dead-end
> somewhere.
The inherent problem with this suggestion is that it is not reasonable to
invest in a project where the big design issues are not addressed. The best
thing would be to come to an agreement in theory, then as coding progresses,
change the theory if necessary. The second best thing would be to fork the
project into two -- one based on the trunk, one based on alt-design. If that
split were made official, I think developers would be much easier to recruit
(and retain) for both.
If Peter's principles prevail, it will be a permanent triumph of performance
over quality, and FOP will never be useful for my purposes. I don't have a
problem with that, but it is not unreasonable to try to resolve it before
investing more in the project.
Victor Mote
Going away (was: FOs and Areas)
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 17.12.2003 15:25:37 Victor Mote wrote:
> I would rather go away than to be the guy that everyone wishes would
> go away.
Ok, Victor, until that happens I'd like you to stay. I don't see *any*
indication that *anyone* wishes that *anybody* should go away. Well, our
moderators would surely like to get rid of all spammers. But seriously,
please reconsider your decision, maybe take a break from the mailing
list to clear your head. Consensus is sometimes hard to find especially
over such an problematic medium such as this mailing list. Intentions
are always difficult to transmit. Mails take a long time to write, time
we usually don't have and would rather spend programming. I think we all
share that frustration. Maybe we should all buy a webcam so we can
occasionally chat together face to face as we're all a long way from
each other.
Now the following is not only directed to you, Victor, but to everyone
else as well. Just personal opinions:
I followed the wars on the Avalon mailing list which at one time even
produced a victim in form of a partial expulsion from the ASF. I would
be very sad to have to see similar things here, especially in the
project's present state.
I told Glen this summer that it's better to fire away with changes than
letting himself block by myself who, at that time, only injected his
ideas and opinions but without code to back them. What this project
needs is people who simply do it (tm). A good design is useful but
obviously it's not so simple to find in our case. We can't live without
some sort of design that gives use some direction but things like
Victor's pluggable LayoutStrategy may really help, if we need to
investigate different approaches. I'd rather have two or three
half-completed layout approaches with lots of things learned than not a
single working one with a community at total stand-still. We failed to
integrate Peter's branch into HEAD but maybe that's also because it was
too big a bundle at one time.
Everyone should accept that another person has a different opinion. That
shouldn't block us in our work. We all look forward to the same goal.
That much I know or else we wouldn't be here.
So, I mostly agree with Joerg's and Andreas' recent comments. Please
let's focus on coding even if we may have to throw away little parts
again in the process. (This doesn't mean I don't want to see anymore
threads on design.) I think one of the most important points we learned
since the redesign decision is to better split up the whole thing so
it's easier (and less painful) to change if we run into a dead-end
somewhere.
Jeremias Maerki
RE: FOs and Areas
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: Victor Mote [mailto:vic@outfitr.com]
>
> Andreas L. Delmelle wrote:
>
<snip />
>
> The gist of this section seems to be ... that you don't know enough to
> comment on what is going on. Duly noted.
>
Not quite. More like: I *think* I don't know enough (maybe _that_ is
overreacting).
Sometimes this assumption gets affirmed, and at others --for example, your
announcement yesterday - I am strongly convinced there is a lot to be
learned from me ;)
Cheers,
Andreas
RE: FOs and Areas
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: Victor Mote [mailto:vic@outfitr.com]
>
> Andreas L. Delmelle wrote:
>
<snip />
>
> > However, right now, reacting the way you do, I'm getting the impression
> > you're taking it waaay *too* seriously --in fact, you have been
> doing that
> > all along. It almost seems like you are backing out now,
> because you see a
> > certain failure ahead and you want to avoid it. You just don't
> want to be
> > there when it turns out your proposals were worthless to begin with.
>
<snip />
> Your ad hominem attack on my motives is rude, arrogant, offensive, and not
> supported by anything that I have said. And I don't mind saying that it is
> false.
>
> ..., not everyone is as
> > fluent in expressing himself in writing, and, as it turns out,
> > not everyone
> > seems to be as fluent in reading what is written...
>
> Again you have misunderstood the issue. ...
>
Nope! Maybe someone has failed to read what was *written* (otherwise IMHO
one wouldn't see it as an ad hominem attack, neither would one read it as
rude, offensive and so on... or rather, now I'm closer to believing that
there is some truth in it than I was before you told me it was false). If
you re-read the whole message, you should be able to see that you cannot
separate the last sentence of my so-called attack from the "I'm getting the
impression that..." Besides that, it is definitely *not* based upon what you
said, but it *was* based on what I gathered you were about to DO (or,
rather, STOP doing...)
Anyway, it seems to have worked out pretty good.
> It is not that we do not understand each other, but in fact that we
understand each other too well.
Hmmm... know what? I think I agree with you on this.
Cheers,
Andreas
RE: FOs and Areas
Posted by Victor Mote <vi...@outfitr.com>.
Andreas L. Delmelle wrote:
> With all due respect, I think you're overreacting here. Maybe you already
> know this yourself, and have changed your mind about the
> 'adios'... Anyway,
> I have been following the discussions between Peter and yourself
> (--at least
> the recent ones, which may be exactly why I'm convinced this is
> all strongly
> exaggerated).
> Before you leave, I have a thing or two to add about one of the previous
> posts in this thread, where you are talking about an abstract 'team' where
> at first 100 percent of the committers are pro one particular design --you
> know, the part about 'choosing sides' and how this affects global
> efficiency
> within a project. Since the post in question was composed shortly after my
> 'heads up' to Peter, I can't help but feel it's somehow related to that.
No. It took me several hours to draft that message. The fact that they were
sent close together is a coincidence.
> Perhaps you would rather have seen me (or others) having a go at him as
> well?
Yes, I think some discipline is needed here, but I don't expect it to come
from you.
> It definitely was never my intention to occupy myself with something so
> mean/common as 'choosing sides'. Fact of the matter is that, for
> the moment
> I *know* too little about the workings of FOP (either HEAD or
> alt-design) to
> actually have a thoroughly reflected preference for either approach.
> Hey, maybe I just need to catch up on the archives, and will then suddenly
> discover what kind of a pest Peter really is... but right now, I lack any
> indication of him trying to undermine every one of your design proposals,
> neither have I been confronted with any evidence that he is
> actually trying
> to force anyone to see things *his* way at the cost of everything
> else (and
> these are two things you seem to be _reproaching_ him in your replies).
The gist of this section seems to be ... that you don't know enough to
comment on what is going on. Duly noted.
> Re-reading Peter's posts, on the contrary, I see someone who was daring
> enough at some point to say: "I'm going to try it like that, regardless of
> what the rest of you does." Some time later, he came to the
> conclusion that
> he wouldn't solve some of the issues the others were trying to
> solve at the
> time he went his own path, and now he's here again --to see if any of the
> issues have already been sorted out.
If what you say were true, the alt-design properties work would have been
integrated into the trunk, and the alt-design branch abandoned. No, he is
here, again, to sell us on the idea that you can't build an FO Tree without
first building the Area Tree. He is unwilling to consider simpler
alternatives.
> Look, I can understand your agitation stemming from the fact that you had
> put considerable time and effort into providing a means to be
> able to choose
> between different layout strategies, and now it turns out this
> wasn't really
> necessary after all --and Peter's shrugging his shoulders, which obviously
Where do you get the idea that LayoutStrategies aren't necessary after all?
IMO, they are crucial, regardless of what Peter does.
> would cause a lot of frustration with (and would thus come across as
> offending to) someone who takes the project seriously, like yourself.
I don't care whether Peter uses LayoutStrategy or not. My frustration stems
from the fact that design questions can be repeated ad infinitum and ad
nauseam. People who take the questions seriously and try to develop answers
to them have the same weight as those who flippantly say "-1" or those who
let the thread dangle until they can reagitate the question again.
> However, right now, reacting the way you do, I'm getting the impression
> you're taking it waaay *too* seriously --in fact, you have been doing that
> all along. It almost seems like you are backing out now, because you see a
> certain failure ahead and you want to avoid it. You just don't want to be
> there when it turns out your proposals were worthless to begin with.
Perhaps you would be so kind as to tell me what you are talking about.
Specifically what is it that you think will fail, and why? If you can answer
that, then you can answer the question that I have asked Peter to answer 4
times now.
I have acknowledged that my proposals may be worthless. In fact, I have
asked Peter to simply show that they are. If the solution requires a complex
system to coordinate parsing and layout, then that is what we need to do. I
have proposed a much simpler alternative that leaves our existing code base
intact, and have asked Peter to find any flaws in it. The nature of this
stuff is that some days you teach and others you are taught. I can't get
Peter to do either one.
Your ad hominem attack on my motives is rude, arrogant, offensive, and not
supported by anything that I have said. And I don't mind saying that it is
false.
> Nowhere have I read any allusion to you as the guy everyone else wishes
> would go away (perhaps somewhere in the whitespace in between two words in
> one of Glen's posts ;) ) Things get rough sometimes, not everyone is as
> fluent in expressing himself in writing, and, as it turns out,
> not everyone
> seems to be as fluent in reading what is written...
Again you have misunderstood the issue. It is not that we do not understand
each other, but in fact that we understand each other too well.
Victor Mote
RE: FOs and Areas
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: Victor Mote [mailto:vic@outfitr.com]
> Peter B. West wrote:
>
> > The statements are getting extreme. Let's just agree to differ. I'm
> > happy to let my code and the design that underlies it do my talking.
>
> OK. For the reasons already mentioned, this does not work for me.
> I consider
> this kind of behavior to be uncivilized. However, I have to consider the
> possibility that the problem lies with me. Since this is the
> second time in
> the last several months that I have had to call someone out for
> unsupported
> (and unsupportable) conclusions, and since I have had to do so alone, and
> indeed stand alone here, it seems probable that this is just the
> way things
> work, and that I should somehow adapt myself to it. That ain't going to
> happen. I would rather go away than to be the guy that everyone
> wishes would
> go away. So, adios.
>
Victor,
With all due respect, I think you're overreacting here. Maybe you already
know this yourself, and have changed your mind about the 'adios'... Anyway,
I have been following the discussions between Peter and yourself (--at least
the recent ones, which may be exactly why I'm convinced this is all strongly
exaggerated).
Before you leave, I have a thing or two to add about one of the previous
posts in this thread, where you are talking about an abstract 'team' where
at first 100 percent of the committers are pro one particular design --you
know, the part about 'choosing sides' and how this affects global efficiency
within a project. Since the post in question was composed shortly after my
'heads up' to Peter, I can't help but feel it's somehow related to that.
Perhaps you would rather have seen me (or others) having a go at him as
well?
It definitely was never my intention to occupy myself with something so
mean/common as 'choosing sides'. Fact of the matter is that, for the moment
I *know* too little about the workings of FOP (either HEAD or alt-design) to
actually have a thoroughly reflected preference for either approach.
Hey, maybe I just need to catch up on the archives, and will then suddenly
discover what kind of a pest Peter really is... but right now, I lack any
indication of him trying to undermine every one of your design proposals,
neither have I been confronted with any evidence that he is actually trying
to force anyone to see things *his* way at the cost of everything else (and
these are two things you seem to be _reproaching_ him in your replies).
Re-reading Peter's posts, on the contrary, I see someone who was daring
enough at some point to say: "I'm going to try it like that, regardless of
what the rest of you does." Some time later, he came to the conclusion that
he wouldn't solve some of the issues the others were trying to solve at the
time he went his own path, and now he's here again --to see if any of the
issues have already been sorted out.
Look, I can understand your agitation stemming from the fact that you had
put considerable time and effort into providing a means to be able to choose
between different layout strategies, and now it turns out this wasn't really
necessary after all --and Peter's shrugging his shoulders, which obviously
would cause a lot of frustration with (and would thus come across as
offending to) someone who takes the project seriously, like yourself.
However, right now, reacting the way you do, I'm getting the impression
you're taking it waaay *too* seriously --in fact, you have been doing that
all along. It almost seems like you are backing out now, because you see a
certain failure ahead and you want to avoid it. You just don't want to be
there when it turns out your proposals were worthless to begin with.
Nowhere have I read any allusion to you as the guy everyone else wishes
would go away (perhaps somewhere in the whitespace in between two words in
one of Glen's posts ;) ) Things get rough sometimes, not everyone is as
fluent in expressing himself in writing, and, as it turns out, not everyone
seems to be as fluent in reading what is written...
> I have a great amount of respect for everyone on this team, and
> wish you all
> well. I very much regret leaving my various interests in the project
> unfinished.
>
To be honest: whether you decide to stay or not, I'll certainly be
frequenting this list for some time to come... too bad I just considered
myself ready to start studying your FO tree in more detail ( Peter could
turn out to need it as well ) :)
Cheers,
Andreas
RE: FOs and Areas
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> The statements are getting extreme. Let's just agree to differ. I'm
> happy to let my code and the design that underlies it do my talking.
OK. For the reasons already mentioned, this does not work for me. I consider
this kind of behavior to be uncivilized. However, I have to consider the
possibility that the problem lies with me. Since this is the second time in
the last several months that I have had to call someone out for unsupported
(and unsupportable) conclusions, and since I have had to do so alone, and
indeed stand alone here, it seems probable that this is just the way things
work, and that I should somehow adapt myself to it. That ain't going to
happen. I would rather go away than to be the guy that everyone wishes would
go away. So, adios.
I have a great amount of respect for everyone on this team, and wish you all
well. I very much regret leaving my various interests in the project
unfinished.
Victor Mote
Re: FOs and Areas
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor,
The statements are getting extreme. Let's just agree to differ. I'm
happy to let my code and the design that underlies it do my talking.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: FOs and Areas
Posted by Manuel Mall <mm...@arcus.com.au>.
As an active FOP user I have been monitoring the fop-dev list for the last 2
years or so.
The recent discussion between Victor and Peter and Jörg's comment below seem
to highlight a difference in opinion where the project is headed.
Based on the various discussions on this list and the web site it appeared
to me that the goal for the development branch is:
a) Basic level compliance to the FO spec
b) Support for arbitrary sized documents
plus a number of sub goals.
Both of these goals appear to create really hard design problems for which
even experienced FOP developers don't have solutions to. For example the
issue of resolving property values, the dependency of the resolution on the
layout, and the special handling required for resolution in the context of
markers, seem to cause lots of design discussions without actually
converging. This indicates to me it is most likely a hard problem when,
given the quality of the people contributing, not even after a year or so an
agreed and understood design solution is forming. And property value
resolution is only a small item in the problem domain created by the XSL-FO
spec.
Personally I agree with Jörg that the project needs working code especially
as the maintenance branch is frozen and no more releases are forthcoming
until the development branch is ready. This becomes a "very long time
between drinks" for your user base.
However, to achieve the working code may be the project goals need to be
revised downwards. May be the project should scrap the design goal of basic
level compliance and support for large documents and aim for a smaller
subset. For example: Go through the list of unsupported or incomplete
supported fo elements and properties and agree on a subset to be supported
in the next release. Keeps, auto table layout, bidi font support are some
that come to mind but I am sure there are more (or less).
Once that is agreed concentrate design and implementation discussions on
these revised goals. If it turns out that this leads to design decision
which will make other things (outside the stated goals) hard later - tough
luck that's then left to the next refactoring effort. If it leads to certain
property expressions not being supported - tough luck as well. If it leads
to markers not being done perfectly - tough luck as long as the stated goals
are achieved (this assumes perfect marker handling is not one of the goals).
Isn't that part of the 'Extreme Programming' methodology? If it's not needed
now (= not part of the project spec) don't build it in.... don't even waste
time discussing it.
Most projects go through many iterations each leading to rewrites of
significant portions of the code (eg. tomcat 3.x, 4.x, 5.x). Why should FOP
get away with only two iterations?
Manuel
----- Original Message -----
From: "J.Pietschmann" <j3...@yahoo.de>
To: <fo...@xml.apache.org>
Sent: Thursday, December 18, 2003 3:26 AM
Subject: Re: FOs and Areas
Peter B. West wrote:
> (does Jörg work?),
Not in the archive.
>
> I know you are a long-time advocate of sticking with the codebase, and
> have been very critical of my approach, so I don't want to draw any
> unwarranted conclusions here. Does the above mean that you are
> interested in my ideas?
I've got a lot of ideas myself, perhaps too many. What the
project needs is *working* *code*.
J.Pietschmann
RE: FOs and Areas
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
>
> Yuck! Flashbacks of SoftRAM....
>
Ok, that's understood! None of that here!
Thanks for the info. (I'll be back with more ideas... maybe some more bad
ones, but I'll leave you guys to judge that ;) )
Cheers,
Andreas
Re: FOs and Areas
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Andreas L. Delmelle wrote:
> Which is done by {which parser?}
Xerces 2.3.4, but it doesn't matter. The problem are the generated
Java objects.
> 80k? For how many fo:* approx. in the file?
80000 objects. A table with some twenty odd columns and 800+ rows.
A TableCell, a Block and a FOText per cell. The rest is small change.
> Problem seems to be one of nested little objects, no longer 'needed', but
> still referenced by their parent, which is still 'needed' --btw: What
> exactly are the criteria by means of which it is possible to decide that a
> given FO object, no matter how deeply nested, can safely be 'discarded' from
> the tree?
A) it has been rendered.
B) no chance to backtrack (due to keeps, widows/orphans, side-floats,
column rebalancing because of footnotes or before-floats, last page
layout and perhaps a slew of less obvious reasons)
Note that there are scenarios where a backtracking can ripple back
through an arbitrary number of pages, although 99.99% ought to affect
the current page only and even scenarios affecting the previous page
look rather artificial.
FOs not generating areas, in particular fo:table-column, could probably
discarded immediately after the interesting info has been processed into
a more amenable data structure referenced from parent FO.
> [Another option (--also a very long shot maybe) would be to try and, ahem,
> _steal_ a little of the PDF approach... implement a form of (binary)
> compression on the FO tree storage in memory?
Yuck! Flashbacks of SoftRAM....
J.Pietschmann
RE: FOs and Areas
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: John Austin [mailto:jwaustin@sympatico.ca]
>
> On Wed, 2003-12-17 at 15:56, J.Pietschmann wrote:
> > I've got a lot of ideas myself, perhaps too many. What the
> > project needs is *working* *code*.
>
> Amen!
>
> [but a short one, not drawn out like the final chorus of Messiah!]
Well, just helps if you have ideas to share these from time to time, whether
it's working code or not. It has proven to provide very interesting clues
when it comes to getting pointers on where to look for which particular
mechanism, and on how these could be improved, possibly at very low-level.
So to add some :
> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
>
> I wondered why I got a OutOfMemory already during *parsing*...
>
Which is done by {which parser?} ... Just asking because on Xerces-J's
feature page
( http://xml.apache.org/xerces2-j/features.html ), I saw a little note on
'http://xml.org/sax/features/string-interning' (--with all the rant on
String.intern() a while ago, this _may_ provide a clue to some; or may well
be a well-known fact, perhaps already explored ).
Anyway, it defaults to 'true' for any parser that is derived from the Xerces
default parser (you can't even unset it)
Perhaps (--a long shot) the earlier attempts to try and use this blocked on
the internalizing being doubled in some way?
> ... In a real world file I benchmarked (rendered to 58 pages),
> the FO tree for the second page sequence run up to >70MB due to a table
with
> lots of small cells, which generated more than 80k FOs alone.
80k? For how many fo:* approx. in the file? Guess that's the counterweight
for verbosity mandated by the spec... a fo:block could consist of only one
node, an fo:table still takes at least five (six in the exotic case you
actually need to place some content in the cell, for testing purposes ;) )
Problem seems to be one of nested little objects, no longer 'needed', but
still referenced by their parent, which is still 'needed' --btw: What
exactly are the criteria by means of which it is possible to decide that a
given FO object, no matter how deeply nested, can safely be 'discarded' from
the tree? I mean not solely from the spec point-of-view: it would of course
be possible for an object to refer to another defined at the start of the
page-sequence, but does that necessarily mean having to keep a reference to
all of the latter object's descendants?
[Another option (--also a very long shot maybe) would be to try and, ahem,
_steal_ a little of the PDF approach... implement a form of (binary)
compression on the FO tree storage in memory? Since zipping objects already
has the known benefit of saving bandwidth, why not try and use it to reduce
footprint? Compress in static form, decompress the objects (and their
descendants) as-and-when they get needed by Layout/Area tree. In cases as
mentioned above this would already decrease memory fp by, what? 30%? Taking
into account you still have to have uncompressed instances of objects needed
by the other running processes (apart from tree building). Would it weigh up
to the processing cost?]
Just an idea...
Cheers,
Andreas
Re: FOs and Areas
Posted by John Austin <jw...@sympatico.ca>.
On Wed, 2003-12-17 at 15:56, J.Pietschmann wrote:
> I've got a lot of ideas myself, perhaps too many. What the
> project needs is *working* *code*.
Amen!
[but a short one, not drawn out like the final chorus of Messiah!]
--
John Austin <jw...@sympatico.ca>
Re: FOs and Areas
Posted by "Peter B. West" <pb...@powerup.com.au>.
Andreas L. Delmelle wrote:
>>-----Original Message-----
>>From: Peter B. West [mailto:pbwest@powerup.com.au]
>>
>>J.Pietschmann wrote:
>>
>>>I've got a lot of ideas myself, perhaps too many. What the
>>>project needs is *working* *code*.
>>
>>Working code is predicated on working ideas, is it not? That's why I
>>asked about ideas.
>>
>
>
> Not necessarily (--that, I believe, is Victor's whole point). You can have perfectly working software, which turns out to be poorly designed, and the biggest problem there is that the flaws in the design will almost always turn up at a moment when it's least convenient to change it (we'll leave the name-dropping to _your_ imagination ;) )
My meaning was that software doesn't write itself - all software is
thought into existence (even software from code generators.)
I agree with your final point, with the substitution of
"imperfectly-working" for "perfectly-working." (Note - this was a
conversation with Joerg.)
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
RE: FOs and Areas
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: Peter B. West [mailto:pbwest@powerup.com.au]
>
> J.Pietschmann wrote:
> >
> > I've got a lot of ideas myself, perhaps too many. What the
> > project needs is *working* *code*.
>
> Working code is predicated on working ideas, is it not? That's why I
> asked about ideas.
>
Not necessarily (--that, I believe, is Victor's whole point). You can have perfectly working software, which turns out to be poorly designed, and the biggest problem there is that the flaws in the design will almost always turn up at a moment when it's least convenient to change it (we'll leave the name-dropping to _your_ imagination ;) )
Cheers,
Andreas
Re: FOs and Areas
Posted by "Peter B. West" <pb...@powerup.com.au>.
J.Pietschmann wrote:
> Peter B. West wrote:
>
>> (does Jörg work?),
>
> Not in the archive.
>
>>
>> I know you are a long-time advocate of sticking with the codebase, and
>> have been very critical of my approach, so I don't want to draw any
>> unwarranted conclusions here. Does the above mean that you are
>> interested in my ideas?
>
>
> I've got a lot of ideas myself, perhaps too many. What the
> project needs is *working* *code*.
Working code is predicated on working ideas, is it not? That's why I
asked about ideas.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: FOs and Areas
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Peter B. West wrote:
> (does Jörg work?),
Not in the archive.
>
> I know you are a long-time advocate of sticking with the codebase, and
> have been very critical of my approach, so I don't want to draw any
> unwarranted conclusions here. Does the above mean that you are
> interested in my ideas?
I've got a lot of ideas myself, perhaps too many. What the
project needs is *working* *code*.
J.Pietschmann
Re: FOs and Areas
Posted by "Peter B. West" <pb...@powerup.com.au>.
J.Pietschmann wrote:
> Victor Mote wrote:
>
>> I guess you are saying that a page-sequence will use too much memory
>> (??).
>> Again, this is a non-issue. Just use a different LayoutStrategy that
>> is more
>> eager.
>
>
> This can be an issue. In a real world file I benchmarked (rendered to 58
> pages),
> the FO tree for the second page sequence run up to >70MB due to a table
> with
> lots of small cells, which generated more than 80k FOs alone. This also
> generates a huge amount of areas, even if they are discarded almost as fast
> as possible, it is easy to max out a 512MB VM configuration. And that's by
> no means an completely unreasonable example.
>
> I wondered why I got a OutOfMemory already during *parsing*...
Joerg (does Jörg work?),
I know you are a long-time advocate of sticking with the codebase, and
have been very critical of my approach, so I don't want to draw any
unwarranted conclusions here. Does the above mean that you are
interested in my ideas?
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
RE: FOs and Areas
Posted by Victor Mote <vi...@outfitr.com>.
J.Pietschmann wrote:
> Victor Mote wrote:
> > I guess you are saying that a page-sequence will use too much
> memory (??).
> > Again, this is a non-issue. Just use a different LayoutStrategy
> that is more
> > eager.
>
> This can be an issue. In a real world file I benchmarked
> (rendered to 58 pages),
> the FO tree for the second page sequence run up to >70MB due to a
> table with
> lots of small cells, which generated more than 80k FOs alone. This also
> generates a huge amount of areas, even if they are discarded
> almost as fast
> as possible, it is easy to max out a 512MB VM configuration. And that's by
> no means an completely unreasonable example.
>
> I wondered why I got a OutOfMemory already during *parsing*...
You must have missed the previous parts of the thread. Your response has
nothing to do with the issue being discussed. Yes, we can no doubt make the
parsing more efficient, the storage of the FO Tree less costly. But that was
not the issue on the table.
Victor Mote
Re: FOs and Areas
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Victor Mote wrote:
> I guess you are saying that a page-sequence will use too much memory (??).
> Again, this is a non-issue. Just use a different LayoutStrategy that is more
> eager.
This can be an issue. In a real world file I benchmarked (rendered to 58 pages),
the FO tree for the second page sequence run up to >70MB due to a table with
lots of small cells, which generated more than 80k FOs alone. This also
generates a huge amount of areas, even if they are discarded almost as fast
as possible, it is easy to max out a 512MB VM configuration. And that's by
no means an completely unreasonable example.
I wondered why I got a OutOfMemory already during *parsing*...
J.Pietschmann
RE: FOs and Areas
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> >>It seems to me, however, that the key to 1) solving the layout
> >>dependencies of FO property expressions, and 2) reducing footprint,
> >>particularly for those long documents which are naturally expressed with
> >>very large fo:flow trees in a few page-sequences, is to have the areas
> >>generated by the FOs as soon as the FOs are parsed and entered into the
> >>FO tree.
> >
> If we are both correct in assuming that layout is still triggered by the
> end of a page-sequence, 2) above is reinforced.
I guess you are saying that a page-sequence will use too much memory (??).
Again, this is a non-issue. Just use a different LayoutStrategy that is more
eager.
> > You have repeatedly REFUSED to answer pretty basic questions that I have
> > asked about how to resolve the dependencies between FO Tree and
> Area Tree.
>
> That's news to me, Victor.
Well, here are the threads:
http://marc.theaimsgroup.com/?l=fop-dev&m=105817834112610&w=2
http://marc.theaimsgroup.com/?l=fop-dev&m=107074009107318&w=2
> > I
> > guess I must settle for your answer above, which I paraphrase
> as follows:
> > "Unless you are willing to do layout in parallel with FO Tree
> building, you
> > can't resolve the FO Tree's dependencies on the Area Tree."
>
> No. I'm saying that the natural, clean, *good* (as in 'quality') way is
> to do layout in parallel with FO Tree building. I'm sure there is a
> myriad of solutions. They just aren't as nice, in the nice sense of the
> word.
OK, we can agree to disagree on this. The only cost is that you'll have to
use your own FO-tree-like-thing, which IIUC, you already have.
> > I disagree. I
> > may be wrong, I may even be very wrong, but why must my pleas for an
> > explanation from you be ignored? You are asking us to make a
> major, major
> > design change, but you REFUSE to tell us why it is necessary.
> >
> Again, that's news to me. I've repeated my reasons on many occasions.
> It boils down to this: there are properties which cannot be resolved
> without reference to an area created by an ancestor FO node of the one
> on which the properties are defined. You say, "Mark it as unresolved,
> and do it later," with no idea of the implementation implications of
> that statement. I wrote an implementation of properties from the
Actually, I think I do have a pretty good idea what the implementation
implications of that statement are. Very simply, if the "get" method is run,
and the relevant Area hasn't been passed, and I need it to resolve the
value, I have to return an "I don't know" value. That means that there is a
logic problem in the layout that needs to be fixed, i.e. the Area should be
created before this request is made. None of this implies that layout must
be run in parallel with FO Tree building.
> Recommendation up, with the *same* approach, and when I got to the end,
> realized it was crap, as I seem to recall saying once or twice before.
> Now I want that area available to me (whether I know its dimensions or
> not) when I parse the expressions.
OK. The question I keep asking is "why"? What is wrong with deferring
property resolution until after parsing? You say that I don't understand the
implementation issues. Well, in plain English, what are they? And you still
haven't addressed the fact that you can have items that are grafted into
multiple places on the FO Tree.
> That is the essential difference. I have a pretty detailed idea of the
> implementation of properties, based on that experience.
>
> There are open questions about this. If I don't answer them, it's not
> that I REFUSE to, but that I don't yet know the answer. I have been out
> of the loop for about 6 months of this year, but in the other 5,
> whenever I have been thinking about FOP design issues, I have been
> thinking about the relationship between FO nodes and areas, and the
> dynamics of layout. I haven't worked it out yet. When I do, this list
> will be first to know.
I wasn't trying to force you to come up with a solution. I was asking you to
evaluate a proposed one. I am trying to find a simple, robust way to deal
with the problem, which does not require concurrent parsing and layout, and
am asking you to evaluate it. I did that out of respect for your experience
here. But your answers come back "you don't understand", "my first
implementation was wrong", "parsing and layout must be concurrent". These
are all non-responsive. You seem to be prejudiced against any idea that
might allow parsing and layout to be separated.
> >>If this were done, then there would *always* exist a reference area for
> >>the percentage expressions, even if that area could not always be
> >>dimensioned. Having a reference for the expression makes it
> >>straightforward to resolve the expression as soon as the referent is
> >>dimensioned, and also makes feasible the re-dimensioning of the
> >>referring areas if the referent is required to change (e.g., by virtue
> >>of being forced onto a new page with different margins.)
> >
> >
> > AFAICT, this is the same effect as what I proposed.
>
> Please explain this part again.
What I proposed is that the "get" method be passed the relevant Area. This
can be null, but if "get" can't compute the value without the Area, then
"get" must return an "I can't compute that" value.
> >>Some of my other preoccupations I have mentioned before. Line-areas
> >>should be filled from the bottom-up, while dimensions filter down from
> >>the top. E.g. my procedure for resolving footnotes implies that
> >>individual line-areas are passed up to the page level (region-body, at
> >>least) along with any impacts (footnotes, before-floats) associated with
> >>the line area. When side-floats occur, the line, and its impact (which
> >>is, I think, the entire side-float, which must therefore be resolved
> >>when encountered) are passed back to the ancestor reference area.
> >>
> >>My focus in this is on the *page*-area-tree, which establishes a subtree
> >>of containers. These containers are then filled from the bottom up by
> >>line-areas, themselves filled from the bottom up by the atoms of the
> >>flow. While the page-area-tree is structured, and dimension issues can
> >>be resolved within it, there remains a close connection with the
> >>corresponding FO subtree, which itself is a subtree of the fo:flow
> >>subtree. Both the page-area-tree and the flow subtree can be very
> >>complex. Think of multi-column layout including tables with footnotes,
> >>and a list or two thrown in for good measure.
> >>
> >>The containers of the page-area-subtree are filled from bottom-level FO
> >>nodes. The bottom-level FO nodes must be able to sensibly construct
> >>line-areas, including all of the line-breaking logic that is required.
> >
> >
> > These are all layout issues. You now have the ability to create
> and use your
> > own LayoutStrategy.
>
> Areas *are* about layout. Working out the relationship between FO tree
> nodes and areas implies working out the structure of layout, for me.
> Before I can draw meaningful conclusions about former, I need to have
> determined the latter. This, again, is my requirement for my design
> decisions, based on my usual bad design principles.
Well, the fundamental disagreement is whether properties must be totally
resolved at parse time. All of the rest of your logic depends on that, and
that is why you have gone down the path that you have, all of which seems
needlessly complex to me. I acknowledge that I may have oversimplified the
problem. If so, having you tell me so is not nearly as helpful as telling me
why.
> > OK, I am upset, but not for the reason that you think. Rather
> than answering
> > the thread that we already had active on this topic, you have chosen to
> > start a new one. This is now at least the third time you and I have been
> > down this path.
>
> Threads get stale. Other things happen. New people arrive. The
> entrance of John and Finn has triggered a lot of discussion about
> alt.design property handling, so the context of discussion does change
> over time. I have, as I said, been racking my brains over these issues
> for some time now. Difficult issues take me a lot of time to resolve.
> This is what I meant earlier by the slowness of my understanding.
Threads get stale when people don't answer. New people haven't changed the
need for sound design. Even when I point out the fact that you haven't
answered the previous threads, you still don't answer them. The context has
not changed even slightly. Difficult issues may take time, but they actually
take forever when they are just dropped in mid-thread. You may be interested
to know that I have spent a lot of time thinking about possible solutions to
this problem also. My purpose here was to maximize the value of your
experience, and to salvage as much as possible from the work you have done
on alt-design. I see now that you are not willing to do that. I'm sorry. It
seems to me to be a net loss for both you and the project. I'll test my
ideas another way.
> > I don't know the history behind why alt.design is on a
> > separate branch, but these issues were probably hashed out back
> then as well
> > (before my time).
>
> alt.design was started as an experiment in the representation of
> properties. I expected that by the time I was finished, the layout
> redesign would have been hashed out in great detail. I couldn't follow
> the process, so I got busy with properties, and a general idea of how to
> structure the parsing, FO tree and Area tree builders. What progress
> has been made on the design of layout in HEAD over that period?
See, I have been under the mistaken impression that we were on the same
team, that your efforts were eventually intended to benefit the FOP project.
I did not understand that this was a contest. If you have forked the
project, then let's set up a separate mailing list for alt-design, so that
I'm not distracting you and you're not distracting me.
For the record, IMO FOP has some infrastructure problems that have brought
layout work to nearly a halt. My work has been aimed at trying to resolve
those problems. I am looking forward to working on layout, but some days you
have to do the dirty work before you can do the fun stuff. One of the
infrastructure problems that I have been trying to solve is alt-design. I do
not mean to imply that its contents are a problem. However, its existence
means that we have at least one unresolved design issue. Either trunk or
alt-design is a superior design. I have made pretty substantial efforts
toward resolving this question for may own satisfaction, and have concluded
that the trunk is superior in general, the properties handling being an
exception. So every time I see an alt-design post, or a new developer being
recruited to that line of thinking, I think to myself "wouldn't it be good
if we could resolve this design issue, come to an agreement, and get
everyone on the same page?" If all of the developers are equal to 100 units
of progress, and 20 units break off to do something else, we are down to 80.
If those 20 are pulling against us (which is true of alt-design IMO), then
we are down to 60. I must admit that it sounds pretty lame for the 20 to ask
why the whole is only working at 60% efficiency. So, one must ask whether
the 20 are correct, whether their design is better. OK, if so, explain or
show how. I understand you to be unable to explain how, but still hopeful of
showing how. That prospect seems dubious. I have never written a line of
code that wasn't predicated on an idea that it would work. OK, so I will
write off the 20 that isn't pulling with us. What I am going to put a stop
to is the 20 pulling against us. At the point in time that you are willing
to explain or show why the alt-design is better, I'll be glad to listen. In
the meantime, please forgive me for ignoring it entirely. And I will stop
trying to reconcile the two.
My attempts to bring unity here have badly backfired. I apologize to all.
> In the past 12 months, I have had at least five developers approach me
> off-line, wanting to get involved in alt.design. I had to turn them
> away, because I had the huge issues of layout design in front of me, and
> nothing definite to give them. They must all have been monitoring
> fop-dev. I didn't see them getting involved in HEAD.
Yes, this is the 20 pulling against us. New developers are needlessly forced
to choose sides. Most want to code, not get involved in political disputes.
I'll go so far as to suggest that the negative effect may be much greater
than 20 when this is considered.
> > Much of the work I have done over the past six months has been,
> consistent
> > with good design principles, to make it easier to accommodate
> your layout
> > ideas, including doing your own FO-Tree-like thing, without
> rewriting all of
> > the rest of the code. (Don't get me wrong -- your code is not the *only*
> > reason I have made these changes, but it has been a big part of the
> > thinking). The trunk code is now flexible enough for you to drop in your
> > code as a LayoutStrategy.
>
> > What galls me is that you insist that everyone
> > else must adopt your approach as well.
>
> Victor, please.
I guess you are disagreeing with my point. You don't have to use the trunk
FO Tree or LayoutStrategies. That leaves Area Tree and Rendering. If you
don't want to use those, then I think you really have a separate product.
Your persistence on the matter can only be interpreted as thinking that HEAD
should adopt your approach.
> > I guess I'll do that when I see that
> > it is, on balance, superior.
>
> Do I ask anything else?
Yes, see above.
> > You won't give me any theoretical ideas why
> > that should be, and AFAICT, there is no practical evidence that it is
> > superior either. (I am talking about FOTree/AreaTree here, not your
> > properties handling, which has been recognized for some time as
> having some
> > merit).
> >
> > Until you are ready to prove the superiority of your design, my humble
> > suggestion is that you drop it in as a LayoutStrategy, and keep
> working on
> > it. This makes the most upstream common code that you use the AreaTree
> > itself.
>
> I have no objection to using LayoutStrategy if it meets alt.design's
> needs. I have had other fish to fry, so I haven't had a chance to
> investigate it.
No hurry. In the meantime, it will be a net benefit to the project for you
to cease and desist from denigrating FOP's design in favor of another whose
benefits cannot be explained.
> I have stated before that our multiple lines of development are
> our biggest
> > problem. I was wrong. As bad as that is, the constant agitation
> of design
> > issues that should be resolved and documented is even worse. Design by
> > committee is a horrible idea anyway, but when people ignore
> critical threads
> > and continue beating the drums anyway, it is downright unbearable.
>
> So I guess it must be my fault that FOP design issues have not been
> resolved and documented in full over the past three years that I have
> been involved. I'm not the Messiah, I'm a very naughty boy.
Well, I won't blame you for all of them, or for not being the Messiah, but I
think it is very fair to hold you accountable for the agitation on the issue
at hand. And, as you well know, this is a big issue. The resolution of
smaller downstream issues rely on the resolution of the bigger upstream
issues. IMO you owe the project one of the following: 1) to throw in with
the trunk design, 2) to explain in logical, supportable terms why your
design is better, or 3) to expect the rest of us to ignore it.
> I realize the tone of this posting has not been entirely irenic. I'll
> try harder.
And I apologize for my part in this desultory conversation. If anyone thinks
I am out of line here, I'll be happy to find something more productive to do
with my time.
Victor Mote
RE: FOs and Areas
Posted by "Andreas L. Delmelle" <a_...@pandora.be>.
> -----Original Message-----
> From: Peter B. West [mailto:pbwest@powerup.com.au]
>
<snip />
>
> I realize the tone of this posting has not been entirely irenic. I'll
> try harder.
>
As a kind-of headz up (seen my understanding, for the moment, is too little
to add anything interesting to the discussion --maybe I should check in the
dev-list archives to see where the antagonism between Victor and yourself
stems from... I sense a missing link here, just haven't found it yet ;) )
Just glad to not have to read at the end that you're totally fed up with
FOP... au contraire!
Cheers,
Andreas
Re: FOs and Areas
Posted by "Peter B. West" <pb...@powerup.com.au>.
Victor Mote wrote:
> Peter B. West wrote:
>
>
>>Herewith some notes on the tortured relationship between the two. As I
>>don't know much about layout in HEAD, I am hoping that differences and
>>(hopefully) correspondences between my ideas and the HEAD redesign can
>>be pointed out by wiser HEADs than mine.
>
>
> I don't claim to be in that category, but hope to be heard anyway.
>
>
>>As I recall, in the original original version, the complete FO tree was
>>built before the Area tree construction was started. When Mark
>>Lillywhite looked at the code, his most important contribution was to
>>realize that the FO tree could be broken up into page-sequences, and the
>>construction of the page-sequence Area subtree could be commenced at the
>>end of each page-sequence.
>
>
> This is still true.
>
As I imagined.
>
>>In my original design, I intended to run parsing, FO tree building and
>>Area tree building in parallel, linked together by producer/consumer
>>buffers. I've done that for parsing and FO tree building, but my
>>concepts of how to link FO tree and Area tree have been in a state of
>>flux for some time.
>
>
> Both maintenance and trunk have parsing and FO Tree building integrated.
> Neither of them nor alt-design have Area Tree building (aka Layout)
> integrated. So really they both come out at the same place AFAICT.
>
Yes, in that sense.
>
>>It seems to me, however, that the key to 1) solving the layout
>>dependencies of FO property expressions, and 2) reducing footprint,
>>particularly for those long documents which are naturally expressed with
>>very large fo:flow trees in a few page-sequences, is to have the areas
>>generated by the FOs as soon as the FOs are parsed and entered into the
>>FO tree.
>
If we are both correct in assuming that layout is still triggered by the
end of a page-sequence, 2) above is reinforced.
>
> Well, some are concerned about memory requirements, some are more concerned
> about speed, others still are more concerned about quality. Hence the
> introduction of the LayoutStrategy concept, which can accommodate the scheme
> that you have suggested here without locking everyone into it.
>
I have no objection in principle to such a solution.
> You have repeatedly REFUSED to answer pretty basic questions that I have
> asked about how to resolve the dependencies between FO Tree and Area Tree.
That's news to me, Victor.
> I
> guess I must settle for your answer above, which I paraphrase as follows:
> "Unless you are willing to do layout in parallel with FO Tree building, you
> can't resolve the FO Tree's dependencies on the Area Tree."
No. I'm saying that the natural, clean, *good* (as in 'quality') way is
to do layout in parallel with FO Tree building. I'm sure there is a
myriad of solutions. They just aren't as nice, in the nice sense of the
word.
> I disagree. I
> may be wrong, I may even be very wrong, but why must my pleas for an
> explanation from you be ignored? You are asking us to make a major, major
> design change, but you REFUSE to tell us why it is necessary.
>
Again, that's news to me. I've repeated my reasons on many occasions.
It boils down to this: there are properties which cannot be resolved
without reference to an area created by an ancestor FO node of the one
on which the properties are defined. You say, "Mark it as unresolved,
and do it later," with no idea of the implementation implications of
that statement. I wrote an implementation of properties from the
Recommendation up, with the *same* approach, and when I got to the end,
realized it was crap, as I seem to recall saying once or twice before.
Now I want that area available to me (whether I know its dimensions or
not) when I parse the expressions.
That is the essential difference. I have a pretty detailed idea of the
implementation of properties, based on that experience.
There are open questions about this. If I don't answer them, it's not
that I REFUSE to, but that I don't yet know the answer. I have been out
of the loop for about 6 months of this year, but in the other 5,
whenever I have been thinking about FOP design issues, I have been
thinking about the relationship between FO nodes and areas, and the
dynamics of layout. I haven't worked it out yet. When I do, this list
will be first to know.
>
>>If this were done, then there would *always* exist a reference area for
>>the percentage expressions, even if that area could not always be
>>dimensioned. Having a reference for the expression makes it
>>straightforward to resolve the expression as soon as the referent is
>>dimensioned, and also makes feasible the re-dimensioning of the
>>referring areas if the referent is required to change (e.g., by virtue
>>of being forced onto a new page with different margins.)
>
>
> AFAICT, this is the same effect as what I proposed.
Please explain this part again.
>
>
>>Some of my other preoccupations I have mentioned before. Line-areas
>>should be filled from the bottom-up, while dimensions filter down from
>>the top. E.g. my procedure for resolving footnotes implies that
>>individual line-areas are passed up to the page level (region-body, at
>>least) along with any impacts (footnotes, before-floats) associated with
>>the line area. When side-floats occur, the line, and its impact (which
>>is, I think, the entire side-float, which must therefore be resolved
>>when encountered) are passed back to the ancestor reference area.
>>
>>My focus in this is on the *page*-area-tree, which establishes a subtree
>>of containers. These containers are then filled from the bottom up by
>>line-areas, themselves filled from the bottom up by the atoms of the
>>flow. While the page-area-tree is structured, and dimension issues can
>>be resolved within it, there remains a close connection with the
>>corresponding FO subtree, which itself is a subtree of the fo:flow
>>subtree. Both the page-area-tree and the flow subtree can be very
>>complex. Think of multi-column layout including tables with footnotes,
>>and a list or two thrown in for good measure.
>>
>>The containers of the page-area-subtree are filled from bottom-level FO
>>nodes. The bottom-level FO nodes must be able to sensibly construct
>>line-areas, including all of the line-breaking logic that is required.
>
>
> These are all layout issues. You now have the ability to create and use your
> own LayoutStrategy.
Areas *are* about layout. Working out the relationship between FO tree
nodes and areas implies working out the structure of layout, for me.
Before I can draw meaningful conclusions about former, I need to have
determined the latter. This, again, is my requirement for my design
decisions, based on my usual bad design principles.
>
>
>>They know nothing of pages, however. When the page-area-tree fills, a
>>page is ready for rendering or intermediate storage, so the
>>page-area-tree "goes-away". That leaves the flow subtree in a suspended
>>state, with the low-level FO nodes demanding space for the next
>>line-area. (Note that blocks aren't "broken" - instead, areas are
>>filled until a line-area comes along which would cause overflow. The
>>offending line-area and its components are conceptually pushed back for
>>reprocessing on the next page. It is this pushed-back line-area which
>>generates the initial demand for more space.)
>
>
> This is currently handled through the area.AreaTreeModel concept, which is
> pretty cool, except that I need to get the LayoutStrategy involved with
> choosing which model to use. (Some LayoutStrategies by definition don't want
> to spit out pages too quickly, which is what you have proposed).
>
Page aren't necessarily spat out too quickly, in the sense that a layout
may not be regarded as final until higher level decisions about
multi-page issues are made. But in my current thinking, layout is
attacked on a page basis, rather than on a page-sequence basis.
>
>>This demand percolates up through the flow active ancestry until it
>>results in a demand for a new page. The page factory associated with
>>the page-sequence and the layout-master-set through the page-sequence
>>master-reference, generates a new page container set, and the relevant
>>area and its dimensions are passed to the flow FO. From here the
>>container availability percolates back down the active flow descendants,
>>with the FO nodes generating new sub-areas, and attaching percentage
>>expressions to their reference areas as control descends. At the
>>bottom, the line-area generators are given new dimensions to deal with,
>>and the bottom-up filling process begins again.
>>
>>I want to diagram this, and look more closely at the nasty cases as I
>>do, but comments are, as always welcome. Victor will be upset, I know,
>>but I can't see the separation of FO tree building and Area tree
>>building. Keiron may be screaming, "That's what I was doing," in which
>>case my apologies.
>
>
> OK, I am upset, but not for the reason that you think. Rather than answering
> the thread that we already had active on this topic, you have chosen to
> start a new one. This is now at least the third time you and I have been
> down this path.
Threads get stale. Other things happen. New people arrive. The
entrance of John and Finn has triggered a lot of discussion about
alt.design property handling, so the context of discussion does change
over time. I have, as I said, been racking my brains over these issues
for some time now. Difficult issues take me a lot of time to resolve.
This is what I meant earlier by the slowness of my understanding.
> I don't know the history behind why alt.design is on a
> separate branch, but these issues were probably hashed out back then as well
> (before my time).
alt.design was started as an experiment in the representation of
properties. I expected that by the time I was finished, the layout
redesign would have been hashed out in great detail. I couldn't follow
the process, so I got busy with properties, and a general idea of how to
structure the parsing, FO tree and Area tree builders. What progress
has been made on the design of layout in HEAD over that period?
In the past 12 months, I have had at least five developers approach me
off-line, wanting to get involved in alt.design. I had to turn them
away, because I had the huge issues of layout design in front of me, and
nothing definite to give them. They must all have been monitoring
fop-dev. I didn't see them getting involved in HEAD.
>
> Much of the work I have done over the past six months has been, consistent
> with good design principles, to make it easier to accommodate your layout
> ideas, including doing your own FO-Tree-like thing, without rewriting all of
> the rest of the code. (Don't get me wrong -- your code is not the *only*
> reason I have made these changes, but it has been a big part of the
> thinking). The trunk code is now flexible enough for you to drop in your
> code as a LayoutStrategy.
> What galls me is that you insist that everyone
> else must adopt your approach as well.
Victor, please.
> I guess I'll do that when I see that
> it is, on balance, superior.
Do I ask anything else?
> You won't give me any theoretical ideas why
> that should be, and AFAICT, there is no practical evidence that it is
> superior either. (I am talking about FOTree/AreaTree here, not your
> properties handling, which has been recognized for some time as having some
> merit).
>
> Until you are ready to prove the superiority of your design, my humble
> suggestion is that you drop it in as a LayoutStrategy, and keep working on
> it. This makes the most upstream common code that you use the AreaTree
> itself.
I have no objection to using LayoutStrategy if it meets alt.design's
needs. I have had other fish to fry, so I haven't had a chance to
investigate it.
>
> I have stated before that our multiple lines of development are our biggest
> problem. I was wrong. As bad as that is, the constant agitation of design
> issues that should be resolved and documented is even worse. Design by
> committee is a horrible idea anyway, but when people ignore critical threads
> and continue beating the drums anyway, it is downright unbearable.
So I guess it must be my fault that FOP design issues have not been
resolved and documented in full over the past three years that I have
been involved. I'm not the Messiah, I'm a very naughty boy.
I realize the tone of this posting has not been entirely irenic. I'll
try harder.
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
RE: FOs and Areas
Posted by Victor Mote <vi...@outfitr.com>.
Peter B. West wrote:
> Herewith some notes on the tortured relationship between the two. As I
> don't know much about layout in HEAD, I am hoping that differences and
> (hopefully) correspondences between my ideas and the HEAD redesign can
> be pointed out by wiser HEADs than mine.
I don't claim to be in that category, but hope to be heard anyway.
> As I recall, in the original original version, the complete FO tree was
> built before the Area tree construction was started. When Mark
> Lillywhite looked at the code, his most important contribution was to
> realize that the FO tree could be broken up into page-sequences, and the
> construction of the page-sequence Area subtree could be commenced at the
> end of each page-sequence.
This is still true.
> In my original design, I intended to run parsing, FO tree building and
> Area tree building in parallel, linked together by producer/consumer
> buffers. I've done that for parsing and FO tree building, but my
> concepts of how to link FO tree and Area tree have been in a state of
> flux for some time.
Both maintenance and trunk have parsing and FO Tree building integrated.
Neither of them nor alt-design have Area Tree building (aka Layout)
integrated. So really they both come out at the same place AFAICT.
> It seems to me, however, that the key to 1) solving the layout
> dependencies of FO property expressions, and 2) reducing footprint,
> particularly for those long documents which are naturally expressed with
> very large fo:flow trees in a few page-sequences, is to have the areas
> generated by the FOs as soon as the FOs are parsed and entered into the
> FO tree.
Well, some are concerned about memory requirements, some are more concerned
about speed, others still are more concerned about quality. Hence the
introduction of the LayoutStrategy concept, which can accommodate the scheme
that you have suggested here without locking everyone into it.
You have repeatedly REFUSED to answer pretty basic questions that I have
asked about how to resolve the dependencies between FO Tree and Area Tree. I
guess I must settle for your answer above, which I paraphrase as follows:
"Unless you are willing to do layout in parallel with FO Tree building, you
can't resolve the FO Tree's dependencies on the Area Tree." I disagree. I
may be wrong, I may even be very wrong, but why must my pleas for an
explanation from you be ignored? You are asking us to make a major, major
design change, but you REFUSE to tell us why it is necessary.
> If this were done, then there would *always* exist a reference area for
> the percentage expressions, even if that area could not always be
> dimensioned. Having a reference for the expression makes it
> straightforward to resolve the expression as soon as the referent is
> dimensioned, and also makes feasible the re-dimensioning of the
> referring areas if the referent is required to change (e.g., by virtue
> of being forced onto a new page with different margins.)
AFAICT, this is the same effect as what I proposed.
> Some of my other preoccupations I have mentioned before. Line-areas
> should be filled from the bottom-up, while dimensions filter down from
> the top. E.g. my procedure for resolving footnotes implies that
> individual line-areas are passed up to the page level (region-body, at
> least) along with any impacts (footnotes, before-floats) associated with
> the line area. When side-floats occur, the line, and its impact (which
> is, I think, the entire side-float, which must therefore be resolved
> when encountered) are passed back to the ancestor reference area.
>
> My focus in this is on the *page*-area-tree, which establishes a subtree
> of containers. These containers are then filled from the bottom up by
> line-areas, themselves filled from the bottom up by the atoms of the
> flow. While the page-area-tree is structured, and dimension issues can
> be resolved within it, there remains a close connection with the
> corresponding FO subtree, which itself is a subtree of the fo:flow
> subtree. Both the page-area-tree and the flow subtree can be very
> complex. Think of multi-column layout including tables with footnotes,
> and a list or two thrown in for good measure.
>
> The containers of the page-area-subtree are filled from bottom-level FO
> nodes. The bottom-level FO nodes must be able to sensibly construct
> line-areas, including all of the line-breaking logic that is required.
These are all layout issues. You now have the ability to create and use your
own LayoutStrategy.
> They know nothing of pages, however. When the page-area-tree fills, a
> page is ready for rendering or intermediate storage, so the
> page-area-tree "goes-away". That leaves the flow subtree in a suspended
> state, with the low-level FO nodes demanding space for the next
> line-area. (Note that blocks aren't "broken" - instead, areas are
> filled until a line-area comes along which would cause overflow. The
> offending line-area and its components are conceptually pushed back for
> reprocessing on the next page. It is this pushed-back line-area which
> generates the initial demand for more space.)
This is currently handled through the area.AreaTreeModel concept, which is
pretty cool, except that I need to get the LayoutStrategy involved with
choosing which model to use. (Some LayoutStrategies by definition don't want
to spit out pages too quickly, which is what you have proposed).
> This demand percolates up through the flow active ancestry until it
> results in a demand for a new page. The page factory associated with
> the page-sequence and the layout-master-set through the page-sequence
> master-reference, generates a new page container set, and the relevant
> area and its dimensions are passed to the flow FO. From here the
> container availability percolates back down the active flow descendants,
> with the FO nodes generating new sub-areas, and attaching percentage
> expressions to their reference areas as control descends. At the
> bottom, the line-area generators are given new dimensions to deal with,
> and the bottom-up filling process begins again.
>
> I want to diagram this, and look more closely at the nasty cases as I
> do, but comments are, as always welcome. Victor will be upset, I know,
> but I can't see the separation of FO tree building and Area tree
> building. Keiron may be screaming, "That's what I was doing," in which
> case my apologies.
OK, I am upset, but not for the reason that you think. Rather than answering
the thread that we already had active on this topic, you have chosen to
start a new one. This is now at least the third time you and I have been
down this path. I don't know the history behind why alt.design is on a
separate branch, but these issues were probably hashed out back then as well
(before my time).
Much of the work I have done over the past six months has been, consistent
with good design principles, to make it easier to accommodate your layout
ideas, including doing your own FO-Tree-like thing, without rewriting all of
the rest of the code. (Don't get me wrong -- your code is not the *only*
reason I have made these changes, but it has been a big part of the
thinking). The trunk code is now flexible enough for you to drop in your
code as a LayoutStrategy. What galls me is that you insist that everyone
else must adopt your approach as well. I guess I'll do that when I see that
it is, on balance, superior. You won't give me any theoretical ideas why
that should be, and AFAICT, there is no practical evidence that it is
superior either. (I am talking about FOTree/AreaTree here, not your
properties handling, which has been recognized for some time as having some
merit).
Until you are ready to prove the superiority of your design, my humble
suggestion is that you drop it in as a LayoutStrategy, and keep working on
it. This makes the most upstream common code that you use the AreaTree
itself.
I have stated before that our multiple lines of development are our biggest
problem. I was wrong. As bad as that is, the constant agitation of design
issues that should be resolved and documented is even worse. Design by
committee is a horrible idea anyway, but when people ignore critical threads
and continue beating the drums anyway, it is downright unbearable.
Victor Mote
Re: FOs and Areas
Posted by Glen Mazza <gr...@yahoo.com>.
--- "Peter B. West" <pb...@powerup.com.au> wrote:
> It seems to me, however, that the key to 1) solving
> the layout
> dependencies of FO property expressions, and 2)
> reducing footprint,
> particularly for those long documents which are
> naturally expressed with
> very large fo:flow trees in a few page-sequences, is
> to have the areas
> generated by the FOs as soon as the FOs are parsed
> and entered into the
> FO tree.
>
Keiron indicated [1] that we have that something of
that already in the HEAD version--so FOP is no longer
building the whole FO tree and *then* the area tree.
Now how *good* the 1.0's implementation is may be
another matter. It may be something worthwhile for
you to take a look at.
Glen
[1]
http://marc.theaimsgroup.com/?l=fop-dev&m=105270887501490&w=2
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/