GF_Latin_African glyphset FAILS #12
Comments
|
So I think what it is looking for is for you to have "Eng.loclNSM" as a
glyph.
[image: image.png]
The default form ( which is a change) is on the left and the highlighted in
blue one is the one we had been making. The Default is dominant in
Afria and has the larger population of users overall. The one of the right
is used by the Sami people in the north of Europe and is also the minority
version in Africa where it is also used.
I have seen in localization code that this 'Eng.loclNSM' is sometimes also
specified in the localization code beyond this:
*script* latn;
*language* NSM;
*lookup* locl_latn_6 {
*sub* Eng *by* Eng.loclNSM;
} locl_latn_6;
but I need to dig that up because I don't have it in Merriweather yet.
Is that helpful? or are you doing this already and getting the error you
mention?
…On Tue, May 14, 2024 at 9:54 AM Kostas Bartsokas ***@***.***> wrote:
There are series of FAILS related to the GF_Latin_African glyphset (mostly
the locl Eng alternate) but I could not find the respective Language tags
on the Microsoft spec for all the languages mentioned on the report.
The report is too long to be posted in a comment.
@EbenSorkin <https://github.com/EbenSorkin> what should I do?
—
Reply to this email directly, view it on GitHub
<#12>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQUQXKMRPMGKSPGIOTIYD3ZCIJSFAVCNFSM6AAAAABHWHRF3KVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI4TKNJSGMZDGNI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@EbenSorkin sorry I should have been more descriptive. Yes, I have the alternate Eng (.loclNSM) and I have added locl support for a series of languages that the report indicates. 
However there are many languages mentioned in the report that don't correspond to any language tag in the spec. For example there is no 3 letter language system tag for Sokoro or its ISO ID, sok:
The list of such languages is quite lengthy on the report. Whoever did the research for FontBakery should have added the suggested solution somewhere too. |
|
I think you can ignore that one for now then.
I am ccing Dave, Yan and Denis. I'll need the answer to this too.
…On Tue, May 14, 2024 at 1:09 PM Kostas Bartsokas ***@***.***> wrote:
@EbenSorkin <https://github.com/EbenSorkin> sorry I should have been more
descriptive.
Yes, I have the alternate Eng (.loclNSM) and I have added locl support for
a series of languages that the report indicates.
However there are many languages mentioned in the report that don't
correspond to any language tag in the spec.
<https://learn.microsoft.com/en-us/typography/opentype/spec/languagetags>
For example there is no 3 letter language tag for Sokoro (or sok) :
- 🔥 *FAIL*
GF_Latin_African glyphset:
Language FAIL messages
sok_Latn (Sokoro) The locl feature did not affect Eng
The list of such languages is quite lengthy on the report.
Whoever did the research for FontBakery should have added the suggested
solution somewhere too.
—
Reply to this email directly, view it on GitHub
<#12 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQUQXK5PBTO6X4SSPCN3OTZCJAKXAVCNFSM6AAAAABHWHRF3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJQG4ZDMNRTGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Actually this is my brain just playing games for me since there is no actual issue... The rest I put there after the fontbakery report but since they are all referring to African languages the default Eng should be fine, and of course the locl feature does not affect the Eng. I guess the problem is that fontbakery probably expects the default Eng to be the Sami one. But the character sets are made so that in SSA Eng is expected to be the African one and Eng.loclNSM to be the Sami preferred one. In any case I think I can safely disregard these fails in my case. |
|
I don't agree about fontbakery expecting the Sami one - but otherwise; for
now; yes.
…On Tue, May 14, 2024 at 2:29 PM Kostas Bartsokas ***@***.***> wrote:
Actually this is my brain just playing games for me since there is no
actual issue...
The loclNSM is used in the first lines to make the change for the Sami
languages (KSM; NSM; ISM; SKS; LSM; SSM;)
The rest I put there after the fontbakery report but since they are all
referring to African languages the default Eng should be fine, and of
course the locl feature does not affect the Eng.
I guess the problem is that fontbakery probably expects the default Eng to
be the Sami one. But the character sets are made so that in SSA Eng is
expected to be the African one and Eng.loclNSM to be the Sami preferred one.
In any case I think I can safely disregard these fails in my case.
—
Reply to this email directly, view it on GitHub
<#12 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQUQXL4YFDYFZDC5GEGPODZCJJW7AVCNFSM6AAAAABHWHRF3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJQHA2TQMZQG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I second that. That report should be a WARN and not a FAIL. |
|
The FAIL is produced by Shaperglot and only passed through to Fontbakery. So we'd have to investigate a solution there. One problem we're definitely having is that we currently have no way of defining what a font is supposed to contain as default shapes, and what as alternative/locl shapes, which is also why the discussion about defining unencoded variants into the glyphsets is stalling. Is a font primarily an African or a European Latin? Is a font primarily Russian or Bulgarian? If both ways are/should be possible within Google Fonts, checks in Fontbakery and Shaperglot need to be flexible enough to react to that. Currently they aren't, so it's possible that they're checking the inverse of what they're supposed to check, which is bound to cause lots of confusion. I'm lacking knowledge about the languages. My current understanding is that the historically dominating conduct overall is that the default shape of the Is this correct? In that case it looks like either Oi or Shaperglot is set up the wrong way around and any @simoncozens: Which way does the Shaperglot check expect? I'm sure we can take it as a given that languages without a OT code shouldn't produce a FAIL, but let's talk about the above chicken/egg problem first. |
|
@yanone yes the images are correct. And Oi is setup with the African Eng as default and the Sami as alternate. It's not a big deal to change it. |
|
Don't do anything for now. Let's have a conversation with @simoncozens and also @moyogo first. We need to answer whether the tooling maybe should be able to react to different sets of defaults and alternatives. This implicates not just Shaperglot, but also the glyphset definitions, as the glyph alternatives there must then also be inverted. This is not my decision to make, but personally I think it's a good idea to the have the African Eng as default for fonts that are primarily targeting African Latin (even though Oi isn't that, it appears), because it would improve African Latin rendering in situations where languages aren't explicitly set in the application. What does everyone think about that? So even though Oi appears to not necessarily need the African Eng as the default, let's have that conversation please because it definitely affects other fonts and we’ll keep running into this issue. |
|
The rationale for using the "African" shape is that Sami languages or adjacent languages like Swedish, Norwegian and Finnish have OpenType Language system tags whereas many African languages that use the letter do not have any OpenType Langue System tags, plus the "African" shape is used in languages spoken by millions whereas the "Sami" shape is used in languages spoken by a few thousand people. That said, we’re probably making this a bigger issue than necessary. Experts will complain that one shape is not the canonical one in one language or another, but both shapes and others are so ubiquitous the layperson probably just deals with it. I’d recommend using the shape you think fits best as the default, have the other(s) accessible via the locale feature if possible and via character variants or stylistic sets features. The more fonts support these languages in various ways, the less of an issue this is. All fonts doing the exact same thing cannot be a perfect solution for everyone. Some fonts doing what one needs is better than none. The shaperglot check fontbakery is using is most likely unusable: googlefonts/shaperglot#37. |
|
I'll close this issue also. |
There are series of FAILS related to the GF_Latin_African glyphset (mostly the locl Eng alternate) but I could not find the respective Language tags on the Microsoft spec for all the languages mentioned on the report.
The report is too long to be posted in a comment.
@EbenSorkin what should I do?
The text was updated successfully, but these errors were encountered: