replace extension bookmarks with XSL 1.1 ones?
Team, Silly confirmation question here -- is the 1.1 XSL Spec's fo:bookmark-tree, fo:bookmark, and fo:bookmark-title [1] basically the same thing as our fox:bookmarks, fox:outline, and fox:title, respectively? (i.e., they're for off-document PDF bookmarks?) Its mandated location [2] in the FO is the same place where our fox: equivalents are. (The only issue giving me pause is that fo:bookmark apparently generates inline areas according to the spec [3], i.e., it appears to be something that is *on* the document.) Anyway, if they're equivalent, I would like to bring these three 1.1 elements in (I'm guessing a new pagination.bookmarks package, we can move it around later) and drop our fox: equivalents. Backwards compatibility with 0.20.5 is already broken because of the addition of fox:bookmarks in 1.0, as well as the enforced validation scheme, so we can fortunately focus on the best design here. There is a differing namespace issue that will need to be taken care of eventually but I think we can tend to that afterwards without much hassle. (We can handle it now, if anyone has ideas.) My primary goal for the moment is to pull out our bookmark extension elements and put in the official XSL elements (even if 1.1) instead. Thoughts? Objections? Thanks, Glen [1] http://www.w3.org/TR/xsl11/#d0e12873 [2] http://www.w3.org/TR/xsl11/#fo_root [3] http://www.w3.org/TR/xsl11/#fo_bookmark
Re: Large files.
Finn Bock wrote: The loop can be stopped when we temporary run out of FO tree nodes and restarted again when new nodes has been added. I suppose that the FO tree can then be viewed as a stream of FO nodes. [Victor] This model probably works fine if you never need to look ahead, but there are numerous examples (well discussed in the archives) where one does need to do that, the most obvious being automatic table layout. Peter's solution to that is pull parsing, which probably works, but forces an intermingling of interests that I need to avoid. My solution is to serialize the FOTree as necessary Did you notice that if a FOTree (or a fragment of it) is serialized to a preorder sequential representation with end markers, the preorder, postorder and child events can be fired directly from the input stream? Which is what Defoe does. Now let go of the notion of firing events, and we are in agreement. The SAX model is not relevant once the basic parsing is done. With a full-fledged stream parser, it won't be relevant at all. IOW the event based layout can work both of a normal parent/children linked tree and a sequential tree. Peter
Re: Large files.
The loop can be stopped when we temporary run out of FO tree nodes and restarted again when new nodes has been added. I suppose that the FO tree can then be viewed as a stream of FO nodes. [Victor] This model probably works fine if you never need to look ahead, but there are numerous examples (well discussed in the archives) where one does need to do that, the most obvious being automatic table layout. Peter's solution to that is pull parsing, which probably works, but forces an intermingling of interests that I need to avoid. My solution is to serialize the FOTree as necessary Did you notice that if a FOTree (or a fragment of it) is serialized to a preorder sequential representation with end markers, the preorder, postorder and child events can be fired directly from the input stream? IOW the event based layout can work both of a normal parent/children linked tree and a sequential tree. The bottom line is that, if you conceivably need to see both the beginning and end of the input simultaneously (which we do), I can see a need for several passes over the same tree fragment, but do we really need to see the beginning and the end at the same time? The auto table example appears to need 2 or 3 sequential passes over the table subtree (one to find the minimum/maximum column width and one to do the actual layout), but the layout process is still sequential. regards, finn
