The keycap on the KeymanWeb keyboard is showing the U+0674 high hamaz followed by a dotted circle, as though it was trying to treat it as a combining character. I see the same behaviour on both Firefox, Chrome and Opera. Whereas the both the touch keyboard on Android and the on-screen keyboard on Windows Keyman Desktop show the U+0674 correctly as a simple character. Am I missing something or has KeymanWeb got a bug?
It could be a font issue. Does the key cap contain only a U+0674 character in Developer? Or can you give a reference for the keyboard?
The project is in the repository at
Versions just in case it matters:
Chrome:81.0.4044.92 (Official Build) (64-bit)
Windows 10 Pro (64bit):1909 build 18363.720
That doesn’t exist in the main keyboards repo, but I believe it’s in your keyboards repo.
We can take a look and see…
Just noting the rendering between the two fonts
High Hamza on the
This may be related to https://github.com/keymanapp/keyman/issues/2990#issuecomment-616251617
Okay, I’ve found something a little unexpected here. It seems that the base width of the character is coming up as zero, so KeymanWeb adds a U+25CC dotted circle in an effort to help the character display better.
This is not ideal. We are seeing issues with this with the Khmer Angkor keyboard as well. We will discuss solutions here: maybe we will need to roll back the dotted circle change (it works well on some devices and some scripts but is not consistent).
My own view is that the dotted circle should only display if a character has combining properties, not if the glyph has zero width. Look at the UCD properties, not at how the font implements it.
The problem is because different fonts handle standalone combining marks differently, and different renderers also have varying implementations, we can end up with situations where dotted circles are repeated just on one platform or with one font, or conversely where one platform shows a dotted circle by default but another renders the mark out of the bounding rectangle – i.e. invisible. Neither of these are great outcomes.
So I think that whether we work with a zero-width heuristic or a UCD property test (which has its own back-compat issues on browser ) we still have the same problems to solve.
See https://marc.durdin.net/2015/01/how-to-rendering-combining-marks-consistently-across-platforms-a-long-story/ for a robust cross-platform solution that we implemented for Lao. That’s five years ago but things are just as much of a mess today. It’s not a simple solution but I think it’s probably the best one. I would like to do similar for Khmer.