Re: [Indic-computing-devel] Re: [Kannada] A few kannada bug fixes to qt-3.2.1

[Arun S. <ar...@sh...>]

Krishnamurthy Nagarajan wrote:

> Hi Arun,
> 
> The fundamental issue is that the glyph composition
> and rendering logic is 'hardcoded' in C code of each
> application, that to for a 'given' font. 

Agree that the logic is hardcoded in the libraries (pango and qt), 
without an extensible plugin. But I'm not sure that the logic is font 
specific. It should work with any opentype font for a given script, as 
far as I can see it.

> A more
> broad-based approach would be to provide generic X
> input methods for Indian languages.

Given the difficulty of getting my parents to learn the inscript 
keyboard, I think this is definitely important. If you read the 
archives, I've not been fan of implementing logic in client side 
libraries or even client side fonts in general.

So any approach with a X server side solution with X protocol extensions 
is what I like the best. But the client side does need modifications to 
understand Indic syllables for proper text editing.

But in the short term, qt and pango are the way people are going to do 
Indic computing. So I thought I'd fix up a few bugs during the weekend :)

> Tamil), with all the complexity in the rules (given in
> a text file to the translib library) and zero C code
> that is specific to any language/script, I am
> convinced that 
> any language/script specific peculiarities (like the
> reph case in Kannada, split vowel signs in Devenagari
> and Tamil, multiple representations for the same input
> etc etc) can be handled without any special coding at
> the app level (gnome, qt or whatever).

Interesting. Thanks for the pointer. Will take a look at it this week.

	-Arun