Re: Problem with xkb

Subject: Re: Problem with xkb
From: Vlad Harchev (
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
  Here is the declaration:

class XAP_EncodingManager
    /*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();

    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,

This archive was generated by hypermail 2b25 : Tue Sep 26 2000 - 01:24:44 CDT