[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: Cursor Movements (for Indian Language)
From:       Lars Knoll <lars () trolltech ! com>
Date:       2003-03-24 12:19:06
[Download RAW message or body]

Hi,

yeas, I can give a short comment. Qt-3.2 will have native support for indic 
languages (only devanagari and bengali are implemented currently, but other 
indic languages will be straightforward to add and only require modifications 
in Qt, not in KDE). To achieve this we've added support for open type fonts 
and implemented indic ayllable analysis and shaping rules in Qt.

There are two main problems with supporting indic languages. Rendering and 
cursor movement. Indic languages are syllable based, and do complex shaping 
and reordering of the characters within a syllable. The characters in the 
syllable are stored in "logical" order (ie the order you would pronounce 
them), while rendering might reorder this (move some characters to the front 
or do complex ligatures and shaping).

Cursor movement is more or less constrained to syllable boundaries (ie. you 
can't move your cursor into the middle of a syllable).

Koffice apps will get the shaping for free from Qt (if they use 
QPainter::drawText()), but restricting the cursor movement will require use 
of a few (one or two) methods that are currently internal to Qt.

Since koffice uses a modified Qt richtext engine, the modifications needed 
should be rather easy to copy from the Qt richtext engine. Once the 3.2 beta 
is out, I'll be willing to help getting these integrated.

Cheers,
Lars

> On Monday 24 March 2003 09:22, Bharathi S wrote:
> > On Wed, 12 Mar 2003, David Faure wrote:
> > > > Presently we are trying to providing Indian Language support for
> > > > Koffice Application.
> > > > Here Cursor positioning is the major problem, Bcoz of 1:2, 2:1,
> > > > *:* mapping b/w Encoding and Glyph.
> > >
> > > I don't know what those things are, obviously. Can you detail a bit?
> >
> > In English, 65 = A, 66 = B, ... . The application is storing the ASCII
> > values.
>
> Unicode values, actually, in the case of any KDE application
>
> > Here ASCII is nothing but a index for the glyphs. So app is
> > easily calculate the width and place cursor in correct position.
> >
> > In Indian Languages, for example, 65 = A, 66 = B. But B is followed by
> > A the output will be X / XAY / WXYZ ...etc. We like to handle this
> > mapping in output side (By Encoding to Glyph mapping). Here problem is
> > application know about 2 codes ( 65, 66), the output may be 1(X) /
> > 2(AB) / 3(XAY) / 4(WXYZ). This mapping is done by our intermediate
> > layer. So application don't know abt it and try to place the cursor in
> > a wrong position.
>
> This looks like an input method problem, not like a problem in the
> rendering. The application doesn't have to store "BA", it has to store the
> result, i.e. X / XAY / WXYZ.
> The intermediate layer needed is the input method, i.e. something that
> sends the right characters (unicode values) to the application.
>
> Or should the application never be allowed to put the cursor between
> X and Y in "WXYZ" ?
> Hmm, then we have indeed "several glyphs for a single character"....
> I haven't seen any support for this yet in Qt, but I could be wrong.
>
> Lars? Can you comment on this?
>
> > > Is it like the (Asian) XIM input stuff ?
> >
> > Combination XIM and XOM.
> >
> > XIM :( I tried that also, but I failed to successfully complete it.
> > Due to the lack of understanding. AFAIK, It also work based on Glyphs.
> > Plz correct me, if it is wrong.
> >
> > Thanks,
> > --
> > Bharathi S, IndLinuX Team,  (__)
> > DON Lab,      TeNeT Group,  oo )
> > IIT-Madras, Chennai-INDIA.  (_/\
> >
> > ____________________________________
> > koffice mailing list
> > koffice@mail.kde.org
> > To unsubscribe please visit:
> > http://mail.kde.org/mailman/listinfo/koffice

____________________________________
koffice mailing list
koffice@mail.kde.org
To unsubscribe please visit:
http://mail.kde.org/mailman/listinfo/koffice
[prev in list] [next in list] [prev in thread] [next in thread]