[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-25 9:55:19
[Download RAW message or body]


> On Monday 24 March 2003 16:06, Bharathi S wrote:
> (please keep the CC to Lars when answering, I don't think he reads
> koffice@)
>
> > On Mon, 24 Mar 2003, Lars Knoll wrote:
> > > yeas, I can give a short comment. Qt-3.2 will have native support
> > > for indic languages (only devanagari and bengali are implemented
> >
> > May be for Unicode only. But We are having lot of internal encodings.
> > So We like to provide a encoding independent solution. Anyway it
> > need some rule files for each encoding stds.

No, it doesn't. Unicode encodes everything you need to render indic languages, 
and I am not willing to add other proprietary encodings to Qt or KDE. Yes, if 
you mix up the difference between character (a letter of the language) and 
it's representation on the screen (the glyphs used to render the character) 
Unicode might seem like it doesn't fit. But as I said: It _does_ have 
everything you need to encode indic text. A rendering engine in combination 
with open type fonts (or other fonts that encode the glyphs in some way) can 
then be used to get the text rendered correctly on the screen.

There is lot of material available that is encoded in some prorietary indic 
encoding. For these you can write QTextCodec classes to make it possible to 
convert from these encodings to Unicode and back.

> Internally (in memory) we (Qt, KDE and KOffice) _always_ use Unicode.
> If you mean encoding as in "what's in the file", that's still unicode for
> KOffice; if you mean it as "font charset", Qt is clever enough to find the
> right font and convert to the right charset.
> Or are you talking about something that Unicode can't express?? Oh I see
> something related to this, below...
>
> > > 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.
> >
> > qt/src/kernel/qfont_x11.cpp : Line 622
> > XCharStruct *getCharStruct( .. )
> >
> > In QT, I tried at the above level, by using simple substitution table
> > b/w encoding and glyph. Cursor position is calculate correctly, after
> > hard coding few of spl combination. But I am unable to handle the
> > cursor movement, particularly when
> > XY /WXY (multi) MAP-TO Z (single).

Please: Wait for Qt-3.2 beta, test it with the free RagHindi font and then 
come back with what you think is missing.

> > AFAP, We like to make our solution as a ToolKit independent solution.
> >
> > > Once the 3.2 beta is out, I'll be willing to help getting these
> > > integrated.
> >
> >   Thanks :)
> >
> > > Unicode values, actually, stored in the case of any KDE application
> >
> > [ Not Sure ] Unicode is provide very less no .of slots for Indic and
> > at time we can use any one of the Indian language. So we are planning
> > for a 16Bit encoding which will cover all Indian language and few
> > other mostly used languages.

You are talking about some proprietary encoding that encodes glyphs again and 
not characters. We won't support this, as it will lead us back into the hell 
from which Unicode is starting to free us.

And: It's not needed. Devanagari has not much more letters than the latin 
alphabet, so Unicode is enough to unambiguously store a stream of text. 
Rendering of this text is however very complex, but this problem has been 
solved already with the usage of open type fonts and some rendering 
technology in the toolkit. Qt-3.2 is going to adopt this technology, building 
on open standards.

If you talk about transliterating from eg. Devanagari to Bengali, then Unicode 
already offers you an easy way to do it (as all indic scripts are encoded 
similarily): Just add a certain offset (in this case 0x80) to all characters 
and your transliteration is done.

> Ouch.
>
> > > > 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.
> >
> > This is input problem, ONLY when the application is working in GLYPH
> > Based method. If App is running in Encoding method then App will store
> > only the encoded codes and we have to render it on output side. By
> > using this feature we can view the same content in different indic
> > languages.

It is IMO correct that different indic scripts are encoded at different 
locations in the Unicode standard (only this makes it possible to eg. mix 
devanagari and bengali text). As I pointed out above transliteration is 
mostly trivial, and can be easily done with some helper classes.

> > > > Or should the application never be allowed to put the cursor
> > > > between X and Y in "WXYZ" ?
> >
> > No. If App(s) uses some std Cursor API (From XLIB or Developer Std) to
> > draw the cursor then, I hope, it will be very to calculate the new
> > position externally and *UPDATE* the application with new values.
>
> I don't think this is solvable at the Xlib level at all. The current
> solutions for all this kind of problems (e.g. arabic shaping etc.) are done
> in Qt. So if Lars says there will be code in Qt 3.2 for this, this part of
> the problem is solved.

You're mixing up things here. The X cursor API has _nothing_ to do with cursor 
(or better caret) movement inside a text input widget. X cursor is the mouse 
cursor.

Lars

PS: Please CC me on answers, I'm not on the koffice list.

____________________________________
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]