Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 202161 - [ml_IN] Issue with (U+0d30) and (U+0d31)
[ml_IN] Issue with (U+0d30) and (U+0d31)
Product: Fedora
Classification: Fedora
Component: fonts-indic (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rahul Bhalerao
: i18n
Depends On:
  Show dependency treegraph
Reported: 2006-08-11 01:41 EDT by Ani Peter
Modified: 2016-07-31 21:30 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-27 08:16:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Pango patch attached (497 bytes, patch)
2006-08-11 08:16 EDT, Darshan Santani
no flags Details | Diff
Font Patch attached (431 bytes, patch)
2006-08-11 08:18 EDT, Darshan Santani
no flags Details | Diff
Verified Image (2.26 KB, image/png)
2007-04-27 08:15 EDT, A S Alam
no flags Details

  None (edit)
Description Ani Peter 2006-08-11 01:41:06 EDT
Description of problem:
In the present Malayalam font, for the special combination of :
Any consonant + (U + 0d4d) + (U+0d30) = we get a new glyph with a symbol on the
right side of the consonant, which actually must be on the left side. ie, the
symbol should be before the consonant used.

Also, in the actual malayalam script, for this particular combination, 
we have to use (U+0d31) instead of (U+0d30)
 ie, we must get the above mentioned glyph when  we use:

Any consonant + (U + 0d4d) + (U+0d31). Due to some unknown reasons or ignorance
there are some using (U+0d30) in the community. But I request to change this to
(U+0d31) which is the actual one and hence we shall not follow the same mistake
like others. If at all any questions from community, we can prove this by siting
 word examples.
Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open kedit
2. Type any consonant
3. Type (U+0d4d)
4. Type (U+0d30) (according to our present font)
Actual results:
On doing the above steps, we get a new glyph with a symbol after the consonant

Expected results:
but the symbol should have been before the consonant

Additional info:
Comment 1 Darshan Santani 2006-08-11 08:02:45 EDT
Ani, the first issue ie, "Any consonant + U+0d4d + U+0d30" has already been
fixed in the latest release of Pango ie, pango-1.14. Please refer the following:


Comment 2 Darshan Santani 2006-08-11 08:13:44 EDT
And, regarding the second issue ie the combination "Cons + U+0d4d + U+0d30" has
to be replaced with this combination "Cons + U+0d4d + U+0d31", I am enclosing
the following 2 patches:

1. Pango patch
2. Font patch
Comment 3 Darshan Santani 2006-08-11 08:16:57 EDT
Created attachment 134013 [details]
Pango patch attached

Patch about the conjuctions of "Con + 0d4d + 0d31" instead of "Con + 0d4d +
Comment 4 Darshan Santani 2006-08-11 08:18:12 EDT
Created attachment 134014 [details]
Font Patch attached
Comment 5 Darshan Santani 2006-08-11 08:20:47 EDT
Lizhang, Can you please test the above patches ?  
Thanks in advance.
Comment 6 Liang Zhang 2006-08-14 05:32:49 EDT
I filed a new bug to Pango, and I wrote a patch for this bug.
The bug is:
I tested it, and this patch of the font file is OK.
Comment 7 Rahul Bhalerao 2006-08-14 07:02:45 EDT
In 'Steps to reproduce', its said 
'1. Open *kedit*'

*kedit* does not use Pango. Thus Pango patch may not work for kedit or any KDE/QT
application. Lizhang, can you please confirm this.

IMHO the bug needs different fix for QT if implemented within the rendering
A Font patch should work on both the engines. :)

Comment 8 Liang Zhang 2006-08-14 21:39:16 EDT
yes, kedit uses qt, doesn't use pango.
But I used a demo of pango to test it, the bug about 0x0d31 is existing, so I
wrote a patch for it.
Comment 9 Leon Ho 2006-08-17 03:19:40 EDT
built in fonts-indic-2.0.1-1
Comment 10 Ani Peter 2006-08-31 09:28:55 EDT

Before Darshan leaving , we had discussion on this and had decided to go  with
the correct combination instead of using the wrong one existing in the community.

Hence, any consonant + (U+0d4d) + (0d31) must give a glyph with a symbol on the
left side of the consonant and
 Any consonant + (U+0d4d) + (U+0d30) must be just the key sequence .

But what happens in the current font is,
-any consonant + (U+0d4d) + (0d31) gives the output as according to the key
sequence and
-Any consonant + (U+0d4d) + (U+0d30) gives the output wrong and not even in the
key sequence, there exist a rendering issue with this. ie, its printing in the
order (U+0d30),(U+0d4d) and any consonant which is absolutely wrong

Comment 11 Ani Peter 2006-08-31 09:38:49 EDT

If at all we want to use what is existing in the community, then we can have the
option that:

any consonant + (U+0d4d) + (0d31) must give a glyph with a symbol on the
left side of the consonant and 
Any consonant + (U+0d4d) + (U+0d30) when used this with (U+200d) can result the
above glyph. 

This is what I suggest and if at all any question from community can ba handled.

Comment 13 Lawrence Lim 2006-09-28 22:26:05 EDT
Which group (Pri A, B, or C) does this bug belong to??
Comment 14 Rahul Bhalerao 2006-10-03 09:27:05 EDT
It is Priority A bug.  It has been fixed by the patches submitted on bug
#208198, cloned as #209095.
Comment 15 A S Alam 2007-04-27 08:15:48 EDT
Created attachment 153612 [details]
Verified Image
Comment 16 A S Alam 2007-04-27 08:16:50 EDT
Bug is verified with following package:

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