Currently, keys must be a UTF-16 code unit or a virtual key. Non-BMP
characters are unsupported. Technically, there is space available in the
.kmx `COMP_KEY` structure to accommodate UTF-32 codepoints, from
kmx_file.h:
KMX_WORD_unaligned Key;
KMX_WORD_unaligned _reserved;
However, the utility of this is almost nil, as it is very unlikely we
will encounter base keyboards (for mnemonic layouts) that generate any
characters outside the BMP, so there is little value in adding support
for this at this time.
The compiler will generate an error if this is encountered.
Fixes: #11643
# Keyman Conventional Commit suggestions:
#
# - Link to a Sentry issue with git trailer:
# Fixes: _MODULE_-_ID_
# - Give credit to co-authors:
# Co-authored-by: _Name_ <_email_>
# - Use imperative, present tense ('attach' not 'attaches', 'attached' etc)
# - Don't include a period at the end of the title
# - Always include a blank line before trailers
# - More: https://github.com/keymanapp/keyman/wiki/Pull-Request-and-Commit-workflow-notes
The keyboard editor has a complex edit state machine, which has
grown a lot over time. This is a minimal patch to address one specific
edge case scenario on that state machine, without any attempt to improve
the state machine overall. The biggest change here is bubbling failure
up to the main form so that it can destroy (aka Release, which is an
asynchronous destroy) the editor window if it fails to load completely.
Fixes: #11715
Fixes: KEYMAN-DEVELOPER-1JC
I have not been able to reproduce this problem, so adding some extra
debug logs in an attempt to determine what is causing the assertion
failure.
Relates to: #11706
# Keyman Conventional Commit suggestions:
#
# - Link to a Sentry issue with git trailer:
# Fixes: _MODULE_-_ID_
# - Give credit to co-authors:
# Co-authored-by: _Name_ <_email_>
# - Use imperative, present tense ('attach' not 'attaches', 'attached' etc)
# - Don't include a period at the end of the title
# - Always include a blank line before trailers
# - More: https://github.com/keymanapp/keyman/wiki/Pull-Request-and-Commit-workflow-notes
The ttfmeta library is extremely rudimentary. It does next to no error
checking, and supports only a small part of the TTF spec. It did not
support NAME platforms 0 or 3 (the most common platform, Windows), and
these are encoded in UTF-16BE. This patch adds support for those
platforms and throws if an unsupported platform/encoding is encountered.
Now, the ttfmeta library is unsupported and gone (#11630). It is based
on another library, ttfinfo, last updated 11 years ago. This is not
great. But the other Node libraries that I located introduce further
dependencies or complex builds (e.g. WASM) and that's not great either,
for a function used only in one place in our build environment.
https://learn.microsoft.com/en-us/typography/opentype/spec/name
The test-font-family.ts runs a basic test against Lateef font, and has
a skipped test that can be run (with minor edits) against all fonts in
the keyboard repository. I have done this to verify that there are no
fonts that return errors, but have disabled this test for deployment for
now.
Fixes: #11625
Remove ttfmeta from package.json, and copy only the relevant files into
ttfmeta/ under kmc-keyboard-info. This is a stopgap measure as we will
probably attempt to identify an alternate library in the future.
See also #11625 which is the driver for making this change now.
Fixes: #11630