Re: Redesign Ideas II
At 12:08 AM 6/28/01 -0300, Arved Sandstrom wrote:
>A side-float becomes a child of the nearest ancestor reference area (I still
>need to figure out what the hell the spec means by "reference area chain",
>so this may change). This will usually (but not always) be a column area
>within a span area within a main-reference-area. The location of the anchor
>will determine the current ("nearest") ancestor reference area.
OK, I determined what is meant by reference-area-chain in this context. The
sequence of normal-flow-reference-area (read "column areas") generated by a
single fo:region-body are considered to be a "reference-area-chain" (there
are other possibilities, in general).
According to the spec, an xsl-side-float area may become a child of a later
reference area in the reference-area-chain. Now that statement is clear (I
thought I knew what it meant, but I hadn't found the definition).
I am still wrestling with a perceived ambiguity (no, reading the CSS2 spec
doesn't help :-)), so it will be a few days before I update the design
discussion on side-floats.
Regards,
Arved Sandstrom
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Redesign Ideas II
Here are some initial thoughts on another aspect of redesign. This is complementary to Karen Lease's thoughts from one week ago (20th June). This is not a formal design document. The intention would be to turn this into one, though, within a couple of weeks, that will sit in CVS. HIGH-LEVEL PICTURE We can picture 3 cooperating subsystems: one is oriented toward pages, one to blocks, and one to inlines. Karen described the operation of the latter - this fundamentally reduces to providing an Inline FlowSet (IFS) corresponding to each "raw" block. A "raw" block maps to an original FO that generates block-level areas (not necessarily normal). The block-oriented and inline-oriented subsystems are processes, whereas the page-oriented subsystem becomes rather more of an "on-demand" page-provider than it is now. We assume for the purposes of this discussion that there exists a "page factory" that produces the "next" page as required, with suitable request flags. It is the function of the inline-building process to provision a number of queues: (1) normal areas (xsl-normal), side-floats (xsl-side-float), and all anchors (xsl-anchor); (2) before-floats (xsl-before-float); (3) footnote bodies (xsl-footnote). Absolutely-positioned areas (xsl-absolute and xsl-fixed, pertaining to absolutely-positioned block-containers) need not be maintained as a queue - they are taken out of the normal flow and do not affect layout of later stuff (we do of course need to maintain a pointer to the page that they must be on, as required by 7.4.1, Restrictions). All areas will possess complete traits (returned-by, generated-by, is-reference-area, for example, plus parent ID) as required by the spec, both directly and indirectly derived. It is the function of the page-layout (block-oriented) process to consume material in these queues, and to layout pages. PAGE LAYOUT *** Basic Operation *** Def'n: "basic" means no keeps, no floats, no footnotes, no forward references. I will also not discuss tables until Part 2 of this note (to appear in a few days). The page layout engine (PLE) pops areas from the normal queue. Each area uniquely maps to an IPD. In the most basic situation, the basic IPD is restricted to 2 possibilities on any given page-master, corresponding to span='all' or span='none'. The PLE instructs each IFS to line-break itself, given appropriate constraints (generally, the base IPD and the available BPD). Breaks are unambiguous and simple. They terminate the current page. The "page factory" will be provided with sufficient information to react appropriately (e.g. possible production of blank pages). The PLE will make use of an auxiliary Space-Specifier-Resolution module as required. *** Introduction of Keeps *** .within-line keeps affect line-breaking, and are of no concern to the PLE. In addition, all keeps that are negated by breaks are removed or suitably modified. .within-column and .within-page keeps consist of keep-with-next (KWN), keep-with-previous (KWP) and keep-together (KT). A KWP on area N+1 will be translated into a KWN on area N. All KT conditions will be translated into KWN conditions (except for the last area affected by a KT). Superimposed KWN conditions that result will be refined into one KWN, that has the highest strength. [ Note: please poke holes in this, if you think of any ] This process will provide the PLE with "KWN chains" that make it much easier to compute actual page-breaks. I will talk more about this; this will be treated in detail in design. I invite lots of comment and participation. :-) *** Introduction of Before-Floats and Footnotes *** Discussion below implicitly assumes proper treatment of xsl-before-float-separator and xsl-footnote-separator. That is, when calculations of BPD are made, the static-contents, if any, must be included. -- Before-Floats -- Before floats are placed at the top of the page containing the anchor, or on a subsequent page, and must be properly ordered in their class. As anchor areas are encountered in the normal queue, the decision-making is two-fold: 1) does the before-float "fit" on the current page, and if so, does the anchor get displaced to the next page? [ "fit" means an assessment based on heuristics similar to fractional coverage rules for floats as found in LaTeX; I anticipate exposing the capability to adjust these heuristics through a strategy object that gets loaded by user configuration data ]; and 2) does retaining an otherwise acceptable before-float on the current page represent an optimal choice in light of any keep conditions on text? Decision may be made to punt the float to the next page. -- Footnotes -- I believe that very similar design choices can be made here as for before-floats. The main difference is that extra weight will be placed on starting the footnote body on the same page as the anchor (that is, the last area returned by the inline), and that once star
Re: Redesign ideas
Quoting Karen Lease <[EMAIL PROTECTED]>: [ SNIP ] > FOP REDESIGN > This is all focused on layout and should be fairly independent of the > work mentioned above. > > We can think of layout proceeding in two parallel but interdependent > processes, one of which is block oriented and the other of which is > inline-oriented. I'll let Arved talk more about the block side. Here are > a few of the main ideas of the design for the new inline layout > strategy. There will be more formal design docs coming! I will make a point of following up with my design thoughts with a quickness; namely, within a week. It would be sooner but my FOP material is in Nova Scotia and I'm in Mountain View, California. :-) Regards, Arved --- This mail was sent through the Nova Scotia Provincial Server, with technical resources provided by Chebucto Community Net. http://nsaccess.ns.ca/mail/ http://www.chebucto.ns.ca/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Redesign ideas
Hi all, Here is a contribution to the redesign vs. maintenance thread on FOP. I've split my ideas into two parts: work which is somewhat independent of redesign and the redesign itself. Here goes! WORK WHICH IS SOMEWHAT INDEPENDENT OF REDESIGN It seems like there is fairly broad agreement that we must continue to support and extend fop 0.xx as we try to work on the redesign. 0.19 is a good example of a new release that adds a lot of value. There are several areas we can continue to address in this thread without necessarily writing a lot of code which will be zapped by the redesigned version. - properties: the "inherit" keyword in a general way, some unimplemented functions, lots of properties which aren't handled, properties with "special" syntax like text-decoration, extend and improve the PropertyManager idea - rendering: there probably will be some changes here once we've worked on layout, but in the meantime some things come to mind: - doFrame: still some pixel errors in some cases when framing borders - see whether it is possible to use PDF coordinate transforms to handle rotation (reference-orientation) and scaling, rather than explicitly dividing all coordinates by 1000 for millipoints as now (would this help with those 1 pixel rounding errors?) - tables: these will probably be heavily affected by the redesign, but they generate so many questions that it's probably worthwhile adding a few things anyway, notably row-spanning, better alignment, better cell-borders (it seems as though the issue of how to handle borders on table-row and column will be clarified in the PR) - FO tree building: perhaps use addChild to check constraints on which objects can be added where, rather than doing this in the layout method. Could also handle things like table-cell as direct children of table-body, header, footer rather than always being in a row - more work on testing and documentation FOP REDESIGN This is all focused on layout and should be fairly independent of the work mentioned above. We can think of layout proceeding in two parallel but interdependent processes, one of which is block oriented and the other of which is inline-oriented. I'll let Arved talk more about the block side. Here are a few of the main ideas of the design for the new inline layout strategy. There will be more formal design docs coming! Some major goals: 1. Create actual InlineArea objects for Inline type FOs, including arbitrary nesting. We have to do this to correctly handle background, borders, alignment and spacing around and between these objects. This may complicate the line breaking a bit, but it's necessary 2. Separate the line breaking strategy from the area creation process. The idea is to first create what I'm calling "InlineFlowSet" (IFS) under BLock FOs during the first part of the layout process. An IFS is simply an tree of InlineArea objects which hasn't yet been broken up into lines. The actual breaking of the IFS into LineAreas is then done when the block layout gets to the point of needing some more material to layout. The idea is that at that point, we know what the Inline Progression Dimension (IPD) is and also have positioned any side-floats which were anchored in earlier FOs. The line-breaking handles spacing between inline objects, interfaces with the Hyphenation module, and determines possible breakpoints. The design should make it possible to substitute a basic "one line at a time" break strategy with a more global multi-line strategy at some later date. Line-breaking has a dependence on the block-layout concerning side-floats, which influence the available IPD. Since it may be necessary to redo the breaking process several times, it doesn't actually split inline areas until the decisions are finalized. Intermediate decisions are remembered as "pointers/offsets" into the IFS tree. 3. As LineAreas are created, we propagate keep and space information to that level so that the block layout strategy can use those to make its decisions. 4. We should be able to run these processes as actual Java threads in a kind of producer/consumer model. 5. Lists and Tables: low level handling uses Blocks and IFS. But the block-layout here is more complex because it can't just "pull" one line at a time. Looking forward to your feedback, Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
