Bug 318071

Summary: [kn_IN] consonant + Halant + Consonant is wrongly rendering
Product: [Fedora] Fedora Reporter: Shankar Prasad <svenkate>
Component: lohit-fontsAssignee: Rahul Bhalerao <b.rahul.pm>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: rawhideCC: ankit, bugzillas+padREMOVETHISdu, eng-i18n-bugs
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-02 14:13:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Few examples of the consonant+halant+consonant none

Description Shankar Prasad 2007-10-04 10:56:16 UTC 
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 10:56:16 UTC 
Created attachment 215671 [details]
Few examples of the consonant+halant+consonant
Comment 2 Jens Petersen 2007-10-23 04:54:39 UTC 
Presumably this is not fixed yet in F8?
Comment 3 Shankar Prasad 2007-10-23 07:02:35 UTC 
No, the problem still persists in the f8 too.
Comment 4 Rahul Bhalerao 2008-04-02 14:12:57 UTC 
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 21:12:25 UTC 
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?

Thanks!
Comment 6 Padmanabhan V. K. 2009-01-06 23:28:09 UTC 
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.