On 3/4/2020 9:02 PM, Matthias Nagel wrote:

Dear Hans,

I am not quite sure how I shall interpret your response. Unfortunately, I am not an expert for traditional TeX, LuaTex, XeTeX nor the OpenType specs. I am only a user who observed a problem with kerning and is now caught between two stools: the LuaTeX maintainers and the font maintainers. My remarks are below your quotes:

i think that there are hardly any 'correct' math fonts out there (although i consider cambria to be quite ok and it's the standard)

On 3/4/2020 10.43AM, Hans Hagen wrote:

...

On 3/3/2020 9:43 PM, Matthias Nagel wrote:

...

as I am unsure what is the officially correct way to submit a potential bug, I post it here and would like to draw your attention to this post, because I do not know if the tracker is still in use.

http://tracker.luatex.org/view.php?id=1019

My apologies, if this is a double posting. Also, I already have posted this problem to the Libertinus project as I initially thought this would be a bug in the font, but the maintainer of Libertinus said it is an issue with LuaTex. w_j q^j

the w sticks out of its boundingbox, as does the j ... in traditional tex font processing the italic correction is always added to the width and removed in some cases, in opentype it's only added in some cases and the real width is used (combined with staircase kerning for relative positioning)

If I understand you correctly, you say that the specification how fonts are handled has changed for OpenType fonts in comparison to Type-1 fonts used by pdfTeX. And you say that LuaTex' way to handle things is in accordance with the OpenType specification. Is it correct to say then, that the bug is not in LuaTeX but in the font, although the font designer claim the opposite? In other words, should I again get in touch with the font maintainer and convince them to fix their font?

There are two code paths in luatex: (1) old school tex fonts, which does the italic correction juggling: add them always and then remove them sometimes depending on where chars are used, and (2) an open type route where italic corrections are only added in the few places that requires it. I decided (already long ago) for that split because any solution (also at the tex end) that tried to cope with the fact that fonts are inconsistent somehow has side effects. Anyway, in luatex one can actually (runtime) patch a font, so I decided just to wait ... So, in context, once I think that a font is stable (which means that its properties, including maybe or maybe not bugs, will not change) i'll add some such corrective operations in at the tex/lua end. Because math is pretty conservative and hardly changes that can work out on the long run. (Of course, instead, one can decide to turn bugs into features, change the engine, because after all that happens all the time.)

However, XeTeX also uses OpenType and the odd kerning does not appear in XeTeX. Does this imply that Libertinus and XeTeX both handle spacing though not in accordance with the specs, but handle spacing at least consistently with each other? Of course, that would be a very unlucky situation. In that case fixing the font in accordance with the OpenType specs and LuaTeX would break the font for XeTeX.

I never looked into how xetex does it but I think that when its math was implemented there were hardly any opentype math fonts around. So, It might have settled on some mixed "old school tex rendering" and "at that time assumes opentype rendering" which then mostly meant "cambria with its math parameter system".

Out of curiosity: Given the assumption that XeTeX and LuaLaTeX handle kerning and spacing of OpenType fonts differently without any indication which of both is compliant to the OpenType specs, why then is it possible to have other OpenType fonts (e.g. Computer Modern Unicode, Tex Gyre) which are typeset correctly for both engines? This does not sound logical for me. If XeTeX and LuaLaTeX behave differently with respect to OpenType kerning/italic correction information, then one should observe this problem in many more cases.

They are different engines. In the danger of repeating myself (as this topic comes up every now and then), this is what the spec says: \startitemize \startitem {\em italic correction:} When a run of slanted characters is followed by a straight character (such as an operator or a delimiter), the italics correction of the last glyph is added to its advance width. When positioning limits on an N-ary operator (e.g., integral sign), the horizontal position of the upper limit is moved to the right by half the italics correction, while the position of the lower limit is moved to the left by the same distance. When positioning superscripts and subscripts, their default horizontal positions are also different by the amount of the italics correction of the preceding glyph. \stopitem \startitem {\em math kerning:} Set the default horizontal position for the superscript as shifted relative to the position of the subscript by the italics correction of the base glyph. \stopitem \stopitemize

...

now, the distance between w and j: adding the ic to w would increase the distance, and even if it were removed later on it would then be too far apart ... so ... no robust solution for that kind of cases (and we would start oscillating solutions depending on the bug-of-the-day: fix this, breaks that, add another flag here and there ... well, that's something for macro packages to do) ...

Well, in my naive view, everything should be fine if all components adhere to the specs. :-o

Is it possible to fix the problem on a macro level? If yes, that would be great and I would be deeply thankful, if you could you give me an example macro how to do it. I probably cannot wait with my manuscript until either the font, LuaTeX or XeTeX accepts the problem as „their” bug and fix it.

...

of course one can apply some "fix feature" (which i probably would do in context if i'd use that font) that could either implement a staircase kern, or fix the width

Could you enlighten me what a staircase kern is? Is it possible for me to introduce that by myself (whatever it is) or is this something the font maintainer has to do? a profile with discrete steps that defines left or right side kerning,

Sure, my experience is that (nearly) all can be fixed somehow in tex but when you're in a hurry: just use another font (maybe even traditional 8 bit tex fonts). they can be visualized as staircases; so a character can kind of encode its shape and depending on where a next or previous character ends up (its height as well as baseline then matter) kerning can be fine tuned hardly any font implements it ... and even if it does, often only partial but it's a nice mechanism (fwiw: in my opinion the tex community lost the edge in math long ago and microsoft took it up and came up with an opentype spec + (unicode) font; they looked at tex of course and made some decisions, which we might like or not, but we had it coming and now we're stuck with the situation; but the good thing is that tex could and will always adapt) 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 -----------------------------------------------------------------

On 3/7/2020 2:08 AM, Reinhard Kotucha wrote:

So far only ordinary text fonts were considered. Even if XeTeX and LuaTeX interpret the specs differently, the advantage of LuaTeX is that things can be fixed if necessary. indeed, so my take on this is: wait till the font is stable and then add some fixes in macros or lua because messing at the engine level (1) will never be enough, (2) will lead to oscillating solutions and endless debates, and (3) nothing is as frustrating as fighting hard coded heuristics and debatable solutions ... lucky for us these spacing issues can rather well be dealt with (although of course macreo packages choose different routes but that comes with tex)

(the main problem of course is that nowadays it takes a while before fonts get frozen, if at all) 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 -----------------------------------------------------------------