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

David Carlisle <[email protected]> Thu, 17 Jul 2014 09:31:06 +0100
Newsgroups gmane.comp.mozilla.devel.mathml
Message-ID <[email protected]>
On 17/07/2014 06:47, Fr=E9d=E9ric Wang wrote:
> 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.


Sorry I don't understand that comment at all, if I write  MathML to TeX =

converter ion XSLT and choose to
detect <mi class=3D"womble">A</mi> to generate \mathcal{A} then the wuoted =

paragraph is telling me that's OK.
XSLT is only being used as an example transformational mechanism there, =

if you write the same thing in javascript
the same rules apply.


> 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.
>

Yes sure, if the thing is embedded in a larger system that _is_ using =

the class attribute for css styling there are coordination issues to be =

addressed, but my point is that the  mathml spec is silent on the issue =

as it does not assume css rendering at all.


> 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.
>


No that is exact;y what the mathml spec does _not_ say. It explicitly =

says in the paragraph I quoted earlier that a MathML generator such =

LaTeXML may use the class attribute to affect the styling  and that it =

_may_ use css syntax in that attribute, but even if css syntax is used =

it does not say that css has to be used to render it "Typically this =

would be a space separated sequence of words, but this is not specified =

by MathML."
>> If different systems are using <mi class=3D"wibble" mathvariant=3D"scrip=
t">
>> 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.
>


That would be good but do you have a suggestion? The only suggestions =

that I'm aware of currently are using a class then
using css elsewhere to select the font features as you demonstrated =

earlier. Or getting a change to Unicode to distinguish
these characters (which has possibly a simpler end story but far more =

complicated procedural path to reach that)
>>  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.

Well yes that's the question: when they decided on this last time they =

decided that calligraphic and script were just font choices
typically to get a change you/we/someone would have to find a body of =

published work that is clearly using mathcal and mathscript
for different uses in the same document.
> For now, I'm happy with the solution to just use standard CSS
> / OpenType features to access the specific glyph variants

Yes the CSS may be standard but to generate mathml that uses that css =

(or equivalent, such as a TeX based typesetter)
don't you in practice need some standardised class names that you =

objected to above? or else the styled mathml
will only use the intended alphabet style if used with one target =

stylesheet?

David