[
Lists Home |
Date Index |
Thread Index
]
Paul T <pault12@pacbell.net> writes:
> [...]
> XSL FOs have been designed from scratch, like there
> is no tomorrow and like there was no yesterday.
> [...]
> The task I would like to participate in, is :
>
> Re-design XSL FOs on top of :
> existant TeX rendering engine
> CSS
> XSLT ( subset )
> bi-directional XPath binding ( for plugins in other languages )
> [...]
What about Sebastian Rahtz's PassiveTeX?
PassiveTeX seems to me to be exactly what you're describing -- an
FO-to-print implementation based completely on TeX. In what ways would
you say PassiveTeX falls short? Or how would the TeX-based redesign
you have in mind do anything differently?
And I think it's also worth pointing out that at least a couple other
FO-to-print implementations make use of TeX. I know RenderX XEP uses
TeX hyphenation patterns, maybe some other things. And I believe the
XSL-FO support in Arbortext Epic 4.2 is driven in part by some behind
the scenes TeX stuff.
Or when you say "XSL FOs have been designed from scratch" and propose
a TeX-based redesign, are you referring not to the existing
implementations but to the XSL spec itself -- the FO part of it?
It doesn't seem like you could be. Probably you're more familiar with
the details of the spec than I am, but from the little I know and from
looking at the list of XSL WG members, it seems like its design had to
be very much influenced by some years of experience by members of the
working group building and using implementations based on FOSIs and
DSSSL and proprietary formatting languages and whatever else.
And looking at your list of things you propose that XSL FOs should be
built "on top of", I can't think of what it would mean to redesign the
FO part of the XSL spec on top of TeX, or what sense it would make to
redesign the relationship between the overall XSL spec and the XSLT
spec. And isn't the set of XSL-FO formatting properties/attributes
basically a superset of CSS properties already?
> [...]
> 4. I can hack TeX ( including source code ), I can do all the ground
> development and help with design, but I don't want to make the
> core design, because I belive that it should be done by some
> person who has better experience in typesetting / printing domain,
> than myself.
>
> 5. The world has no real need in yet another emacs, but
> the world (still) has no nice solution for document printing,
> and XSL FOs are ... not there ... yet ...
If it is the implementations that you're talking about and not the
spec, and you've got the TeX chops, I'd bet good money that Sebastian
would be very happy if you were to offer to help him out with further
development of PassiveTeX.
And if when you say that "XSL FOs are not there yet" you mean the
open-source FO-to-print implementations aren't ready for production
work yet, I don't think anybody would argue with you, though it seems
like PassiveTeX might be significantly further along than FOP.
Anyway, there are a couple of commercial implementations -- Arbortext
Epic 4.2 and recent releases of RenderX XEP -- that seem pretty mature
to me. Have you run into problems using either of those?
FWIW, I agree completely it doesn't make much sense to re-invent the
wheel when we've already got an open-source system -- TeX -- for doing
production-quality print/PDF rendering. That's why it'd be great to
see more work invested in PassiveTeX, great if it were brought up to
at least the same level as the Arbortext and RenderX implementations.
--
Michael Smith, Tokyo, Japan http://sideshowbarker.net
マイク
The mysteries of human nature
surpass the "mysteries of redemption,"
for the infinite we only suppose,
while we see the finite.
--Emily Dickinson (*251) http://www.logopoeia.com/ed/
|
