Wikipedia talk:WikiProject Mathematics/Archive/2004/Sep-Dec

The case for LaTeX

In recent days, I have been adding <math>...</math> to every inline math expression I have encountered, starting with articles in Category:Curves and category:Bundles (mathematics). At the time, I thought that the HTML wikitext markup for equations was provisional, and that by TeXifying expressions, I was improving the articles. I didn't know about the existence of the Wikiproject Mathematics page. I'd like to offer my apologies for breaking convention.

That said, I'm perfectly astonished that HTML wikitext markup for inline equations and variables is an official recommendation (not truly "official," but you know what I mean.) I think it's a bad idea, so allow me to flesh out my case here. My proposal is that we should use <math>...</math> markup for any and every expression related to math, including formulae, single-letter variable names, and all inline expressions. Here's why:

1. Content != presentation. The entire reason that XHTML and CSS were created from the ashes of HTML 3.0 was to separate presentation from content. We can see the effectiveness of that design decision right here in the Wikipedia: I can change the "skin" of the site (which is just a CSS file) and the look of the site changes automatically, in spite of the fact that the content of every page remains the same.
   Doing this required tags that were solely devoted to presentation, like <i>...</i>, <b>...</b>, and <u>...</u> to be removed from the standard. They force presentation and content to mix. So why do we require mathematical expressions to be represented in the exact same manner? Why should a variable name be "italic?" What, precisely, does that indicate to the user?
2. Consistency. TeX is capable of creating beautiful PNG representations of math expressions, but the fonts and styles it uses for PNG do not match the fonts and styles used for the present "wikitext math" style. TeXifying everything will make all variables and equations look consistent. We won't be able to avoid TeX for more complex formulae anyway; we might as well let TeX choose the font for us.
3. TeX allows the user to decide. If we put all math expressions (including inline expressions and even variable names) in the <math>...</math>, any user will be able to change the look of all math-related pages with a single tweak to their preferences. They can view everything as HTML unless absolutely necessary, or they can view everything as PNG for maximum clarity. That all users' default preferences are not set to the latter is no reason to avoid LaTeX markup.
4. TeX allows the admins to decide. If, in the future, some brave developer decides to replace our LaTeX engine with MathML or some other more fitting standard, they can write a bot that automatically converts all LaTeX expressions on every page. Alternately, they may decide to change the default fonts for TeX (I don't know if this is possible, but I assume that it is), and again, all math expressions in the Wikipedia will respond to the change. Neither scenario is possible with "wikitext math," which would have to be changed by hand.
5. PNG images are small. That's the entire point of PNG, and why we use it in the Wikipedias in preference to GIF files. An expression like $\int _{0}^{\infty }e^{-x^{2}}\,dx$ only takes up 680 bytes; this post I am typing is much larger. It would be difficult to achieve better compression without throwing away image quality! In a giant page full of these types of expressions, the bandwidth "wasted" downloading the PNGs is negligible compared to the bandwidth required for (1) the article text, and (2) the Wikipedia logo in the upper left corner.
   Now, if you're using a graphical browser, right-click on the previous image and view its file name. Then compare that file name to the one on the WikiProject Mathematics page (where I got it from.) The filenames are exactly the same--5aa3fbdb28e2859859317b8a9d316fa9.png. So server space is not wasted for common expressions like variable names, either, even if they are forced to render as PNGs. There will be only one copy of the PNG file for $\,\!\theta$, and anyone viewing our math articles will have it cached.
6. TeX can emulate inline HTML, anyway. One objection to the use of LaTeX markup (and, in my opinion, the most legitimate one) is that some browsers cannot view inline PNG, and the resulting alt-text is incomprehensible. This is true; however, the MediaWiki LaTeX engine creates inline HTML already! Compare:
   • HTML style: f(x) = a₀x² + (a₁x)cos θ
   • TeX inline HTML: $f(x)=a_{0}x^{2}+(a_{1}x)\cos \theta$
   • TeX with forced PNG rendering (with \left, \right, and \!\,): $\!\,f(x)=a_{0}x^{2}+\left(a_{1}x\right)\cos \theta$

But it is true that mixing inline PNGs with ordinary article text can have a somewhat jarring effect; this is unavoidable, and I happen to not mind it at all (I have seen textbooks that have odd line spacing due to inline math expressions; they still sell well.) One possible compromise is to avoid forced PNG rendering unless absolutely necessary (that is, do not use "\!\," or other "artificial" spaces if you can possibly help it), so the user will see the maximum amount of inline HTML. They can still use their preferences to turn PNG rendering on, so we should expect that PNG versions of all of our expressions, equations, and variable names will exist.

I admit that such a proposal will require us to avoid the more traditional style; $x\cos \phi$ renders as "squashed" inline HTML, and would require parentheses if we did not allow artificial spaces: $x(\cos \phi )$ or $(x)\cos \phi$ or $x*\cos \phi$, etc. It's easier to simply allow PNG rendering for unsatisfactory expressions, but nevertheless, this proposal does address the inline objection.

I'm not surprised that my sentiments have been expressed before: Wikipedia talk:WikiProject Mathematics/Archive1#Moved_from_Village_Pump (see comments by User:Pascalromon.) I echo his/her sentiments, but I don't think we need changes as drastic as those that he/she proposed. So how about it, everyone?

Ardonik 19:26, 2004 Aug 3 (UTC)

You write I happen to not mind it at all. If most people agreed, we wouldn't be having the discussion, though. Wiki tends to look provisional, and there's a reason (it is). Now, work on format is constructive; but I don't know enough TeX to be happy with it. We have a kind of compromise at present. I expect it to remain until there is a clear technical shift in rendering, making inline TeX the obviously right way to go. Charles Matthews 21:52, 3 Aug 2004 (UTC)

The beauty of TeX is that we can avoid inline PNGs (which I am not opposed to avoiding) and still reap the other benefits of TeX mentioned above by keeping inline expressions in <math> tags. As for not knowing TeX, you don't have to! You add a lot of useful math content to the Wikipedia, Charles, and I figure that the job of less math-literate people like me is to follow in your footsteps, tweaking things here and there. TeXifying equations is one way to do that.
Perhaps it would be to everyone's benefit to mark the "old style" as provisional, so as to encourage intrepid Wikipedians to update it at their convenience to the "new format" without shunning the old style completely? --Ardonik 22:28, 2004 Aug 3 (UTC)

I think inline PNGs are ugly. I don't mind the use of <math> tags if they are properly translated in inline HTML; in fact, I prefer to type <math>f(x)</math>, rendering as $f(x)$, to ''f''(''x''), rendering as f(x) [side remark: I am surprised to see that both expressions render differently; on my display, I prefer the latter]. Unfortunately, not all mathematical expressions are translated into HTML, and I think that these expressions should be either translated by hand to HTML, or put on a separate line. -- Jitse Niesen 20:19, 4 Aug 2004 (UTC)

I will admit that it often takes some degree of coaxing to convince TeX to leave some simple expressions as HTML (for instance, using \(space) seems to invariably cause PNG conversion.) TeX isn't perfect, but I still think the advantages of keeping expressions TeXified more than outweigh the disadvantages.

If the community consensus is to avoid inline PNGs, then the next step is to discuss strategies for keeping TeX from PNG conversion. I am assuming that the conversion program ultimately responsible is latex2html. As seen from this page in the official manual, there are any number of ways to induce image conversion, but there appears to be no option by which one can force HTML output. (Can someone who is more familiar with the world of TeX correct me on this point?) That rules out convincing the developers to change program parameters; I think we'll just have to come up with a list of TeX features to avoid or replace in order to ensure inline HTML generation. But now is the right time to discuss such things, and this is the right place to do it.

Ardonik 07:39, 2004 Aug 5 (UTC)

Use of \mbox

We can use \mbox{ } to force spaces without inducing PNG conversion. Compare:

	Appearance	Markup
HTML	a2b cos x	''a''<sup>2</sup>''b'' cos ''x''
TeX (PNG rendered)	${a^{2}}b\cos x\,\!$	<math>{a^2} b \cos x\,\!</math>
TeX (without \mbox)	${a^{2}}b\cos x$	<math>{a^2} b \cos x</math>
TeX (with \mbox)	${a^{2}}b{\mbox{ }}\cos {\mbox{ }}x$	<math>{a^2} b \mbox{ } \cos \mbox{ } x</math>

Can anyone think of any other HTML syntax that TeX can't handle without PNGs?

Ardonik 11:21, 2004 Aug 5 (UTC)

TeX/HTML currently incompatible

On line bundle, I attempted to view the article using all possible choices of user preferences, and none of them were able to convert things like the "Z/2Z", "RP2", "CP2", etc. (blackboard bold, fractions, etc.) to inline HTML. When strict HTML was selected, of course it returned tex code. The point is that there is no way to use inline math mode while avoiding PNGs. TeX and HTML simply "evolved" from different origins and haven't quite become compatible. I expect this problem will be solved in time. In any case, there's no telling that the solution won't require detailed combing over and editing in the future, anyway. So, I agree completely with you in principle, but think it's too early to work in practice. And I don't think it's that big a deal...it will be a lot of work to make the switch when HTML and TeX become compatible, but with enough people working on it, shouldn't be a problem. Revolver 21:02, 5 Aug 2004 (UTC)

If the \frac notation cannot be used inline, then we should employ a forward slash instead. TeX understands it; see http://turing.une.edu.au/~amth247/Lectures_2003/Lecture_03/lecture/, and in particular the section of fractions and roots. It recommends that the slash notation be used in favor of \frac wherever it would make an equation easier to read; thus "Z/2Z" would become $Z/{2Z}$. In order to prevent the "RP" and "CP" in line bundle from rendering inline as PNGs, it suffices to avoid switching to fonts like \blackbb (and it makes perfect sense that HTML would not be able to handle those.) Again, we can reap the benefits of TeX without generating PNG files. --Ardonik 02:33, 2004 Aug 6 (UTC)

If the community consensus is to avoid inline PNGs, then the next step is to discuss strategies for keeping TeX from PNG conversion....That rules out convincing the developers to change program parameters; I think we'll just have to come up with a list of TeX features to avoid or replace in order to ensure inline HTML generation. But now is the right time to discuss such things, and this is the right place to do it.

Maybe so. I don't know, maybe this comes from seeing articles evolve over months or a couple years, but I don't think this is a urgent problem in any case. Try to avoid the most obvious problems (e.g. I think blackboard bold should be entered as bold for the moment) but it's nothing to get too uncomfortable over. For now, it's probably enough to sit back and wait for the inevitable HTML/TeX compatibility to happen, and then let things sort out. None of these articles are really going to look like they do at present in 2-3 years, anyway. Adding good content and improving some of the weaker "elementary" articles (fundamental thm of calculus, etc.) seems far more important. (BTW, why is FTC listed first in the "calculus" box, before derivatives even?) Revolver 21:15, 5 Aug 2004 (UTC)

It's not urgent (what is urgent in this Wikipedia?) but I feel that we do need to address it. LaTeX is not some relatively new technology waiting for extra features to be added by enterprising programmers. It is mature and fully featured; latex2html itself was around before 1993. There is nothing to wait for. The TeX tools were designed to empower those who love math, and now that they have been enabled in the MediaWiki projects, they are at our disposal. They do everything we want. What reason do we have to avoid them?
Of course I agree with you that adding content is more important than worrying about style, but by formalizing a system now, we ensure that future Wikipedians will know what guidelines to turn to when creating new math and science articles, and that people like me will know how to TeXify articles without ruining them. A thousand times over do I prefer consensus to inaction. --Ardonik 02:33, 2004 Aug 6 (UTC)

P.S. FTC? Calculus box? --Ardonik 02:33, 2004 Aug 6 (UTC)

Fundamental theorem of calculus. Look at the "topics" box on the right. FTC is the first topic. Revolver 19:55, 6 Aug 2004 (UTC)

I agree that <math>f(x)</math> is more logical than ''f''(''x''), and that content is more important than format, but I also agree that the HTML version looks better. Supposedly this will all be resolved when mathml is working. Should we just wait until then? (and how long will that be, anyway?) - Omegatron 02:47, Aug 6, 2004 (UTC)

Well, we have "experimental" MathML support right now, but as for how long we'll have to wait before MathML becomes a widespread standard, the answer is perhaps indefinitely. How could a company that failed to correctly support even CSS 1 be bothered with adding MathML support? Sure, Mozilla might get it eventually (or someone might develop a fork of Mozilla that supports it), but until aforesaid company makes Mozilla or Firefox the default desktop browser, few people will be able to view MathML. Additionally, when MathML support is fully enabled, we won't be able to take advantage of it without putting our expressions in <math> tags first, so we will be better off TeXifying our expressions now than continuing to use raw HTML and piling up the amount of conversion that will need to be done later.
Honestly, what do we stand to gain by waiting? --Ardonik 03:37, 2004 Aug 6 (UTC)

A few points. (1) Actually there is a free plug-in for Explorer available and Mozilla et al. have already a reasonable support for MathML (but you need to download some fonts). (2) What happens to <math> is determined by a home-grown transformation that might be changed if desired. (3) MathML is not really functional right now. I think the last point is important. There should be at least one way to see the ideal end-result. -- Jan Hidders 11:22, 6 Aug 2004 (UTC)

Yeah, I used the MathML player when I was still in IE. It seemed to work fine, and is free. MathML is probably the ideal future solution, but ideals are commonly nonviable.

Maybe we can make some sort of compromise? add an attribute "inline" to the math tags ( <math style="inline">, etc. )to make it format as HTML if at all possible, or in small-lettered, center-aligned TeX if not? And when converting to HTML, change the span.texhtml { font-family: serif; } to something that renders prettier? Perhaps just leave it in the default font? - Omegatron 13:36, Aug 6, 2004 (UTC)

From what I can gather, TeX's chief weakness is its inability to guarantee the generation of inline HTML (by default, of course; user preferences would always be able to force PNG generation.) I am convinced that this can be worked around, but I openly admit that the solutions (like using \mbox{ } instead of a space) are cumbersome. Another weakness is that the inline HTML is rendered in a different font than the HTML that surrounds it. Only the developers can fix this problem, as they control the MediaWiki CSS.

At the same time, responders seem to generally agree that there are tangible benefits to preferring the <math> markup to ordinary HTML.

I see the workings here of a possible compromise:

1. Content and accuracy are more important than anything else. Compared to these, the beauty of a page's math should be an afterthought.

(I'm afraid I can't agree that considerations of beauty "should be an afterthought". Of course content and accuracy are of paramount importance, but if an article is so off-putting, that it isn't read, well … Paul August 16:34, Aug 24, 2004 (UTC))

1. Allow people to continue creating and formatting equations in the "wikitext math style" currently described on the WikiProject Mathematics page, but recommend use of the <math> tag for future entries.
2. When using LaTeX, the "house style" will be to avoid generating PNG images for inline equations and variables. Anyone TeXifying wikitext math must be careful to preserve the HTML format for all inline expressions and variables; when this cannot be done, they should leave the expressions and variables as they are. Conversely, if the TeXification of a page's math expressions is done correctly, there should be no reason to remove it.
3. The WikiProject Mathematics page will feature a tutorial on how to keep LaTeX from generating images so that Wikipedians can share tricks like \mbox{ } with others. I can help to write this.
4. Expressions on their own line may freely be converted to PNG, so house style will be to prefer that complex expressions remain on their own line whenever possible.
5. Convince the developers to use a prettier font-family, font-weight, font-style and font-size for inline HTML conversion (what specific settings would be ideal I do not know.)

Does this sound like a reasonable set of guidelines? Would anyone be opposed to them, and if so, what can I do to improve them? --Ardonik 19:10, 2004 Aug 6 (UTC)

"Well, the ideal solution would be …"

Well, the ideal solution would be to just have any and all articles that use mathematical expression to jettison HTML entirely and have the whole thing be a LaTeX file. This would eliminate all the problems. (I'm being facetious, of course...but also trying to indirectly point out what the problems are short of doing this.)

From what I can gather, TeX's chief weakness is its inability to guarantee the generation of inline HTML.

It's a bit more than that. For people who dislike the ugly "discontinuity" of alignment between HTML and PNG, and find it personally disruptive, solving this problem would still these people to choose "always HTML" and so give up inline PNG images altogether. But why should they have to do that?

The guidelines sound alright. I still believe that for relatively simple things, it's best to leave in HTML as we've always done. I'm talking about the greek letter "π", for instance. Or, single variables, like "x" or "y". Nothing gets me more than seeing a variables that stands out nearly TWICE AS TALL as the text size I'm reading. For more complicated inline expressions, I have a lot more tolerance and understanding. But, even something like Z/2Z, doesn't seem to need texifying. Of course, I'm sure I draw the line much farther than most other people.

Revolver 19:50, 6 Aug 2004 (UTC)

Here is where you and I disagree--I think anything related to math should be TeXified, so as to indicate that the information being marked up is math and not prose. I've already outlined my reasons for preferring this, so I'll have to accept that we will differ on this point. But remember that with inline HTML generation, the user should not see any drastic difference between &pi; (π) and <math>\pi</math> ($\pi$). The only real difference to the user will be that they can change the look of the second one on the fly with a single change to their preferences. --Ardonik 20:48, 2004 Aug 6 (UTC)

Your assertion is just not true. Obviously, you have never attempted to do this on IE personally, or you wouldn't claim this. Here's the problem: too many math expressions are not changeable (or won't change) to HTML. So, even after changing preferences, the user is STILL bombarded with a ton of inline math expressions, esp. at articles like curve and a lot of the category and algebraic topology articles. These things can't be changed to HTML, and given that there will always be a wide variability in the size people choose for their fonts, someone will be left looking at disruptive text. Revolver 17:45, 24 Aug 2004 (UTC)

Crazy idea

This may seem like a crazy idea, but it would be something I would be willing to contribute time toward. There is a company which makes a semantic interface onto LaTeX (Scientific Works), which you can enter into directly (not WYSIWYG, but logical interface). It takes very little time to enter stuff, about as fast as using a word processor. Then, there is a viewer that comes with it which is free for anyone to download on the internet. So, once you make a file, you just direct someone to download the viewer and view the file with the viewer. There is absolutely no TeX code involved at all.

While this is clearly not workable for the wiki pages that people work on, it might be possible to do periodically for some of the more important math and technical pages, I'm thinking of Wikipedia 1.0 in particular and its updates. The number of articles here wouldn't be too much, it would be much better visually, and both the wiki-HTML-PNG version as well as the Works version could be available for people to choose.

Otherwise, I'm just starting to think, while the CD-ROM viewers of 1.0 will have the option of which way to see it, the people reading the paper version will not.

Revolver 20:10, 6 Aug 2004 (UTC)

The best way to integrate any document-viewing plugin is with XHTML's <object> tag; say, something like

 <object data="proof.tex" type="text/plain" width="400" height="200">
   alternative text (i.e. inline HTML for the proof)
 </object>

sort of like an "applet" for math pages.

Yet I would still prefer the current system of integrated LaTeX to this--the user doesn't have to know that we're using a LaTeX back-end, and we can swap it out with something more effective (read: MathML) at any time. It's definitely not as easy to use as a WYSIWYG editor, though.

Ardonik 20:57, 2004 Aug 6 (UTC)

My own two cents: In principal, I completely agree with the idea of writing all math code in TeX. That being said, I must object to actually doing this at present. I personally think that all inline TeX—whether rendered as HTML or PNG's—looks terrible. More than once I've avoiding reading a math article (let alone bothering to edit it) simply because I don't want to get a headache trying to wade through the changes in font sizes. In principal, the TeX->HTML shouldn't look bad, but it does. Yes, I know this can be fixed by a simple change to the wiki CSS file, but no one seems to be doing this. In the meantime, I'd much rather have a article that I can read rather than one which is semantically "correct".

Point 2: I think the real push should not be towards getting everyone to TeXify everything, but rather towards getting the wiki developers to implement MathML output. I believe that MathML is a viable solution now! Not some distant future. MathML looks reasonable in Mozilla browsers and plugins are available for other 'less competent browsers'. If you ask yourself why there isn't better browser support for MathML, the answer is pretty obvious: there just isn't much demand for it. What's needed is a site like Wikipedia, with its large quantity and quality of math content, to start outputing things in MathML to increase demand. Who should we be talking to, to push this matter?

In the meantime, I will continue to use pure HTML for everything inline simply so I can read it. I will starting inputing TeX as soon as wiki starts outputing MathML. As to having to rewrite all the articles when this happens, I don't think it's such a big deal. It's not like it has to be done all at once. Articles are getting edited all the time, they can be converted piece by piece. And until they are, it's not like they're going to be unreadable.

Fropuff 04:08, 2004 Aug 8 (UTC)

For changes to the CSS file you could do a request at the wikitech-l mailing list [1]. I suspect that if you make clear that this is a common complaint in the math community there will be a quick response. I'm not really an expert on CSS matters, so I cannot do this myself. As far as real support of MathML goes, see the discussion on this in this newsgroup last week (in August 2004) with subject "Status of MathML support". -- Jan Hidders 09:51, 8 Aug 2004 (UTC)

Fropuff, you think that neither TeX's PNG rendering NOR its inline HTML look good? Honestly, is the serif font on your browser that ugly?

I've performed an experiment in the interest of furthering this conversation. I have just TeXified the entirety of the determinant article, trying as much as I could to keep inline statements from rendering as PNGs. I will disclose now that in four areas, I failed to accomplish this task, though not for lack of trying:

1. The \approx symbol in TeX apparently forces PNG output, in spite of the existence of the &asymp; entity in HTML. I could not find a suitable replacement for this.
2. I was unable to specify a bold font for the "R" characters in ${\textbf {R}}^{n}$ without generating PNGs. From the documentation I read today, it seems that the command to do this is \textbf, but it apparently has the same effect as \mathbf in the MediaWiki.
3. The correct way to prevent $|A|$ from looking spaced out is to use the \left and \right commands, but for reasons unknown to me, <math>\left| A \right|</math> displays as a PNG: $\left|A\right|$.
4. I couldn't find an inline sqrt or a square root symbol. Using \sqrt{} guarantees PNG output.

Anyway, here are links to the old version and the current version. Compare the way they look. Except for the places I mentioned above, how similar are the two articles? Do those of you who dislike TeX's HTML output still dislike the text that you see?

It took me several hours of browsing through manuals and latex files to fully TeXify the article (I'm still learning TeX, too), but if any of you feel that I've mangled it or inserted something contrary to fact, please revert my changes.

Ardonik 11:33, Aug 8, 2004 (UTC)

Determinant#Derivative is somewhat messed up. The first two expression render differently of the last two... IMO major, i.e. long, expressions should (be allowed to) render as PNG and be placed in a new line, for clarity; there should be no "tricks" when writing <math> so that it is easy to edit and convert to some later format; expressions and/or single letters/symbols inline with text should be <math> also, although uglyer it is more clear.--Nabla 12:40, 2004 Aug 8 (UTC)

I honestly think the old version of the determinant article looks far better. If there isn't a whole lot of inline TeX, the effect isn't too bad, but take a different example with a higher density: compare the current version of Representable functor to the last unTeXified version [2]. Again, I think the old version is far more readable.

"Honestly, is it the serif font on your browser that's ugly?" No, I actually approve of the serif font. It's the size that bothers me. PNG's are too large, the text of the TeX/HTML is too small (hard to read in fact). When the two are used side by side its just a mess. I know this may sound nitpicky, but I honestly get a headache trying to read that stuff.

Fropuff 14:26, 2004 Aug 8 (UTC)

I agree with Fropuff that the inline PNGs are very ugly and with Ardonik that it would be preferable to use <math> tags to deliminate maths expressions. The discussion that Jan pointed to shows that we will probably not have MathML output in the near future. The only satisfactory resolution, as far as I can see. is to improve the translation of <math> environments to HTML, so that for instance <math>|A|</math> automatically renders as |A|. -- Jitse Niesen 18:19, 8 Aug 2004 (UTC)

Is it just me, or do the HTML sup constructs show up really low? Compare x² to $x^{2}$. This makes articles that contain many superscripts very hard to read because the superscripts are hard to distinguish from regular text. TeX/HTML renders the superscripts much better in my opinion. Gadykozma 14:14, 27 Aug 2004 (UTC)

The both 2's look to be at the same height for me - the bottem of each "2" just below the top of the "x". Paul August 16:33, Aug 27, 2004 (UTC)

The TeX version looks awful -- the x of x^2 protrudes far below the "baseline" of text. The HTML version is balanced in height and more readable. Revolver 09:00, 31 Aug 2004 (UTC)

Maybe it was a linux problem, or the specific version of Mozilla/Galeon I usually use. Now I'm on windows and both look fine. Gadykozma 18:59, 1 Sep 2004 (UTC)

A clarification

A Clarification -- one more reason I prefer HTML. Besides lots of things not being able to render in HTML, there is another big problem. Many people urge me to change my preferences. But then a lot of expressions I wish were KEPT in TeX get changed to HTML when I don't want them to!! This happens for example at the article pi. Long, single-line expressions get chopped up and rendered often in a silly manner. Besides, for single-line, I WANT TeX. Why should I be force to give it up?? Revolver 09:04, 31 Aug 2004 (UTC)

Good point. The preference "HTML if possible or else PNG" renders fractions as HTML, which looks terrible (at least in my browser). A possible solution is to change the software so that all single-line expressions are rendered as PNG, even if they could be rendered as HTML. With single-line expressions, I mean lines that contain only a <math>...</math> construct, and possibly white space. I do not know how feasible this is technically. What do people think of this idea? -- Jitse Niesen 10:22, 31 Aug 2004 (UTC)

Its strange nobody seems to have mentioned the project for a paper version of wikipedia, meta:Paper Wikipedia. This seems very relevant to the question whether LaTeX or html markup is to be preferred. Gadykozma 18:23, 5 Sep 2004 (UTC)