We’ve submitted our keyboard, and have gotten the feedback that the preference is to use the fonts in the \shared\fonts\ folder rather than including a font in the package.
That may be fine for people who install the keyboard over the Internet, but what if we install the keyboard on a computer or a phone manually using the .kmp file? Would we also have to manually install the font?
The font we included was the Andika Africa subset (202Kb). If we don’t install that font with the keyboard on an Android phone, we often get boxes with X’s in them instead of the dotted circle that we want to appear as a base for combining diacritics on the touch layout.
We can make this change (to remove the font from the package), but we just want to understand the consequences.
The recommendation is to use the shared fonts path in the Keyman keyboard package source (.kps) file so that the keyboards repo doesn’t need to keep multiple copies of the same font files.
but what if we install the keyboard on a computer or a phone manually using the .kmp file?
The compiled keyboard package (.kmp) files distributed on https://keyman.com include the font file.
Keyman for Android will use the font file for displaying the on-screen keyboard. This also applies when you compile .kmp files with Keyman Developer and distribute them yourself.
Note: Android limitations prevent us from installing the font on the device, so output text may still get the square boxes.
One implication: If we haven’t cloned the entire keyboards repo (we just submit our individual keyboard in its precise location using GitHub web), then either we would need to create a “fake” directory structure for our keyboard development that duplicates the required paths of the repo (to be able to refer to the font at ..\..\..\shared\fonts\sil\andika_subsets\AndikaAfr-R.ttf) or we would need to include the font in the local source folder for our local testing, and then make the change in the package to point the shared font folder when we submit our keyboard.
Yes Jeff, If you don’t do your testing in the full Repo, you either need a faked structure for fonts, or you will have a different path in your local copy’s .kpj.
I typically release my Android app with a beta version of Keyman for Android, and the copy in the Repo is “locked” to features available in Keyman Stable. I’ve ended up with a process where I do my testing in a different directory structure with a local font folder (and the local path) and use a visual comparison/diff tool to copy over changes to the cloned repo. My local and repository folders thus have a few different lines in the .kpj file, and the local copy has the fonts inside. Each of my Local and cloned repo folders have separate version control.
Local folder for Keyman Beta and Alpha testing. Includes local fonts and unreleased notes, and notes for my Blog.
The cloned keyman/keyboards repository with shared fonts and only approved support files.
A repo for my custom Android App (including my beta-compiled KMP). I’m still waiting for the final feature of Keyboard resizing in KAB before I move over to KAB and happily abandon my custom app.
While this setup is more complicated, this helps me:
Avoid merge clashes if the Keyman repo gets updated by the team while I work on my local copy.
Test and submit my Android app with Beta features (And a beta KMEA), whereas the code in the official Keyman Repo always stays backward-compatible with Keyman Stable.
Keep and check in personal supporting documents that don’t get submitted to Keyman Central.
Avoid the anecdotal case where a compiled keyboard bundled locally with an App Builder app doesn’t display the font.
Make sure that my QWERTY and AZERTY keyboards stay as synchronized as possible.
Have a granular look at changes to avoid regressions during the diffing stage and the commit stage.