Re: Math prime issues for some fonts

[Hans Hagen via ntg-context <ntg-context@ntg.nl>]

On 11/26/2021 10:05 PM, Mikael Sundqvist via ntg-context wrote:
> Hi Jack,
> 
> I've been working with Hans on math in general and primes in
> particular in the last week. I do not understand all the details, but
> I think primes are handled differently now, and that one essentially
> need to have some tuning in goodie files (the reason is that they are
> done differently in different fonts, and that there was not simple
> one-fits-all solution). We have not touched eulernova yet.
It's not easy to explain in a few sentences so here we go.

In unicode, math is a script. There are plenty scripts supported and 
unicode supports their properties. Unicode tries to avoid duplicates 
but we have an latin A and a greek A, and we have plenty of nukta in 
indic scripts even if the shapes are the same. In math however, for some 
reason, we have ended up with some math code points being shared. So, we 
don't have a small italic h (because every italic h is supposed to be 
plank constant) and we don't have primes because minutes are primes. 
Maybe today some strong arguing could avoid those anomalities but i fear 
that we're stuck with it forever now (math legacy stuff etc).

This results of for instance holes in math alphabets (less such holes in 
other scripts) that every application has to deal with and we end up 
with symbols that depending on their usage need some interpretation and 
handling. Btw, a side effect is that where an one can distinguish 
between f as variable or function by using an indicator this is not 
possible with h so in copy/paste or interpretation one has to guess what 
it is. The same is true for prime like symbols: are they minutes or primes.

So, as the unicode slot for a prime is used for minutes (in text) the 
symbols in a font ends up as superscript but in math text mode it would 
not be in the right spot. Keep in mind that we have specific math fonts 
so ther ei sno real reason for not making primes consistent in text, 
script and scriptscript (ssty features): it simply is not done which in 
turn is probably a side effect of cmr being uses as template even if for 
other properties cmr fundamentally differs from open type math fonts.

Anyway, in the traditional tex approach to primes, the prime symbol is 
taken from the script variant, where is has a different size (or not), 
different boundingbox (or not) and/or is already raised (or not). Also, 
in tex the ' is made into an "active in math mode" character (one of 
few, an dit might even be that the reason for active math characters is 
in primes) in order to ease input. It effectively being a macro means 
that it can do some lookahead in order to (1) position itself as well as 
(2) make it possible to be followed by a superscript and/or subscript.

And, because the way math is coded and dealt with in tex basically has 
been chisseled in stone early after tex showed up, that situation is 
supposed to be dealt with: a multi-purpose shape with somewhat weird 
properties, parsing preferably in a robust way, positioning in a 
superscript like position (before or after a script), i fpossible 
intercepting interference etc. And ... all that is resembled in unicode 
math as well as all these math fonts out there.

But it is not the way i want to deal with it in context, also because 
there is even more involved (which i happily let you guess about). I 
want clean solution with no fancy (and somewhat obscure) tex macro doing 
magic that only a few are supposed to understand.

When we started with luatex, and thereby mkiv, we immediately went full 
unicode math (also with old fonts) and primes (plus a few other things) 
were a pain in the butt from the start due to fonts. For more than a 
decade I tried to catch this automagically by runtime patching and that 
works ok for most fonts but as recently more opentype math fonts showed 
up, some actually more opentypish than what we had, the decision was 
made to delegate this to the goodies mechanism than Mikael refers to. It 
means that we can control individual fonts (and users can patch that 
themselves if needed) because in the end, as always with fonts, scripts, 
languages and probably most of tex, heuristics tend to fail and clash.

It means that, as Wolfgang explained, you need to specify a goodie file 
with \definefontfamily (could be your own copy with personal 
preferences). Just for the record, some more is done on goodies and some 
more runtime patching might move that goodie control. It actually does 
mean that when a font (if ever) gets updated we need to check things 
which is why a mismatch in version will be reported on your console. 
Among the things we still need to discuss are if we wil freeze fonts in 
the distribution (only explicit updates) and if we drop official support 
for obsolete or (just) bad (looking) math fonts.

So to summarize: with primes we have to deal with (1) frozen tex math 
expectations that won't change (although in context we're free to do 
so), which (2) have found their way in unicode, and (3) also in fonts 
due to the way traditional tex does it, and (4) with which we cannot 
deal with in the engine, so (5) we do it our own contexty way, in the 
hope that (6) in the end it all looks good and (7) also gives us some of 
the benefits that i don't even dare to bring up here in order not to 
make it sound more complex.

As a note: if you notice suboptional things in math fonts, don't 
hesitate to make a good minimal example and then ask Mikael to look into 
is because he deals with and coordinates the tuning of goodie files.

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________