[LON-CAPA-users] tex in loncapa
Tue, 12 Jun 2007 16:28:40 -0600
To add more to this discussion, it appears that there is either a
lon-capa related bug, or something we have done wrong. We have two
resources that we glue into a page. When the resources are separate,
they display just fine in jsmath, but when they are part of a page, then
the math on the second resource is not displayed properly at all.
The resources in question (open source) are:
tth works, but is ugly, and images works, but is also ugly. However,
since they work fine separately, it seems there must be something about
the way the page is glued together that breaks jsmath.
We can fix it using <m display="mimetex">, but since it's only needed
when the resource is part of a page, that seems a bit heavy-handed.
Guy Albertelli II wrote:
> Hi Peter,
>> every now and then I experience that latex commands do not come out as I
>> expect (we use convert to images as a default here).
> Well we haven't written the tex coversion engines that are in
> lon-capa, we've just used some existing ones with the occaisional
> tweak to make things work better. We've also limited ourselves to fast
> engines, We didn't want the <m> conversion to be a performance killer
> if it at all possible. That said we've ended up with 3 engines with
> various features/bugs to them.
> the tth engine is generally the most complete in it's support of
> latex, almost anything works correctly but the output isn't always the
> prettiest (looks like \"u is fine but \mapsto uses the \to arrow)
> jsmath makes the prettiest output, but only really supports math and
> does require js (looks like it gets \mapto correct but not \"u)
> mimetex (the image one) will work on any browser no matter the setup,
> but looks poor and only supports a math subset. (It gets neither the
> \"u nor the \mapsto correct)
> So they all have tradeoffs... I suspect that you might prefer
> something like latexrender does, which is to have latex parse and
> generate the dvi, and then convert the dvi to a web graphic. Which has
> serious speed issues and thus isn't included as option.
>> Sometimes we can use the HTML typesetting ü as a workaround, but
>> occasionally it is absolutely necessary to have the Umlaut within tex, as in
> I'd suggest switching renders for just this one then, you can do this
> by telling <m> that you know that this one only work in a specfic
> engine and to override the users preference
> <m display="tth">...</m>
Dr. Todd Ruskell
Senior Lecturer, Department of Physics Office: Meyer Hall 326
Colorado School of Mines Phone: 303-384-2080
1523 Illinois Street Fax: 303-273-3919
Golden, CO 80401