Add jlm_msam10.ttf and somme symbol it contains

[Orace]

This commit add a new font jlm_msam10.ttf copied from jlatexmath .

• Closes Angle, MeasuredAngle and Square symbols are not rendered  #127,
• closes an unsupported command (\geqslant) #313.

It adds support for:

\rightleftharpoons
\angle
\sqsubset
\sqsupset
\Box
\Diamond
\leadsto
\lhd
\unlhd
\rhd
\unrhd
\boxdot
\boxplus
\boxtimes
\square
\blacksquare
\centerdot
\lozenge
\blacklozenge
\circlearrowright
\circlearrowleft
\leftrightharpoons
\boxminus
\Vdash
\Vvdash
\vDash
\twoheadrightarrow
\twoheadleftarrow
\leftleftarrows
\rightrightarrows
\upuparrows
\downdownarrows
\upharpoonright
\downharpoonright
\upharpoonleft
\downharpoonleft
\rightarrowtail
\leftarrowtail
\leftrightarrows
\rightleftarrows
\Lsh
\Rsh
\rightsquigarrow
\leftrightsquigarrow
\looparrowleft
\looparrowright
\circeq
\succsim
\gtrsim
\gtrapprox
\multimap
\therefore
\because
\doteqdot
\triangleq
\precsim
\lesssim
\lessapprox
\eqslantless
\eqslantgtr
\curlyeqprec
\curlyeqsucc
\preccurlyeq
\leqq
\leqslant
\lessgtr
\backprime
\risingdotseq
\fallingdotseq
\succcurlyeq
\geqq
\geqslant
\gtrless
\vartriangleright
\vartriangleleft
\trianglerighteq
\trianglelefteq
\bigstar
\between
\blacktriangledown
\blacktriangleright
\blacktriangleleft
\vartriangle
\blacktriangle
\triangledown
\eqcirc
\lesseqgtr
\gtreqless
\lesseqqgtr
\gtreqqless
\yen
\Rrightarrow
\Lleftarrow
\checkmark
\veebar
\barwedge
\doublebarwedge
\measuredangle
\sphericalangle
\varpropto
\smallsmile
\smallfrown
\Subset
\Supset
\Cup
\Cap
\curlywedge
\curlyvee
\leftthreetimes
\rightthreetimes
\subseteqq
\supseteqq
\bumpeq
\Bumpeq
\lll
\ggg
\ulcorner
\urcorner
\textregistered
\circledS
\pitchfork
\dotplus
\backsim
\backsimeq
\llcorner
\lrcorner
\maltese
\complement
\intercal
\circledcirc
\circledast
\circleddash

TODO

• @ForNeVeR: add documentation on TTFMetrics usage
• @ForNeVeR: add the font licensing details, make sure we follow the license

[Orace]

This should Fix #127, Fix #282 and Fix #313.
License should be checked!

[ForNeVeR]

According to the license information, it seems to use OFL which should be pretty okay.

[ForNeVeR]

@Orace, how did you generate DefaultTexFont.xml? Have you just copied the data from JLaTeXMath?

I fear that would be covered by GPL :(

[ForNeVeR]

The font files seems pretty okay (we'll need to just copy and redistribute the OFL text with us, I think), though the GPLd data inclusion doesn't look good. If you did take the data from JLaTeXMath, then I fear I'll have to put veto on merging of this until we figure out how to regenerate it without GPL involvement :(

(Which have to be possible, yet have never been demostrated.)

[Orace]

The font files seems pretty okay (we'll need to just copy and redistribute the OFL text with us, I think), though the GPLd data inclusion doesn't look good. If you did take the data from JLaTeXMath, then I fear I'll have to put veto on merging of this until we figure out how to regenerate it without GPL involvement :(

(Which have to be possible, yet have never been demostrated.)

I did copy the data from the JLaTeXMath repository, I will search for a solution, ideally it should be extracted from the font itself on the fly.

[ForNeVeR]

Some known information is documented in https://github.com/ForNeVeR/xaml-math/blob/master/docs/prepare-font.md

But, sadly, I don't know everything, yet :(

[ForNeVeR]

I'd like to emphasize that I value your efforts very much!

But we've already had some problems with GPL data and sources relicensing in the past, and we want to make the library available under the MIT license. So, for the best of our users, and to follow all the GPL requirements (which, I should add, we of course respect), we have to avoid distributing GPL code and data with the library.

Earlier, I had a feeling that we almost have everything to regenerate the data, and there are only a few steps left before we'll be able to automate that and get rid even of the data we've copied from a GPL project (and then legally relicensed, with the permission of the maintainers).

[Orace]

I played a little bit with the GlyphTypeface type and get this result:

While data from JLaTeXMath give:

Big difference:

• columns 5 and 6 and rows 2 and 3 from the bottom.
• columns 4 and 5 and row 4 (three points symbols) are completely out of the box with JLaTeXMath data.

[Orace]

Output of \\ \ulcorner A \urcorner \\ \llcorner A \lrcorner:

The same in Texmaker:

[ForNeVeR]

Wow, that's a solid research. I'll take some time to think about it.

[ForNeVeR]

A couple of things I've found during the experiments.

1. If you process any other font file using the new tool, for example, cmsy10.ttf — then a lot of metrics don't line up correctly (I mean, the generated metrics are different from what we have in our DefaultTeXFont.xml).

2. I have tried copying the font data from jlatexmap and generate same markup you mentioned, \\ \ulcorner A \urcorner \\ \llcorner A \lrcorner, and it doesn't work in XAML-Math either.

   So, the reason it doesn't work is not incorrect metrics but something else (probably the <Parameters> section at the top of our DefaultTexFont.xml?
   

[ForNeVeR]

Output of \\ \ulcorner A \urcorner \\ \llcorner A \lrcorner:

The same in Texmaker:

@Orace, after a little debugging, I was able to crack down this particular problem.

Distance from one symbol to another relies on the symbol kind: for example, an equals sign has a "relative operator" kind and thus will be enclosed with some space.

You've set certain symbols such as ulcorner and urcorner as rel — same kind as the equals sign, and that's why they are spaced as such. In jlatexmath, they have kind open and close (which is, I believe, the correct one). After I've updated that, I was able to see this image:

  <Symbol name="ulcorner" type="open"/>
  <Symbol name="urcorner" type="close"/>

  <Symbol name="llcorner" type="open"/>
  <Symbol name="lrcorner" type="close"/>

[ForNeVeR]

Anyway, I guess we can start from the definitions you were able to generate using this tool. It still lacks some details (such as italic), but I think that WPF font model lacks them as well, and we can't really improve it right now.

[ForNeVeR]

Alright, anyway: I suggest you to take another look at the current symbol list and what should have which kind (or maybe dig down into the TeX sources to find out the real symbol kind mappings, though that's optional).

I am still not entirely happy with our character data generator, but that's an impressive start.

After that, I'll manage the dull details of licensing and documentation, and that's good to be merged.

[Orace]

@ForNeVeR, I used the \meaning command to get the macros definitions, which are mostly of the form \mathchar”XYZZ, from there the Z number (0 if not present) give the symbol type.

The special cases (for which the type seems obvious, but I have checked jlatexmath) are:

• \ulcorner: open
• \urcorner: close
• \llcorner: open
• \lrcorner: close
• \textregistered (aka ®): ord

[ForNeVeR]

Thank you so much for your help on these issues!