Le 21 févr. 08 à 05:07, Sergiu Dumitriu a écrit :
We're currently using FOP to generate PDFs. FOP cannot use DVIs (at least not currently, with the available external resource plugins). It does support some EPS.
Therefore I asked if drawing on some Graphics2D was doable as part of that (I suppose it could be piped along with Batik's Graphics object for example). We do have a dvi2svg tool already here.
We'd still be minimal in terms of installation... the TeX fonts only and still not the TeX system.
However, using the TeX system brings some problems: - there is a dependency on an external tool, as we cannot bundle a TeX system.
No. That is the idea of using MathTran as a service... it's a remote service.... currently the macro just generates the appropriate <img> tags. All the PNG generation and TeX running is MathTran's.
For MathTran to do proper alignment it should be served from the server so caching is being considered.
- TeX is pretty slow.
Damm less than FOP ! (;-)) (some FOP instances used TeX btw)
If it is used only for generating the PDF export of a wiki document with few equations, then that is not a major issue, since exporting PDF is not something frequently done. But imagine using it for displaying a document with several equations (>20), and how longit would take to make 20 shell commands to start TeX, generate the eps files, load those files from the disk, and send them to the client. No way this would work without a proper cache.
That is why MathTran is a TeX daemon... it seems to be able to make at least hundreds expressions a second. Note... the i2geo server does no rendering... it's all at mathtran's server at the open-university- of-the-uk.
Another way to generate nice graphics from LaTeX equations is by combining these tools: one that converts LaTeX to MathML, and one that converts MathML to something else.
MathML is surely very good and the MathML tool-set is far richer (see MathML software section of w3.org/Math). I can attest this many times! What's not rich enough to the taste of many mathematicians (and cannot be fully rich since this language is not specified) is LaTeX to MathML... the differences always byte TeX-experts. This is my sole reason to push a pure TeX approach such as MathTran (aside of the high-layout-quality).
As I indicated at other places I wish math-input would be in three flavours:
- TeX because there will always be folks asking it- some syntax (but which? Blahtex, which is known to cover the whole wikipedia? itex2mml? LaTeXMML?) which goes to MathML-presentation for supporting browsers (and pictures for others)
- a content-oriented syntax that produces OpenMath or MathML-content (searchable, tooltippable, better-copy-and-pastable, ...).
In all these situations the TeX fonts are very often needed to do a good quality rendering.
Should I rather stop the TeX approach (MathTran has limitations e.g. with the usage of self-defined macros) and push more the MathML one?
It's basically about assessing the "eternal need for real TeX". thoughts most welcome! paul
The first tool is needed as LaTeX is not quite an open standard. There is only one fully supported compiler, and it has limitations. On the other hand, MathML is interesting even as a final equation format, as some browsers have support for it, although with some problems. Butthere are many tools that work with MathML, viewers, editors, converters...Two candidates I found during a small Google session: http://math.etsu.edu/LaTeXMathML/LaTeXMathML.js -> LaTeX => MathML converter in JavaScript. The code should be converted to Java, so that the whole process can be done in the native language for XWiki. http://jeuclid.sourceforge.net/ -> MathML multipurpose tool. among others, it has a MathML => PNG converter, and a FOP plugin to directly support MathML in the XML source, which are preserved in the generatedPDF. This means that we don't need to separately convert equations intosomething else and then include some images in the PDF, but we can useone XML file that contains all the XHTML source and the MathML equations.These tools can be combined into a Radeox filter + macro. The filter allows a fast syntax, like $$\sum(i)$$, while the macro allows some customization, like {latex:align=right|zoom=2|background=yellow}\sum(i){latex}Another TeX=>MML converter I found is BlahTeXML, but it is written in C.And the code is not so comprehensible, so porting it to java will be harder. However, by comparing the size of blah and the js converter above, I'd say that probably blah does a better job at the conversion.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
