texvc is able to produce MathML for some input (currently just some very simple text, not complex equations). When using XHTML output, it's possible to embed MathML directly in the text such that Mozilla and maybe Amaya can render it inline:
<math xmlns="http://www.w3.org/1998/Math/MathML">bla bla</math>
Is this a useful thing we should support, is it worth the trouble?
Good: * Text can be cut-n-pasted * Can scale with zoomed font sizes and for printouts * Inherits user overrides of forward and background colors * Transparency with no alpha channel tricks
These would be good for users requiring large font sizes or high-contrast displays;transparent PNGs that hard-code a black foreground will be illegible for a user who forces white-on-black text. All the above points are true of hacky HTML output as well, but hacky HTML doesn't tend to look that good, particularly for fractions, radicals, etc where positioning is hard to do right.
Bad: * Needs more work on texvc to be useful for non-trivial equations. * Supported by few browsers. Either a browser detect or an explicit user option must be used. We'd prefer to only have one canonical rendering to simplify caching.[1] * Mozilla complains at the user that they don't have special math fonts installed, which is rather annoying.
[1] A sick and evil option may be to introduce the MathML at load time via JavaScript+DOM upon determining that browser should support it. As with all such solutions this won't function with JavaScript disabled and is thus suboptimal.
-- brion vibber (brion @ pobox.com)
On Tue, Apr 20, 2004 at 02:20:52AM -0700, Brion Vibber wrote:
texvc is able to produce MathML for some input (currently just some very simple text, not complex equations). When using XHTML output, it's possible to embed MathML directly in the text such that Mozilla and maybe Amaya can render it inline:
<math xmlns="http://www.w3.org/1998/Math/MathML">bla bla</math>
Is this a useful thing we should support, is it worth the trouble?
Good:
- Text can be cut-n-pasted
- Can scale with zoomed font sizes and for printouts
- Inherits user overrides of forward and background colors
- Transparency with no alpha channel tricks
These would be good for users requiring large font sizes or high-contrast displays;transparent PNGs that hard-code a black foreground will be illegible for a user who forces white-on-black text. All the above points are true of hacky HTML output as well, but hacky HTML doesn't tend to look that good, particularly for fractions, radicals, etc where positioning is hard to do right.
Bad:
- Needs more work on texvc to be useful for non-trivial equations.
- Supported by few browsers. Either a browser detect or an explicit
user option must be used. We'd prefer to only have one canonical rendering to simplify caching.[1]
- Mozilla complains at the user that they don't have special math fonts
installed, which is rather annoying.
[1] A sick and evil option may be to introduce the MathML at load time via JavaScript+DOM upon determining that browser should support it. As with all such solutions this won't function with JavaScript disabled and is thus suboptimal.
Extending texvc to support real mathml is quite simple. I didn't do it yet because: * it can't be used without xhtml * I don't have any browser that supports mathml (mozilla on Debian has serious fonts problems with math), so I can't test it
If we ever start producing xhtml, I'll add real mathml support.
On Tue, 2004-04-20 at 17:06 +0200, Tomasz Wegrzanowski wrote:
If we ever start producing xhtml, I'll add real mathml support.
The current skins (see test.wikipedia.org) are xhtml-based now, and most content pages validate as such.
On Tue, 2004-04-20 at 17:06 +0200, Tomasz Wegrzanowski wrote:
If we ever start producing xhtml, I'll add real mathml support.
The current skins (see test.wikipedia.org) are xhtml-based now, and most content pages validate as such.
On Apr 20, 2004, at 08:30, Gabriel Wicke wrote:
On Tue, 2004-04-20 at 17:06 +0200, Tomasz Wegrzanowski wrote:
If we ever start producing xhtml, I'll add real mathml support.
The current skins (see test.wikipedia.org) are xhtml-based now, and most content pages validate as such.
One caveat: the page also has to be served with an XML content-type or Mozilla ignores the MathML tags. This leads to a much stricter requirement for output to be well-formed, since any error will prevent the page from being viewable.
We're improving in this regard, but user-supplied HTML isn't always well-formed, and problems aren't always corrected automatically. If we serve pages as XML, we *must* ensure that all possible output is well-formed so that non-experts can see the page, follow the link back to the edit page, etc. I'm not sure to what degree the output has to validate... -- brion vibber (brion @ pobox.com)
I see that currently math content is rendered from DVI to PNG by using dvips and gs. A possible way to do this simpler (and save some server CPU) would be to use the dvipng utility:
http://sourceforge.net/projects/preview-latex/
/Jan-Åke
On Apr 21, 2004, at 03:42, Jan-Åke Larsson wrote:
I see that currently math content is rendered from DVI to PNG by using dvips and gs. A possible way to do this simpler (and save some server CPU) would be to use the dvipng utility:
Note for others; see earlier thread mentioning possible use of dvipng including initial patch to texvc (needs to be changed to a command-line selectable switch between dvips and dvipng): http://mail.wikipedia.org/pipermail/wikitech-l/2004-April/009564.html
-- brion vibber (brion @ pobox.com)
On Apr 20, 2004, at 08:06, Tomasz Wegrzanowski wrote:
Extending texvc to support real mathml is quite simple. I didn't do it yet because:
- it can't be used without xhtml
- I don't have any browser that supports mathml (mozilla on Debian has
serious fonts problems with math), so I can't test it
If we ever start producing xhtml, I'll add real mathml support.
I've gone ahead and added an experimental MathML option which can be selected in preferences. It'll only actually work in the browser if using an XML content type, so set something like this in localsettings:
$wgMimeType = "application/xhtml+xml";
XHTML output is not always perfect, and this mode will cause Mozilla to refuse to display any page that's not well-formed. If you find such pages, those are bugs to be fixed in the parser somewhere...
I've also done some refactoring on Math.php to reduce some of the duplication and weirdness, but it's still kind of scary. :)
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org