RE: [ft] Vertical layout

[Sergey Tolstov]

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:address@hidden 
> Sent: Wednesday, October 12, 2005 4:40 PM
> To: Sergey Tolstov
> Cc: address@hidden
> 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
>