On Sep 12, 2008, at 08:27, Jeremias Maerki wrote:
On 11.09.2008 22:59:31 Vincent Hennebert wrote:
Jeremias Maerki wrote:
<snip />
At any rate, I don't think that generating FOs for missing table
cells
is the right approach.
Why?
Elaborating on "additional overhead": You would generate additional
FOs
for non-existent table-cells. For each FO, a layout manager is created
which will also need to be called. Table layout will need to run
through
more cells per row than necessary even though they're empty. More
objects, more CPU cycles. Granted we're probably not talking about
a lot
of empty table-cells but still.
Sounds about right to me. Besides that, the instance size of a
TableCell is large enough to justify not generating any more of these
than strictly necessary. Let alone increase the amount of memory used
by the FO tree even further if we would also start generating
implicit empty Blocks...
To work around that, one would need to create a new FONode subclass,
especially meant to deal with missing cells (no need to reserve space
for references to properties and/or child-nodes). If that particular
type is then mapped to a dedicated (very minimal) LM implementation,
this could reduce the overhead somewhat.
On the other hand, all is well when you only consider very simple
cases, where there's a handful of empty positions in a whole table
(or none at all).
Once we start considering more exceptional cases, say a 20x200 grid,
with only a handful of effective cells per row, it becomes apparent
that generating dummy FONodes for the empty grid-units is probably
not the best of solutions (in terms of generality and scalability).
If there is only one position per row that is effectively occupied by
a table-cell, then we would, what, generate 19x200 'missing' cells
(and blocks)? Yuck!
RowPainter is area-generation stage. My solution is just making sure
areas are generated with the information that is available anyway.
It's
not doing anything in a place where it shouldn't do it.
Ultimately, that is the only place where this should have effects, I
think.
Seems like we don't really need dummy nodes for anything layout-
related, so why precisely should they exist at that point?
Unless a darn' *good* answer to this question is given (i.e. a point
other than a rigid adherence to the 'no-duplication' rule), I would
even veto the proposal of making any adjustments in the fo.table
package to solve this... but that's just me. ;-)
So I'm not convinced that my solution is bad or that your solution is
better.
The better approach is always the one that works for the simple as
well as the more difficult cases, without too big a drain on
resources for the latter.
I see Vincent's point, but I don't agree that the proposed solution
is actually improving anything. Seems like we should be looking for a
way to eliminate the code-duplication without touching any other
packages than is currently the case. Not possible? While I can't
really offer an alternative here, I don't believe that...
I'd like to point out that FOP in its entirety is a continuous work-
in-progress. The XSL-FO Rec is not a cake-walk to implement (some of
the commercial implementations even go so far as to simply be non-
compliant, to reduce complexity)
As such, there are always going to be 'unfinished' pieces of code, or
parts that can be improved upon. The base rule remains: if it works,
and it didn't work before, the balance is positive. If we take that
simple rule away, this will in the long run be counter-productive, I
think. No committer should
One of the consequences of being what we are, and having an
imagination, is that, no matter what, we can /always/ find something
that would be/look better... Good thing, it can be a goal for the
future.
Cheers
Andreas
