FRAC feature: parsing and mis-identifying which chars are part of the fraction, when non-digits present

[AndydeCleyre]

I don't know if this logic is part of the font, or rather outside the scope of Iosevka, but using the FRAC feature can mis-identify which characters should be part of a fraction, when there are non-digit characters involved.

Examples:

100.0/200.0
10mb/20mb
5x/10x

---

• Your font version: 28.0.2-dev-28b84bf
• Your font variant: Term
• Your operating system (name and version): Ubuntu 22.04 LTS
• Your application using Iosevka: Wezterm

[be5invis]

[AndydeCleyre]

Wow, thanks!

[aricaldeira]

Could those work also with U+2044, and separators comma and U+202F (narrow no-break space)?

Maybe also separators U+2007 (figure space), U+2008 (punctuation space), U+2009 (thin space), U+200A (hair space)?

Meaning, even without frac activated, the use of U+2044 with digits and those sepators, trigger the frac behavior?

Regular space and non-breaking space (or any other character) should break the fraction, IMO.

Also, thanks, great work!

I never saw another font that treats the dot as part of the fractions, but I think all should (and at least the comma too)

[jmcwilliams403]

Regular space and non-breaking space (or any other character) should break the fraction, IMO.

I disagree. If anything, non-breaking space and narrow non-breaking space would be the only ones that could potentially carry additional characters up to the numerator or down to the denominator, and either way it's still a non-standard behavior.

[aricaldeira]

Doable with those two spaces (since they’re all the same width anyways), plus the comma.

The dot is not the only decimal separator used, most languages (but not most population) use the comma instead:

https://en.wikipedia.org/wiki/Decimal_separator

Plus, about the non-standard behaviour, it may be so, but it shouldn’t, IMO, since it’s an ISO standard:

https://en.wikipedia.org/wiki/Decimal_separator#Current_standards

Since I type a lot of code and technical documents, I added both U+00A0 (at AltGr+space) and U+202F (AltGr+shift+space) to my keyboard layout

Also, just remembered, it would be a great thing for the dozenalist community if the fraction behavior worked also on U+218A ↊ and U+218B ↋ (dozenal/duodecimal digits ten and eleven)

A final note about the spaces, just if someone from other fonts sees this, is that, if you take the information about how languages use a space as a group separator, instead of the dot or comma, appart from the two non-breaking spaces (full-width and narrow), according to the unicode standard (https://www.unicode.org/charts/PDF/U2000.pdf), U+2008 is a space that is intended to be the width of a full stop (the narrow punctuation mentioned there), so, it could be used to separate digits, and give a nice balance combined with separating the fractional part with the dot or comma;

To @jmcwilliams403
Kaj, ĉar vi estas same esperantisto, kiel mi, kaj ankaŭ klavarŝanĝisto :), mia persona klavararanĝo permesas tajpi la du nedisigeblajn spacetojn, krom la 'numera' spaceto (per morta klavo + spaceto): https://github.com/aricaldeira/nativo

[jmcwilliams403]

Kaj, ĉar vi estas same esperantisto, kiel mi, kaj ankaŭ klavarŝanĝisto :), mia persona klavararanĝo permesas tajpi la du nedisigeblajn spacetojn, krom la 'numera' spaceto (per morta klavo + spaceto): https://github.com/aricaldeira/nativo

Ĉi tio estas iom ekstertema, sed mi dankas vian ĝentilecon.

[aricaldeira]

⭐‍💚🙏🏻

[aricaldeira]

Ok, after some tinkering, some things worked, some others, don’t:

By looking at the original commit, I managed to add comma, nbsp and nnbsp to the list of characters that are treated as part of the fraction (the others are for my personal use, and plus and minus are different codepoints for superscript/numerator):

list null 'comma'
list null 'nbsp'
list null 'nnbsp'
list null 'turnDigitTwo'
list null 'turnDigitThree'
list 0x208A 'plus'
list 0x208B 'minus'
list null 'plusminus'

I understood that the null there means the character doesn’t have a unicode code point, but it will exist within the font itself;

What I don’t understand is that, why using U+2044 alone doesn’t trigger the same behavior as frac?

I allways thought they were practically the same feature, activated in two different ways.

It’d be awesome if someone could point me out where to look, so that using U+2044 next to the same characters get the same result as using frac at the font level.

Thanks!