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

[Drew Parsons]

On Mon, 2006-01-23 at 11:20 +0100, david turner wrote:
> Hello Drew,
> 
>   If this assumptions holds true (i.e. Xprint basically uses its own 
> copy of FreeType
>   instead of the one installed on the system), it is at least safe from 
> the 2.2 install
>   problems we described recently. Good to know.

Yes, that's been the case up till now with the X.org monolithic build. A
copy of Freetype was held in the extras directory.  The new modular
build is intended to loosen up tight code dependencies, so I understand
X.org's X11R7 would prefer to use the normal installed version of
Freetype, using its public API, rather than continuing to keep a version
bindled with the X.org code.


> - there is a public field named "bbox" in the FT_Face structure that 
> receives
>   the global font bounding box in EM units. This is slightly different 
> from the
>   so-called Type 1 "font_bbox" values that are accessed by the code, which
>   are all expressed in 16.16 fixed point values.
> 
>   For example, the face->bbox fields are populated by code that is found
>   here in the CVS sources:
> 
>   src/type1/t1objs.c (403):
>       root->bbox.xMin =   type1->font_bbox.xMin             >> 16;
>       root->bbox.yMin =   type1->font_bbox.yMin             >> 16;
>       root->bbox.xMax = ( type1->font_bbox.xMax + 0xFFFFU ) >> 16;
>       root->bbox.yMax = ( type1->font_bbox.yMax + 0xFFFFU ) >> 16;
>   
...
> Now, it all depends wether Xprint needs the original exact values or not.
> 
> A/ in one hand, we can imagine it could use the face->bbox fields, multiply
>   them by 65536 to obtain "equivalent" values. This may create a slightly
>   larger bounding box *if* the original values were decimal, instead of
>   integers.
> 
>   First of all, I don't think that this will be the majority of cases. 
> Second, I'm
>   not even certain that this would have any impact on Xprint's output.
> 
> B/ on the other hand, we can also imagine that Xprint wants the *absolutely*
>   exact values, without truncating/rounding. Then, we can provide you with
>   a small high-level API that implements this "feature" in a clean way. For
>   example by getting the Type42 values from the TrueType container
>   as well :-)
> 

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.


>   This code would depend on a newer version of FreeType though.

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.

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? 

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?

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?

Thanks for the tips,

Drew