The font size used seems to be too large, and as a result long words don’t feet. As a result it’s hard to pick the right word form, which makes it almost useless exactly when it would be most useful: to tap in long words. Can’t the font size be defined or adjusted based on word length?
When replacing the word in the text, capitalization of the that word is ignored. I was unable to find any hints about how to change that in docs. The Typescript examples are all about how to make for the proper search in the dictionary, but not about getting the right form for replacement.
Note that you can press down on suggestions and scroll them horizontally if needed. We have received a number of ideas for improvement in this area, but unfortunately they won’t be landing in 14.0.
As for capitalization, a lexical model (dictionary) developer must explicitly tell Keyman to model capitalization via use of the languageUsesCasing flag, setting it to true in the lexical model’s source. If that language uses English-like capitalization rules, that will probably be enough; languages with more “unique” rules may need additional effort to work correctly. We can’t quite know every language’s capitalization patterns in advance, after all.
Thank you! The documentation was not clear about languageUsesCasing flag , so I thought that’s a default setting for the model. Will add.
As to scrolling the suggestions - that’s a great hint I did not know. It is still quite slow, and as Armenian has full set of inflections of words, it could be quite frustrating, as you may end up trying 3 times just to find out none of the words fit. The default behavior of Apple’s own keyboards for long words is to show the end of the word, not the beginning, manifesting that it agrees with how the beginning of the word was typed and proposing how it could be finalised. That seems relatively easy to implement and works very well. If the typo is in the beginning, it proposes the shortest forms (which are not necessarily the basic form) so that the chance they fit into the field is higher.
Here is the information:
Device: iPhone Xs Max
OS: iOS
Keyman version: 14.0.243
Target app: any (e.g. Notes).
Keyboard is developed by me for Armenian language (Armenian Typewriter). I am planning to upload it to the repository as soon as it’s properly tested. I’ve attached the screenshot. BTW, I am also unable to set the font for the keys, whatever I define and add into the package, the default system font is used, and for numbers layer the font is different - it’s a serif font, while for the letters a sans serif font is used.
Then I plan to also design an Armenian phonetic keyboard, as the default iOS keyboard is terribly bad.
I recently discovered that with my Keyman file open in Developer, there is a Keyboard menu that allows you to define the font used for the touch layout:
This shows up in the .js file like this:
I’m using an Africa subset of Andika, which is a lot smaller, and I package that font (AndikeAfr-R.ttf) in with the keyboard package.
You seem to be lucky. With my setup I’ve tried all the kinds of fonts exactly the way you do, and still Keyman uses the default system font on iPhone ignoring my setting. Any suggestions?
What Jeff has suggested is true…that the font can be set within Keyman Developer, and in the Android phones it will use that font in the Keyman application. However, my understanding is that the IPhone or IPad will not allow for a font to be installed and used in the Keyman application. It is unfortunately not something we can control at this point.
You can include a font with your package and it will work with the key caps of the keyboard - both Android and iOS.
You can also include a font that will work within the Keyman app for editing.
But, we cannot make a font available system-wide on Android – Android does not permit this. This means that other apps on Android may not support your writing system (and we cannot control this).
We also do not currently support installing a font system-wide on iOS – but this feature will be available in an upcoming release (#3445).
