Re: Problem with xkb


Subject: Re: Problem with xkb
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Mon Sep 25 2000 - 20:35:20 CDT


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.

I'm looking forward to seeing this patch! This has been a long standing
problem.

I hope to have another look at printing after the Fields are done.

Cheers

Martin
 



This archive was generated by hypermail 2b25 : Mon Sep 25 2000 - 20:35:35 CDT