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]
