freetype-devel
[Top][All Lists]
Advanced

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

Re: [Devel] Freetype2 Type1 Glyph Character Advancement Loss of Precisi


From: mly
Subject: Re: [Devel] Freetype2 Type1 Glyph Character Advancement Loss of Precision
Date: Mon, 25 Feb 2002 17:42:00 +0100

Hi David,

Thanks for your reply.

The problem is that we're using the Freetype glyph cache so we don't call
FT_Load_Glyph() directly ourselves (we have to use the cache because of
critical performance issues):

      rc = FTC_ImageCache_Lookup(
         pThis->Freetype.pImageCache,
         pDescriptor,
         iGlyph,
         &Glyph,
         NULL
      );
      ftchk(rc);

      assert(Glyph->format == ft_glyph_format_outline);
      /* render the glyph to a bitmap, don't destroy original */
      rc = FT_Glyph_To_Bitmap(&Glyph, ft_render_mode_mono, pOrigin, 0);
      ftchk(rc);
      assert(Glyph->format == ft_glyph_format_bitmap);
      pGlyph  = (FT_BitmapGlyph) Glyph;
      pBitmap = &pGlyph->bitmap;

      pResult->Metrics.Size.x    = pBitmap->width;
      pResult->Metrics.Size.y    = pBitmap->rows;
      pResult->Metrics.Advance.x = Glyph->advance.x;
      pResult->Metrics.Advance.y = Glyph->advance.y;
      pResult->Metrics.Bearing.x = pGlyph->left;
      pResult->Metrics.Bearing.y = pGlyph->top;
      pResult->Stride            = ips_abs(pBitmap->pitch);
      pResult->nBytes            = pResult->Stride *
   pResult->Metrics.Size.y;
      pResult->pBytes            = pBitmap->buffer;

Later we convert the Freetype units to our own internal 7200 dots-per-inch
format using (pThis->Scale.x and pThis->Scale.y contains "7200 / horizontal
DPI" and "7200 / vertical DPI" respectively):

   /* convert Freetype 16.16 sub-pixel advance to IPE dots-per-inch */
   pResult->Metrics.Advance.x  *= pThis->Scale.x;
   pResult->Metrics.Advance.x  += 0x8000;  /* round up to nearest integer
*/
   pResult->Metrics.Advance.x >>= 16;     /* convert 16.16 format to 32.0
*/
   pResult->Metrics.Advance.y  *= pThis->Scale.y;
   pResult->Metrics.Advance.y  += 0x8000;
   pResult->Metrics.Advance.y >>= 16;
   pResult->Metrics.Bearing.x *= pThis->Scale.x;
   pResult->Metrics.Bearing.y *= pThis->Scale.y;

As far as I can determine, we simply don't have access to the
linearHoriAdvance and linearVertAdvance advance fields as we don't have
access to the glyph slot itself.

It seems odd that T1_Load_Glyph intentionally discards information (the
fractional part), which is important in certain situations.  Wouldn't it be
more appropriate if T1_Load_Glyph() did not discard this information and
the client (caller) instead discarded the information if it was unimportant
to that particular client?  This way, we could choose to use the
information in the fractional part and others might choose to not use it.

Getting access to the glyph's design units seems rather complicated as we
would then have to introduce awareness about font-specific issues that are
far outside the domain of our problem.


Sincerely,

Mikael Lyngvig



|---------+--------------------------->
|         |           David Turner    |
|         |           <address@hidden|
|         |           eetype.org>     |
|         |           Sent by:        |
|         |           address@hidden|
|         |           type.org        |
|         |                           |
|         |                           |
|         |           2002.02.20 21:31|
|         |           Please respond  |
|         |           to devel        |
|         |                           |
|---------+--------------------------->
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                                                     |
  |        To:      address@hidden                                              
                                                                 |
  |        cc:                                                                  
                                                                     |
  |        Subject: Re: [Devel] Freetype2 Type1 Glyph Character Advancement 
Loss of  Precision                                                       |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|



Hello Claus and Michael,

address@hidden a écrit :
>
> Hi,
>
> For some reason or another, Freetype2 discards the fractional value of
the
> horizontal and vertical glyph advance as computed by T1_Load_Glyph if
> hinting is enabled.  The code shown below, which is found in
T1_Load_Glyph
> () in the t1gload.c module, intentionally discards the fractional part:
>
> [..... text removed ...]
>
> The CID and CFF font drivers functions identically.  The problem may be
> apparant elsewhere in Freetype.
>

This is purely intentional. You should use the "linearHoriAdvance" and
"linearVertAdvance" fields of the FT_GlyphSlot structure (after calling
FT_Load_Glyph) to retrieve the information you need:

  * by default, they contain the linearly scaled advance values
    expressed in 16.16 fixed float format (_not_ 26.6 !!)

  * if you use the FT_LOAD_LINEAR_DESIGN flag when calling
    FT_Load_Glyph, then these field contain the original
    values expressed in design units.

    this is useful to perform computations with very high
    accuracy (e.g. with floating points)..


Hope this helps..

- David Turner

_______________________________________________
Devel mailing list
address@hidden
http://www.freetype.org/mailman/listinfo/devel







reply via email to

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