Help talk:Displaying a formula/Archives/2007

Why not use ASCIIMathML?

Hi math people. Why doesn't Wikipedia use ASCIIMathML to render equations? I have used it on my blog, and it seems to work well, producing equations that are much nicer-looking than what Wikipedia currently produces by default (i.e., gigantic JPEGs). It seems like better technology is already available, no? Why can't we have nice-looking math right now? Thanks. —Dfass 17:36, 6 February 2007 (UTC)

This is the first time I've seen this ASCIIMathML, and yes, it looks great! ...Only when I used Firefox. It says "This page requires Internet Explorer 6+MathPlayer or Mozilla/Firefox/Netscape 7+", and sure enough it didn't work on my Safari. (I only got plain text instead of an equation.) I guess it won't work on plain vanilla IE too. (Correct me if it does. I don't use Windows...) I think the requirements for that tool to render properly is too high. --朝彦 (Asahiko) 14:50, 7 February 2007 (UTC)

Plain text

There are several things that produce plain text:

• mbox
• mathrm
• textrm

What's the difference?

• ${\mbox{mbox produces plain text}}_{\mbox{with a subscript}}$
• $\mathrm {mathrmproducesplaintext} _{\mathrm {withasubscript} }$
• ${\textrm {textrmproducesplaintext}}_{\textrm {withasubscript}}$

According to this, our implementation is wrong, and textrm should respect whitespace:

• mbox $50{\mbox{ apples}}\times 100{\mbox{ apples}}={\mbox{lots of apples}}$
• math $50\mathrm {apples} \times 100\mathbf {apples} ={\mathit {lotsofapples}}$
• text $50{\textrm {apples}}\times 100{\textbf {apples}}={\textit {lotsofapples}}$

• $A=\pi r^{2}$
• Failed to parse (syntax error): {\displaystyle \mbox{A = \pi r^2}}
• $\mathrm {A=\pi r^{2}}$
• ${\textrm {A=\pi r^{2}}}$

— Omegatron 23:03, 24 February 2007 (UTC)

How to do …

… a « ç » ? User:VIGNERON 20:39, 27 February 2007 (UTC)

D'après le guide LaTeX, c'est supposé être :<math>\c{c}</math>, mais ça donne :

Failed to parse (unknown function "\c"): {\displaystyle \c{c}}

Urhixidur 18:18, 2 September 2007 (UTC)

exponential of exponential

$2^{2^{n+2}}$ does not, in my opinion, make it obvious to the casual reader that $2^{x}$ with $x=2^{n+2}$ is meant. It looks more like $2^{2n+2}$. Is there a way for me to make the last exponent "higher" for clearness? Thanks, Richard L. Peterson March 12, 2007; forgot to log in.

I think it's pretty clear how it is, but you could do this: $2^{2^{\overset {n+2}{}}}$. --Egriffin 15:41, 23 March 2007 (UTC)

mathscr

Is there anywhere I can complain to get \mathscr to work, which needs \usepackage{mathrsfs} of course. This command is needed to represent \mathscr{I}^+, etc, which is "future null infinity". To give a technically correct formal definition of a black hole, for instance, you want to use this symbol. I couldn't figure out how to hack texvc for my own nefarious purposes. Is texvc still being maintained?--Lionelbrits 02:05, 30 March 2007 (UTC)

Looks like one needs to edit /math/texutil.ml and recompile.--Lionelbrits 20:22, 1 April 2007 (UTC)

Adding symbols to TeX

How does one go about adding symbols or commands to TeX? For instance, there is a section here in "Displaying a formula" for "Unsorted new stuff". How does one create "new stuff"——If it has to be approved, where does one submit it? ~Kaimbridge~17:35, 9 June 2007 (UTC)

Update Patch for MediaWiki 1.10.0

In Mediawiki 1.10 (and perhaps earlier) the paths for reaching math PNG images have changed, so the above patch must be changed slightly. Step 1 (above) involving the shell script remains the same. But now replace step 2 (in /wiki/includes/Math.php) with this:

       function _linkToMathImage() {
               global $wgMathPath;
               $url = htmlspecialchars( "$wgMathPath/" . substr($this->hash, 0, 1)
                                       .'/'. substr($this->hash, 1, 1) .'/'. substr($this->hash, 2, 1)
                                       . "/{$this->hash}.png" );
               $alt = trim(str_replace("\n", ' ', htmlspecialchars( $this->tex )));
            #  return "<img class='tex' src=\"$url\" alt=\"$alt\" />";
               $wgGetTexImageHeightInEx = './math/getTexImageHeightInEx.sh';
               $cmd = $wgGetTexImageHeightInEx .' '. wfEscapeShellArg( $this->_getHashPath() . "/{$this->hash}.png" );
               $heightInEx = chop(`$cmd`)."ex";
               return "<img class='tex' src=\"$url\" alt=\"$alt\" style=\"height:$heightInEx;\" />";
       }

Note that we no longer must declare $wgMathDirectory to be global because the path to PNG images is now built by the new function _getHashPath() in Math.php. --Jhaile 13:41, 28 June 2007 (UTC)

Update Patch for MediaWiki 1.13.3

Again the original source of Math.php has been updated, this time to form XML tags. This piece of code works for me:

        function _linkToMathImage() {
               global $wgMathPath;
               $url = "$wgMathPath/" . substr($this->hash, 0, 1)
                                       .'/'. substr($this->hash, 1, 1) .'/'. substr($this->hash, 2, 1)
                                       . "/{$this->hash}.png";

               $wgGetTexImageHeightInEx = './math/getTexImageHeightInEx.sh';
               $cmd = $wgGetTexImageHeightInEx.' '.wfEscapeShellArg( $this->_getHashPath()."/{$this->hash}.png" ); 
               $heightInEx = chop(`$cmd`)."ex";

               return Xml::element( 'img',
                       $this->_attribs(
                               'img',
                               array(
                                       'class' => 'tex',
                                       'alt' => $this->tex,
                                       'style' => 'height:'.$heightInEx ),
                               array(
                                       'src' => $url ) ) );
       }

HOW TO MAKE PRETTIER FONT-SIZED PNGs

So the above works, but the pngs can look a little ugly. (At least they do on Safari 1.3, and probably on some other browsers.) Can we do something to fix this? Of course we can.

If you spend some time screwing around with this stuff, you will see that the PNGs produced by texvc are created at a size that is kinda-sorta about the right size for what the texvc author hopes is the most common font size they'll be used with. Since we are now getting the browser to scale them for us, we can change this to create them at whatever size we think makes sense. In an ideal world what one would do is something like create the png at the largest practical size at which it might be displayed, and rely on the browser to scale it down appropriately. This would provide the maximum amount of information in the png for the scaling operation. The problem is that for this to work, the browser has to do a decent job of scaling down the image, in particular it has to use a scaling algorithm that does not generate aliasing (in the good old sampling theorem sense), eg some sort of multi-tap filter. Unfortunately it seems that at least Safari 1.3, and I'm guessing other browsers, do not utilize such an algorithm but appear to use old-fashioned linear interpolation. It is this lame-assed interpolation that makes our newly scaled pngs sometimes look not-so-great. What can we do about this?

Option one is to say screw it; tell the browser vendors to bring their products into the 21st century. Firefox does the scaling correctly. I don't know if Safari 2.0 does or not --- if not, someone should write a bug report because Apple clearly has code to do this right, since Preview.app does it correctly (even better than Firefox). The big issue is presumably whether IE does it right or not.

Option two is to accept lame browsers and ask: what's the best we can do to generate a good image?
The answer is that we want a png that is

1. appropriately sized and
2. dark enough.

Appropriately sized means that it should be a little larger than the smallest size we'd expect to be used, but not much larger. If it's a little larger than the smallest value we expect it to be used at, then its display under normal sizes will be at scalings of around 1x, while small scalings will be at around .75x and large scalings at up to maybe 1.5x. Even linear interpolation can do an acceptable job in that range of scaling.
Dark enough refers to the fact that scaling (linear interpolation or multi-tap-filter based) is usually done using raw RGB values, not gamma-corrected RGB values. For most images this works fine, but for TeX type images with very strong black-white transitions, the scaled images result in greys, and the non-linearity of gamma correction means the scaled image doesn't seem as dark as the non-scaled image. We can generate darker images by forcing TeX to create its dvi file using smaller point fonts (which are, as should be obvious) darker on average than larger point fonts.

So putting these together and performing a whole lot of experimentation, we arrive at the following set of optimal parameters:

• we tell convert to use a density of 150 rather than texvc's original value of 120. This means the images created by convert (and thus ultimately by texvc) are 25% larger than they used to be.
• but we tell TeX to create the image using smaller fonts, in particular using the \footnote sized fonts.

The net result of this is that our empirical scaling-to-ex magic value of 0.11 is still valid, but we land up creating png's that are a little darker and that thus display better at smaller sizes.

How to actually do this? First we modify wiki/math/render.ml. We already modified this earlier to give us transparent pngs, now we modify it again to scale those pngs differently. Change the third line to

let cmd_convert tmpprefix finalpath = "convert -quality 100 -density 150  -matte -fuzz 1% -fill None -opaque White " ^ tmpprefix ^ ".ps " ^ finalpath ^ " >/dev/null 2>/dev/null"

The change here is from -density 120 to -density 150.

Second we modify wiki/math/texutil.ml to tell it to tell text to use smaller fonts. Change the line 52, the fourth line of the function get_preface() to

"\\pagestyle{empty}\n\\begin{document}\n\\footnotesize\n$$\n"

The change is that we added \\footnotesize\n into the stream of TeX this file generates, and \footnotesize is a LaTeX command that sets a smaller overall size for all subsequent text.

You will now need to cd to wiki/math and type make to rebuild texvc withh these two changes. You will also, and this is important, need to go to wherever you have your system storing the TeX pngs, usually wiki/images/math, and throw all those pngs away, otherwise those pngs will be used when pages are displayed rather than having new pngs created according to the new specifications we have given texvc. After the make, and the png disposal, you can now try to look at some TeX png pages. If you're using Firefox they probably won't look much different, but on Safari 1.3 (and I'm guessing IE 5) they will look quite a bit better.

You also need to clear out the "math" table in the wiki database. Dmharvey 22:41, 18 August 2005 (UTC)

Idea: How about generating PNG's in several different sizes and loading the right size using JavaScript? -- 143.229.1.42 16:40, 6 December 2007 (UTC)

TeX font table omission

The page at http://meta.wikimedia.org/wiki/Help:Displaying_a_formula lacks entries for italic bold letters, required to complete the partial boldface greek alphabet already in place. The missing entries MAY simply be of the form

   \boldsymbol{o} [omicron] 

etc in math mode; but as I only looked at this page in the first place because I couldn't get \boldsymbol to work in TeXShop, I'm not going to stick my neck out by attempting to correct it myself! 85.134.145.162 01:56, 19 October 2007 (UTC) Fred Lunnon

That works for me, but what is the problem? <math>\boldsymbol{\alpha}</math> gets you ${\boldsymbol {\alpha }}$ but <math>\boldsymbol{\omicron}</math> just gets a parsing error. Both upper and lower case omicron have a problem. Also <math>\boldsymbol{α}</math> is a parsing error so no consistency. 82.10.79.163 18:38, 26 April 2008 (UTC)