After upgrading Developer from 13.0.108 to 13.0.111 today, and rebuilding my standalone app, the text on the buttons was reduced to a few pixels. (It wasn’t until I saw an enlargement of the screenshot that I could see any shape to them at all, and realize the characters were actually present, just reduced.)
Also: Setting the font size to 30 em fixes that problem, but creates a new one: Now the touch keyboard editor spaces the rows probably 20 times as far apart (so you have to scroll way down to see it all), and doesn’t display the text on the buttons:
30em is the same as 3000% – that is, 30x the default size if the value is left out. So actually the behaviour in the editor makes some kind of sense – you are asking for a font 30x the default and that just weirds it out.
If you choose a different font, what happens to the scaling on device? Trying to narrow down if it’s a font-specific issue or something gone wrong elsewhere.
Yes, it does make sense that 30 em throws the editor for a tizzy. One should never have to use a setting so extreme. However, the 30x scale does not actually seem to based on the “default size if the value is left out”. If I leave the value out, the characters are legible but in need of 50% enlargement, which is why I had been using 1.5 em.
I’m sure it’s related to the font somehow, or you’d have heard from others besides me. Unfortunately I can’t get KAB to accept any other Thaana font. My guess was that somewhere between 13.0.108 and 13.0.111, the calculation was changed to reference a different font metric?? I’ve just added you to the GitHub project if you want to take a look at the font and/or keyboard.
Another problem that is new since 13.0.108 is that when I test my touch layout in a browser, it doesn’t matter what the font size setting is: It could be 0.5em or 30em, and regardless of this, it will always display at the default somewhat-too-small scale. I’m not too bothered by this, but perhaps it will provide a clue as to what’s going on.
Thanks for sharing the project. I have reproduced the problem here and have tracked it down to a fix in https://github.com/keymanapp/keyman/pull/3204. This was an important fix but it turns out to have highlighted a bug in the fontsize property – it’s treated as an integer internally but works as a string in the designer. This means that when it is compiled, we end up going from "1.5em" to just plain 1 which is probably treated as 1pt or even 1px … That’s not what we want, obviously.
I’ve documented this problem at https://github.com/keymanapp/keyman/issues/3487 and given it is a regression, we’ll back-port a fix to 13.0 as soon as we can (I am away for the next week, so it will probably be the following week). It shouldn’t be a hard issue to fix but we’ll want to test thoroughly.
In the meantime, you can work around the issue by editing the compiled .js file, after compiling, and manually replacing "fontsize":1 with "fontsize":"1.5em", to at least let you continue to test etc. Obviously, that’s not a workable long term solution
