Hi everyone, A follow-up question after Fred commented <https://github.com/dpvc/MathJax/commit/98e3f098bd519dabe9bf558736c5bf6438fbc217> on our changes to MathJax (following the results of this discussion); these changes include resetting the scriptlevel to 0. To us, this seemed to make the most sense after the discussion: if display style wasn't supposed to be inherited, then scriptlevel seemed strange to inherit (also, there were some "matching TeX behavior" comments on this thread). To put it differently, we couldn't imagine how an author setting displaystyle to "true" would expect to stay at scriptlevel=1 (for example). The only use-case we could think of would be an array in a superscript or fraction, but this doesn't seem very likely. However, as Fred pointed out, the spec seems to read differently. Since displaystyle needed to be clarified, we thought it's best to ask for clarification on this as well. Thanks in advance, Peter. On Fri, Jun 13, 2014 at 10:28 AM, David Carlisle <davidc@nag.co.uk> wrote: > On 13/06/2014 07:13, Frédéric WANG wrote: > > Le 13/06/2014 01:29, David Carlisle a écrit : > > Unlike array, aligned sets its cells in displaystyle so should map to > <mtable displaystyle="true"> which is no harder to generate than <mtable> > You don't need to generate many (or any) mstyle elements. > > It's unfortunate if some convertors get that wrong but it shouldn't be > hard for the maintainers to fix them (Davide's already entered a bug > for MathJax.) > > Thank you David. Are there any table-like environments that inherit the > displaystyle (and could be nested)? If they all automatically force either > displaystyle="true" or displaystyle="false", then I'm no longer concerned > (except that we're likely to get report like > https://bugzilla.mozilla.org/show_bug.cgi?id=1011237 until everybody > align on the MathML spec). > > - > > > > In TeX? > > No not really: the underlying \halign alignment structure always takes you > out of math mode > and there is no sane way of "inheriting" the current math style through to > the cells. > So macros tend to use textstyle (like array) or displaystyle (like > aligned). > > > The only way in TeX to fake inheriting the current style is to set the > entire alignment in all four styles > (display, text, script and scriptscript) and have the primitive > \mathchoice pick one as it lays out the > final math list after the macro layer hands over control. That's slow and > painful and so typically > only used for things that have "hidden alignments" eg the use of \ooalign > to make up constructed symbols > such as plain TeX's \rightleftharpoons. I don't know of any common macro > definitions in the usual TeX > packages that make alignments with author supplied content in cells that > inherit the display style. > > David > >

On 17/09/2014 20:37, Peter Krautzberger wrote: > Hi everyone, > > A follow-up question after Fred commented > <https://github.com/dpvc/MathJax/commit/98e3f098bd519dabe9bf558736c5bf6438fbc217> > on our changes to MathJax (following the results of this discussion); > these changes include resetting the scriptlevel to 0. To us, this > seemed to make the most sense after the discussion: if display style > wasn't supposed to be inherited, then scriptlevel seemed strange to > inherit (also, there were some "matching TeX behavior" comments on > this thread). > > To put it differently, we couldn't imagine how an author setting > displaystyle to "true" would expect to stay at scriptlevel=1 (for > example). The only use-case we could think of would be an array in a > superscript or fraction, but this doesn't seem very likely. > > However, as Fred pointed out, the spec seems to read differently. > Since displaystyle needed to be clarified, we thought it's best to > ask for clarification on this as well. > > Thanks in advance, Peter. > I think the spec is clear, and the splitting of tex's \xxxstyle concept into two separately settable parameters was certainly intentional: 3.1.6 says > TEX's \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle > correspond to displaystyle and scriptlevel as "true" and "0", "false" > and "0", "false" and "1", and "false" and "2", respectively. That choice inevitably means that there are combinations not reachable in TeX (and thus uncommon to most authors and probably unlikely to be used except in exceptional circumstances) but I think it's clear that the spec intends that they are reachable. David

Thanks, David, for confirming the reading of the spec. So to guarantee \displaystyle we're supposed to do something like <mstyle scriptlevel="0"> <mtable displaystyle="true"> ... </mtable> </mstyle> To guarantee \textstyle something like <mstyle displaystyle="true" scriptlevel="0"> <mtable> ... </mtable> </mstyle> And <mfrac> <mtable displaystyle="true"> ... </mtable> <mrow> ... </mrow> </mfrac> would get us a table with displaystyle formatting, but in scriptstyle size (when used in an inline formula). (I admit I find that somewhat strange; oh well.) Thanks again for your quick response! Peter. On Thu, Sep 18, 2014 at 5:07 PM, David Carlisle <davidc@nag.co.uk> wrote: > On 17/09/2014 20:37, Peter Krautzberger wrote: > >> Hi everyone, >> >> A follow-up question after Fred commented >> <https://github.com/dpvc/MathJax/commit/98e3f098bd519dabe9bf558736c5bf >> 6438fbc217> >> on our changes to MathJax (following the results of this discussion); >> these changes include resetting the scriptlevel to 0. To us, this >> seemed to make the most sense after the discussion: if display style >> wasn't supposed to be inherited, then scriptlevel seemed strange to >> inherit (also, there were some "matching TeX behavior" comments on >> this thread). >> >> To put it differently, we couldn't imagine how an author setting >> displaystyle to "true" would expect to stay at scriptlevel=1 (for >> example). The only use-case we could think of would be an array in a >> superscript or fraction, but this doesn't seem very likely. >> >> However, as Fred pointed out, the spec seems to read differently. >> Since displaystyle needed to be clarified, we thought it's best to >> ask for clarification on this as well. >> >> Thanks in advance, Peter. >> >> > I think the spec is clear, and the splitting of tex's \xxxstyle concept > into two separately settable parameters was certainly intentional: > > 3.1.6 says > > TEX's \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle >> correspond to displaystyle and scriptlevel as "true" and "0", "false" >> and "0", "false" and "1", and "false" and "2", respectively. >> > > > > That choice inevitably means that there are combinations not reachable > in TeX (and thus uncommon to most authors and probably unlikely > to be used except in exceptional circumstances) but I think it's clear > that the spec intends that they are reachable. > > > > David > > > > > >

On 18/09/2014 22:09, Peter Krautzberger wrote: > Thanks, David, for confirming the reading of the spec. > > So to guarantee \displaystyle we're supposed to do something like > > <mstyle scriptlevel="0"> > <mtable displaystyle="true"> > ... > </mtable> > </mstyle> > To guarantee \textstyle something like > > <mstyle displaystyle="true" scriptlevel="0"> > <mtable> > ... > </mtable> > </mstyle> well if an author is coding directly in mathml probably wouldn't have the mstyle. If you're converting from TeX code (that is not using \mathchoice) then you would need that for absolute fidelity, although to be honest often if tex alignments end up being used in a subscript the author _doesn't want the table to stay using large fonts, and ammends the code to use mathchoice so it gets smaller. > > And > > <mfrac> > <mtable displaystyle="true"> > ... > </mtable> > <mrow> > ... > </mrow> > </mfrac> > > would get us a table with displaystyle formatting, but in scriptstyle > size (when used in an inline formula). (I admit I find that somewhat > strange; oh well.) again, if tex did this you probably wouldn't find it strange:-) > > Thanks again for your quick response! > Peter. From the speed you may note that it was a personal response, but I think I only cited what the spec is saying:-) David

Fair enough :-) Peter. Am 18.09.2014 23:33 schrieb "David Carlisle" <davidc@nag.co.uk>: > On 18/09/2014 22:09, Peter Krautzberger wrote: > >> Thanks, David, for confirming the reading of the spec. >> >> So to guarantee \displaystyle we're supposed to do something like >> >> <mstyle scriptlevel="0"> >> <mtable displaystyle="true"> >> ... >> </mtable> >> </mstyle> >> To guarantee \textstyle something like >> >> <mstyle displaystyle="true" scriptlevel="0"> >> <mtable> >> ... >> </mtable> >> </mstyle> >> > > well if an author is coding directly in mathml probably wouldn't have the > mstyle. > If you're converting from TeX code (that is not using \mathchoice) then > you would need that for absolute fidelity, although to be honest often > if tex alignments end up being used in a subscript the author _doesn't > want the table to stay using large fonts, and ammends the code to use > mathchoice so it gets smaller. > > > > >> And >> >> <mfrac> >> <mtable displaystyle="true"> >> ... >> </mtable> >> <mrow> >> ... >> </mrow> >> </mfrac> >> >> would get us a table with displaystyle formatting, but in scriptstyle >> size (when used in an inline formula). (I admit I find that somewhat >> strange; oh well.) >> > > again, if tex did this you probably wouldn't find it strange:-) > >> >> Thanks again for your quick response! >> Peter. >> > > > From the speed you may note that it was a personal response, but I think I > only cited what the spec is saying:-) > > David > >

Hi David and Peter, On 19/09/2014, at 7:33, David Carlisle <davidc@nag.co.uk> wrote: > On 18/09/2014 22:09, Peter Krautzberger wrote: >> Thanks, David, for confirming the reading of the spec. > >> <mfrac> >> <mtable displaystyle="true"> >> ... >> </mtable> >> <mrow> >> ... >> </mrow> >> </mfrac> >> >> would get us a table with displaystyle formatting, but in scriptstyle >> size (when used in an inline formula). (I admit I find that somewhat >> strange; oh well.) > > again, if tex did this you probably wouldn't find it strange:-) I can well imagine this being used in Statistics, or Statistical Mechanics, and related fields, where the fraction is the ratio of integrals or summations or products — especially for presentation slides, where the ratio of text width to line height is typically much less than in printed publications. Of course you need to manipulate the TeX by declaring \displaystyle within the numerator and denominator, as David suggests. But not all that strange, afterall. >> >> Thanks again for your quick response! >> Peter. > > > From the speed you may note that it was a personal response, but I think I only cited what the spec is saying:-) > > David Cheers, Ross

Le 03/07/2014 15:53, David Carlisle a écrit : > Oh Ok that's simpler: don't fix the names in the file just mark then > as set="historical" > OK good plan! Is there any update on this or a plan to lead to reliable set of LaTeX mappings (in the last version of unicode.xml I still see some of the errors I initially reported and no set="historical") ? As I see, the unicode-math names are not really "standard" (whatever it means for LaTeX), for example "GREEK SMALL LETTER ALPHA" is mapped by "\upalpha" instead of the more traditional "\alpha". Just marking the legacy mappings "historical" without fixing the errors, will not be very helpful for someone willing to rely on this set. -- Frédéric Wang maths-informatique-jeux.com/blog/frederic

On 05/09/2014 15:33, Frédéric WANG wrote: > Le 03/07/2014 15:53, David Carlisle a écrit : >> Oh Ok that's simpler: don't fix the names in the file just mark then >> as set="historical" >> OK good plan! > Is there any update on this or a plan to lead to reliable set of LaTeX > mappings (in the last version of unicode.xml I still see some of the > errors I initially reported and no set="historical") ? As I see, the > unicode-math names are not really "standard" (whatever it means for > LaTeX), for example "GREEK SMALL LETTER ALPHA" is mapped by "\upalpha" > instead of the more traditional "\alpha". Just marking the legacy > mappings "historical" without fixing the errors, will not be very > helpful for someone willing to rely on this set. > ah I'll see what I can do.... Although it really isn't so clear in a unicode setting that saying U+03B1 is traditionally mapped as \alpha really helps. U+03B1 is (as you know) textual Greek, and mapping it to \alpha with the traditional definition of \alpha will just lead to tex errors. Perhaps I can document that if the character element has mode="math" then the <latex> mapping is only assumed to work in math mode. But in anycase the errors you reported initially were just errors I think not relying on such details, I'll try to get that done..... David

Frédéric, Thanks again for your comments, a somewhat belated reply... > > - Some characters have mathclass="R?" (with a question mark)... I guess > that's because the mathclass is not clear, but it is unexpected for > someone who wants to process the file automatically... > fixed at the time, updating from version 11 to 13 of the unicode data. > - Some Arabic Letters (U+0627-U+063A and Arabic mathematical alphabetic > symbol) should probably have mathclass="A" since they are used as > mathematical variables. ftp://ftp.unicode.org/Public/math/ unicode still at revison 13, so this hasn't changed (unless I decide to break from exact matching of mathclass data with the Unicode data) > > - Some LaTeX commands map to different Unicode code points. For example > \mathsfbf{\Alpha} maps to both the capital and small (bold sans-serif) > alpha, which is clearly wrong (one should be \mathsfbf{\alpha}). See the > attached diff files for details. They were generated using the attached > XSLT stylesheet and the Unix command "xsltproc extract.xsl unicode.xml > | sort --key=2,2 > commands1.txt; cat commands1.txt | uniq > --skip-chars=7 > commands2.txt ; diff -U8 commands1.txt commands2.txt > > commands.diff". That one is clearly wrong but it isn't necessarily wrong that you get duplicate mappings in the latex to unicode direction. Classic Tex fonts do not for example have a full Greek alphabet so both U+006F and U+03BF ( latin o and Greek omicron) map to o. Al the entries in your MathLaTeX-commands.diff file are of this form as far as I can see, Greek letters with tonos being overloaded with latin letters with acute which is not exactly a brilliant mapping but agrees with classical tex usage. By far the biggest set of incorrect mappings wer essentially all the lowercase greek mathematical alphabet blocks having uppercase names. I fixed those thanks. Comments on some others in your LaTeX-commands-diff file below. the first group is U0002D - -U02010 - -U02212 - that is ascii - and the explicit hyphen and minus characters all mapping to - in latex, that again is the best you can do really if mapping to classic 7bit fonts -U0201A ,similar mapping the low quotation to a comma matches classical TeX usage -U02024 . One DOT leader, I suppose this could be \ldotp rather than . (although that's the same character in the default setup) -U02019 ' again using the ascii ' for the right quotation mark is normal tex usage -U00386 \'{A} as for the mathlatex usage this is the best approximation you can do in classic tex font distribution -U0212B \AA angstrom and A ring being same character, this seems correct -U0219D \arrowwaveright oops thanks, that's the left arrow.... -U025EF \bigcirc size mapping to classical fonts is a bit strained, this is "WHITE CIRCLE" and "LARGE CIRCLE" not sure I can do better but suggestions welcome -U022C5 \cdot "DOT OPERATOR" and "MIDDLE DOT" the latter is a bit of abuse of the math font but again accords with 7bit cm font usage. -U02662 \diamond diamond/lozenge -U02729 \ding{73} two different white stars -U02A63 \ElsevierGlyph{225A} This macro name is not actually usable to anyone other than Sebastian I guess -U00192 f f and script f. -U00261 g same for g -U1D716 \in -U1D750 \in -U1D78A \in -U1D7C4 \in Yes I guess I could wrap some of those in a math alphabet (although classic tex mathalphabet commands do not affect the standard definition of \in) -U0039C M Mu=M. -U1D6B3 M -U1D6CD M -U1D6ED M -U1D707 M -U1D727 M -U1D741 M -U1D761 M -U1D77B M -U1D79B M -U1D7B5 M Mu=M but I added the math alphabets \mathbf{M} etc U02306 \perspcorrespond -U02A5E \perspcorrespond Not sure either of these are really defined in classic tex setups, I made one var... (to match unicode-math) $ cvs commit -m "lowercase latex greek and other fixes (FW)" unicode.xml /w3ccvs/WWW/2003/entities/2007xml/unicode.xml,v <-- unicode.xml new revision: 1.78; previous revision: 1.77 David

Le 08/09/2014 00:35, David Carlisle a écrit : > Frédéric, > > Thanks again for your comments, > > a somewhat belated reply... Thanks David. I haven't had time to look into the details of the <latex> set, but the 3 issues of the <mathlatex> (http://lists.w3.org/Archives/Public/www-math/2013Dec/att-0001/MathLaTeX-commands.diff) seems to be fixed. The issue in the <AMS> set (http://lists.w3.org/Archives/Public/www-math/2013Dec/att-0001/AMS-commands.diff) does not seem to be fixed though. "LEFT RIGHT DOUBLE ARROW WITH STROKE" should probably map to \nLeftrightarrow (with an uppercase L) just like it is done for the <latex> and <mathlatex> sets. -- Frédéric Wang maths-informatique-jeux.com/blog/frederic

Le 12/09/2014 18:54, Frédéric WANG a écrit : > but the 3 issues of the <mathlatex> > (http://lists.w3.org/Archives/Public/www-math/2013Dec/att-0001/MathLaTeX-commands.diff) > seems to be fixed. > Al the entries in your MathLaTeX-commands.diff file are of this form > as far as I can see OK, actually I executed the wrong command for MathLaTeX-commands.diff. Indeed, the three duplicates are still here but as you say that's expected per classical tex limitation. I now see new duplicates from the unicode-math set for U03014 \lbrbrak U03018 \Lbrbrak U03015 \rbrbrak U03019 \Rbrbrak -- Frédéric Wang maths-informatique-jeux.com/blog/frederic

I verified the latex set this morning and I think you are right that we can not probably do better for the Unicode-to-LaTeX mapping. I attach the updated LaTeX-commands.diff. Since I need the LaTeX-to-Unicode mapping for my math converter, I now only take the "AMS" set as a reference (+ some commands from itex2MML). The remaining issues for the AMS set are the duplicate in http://lists.w3.org/Archives/Public/www-math/2013Dec/att-0001/AMS-commands.diff as well as the question mark for <AMS>\doublebarwedge ?</AMS> (should it be \doublebarwedge or, to match unicode-math \vardoublebarwedge?). Later, I'll try to analyze more carefully the difference between what I get from unicode.xml and itex2MML (mathclass etc) and see if there is anything relevant to say. More comments below. >> - Some Arabic Letters (U+0627-U+063A and Arabic mathematical alphabetic >> symbol) should probably have mathclass="A" since they are used as >> mathematical variables. > > ftp://ftp.unicode.org/Public/math/ > unicode still at revison 13, so this hasn't changed (unless I decide > to break from exact matching of mathclass data with the Unicode data) Do you know when the Unicode group will consider this change? (and whether they have approved that?) > On 03/07/2014 13:49, Patrick Ion wrote: >> I would urge you to change the "nameless" <latex> entries to a >> 'set="latex-historical">' at least so as not to lose the record of >> where people may have got their authoritative info So it seems that this request to add set="latex-historical" has been ignored. In my opinion, keeping these "latex-historical" entries is not really useful since the changes are already recorded in the CVS history, and actually I believe using revision control system is the proper way to record this kind of info. The only potential problem I see is that this CVS repository does not seem public... or is there at least a public web page for that? -- Frédéric Wang maths-informatique-jeux.com/blog/frederic

Dear all, Firefox 32 will be released this week, please find some release notes below. As usual, you can check https://wiki.mozilla.org/MathML:Home_Page#Last_bugs_fixed and https://developer.mozilla.org/en-US/Firefox/Releases/32#MathML for details. * Gecko 32: - Implement menclose notation "phasorangle" - Improvements to the MathML stretchy code * Gecko 33: - Add support for mtable@rowspacing/columnspacing/framespacing attributes - Use Open Type MATH constants for fractions, stacks, radicals and scripts * Gecko 34: - Fix a performance regression due to the mathvariant improvements in Gecko 28 -- Frédéric Wang maths-informatique-jeux.com/blog/frederic