Paul Libbrecht wrote:
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.
That is exactly one of the problems with MathTran: It is on a remote
host. This means that:
- it might not be usable in some strict intranets, where there's no or
restricted access to the internet
- If the MathTran server is down, then no images will appear
- It increases the traffic to an external server
If it were to be installed on a local server, then we're back to the
other problem: heavy installation.
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)
Indeed, one FOP run is slower than one TeX run. But unless you write/use
a TeX daemon (like the MathTran one) then you will have to run TeX many
times for one document, while you would still have one FOP run.
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 long
it 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).
Still, it is TeX and not LaTeX, as I read in the Moodle page talking
about MathTran. This is a drawback, as LaTeX users will be confused. I,
for one, know only the LaTeX syntax.
A problem with non-TeX is that the result is not as good looking as a
TeX one. Damn, those articles look good! Still, the wiki is not meant to
be the complete article authoring product. It is just the place where
the authors can collaborate on the article, and have a fair preview of
how the document would look, then export it as a LaTeX document which
can be processed by a real tex system.
And another thing is that the STIX fonts are almost (!) ready. They are
passed the beta preview stage, and will soon be final. Perhaps MathML
and PNG-ed MathML equation will look better with those fonts.
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".
I'd say that the web is moving towards XML and XML languages. MathML
belongs to the future. There are much more tools that support MathML
than (La)TeX.
Still, asking users to write MathML in the wiki content is too much. So,
there should be support for LaTeX equations, but they should not be
interpreted by a TeX engine (be it local or a remote service), instead
they should be transformed into MathML (as good as possible, whenever
there's a difference it can be addressed and fixed).
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. But
> there 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 generated
> PDF. This means that we don't need to separately convert equations into
> something else and then include some images in the PDF, but we can use
> one 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.
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu/