Re: [LaTeXML] Fwd: Special TeX/LaTeX fonts in MathML (calligraphy vs. script)

Le 17/07/2014 02:42, David Carlisle a =E9crit :
> On 16/07/2014 22:44, Fr=E9d=E9ric Wang wrote:
>> It's because you are talking about the syntax of the MathML markup
>> while I'm talking about its semantics. AFAIK, using a class name
>> "MJX-..." to change the rendering behavior of elements other than by
>> CSS styling is non-standard =3D not defined in any standard.
>
> It's not defined by MathML but it is explicitly not defined (thus
> allowed) by MathML, the definition of class(in 2.1.6) is
>
>  > Associates the element with a set of style classes for use with
> [XSLT] and [CSS21].
>  > Typically this would be a space separated sequence of words, but this
> is not specified by MathML.
>
> so it explicitly sanctions XSLT transforms rather than css to pick up
> the class:
> times and language fashions change, but using javascript rather than
> xslt isn't really any different.
>

Well I have to disagree, your quotation only says that the class =

attribute can be used to provide a style via XSLT/CSS (which we all =

know) but not that class=3D"MJX-..." with the *exact* class name provides =

a specific semantics to reinterpret the rendering behavior, which is =

what MathJax does. Moreover MathJax (at least the SVG output) does not =

use CSS to change the rendering behavior, so that can't be considered =

some kind of rules in a virtual "user agent stylesheet" (and even if so, =

it would be bad to have selectors on class names in such stylesheet). =

Then to prevent conflicts between MathML content and other elements in =

the page (cf why the "MJX-" prefix was added), you would need to say =

that the class name are reserved for some specific MathML semantic, =

which would definitely clash with the CSS specification and would need =

more than an informal agreement.

Note that here I'm considering the "MathML rendering engine" part of =

MathJax, not the "MathML generator". So make the distinction clearer, my =

point is that the MathML spec says that LaTeXML can attach =

class=3D"ltx_font_mathcaligraphic" to provide specific CSS style but no =

standard says that Gecko can automatically interpret this exact class =

name to change the MathML rendering behavior.

> If different systems are using <mi class=3D"wibble" mathvariant=3D"script=
">
> to distinguish calligraphic rather than script,
> then some kind of note or even informal agreement to use the same class
> names is probably a pragmatic solution.
> whether they use css or c++ or javascript to cause that class attribute
> to have any effect isn't really the concern of the MathML spec.
>

Yes, but certainly a bad solution from a standardization point of view. =

We want something that is well-defined and compatible with CSS, not just =

an informal agreement on class names.

>  From the mathml spec viewpoint that's really saying that a script A and
> calligraphic A are the "same" but one is just styled differently
> In some cases that is definitely a reasonable description of reality.
> I'm sure though there are some documents that use the two
> alphabets in an intentionally distinct manner. using class for that is
> arguably less than ideal however the alternative of getting
> a new calligraphic alphabet added to unicode and (perhaps) a new
> calligraphic mathvariant to match , and then getting fonts updated
> to use the new Unicode code has lots of procedural and time
> disadvantages, it would take years to get deployed and if used would
> probably have bad fallback in systems without updated fonts. That's not
> to say it shouldn't be attempted. Especially if browser and font
> implementers all asked for that, and there were published documents
> using both forms in the same expression....
>

I believe that if the calligraphic style is really use for some =

semantics, then it should follow the same procedure as the other =

mathvariants and have new Unicode code points reserved for them.
For now, I'm happy with the solution to just use standard CSS
/ OpenType features to access the specific glyph variants.


-- =

Fr=E9d=E9ric Wang
maths-informatique-jeux.com/blog/frederic