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

Frédéric Wang <[email protected]> Wed, 16 Jul 2014 23:44:30 +0200
Newsgroups gmane.comp.mozilla.devel.mathml
Message-ID <[email protected]>
Le 16/07/2014 22:32, [email protected] a =E9crit :
>
> I find it odd to call this approach "non-standard". As you already pointe=
d out, there is no "standard" way in MathML to specify calligraphic variant=
s.
>
> To me, it would be "non-standard" if somebody simply used mathvariant=3D"=
calligraphic" or some such thing. But, again as you wrote, using a sensible=
 class name is, well, the sensible thing to do.

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.

>
>
>> Conversely, if LaTeXML or other tools
>>
>> use their own class name ("ltx_font_mathcaligraphic" etc) that will be
>>
>> totally ignored by MathJax.
>
> Well, by default, sure. But if David Starbuck is taking the time to write=
 some CSS to make it work on Firefox I expect there'll be time to pass that=
 information to the MathJax configuration. So I don't quite see the differe=
nce here.

CSS and OpenType tags are standards, so if authors & authoring tools =

like LaTeXML, TeX4ht etc take some time to generate the appropriate =

style, that's not only for Gecko or a specific font but for any =

rendering engines & math fonts that follow these standard. If it =

attaches some class=3D"MJX-..." and we additionally ask them to only use =

MathJax's own internal set of fonts, it's only targeted to MathJax's use.

> I don't consider MathML (or Unicode) to be set in stone. It would probabl=
y not be easy but I think there's a strong case for it, especially if both =
authoring and rendering people worked together.

I didn't say that. But the point is whether calligraphic / old style =

numbers convey semantics. If not, they should be done by CSS styling, =

not mathvariant. It seems that David Carlisle said that the conclusion =

of the discussion with the Unicode group & others was that these are =

styling not semantics. As I said elsewhere, I'm not really clear about =

the styling VS semantics since many existing mathvariants seem to mixed =

both (e.g. is bold a style or does it have a mathematical meaning?).

> That's a great new feature. I'm hoping we'll see other browsers pick it u=
p.  Though it doesn't provide the same semantic flavor that mathvariant (or=
 some alternative attribute) would.

That's the point: using CSS style instead of mathvariant since =

calligraphic & old style numbers don't convey semantics (according to =

David Carlisle's reply).

> Yes, it would help rendering engines to have fonts that are consistent. I=
 suppose I have a different opinion about mathvariants being set in stone t=
hough.

Again, I don't think I said anything like that and I don't have any =

definitive opinion on mathvariant, so please discuss that with the Math =

WG (and continue the discussion I have opened for some time ago now!). =

My main concern is to have a clear specification so that we can =

implement that properly and consistently. However David's answer looked =

reasonable to me and relying on existing CSS technologies seem the =

easiest way for the MathML WG and browser vendors i.e. they won't have =

anything more to do. In my opinion, having new mathvariant attributes =

doing CSS styling instead of Unicode remapping would be a bit messy from =

a standardization & implementation perspective.

-- =

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