From: Karl Pentzlin (karl-pentzlin@acssoft.de)
Date: Mon Jan 04 2010 - 19:37:45 CST
Am Montag, 4. Januar 2010 um 04:25 schrieb Michael S. Kaplan:
>> From: "Karl Pentzlin" <karl-pentzlin@acssoft.de>
>> Microsoft Keyboard Layout Creator (V1.4) is definitely an outdated tool.
>> For instance (please correct me if I have overlooked something):
>> 1. I cannot assign a SMP character as "composite" to a dead key combination.
MSK> A limitation of the Windows USER keyboard architecture. This hardly makes
MSK> the tool "outdated".
In fact, I tried to answer in short, thus I did not provide a detailed
discussion differentiating between the tool itself and its applicability.
Thus, my claim of "outdated" applies to the process to generate
keyboard layouts by MSKLC V1.4 as a whole.
It does not bother me whether the "Windows USER keyboard architecture"
or the tools to work with it are outdated. The whole thing is outdated
in an inacceptable way as long as it does not support SMP characters
completely and without restrictions (independently of my other points).
When the Unicode committee tells proposers e.g. of the Hungarian Runic
script that there is no problem to encode the script in the SMP for
good reason, either all members of the committee (including Microsoft)
have to do their homework (in this case: enable them to implement
their keyboard layouts without any SMP-related problems), or they are
liars.
(I get especially angry on this point as I had several personal
discussions with the representative of the Hungarian NB, to convince
him that there are no problems when he agrees to have their script
encoded in the SMP; thus the accusation of being a "liar" includes myself.)
>> 2. I cannot handle diacritics as dead key when the destination character
>> is not available as a precomposed character.
MSK> Also a limitation of the Windows USER keyboard architecture. This hardly
MSK> makes the tool "outdated".
As said, I want to design keyboard layouts, not to adhere to any
architecture, especially one for which I did not manage to find any
documentation by reasonable means.
Maybe you know the old joke:
Q: How many engineers are required to change a burnt-out light bulb?
A: None, if you declare darkness being the industry standard.
The original version of this joke is attributed to "Microsoft
engineers", but in fact none of the Microsoft employees I met at ISO
meetings or elsewhere showed such an attitude.
However, I see this attitude in the way you recur to the "Windows USER
keyboard architecture" here.
>> 3. I cannot handle multiple diacritics as dead keys (considering applying
>> a single diacritic to a precomposed character a "bad trick").
MSK> Also a limitation of the Windows USER keyboard architecture.
Again - MSDN, Bing, and Google unanimously say:
No Results Found For: "Windows USER keyboard architecture"
(Maybe you can provide a link to a concise description?)
>> 4. I cannot work on a Japanese-like 106-key layout.
MSK> The 106 key keyboard adds only one additional key that would be useful for
MSK> letters/symbols, and adding it when it is unavailable on the vast majority
MSK> of keyboards is a genuine usability issue. This hardly makes the tool
MSK> "outdated".
Maybe "incomplete" is more appropriate than "outdated" here.
The 106-key keyboard obviously has 4 keys more than the 102-key one,
and please let the layout creator decide which keys they consider useful
for whatever purpose.
Of course there is no problem if a tool is restricted to the needs of some users
only (even if this group is considered being the vast majority), if at the same
time another tool is offered to the experts (I even would pay for it).
But there apparently is only one MSKLC, thus I can expect it to handle a
keyboard which is in fact available as an industry mass product for
127 million users (inhabitant count of Japan).
>> 5. I cannot define an ISO/IEC 9995 conformant Group Selection.
MSK> Um, I guess. This makes the tool "outdated" in what way exactly? Any tool
MSK> that does not support a particular ISO standard that Microsoft did not
MSK> participate in and does not use to define or describe its keyboard layouts
MSK> is "outdated"?
In fact, here "defective" is more appropriate than "outdated".
An international standard is an international standard (especially if
in fact there are national standards which adhere to it, as e.g. the
Canadian one), whether Microsoft or any other company participates in
its development or not.
Microsoft is to be praised for its engagement in providing localized
variants of its operating system and other software, thus supporting
the cultural diversity. It is a pity that the company did not accept
the invitation to participate in the special area covered by ISO/IEC
SC35/WG1, to support their own goals there.
>> 6. I cannot import tables (e.g. text files or Excel sheets;
>> except hacking the Source File format).
MSK> And this clear FEATURE REQUEST makes it outdated? Given the lack of any
MSK> coherent format that can describe everything the source format requires,
MSK> even now (years later!) I'd say this is more of a limitation of the format
MSK> makers. :)
Admitted.
>> 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.)
MSK> Um, huh? The layouts do no such thing, and neither does the underlying
MSK> architecture. Maybe this is something extra you are doing?
This depends on the definition what a layout is. Is it only a
description of the keytop engravings, or does it include the exact
function of its keys? I, admittedly, adhere to the latter interpretation.
>> (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.)
MSK> Given the fact that it was the lack of support in a core platform
MSK> architecture and the feedback from Microsoft on that point that led to the
MSK> inclusion of the alternate method in the first place, I would say that the
MSK> only thing "outdated" here is a notion that failing to support 100% of a
MSK> standard that it was never intended to support is a flaw of any sort. The
MSK> whole fanciful "user switching" notion, not supported anywhere, is
MSK> standardese fantasy, not supported by any architecture AFAIK. It was
MSK> originally a compromise to help bring existing architectures into the fold
MSK> but then it went this other weird direction.
Sorry, I have difficulties to understand this. I assume that you refer
to the preceding paragraph cited from my previous mail, referring to
dead-key vs. Unicode-order input of diacritics. Unfortunately, I am
quite new in the SC35/WG1 business and do not know very much of its history.
What "lack of support" and "alternate method" do you refer to?
By "user switching", do you refer to the possibility to switch between the
two mentioned input methods for diacritics?
By "compromise" and "weird direction", do you refer to the "dead key" method?
MSK> ANYWAY, I really only originally took issue with your use of language in
MSK> calling MSKLC outdated, but now I'd add that since I have read most every
MSK> draft of the standard in question you have been citing that I have done my
MSK> due diligence and that you could at least do the appropriate
MSK> research/homework as a part of doing yours. :-)
What, exactly, are you missing?
- Karl
This archive was generated by hypermail 2.1.5 : Mon Jan 04 2010 - 19:40:54 CST