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

[david turner]

Hello Drew,

thanks a *lot* for this e-mail. Here's what I've understood of the 
situation:

- first of all, the fact that the code includes "t42types.h" means that the
 original developer assumed that Xprint was using the version of FreeType
 embedded within the X server, since this header has _never_ been installed
 by our configure scripts in any version of FreeType. the code can only be
 compiled with the FreeType sources available from the include path.

 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.

- 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.

 this is not surprising: since the Type 1 spec states that coordinates 
can be
 decimal, not necessarily integer, we parse all of them as 16.16 fixed 
point
 numbers (which are large enough to contain all coordinate values found in
 real-life fonts). However, we convert them to integers where appropriate.

 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;
 
 src/cid/cidobjs.c (415):
     cidface->bbox.xMin =   cid->font_bbox.xMin             >> 16;
     cidface->bbox.yMin =   cid->font_bbox.yMin             >> 16;
     cidface->bbox.xMax = ( cid->font_bbox.xMax + 0xFFFFU ) >> 16;
     cidface->bbox.yMax = ( cid->font_bbox.yMax + 0xFFFFU ) >> 16;

 src/type42/t42objs.c (290):
     /* Ignore info in FontInfo dictionary and use the info from the  */
     /* loaded TTF font.  The PostScript interpreter also ignores it. */
     root->bbox         = face->ttf_face->bbox;

As you can see, we simply truncate/ceil the 16.16 values to integers for 
the Type 1
and CID formats, and use the integer ones provided by the TTF container for
Type42 (and the comment suggests that this is the correct way to do it).

The Xprint code uses the internals to reach the original 16.16 values, 
and it
also ignores the ones provided by the TrueType container in the case of 
Type42
(which is probably wrong, if we're to believe the comment).

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 :-)

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

I don't know enough about Xprint to determine which solution is correct,
but I suspect that A/ is simple and largely sufficient for your needs.

I hope you'll find this information useful. Please let us know of any change
or patch you'd be able to provide, we'd be happy to add it to our list.

Regards,

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


Drew Parsons a écrit :
> Dear FreeType developers,
>
> I am involved with Xprint, an X11 extension enabling printing using the
> X protocol [1].
>
> Xprint uses FreeType2, but unfortunately its postscript driver uses the
> internal freetype headers.  You've written very clearly [2] that this
> should not be done, and I would to take up your kind offer to work with
> us to patch the problem.
>
> The incriminating code is found in Xprint/ps/psout_ftpstype3.c.  It can
> be found in X.org's new modular system at
> http://cvs.freedesktop.org/xorg/xserver/xorg/Xprint/ps/psout_ftpstype3.c?view=markup
> However the freetype support is not yet switched on in the modular
> build, so if you need to compile it yourself you might find the old
> monolithic builds [3] ready for use.
>
> The internal headers are referenced in psout_ftpstype3.c around l.58:
>
> #define USE_FT_INTERNALS 1
> #ifdef USE_FT_INTERNALS
> #include FT_INTERNAL_TYPE1_TYPES_H
> #include "t42types.h"
> #include FT_INTERNAL_OBJECTS_H
> #endif /* USE_FT_INTERNALS */
>
> FT_INTERNAL_TYPE1_TYPES_H is defined as internal/t1types.h, one the
> internal headers in quiestion. "t42types.h" moreover is in src/type42/,
> not even exported.  I don't know why the original author also referenced
> FT_INTERNAL_OBJECTS_H, but I can find the other two headers used below.
>
> As far as I can make out, they are used to define the function
> FT_Get_PS_Font_BBox( ) near l.290:
>
> #ifdef USE_FT_INTERNALS
> static FT_BBox *
> FT_Get_PS_Font_BBox( FT_Face face )
> {
>   const char *driver_name;
>   FT_BBox    *font_bbox = NULL;
>
>   if ( face && face->driver && face->driver->root.clazz )
>   {
>     driver_name = face->driver->root.clazz->module_name;
>     if ( ft_strcmp( driver_name, "type1" ) == 0 )
>       font_bbox = &(((T1_Face)face)->type1.font_bbox);
>     else if ( ft_strcmp( driver_name, "t1cid" ) == 0 )
>       font_bbox = &(((CID_Face)face)->cid.font_bbox);
>     else if ( ft_strcmp( driver_name, "type42" ) == 0 )
>       font_bbox = &(((T42_Face)face)->type1.font_bbox);
>   }
>
>   return font_bbox;
> }
> #endif /* USE_FT_INTERNALS */
>
> If I'm reading it correctly, it's the use of face->type1.font_bbox with
> face case as T1_Face which is explicitly using the Freetype internal
> structures, since font_bbox is defined in T1_Font in internal/t1types.h. Likewise for t42types.h.  
>
> Is there a public interface for accessing these font_bboxes without
> breaking the way you want the freetype code to be used?
>
> The font bbox is used in psout_ftpstype3.c around l.365 (in
> PSType3_generateOutlineFont( ) ), where the font bbox values are used to
> write a postscript FontBBox.
>
> Patches or clues gratefully accepted!
>
> Thanks,
>
> Drew Parsons
>
>
>
> [1] http://xprint.mozdev.org/
>
> [2] http://freetype.sourceforge.net/freetype2/freetype-2.2.0.html
>
> [3] Latest monolithic source:
> http://cvs.freedesktop.org/xorg/xc/programs/Xserver/Xprint/ps/,
> older tarball:
> http://prdownloads.sourceforge.net/xprint/xprint-2004-07-07-release_009_001-i386-pc-linux-gnu.tar.gz?download
>
>
> _______________________________________________
> Freetype-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/freetype-devel
>
>   

***********************************************************************************
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 address@hidden and destroy the original 
message.
***********************************************************************************