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

On 17/07/2014 18:25, Fr=E9d=E9ric Wang wrote:
> Le 17/07/2014 10:31, David Carlisle a =E9crit :
>> 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 wuot=
ed
>> 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.
>
> It's because I'm considering the MathJax output a "MathML rendering =

> engine" while in your comparison with XSLT your are considering it a =

> "transformation mechanism". But whatever the point of view, the =

> interpretation of the class=3D"MJX-..." to generate a specific rendering =

> is specific to MathJax, to the XSLT transform or to your =

> transformation mechanism. So if you don't like the term non-standard, =

> call it an "extension of MathML", a "special behavior" or a =

> "proprietary feature". But still that won't change that the only =

> guarantee you have when passing "<mi class=3D"womble">A</mi>" is that it =

> will rendered as an italic A by a MathML rendering engines + =

> optionally some CSS style if you provide a stylesheet. AFAIK, any =

> other behavior is not defined by existing Web standards.

I don't think of using a defined attribute (class) with explicitly open =

ended use as an "extension2 (it's not like say  using extra elements or =

using mathvariant=3D"calligraphic"
but other than that terminology difference I don't think we disagree =

anywhere in this thread:-)

>
>> 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."
>
> So the only thing you're saying is that MathML is not so strict on the =

> interpretation of the class attribute. But still, I don't see where it =

> is specified in the MathML spec that the exact class=3D"MJX-..." is to =

> be interpreted as the MathJax rendering does, so to me this behavior =

> is not standardized and specific to MathJax. I say "non-standard" for =

> something that is not defined by any standard while for you anything =

> that does not contradict the spec seems to be "standard". Well, that's =

> probably a different point of view, but for me it's a problem to rely =

> on a feature specific to only one rendering engine...

MathML is rendered by css and non css systems so I think _unless_ we =

extend mathml (or more to the point extend Unicode)  the least effort =

way for the user (and mathml generators) tp get cross system support for =

calligraphic would be to agree a class name such as <mi =

class=3D"calligraphic" mathvariant=3D"script"> then any css based renderer =

can use standard css selectors to do as you showed but say MS Word or  =

mathematica or TeX or APP/3B2 or any number of other non css renderers =

can also produce calligraphic.  Nothing of course prevents authors using =

arbitrary css selectors and arbitrary css styling with the standard =

fallback that that styling is ignored in non css systems, but a =

standardised class name (which is hardly a novel idea) allows a wider =

range of systems to understand the markup.

>
>> 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)
>
> It seems that the only reasonable change is to define new unicode =

> points and mathvariants. =



We could try, I have no idea how likely it is that this would be =

accepted but certainly if we don't ask it won't happen:-)


> Or to leave this undefined in the MathML spec and leave the definition =

> of specific rendering to other specifications like CSS or Open Font =

> Format.
>
>> 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.
>
> It looks like many people in this thread agree that mathcal and =

> mathscript have different meaning, so that's probably worth considering.
>
>> 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?
>
> No you don't need to standardize anything about the class name, the =

> rendering is already defined by CSS / Open Font Format (and as I said, =

> standardizing anything would probably clash with CSS). =


there would be no clash with css all I'm suggesting is that you could =

add something for mi.calligraphic to the mathml css that you already have.

> Authors will just use whatever CSS selectors they want (not just =

> class) and must indeed provide the associated stylesheet... well =

> that's just how we handle Web documents! If that's a problem that e.g. =

> the calligraphic style is lost (e.g. if one disable the document =

> stylesheet or copy the MathML source code) then that certainly is an =

> indication that it has a specific semantic and so again standardizing =

> it as unicode/mathvariant should be considered instead.
>
As I say above that's fine for CSS based systems but there is an awful =

lot of MathML being handled by non css systems.


David