[
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?
It is good.
> 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?
I'd use FOs different from XSL WG FOs.
> 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.
Yes, that's reasonable thing to re-use some bits of TeX, when
implemeting XSL FOs. But that's not what I would like to
concentrate on. I'd like to concentrate on FOs 'anybody'
can use for some routine tasks, not just hi-fi printing.
> 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?
Yes.
> 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.
Yes, my mistake. XSL FOs are derived from DSSSL.
What do you think about the client base of DSSSL?
I mean, how many people do use DSSSL, comparing to
TeX userbase?
> 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?
XSL FO processing model is different from CSS processing
model. CSS processing model results in more supportable
components. In my oppinion, of course.
> > [...]
> > 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.
But I'm not actually interested in investing into XSL FOs
(that is what PassiveTeX does). My concern is not a hi-fi
printing, but expandability. XSL FOs (by design) give
you (almost) no hooks from renderer to plugins
and I forsee some problems when trying to use XSL FOs
with some 'custom tags', and I consider 'custom tags'
to be the most interesting situation.
In brief, instead of 100 of hardcoded objects I want
a mechanizm that would allow plugging new objects
into the system. That would imply a design, which
would be different from XSL FOs design. It looks
that TeX provides at least some hooks
to/from the renderer, so it should work Ok for the
propotype implementaion. If there is any
'more open' renderer, that is as good as TeX is -
I'd like to know ... I have not heard about
something better, than TeX...
> 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.
Passive TeX can be used in production and to the best of my
knowledge, Sebastian had used it already for at least one book.
However, teaching Passive TeX to learn XSL FO tricks looks like
kind of dead end to me, because of some limitations of TeX
engine. I would prefer teaching TeX a 'NewFO' tricks.
> 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?
I have not used neither of these engines for a while. Also, I'm biased.
> 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.
'The level' is subjective. TeX can do tricks that XSL FOs can not and
XSL FO native engines can do the tricks that TeX can not. I'm more
interested to do some brutal things, like going from XML to any possible
format fast, trought intermediate layer of FOs , plug-in 'custom' tags
into the tree e t.c. XSL FOs are'nt good for this domain, they're
concentrated
on a hi-fi printing only.
Rgds.Paul.
|
