PRI #367: Generic dead keys and dead-key-based selectors


Older sources already promote a composition dead key and/or a remnant group selector. These are indispensable features of modern, performative keyboard layouts. This feedback proposes to redesign the composition tree on one hand, and on the other hand, to re-engineer the group selector as a dead key on AltGr/Option + Spacebar, giving access to a stack of up to eleven layout groups.






May 9, 2019, 9:31 PM
Trac Comment 7 by Marcel Schneider <charupdate@e3c7c05a764702d9—2018-02-10T19:25:10.776Z

== Cross-platform implementability of standard keyboards ==
It happens that keyboard layouts like those following ISO 9995, as found in Germany, can be implemented as-is on XKB, and are implemented there, just not on Windows nor on macOS with system resources (except modified versions).


On Windows and macOS, they can be implemented for sure using '''Keyman.'''

Problem: Many countries want their standard keyboard layouts ship with Windows and macOS. So there is no point in designing standards without making sure beforehand that Microsoft and Apple will implement them or at least provide the required framework. Thatʼs not how things worked when parts of ISO/IEC 9995 were published, however.

This is why we started making keyboard layouts that can be implemented on Windows and macOS, regardless of conformance to ISO/IEC 9995.

Now all weʼre waiting for is that Microsoft, Apple and CLDR recognize the use we make of the functionalities, and that LDML is extended to represent them.

May 9, 2019, 9:31 PM
Trac Comment 8 by Marcel Schneider <charupdate@e3c7c05a764702d9—2018-02-11T11:51:59.505Z

== Inappropriate representation of dead keys in LDML ==
Actually when reading an XML keyboard layout definition file in CLDR, we are expected to check the

element to learn whether a given output is a dead character or not; a bit less when it occurs as both and the

argument is present in one instance.

That syntax is counter-intuitive, and that is putting things upside down. Reaching the declared goal of better legibility is therefore compromised, already for simple transforms, and even more when it comes to chained dead keys. And when the accurate representation of dead keys by precomposed characters is applied, the whole stuff will become fully illegible.

This is why we propose the vocabulary and syntax corrections suggested in this ticket.

May 9, 2019, 9:31 PM
Trac Comment 9 by Marcel Schneider <charupdate@e3c7c05a764702d9—2018-02-12T16:19:29.024Z

== Add the

argument in the

element ==
To avoid updating the existing keyboard data in CLDR, the

argument is proposed for addition in the

element. The default value of


would be

, which means that all characters listed in the first place in the


argument are automatically dead keys, without further tagging, while only duplicate mappings intended for live output have the

argument in the

element. Legacy data is then fully compatible with the new syntax.


is in

, any dead key must have the

argument instead of the

argument. The

element can occur in multiple instances, and contains the


arguments as proposed in [comment 5|#comment:5]. This way, only the DTD is to be updated, and new layouts can be added with the more straightforward and powerful syntax, while all legacy layout data may remain as-is.

== The point in extending dead key syntax ==

The actual syntax seems to be designed for simple keyboard layouts with few through no dead keys and only most common transforms. However, especially with respect to Latin keyboards, not accessing all dead keys on the current layouts has become a non-starter, due to globalization and the need to respect everybodyʼs orthography. Without complete Latin layouts on a per-locale basis, adding an umlaut, a hacek or a dot below needs switching back and forth between different locales, possibly with base letters moving around. Alternatively, time-consuming long-presses may or may not be implementable on a given platform on a layout driver basis.

The legacy dead key scheme using spacing diacritics is a non-starter, too, as it does not cater for letters without a decomposition mapping (except bar and stroke). To input a letter with crook, we cannot predict what squiggle will be seen during the transform. And even such diacritics as cedilla and comma below are confusable in many font families and/or font sizes. This is why we suggest that dead characters be precomposed letters throughout. Additionally the

ASCII circumflex is needed as a dead character for the ‹superscript› dead key, for a proper and usable fallback output, and cannot be associated with ‹circumflex accent› any longer. Using the modifier letter circumflex accent instead is no solution, given the confusability, particularly for the user.

=== Conclusion ===

Summing it up: Dead keys need a new syntax, less invented and closer to actual implementations, conforming to goal 2 (faithfulness).

=== Updating legacy data ===

Actual legacy data may nevertheless be updated at some point, given that the layouts already in CLDR are less numerous than those being added when Linux (full XKB) and Keyman will be admitted.

== Comparison not compromised ==
The dual dead key syntax may be considered a concern wrt comparison of layouts.

This action however is typically performed using parsers or converters (to tabular format). These tools can be programmed to produce equivalent output from both syntaxes.

May 9, 2019, 9:31 PM
Trac Comment 11 by —2018-02-25T19:23:27.854Z

There was a lot of feedback on this PRI. The keyboard group has made some modifications based on feedback, but decided to leave other features for consideration for a future version.

May 9, 2019, 9:31 PM
Trac Comment 12 by —2018-10-17T15:34:50.339Z

CLDR 34 BRS closing item, move all upcoming → UNSCH




Mark Davis








Fix versions