Re: "XSL FOs not there yet" [was Re: XML-based text editor:a p
> Paul T <pault12@p...> 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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format