freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freetype] .pfb font screwyness...


From: David Turner
Subject: Re: [Freetype] .pfb font screwyness...
Date: Thu, 11 Apr 2002 17:18:17 +0200

Hi Paul,

"Pedriana, Paul" a écrit :
> 
> Perhaps this has been fixed in some recent Freetype update, but...
>
It was a bug, please update to 2.0.9 :-)

Regards,

- David Turner


 
> I load a .pfb font (from ITC called "Arta Book") and then call:
>    FT_Set_Pixel_Sizes(face, 9, 9);
> 
> After doing this I get:
>    face->units_per_EM            = 1000
>    face->ascender                = 921
>    face->descender               = -250
>    face->height                  = 1405
>    face->size->metrics.x_ppem    = 9
>    face->size->metrics.y_ppem    = 9
>    face->size->metrics.x_scale   = 37749
>    face->size->metrics.x_scale   = 37749
>    face->size->metrics.ascender  = 512
>    face->size->metrics.descender = -128
>    face->size->metrics.height    = 832
>    face->bbox.xMin               = -6225920    <----- ???
>    face->bbox.yMin               = -16384000   <----- ???
>    face->bbox.xMax               = 72548352    <----- ???
>    face->bbox.yMax               = 60358656    <----- ???
> 
> I don't understand the bbox values. Why are they so large?
> I thought they were supposed to be in font units. Based on
> the Freetype documentation and based on what I get when using
> the TrueType version of this font, I expect values to be
> something like:
>    face->bbox.yMax ~= face->height
> 
> I stepped into the T1_Init_Face() function and found this (some blank lines
> removed):
>    root->bbox = face->type1.font_bbox;
>    if ( !root->units_per_EM )
>       root->units_per_EM = 1000;
>    root->ascender  = (FT_Short)( face->type1.font_bbox.yMax >> 16 );
>    root->descender = (FT_Short)( face->type1.font_bbox.yMin >> 16 );
> 
> This is saying that the bbox data is in 16.16 format and not
> in font units as the Freetype documentation says it should be.
> This suggests that there is a bug somewhere. To be consistent
> with the documentation, this code should be dividing the bbox
> values by 65536 before returning to the caller. The fact that
> the TrueType driver and the Type1 driver act differently suggests
> to me that I'm misinformed or there is a bug somewhere.
> 
> Let me quote the documentation:
>   /*    bbox :: The font bounding box.  Coordinates are     */
>   /*            expressed in font units (see units_per_EM). */   <----- Here
>   /*            The box is large enough to contain any      */
>   /*            glyph from the font.  Thus, bbox.yMax can   */
>   /*            be seen as the `maximal ascender',          */
>   /*            bbox.yMin as the `minimal descender', and   */
>   /*            the maximal glyph width is given by         */
>   /*            `bbox.xMax-bbox.xMin' (not to be confused   */
>   /*            with the maximal _advance_width_).  Only    */
>   /*            relevant for scalable formats.              */
> 
> What should I do?
> 
> Paul
> 
> _______________________________________________
> Freetype mailing list
> address@hidden
> http://www.freetype.org/mailman/listinfo/freetype



reply via email to

[Prev in Thread] Current Thread [Next in Thread]