by Michael S. Kaplan, published on 2006/11/02 03:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/11/02/928185.aspx
Christoph Päper asks:
Considering heterogeneous networks (OS-wise), wouldn’t it be benefical if MSKLC could export to, say, XML files conforming (as much as possible) to Apple’s keyboard DTD as described in
http://developer.apple.com/technotes/tn2002/tn2056.html? Alternatively this could be accomplished by a third-party app that converted MSKLC’s source files to XML (or vice versa)
This is an interesting question, one that was actually brought up at the time that the XML file as first announced on the Unicode List by Deborah Goldsmith of Apple (August 24, 2002 -- with the first mention of new features to be announced that day on August 15th).
The format of the .KLC file was not invented for Microsoft Keyboard Layout Creator; other than the fact that it's parent was not saved as a UTF-16 LE file, the format is almost identical to the one used in the Windows build process to generate the actual keyboards that have been used in NT-based Windows since the very beginning. Though there was a suggestion about it, no serious thought had been followed about creating a new format, mainly because creating a keyboard by using any kind of text file is actually the sort of thing MSKLC was trying to get away from! The goal of MSKLC was to create a user interface to make it easier to build the sort of keyboards that were already being used by Microsoft....
Anyway, after the format was announced, I had taken a quick look at it at noted that it was based on very different principles than keyboards on Windows used, and did not clearly define all of the same features (some could be described by using entirely different principles, others did not really appear to exist at all).
Also, Apple announced no immediate plans for a tool and in fact when people asked about tools to help create them, John Jenkins of Apple specifically stated "Keyboards can be straight XML now. You don't need any special tools to edit them. It's very nice that way." and Michael Everson (who had helped create some Apple keyboards in the past) "My understanding is that while a graphical editor would be nice, it's not the highest priority for the development team. Editing the hard way is what I'm doing anyway. :-)"
Given these facts, given the fact that there was already a working MSKLC.EXE that could get the job done, and given the fact that from our experience (including my own experience when I had to hastily create a large series of these keyboard layout files in a short amount of time) that the fix for a difficult file format is not a less difficult file format, it simply did not seem like a priority for MSKLC to support a format that couldn't in its initial form handle all of the layouts that it would need to and whose main benefit would be to make it easier to create keyboards for the Mac. :-)
In the time since then, a request for a new file format or for the idea of adopting one like Apple's has come up occasionally, but the case has never been too terribly compelling. Both approaches to keyboard layout creation are definitely children of their respective parents, and presumably of both the user scenarios they try to address and the method in which the respective companies expect people to use them.
Though in my opinion comparing
the user experience of working with the complicated Apple XML format with no special tool to create/edit them
with
the user experience of working with MSKLC
I have to say that it looks like the whole argument of who is hip and cool and who is stodgy and unyielding shows a decided reversal from what Apple is putting in its recent commercials. In fact, if I myself were more creative I'd create the spoof of the commercial to show that very thing! :-)
This post brought to you by ܞ (U+071e, a.k.a. SYRIAC LETTER YUDH HE)
Rosyna on 2 Nov 2006 3:27 PM:
FWIW, there's always this:
Michael S. Kaplan on 2 Nov 2006 3:40 PM:
Hi Rosyna,
Thanks for the link!
If the SIL tool is popular it kind of proves that Apple was incorrect that doing something cool here was not important (and given their commercials I doubt they want to be cast as doing uncool file formats while others create cool stuff after the fact -- they want to be cool out of the box!).
Michael S. Kaplan on 3 Nov 2006 5:36 AM:
Oops! Typo fixed now. :-)
Rosyna on 5 Nov 2006 10:35 PM:
Conversely, if the SIL tool is meeting people's expectations, then why should Apple make their own version?
But then again, I'm not sure there are enough Mac users that need this tool for Apple to write one and support it.
Michael S. Kaplan on 5 Nov 2006 11:40 PM:
SIL is one of the leading supporters of Keyman, but there was still a strong external and internal push for Microsoft to create the tool that became MSKLC. :-)
Henrik Holmegaard on 20 Dec 2006 4:51 AM:
Transparency from key cap to code point, and from code point to glyph (or grapheme with combining diacritics, ouch), is necessary.
It took Monotype and Linotype a quarter of a century to understand that the value of the hardware, the caster itself, depended on what you could compose with it.
Apple Computer and Microsoft Corporation are coming to the same conclusion, after the same delay, because the delivery model of publishing is changing.
The print-based delivery models in which TrueType and OpenType emerged, and in which ColorSync came to be central, is giving way to disk-based delivery models.
Transparent auditing and correcting of evaluatable color-colorant transforms has been available to professional photographers and lithographers since 1999.
Transparent auditing and correcting of evaluatable character-glyph transforms cannot reasonably be said to be available today.
The first alarm signal was when Apple Computer and Adobe Systems agreed to release the Adobe Type 1 Enabler for the SFNT Spline Font file format in September 1994.
The challenge was to correct the arbitrary assignments of Adobe Type 1 Expert glyphs, so composing Apple Offices did not cause coding of Apple OYces (ffi = Y).
The tools and the documentation were simply not there, neither for professional type users nor for professional type makers.
Hopefully, Apple Computer will not make the same mistake twice, since the mistake in 1994 sank the Apple professional prepress community into a morass which eventually led to the readoption of Adobe Type 1 and Adobe Type 1 Expert product lines, and the consequent chaotification of legible line layout in the Latin script.
With best wishes,
Henrik Holmegaard
technical writer, mag.scient.soc.
Henrik Holmegaard on 6 Apr 2008 6:07 AM:
> Transparency from key cap to code point, and from code point to glyph (or grapheme with combining diacritics, ouch), is necessary.
Marrying page description models and page markup models is problematic when the Adobe Type Library and the Linotype Type Library publish type product in which alternate stylistic appearances are depicted directly onto the CMAP as Private Use Area pseudo-charactoids.
It is not about being for or against a specific software publisher, but about software publishers taking software users hostage to strategies that block invertibility in information processing models in order to further some product or other.
The ICC Specification began with a clear and concise concept of a data space, a code space, and an rendering or output and a referencing or input transform for obligatory inversion. The flavours of SFNT Specification are flake specifications.
The semantic impoverishment of coded character sets prior to ISO-IEC 10646:1993 and the dominance until 1993 of serial access page description models that perish in printer memory as the page emerges have produced a problem in information processing.
The problem is that it is acceptable to sacrifice coded text for the sake of composed type. This simply has to stop or the costs will climb to catastrophic levels in the midterm and longterm.
Best wishes,
Henrik Holmegaard
sometime technical writer
Michael S. Kaplan on 6 Apr 2008 10:26 AM:
Okay, that is the last off-topic blather I will permit, Henrik -- from now on I'll truncate or delete if you can't stay somewhere within the topic -- which in this case was clearly CUSTOM KEYBOARDS and the priority Apple placed on creation of a tool to produce them.
An when I say somewhere within, I mean the bulk of the comment. :-)
Henrik Holmegaard on 25 Jun 2008 9:32 AM:
> CUSTOM KEYBOARDS and the priority Apple placed on creation of a tool to produce them.
Michael,
Producing character streams with pseudo-private Combing Diacritic charactoids or Private Use Area charactoids is controversial.
It impacts academic publishing e.g. in anthropology, modern linguistics, and historical linguistics, and it impacts lesser languages outside the EU.
ISO 10646 level 3 / Unicode is OK for printing hardcopy, but Ken Whistler who pushed a productive character model has not got it into his head that there is such a thing as softcopy.
Softcopy presupposes that the author configures the coding of text for assumptions compatible with those of her audience.
Pushing productive input methods for a productive character model is without pushing documentation is, to put it bluntly, bad salesmanship.
Henrik
Michael S. Kaplan on 25 Jun 2008 1:18 PM:
As usual Henrik, you confuse me. I see they are (mostly) English words (though none of my dictionaries here contain "charactoids"), but they have been strung together in a way that makes no sense to me, and I cannot tell for sure what you mean.
Though this par for the course, I suppose.
Once again you are not really on-topic but you seem to be taking longer pauses which helps your case a little. :-)
Henrik Holmegaard on 11 Jul 2008 7:08 AM:
> though none of my dictionaries here contain "charactoids"
'Charactoid' coined in 1991 by Ken Whistler as first technical secretary to the Unicode Consortium. It should be simple -:)
hh