A scheme

users
#1

What I suggest is that an user first select what range of unicode they want
to type in, and then the software present them with all fonts and unicode
fonts on the system that support that range. So one box will say "choose
language or script," (ie. choose unicode range) and the other will say
"choose font." Of course, this effort means that we need to figure out
which fonts support which unicode ranges, and put in all free unicode fonts
in the package. It's not a far fetched idea either, LibreOffice does come
with Linux Libertine and Liberation fonts.

There are characters that transcend unicode range boundaries, like
quotation marks, dashes, and question marks that need to be accounted for
if the plan is implemented.

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. Fortunately, there is a global user base that can
contribute to this.

Because of the above, ackaging support for all scripts and languages could
cause the package to be quite big. I find two approaches to deal with this.
First, we can ship different packages for different languages. Also, we can
allow the user to select which languages they want to put into the package,
the way OpenSuSE allows for the creation of a distro with the packages they
choose.

The option should actually say "choose language or script," since people
will be choosing only that when they both download and use the app.

Thanks all.

#2

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.