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
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.
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.
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).
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
(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.
Closing. Please feel free to reopen if you find further information. Thanks. :)