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

On 18/07/2014 06:33, Fr=E9d=E9ric Wang wrote:
> Le 18/07/2014 00:21, David Carlisle a =E9crit :
>> That's not an unreasonable position to take although (in the absence of
>> an update to Unicode and matching updates to fonts, which would be years
>> at least) that would mean that any document using a mathml fragment to
>> be rendered in calligraphic would need at the document level to apply
>> some css to achieve that. That's certainly less convenient for mathml
>> generating tools (as basically it means they can't support calligraphic
>> within the math expression) but I'm not strongly arguing that you should
>> do differently as it is I agree a coherent position to take.
>> But suggesting a class name can't hurt in any case as something like
>> that would be needed in any case for other systems as I said. No need to
>> highlight mathjax theer are many non css based systems Word for example.
>
> Well, in that case the discussion and your proposal are clearly =

> motivated by MathJax's specificity. =


Perhaps the start of the thread was (I didn't check) but my comments are =

not motivated by anything
MathJax specific (I don't actually know what MathJax does here), usually =

my comments are biased by a TeX and XSLT background:-)

> But in general, there are many problems in the MathML specification =

> due to the fact that the spec was written with non-css based systems =

> in mind (before MathJax ever exists) or, depending on the point of =

> view, due to the fact that browser vendors did not involve enough to =

> influence the decisions. So I would personally not buy any argument =

> around "this is needed to make it work with non css based systems". If =

> calligraphic is considered something important then I believe it =

> should be and should have been standardized like the other mathvariant =

> attributes.

Yes it's easy to say that "it should be in Unicode" and if it was in =

Unicode it would be much clearer which markup to use.
But at the current time it is not in Unicode.

The topic as I thought was what markup to use now, while it isn't in =

Unicode.

> Adding a temporary solution because the Math WG was not able to get =

> that accepted before does not seem a very good way to handle the issue =

> ; tools and implementers can just agree on such hacks themselves =

> without having to put them explicitly in standards.


I certainly wouldn't suggest putting it in MathML or any other standard =

but implementers need somewhere to record any agreement
we could certainly have a "Note" under www.w3.org/Math as a vendor =

neutral place to record any agreement
(but I haven't seen much agreement to record so far:-)

>
>>
>> when I said standardising class names was hardly a novel idea I was
>> alluding   to
>>
>> http://microformats.org/
>>
>> and similar initiatives.
>>
>> you could make exactly the same objection against microformat
>>
>> <a  class=3D"h-card"  href=3D"http://benward.me">Ben Ward</a>
>>
>> that if a random user stylesheet has a selector for .h-card then odd
>> things might happen.
>
> As I understand, your "novel idea" is to make some class to suggest =

> some specific rendering behavior without the use of CSS, not to just =

> to indicate class names =

I don't think that's novel (and that is how class has always been =

defined in MathML)
but anyway the main point was that standardising class names is hardly a =

new idea despite the obvious possibility of clashes that you raise.
> (anyway, I think Microformats are controversial and other people are =

> suggesting using other methods to convey metadata). If instead it is =

> just adding class names and explicitly saying that the rendering =

> behavior is undefined and that they are just suggestions for possible =

> stylistic use but that implementers are free to ignore that, then I =

> won't mind but that just seems a vacuous statement that does not =

> really help ensuring cross-compatible rendering.
>
That _is_ the definition of class as far as MathML is concerned. The =

question is what to we tell    makers of mathml  generators =

(tex-to-mathml converters, editors etc)
what markup to generate.

As far as I can see you are telling them to generate

<mi>U+1D49C</mi> or <mi mathvariant=3D"script">A</mi>

and let the end user sort out a request to get calligraphic rather than =

script in the document level css.

I'm suggesting that we could tell then to generate

   <mi class=3D"calligraphic">U+1D49C</mi> or <mi class=3D"calligraphic" =

mathvariant=3D"script">A</mi>

and that they may find that popular mathml renderers do the right thing,
but if not, the end user sort out a request to get calligraphic rather =

than script in the document level css.


David