Closed jahorton closed 9 months ago
A prime example of an affected keyboard: sil_euro_latin
Touch layout:
"font": "DejaVu Sans",
Actual stub from the KMW Cloud API:
"font": {
"family": "LatinWeb",
"source": ["DejaVuSans.ttf", "DejaVuSans.mobileconfig"]
}
LatinWeb
will properly link the font - as that's what the stub calls it - while DejaVu Sans
will not.
Attempts to investigate this lead me to a question - where does that LatinWeb
bit even come from? I don't see any evidence of that string within sil_euro_latin.kps
!
Found this one while working on a user test for #10506.
We have a number of published keyboards in which the touch-layout has one setting/name for the keyboard's font while the package and/or stub uses a different name for the font. Details I've discovered:
stub name != touch-layout name
, the key-cap scaling function fails to find the font being used, instead basing key-cap scale on the default font, rather than the one KMW is using to display it!Since we have a lot of keyboards out there with a mismatch, we probably need to ignore the touch-layout name entirely, using only the stub-name instead.