On Tue, 2003-06-10 at 23:03, Alexander Schatten wrote: > Andreas Kuckartz wrote: > > >>I think it's not in the the cocoon project's goals. > >> > >Why not? A good reason which I can see for such a component is that you > >could use the features of TeX to automatically create printable pages with > >high quality.
This has come up several times before. I agree completely: many people want to use LaTeX to create PDF because it does a vastly better job than any of the FOP systems. > I cant get the point. Cocoon is an XML publishing tool. The central idea > is the XML based pipeline. Sure. So why not let external processors into the pipeline? Other systems do (eg PropelX). You seem to have missed the point that at *some* stage, your text *has* to cease being XML and become pixels if you want it read. It's just a case of when that happens: normally we want to keep it in XML as long as possible, because Cocoon and other XML systems provide better control than non-XML systems. But only up to a point: I would argue that because LaTeX does a better job of formatting than anything else, *that* is the point when my text should leave XML and start the journey to pixels. > Why should Cocoon now be responsible for a hodgepodge of other > publication tasks? how does TEX fit into the pipeline? not at all. Very easily. It's almost trivial to write text-mode XSLT which will output LaTeX source code. All that is needed is to spawn a task which runs LaTeX on that code (and can subspawn BIBTeX and makeindex). > only > if (what I would *really* appreciate) someone would generate an TeX > generator, that creates XML out of tex; this would seamless integrate > also TeX ressources. This is really a bad idea, I'm afraid, and the very last thing we actually want or need. TeX systems are for formatting: you use them to typeset something which was created/edited/stored/manipulated in (for example) XML. Because of the way history happened, TeX preceded XML, so we have a lot of legacy TeX. Sure it would be nice to have a tex2xml which would do the job (actually there are a few attempts) but if you stop for a moment to think of the ghastly mess which most authors make of TeX, you'll realise why there is no such animal right now. Yes, you could write a conversion from well-formed LaTeX to XML (I actually did one a long time ago, for SGML) but the instant an author starts to write her own macros or mess manually with the formatting, the model breaks and translation becomes virtually impossible. To effect it fully you'd need to rewrite TeX the program to output XML instead of DVI or PDF, and you'd *still* be in trouble because most of what TeX formats carries nothing with it which can be used to indicate markup, unless you want to go back to the days of <b>, <i>, and <u>. > but TeX processing is obviously no Cocoon purpose. On the contrary, it's badly needed. Even more so is a latex-mode for XSLT (but that's a different thing). > The next one will ask, why Cocoon cannot create WML from powerpoint or > SVG from Postscript. Because PowerPoint is not (yet) an XML format, nor is PostScript. What we need to to be able to go from XML to PDF via LaTeX. In any case, it shouldn't be specific to LaTeX. All we need is an ability of Cocoon to spawn an external process and serve the result back to the user with a defined media type. ///Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
