Thread: [Indic-computing-devel] Problem with freetype rendering of an Indic opentype font
Status: Alpha
Brought to you by:
jkoshy
Menu
▾
▴
indic-computing-devel
|
From: Arun S. <ar...@sh...> - 2003-09-01 18:32:38
|
I see a problem with the freetype rendering of this unicode string: "0xcb7 0xccd" Using Microsoft tunga.ttf (A kannada font that ships with Windows XP). In fact, the problem manifests itself with all other consonants too, including 0xcb7. Here are the screenshots to demonstrate the wrong and the right rendering: http://www.sharma-home.net/~adsharma/misc/wrong.jpg http://www.sharma-home.net/~adsharma/misc/right.jpg The problem is seen with both gnome and kde on Linux with Redhat Beta (Severn) - freetype-2.1.4-4.0. Can one of you tell me if this is a broken font or a bug in freetype ? -Arun |
|
From: Arun S. <ar...@sh...> - 2003-09-05 16:08:24
|
Werner LEMBERG wrote: > > I don't have time to investigate but it seems to me that some > contextual shaping is happening. If this is true it is not a problem > of FreeType 2 (which doesn't support OpenType directly for the moment) > but rather a problem one level higher where Indic scripts are handled, > probably within the Pango library. Owen? Here's what the qt guys had to say about this: > I did some tests, and it seem the problem is buried somewhere in the > open type code used by both gtk and Qt. I've personally verified that "0xcb7 0xccd" is not reordered by the shaping engines. -Arun |
|
From: Arun S. <ar...@sh...> - 2003-09-07 21:35:33
|
On Thu, Sep 04, 2003 at 10:24:10PM +0200, Werner LEMBERG wrote:
> > I see a problem with the freetype rendering of this unicode string:
> >
> > "0xcb7 0xccd"
> >
> > Using Microsoft tunga.ttf (A kannada font that ships with Windows
> > XP). In fact, the problem manifests itself with all other
> > consonants too, including 0xcb7.
>
> I don't have time to investigate but it seems to me that some
> contextual shaping is happening. If this is true it is not a problem
> of FreeType 2 (which doesn't support OpenType directly for the moment)
> but rather a problem one level higher where Indic scripts are handled,
> probably within the Pango library. Owen?
ok, I did some more investigation. Here's a partial dump of the font.
According to this rule, glyph 0x62 should've been substituted by glyph
0xb0. But for some reason, it's not happening.
Does this ring a bell ?
-Arun
<Lookup> <!-- 36 -->
<LookupType>SINGLE</LookupType>
<Subtable>
<SubstFormat>2</SubstFormat>
<Coverage>
<CoverageFormat>2</CoverageFormat>
<Glyph> 42 - 64</Glyph>
<Glyph> 75 - 75</Glyph>
<Glyph> 10d - 10e</Glyph>
</Coverage>
<GlyphCount>38</GlyphCount>
<Substitute>0x90</Substitute> <!-- 0 -->
<Substitute>0x91</Substitute> <!-- 1 -->
<Substitute>0x92</Substitute> <!-- 2 -->
<Substitute>0x93</Substitute> <!-- 3 -->
<Substitute>0x94</Substitute> <!-- 4 -->
<Substitute>0x95</Substitute> <!-- 5 -->
<Substitute>0x96</Substitute> <!-- 6 -->
<Substitute>0x97</Substitute> <!-- 7 -->
<Substitute>0x98</Substitute> <!-- 8 -->
<Substitute>0x99</Substitute> <!-- 9 -->
<Substitute>0x9a</Substitute> <!-- 10 -->
<Substitute>0x9b</Substitute> <!-- 11 -->
<Substitute>0x9c</Substitute> <!-- 12 -->
<Substitute>0x9d</Substitute> <!-- 13 -->
<Substitute>0x9e</Substitute> <!-- 14 -->
<Substitute>0x9f</Substitute> <!-- 15 -->
<Substitute>0xa0</Substitute> <!-- 16 -->
<Substitute>0xa1</Substitute> <!-- 17 -->
<Substitute>0xa2</Substitute> <!-- 18 -->
<Substitute>0xa3</Substitute> <!-- 19 -->
<Substitute>0xa4</Substitute> <!-- 20 -->
<Substitute>0xa5</Substitute> <!-- 21 -->
<Substitute>0xa6</Substitute> <!-- 22 -->
<Substitute>0xa7</Substitute> <!-- 23 -->
<Substitute>0xa8</Substitute> <!-- 24 -->
<Substitute>0xa9</Substitute> <!-- 25 -->
<Substitute>0xaa</Substitute> <!-- 26 -->
<Substitute>0xab</Substitute> <!-- 27 -->
<Substitute>0xac</Substitute> <!-- 28 -->
<Substitute>0xad</Substitute> <!-- 29 -->
<Substitute>0xae</Substitute> <!-- 30 -->
<Substitute>0xaf</Substitute> <!-- 31 -->
<Substitute>0xb0</Substitute> <!-- 32 -->
<Substitute>0xb1</Substitute> <!-- 33 -->
<Substitute>0xb2</Substitute> <!-- 34 -->
<Substitute>0xb3</Substitute> <!-- 35 -->
<Substitute>0x10f</Substitute> <!-- 36 -->
<Substitute>0x110</Substitute> <!-- 37 -->
</Subtable>
</Lookup>
|
|
From: Lars K. <la...@tr...> - 2003-09-07 21:55:14
|
On Sunday 07 September 2003 23:37, Arun Sharma wrote: > On Thu, Sep 04, 2003 at 10:24:10PM +0200, Werner LEMBERG wrote: > > > I see a problem with the freetype rendering of this unicode string: > > > > > > "0xcb7 0xccd" > > > > > > Using Microsoft tunga.ttf (A kannada font that ships with Windows > > > XP). In fact, the problem manifests itself with all other > > > consonants too, including 0xcb7. > > > > I don't have time to investigate but it seems to me that some > > contextual shaping is happening. If this is true it is not a problem > > of FreeType 2 (which doesn't support OpenType directly for the moment) > > but rather a problem one level higher where Indic scripts are handled, > > probably within the Pango library. Owen? I did some investigations and the problem seems to lie within the freetype 1 open type code used by Qt and pango. The font uses chain substitutions to achieve correct rendering of this combination and these seem to work incorrectly. Up do now I didn't find time to dig into this in more detail. > ok, I did some more investigation. Here's a partial dump of the font. > According to this rule, glyph 0x62 should've been substituted by glyph > 0xb0. But for some reason, it's not happening. > > Does this ring a bell ? The lookup table you quite below is actually a subtable of some chain substitution table as far as I can tell. > <Lookup> <!-- 36 --> > <LookupType>SINGLE</LookupType> [...] I'll try to have a closer look in the next days if time allows. Cheers, Lars |
|
From: Owen T. <ot...@re...> - 2003-09-07 23:42:00
|
On Sun, 2003-09-07 at 17:51, Lars Knoll wrote: > On Sunday 07 September 2003 23:37, Arun Sharma wrote: > > On Thu, Sep 04, 2003 at 10:24:10PM +0200, Werner LEMBERG wrote: > > > > I see a problem with the freetype rendering of this unicode string: > > > > > > > > "0xcb7 0xccd" > > > > > > > > Using Microsoft tunga.ttf (A kannada font that ships with Windows > > > > XP). In fact, the problem manifests itself with all other > > > > consonants too, including 0xcb7. > > > > > > I don't have time to investigate but it seems to me that some > > > contextual shaping is happening. If this is true it is not a problem > > > of FreeType 2 (which doesn't support OpenType directly for the moment) > > > but rather a problem one level higher where Indic scripts are handled, > > > probably within the Pango library. Owen? > > I did some investigations and the problem seems to lie within the freetype 1 > open type code used by Qt and pango. The font uses chain substitutions to > achieve correct rendering of this combination and these seem to work > incorrectly. Up do now I didn't find time to dig into this in more detail. I just recently applied a patch to Pango for Chain Context substitutions that apparently was needed for Kannada - http://people.redhat.com/otaylor/opentype-patches/pango-26-chain-format3 (from Kailash C. Chowksey.) Could that fix the problem here? (That patch is in Pango-1.2.5) http://bugzilla.gnome.org/show_bug.cgi?id=118592 also comes up for tunga.ttf, though we haven't come up with a final patch for that. Regards, Owen |
|
From: Dr. U.B. P. <pav...@vi...> - 2003-09-10 04:07:13
|
> On Monday 08 September 2003 01:39, Owen Taylor wrote: > > On Sun, 2003-09-07 at 17:51, Lars Knoll wrote: > > > On Sunday 07 September 2003 23:37, Arun Sharma wrote: > > > > On Thu, Sep 04, 2003 at 10:24:10PM +0200, Werner LEMBERG wrote: > > > > > > I see a problem with the freetype rendering of this unicode string: > > > > > > > > > > > > "0xcb7 0xccd" > > > > > > > > > > > > Using Microsoft tunga.ttf (A kannada font that ships with Windows > > > > > > XP). In fact, the problem manifests itself with all other > > > > > > consonants too, including 0xcb7. > > > > > > > > > > I don't have time to investigate but it seems to me that some > > > > > contextual shaping is happening. If this is true it is not a problem > > > > > of FreeType 2 (which doesn't support OpenType directly for the > > > > > moment) but rather a problem one level higher where Indic scripts are > > > > > handled, probably within the Pango library. Owen? > > > > > > I did some investigations and the problem seems to lie within the > > > freetype 1 open type code used by Qt and pango. The font uses chain > > > substitutions to achieve correct rendering of this combination and these > > > seem to work incorrectly. Up do now I didn't find time to dig into this > > > in more detail. > > > > I just recently applied a patch to Pango for Chain Context substitutions > > that apparently was needed for Kannada - > > > > http://people.redhat.com/otaylor/opentype-patches/pango-26-chain-format3 > > > > (from Kailash C. Chowksey.) Could that fix the problem here? (That patch > > is in Pango-1.2.5) > > No, the problem was actually unrelated to the chaining substitutions. > > > http://bugzilla.gnome.org/show_bug.cgi?id=118592 also comes up for > > tunga.ttf, though we haven't come up with a final patch for that. > > I have debugged the problem today, and found that the problem lies somewhere > else than I first guessed. tunga.ttf has a ligature for the character > combination quoted above. The lookup table for the ligature has a LookupFlag > of 0x0100, so it should skip marks that do not have a MarkAttachmentClass of > 0x01. The 0xccd character however is a mark according to the gdef table, but > has no MarkAttachmentClass defined. > > Thus TT_GDEF_Get_Glyph_Property() return 0x8 for the glyph, and the > Check_Property() call fails Lookup_LigatureSubst. Seems like we have to > ignore the high byte of the LookupFlag if the glyph has no > MarkAttachmentClass (the specs are not really clear about this IMO). What is meant by MarkAttachmentClass? When we design the Opentype font, normally we use Microsoft VOLT and define the glyphs there. As you correctly pointed out, 0xccd is defined as Mark. This will define the glyph as Mark in the GDEF table. How to add the MarkAttachmentClass? Which tool are you using to dump the embedded tables of the OTF? Is it TTX? BTW, I did not develop Tunga.ttf :-) > I've attached a patch that fixes the problem and gives correct shaping of the > above glyph combination. > > Cheers, > Lars Rgds, Pavanaja----------------------------------------------------- Dr. U.B. Pavanaja Editor, Vishva Kannada World's first Internet magazine in Kannada http://www.vishvakannada.com/ Note: I don't worry about pselling mixtakes |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X