Hi Hashao,
thanks for your comments.
> On Sun, Mar 04, 2001 at 09:17:30PM -0000, [EMAIL PROTECTED] wrote:
> > The TextRun is internally unicode, so that it is, and I think should
> > remain, ignorant of any font-design issues (which is what this is
> > really about), and the associated encoding problems; we will
> Well, language attribute is font related too. In unicode, ideograph
> of Chinese, Japanese, Korean (so called 'unihan') are mapped to the same
> code points. But the actually shape of some glyphs are subtly different
> among the 3 languages although they looked similar.
This is really a different issue from the problem I have referred to.
The CJK problem has to do with appearance of glyphs with the
same code points and unicode values, and this should be handled
using 'language' property of a run. The problem of multilingual
documents under 8-bit locale cannot be resolved by a language
property in the same way, because it has to do with conflicting
encodings, with the fact that under and 8-bit locale there are only
256 characters available to you. To be able to resolve it you have to
move away from 8-bit based drawing to 16-bit drawing or wchar_t
drawing.
> I would think when locale is added to text run, abiword should check
> for the locale and then draw text with the suitable locale using
If by locale you mean encoding information, then locale attribute
should *under no circumstances* be added to text run; doing so
would defeat the very reason why our text runs are Unicode (so
that they would be locale independent). Adding language
information by all means, but nothing to do with encodings.
> CJK text drawing in abiword use fontset, so I don't know how much
> work it is to add this to 8bit encoded text. For gtk, you just
> load_fontset instead of load_font, gtk will handle the rest.
There is no point adding this to 8-bit encoded text, 8-bit encoded
text cannot represent more than 256 chars no matter how many
glyphs there are in the fontset (perhaps you are forgetting that with
CJK you use multibyte strings). What is required is to move away
from the 8-bit drawing functions before fonts are replaced with font-
sets. With gtk this, if I am not mistaken, would mean moving to the
wchar_t functions, but we do not use wchar_t, nor is wchar_t
particularly portable because ANSI does not say how big it should
be. Further, XAP_UnixFontSet would need to be written, at some
places in our code replacing XAP_UnixFont and at others not
(since sometimes we want the fontset appearing as a single 'font'
and sometimes we have to deal with the actual font within the set);
the PS code would have to be rewritten, etc. There is more to it
than meets the eye.
Best regards, Tomas
