Emscripten 3.1.60 made a breaking change to `BindingType::toWireType`
(why is this done in a patch version?) so this change ensures that we
can continue to build on 3.1.58 and 3.1.64 (which is needed for #12234),
as a bridging strategy. We will need to merge this into 17.0-stable as
well so that we can upgrade the build agents to 3.1.64.
Relates-to: emscripten-core/emscripten#21692
Relates-to: #12234
The Description field should be required for published keyboards and
models, so this change means kmc-keyboard-info and kmc-model-info will
report an error if it is missing.
Relates-to: keymanapp/keyboards#3037
Relates-to: keymanapp/lexical-models#262
Fixes: #12202
The Windows Clipboard Win+V key event emits Ctrl+V after rewriting the
clipboard, in order to trigger a Paste action in the active app.
However, the Ctrl key event has been given a scan code value of zero by
Windows Clipboard, which was confusing the Keyman Developer Debugger,
causing it to process Ctrl as an unrecognized key rather than as a
modifier, and leading to an unsupported state.
This is a fix for the immediate issue. We could do more to improve
resilience such that `km_core_state_debug_items()` can never end up with
this exception when `km_core_process_event()` has returned true.
Fixes: #11978
Fixes: KEYMAN-DEVELOPER-20W
This updates the calculation of the lastModifiedDate property of the
.keyboard_info and .model_info file. It now looks for the most recent
commit to HISTORY.md, and then falls back to the project folder for
.keyboard_info and .model_info.
getLastGitCommitDate now also returns UTC date (it was giving TZ=0
which is affected by daylight saving), and works for a file rather than
just for a folder, and a corresponding unit test has been added.
The date strings returned will now always include '.000' msec suffix. I
have manually verified that the import into the api.keyman.com database
copes with this, and that this change still conforms to the expected
schema for .keyboard_info and .model_info files.
Last, but important, it turned out that the unit tests for kmc were not
running. This has been resolved in kmc/build.sh.
Fixes: #11793
Cherry-pick-of: #11805
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
Cherry-pick-of: #11806
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
Cherry-pick-of: #11707
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
There were two problems here:
* An undeclared variable `source`
* The `flick` parameter is an array, not an object, so indexing by
direction is invalid
Fixes: #11581
Fixes: KEYMAN-DEVELOPER-1YW
Cherry-pick-of: #11582
Key selection was left in a corrupted state in `builder.loadState()`, on
first load of the touch layout editor, because the selection was not
restored after calling `prepareLayer()`.
This only happens on first load because after first load, the selection
will have been saved to the state (which is kept in the backend,
associated with the instance of the editor), so pressing F5 to reload
the page will not reproduce the issue.
Fixes: #11573
Fixes: KEYMAN-DEVELOPER-1Z8
Handles when `<Version/>`, `<Name/>`, or `<ID/>` elements are missing
from `<Keyboard>` elements in the .kps file in kmc-package. Adds a unit
test.
Fixes: #11562
Fixes: KEYMAN-DEVELOPER-1YY
Also updates the only other place where a project file is loaded like
this, in the project renderer, and handles it too (this scenario is
less likely to happen because the project file must already have been
loaded in order to be presented in the UI).
Fixes: #11557
Fixes: KEYMAN-DEVELOPER-1Z2
If a relative or otherwise invalid path is given for `default project
path` in .keymandeveloper/options.json, then this will reset the path
to the default of `%Documents%/Keyman Developer/Projects`.
Fixes: #11554
Fixes: KEYMAN-DEVELOPER-1ZB
This arises if `%AppData%/Keyman/Keyman Developer` folder is missing.
It is sporadic because most times, Keyman Developer Server wins a
startup race and creates the folder before this code is ever reached.
Fixes: #11551
Fixes: KEYMAN-DEVELOPER-1MY
The `return` statement is unsupported in the web compiler. This is
documented, but the problem here was that the `nomatch` and `match`
metarules have no corresponding `fkp` structure, so that caused a fatal
error in the compiler if these were used in combination, e.g.
nomatch > return
Fixes: #11545
