Quantcast

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

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frédéric WANG
Hi Bruce,

My guess would be that for mathcal & mathsrc, you should indeed keep the
plane1 conversion (or do mathvariant="script", which is now equivalent
in Gecko). So what currently LaTeXML does is the right thing to do: use
the script A for both:

<math><mi class="ltx_font_mathcaligraphic">𝒜</mi><mi
class="ltx_font_mathscript">𝒜</mi></math>

(or <math><mi class="ltx_font_mathcaligraphic"
mathvariant="script">A</mi><mi class="ltx_font_mathscript"
mathvariant="script">A</mi></mrow>)

Then apply the appropriate CSS style. For example

.ltx_font_mathcaligraphic {
         font-family: "Latin Modern Math";
         -moz-font-feature-settings: "aalt";
}
.ltx_font_mathscript {
         font-family: "Latin Modern Math";
}

seems to work for me (the difference between the two glyphs is not
obvious, disable/enable moz-font-feature-settings and zoom in to see the
effect). Of course, the problem is to handle the font & transform, which
do not seem consistent between the various fonts... So would be good to
have something standardized! And also, MathJax has his own non-standard
way to handle that LaTeXML might need to deal with too.

Le 16/07/2014 00:49, Miller, Bruce R a écrit :

> Indeed! I did some preliminary experimentation on this subject,
> so that in the current system,
>    latexmlmath --preload=amsmath.sty '$\mathcal{A} \neq \mathscr{A}$'
> gives
> <math xmlns="http://www.w3.org/1998/Math/MathML" alttext="\mathcal{A}\neq\mathscr{A}" display="inline">
>    <mrow>
>      <mi class="ltx_font_mathcaligraphic">𝒜</mi>
>      <mo>≠</mo>
>      <mi class="ltx_font_mathscript">𝒜</mi>
>    </mrow>
> </math>
>
> Of course, this _cant_ work as is, having taken so much trouble converting
> the A to the appropriate plane-1 code point! (thinking it was The Right Thing to do!)
> Using --noplane1 disables that, so that both A's end up as plain latin A,
> and then CSS has a good chance of mapping the two cases to the appropriate fonts.
> But I haven't spent any time yet trying to figure out _what_ 2 portable, appropriate fonts
> I should use.  Here's where the MathJax folks have a definite leg-up on me!
> (Or, where web fonts would be useful, as you've often suggested!)
>
> bruce

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

peter.krautzberger
Hi,

@Fred could you elaborate how MathJax's implementation is non-standard?

We're using mathvariant=script with a custom class (MJX-tex-caligraphic) to style that which is pretty much what David Carlisle wrote on the MathWG thread linked above (which, btw, I wouldn't understand as a public statement of the MathWG btw though his comments on the Unicode decision on this are obviously relevant).

If there's interest at Mozilla to work something out that can be used automatically across renderers, we'd be happy to get together. Even if the MathWG considers this unimportant at this point, I'm guessing they would take to a joint effort seriously.

Regards,
Peter.

On Wednesday, July 16, 2014 8:03:18 AM UTC+2, fred wrote:

> Hi Bruce,
>
>
>
> My guess would be that for mathcal & mathsrc, you should indeed keep the
>
> plane1 conversion (or do mathvariant="script", which is now equivalent
>
> in Gecko). So what currently LaTeXML does is the right thing to do: use
>
> the script A for both:
>
>
>
> <math><mi class="ltx_font_mathcaligraphic">𝒜</mi><mi
>
> class="ltx_font_mathscript">𝒜</mi></math>
>
>
>
> (or <math><mi class="ltx_font_mathcaligraphic"
>
> mathvariant="script">A</mi><mi class="ltx_font_mathscript"
>
> mathvariant="script">A</mi></mrow>)
>
>
>
> Then apply the appropriate CSS style. For example
>
>
>
> .ltx_font_mathcaligraphic {
>
>          font-family: "Latin Modern Math";
>
>          -moz-font-feature-settings: "aalt";
>
> }
>
> .ltx_font_mathscript {
>
>          font-family: "Latin Modern Math";
>
> }
>
>
>
> seems to work for me (the difference between the two glyphs is not
>
> obvious, disable/enable moz-font-feature-settings and zoom in to see the
>
> effect). Of course, the problem is to handle the font & transform, which
>
> do not seem consistent between the various fonts... So would be good to
>
> have something standardized! And also, MathJax has his own non-standard
>
> way to handle that LaTeXML might need to deal with too.
>
>
>
> Le 16/07/2014 00:49, Miller, Bruce R a écrit :
>
> > Indeed! I did some preliminary experimentation on this subject,
>
> > so that in the current system,
>
> >    latexmlmath --preload=amsmath.sty '$\mathcal{A} \neq \mathscr{A}$'
>
> > gives
>
> > <math xmlns="http://www.w3.org/1998/Math/MathML" alttext="\mathcal{A}\neq\mathscr{A}" display="inline">
>
> >    <mrow>
>
> >      <mi class="ltx_font_mathcaligraphic">𝒜</mi>
>
> >      <mo>≠</mo>
>
> >      <mi class="ltx_font_mathscript">𝒜</mi>
>
> >    </mrow>
>
> > </math>
>
> >
>
> > Of course, this _cant_ work as is, having taken so much trouble converting
>
> > the A to the appropriate plane-1 code point! (thinking it was The Right Thing to do!)
>
> > Using --noplane1 disables that, so that both A's end up as plain latin A,
>
> > and then CSS has a good chance of mapping the two cases to the appropriate fonts.
>
> > But I haven't spent any time yet trying to figure out _what_ 2 portable, appropriate fonts
>
> > I should use.  Here's where the MathJax folks have a definite leg-up on me!
>
> > (Or, where web fonts would be useful, as you've often suggested!)
>
> >
>
> > bruce
>
>
>
> --
>
> Frédéric Wang
>
> maths-informatique-jeux.com/blog/frederic

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frédéric WANG
Hi Peter,

MathJax uses some class="MJX-tex-caligraphic" to indicate that a
specific style (i.e. font-family, at least for the HTML-CSS output)
should be used. This is obviously a non-standard method: it's nowhere
written in the MathML spec that such class name should have a specific
interpretation and there is no reason why a MathML rendering engine
should behave the same as MathJax. Conversely, if LaTeXML or other tools
use their own class name ("ltx_font_mathcaligraphic" etc) that will be
totally ignored by MathJax. This is why for this and other non-standard
features of MathJax I asked clarification to the MathML WG.

IIRC David's reply, he didn't suggest any standardization. He just
repeated that the mathvariant behavior is defined to be equivalent to
Unicode characters that themselves have some kind of semantics
interpretation (as we already discussed, MathJax does not follow the
spec here but that's a separate issue anyway) and so this does not make
possible to add old style number or caligraphic as mathvariants. Adding
a non-normative suggestion for class names would not help much to make
it cross-compatible because people could still be free to use something
else and moreover they may conflict with one author's own class names.

On the other hand if the authors use its own CSS selectors and apply
OpenType tags & font-feature-settings then these are well-defined in the
respective specifications and could work in any Web browsers. This is at
least already implemented in Gecko & Blink under some prefixes.
The problem here is that math font designers do not use these features
very consistently, so the authors might need to handle that in a
per-font basis. Given that standardizing new mathvariants at the MathWG
is not possible, I believe people working on the OpenType font format
and on math fonts should try to agree on the OpenType tags to use
(apparently "onum" is already standard).

Le 16/07/2014 14:14, [hidden email] a écrit :

> Hi,
>
> @Fred could you elaborate how MathJax's implementation is non-standard?
>
> We're using mathvariant=script with a custom class (MJX-tex-caligraphic) to style that which is pretty much what David Carlisle wrote on the MathWG thread linked above (which, btw, I wouldn't understand as a public statement of the MathWG btw though his comments on the Unicode decision on this are obviously relevant).
>
> If there's interest at Mozilla to work something out that can be used automatically across renderers, we'd be happy to get together. Even if the MathWG considers this unimportant at this point, I'm guessing they would take to a joint effort seriously.
>
> Regards,
> Peter.
>
_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

peter.krautzberger
Hi Fred,


> MathJax uses some class="MJX-tex-caligraphic" to indicate that a
>
> specific style (i.e. font-family, at least for the HTML-CSS output)
>
> should be used. This is obviously a non-standard method:

I find it odd to call this approach "non-standard". As you already pointed out, there is no "standard" way in MathML to specify calligraphic variants.

To me, it would be "non-standard" if somebody simply used mathvariant="calligraphic" or some such thing. But, again as you wrote, using a sensible class name is, well, the sensible thing to do.


> it's nowhere
>
> written in the MathML spec that such class name should have a specific
>
> interpretation and there is no reason why a MathML rendering engine
>
> should behave the same as MathJax.

Sure.


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


> IIRC David's reply, he didn't suggest any standardization. He just
>
> repeated that the mathvariant behavior is defined to be equivalent to
>
> Unicode characters that themselves have some kind of semantics
>
> interpretation (as we already discussed, MathJax does not follow the
>
> spec here but that's a separate issue anyway) and so this does not make
>
> possible to add old style number or caligraphic as mathvariants. Adding
>
> a non-normative suggestion for class names would not help much to make
>
> it cross-compatible because people could still be free to use something
>
> else and moreover they may conflict with one author's own class names.

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


> On the other hand if the authors use its own CSS selectors and apply
>
> OpenType tags & font-feature-settings then these are well-defined in the
>
> respective specifications and could work in any Web browsers. This is at
>
> least already implemented in Gecko & Blink under some prefixes.

That's a great new feature. I'm hoping we'll see other browsers pick it up.  Though it doesn't provide the same semantic flavor that mathvariant (or some alternative attribute) would.
 
> The problem here is that math font designers do not use these features
>
> very consistently, so the authors might need to handle that in a
>
> per-font basis.

> Given that standardizing new mathvariants at the MathWG
>
> is not possible, I believe people working on the OpenType font format
>
> and on math fonts should try to agree on the OpenType tags to use
>
> (apparently "onum" is already standard).

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


Anyway, it seems to me the answer David Starbuck's original question is that there's an easy way to handle the problem on both latest versions of Gecko/Firefox as well as MathJax via rather simple CSS (+ a well-designed font).

Regards,
Peter.
_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Carlisle
In reply to this post by Frédéric WANG
On 16/07/2014 20:18, Frédéric Wang wrote:
> Given that standardizing new  mathvariants at the MathWG is not
 > possible, I believe people working on the OpenType font format and
 > on math fonts should try to agree on the OpenType tags to use
 > (apparently "onum" is already standard).

A real alternative would be to try to get an extra alphabet added to
Unicode,
that would be a long haul solution to get it in and then to get fonts to
support
whatever new codepoints are assigned but that would make it easier to do
this in a cross platform way.

Do you think we should try?


David

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frédéric WANG
In reply to this post by peter.krautzberger
Le 16/07/2014 22:32, [hidden email] a écrit :
>
> I find it odd to call this approach "non-standard". As you already pointed out, there is no "standard" way in MathML to specify calligraphic variants.
>
> To me, it would be "non-standard" if somebody simply used mathvariant="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 = 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 difference 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="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 probably 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 up.  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 though.

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édéric Wang
maths-informatique-jeux.com/blog/frederic

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frédéric WANG
In reply to this post by Frédéric WANG
Le 16/07/2014 23:38, David Carlisle a écrit :
> A real alternative would be to try to get an extra alphabet added to
> Unicode,
> that would be a long haul solution to get it in and then to get fonts to
> support
> whatever new codepoints are assigned but that would make it easier to do
> this in a cross platform way.
>
> Do you think we should try?

IIUC, this won't really help since the "semantics requirement" is not
for the mathvariant attribute itself but for adding new code points into
Unicode (??)... Again, I don't really have any opinion on mathvariants ;
but that does not seem to be a very high priority if authors can already
rely on standard CSS + OpenType methods and existing math fonts. Fixing
the font issues will probably be faster than adding Unicode code point.

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Carlisle
In reply to this post by Frédéric WANG
On 16/07/2014 22:44, Frédéric 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 = 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.

If different systems are using <mi class="wibble" mathvariant="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.

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

David



_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frédéric WANG
In reply to this post by Frédéric WANG
Le 17/07/2014 02:42, David Carlisle a écrit :

> On 16/07/2014 22:44, Frédéric 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 = 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="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="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="wibble" mathvariant="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édéric Wang
maths-informatique-jeux.com/blog/frederic

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Carlisle
On 17/07/2014 06:47, Frédéric Wang wrote:

> Le 17/07/2014 02:42, David Carlisle a écrit :
>> On 16/07/2014 22:44, Frédéric 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 = 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="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="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="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="wibble" mathvariant="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.
>


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

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frédéric WANG
In reply to this post by Frédéric WANG
Le 17/07/2014 10:31, David Carlisle a écrit :
> Sorry I don't understand that comment at all, if I write  MathML to TeX
> converter ion XSLT and choose to
> detect <mi class="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.

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

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

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

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frédéric WANG
In reply to this post by Frédéric WANG
Le 17/07/2014 20:35, Deyan Ginev a écrit :
> I can see most of the misunderstanding in this thread has arisen from
> the double-edged meaning of "non-standard". I guess Frederic meant the
> treatment was "para-standard", while Bruce and Peter are taking it to
> mean "anti-standard". Reminded me of the good old need to distinguish
> between "free as in beer" and "free as in freedom".
Yes, thanks for your suggestion on the wording. I think we all agree
that "anti-standard" is definitely a bad thing. My point is that
"para-standard" is also bad because it encourages people to use
something that is known to work only on a specific rendering engine and
forces other rendering engines to do the same if they don't want to be
incompatible with existing content (cf the story with the -webkit-* CSS
prefixes & Webkit's over-dominance on mobile). Here we have the
additional problem that MathJax is not a normal Web rendering engine and
does not encourage people to use classical Web technologies the normal
way but instead throughout its own foo-to-MathML converter, JS API,
configuration options & relying on hacks to workaround Javascript or
MathML limitations... My personal preference would be that the MathML WG
focus on something that is compatible with the rest of Web technologies
and thus could at least be implemented in all browsers. So in that
particular case, either extending mathvariant in MathML or deferring the
styling to other standardization group (since the MathML spec seems to
be agnostic with respect to CSS).

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Carlisle
In reply to this post by Frédéric WANG
On 17/07/2014 18:25, Frédéric Wang wrote:

> Le 17/07/2014 10:31, David Carlisle a écrit :
>> Sorry I don't understand that comment at all, if I write  MathML to TeX
>> converter ion XSLT and choose to
>> detect <mi class="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.
>
> 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="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="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="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="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="calligraphic" mathvariant="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

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frédéric WANG
In reply to this post by Frédéric WANG
Le 17/07/2014 21:39, David Carlisle a écrit :
 > 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="calligraphic" mathvariant="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.

As I see, the HTML and SVG specs only say that the class attribute is
used for general processing and affects CSS selectors. Adding reserved
class names to indicate special rendering behavior *without* assuming
CSS involvement is new to me, so I'm not sure at this point whether this
is good or bad thing. As I see, this is just standardizing what MathJax
does in order to avoid for the MathML WG issues with mathvariant/unicode
and RelaxNG changes... but is it really a good design from a
standardization point of view or is it just a quick solution used as a
pragmatic approach? It seems that even adding new presentation
attributes or defining mathvariant="calligraphic" to temporarily behave
differently than the other mathvariant values would be less confusing
for CSS users.

I think it would be good to have the opinion of someone from Mozilla,
here as I don't really like the idea to follow non css systems to define
the MathML spec.

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

So if someone decides to do .calligraphic { color: red; } to change the
color of some HTML elements, he will suddenly see all the MathML
formulas generated by a third-party tools in red (well that will happen
even if the names are not reserved, but at least the MathML spec remains
neutral). If he decides to use some class="calligraphic" on some MathML
elements for another purpose than the one in the MathML spec, the
elements will unexpectedly have the specific style applied to them. I
believe the trend in Gecko is currently to remove arbitrary values from
the MathML user agent stylesheet (e.g. default font-family on the <math>
element) to have a minimum set of rules and make the behavior more
predictable for Web authors. Adding reserved class names for MathML-only
is likely to lead to the opposite effect for people that are used to CSS
but don't know the details of the MathML spec. Personally, I'd prefer to
let people specify their own CSS themselves rather than trying to
magically do something that they may not actually want.

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Carlisle
On 17/07/2014 21:50, Frédéric Wang wrote:
> Personally, I'd prefer to let people specify their own CSS themselves
> rather than trying to magically do something that they may not
> actually want.

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.

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="h-card"  href="http://benward.me">Ben Ward</a>

that if a random user stylesheet has a selector for .h-card then odd things might happen.

David


_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frédéric WANG
In reply to this post by Frédéric WANG
Le 18/07/2014 00:21, David Carlisle a écrit :

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

>
> 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="h-card"  href="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 (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.

--
Frédéric Wang
maths-informatique-jeux.com/blog/frederic

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Carlisle
On 18/07/2014 06:33, Frédéric Wang wrote:

> Le 18/07/2014 00:21, David Carlisle a écrit :
>> 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="h-card"  href="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="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="calligraphic">U+1D49C</mi> or <mi class="calligraphic"
mathvariant="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

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frédéric WANG
In reply to this post by Frédéric WANG
Le 18/07/2014 19:51, Frédéric WANG a écrit :
> Mmh, really? That sounds like a bug in the Latin Modern Math font (as
> I said, I didn't really check how the glyphs are organized). I expect
> U+1D49C to contain script, U+1D4D0 to contain bold script and the
> "calligraphic" glyphs to be somewhere in the fonts (if there are
> really present in Latin Modern Math) but not at any Unicode position
> (since Unicode does not have characters for calligraphic). Did you
> open the font with fontforge to say that?
So I actually had a quick look at the fonts again and actually most of
them (GUST fonts and Neo Euler) don't have calligraphic glyphs, so we
can't access them anyway... The example I gave for Latin Modern Math
indeed only does a remapping from a script A to a slightly larger script
A, so that's why Bruce & I didn't see an obvious difference.

Asana Math & STIX Math seems to have both script and calligraphic style,
but they are arranged in a weird way. The remapping does not seem to be
done via a font feature tag, but some glyphs are in the PUA so for
example we can access them with <p style="font-family: Asana
Math;">&#x10FE87;</p>.

So I guess, the answer is that as long as the font designer don't
provide script/calligraphic glyphs with consistent mapping, it will not
be possible to use that anyway :-(

The situation for old style numbers seems slightly better, but still we
don't have consistent mapping via the "onum" feature...

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frédéric WANG
So finally the XITS Math font (https://github.com/khaledhosny/xits-math)
works for me. Compare the following markup in Chrome & Firefox with the
XITS fonts installed:

      <p style="font-family: XITS Math">&#x1D49C;</p>
     <p style="font-family: XITS Math; -moz-font-feature-settings:
'ss01'; -webkit-font-feature-settings: 'ss01';">&#x1D49C;</p>
     <p><math><mtext style="font-family: XITS
Math">&#x1D49C;</mtext></math></p>

     <p><math><mtext style="font-family: XITS Math;
-moz-font-feature-settings: 'ss01'; -webkit-font-feature-settings:
'ss01';">&#x1D49C;</mtext></math></p>
     <p><math><mtext style="font-family: XITS Math"
mathvariant="script">A</mtext></math></p>

     <p><math><mtext style="font-family: XITS Math;
-moz-font-feature-settings: 'ss01'; -webkit-font-feature-settings:
'ss01';" mathvariant="script">A</mtext></math></p>

_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

David Carlisle
On 21/07/2014 11:22, Peter Krautzberger wrote:
> And it would definitely help if the MathWG would take an official
> position on issues like this.


Speaking personally, not speaking for the group, but...

we could try to take a position but it's not clear what the position
should be.

For mathvariant there is always a tension between switching fonts (which
is often needed for legacy or typographic reasons) and switching to the
upper plane math alphabets which fits better with a direct
interpretation of the Unicode character model underlying MathML.

The MathML spec doesn't enforce any rendering technology so it only says
that mathvariant should work like the upper plane characters. It will
not take a position on whether you should implement that by mapping <mi
mathvariant=bold to the upper plane and using the same font, or to map
the upper plane alphabets back to the BMP and switch fonts.

See for example

https://github.com/wspr/unicode-math/issues/254

for a discussion about what unicode-math (support for math in unicode
tex extensions) should do with \mathbf (tex markup equivalent of
mathvariant="bold")


The calligraphic alphabet has the additional problems that by some
readings of Unicode it "should" be unified with script.

I suspect that the best we could do _now_ is to make a note suggesting a
markup such as
<mi class="calligraphic" mathvariant="script">A</mi>
that different implementations could then pick up or not as they see fit.

We could also, if people want that, try to coordinate a request to
Unicode to add a new math alphabet,
I have some sympathy with that as a good final outcome but getting code
points assigned, and in particular enough fonts using those code points
that it would make sense to use them in documents, would take some
years so having a class attribute based markup (which has much better
fallback than using new code points on existing systems) may still be
worthwhile.

David







_______________________________________________
dev-tech-mathml mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-mathml
12
Loading...