-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
harfbuzz: mapping from language.Language to OpenType tags seems to be case sensitive #150
Comments
This is probably user-error and the intended usage of language.Language is to use language.NewLanguage to canonicalize the string before assigning it to |
Precisely. |
How do you feel about something like this instead?
The upside is that users are forced to go through NewLanguage to create languages. The downside is that manipulating languages, e.g. via slicing, is less trivial for everyone, and more costly for users as they'd have to go through NewLanguage again. Although arguably most users shouldn't have to manipulate languages in arbitrary ways, anyway. |
Looks great. It would not be backward compatible though, so I'm not sure how much this change is worth doing. @andydotxyz @whereswaldon what do you think ? |
As an aside (which I'm happy to split into its own issue if need be), the handling of language.Script is also case-sensitive, but language.ParseScript doesn't do any normalization. So shaping with the script |
Yes, I encountered this issue as well. I think I kept the lowercase convention because it simplifies thé interaction with fonts at some point. Not sure though, I'll take a deeper look. language.ParseScript should definitively do the appropriate normalisation. |
I'm okay with forcing language to be constructed in the interest of eliminating mistakes. I guess it's up to @andydotxyz |
Agreed. Sorry for having been out of contact last week. |
Looking at
tagsFromComplexLanguage
inot_language_table.go
, the input to the function seems to have the same case that the user set forSegmentProperties.Language
, so for examplezh-Hant-HK
. However, the implementation of the function is case sensitive and doesn't normalize the case. As such, checks likeif langMatches(langStr[1:], "h-hant-hk") {
don't actually match.The text was updated successfully, but these errors were encountered: