[Feature] Slim down foreign fonts during build

[newtonick]

Dependency on SeedSigner/seedsigner-translations#48 and SeedSigner/seedsigner#819. Do not merge until both of these are merged first.

This pull requests is related to at least 2 other other pull requests. One in the seedsigner app repo and the other in the seedsigner-translations repo.

The objective of these 3 pull requests is:

• Move the large foreign language font files from the seedsigner app repo to the translation repo (a submodule in the app repo)
• Update the build script to include slimed down versions the foreign language font files that only include the character set used in seedsigner-translations. This should allow the final image to be ~10MB smaller (or more) than it is today.

This pull request makes these changes:

• create compile_translations_and_fonts function
• move existing create virtual env to compile translation files to this new function
• add steps in compile_translations_and_fonts to slim down the foreign language fonts to only include required characters

[kdmukai]

Not a bash expert, but googling yields this as a way to avoid hard-coded maintenance burden:

for font_file in "${ss_translations_repo}/fonts/*.ttf"; do
    # Extract filename without extension
    name="${font_file%.*}"
    new_name="${name}-Original.ttf"
    mv "$file" "${new_name}"
done

[kdmukai]

Similarly, this could be something like:

for font_file in "${ss_translations_repo}/fonts/*.ttf"; do
    # Extract filename without extension
    name="${font_file%.*}"

    # Replace "-Original" with empty string
    final_name="${name/-Original/}.ttf"

    # Trim the font file to our specified subset
    pyftsubset "${ss_translations_repo}/fonts/${font_file}" --text="${all_chars}" --output-file="${ss_translations_repo}/fonts/${final_name}" || exit
done

[kdmukai]

Now that I've dug into this PR and the related SeedSigner/seedsigner-translations#48 a bit, a couple of thoughts are leading me toward a slightly different implementation.

• The Asian fonts all seem to have some degree of redundant character sets (e.g. the Japanese font might include all the Korean characters). With this PR building a single master char list, that means those redundant character sets will be included multiple times (e.g. the Korean chars will be in the Korean font AND will be kept in the Japanese font). The heaviest consequence would probably be the Japanese font which also includes a lot of (all?) the complex Chinese characters.

• In the other direction, Persian and Arabic would both use the same font file. So we would want at least some kind of smart char set selection.

The bash scripting here isn't terrible but doing anything more advanced really calls for python.

A python script could:

• Import seedsigner.gui.components.GUIConstants to tell us which locales depend on which font file.
• Call the python script from [Feature] Add extract characters script and move foreign fonts into translation repo seedsigner-translations#48 to extract the minimized charset for a given locale. That script should be modified to run as an importable function, though, since it would no longer need to run from the bash script / command line.
• Intelligently merge locale charsets that use the same font (e.g. uses the union of the Persian + Arabic translations)
• And, obv, avoid unnecessarily redundant charsets for a given font (e.g. the Japanese font shouldn't keep the Korean or most of the Chinese characters).
• Then it looks like there are a few options (some more pythonic than others) to invoke the pyftsubset action of fontTools: https://stackoverflow.com/questions/55009981/how-to-use-pyftsubset-of-fonttools-inside-of-the-python-environment-not-from-th

Having this as a python script would also make it easier to run in local dev. And maybe even write some unit tests for it in the translations repo.

[kdmukai]

That all being said, while I prefer what I laid out above, I don't view any of the current approach in this PR to be objectionable.

Judgment call: Is this PR enough of a win to move it more quickly so it can be in the next release or does it just not matter if the next release is slightly bloated but subsequent releases will be quite optimal?

I'm fine with either.