Response below (one of these glorious days, I can stop using Outlook...)
-----Original Message-----
From: Glen Mazza [mailto:glenmazza@xxxxxxxxx]
Sent: Tuesday, May 27, 2003 7:49 PM
To: fop-dev@xxxxxxxxxxxxxx; vic@xxxxxxxxxxx
Subject: RE: hack to avoid memory overflow with tables
>FOP is ultimately a mathematical entity, so we should
be able to avoid the matter-of-opinion conclusions
that would lead to multiple layout strategies.<
While I believe this is generally true, I remain skeptical that there is always
a perfect layout strategy available every time. I think this might especially
be true in cases of overconstraint relaxing or recovering from anomalous
documents. My first impression is that either of these processes will largely
be governed by heuristics, and it's my experience that where heuristics are
involved, matters of opinion quickly follow.
Moreover, is FOP really that far from, say, the HTML rendering engine in a web
browser with respect to layout decisions? I see a lot of "interpretations" and
"opinions" going on in those engines, which is why two browsers sometimes
interpret my HTML table layouts in different ways.
>While there can be plenty of discussion of how best to
obtain #1 and #2, once it is determined that solution
A takes x seconds and solution B takes x + 2 seconds,
you tend to go with solution A. So over the long
term, multiple layout strategies may not be needed. <
They may not, but I think they might. I can safely say that I haven't read all
of the FO spec, but I do see the word "may" cropping up from time to time with
respect to spec compliance. I don't think we can create a single layout
strategy that correctly selects the correct side of that "may" every time. For
certain classes of documents (which, for argument's sake, aren't readily
detectable in a programmatic way), the choice has to be made, and why not leave
that choice in the hands of programmers and operators?
I just mention these sorts of things because, all too often, spec compliance
eventually becomes a matter of opinion anyway.
|
