Hello, The patch helped to fix the problem with vertical metrics. However, now it turns out that SimSun font has vertical advance smaller than bbox height for latin characters (check E, for example). As a result, upright English text in vertical layout, becomes too condensed. Adobe Illustrator displays vertical English text (upright) fine however. It should mean they do not take the vadvance into consideration. So should the vertical advance be ignored, or is there some tricks to detect faulty fonts and ignore it only for them?
Thank you, Sergey Tolstov > -----Original Message----- > From: Chia I Wu [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 12, 2005 4:40 PM > To: Sergey Tolstov > Cc: [email protected] > Subject: Re: [ft] Vertical layout > > On Wed, Oct 12, 2005 at 03:59:18PM -0700, Sergey Tolstov wrote: > Hi, > > Hello, > > > > In what state is FT support for vertical glyph metrics? > The problem you encountered has been fixed in CVS: > http://savannah.gnu.org/cgi-bin/viewcvs/freetype/freetype2/src > /truetype/ttgload.c.diff?r1=1.138&r2=1.139 > > > > I am encountering problem with vertical glyph metrics, when > they are > > present in a font file. I get a huge number for the > linearVertAdvance, > > other values look fine, because of that, glyphs are not > generated. I > > need advance value in design units for WYSIWYG. > > > > While debugging, I found: > > In the ttgload.c, line 1768, subtraction is incorrect > > advance_height = (FT_UShort)( loader->pp4.y - > loader->pp3.y ); should > > be, according to earlier calculations > > advance_height = (FT_UShort)( loader->pp3.y - loader->pp4.y ); > > > > Even with that fix, linearVertAdvance is calculated incorrectly. > > (Should they use loader->vadvance instead?) > As loader->pp's are in 26.6, advance_height should be divided > by y_scale after the calculation. > > -- > Regards, > olv > _______________________________________________ Freetype mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype
