Subject: Re: Problem with xkb
From: Vlad Harchev (hvv@hippo.ru)
Date: Tue Sep 26 2000 - 01:10:19 CDT
On Tue, 26 Sep 2000, Martin Sevior wrote:
> On Mon, 25 Sep 2000, Vlad Harchev wrote:
> >
> > My quick analysis of abiword and already existing hackish solution to allow
> > input of cyrillic in it brings the following notes and questions:
> >
> > 1) AW holds all characters in unicode. But currently the code works only for
> > latin1 symbols since there is no explicit recoding from/to encoding of
> > current locale, that is needed in following cases:
> > 1.1) when text is typed in - the characters should be converted from
> > current locale encoding to unicode. Same when pastingfrom
> > clipboard.
> > 1.2) when text is drawn out - the unicode text (from internal
> > representation) should be converted to text in current locale
> > so that XLib will choose correct glyphs from the font. Same for
> > cutting to clipboard.
> > 1.3) The text that is input into dialogs like "Find" - it should also
> > be converted to unicode (so that unicode text will be searched
> > for, notin current locale's encoding).
> > 1.4) When printing - unicode text should be converted to font's
> > encoding.
> > 1.5) When exporting/importing - but that's another story.
> >
> > For cyrillic and some other sripts that has few letters in them like english
> > (obviously, Japanese doesn't fall into this category) it could be much more
> > attractive to have internal prepresentation of the document contain text in
> > current locale's encoding (but still using wide characters). If you are going
> > to support all languages in the world, the text internally should be stored
> > in unicode, but all necessary conversions mentioned in 1.1 - 1.5 are
> > necessary.
> >
> > As for fonts - since fonts are used both for display and printing, it's
> > impossible to have fonts that contains glyphs for letters for different
> > languages (like arabic, greek, cyrillic, latin). So, there is a need to
> > 2.1) Provide separate font file of the same family for each
> > encoding/language used (the XLfds of these fonts will differ only
> > in last component - encoding name).
> > 2.2) Make AW load only one font of the given family and style, with
> > encoding corresponding to current locale's encoding (i.e. from the
> > set of fonts with lfds differing only in last component the proper
> > one must be loaded - the one that corresponds to current locale).
> > 2.3) When printing, text in internally used encoding should be
> > converted to text in font's encoding.
> >
> > As for me - I'm going to implement most items listed (1.1 - 1.4 and 2.1 -2.3
> > and probably 1.5) and add cyrillic fonts in koi8-r encoding. Implementing
> > all this IMO will lead to correct support for input and display of text in
> > any language. Probably printing CJK (chinese, japanese, korean) texts won't
> > work since AW assumes that there are only 256 symbols in font encoding.
> >
> > Any comments?
>
> >From my limited understanding of X11 Fonts and unicode this all appears
> neccessary. I finally see some of the problems. If X11 gets a Unicode
> string with codes not defined in the last element of the lfd X11 complains
> and Abi crashes. Your changes will fix this.
Also there are asserts on keyval checking that its value is < 256 - I didn't
inspect where it crashed since I plainly fixed the problem.
I should say that I'm 70% completed the patch. The remaining things are to
finish fixing printing and exporting to/from RTF.
The apporach I used is the following:
1) The characters stored internally are in unicode
2) I've added XAP_EncodingManager class to
src/af/xap/xp/XAP_EncodingManager.{cpp,h}
Here is the declaration:
class XAP_EncodingManager
{
public:
/*this shouldn't return NULL. Don't free or write to returned string. */
virtual const char* getNativeEncodingName() const;
virtual UT_UCSChar nativeToU(UT_UCSChar c) const;
virtual UT_UCSChar UToNative(UT_UCSChar c) const;
virtual ~XAP_EncodingManager();
XAP_EncodingManager();
static XAP_EncodingManager* instance;
};
It has no pure methods so there is no need to implement it for each platform.
The implementations of these methods are trivial (just return 'c').
I've added a 'XAP_EncodingManager* p_EncMgr' to XAP_App
Now most part of i18n is to call .UToNative() or .nativeToU() in proper
places (of course, other modifications are required).
I expect to have fully i18ned AW for tonight, but I don't know when I will
clean up it and post patches.
> I'm looking forward to seeing this patch! This has been a long standing
> problem.
I hope you will be willing to integrate it too :)
> I hope to have another look at printing after the Fields are done.
>
> Cheers
>
> Martin
>
>
Best regards,
-Vlad
This archive was generated by hypermail 2b25 : Tue Sep 26 2000 - 01:24:44 CDT