Bug 1016984 - [ml_IN] Unicode standard sequence for stacked chillu-N and RRA not supported in Lohit Malayalam
Summary: [ml_IN] Unicode standard sequence for stacked chillu-N and RRA not supported ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: lohit-malayalam-fonts
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pravin Satpute
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-09 06:00 UTC by Shriramana Sharma
Modified: 2014-04-14 07:22 UTC (History)
4 users (show)

Fixed In Version: lohit-malayalam-fonts-2.91.0-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-22 00:46:18 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Shriramana Sharma 2013-10-09 06:00:00 UTC
Description of problem:

As per TUS 6.2 chapter 9.9 p 321 (p 351 of PDF) the correct sequence to get the display of stacked chillu-N on top of RRA in Malayalam is: CHILLU N + VIRAMA + RRA. That is: ൻ്റ  = 0d7b 0d4d 0d31. However, currently Lohit Malayalam font does not support this sequence. 

Testing Lohit Malayalam and Google Noto Sans Malayalam with latest HarfBuzz git head shows that Lohit is not capable of rendering this sequence correctly whereas Noto is capable. 

Please fix it so that ൻ്റ  = 0d7b 0d4d 0d31 is correctly rendered as stacked chillu-N on top of RRA.

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

Comment 1 Pravin Satpute 2014-01-10 07:29:04 UTC
Ok, after some more work on it i understood it is classic "NTA" dual encoding issue. Introduced due to addition of atomic chillu.

Here i am in favor of providing backward compatibility and avoid dual encoding.


So we will keep with giving only one rule for NTA. i.e. 
u0D28 + u0D4D + u0D31 = NTA

and will avoid having this one.

do you aware any normalization from Unicode on this front?

Comment 2 Shriramana Sharma 2014-01-10 08:22:26 UTC
Hello Pravin. I would advise going by the standard. It was unavoidable that the chillu encoding would break some things and this was one of them. 

But if Lohit also continues to cater to the old system, then people will still continue to use it and not move to the current system at all, especially if you do not provide the current standard. "Backward compatibility" does *not* mean not moving forward at all! And always in software backward compatibility can only be provided to a certain extent, not permanently. 

The standard tells you to do 0D7B CHILLU_N + 0D4D VIRAMA + 0D31 RRA to get stacked chillu-N with RRA below. If one does not follow the standard, then what is the point in the standard?

If I am not convincing you, please ask on the indic@unicode list.

Comment 3 Pravin Satpute 2014-01-10 09:28:24 UTC
Yes, discussing on indic@unicode is more important.

Comment 4 Pravin Satpute 2014-01-13 09:09:41 UTC
Will fix this in next release of Lohit Malayalam.

Comment 5 Fedora Update System 2014-02-05 06:01:26 UTC
lohit-malayalam-fonts-2.91.0-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/lohit-malayalam-fonts-2.91.0-1.fc20

Comment 6 Fedora Update System 2014-02-06 03:59:26 UTC
Package lohit-malayalam-fonts-2.91.0-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing lohit-malayalam-fonts-2.91.0-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-2078/lohit-malayalam-fonts-2.91.0-1.fc20
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2014-02-22 00:46:18 UTC
lohit-malayalam-fonts-2.91.0-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Shriramana Sharma 2014-04-06 05:49:52 UTC
(In reply to Pravin Satpute from comment #1)
> Here i am in favor of providing backward compatibility and avoid dual
> encoding.
> So we will keep with giving only one rule for NTA. i.e. 
> u0D28 + u0D4D + u0D31 = NTA
> and will avoid having this one.

Pravin can you please clarify what you have done on this? In https://bugzilla.redhat.com/show_bug.cgi?id=1016989#c2 you say you will give both rules i.e. with NA and also chillu N but above you say you will give only old rule with NA.

Comment 9 Pravin Satpute 2014-04-14 07:22:01 UTC
We are supporting both sequences.


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