change(common): remove drafted font metadata from KMX+ format 🔱#15788
Open
mcdurdin wants to merge 1 commit intofeat/developer/embed-osk/convert-touch-layout-into-kmx-plusfrom
Conversation
User Test ResultsTest specification and instructions User tests are not required Test Artifacts
|
This comes out of a design philosophy review on what we include when we embed OSK data into KMX. We will now avoid embedding font name into the OSK (and hence .kmx) altogether, and leave that metadata to the packaging data. Reasons: 1. The font information is specified in the .kps, so we have to do a patchup on the .kmx during packaging if we want to embed the info into the OSK. 2. The referenced font must be supplied separately anyway (via .kmp, @font-face, or system supplied, etc), so including the font facename in the keyboard is not really all that helpful. 3. Philosophically, the font is really a presentation level factor (aside from displaymap considerations). Keeping it together with future theming and styling choices, rather than the key layout data, seems appropriate. 4. This makes fewer places where font data is referenced -- in fact, to just one place: in the .kps/.kmp for LDML keyboards, which is great. This also simplifies some aspects of the embed-osk-in-kmx work, removing the need to patch the .kmx after the build, and eliminates the smelly kmx-plus-osk-token.ts file. A corresponding change has been made to the design document referenced in #14857. Test-bot: skip
6e9e351 to
79d4bdd
Compare
ermshiperete
approved these changes
Mar 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This comes out of a design philosophy review on what we include when we embed OSK data into KMX.
We will now avoid embedding font name into the OSK (and hence .kmx) altogether, and leave that metadata to the packaging data. Reasons:
The font information is specified in the .kps, so we have to do a patchup on the .kmx during packaging if we want to embed the info into the OSK.
The referenced font must be supplied separately anyway (via .kmp, @font-face, or system supplied, etc), so including the font facename in the keyboard is not really all that helpful.
Philosophically, the font is really a presentation level factor (aside from displaymap considerations). Keeping it together with future theming and styling choices, rather than the key layout data, seems appropriate.
This makes fewer places where font data is referenced -- in fact, to just one place: in the .kps/.kmp for LDML keyboards, which is great.
This also simplifies some aspects of the embed-osk-in-kmx work, removing the need to patch the .kmx after the build, and eliminates the smelly kmx-plus-osk-token.ts file.
A corresponding change has been made to the design document referenced in #14857.
Test-bot: skip