Re: FOs and Areas
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] 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
-Original Message- From: J.Pietschmann [mailto:[EMAIL PROTECTED] 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
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] 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
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 Jrg'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 Jrg 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 [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 18, 2003 3:26 AM Subject: Re: FOs and Areas Peter B. West wrote: (does Jrg 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
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
RE: FOs and Areas
-Original Message- From: Victor Mote [mailto:[EMAIL PROTECTED] 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
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?
8 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
J.Pietschmann wrote: Peter B. West wrote: (does Jrg 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
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
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
-Original Message- From: Victor Mote [mailto:[EMAIL PROTECTED] 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
Peter B. West wrote: (does Jrg 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
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 [EMAIL PROTECTED]
RE: FOs and Areas
-Original Message-
From: John Austin [mailto:[EMAIL PROTECTED]
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:[EMAIL PROTECTED]
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
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
RE: FOs and Areas
-Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] 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
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-devm=105817834112610w=2 http://marc.theaimsgroup.com/?l=fop-devm=107074009107318w=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
Re: FOs and Areas
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
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
--- Peter B. West [EMAIL PROTECTED] 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-devm=105270887501490w=2 __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
RE: FOs and Areas
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
