Bug 1016989

Summary:	[ml_IN] non-standard sequence sequence for stacked chillu-N and RRA in Lohit Malayalam font should be removed
Product:	[Fedora] Fedora	Reporter:	Shriramana Sharma <samjnaa>
Component:	lohit-malayalam-fonts	Assignee:	Pravin Satpute <psatpute>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	22	CC:	fonts-bugs, i18n-bugs, psatpute
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-12 07:19:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Shriramana Sharma 2013-10-09 06:10:50 UTC

This is related to bug #1016984 which I reported just now.

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. In bug #1016984 I have requested to add it.

Apart from that, note that currently the sequence being used to display stacked chillu-N on top of RRA in Lohit font is ന്റ = 0d28 0d4d 0d31. This is non-standard. It is inadvisable to retain this sequence as having two canonically non-equivalent sequences display the same is a security issue of confusability.

My request from the POV of being standard-compliant would be to remove this sequence.

However I am sure (based on personal email communication) there will be objection from people such as Santosh Thottingal since they do not agree with the standard on this matter. They maintain that NA + VIRAMA + RRA is the correct sequence to get this display.

I have told them that if they disagree with the standard then they should discuss the matter on the Unicode and try to make the Unicode Technical Committee accept their view. Otherwise such sequences will just be standards-non-compliant and the existing diversified situation will only be aggravated.

Certainly the current standard-prescribed sequence should be included to be standards compliant. For that I have already filed the separate bug. For 100% compliance the old non-standard should be removed. To track that I am filing this bug now.

In the face of community objection, it is up to the project maintainer to decide about this.

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

Comment 1 Pravin Satpute 2014-01-09 09:35:24 UTC

This bug report is very clear and i agree with you. but surprisingly some fonts around does not follow it.

Dunno why people are considering U+0D28 and U+0D7B as equivalent.

In reality 

u0D28 + u0D4D + u200D = u0D7B

I hope people around are not using this u0D28 instead of u0D7b and already created some data.

Comment 2 Pravin Satpute 2014-01-13 09:08:26 UTC

1. There is already good amount of data available using this legacy sequence. 
2. Same time, this sequence is supported in Lohit from long time. Removing it will introduce regression.

Lohit2 will also support this sequence with standard one given in Unicode. Closing this as a Not a Bug. Feel free to reopen if more issues.

Comment 3 Shriramana Sharma 2014-10-14 06:36:42 UTC

Dear Pravin,

Based on the way you have handled bug 1078661 don't you think in the case of Malayalam also you can have users use the old version of the font if they want the old behaviour and the new version of the font should support only the standards-compliant sequence?

Since Lohit is a high visibility font especially used in Linux/Android devices and all, if we are standards compliant then it will encourage others to be so as well in their input methods etc. if we are non-compliant then we are merely encouraging people to continue using non-standard input sequences.

I strongly doubt that in latest Windows 8 fonts the old sequence would be supported (but I don't have that OS so I can't test).

Comment 4 Jaroslav Reznik 2015-03-03 16:55:55 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 5 Pravin Satpute 2015-04-16 10:54:23 UTC

(In reply to Shriramana Sharma from comment #3)
 
> I strongly doubt that in latest Windows 8 fonts the old sequence would be
> supported (but I don't have that OS so I can't test).

Malayalam is bit complicated when comes to Unicode standards. We have seen issues with community and Unicode.

Just tested with Google noto fonts and even they are supporting this sequence. Reason should be same backward compatibility.

Comment 6 Pravin Satpute 2015-10-12 07:19:16 UTC

Closing. Please feel free to reopen if you find further information.

Thanks. :)