Another problem with Marker.rebind()
I noticed another problem with Marker.rebind(): When the same marker is retrieved more than once, the first rebind is overwritten with the second. See this example: fo:static-content flow-name=xsl-region-after fo:block text-align=start fo:inline color=redred: fo:retrieve-marker retrieve-class-name=class retrieve-boundary=page retrieve-position=first-starting-within-page//fo:inline, fo:inline color=blueblue: fo:retrieve-marker retrieve-class-name=class retrieve-boundary=page retrieve-position=first-starting-within-page/./fo:inline /fo:block /fo:static-content Both markers are printed in blue. Perhaps it would be a solution to clone the subtree below the marker to retrieve-marker, and rebind that copy. That would be another example of layout dependent data in the FO tree. If every retrieve-marker would always discard its existing subtree and copy the subtree under the retrieved marker in LM.preloadnext(), this would prevent later runs with the same FO tree from reusing markers that would pertain to the layout of an earlier run. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
RE: Another problem with Marker.rebind()
Simon Pepping wrote: Both markers are printed in blue. Perhaps it would be a solution to clone the subtree below the marker to retrieve-marker, and rebind that copy. That would be another example of layout dependent data in the FO tree. If every Just by way of clarification, this is no doubt de facto true in the current FOP HEAD code, but, depending on the design, IMO it is not a necessity. Peter West and I discussed this some, probably around August of 2003. I thought at the time that a GraftingPoint interface which lived in the FOTree could be used to handle this concept without disrupting the independence of the FOTree. I am now of the opinion that the solution may be even simpler. If you take the idea that the AreaTree is a view of the FOTree, so that Areas essentially inherit and/or derive traits from their generated-by FOTree nodes (instead of having bound values cached in them), then the solution may be as simple as using some redirects when static content is involved. This depends, in turn, on late binding (really, no binding) of the property values, which does not appear to be possible with the current FOP design. I am close to being able to demonstrate all of this within FOray, but I am not sure whether I will get it done in time for the upcoming 0.2 release, although it will have an independent FOTree. Victor Mote
Re: Another problem with Marker.rebind()
Victor Mote wrote: Simon Pepping wrote: Both markers are printed in blue. Perhaps it would be a solution to clone the subtree below the marker to retrieve-marker, and rebind that copy. That would be another example of layout dependent data in the FO tree. If every There is a certain wry entertainment value in watching the wheel being re-invented. Before I arrived, this problem was known as re-parenting. In my discussions of the issue, years after re-parenting was first discussed, there is even a diagram - shock, horror! - of the basic process proposed for Defoe (then the non-longer visible, but still present, Alt-design). Oh, I'm sorry, it involves re-thinking the building of the FO tree, using stream parsing. It does render the marker problem trivial, but so what. We have HEAD. Finn's off scratching his head vigorously, having just realized that there is a fundamental flaw in the design wrt markers. It will be interesting to see what emerges. Just by way of clarification, this is no doubt de facto true in the current FOP HEAD code, but, depending on the design, IMO it is not a necessity. Peter West and I discussed this some, probably around August of 2003. I thought at the time that a GraftingPoint interface which lived in the FOTree could be used to handle this concept without disrupting the independence of the FOTree. I am now of the opinion that the solution may be even simpler. Couldn't agree more, Victor. If you take the idea that the AreaTree is a view of the FOTree, so that Areas essentially inherit and/or derive traits from their generated-by FOTree nodes (instead of having bound values cached in them), You can combine both ideas. then the solution may be as simple as using some redirects when static content is involved. Bingo! This depends, in turn, on late binding (really, no binding) of the property values, ...and again... which does not appear to be possible with the current FOP design. ...and again. I am close to being able to demonstrate all of this within FOray, but I am not sure whether I will get it done in time for the upcoming 0.2 release, although it will have an independent FOTree. Thanks for pointing all of this out, Victor. It's nice to see some convergence on these ideas. Interesting that it must happen in Defoe and Foray. Peter
Re: Another problem with Marker.rebind()
- Original Message - From: Peter B. West [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 8:20 PM Subject: Re: Another problem with Marker.rebind() Oh, I'm sorry, it involves re-thinking the building of the FO tree, using stream parsing. Peter, are you saying that a pull parser is more computationally powerful than a SAX Parser--or is it just much more convenient? I don't think pull parsers can do more than SAX Parsers for the simple reason that you can implement a pull parser using a SAX Parser, no? Glen
Re: Another problem with Marker.rebind()
Glen Mazza wrote: Oh, I'm sorry, it involves re-thinking the building of the FO tree, using stream parsing. Peter, are you saying that a pull parser is more computationally powerful than a SAX Parser--or is it just much more convenient? I don't think pull parsers can do more than SAX Parsers for the simple reason that you can implement a pull parser using a SAX Parser, no? Firstly, my apologies to all for the tone of my previous message. Too little sleep, too much gall. Defoe uses SAX for its stream parsing. Consequently, it's less computationally efficient. To use an extreme example, for many years compilers were less computationally efficient than coding with assembler. There are inefficiencies at every level of a computer system, from the microcode up. At any level, does the interface ease the development of solutions built on top? For most of my initial stint at FOP, I was obsessively concerned with micro-efficiencies, and I displayed my ignorance concerning this on many occasions. (Ask Jeremias or Joerg.) I have watched improvements in the performance of JVMs overtake my obsessions while I have been working on FOP. So much for not teaching an old dog new tricks. In spite of those concerns, I went with an inefficient parsing mechanism, because it mightily clarified the parsing process. As a completely unintentional side-effect, it gave me the tools to solve the really critical FOP performance problem on large files. This isn't going to be solved by micro-efficiencies on FO tree storage. Unfortunately, software developers are an intensely conservative lot. R J Neuhaus has a lovely term, the herd of independent minds. And he's not even describing software developers. It will be a long time before the SAX franchise falters. The curious thing is that Microsoft never went down the SAX road. They get by. Defoe is a big job, and I need all the help I can get, but I'll get there. Peter
