[Bug 450699] lohit-fonts: Errors in "sh" and "shrI" in Lohit Tamil font

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=450699


Bug Zapper <fedora-triage-list at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|rawhide                     |10

Padmanabhan V. K. <bugzillas+padREMOVETHISdu at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzillas+padREMOVETHISdu at g
                   |                            |mail.com




--- Comment #1 from Bug Zapper <fedora-triage-list at redhat.com>  2008-11-25 21:24:09 EDT ---

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

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Comment #2 from Padmanabhan V. K. <bugzillas+padREMOVETHISdu at gmail.com>  2009-01-22 15:38:35 EDT ---
(In reply to comment #0)
> A. The ITRANS Tamil character "sh" in Lohit Tamil is rendered as ஶ் : the dot
> above or pulli should be over the character rather than beside it. Most other
> consonants are rendered correctly. For example, the consonant "k" is correctly
> rendered as க். I have been told that the "font must have a correct GPOS table
> for pulli positioning and the rendering engine must utilise that information
> when drawing the glyph" for the character to show up correctly. Of the two, I
> think it more likely that it is the font rather than the rendering system that
> is likely to be faulty because க் shows up correctly.
> 

IMHO the rendering engine is faulty. Since you use Kubuntu, I'd assume your
rendering engine is whatever QT/KDE uses (probably that's just called QT?).
Hence this part of the issue should be reported to them.

In my case I found the same issue with Lohit Tamil with the Pango rendering
engine (used in GTK+/GNOME/etc.). Downloading the source for my version of
Pango and changing one of its file worked for me.

The latest version of the pango file can be viewed here:
http://svn.gnome.org/viewvc/pango/trunk/modules/indic/indic-ot-class-tables.c?revision=2684&view=markup
In the array tamlCharClasses[], entry 55 (corresponding to unicode character
0BB6) should be changed to _ct instead of _xx for "sh," "shaa," "shi," etc. to
be rendered properly.

If I can get over my laziness I'll probably file a bug for this on Pango.

> B. The character "shrI" should properly be rendered as ஸ்ரீ. This character should
> correctly be Unicode 0BB6 + 0BCD + 0BB0 + 0BC0 whereas in Lohit Tamil (and
> possibly other Tamil fonts) it is made from Unicode 0BB8 + 0BCD + 0BB0 + 0BC0,
> which is wrong. This should be corrected to accord with "The Unicode Standard,
> Revision 5.0", p 325.

I agree that Lohit Tamil should be enhanced to render 0BB6 + 0BCD + 0BB0 + 0BC0
also as the "shri" ligature. However for backward-compatibility 0BB8 + 0BCD +
0BB0 + 0BC0 should probably also produce the "shri" ligature -- there would
certainly be older documents where this encoding was used for the "shri"
ligature, and other fonts also seem to have used this encoding, e.g. all the
fonts in Mandriva's fonts-ttf-tamil-1.1-2mdk package that are installed in the
machine I am typing this from.

But Lohit Tamil is producing the ligature for 0BB7 + 0BCD + 0BB0 + 0BC0, which
doesn't seem to be useful.

HTH, Thanks!

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.