"XSL FOs not there yet" [was Re: XML-based text editor: a proposal]
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? 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/
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