Bug 318071 - [kn_IN] consonant + Halant + Consonant is wrongly rendering
[kn_IN] consonant + Halant + Consonant is wrongly rendering
Product: Fedora
Classification: Fedora
Component: lohit-fonts (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Rahul Bhalerao
Fedora Extras Quality Assurance
: i18n
Depends On:
  Show dependency treegraph
Reported: 2007-10-04 06:56 EDT by Shankar Prasad
Modified: 2015-04-21 00:34 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-02 10:13:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Few examples of the consonant+halant+consonant (13.16 KB, image/png)
2007-10-04 06:56 EDT, Shankar Prasad
no flags Details

  None (edit)
Description Shankar Prasad 2007-10-04 06:56:16 EDT
Description of problem: In almost of all the cases consonant+halant+consanat is
wrongly rendering.

Version-Release number of selected component (if applicable):

How reproducible: Every time

Steps to Reproduce:
1. Open gedit (Or any writer)
2. Activate SCIM
3. Select SCIM-inscript
4. Use the inscript key sequence as shown in the attachement

Actual results: Shown in the attachment

Expected results: Shown in the attachment

Additional info: This was solved for some cases via bug #228976, in which the
second example of the attached image depicts the similar issue and has been
solved. The same needs to be applied for all the combination.
Comment 1 Shankar Prasad 2007-10-04 06:56:16 EDT
Created attachment 215671 [details]
Few examples of the consonant+halant+consonant
Comment 2 Jens Petersen 2007-10-23 00:54:39 EDT
Presumably this is not fixed yet in F8?
Comment 3 Shankar Prasad 2007-10-23 03:02:35 EDT
No, the problem still persists in the f8 too.
Comment 4 Rahul Bhalerao 2008-04-02 10:12:57 EDT
This is not possible in the current opentype framework, also it will be, if
possible, fixed in Layout engine first.
Comment 5 Padmanabhan V. K. 2009-01-04 16:12:25 EST
A similar issue exists in Lohit Telugu fonts as well.
I think the attachment 215671 [details] shows the following combinations:

1. U+0C97 U+0CCD U+0CB0 U+0CCD
2. U+0CAA U+0CCD U+0CB5 U+0CCD
3. U+0CAC U+0CCD U+0C97 U+0CCD

Analogously Telugu combinations can be formed which are rendered incorrectly by Lohit Telugu along the same lines:

1. U+0C17 U+0C4D U+0C30 U+0C4D
2. U+0C2A U+0C4D U+0C35 U+0C4D
3. U+0C2C U+0C4D U+0C17 U+0C4D
(subtracting 0x80 from each character)

However there is another OpenType font that is able to render these Telugu combinations correctly -- Pothana2000 from http://www.kavya-nandanam.com/dload.htm (Googling shows A few other Linux distros are currently shipping this font).

Will it be possible to use whatever technique that font uses, to fix the issues in Lohit Kannada and Lohit Telugu? Or does "current opentype framework" in comment 4 mean a restricted framework that precludes fonts like Pothana2000?

Comment 6 Padmanabhan V. K. 2009-01-06 18:28:09 EST
Bug 227971 is the same issue. Looks like only some specific combinations which are shown in the attachments to that bug have been fixed (LA+halant+LA+halant, DA+halant+DA+halant, JA+halant+NYA+halant, KA+halant+SSA+halant). May be other combinations could be fixed similarly.

However it looks like that fix defined separate conjunct glyphs for L+LA, D+DA, J+NYA and K+SSA as well as these followed by various vowel signs which brought about other side effects in rendering consonant+halant+consonant+vowel sign (except vowel signs U, UU and AU). For example, in KA+halant+SSA+sign O the SSA is rendered below KA rather than the "O sign" unlike other combinations of consonant+halant+consonant+vowel sign. I am not sure which is more acceptable in Kannada.

Note You need to log in before you can comment on or make changes to this bug.