SSA latin all changes

[RosaWagner]

cc @EbenSorkin

@moyogo Does it seem all good to you, all files in sync, etc?

[vv-monsalve]

Merging this to main branch would be ideal. I tried to create a custom .plist from the SSA-Latin branch but it still receives the old glyphs that shouldn't be included, e.g. rfishhook.

[RosaWagner]

@vv-monsalve @moyogo @EbenSorkin I updated the lists, can the PR be merged? Or are we waiting for something else?

[vv-monsalve]

I updated the lists, can the PR be merged? Or are we waiting for something else?

@moyogo could you confirm if you are planning to make more changes in the SSA-Latin branch?

[moyogo]

@RosaWagner @vv-monsalve Sorry for the delay. I’ve updated some language data and will use the scripts #109 to regenerate GF Latin African for SSA languages. I had missed a few things when trying to do it manually.

[vv-monsalve]

and will use the scripts #109 to regenerate GF Latin African for SSA languages.

@moyogo did you have the opportunity to regenerate eh GF Latin African? :)

[yanone]

This PR was originally authored before we began the transition of glyphsets to the new approach (outlined in the root README) of separately authoring language codes per glyphset, with characters being pulled in from gflanguages, rather than defining glyphsets manually.

I noticed that this PR produces conflicts with the GF Latin Core files that are now under the new approach. So at the very least, we need to make sure that the GF Latin Core are unaffected by this PR.

But I want to propose to take the opportunity to move the new African glyphsets definitions to the new approach immediately.

The purpose of the new approach is twofold:

• Dramatically improves the authoring of glyphsets by breaking apart the definitions into a language list per glyphset with with characters being pulled in from gflanguages
• Automatically include glyphsets under the new approach into the new shape_languages check in Fontbakery. This check relies on Shaperglot, which in turn relies on language definitions in gflanguages. To make this check even possible, glyphsets need to be in sync with gflanguages, and therefore must be derived from it via language codes rather than manually assembled which might lead to accidental differences in the glyphsets.

This last point is important because African languages contain a lot of character sequences that don't exist as a single encoded character, and therefore the new African fonts that are being authored as we speak should be checked by shape_languages especially for correctly functioning mark features, which requires the glyphsets to be defined under the new approach.

I'm very keen on pushing this transition forward, so I'm offering to author a separate PR. For this, I would need a list of languages per each new glyphset. I'm assuming that the gflanguages definitions are up-to-date for these languages, so assembling the files under the new approach should be easy.

FYI @chrissimpkins

[moyogo]

Closing.