13 Aug
2009
13 Aug
'09
11:06 p.m.
Paul Libbrecht wrote:
Indeed, I noticed that the images from MathTran are already better
aligned than the native ones. But this is a future improvement.
If you want, you can look at the current implementations (
http://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-formula/xwiki-…
) which are pretty small, and try to implement it.
Yes. It should be well documented how to switch to a different default.
If I understood the settings correctly, it has an infinite disk-storage,
and a LRU in-memory limited cache for the most recently used images (it
makes sense to keep in memory the images just stored, since they will be
requested right back anyway).
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
I hadn't seen the whole of this mail, sorry for
the late reply,
Le 12-août-09 à 09:30, Ludovic Dubost a écrit :
I'm not sure this has any effect, since "convert" is invoked only with
ps files generated by dvips, so I guess those are pretty safe.
Q: Does anybody know of any security issues with
running latex, dvips or
convert?
you may add a warning in the readme about usage of convert, I have seen
very many "arbitrary code execution" exploits reported about image file
formats (libpng and libjpeg among others): keep your libraries and
imagemagick (convert is part of that) up-to-date. Especially
with the \openin and \openout commands?
I am not sure I know the dangers there... it should certainly be advised
to run all that as www daemon!
- one which uses MathTran as a remote service
through HTTP requests. It
gives results as good as the native one, enhanced with some metadata,
and depending on the configuration of the server, it might have better
performance than the native one. The disadvantage is that it relies
heavily on a remote server. Note that MathTran is free software, and can
be installed locally on the same or a neighboring server.
MathTran is, by far, much better performing.
Moreover, the infrastructure used has proven to be able to solve the
baseline stuffs, for this, one needs the pictures to be delivered from
the same server so that the javascript reads the PNG headers(!). Note that the option of TeX compilation that MathTran
needs seems
shipped for everyone although J Fine said it was not.
If you are caching, it would make the remote problem almost trivial.
Yes, images are not retrieved directly from MathTran, but stored locally
and served from the XWiki server.
Oh, another
minor problem is that it uses a variant of the TeX
syntax, not LaTeX.
that is the major issue probably.
Note that people will request very soon their own set of macros (e.g
AMStex)
- one which uses SnuggleTeX and JEuclid to transform LaTeX into MathML,
and then render it into images. The results are not as eye-pleasing as
those obtained from LaTeX, but it is a self-contained solution, with no
external dependencies.
SnuggleTeX uses the liberal 3-clause BSD license, JEuclid uses the
Apache v2 license, so both can be deployed. Together, they weight in at
730k, so it's not a big impact. The other two implementations are not
contaminated by the licenses of the underlying system, so there's no
license conflict.
Q: Should either one be removed?
Q: Do you know of any other (better) alternative?
I would document how to implement another one.
MathFlow of Design Science can do this (a subset called "webTeX", it is
commercial but not too expensive.
Q: Is this setup OK as the default one? (native by default, snuggletex
as fallback).
and mathtran only optional? The generated
images are stored in a cache (using the cache component),
for improved performance. This new cache might increase the memory
requirements, but fortunately it is easy to configure.
is it not disk based?