Closed guidoferreyra closed 1 year ago
I agree we should put them in features and make sure the correct codepoints are used when possible, but I do hesitate to break backwards compatibility unless you think it’s required. @guidoferreyra can you confirm?
To have a record of the glyphs currently using PUA:
Only two of these have proper encodings. The frac
feature handles other arbitrary fractions. Should we leave these using PUA?
u+2150
⅐u+2151
⅑U+FB01
fiU+FB02
flImplemented via OpenType feature pnum
, no encoding necessary. (Will also rename glyph name suffix to '.lf' for clarity.)
Use unicode subscripts and superscripts instead or in addition.
Omitting from font.
The font has other "breaking" changes to already consider it as new major release, so my opinion is the following:
Fractions: I don’t see what is the point of having those precomposed glyphs for very rare fractions. But if we need to keep them I think it’s better to remove the PUA to not alter user’s character string when activating the feature.
Ligatures: I agree
Proportional figures: I agree. +1 for the renaming too
Superiors and Inferiors. To me just using the superior and inferior unicode values will be enough, no need to add PUA
Ok sounds like a good plan, I will implement this shortly.
Changed in e16eed91024b8f645f306c2ac6e17ee5307ea784
It’s a bit unusual because the encoded zerosuperior
was set to the numr
feature and the unencoded zero.sups
is set to the sups
feature. But I don‘t see a problem with that.
Many glyphs are using PUA codepoints, we should remove it and double check are accesible through features.