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
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
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
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: firstname.lastname@example.org
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
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy