On Mon, 2004-04-05 at 00:06 +0530, Anirban Biswas wrote: > Hi > > > Can you verify whether this is the case with other Indic languages too? > > (I can supply you with Devnagari text if you want). > > Of course I can but then pls send me fonts or links from where I can download > them. >
here's some hindi text àààààààà ààààààààà àà ààààààà ààààà àà ààààà àààààààààààà àààààààà àààààà ààààà ààààààà àààààààà àà ààààà àààààààà àà, àà:ààààà ààààààààà ààà àààà àààààààààà àà àààààààààà àà àààààà àààààà àààààà àà ààààààààààà ààààààààààà àà ààà àààààà àà ààààà àààààà àààà| àà àààààààà àà ààààààà ààà ààààààààà àààààà àà, ààààààà (UNICODE) ààà ààààà (ISCII) ààààà àà àààààà àààà ààà àààààà àààààààà ààààààà àà ààààà àààààààà àà ààààààààà, àààà 12 ààààà àààààà àààààà àà àààà àààààà àà àààà, ààààààà, àààààà ààà àààààà àààà àà ààà| àà 12 àààààà àà àààààà, ààààà, ààààààà, ààààà, ààààà, àààààà, ààààà, ààààà, àààààà, ààààààà, àààà àà àààààà| ààààààà àààààààà àà àààà ààà ààà àààààà ààààààà, ààààààà ààààà àààà, àà ààààààààà àà àààààà ààààà àà ààààà àààààààà àààà ààà| Font can be downloaded from http://www.indictrans.org/src/fonts/Gargi-1.1.ttf > > Hmm... that was my thoughts - I have seen similar cases with GTK based > > apps too. Width calculation can be tricky sometimes - and things really > > look ugly when you try to place glyphs on screen on the basis of these > > wrong calculation results. ;-) > > I think width is getting calculated correctly but the proble is with cursor > position. But not sure cause I am still unable to debug the code properly I > am depending only on the values printed on the konsole due to kdDebug() funct > [actaully it work like printf() or cout ] what I do while debugging is do a g_print() or a g_warning() and try comparing the glyph position with the width at each iteration (and try to get an idea of what is wrong from the offset) - maybe you would want to to do the same with cursor position/width. > > > > And I have heard (not verified) that this thing also happens with > > Koffice - so this does seem to be a system wide issue (unless > > koffice/kate share cut-paste code ;-) > > Can you verify with kedit/kword ? > > The code responsible for the problem is kdelibs/kate/part as the name suggest > this code is generally get reused in many kde apps so you will have problem > there also. ok - goody. > > the kdelibs/kate/part is shared by kate , kwriter so both of them has same > problem. > > On the other hand kediit has same problem too but same bengali word do not > cause the problem. For example when I typed Sukanta on Kate it gives problem > but not in kedit. On the other hand kedit cause probelm when typed > Battacharejee. > Do both use kate/part ? > There are a few other issues with QT (somehow it cannot display the > > daanri/double daanri), and the ekaar/aikaar has some issues (the "init" > > form is displayed in all cases, whereas the init form, according to > > current typographical convention, as well as according to the published > > specs from Microsoft, is only used if ekaar/aikaar is attached to the > > cluster at the beginning of a word. > > I shall try to regenerate the above issues for Qt. here's some text that should help (don't get offended - this is our unofficial "hello world" for Bangla ;-) ààààà àààà ààààà à try copy pasting into any plain and simple qt editor - and see what happens - the expected rendering with Gedit is at http://clai.net/sayamindu/images/bn_helloworld.jpg (use MuktiNarrow.ttf) Note how the initial portion of the oukaar of ma does not have a matra, while that of the oukaar applied to da has a matra. In QT, both of them have the matra missing. The code in this case is where[0] = TRUE; openType->applyGSUBFeature(FT_MAKE_TAG( 'i', 'n', 'i', 't' ), where); The rules for the init feature are as follows: <quote copyright="Microsoft"> Initial form Feature Tag: "init" This feature takes nominal (full) forms of consonants and produces initial forms when the glyph is at the beginning of a word: Cf -> Cf-init The initial form displays a glyph variant form that does not have a connecting bar on the leading side of the glyph. All initial forms must be based on an input context consisting of the full form of consonants. As a user types each character, the text-processing application will reshape the glyph or glyph cluster. </quote> I don't think QT is checking whether the glyph is at the beginning of the word, most probably, it is checking whether the thing is at the beginning of a cluster or a syllable. But I don't know anything about C++, and I looked at the code for just around a minute - I may be wrong. -thanks- Sayamindu PS: btw, now that I think about it, the specs for init does not appear to be remarkably clear - especially to someone who is not familiar with our script - Deepayan - should we file a bug with Microsoft (Paul Nelson & friends ??) -- To unsubscribe, send mail to [EMAIL PROTECTED] with the body "unsubscribe ilug-cal" and an empty subject line. FAQ: http://www.ilug-cal.org/node.php?id=3
