David Carlisle wrote:
but there's no *inherent* limitation in the ability of FO-based
systems to produce typographic results as good as those produced by any
other system.
Actually I disagree. XSLT inherits from DSSL implementations a lack of
feedback from the typesetter to the rest of the system.
this means that there are some things you just can not do without some
non standard extension.
Actually, I was thinking of things like line breaking and character
spacing, not area positioning. You are of course correct that without
feedback from the paginator to the FO generator, there are certain
layout problems that cannot be solved by an automatic system.
[...]
I'm a bit confused here because I seem to be agreeing with your whole
message including this bit, which seems to not agree with teh "inherent
limitation" qute above, unless you mn that these feedback issues could
be fixed in a revised spec?
Yes--on the EXSLFO list I've discussed several possible low-cost
solutions to this limitation, and an architected solution in the spec
itself is certainly possible. It's also important to keep in mind that
while XSL was designed to support a two-stage generate/paginate process,
it does not require that--there's no reason an FO implementation
couldn't provide a private feedback mechanism in an all-in-one processor.
My low-cost solution is simply to define a mechanism by which FO
processors can be directed to generate auxiliary, or "side" files, with
page- and marker-specific information that can be fed back into an XSLT
process. This would enable a multi-pass, layout-aware process at minimal
additional cost to FO implementations.
Cheers,
Eliot
--
W. Eliot Kimber, eliot(_at_)isogen(_dot_)com
Consultant, ISOGEN International
1016 La Posada Dr., Suite 240
Austin, TX 78752 Phone: 512.656.4139
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list