[ft-devel] patch requested for freetype2/internal header usage (using font_bbox)

[david turner]

Hi Drew,


> I think your option A would probably be safe.  But if you do think
> providing the API would be generally useful, then let me know when it's
> implemented, I could upgrade the Xprint to use it in the future.
>
>   
I don't think it is useful for ordinary users of the library. The 
programs that need the *exact*
values tend to be the one that are capable of parsing the Postscript 
anyway, so they don't
rely on something like FreeType that tries to provide a unified 
interface instead, masking
as much nasty things as possible.
> Yes, it's probably better for Xprint users not to necessarily have to
> force them to upgrade their version of Freetype, I think. So working
> around the cooordinate conversion is probably best for now.
>
>   
I think so
> Let me see if I have the idea right.  I would simply want to replace
> FT_Get_PS_Font_BBox( ) to look something like:
>
> static FT_BBox *
> FT_Get_PS_Font_BBox( FT_Face face )
> {
>   const char *driver_name;
>   FT_BBox    *font_bbox = malloc(sizeof( FT_BBox ) );
>
>   if ( face )
>   {
> 	font_bbox->xMin = face->bbox.xMin * 65536;
> 	font_bbox->yMin = face->bbox.yMin * 65536;
> 	font_bbox->xMax = face->bbox.xMax * 65536;
> 	font_bbox->yMax = face->bbox.yMax * 65536;
>  }
> return font_bbox;
> }
>
> Is that the general idea? 
>
>   
Yes, it is, but you'll have the problem of knowing when freeing the 
allocated structure
(and handling out-of-memory conditions as well properly within the 
function and its
caller as well, tsss, tsss :-)

> xMax and yMax also added 0xFFFFU ("root->bbox.xMax =
> ( type1->font_bbox.xMax + 0xFFFFU ) >> 16;" instead of just
> "root->bbox.xMin =   type1->font_bbox.xMin  >> 16;"), so is simply
> multiplying by 65536 really all I need to do?
>
>   
yes, the operation is equivalent to a ceil-rounding, i.e. it will round 
2.0 to 2 and 2.1 to 3
when you receive the integer values, you've already lost the fractional 
part anyway, so
simply multiplying by 65536 converts the integers to the same 16.16 
fixed point values.

> Actually, mallocing the font_bbox like this will be a nuisance since I'd
> have to be careful to deallocate afterwards.  I might therefore prefer
> to use "face->bbox.xMin * 65536" directly in
> PSType3_generateOutlineFont:
>
>  else
>   {
>     fprintf(out, "/FontBBox [%d %d %d %d] def\n",
>                  (int)ti->ttface->bbox->xMin * 65536,
>                  (int)ti->ttface->bbox->yMin * 65536,
>                  (int)ti->ttface->bbox->xMax * 65536,
>                  (int)ti->ttface->bbox->yMax * 65536);
>   }
>
> instead of 
>
>  else
>   {
>     FT_BBox *font_bbox = FT_Get_PS_Font_BBox(ti->ttface);
>     fprintf(out, "/FontBBox [%d %d %d %d] def\n",
>                  (int)font_bbox->xMin,
>                  (int)font_bbox->yMin,
>                  (int)font_bbox->xMax,
>                  (int)font_bbox->yMax);
>   }
>
>
> I suspect I can remove the (int) cast here too, since the face->bbox
> values are already integers, would that be correct?
>
>   
the values are longs. Apart from that, you're correct !

But wait, there is more: the original code is buggy !!
it should really look like the following instead:

    FT_BBox *font_bbox = FT_Get_PS_Font_BBox(ti->ttface);
    fprintf(out, "/FontBBox [%f %f %f %f] def\n",
                 font_bbox->xMin/65536.0,
                 font_bbox->yMin/65536.0,
                 font_bbox->xMax/65536.0,
                 font_bbox->yMax/65536.0);

that's because, according to the Type 1 spec, the values of  /FontBBox 
are normally expressed
in outline coordinates, as "regular" numbers. the original code produces 
values that are too large
by a factor of 2**16 !!

the consequence of this is that:

- this code generates bogus values for /FontBBox already (they're huuuge)
  and it seems that this has never been spotted before. In other words, it
  probably isn't important at all.

- thus we can use the public face->bbox fields instead, since any loss of
  accuracy due to the integer truncation is far below the radar of anything
  important.

So, the correct, non-buggy code would be:

 else
  {
    fprintf(out, "/FontBBox [%ld %ld %ld %ld] def\n",
                 ti->ttface->bbox->xMin,
                 ti->ttface->bbox->yMin * 65536,
                 ti->ttface->bbox->xMax * 65536,
                 ti->ttface->bbox->yMax * 65536);
  }

and should be compatible with any release of FT2.

Hope this helps,

- David Turner
- The FreeType Project  (www.freetype.org)

PS: It's sort of funny to see that the original developer went to great 
lengths
      (peeking within the library internals) to get the values it 
needed, without
      being able to use them correctly. Oh well :o)

> Thanks for the tips,
>
> Drew
>
>
>   

***********************************************************************************
Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster at nds.com and destroy the original message.
***********************************************************************************