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