Libertinus: ₘ (U+2098) and ₙ (U+2099) subscripts (m and n) overlap integer subscripts

[yuvalgnessin-qz]

Describe the bug
When preceded by an integer subscript, subscripts m and n overlap the integer.

Subscripts m and n are represented respectively by ₘ (U+2098) and ₙ (U+2099)

This appears to only happen when preceded by an integer subscript, not another letter subscript. Furthermore, this only appears to affect m and n, but not other letter subscripts in the U+209x range.

Steps to reproduce

1. C₃ₘ
2. C₃ₙ

Expected vs. actual behavior
Expected: subscripts to render side-by-side
Actual: the m or n subscript overlaps the integer

Screenshots / logs

Bug:

But other U+209x work correctly:

Preceding with a letter subscript instead of integer subscript also works correctly:

Additional context
This was observed with Sans Regular .otf file on both Android and iOS. Not sure if the platform matters, but since we've seen the issue on both I assume it's not too platform-specific.

[alerque]

Thanks for the clear report @yuvalgnessin-qz. This is probably not a hard fix if anybody wants to poke around in FontForge and jump in with a PR (and yes I'm in a position to review and accept PRs now). I'll retag/assign when I get around to working on this if nobody else is at that point so we don't duplicate work.

[yuvalgnessin-qz]

Thank you @alerque! Unfortunately I have absolutely zero context and experience with developing fonts, so I don't think I'm qualified to fix this myself. But please let me know if there's any other way in which I can help!

[yuvalgnessin-qz]

Hi again @alerque, I'm sure you're very busy, but do you know if you'll be able to get to this fix soon? Is there anything I can do to help?

Thank you so much!

[clsn]

It would appear that the issue is that uni2098 and uni2099 are placed in the kerning class (right-hand side) along with all the superscript characters and the degree sign and stuff like that, which understandably have a huge negative kern with respect to preceding subscripts. Should they just be removed from that class?

[alerque]

Thanks @clsn, that does sound about right. I went looking for this once already and didn't find it (my FontForge foo is still pretty weak sauce). Are you interested in contributing a PR for this?

[clsn]

I'll give it a try. Just a matter of mucking about with the kerning classes. And making sure I understand how the repo is organized, what goes in sfd and what in fea and all that.

[clsn]

OK, it's... weird. I tried using fontforge's python bindings, pulling in the kern table, taking those two characters out of that class, and putting the table back, but when I look at the diffs of the SFD files, it looks like a bunch of other kern classes have also changed, inexplicably. It's as if FF has its own ideas of what should be in the class. And for all I know it might be right!
I think I'll twiddle the SFD files so that ONLY the changes I meant to change are changed!

NO. I think it knows what it's doing.

[alerque]

@clsn I haven't actually used FontForge's Python bindings myself, I'd be interested in seeing the code snippet you used to make this attempt.

[alerque]

@yuvalgnessin-qz Since the PR fixing this has been merged to the master branch it will be in the next release, whenever that is. In the mean time feel free to use the fonts from development builds, you can find them attached as artifacts to each build here (newest first). The fonts in there have development version numbers, but should be a fully working set with whatever changes have been committed to master up to the point they were built.

Do let us know in a new issue if any problems come up in your usage.

[yuvalgnessin-qz]

Thank you so much! I think I should have time tomorrow or early next week to give it a shot and validate the fix.

[yuvalgnessin-qz]

Hi @alerque, I was able to validate this fix in my app. It works perfectly! Thank you so much!