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

List:       koffice
Subject:    Re: Cursor Movements (for Indian Language)
From:       David Faure <dfaure () klaralvdalens-datakonsult ! se>
Date:       2003-03-24 17:55:35
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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).
> 
> 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.
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.
> 
> > > 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.

- -- 
David Faure -- faure@kde.org, dfaure@klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+f0aX72KcVAmwbhARAoxlAJ0RT3tTpgg3m4MOVPr8Jl3gFFwSTACcCLlH
G9e8loR0+NMZYDvCsCpquHs=
=bhpk
-----END PGP SIGNATURE-----

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