Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
Le 30/05/12 06:26, Jean-François Colson a écrit : Le 28/05/12 22:53, Doug Ewell a écrit : Karl Pentzlin wrote: As said in an earlier posting, the part 9995-9 is now in DIS, which means that its final version will be published 2013 or 2014. Thus, national standards referring to this part will hardly be published before 2015. Thus, there is enough time for any manufacturer of operating systems or third-party software suppliers to announce their support of any keyboard layout compliant with a standard referring to ISO/IEC 9995-9. Again, just speaking about one platform (Windows) that seems to be in somewhat common use, the problem is that the underlying architecture doesn't support multiple dead keys on a single base character, nor does it support a fifth, sixth, etc. shift state (unless one chooses to be reckless and use Ctrl). This is unlikely to change in the next two to three years. It isn't a matter of providing a layout—otherwise, anyone with MSKLC and a supported Windows version could create one. The only limitS I know for Windows’ dead keys is that they can’t handle characters outside from the BMP. … and that there can only be one single character at the output. With MSKLC, it is possible to support multiple dead keys on a single base character: http://msdnrss.thecoderblogs.com/2011/04/chain-chain-chain-chain-of-dead-keys/ (I didn’t say it’s easy: you need to edit the klc file with a text editor and to compile it manually.) Using the same technique, you can even make a compose key. And for the 5th and 6th layers, perhaps you could look at the Neo layout (a Dvorak-like keyboard layout for German, http://neo-layout.org). They made Windows drivers for their very special layout which uses three pairs of modifiers: Shift, Mod3 and Mod4. You could certainly find ideas there. JF
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
On Tue, 29 May 2012 12:52:12 -0700 Doug Ewell d...@ewellic.org wrote: And yes, of course it's possible to stack an entire new layer on top of the existing Windows key architecture, as Keyman does. Maybe that is the long-term solution, but I haven't heard that MS is planning to go that route. I'm confused by this technology discussion. I thought the Windows 'Text Services Framework' was already available as a ready way to implements one's own IME. For example, it's used by an open source Keyman for Linux (KMFL) implementation for the Windows by the name of Ekaya, and at the very least it has been used to implement a brute force method of entering BMP characters by hex. (At least, it sounded like brute force to me.) Richard.
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
On 2012-05-28, Doug Ewell d...@ewellic.org wrote: ... Again, just speaking about one platform (Windows) that seems to be in somewhat common use, the problem is that the underlying architecture doesn't support multiple dead keys on a single base character, nor does it support a fifth, sixth, etc. shift state (unless one chooses to be reckless and use Ctrl). This is unlikely to change in the next two to three years. It isn't a matter of providing a layout—otherwise, anyone with MSKLC and a supported Windows version could create one. .. Microsoft can never support ISO/IEC 9995-3:2010 unless they change their keyboard handling architecture, as above. Why is this a problem? The X keyboard handling has undergone a couple of significant extensions of architecture over the years, and that involved getting lots of people to agree. Microsoft can just do it. And I don't see what the problem is, anyway: from a quick look at the MS keyboard model, one could (as one does with X) process keystrokes through a userspace library to get the desired effect. The keyboard driver may only handle a couple of shift states and one dead character, but an input library can do whatever it likes. No actual need to extend all the keyboard drivers - it can all be done by TranslateMessage(), can't it? -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
Some of the features in those keyboard standards seem of sufficient complexity that I can't imagine anyone other than specially trained typists to ever be using them. That would presumably dampen the enthusiasm of anybody in the business of catering to average users. I'm basing that on personal observation of how such average users are struggling with utilizing even the features that exist today. A./
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
On May 29, 2012, at 5:30 AM, Asmus Freytag wrote: Some of the features in those keyboard standards seem of sufficient complexity that I can't imagine anyone other than specially trained typists to ever be using them. Indeed, I suspect the future may lie elsewhere than in creating more shift states for individual keys, for example the character picker feature now available on the Mac and Apple mobile devices. http://macnancy.wordpress.com/2011/09/29/how-to-use-character-picker-in-lion/
[OT] Keyboard standards (was: Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee)
Am Dienstag, 29. Mai 2012 um 11:30 schrieb Asmus Freytag: AF Some of the features in those keyboard standards seem of sufficient AF complexity that I can't imagine anyone other than specially trained AF typists to ever be using them. Exactly this user group is the primary audience for whom at leat the new German keyboard standard DIN 2137:2012 was developed. When you type a private SMS to your friend which contains an ç, you may picking characters by holding your finger one second on the c on your iPhone, look which variants are displayed then near your finger, and then move your finger there accordingly. But if you are a secretary who has to deliver your 210 strokes per minute the whole working day from 9 to 5, this is no option. Then you are happy if you can rely on a new standard to write all names of your business partners in the European Union correct, just by learning some additional fingerings for your touch typing. AF That would presumably dampen the AF enthusiasm of anybody in the business of catering to average users. As average user, you can decide by yourself what (if any) of the added features you want to use, and you have the choice to learn only the characters which are important for you. E.g., if you are one of the 2 million Turks living in Germany, you may learn how to type çğıİş. If you are a Fraktur enthusiast, you probably will learn how to type the long s and how to work with the Zero Width Non-Joiner enterable by AltGr+., without caring about the Turkish letters at all. If you care about typography, you may be happy that you now can type the true apostrophe and the en/em dashes with ease. If you care about nothing of these (or if you use such features only occasionally, thus a character picker is still a better tool for you), you can simply type like before (we deliberately changed no feature, but only added features, thus even for the touch typist, in no case a fingering was changed). - Karl
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
2012/5/28 Karl Pentzlin karl-pentz...@acssoft.de: Am Montag, 28. Mai 2012 um 19:02 schrieb Doug Ewell: DE ISO/IEC 9995-9 cannot be implemented natively on Microsoft Windows; it DE requires a third-party add-on package such as Keyman, which is not free. It is too early to blame Microsoft (or anybody else) on this. I do agree. When this will become an approved standard, Microsoft will even provide an updated MSKLC tool to support it completely.
RE: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
Philippe Verdy verdy underscore p at wanadoo dot fr wrote: DE ISO/IEC 9995-9 cannot be implemented natively on Microsoft DE Windows; it requires a third-party add-on package such as Keyman, DE which is not free. It is too early to blame Microsoft (or anybody else) on this. I do agree. When this will become an approved standard, Microsoft will even provide an updated MSKLC tool to support it completely. Did you read what I wrote? The *underlying architecture* of Windows key handling supports neither additional shift states nor multiple dead keys, both of which are required to support this standard. A new version of MSKLC on top of the existing architecture will not help. -- Doug Ewell | Thornton, Colorado, USA http://www.ewellic.org | @DougEwell
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
2012/5/29 Doug Ewell d...@ewellic.org: Philippe Verdy verdy underscore p at wanadoo dot fr wrote: Did you read what I wrote? The *underlying architecture* of Windows key handling supports neither additional shift states nor multiple dead keys, both of which are required to support this standard. A new version of MSKLC on top of the existing architecture will not help. If that was true, then Keyman would not even work on Windows ! There are several layers in the Windows keyboard architecture (between the physical keycodes detected at the hardware level, their translation into virtual keycodes by the low-level device driver, their classification into system keys handled directly and not converted within Windows and the rest of the conversion to characters which is fully part of the keyboard driver, then for their conversion to applciations using several interface layers for BIOS/DOS compatiblity, or for onversion to legacy non-Unicode ANSI applications) and all these layers allow this support. MSKLC provide the support in the driver it generates for almost all these levels : it does not just allows building the layout tables, it also creates a complete driver that integrates this layout. MSKLC does not just build a layout file (this does not work alone on Windows), as simply as what you can find on keyboard layouts for X11 on Linux/Unix'es. Keyman is different because it installs a generic driver that can then load multiple layout files. The drivers built by MSKLC are not separatable between the code part and the layout part, even if you can create a source file describing only the layout data (these files are not installable on Windows, they have to be compiled into a driver, and the driver installed like a regular device driver).
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
On 2012-05-29, Doug Ewell d...@ewellic.org wrote: Did you read what I wrote? The *underlying architecture* of Windows key handling supports neither additional shift states nor multiple dead keys, both of which are required to support this standard. A new version of MSKLC on top of the existing architecture will not help. Again, please could you explain how this is the case? -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
RE: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
Julian Bradfield jcb plus unicode at inf dot ed dot ac dot uk wrote: Did you read what I wrote? The *underlying architecture* of Windows key handling supports neither additional shift states nor multiple dead keys, both of which are required to support this standard. A new version of MSKLC on top of the existing architecture will not help. Again, please could you explain how this is the case? Michael Kaplan, who developed MSKLC, has blogged about this quite a few times: http://blogs.msdn.com/b/michkap/ And yes, of course it's possible to stack an entire new layer on top of the existing Windows key architecture, as Keyman does. Maybe that is the long-term solution, but I haven't heard that MS is planning to go that route. -- Doug Ewell | Thornton, Colorado, USA http://www.ewellic.org | @DougEwell
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
Le 28/05/12 22:53, Doug Ewell a écrit : Karl Pentzlin wrote: As said in an earlier posting, the part 9995-9 is now in DIS, which means that its final version will be published 2013 or 2014. Thus, national standards referring to this part will hardly be published before 2015. Thus, there is enough time for any manufacturer of operating systems or third-party software suppliers to announce their support of any keyboard layout compliant with a standard referring to ISO/IEC 9995-9. Again, just speaking about one platform (Windows) that seems to be in somewhat common use, the problem is that the underlying architecture doesn't support multiple dead keys on a single base character, nor does it support a fifth, sixth, etc. shift state (unless one chooses to be reckless and use Ctrl). This is unlikely to change in the next two to three years. It isn't a matter of providing a layout—otherwise, anyone with MSKLC and a supported Windows version could create one. The only limit I know for Windows’ dead keys is that they can’t handle characters outside from the BMP. With MSKLC, it is possible to support multiple dead keys on a single base character: http://msdnrss.thecoderblogs.com/2011/04/chain-chain-chain-chain-of-dead-keys/ (I didn’t say it’s easy: you need to edit the klc file with a text editor and to compile it manually.) Using the same technique, you can even make a compose key. And for the 5th and 6th layers, perhaps you could look at the Neo layout (a Dvorak-like keyboard layout for German, http://neo-layout.org). They made Windows drivers for their very special layout which uses three pairs of modifiers: Shift, Mod3 and Mod4. You could certainly find ideas there. JF
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
Le 28/05/12 22:53, Doug Ewell a écrit : Karl Pentzlin wrote: As said in an earlier posting, the part 9995-9 is now in DIS, which means that its final version will be published 2013 or 2014. Thus, national standards referring to this part will hardly be published before 2015. Thus, there is enough time for any manufacturer of operating systems or third-party software suppliers to announce their support of any keyboard layout compliant with a standard referring to ISO/IEC 9995-9. Again, just speaking about one platform (Windows) that seems to be in somewhat common use, the problem is that the underlying architecture doesn't support multiple dead keys on a single base character, nor does it support a fifth, sixth, etc. shift state (unless one chooses to be reckless and use Ctrl). This is unlikely to change in the next two to three years. It isn't a matter of providing a layout—otherwise, anyone with MSKLC and a supported Windows version could create one. The only limit I know for Windows’ dead keys is that they can’t handle characters outside from the BMP. With MSKLC, it is possible to support multiple dead keys on a single base character: http://msdnrss.thecoderblogs.com/2011/04/chain-chain-chain-chain-of-dead-keys/ (I didn’t say it’s easy: you need to edit the klc file with a text editor and to compile it manually.) Using the same technique, you can even make a compose key. And for the 5th and 6th layers, perhaps you could look at the Neo layout (a Dvorak-like keyboard layout for German, http://neo-layout.org). They made Windows drivers for their very special layout which uses three pairs of modifiers: Shift, Mod3 and Mod4. You could certainly find ideas there. JF
[OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
Karl Pentzlin replied to Jukka K. Korpela: JKK I don’t think there will be any standard on [how to type INDIAN RUPEE SIGN on a U.S. English keyboard]. It is contained in the draft of ISO/IEC 9995-9 Multilingual, Multiscript Keyboard Group Layouts which is currently being submitted to DIS voting. ISO/IEC 9995-9 cannot be implemented natively on Microsoft Windows; it requires a third-party add-on package such as Keyman, which is not free. -- Doug Ewell | Thornton, Colorado, USA http://www.ewellic.org | @DougEwell
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
On 2012-05-28, Doug Ewell d...@ewellic.org wrote: Karl Pentzlin replied to Jukka K. Korpela: JKK I don’t think there will be any standard on [how to type INDIAN RUPEE SIGN on a U.S. English keyboard]. It is contained in the draft of ISO/IEC 9995-9 Multilingual, Multiscript Keyboard Group Layouts which is currently being submitted to DIS voting. ISO/IEC 9995-9 cannot be implemented natively on Microsoft Windows; it requires a third-party add-on package such as Keyman, which is not free. I don't understand this remark. Microsoft Windows is not free, so what does it matter whether there's a free addon or not? If ISO/IEC 9995-9 becomes a standard, then Microsoft will presumably support it, either themselves or by buying Keyman. If they don't, then there are other operating systems. Defects in one OS have no relevance for standards - although they may be a pain for a little while (e.g. Linux' rather slow support for Unicode). -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
Am Montag, 28. Mai 2012 um 19:02 schrieb Doug Ewell: DE ISO/IEC 9995-9 cannot be implemented natively on Microsoft Windows; it DE requires a third-party add-on package such as Keyman, which is not free. It is too early to blame Microsoft (or anybody else) on this. The ISO/IEC 9995 series does not define keyboard layouts itself, but provides a framework on which (national and other) standards which define a keyboard layout can rely or refer to. As said in an earlier posting, the part 9995-9 is now in DIS, which means that its final version will be published 2013 or 2014. Thus, national standards referring to this part will hardly be published before 2015. Thus, there is enough time for any manufacturer of operating systems or third-party software suppliers to announce their support of any keyboard layout compliant with a standard referring to ISO/IEC 9995-9. The fact that Microsoft until now does not support ISO/IEC 9995-3:2010 Complementary layouts of the alphanumeric zone of the alphanumeric section, which is required e.g. by the German standard DIN 2137:2012 to be published in June, is a different issue. (But, referring to the original thread topic, 9995-3 does not contain the new Indian Rupee sign.) - Karl
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
Julian Bradfield wrote: ISO/IEC 9995-9 cannot be implemented natively on Microsoft Windows; it requires a third-party add-on package such as Keyman, which is not free. I don't understand this remark. Microsoft Windows is not free, so what does it matter whether there's a free addon or not? Users and companies often aren't inclined to pay extra for third-party solutions to problems that are generally perceived to be part of the operating-system domain, such as keyboard layouts. If ISO/IEC 9995-9 becomes a standard, then Microsoft will presumably support it, either themselves or by buying Keyman. Or they could revamp their keyboard model to support multiple dead keys and a fifth (and beyond) shift state, and produce (or commission) physical keyboards with more keys so users could get into those shift states. But those don't exist today (and Michael Kaplan has blogged often about the difficulty of changing this model), and meanwhile Karl's comment seemed to be that support for U+20B9 existed *today* in the ISO/IEC 9995-9 draft. Changes in standards don't always translate to commercial support. I never did find a pre-packaged Windows layout for the common secondary layout of ISO/IEC 9995-3:2002 (which the new version proudly dubs outdated, though the difference seems to be more a matter of less complete vs. more complete than old-fashioned vs. modern). If they don't, then there are other operating systems. Users often don't get to pick their platform, especially in a corporate environment, and especially for reasons like keyboard support for a single new character. Defects in one OS have no relevance for standards - although they may be a pain for a little while (e.g. Linux' rather slow support for Unicode). Anand Kumar Sharma didn't specify a particular vendor, but he asked about the key position when new keyboard with rupee symbol will come into market. He did use the term U.S.-English keyboard, a term I suppose is used by all vendors, not just Microsoft. Since changes in standards don't always translate to commercial support, I answered in terms of a vendor I was familiar with. Users of other platforms may have different stories. -- Doug Ewell | Thornton, Colorado, USA http://www.ewellic.org | @DougEwell
Re: [OT] Re: Exact positioning of Indian Rupee symbol according to Unicode Technical Committee
Karl Pentzlin wrote: As said in an earlier posting, the part 9995-9 is now in DIS, which means that its final version will be published 2013 or 2014. Thus, national standards referring to this part will hardly be published before 2015. Thus, there is enough time for any manufacturer of operating systems or third-party software suppliers to announce their support of any keyboard layout compliant with a standard referring to ISO/IEC 9995-9. Again, just speaking about one platform (Windows) that seems to be in somewhat common use, the problem is that the underlying architecture doesn't support multiple dead keys on a single base character, nor does it support a fifth, sixth, etc. shift state (unless one chooses to be reckless and use Ctrl). This is unlikely to change in the next two to three years. It isn't a matter of providing a layout—otherwise, anyone with MSKLC and a supported Windows version could create one. The fact that Microsoft until now does not support ISO/IEC 9995-3:2010 Complementary layouts of the alphanumeric zone of the alphanumeric section, which is required e.g. by the German standard DIN 2137:2012 to be published in June, is a different issue. Microsoft can never support ISO/IEC 9995-3:2010 unless they change their keyboard handling architecture, as above. -- Doug Ewell | Thornton, Colorado, USA http://www.ewellic.org | @DougEwell
