From: Michael S. Kaplan (michka@trigeminal.com)
Date: Sun Jan 03 2010 - 21:25:27 CST
From: "Karl Pentzlin" <karl-pentzlin@acssoft.de>
> MSK> From: "Karl Pentzlin" <karl-pentzlin@acssoft.de>
> >> Microsoft Keyboard Layout Creator (V1.4) is definitely an outdated
> >> tool.
> MSK> I'd love to better understand this assertion....
>
> For instance (please correct me if I have overlooked something):
> 1. I cannot assign a SMP character as "composite" to a dead key
> combination.
A limitation of the Windows USER keyboard architecture. This hardly makes
the tool "outdated".
> 2. I cannot handle diacritics as dead key when the destination character
> is not available as a precomposed character.
Also a limitation of the Windows USER keyboard architecture. This hardly
makes the tool "outdated".
> 3. I cannot handle multiple diacritics as dead keys (considering applying
> a single diacritic to a precomposed character a "bad trick").
Also a limitation of the Windows USER keyboard architecture. This hardly
makes the tool "outdated".
> 4. I cannot work on a Japanese-like 106-key layout.
The 106 key keyboard adds only one additional key that would be useful for
letters/symbols, and adding it when it is unavailable on the vast majority
of keyboards is a genuine usability issue. This hardly makes the tool
"outdated".
> 5. I cannot define an ISO/IEC 9995 conformant Group Selection.
Um, I guess. This makes the tool "outdated" in what way exactly? Any tool
that does not support a particular ISO standard that Microsoft did not
participate in and does not use to define or describe its keyboard layouts
is "outdated"?
> 6. I cannot import tables (e.g. text files or Excel sheets;
> except hacking the Source File format).
And this clear FEATURE REQUEST makes it outdated? Given the lack of any
coherent format that can describe everything the source format requires,
even now (years later!) I'd say this is more of a limitation of the format
makers. :)
> 2./3. simply require sequences of combined characters entered as dead
> keys simply being reordered after the next character suitable as base
> character, and then being reordered according to NFC or NFD when used
> in a Unicode environment. (In fact, some special cases like use of
> Backspace after a dead key may require additional rules.)
Um, huh? The layouts do no such thing, and neither does the underlying
architecture. Maybe this is something extra you are doing?
> Please refer to the following documents to see what kind of keyboard
> layouts are expected to be dealt with an up-to-date version of MKSLC:
> 1. http://www.open-std.org/JTC1/SC35/WG1/docs/info1-9995-3.pdf
> (description of the revision of ISO/IEC 9995-3, currently in FDIS)
> 2.
> http://portailgroupe.afnor.fr/public_espacenormalisation/ISOCEIJTC1SC35/jtc1sc35n1381.pdf
> (NP proposal on ISO/IEC 9995-9: Multilingual, Multiscript Keyboard
> Group Layouts)
> 3. http://www.csc.fi/english/pages/meek/cwa-draft-091005 - Appendices 1
> and 3
> (the final version of this paper, with some editorial changes, is
> submitted to CEN
> for publication);
> for more details about Appendix 3 see the "Five Scripts Keyboard":
> http://www.world-keyboard.com/
I've seen the doc, and I remain unimpressed. And I hardly find anything that
fails to dance to a given tune as "outdated".
> (Note regarding dead keys: People using a dead-key-free keyboard may
> consider it appropriate to have diacritics entered in the Unicode
> order, i.e. after the base character. Unfortunately, virtually all
> keyboards for languages using the Latin script implement diacritics as
> dead keys, as a heritage of the mechanical typewriters. Therefore,
> ISO/IEC 9995-3 is bound to dead keys, while newer concepts like the
> ISO/IEC 9995-9 draft employ both ways, leaving the choice to the
> users.)
Given the fact that it was the lack of support in a core platform
architecture and the feedback from Microsoft on that point that led to the
inclusion of the alternate method in the first place, I would say that the
only thing "outdated" here is a notion that failing to support 100% of a
standard that it was never intended to support is a flaw of any sort. The
whole fanciful "user switching" notion, not supported anywhere, is
standardese fantasy, not supported by any architecture AFAIK. It was
originally a compromise to help bring existing architectures into the fold
but then it went this other weird direction.
ANYWAY, I really only originally took issue with your use of language in
calling MSKLC outdated, but now I'd add that since I have read most every
draft of the standard in question you have been citing that I have done my
due diligence and that you could at least do the appropriate
research/homework as a part of doing yours. :-)
Michael
This archive was generated by hypermail 2.1.5 : Sun Jan 03 2010 - 21:29:01 CST