Samiur: Regarding your statement: "Also, all the rules on how compound characters are formed through keyboard commands and how characters are joined have to be now dealt with by the office application."
Strange as it might seem, I think that having such things handled by the office application is part of the problem we now face with multi-lingual computing (which is what I believe the objective should be). Allow me to explain: back in the "old days" WordPerfect dominated the word processing world, on ALL platforms, and there were many more of them than there are now. One (of many) reasons for this was their absolutely unparalleled support for almost every printer that existed (and, other than ASCII codes, there were very few "standards" then). This was necessary for them to do. Period. In the long term however, this meant that each application that wanted to support a variety of printers also needed to add their own printer drivers. Even as we were all used to this by the time the 1990s rolled around, it was unpleasant, annoying and inefficient. Then Microsoft (although not the first to attempt this, they were the first with the market clout to force the change) put printer driver support in the operating system. All Windows applications could support the same printers. Wow! Nirvana. Their initial support was nowhere near as good as WordPerfect's was in terms of access to features and so forth, but that rather quickly changed. There is a similar situation with what you refer to as "compound characters" and joining characters - particularly important in scripts such as Arabic and Hebrew to name just two. As I write this, font technology is at a state where all of this can be (and often is) defined within the font itself. With most of the fonts I commonly use, such things as character modification, compound characters, text direction, placement of modifiers and so forth work quite well even at the command line or in a simple text editor. In more and more cases, I find that Writer actually interferes with the proper layout of text written with those fonts. Much of the whole CTL and related schemes actually date back to the days when WordPerfect dominated word processing. My own opinion is that we should be moving forward to having character support at as low a level as possible - so that any application can be (or more easily be made to be) language/script neutral. Some application classes (and certainly word processors are one of these classes) need to be very aware of these issues because of their specialties (one doesn't normally attempt to justify their shell/batch scripts for instance), but support for scripts and languages should move to the lowest/most common level possible in order to move the world of computing forward. It can be - and likely will be - disruptive (just as the switch to common printer drivers was), but will ultimately allow for a better user experience. Likewise, I hope (but don't really anticipate) a standardization of input method editors across operating systems. Having used a few of these over some time, I'm surprisingly happy with the state of the one I'm using currently combined with the up-to-date font technologies I'm using currently. Have a great day and keep pushing/exploring. -- View this message in context: http://nabble.documentfoundation.org/A-scheme-tp4187966p4187975.html Sent from the Users mailing list archive at Nabble.com. -- To unsubscribe e-mail to: [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
