Extension:Blahtex/Bugs and feature requests

From MediaWiki.org

Jump to: navigation, search

This page has been superseded. The new bug reporting page is located at Extension:Blahtex/Bugs.

The bugs on this page all pertain to blahtex version 0.2.1. Blahtex has been completely rewritten since then, and many of the bugs (especially relating to spacing) have been swept up in the rewrite. Please report them again on the new bugs page if they still are causing problems.

Contents

[edit] OLD CONTENT

This is the place to report bugs and requests for new features in Extension:Blahtex.

Please start a new section if you have a new bug to add.

If your bug is actually a problem with a specific browser's rendering of MathML, consider filing it here instead.

This page is a bit like an "article" page and a bit like a "talk" page. You may discuss things here like on a "talk" page, but the conversation may eventually be distilled into something more succint. Use the actual talk page if you don't want your conversation to be summarised like this.

[edit] Bug: Spacing around ellipsis

  • Reported by: Omegatron 23:09, 28 July 2005 (UTC)
  • Status: maybe fixed in version 0.2

The spacing around the ellipsis in 997f5ab83e11f0604213ac12e63109db is not great, whereas the spacing in 995b298db7ba9333938381ff9509a539 is fine.

Looks good. - Omegatron 02:26, 4 August 2005 (UTC)

[edit] Solution

Actually the problem was with the spacing around the comma. I think it's a bit better in version 0.2. Let me know what you think. Dmharvey 21:42, 2 August 2005 (UTC)

[edit] Bug: Extra space at bottom of matrices

  • Reported by: Omegatron 23:09, 28 July 2005 (UTC)
  • Status: Fixed in version 0.2

[edit] Description

There is extra space at the bottom of the matrices in 9994b1ac491122c91c178a3ad68e8278 which is not present in 9910e94f748869e967e8e9ef32987a32 or 993caefc4bb56f7f093e779f75b16388.

[edit] Solution

The offending LaTeX code was something like

\begin{pmatrix} a & b \\ c & d \\ \end{pmatrix}

and the last "\\" was causing an extra table row to be generated. This has been fixed. Dmharvey 21:42, 2 August 2005 (UTC)

[edit] Bug: Space between "<<" characters

  • Reported by: Omegatron 23:09, 28 July 2005 (UTC)
  • Status: This is not a bug.

For example in 99d1d9133a0a5551e047a9560783aedc, the author should probably have used the "\ll" command instead of "<<". (Unless they were talking about a bitshift operator, in which case why were they writing in LaTeX?) Dmharvey 21:42, 2 August 2005 (UTC)

[edit] Bug: Space between thousands separators

  • Reported by: Omegatron 23:09, 28 July 2005 (UTC)
  • Status: open in blahtex 0.2.1, fix planned in blahtex 0.3.

[edit] Description

Blahtex does not distinguish between the LaTeX input

65,536

and the input

65{,}536

These should look like

Image:Blahtex-comma-bug-1.png

and

Image:Blahtex-comma-bug-2.png

respectively. (Note the different spacing after the comma.) The first method should be used for lists of numbers (like 2, 3, 5, 7, ...); the second should be used for writing down large numbers whose thousands are separated by commas.

(Thanks Jitse Niesen for pointing out the correct latex markup to distinguish the two cases; see also the TeXbook p134.)

[edit] Solution

Blahtex 0.3 will be much more aware of spacing issues and the subtleties conveyed by grouping braces.

[edit] Bug: ":=" renders as ": ="

  • Reported by: Omegatron 03:16, 4 August 2005 (UTC)
  • Status: open in version 0.2

In bdba39305b6a662b45cb70b7bcb90946, := renders as : = (Windows XP, Firefox 1.0.x)

[edit] Discussion

This is tricky. There is a command "\coloneqq" in a nonstandard LaTeX package ("txfonts" or "pxfonts") which does what you want, but LaTeX/AMS-LaTeX don't define it. Unfortunately those packages also seem to change the fonts used throughout your document. (I don't know anything else about those packages.)

That doesn't answer the question though. The problem is that ":=" is getting translated as two successive MathML operators, i.e. as

<mo>:</mo><mo>=</mo>

(You'll find that all existing translators out there do exactly the same thing.)

The problem is how to recognise, in general, that two successive LaTeX operators should be translated as one MathML operator. I'm not sure of the best way to do this in general. It might be possible to solve the problem in this particular case, but I'd rather see how it crops up in general first, and act on it when this is better understood.

Of course it's similar to the "<<" operator mentioned earlier, but in that case there is a standard command "\ll" which should have been used instead. Dmharvey 16:37, 4 August 2005 (UTC)

[edit] Bug: mozilla spacing tweak producing poor results in some situations

  • Reported by: Omegatron 03:16, 4 August 2005 (UTC)
  • Status: mostly fixed but still open for discussion in version 0.2

[edit] Description

In the translation of something like "10^2", there is a large space between the "1" and the "0".

The problem occurs under Windows XP, Firefox 1.0.x, with the mozilla tweaks turned off. Switching on the mozilla tweaks reduces the severity, but the result is still not perfect. (The problem does not occur with MathPlayer 2.0.)

Examples in the Wikipedia samples include bddfd11386561b4e0a9fad6cda86de0a, bdf16e4c7fdce2d1e74b98c91e9a6167, bd71b01fb7079bbadac8383b7a11748e, bd4b88f76626aafa246532849987a151, bd496c3e281c7de46be99bed85611f99, bddc2a2e6fcccb6315f7859e22b916da.

[edit] Discussion

The underlying problem here is that MathML is slightly more structured than LaTeX. The intended translation of "10^2" is

 <msup>
   <mn>10</mn>
   <mn>2</mn>
 </msup>

However, blahtex has no way of knowing that the base of the superscript is supposed to be the whole string "10". In fact, neither does LaTeX. This happens for the same reason that, for example, in "1^23", only the "2" is superscripted, not all of "23". It would be incorrect for blahtex to assume that the base is actually "10". (Knuth says as much in the TeXbook on p.129 (1996 edition)).

Clearly, one can tell blahtex what is intended by writing "{10}^2" instead. This doesn't really solve our problem, because people familiar with LaTeX expect that "10^2" will give them the intended result.

For LaTeX the distinction is usually unimportant, because its output is purely visual, although it does become important in comparing expressions like

((x^2)^3)^4

and

{({(x^2)}^3)}^4,

which do render differently in LaTeX. (This is Knuth's example.)

But blahtex does need to take the distinction into account, because its output is MathML, not visual. Therefore, the most correct MathML translation of "10^2" is something like

 <mn>1</mn>
 <msup>
   <mn>0</mn>
   <mn>2</mn>
 </msup>

This would be visually okay if Mozilla/Firefox did not insert too much space between the first <mn>1</mn> and the base of the following superscript. (Neither MathPlayer nor Amaya (for Mac) insert too much space.)

Unfortunately, Mozilla/Firefox does insert too much space. This appears to be the same bug that causes too much space to be inserted between <mi>...</mi> elements. (See the Mozilla bugs page -- this has also been reported by others on the official Mozilla MathML bugs page.) The workaround that blahtex uses for that bug seems to do a decent job in this case as well. Dmharvey 15:58, 10 August 2005 (UTC)

[edit] Bug: Infinity symbol size

[edit] Description

In bd2ebd189450412d6a70d7fef7141e8c, the infinities look different sizes in my browser. (Windows XP, Firefox 1.0.x)

[edit] Bug: Roman font subscripts look bigger than italics

[edit] Description

In input like

R_L = R_\mathrm{L},

the roman font L appears somewhat larger than the italics L.

[edit] Bug: path integral size

  • Reported by: Omegatron 03:09, 4 August 2005 (UTC)
  • Status: fixed in version 0.3 (not released yet)

In bdb9e77a6f12b2381fded0a2d8599278, \oint s are different sizes (Windows XP, Firefox 1.0.x)

[edit] Discussion

There are several other operators that had this behaviour. Hopefully they are all fixed now. Unfortunately Mozilla in unable to stretch certain operators at all, so you'll find that "\bigvee" doesn't work properly. Dmharvey 13:03, 6 August 2005 (UTC)

[edit] Bug: < and > recognized as langle and rangle

\left <:

Failed to parse (syntax error): \left < {12 \over 34} \right >


is rendered the same as \left \langle:

\left \langle {12 \over 34} \right \rangle

Although I think this is the way it should work, texvc doesn't work this way, so it should be removed for consistency. Otherwise we'll have people like me editing with mathML output and no problems, and regular people looking at the "Failed to parse" error.

The other alternative is to get them to add it to texvc, but it may be be invalid latex. There's no way you could modify one of the pre-existing TeX --> mathML converters for our use, is there? Then we'd be sure it interprets things the "official" way for everything. - Omegatron 15:53, 10 August 2005 (UTC)

Actually, this is correct LaTeX. "\left\langle" is rendered equivalently by LaTeX to "\left<". The reason texvc breaks is that its author(s) didn't allow it to recognise "<" as a delimiter.
By the way, what makes you think that any of the existing converters do things the "official" way? :-) In fact, two of the three converters that I have listed on the main blahtex page do "\left<" and "\left\uparrow" incorrectly. (I can't test the Canadian demo, they seem to be down at the moment.) I suspect that the current state of LaTeX => MathML translators is not as good as you think it is.
(Update: the Canadian guys get the "\left<" incorrect, but they do get the uparrows correct. Conclusion: none of the existing converters listed on the blahtex page do "\left<" the way that LaTeX does it. Dmharvey 11:15, 12 August 2005 (UTC))
But you have raised a very interesting question, about what to do about constructs that blahtex accepts and texvc does not. (There are plenty of other odd examples of this that you haven't found yet :-). ) I have thought about this long and hard. The best solution I can come up with is the following.
Blahtex does at least as much work as texvc in terms of parsing the input expression. Far more in fact. Obviously, it has to. Therefore, it would be relatively trivial to reproduce all of texvc's functionality (except perhaps latex => HTML conversion) in blahtex. In other words, when we have a demonstration version of blahtex/mediawiki up and running, it won't require much extra work to get blahtex to do all the PNG rendering that texvc currently does. So I'm talking about eventually replacing texvc entirely.
So I guess that I want "backward compatibility" to mean "no existing equations will break" rather than "blahtex knows no more and no less than texvc". Dmharvey 16:29, 10 August 2005 (UTC)
Well, eventually, when all browsers support mathML perfectly and that is all anyone ever wants to use, it may replace texvc, but for now, and probably a few years into the future, only a few people are going to use mathML output, and the two are going to have to coexist. So it is more important right now to make them as compatible as possible, including quirks.
For something like this, of course, the best way to make them exactly compatible is to add this function to texvc instead of crippling blahtex. - Omegatron 21:29, 10 August 2005 (UTC)
Actually, I expect that blahtex will be doing the PNG conversions before we even switch on the MathML functionality. :-) Dmharvey 22:13, 10 August 2005 (UTC)
Ah! Well in that case I guess I don't understand the mission of blahtex. I thought it was to fit into texvc where the previous minimal mathml converter was. - Omegatron 01:47, 11 August 2005 (UTC)
You are right, that was my original intention, and that is how I've been mostly explaining it. But because of issues like the one you've raised, it's become clear that it will work better if it simply replaces texvc altogether. I don't think this is really such a big deal. Blahtex already does most of the hard work that texvc does. (i.e. the "validation" part of "TEX Validation & Converter".) I believe that the PNG conversion is relatively easy, as long as you know what system calls to use. The main thing missing at the moment is a LaTeX => HTML converter. I haven't studied that part of texvc at all, so I don't know exactly what's required. Dmharvey 10:32, 11 August 2005 (UTC)

[edit] Update: I am a bit puzzled

I said earlier that "\left<" is standard LaTeX. Now I'm not so sure that this is the case. Everywhere on the web indicates the opposite.

Nevertheless my installation of LaTeX, and two others that I have tried (on different operating systems) all translate "\left<" the same way as "\left\langle". In fact, even just plain TeX by itself seems to do so! I'm running the fink version of latex. Please somebody explain this mystery to me! Dmharvey 18:53, 14 August 2005 (UTC)

[edit] Puzzlement resolved

Aha. On p150 of the TeXbook, Knuth says that "<" is indeed equivalent to "\langle" for the purposes of delimiters. Discussion closed :-) Dmharvey 19:08, 14 August 2005 (UTC)

[edit] Spaces between numbers and units are rather large

10 V = 10\ V = 10\ \mathrm{V}

10 V = 10\ V = 10\ \mathrm{V} - Omegatron 00:15, 12 August 2005 (UTC)
There are two distinct problems to deal with here.
  • First, for "10V", is the spacing problem corrected for you by turning on the "mozilla tweaks"?
I didn't mean there was a problem with 10V. Just showing it for comparison. It looks fine with or without tweaks, really. - Omegatron
  • Second, for "10\ V", if you try using "\," instead, is that closer to what you expected "\ " to do? Or is it still too large? (btw I have a bad feeling about Mozilla's interpretation of MathML mspace elements.) Dmharvey 10:20, 12 August 2005 (UTC)
Yes, the \, spacing looks better. Still a little wide, maybe. - Omegatron 14:39, 12 August 2005 (UTC)
Retrieved from "http://www.mediawiki.org/wiki/Extension:Blahtex/Bugs_and_feature_requests"
Personal tools