spec(developer): LDML to keyman-touch-layout tool 🙀

[mcdurdin]

Proposal

This will be a compile-time tool written in Typescript that takes the .kmx-ldml file and uses the DataBlob Library to interrogate the LDML file and generate a corresponding .keyman-touch-layout file.

This will then be used by the existing compiler toolchain to generate:

• the .js .KVKL property for web/touch platforms.

This tool should be accessible as a standalone library, wrapped with a command-line tool, so that it can be used for unit testing as well.

We may make this into the same command line tool as for .kvk (#5077), but the libraries should be separate deliverables.

Notes

• Globe button needs to be considered from a Keyman perspective
• fonts are "up to the vendor".
  • Use existing packaging keyboard property to define the font.
  • Keyman Cloud font data is part of .keyboard_info
• How do we handle the key identifiers from touch to send them into the LDML keyboardprocessor?
  • This is an open issue for discussion with the Keyboard-SC.
• Proposal for building layouts with hardcoded default sizing
  • This is an open issue for discussion with Keyboard-SC
  • key widths always 100 except a set of special keys
  • 'switch' keys are also 150? or 100?
  • rows are always centered, rather than stretched
    • question: stretch special keys at row margins?
    • alternative: ‘widths’ are more of a “width weighting” - rows always scaled to “full justified”
      • motivation (for vendor reference use): easier handling when keys dynamically inserted into a row (iOS globe / dictation keys)
  • spacebar always… 250? 500?
    • alternative: fill the remaining space once we've put the other A## row keys in (switch keys, specials, etc)
  • Different hardcoded default for desktop & touch
    • Because ctrl, alt more needed on desktop
• From LDML’s perspective, the output is the key identifier when it comes to displaying.
  • While many-keys to one-output scenarios are possible… it doesn’t matter which key is used to represent it. From LDML’s perspective, they all act identically.

Related

• 2858: KMW, Developer: Add support for multi-char U_xxxx_yyyy key identifiers

• 5079: KMW, Develoepr: Add support for hint property

• 5029: spec: Add support for multitap (and flick!)

• 5077: spec: LDML to KVKS tool

• Draft spec

---

Keyman Developer:

• OS: any
• Keyman Developer version: 15.0

[darcywong00]

Do we need a separate spec for how Developer and Web will handle the LDML spec of additional form-factors by size in mm? From Feb 2022 planning meetings, a possible workaround is having tablet vs phone map to various mm sizes.

Also possibly related to #4861?

[mcdurdin]

Do we need a separate spec for how Developer and Web will handle the LDML spec of additional form-factors by size in mm? From Feb 2022 planning meetings, a possible workaround is having tablet vs phone map to various mm sizes.

I am hoping we can update the touch layout template to support multiple sizes in mm rather than wedging LDML sizes into the limits of phone vs tablet. That will give us an answer for Android device type detection as well (where we are just guessing, heuristically, whether a device is a tablet or a phone).

[darcywong00]

From A18S8 NA planning meeting, reassigning to @ermshiperete for A18S9