Description of problem: Complex glyph SRI was changed from U+0BB8 U+0BCD U+0BB0 U+0BC0 to U+0BB6 U+0BCD U+0BB0 U+0BC0 in Unicode 4.1. Lohit-Tamil displays the complex glyph for both forms for backward compatibility. However this also prevents migration to latest standard as some input tools too offer same functionality leading to more content created with U+0BB8 U+0BCD U+0BB0 U+0BC0 as SRI which increases the need for backward compatibility. To break this vicious cycle, I propose U+0BB8 U+0BCD U+0BB0 U+0BC0 should not be substituted with complex glyph SRI and should be displayed normally. Apple / iOS fonts already do this complying with latest unicode standard. Failing to move to single consistent representation in line with latest unicode leads to fragmentation within unicode text, a greater cause for worry than backward compatibility. I understand the larger problem of standardization cannot happen only by changing this font, but its a start and Lohit being the only maintained free Tamil font, can help in the process. Version-Release number of selected component (if applicable): 2.5.3 How reproducible: Always Steps to Reproduce: 1. ஸ்ரீ (U+0BB8 U+0BCD U+0BB0 U+0BC0) should be displayed as ஸ்(U+0BB8 U+0BCD) ரீ(U+0BB0 U+0BC0) without a space in middle and not compounded form. Actual results: U+0BB8 U+0BCD U+0BB0 U+0BC0 giving complex glyph SRI Expected results: U+0BB8 U+0BCD U+0BB0 U+0BC0 should not give complex glyph SRI, should give U+0BB8 U+0BCD and U+0BB0 U+0BC0 seperately. Change Required: The line Ligature2: "'abvs' Above Base Substitutions in Tamil lookup 0 subtable" u0BB8_u0BCD.half u0BB0 u0BC0 in Lohit-Tamil.sfd should be removed. Additional info: See also bug 450699
I have always been in favour of following the standard over keeping sticking to legacy data. If fonts continue to display non-standard sequences like this, then as Srikanth says the interoperability purpose of the standard is lost. Also consider Arabic/Urdu-based names like tasrīn. In Tamil script they should be written as தஸ்ரீன் (தஸ்.ரீன் without the dot) but with the current behaviour they are displayed identical to தஶ்ரீன் whereas ஶ்ரீ is only ever found in Sanskrit-based names. (On Firefox 28 on my Kubuntu Saucy system I am able to prevent the ligature by using ZWNJ but that should not be required for normal usage.) Previously (bug 1016984 and bug 1016989) the maintainers have refused to remove old sequences citing legacy use, but in this case such refusal would mean such Arabic-based names cannot be written naturally in Tamil script without using ZWNJ and that affects usability.
I think we can do this change in Lohit2 Tamil development. If someone request for old sequence support we can request him to use old version. give me couple of month for this.
lohit-tamil-fonts-2.91.0-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/lohit-tamil-fonts-2.91.0-1.fc20
lohit-tamil-fonts-2.91.0-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/lohit-tamil-fonts-2.91.0-1.fc21
Package lohit-tamil-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-tamil-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-12828/lohit-tamil-fonts-2.91.0-1.fc20 then log in and leave karma (feedback).
lohit-tamil-fonts-2.91.0-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/lohit-tamil-fonts-2.91.0-2.fc21
lohit-tamil-fonts-2.91.0-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.