Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Dec 2000 19:46:27 -0800
From:      bstell@netscape.com (Brian Stell)
To:        i18n@XFree86.Org
Cc:        li18nux@li18nux.net, i18n@freebsd.org
Subject:   Re: [I18n] Restart: better XI18N future API
Message-ID:  <3A42CE93.98DC2305@netscape.com>
References:  <20001221.160155.125112926.hiura@Eng.Sun.COM>

next in thread | previous in thread | raw e-mail | index | archive | help

hiura@unicode.org wrote:

> It was unfortunate that we had the discussion much earlier, but
> it is not too late to design and implement the better solution.
> I'd like to thrust the gear to the forward to facilitate the XI18N
> future API design discussion by once resetting the Xutf8* discussion,
> but taking the useful information from our discussions from both of
> the pro-Xutf8* and the anti-Xutf8* side.
>
> First of all, there are a couple of limitations we are aware of which
> are missing from current XI18N API and we'd like to enhance in some
> form. One of the approaches presented for evaluation is Xutf8*
> functions.
>
> Here are the what I consolidated as important requirement from our
> previous discussion:
>
> #1. Thread safe multi-locale equivalent capability for X for the
>     applications willing to do the extra-things for I18N without
>     changing systems' global locale.
> #2. Processing the text in the different encodings from the encodings
>     set by the system's global locale, particularly in UTF-8.
> #3. Upward compatibility with the existing API, avoid unnecessary
>     duplication for the short circuiting.
> #4. Support multiple encodings including Unicode and legacy, provide
>     options for both users and *programmers* to chose which encoding(s)
>     to deal with, but no hardwiring to particular encoding.

What about glyph codes?

Some languages have characters that have different shapes (glyphs)
depending on the position relative to other characters (isolated,
beginning of word, middle of word, end of word).

Sometime fonts supply alternate glyphs for a given character based
on other factors such as modern vs archaic shape.

Some languages have ligatures.

How will the drawing APIs support this?

Brian Stell




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-i18n" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A42CE93.98DC2305>