From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Sat Apr 12 2003 - 09:53:52 EDT
Hi Andrew,
> I'm doing this at the moment but there is a problem
> with doing things this way. A language per se doesn't
> have a direction - a script may have one or more
> directions and a language may have one or more
> scripts.
> This won't matter for the obvious langugaes but a few
> languages in Central Asia have recently moved between
> Arabic script and either Latin or Cyrillic script and
> thus could be either LTR or RTL depending on which
> script is being used. Since AbiWord doesn't have a
> way to differentiate between which script a language
> is using at a given place within a document there is
> no way to know.
> A much more obvious problem is with Chinese, Japanese,
> and Korean - all of which are commonly written both
> horizontally and vertically.
>
> Why can't the characters themselved determine this?
This is not intended for doing "serious" layout, in this regard I am
determined to stick to the Unicode specs. Rather, I am using these
values in emulation of some M$ Word behaviour; basically M$ Word
employs a proprietary bidi algorithm that uses the language
information associated with a text to force strong directional
properties on neutral characters. For instance, character like '('
will behave as strong LTR if the user enters it with en-US keyboard
layout, but strong RTL if the user enters it with he-IL keyboard
layout. The same applies to other neutrals. This behaviour, non-
standard as it might be, often makes good sense, for instance with
the brackets, but also as I recall, with phone numbers: it was one of
the issues that was raised by the Israeli users from very early on.
So, I want to provide a preference based emulation of some of this
behaviour, and for that I need a way for translating the language
info to a direction; the ut_Language class was a convenient place to
put it, particularly as the all the search functions are already in
place.
Since we currently do not support vertical layout, the
UTLANG_VERTICAL value is really supperfluous for now anyway, just
thought it should be there for the sake of completion. For CJK we
should probably enter a value that corresponds to the kind of layout
we do.
> I'll make the changes anyway but as long as you know
> the limitations of this system now.
Thanks Andrew.
Tomas
This archive was generated by hypermail 2.1.4 : Sat Apr 12 2003 - 10:04:52 EDT