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

Drew Parsons dparsons at debian.org
Tue Jan 24 16:19:05 PST 2006


On Wed, 2006-01-25 at 00:58 +0100, David Turner wrote:
> Drew Parsons a écrit :
> 
> >OK. In that case you mean the 65536 needs to removed from the other 3
> >coords. That is I want:
> >
> > else
> >  {
> >    fprintf(out, "/FontBBox [%ld %ld %ld %ld] def\n",
> >                 ti->ttface->bbox->xMin,
> >                 ti->ttface->bbox->yMin,
> >                 ti->ttface->bbox->xMax,
> >                 ti->ttface->bbox->yMax);
> >  }
> >
> >Correct?
> >
> >  
> >
> Correct
> 

Great.

Except it's  bbox.xMin, etc, not bbox->xMin  :)

> >
> >I'll be able to apply your patch in the next day or two, but I'm not
> >sure of a good way to test it.  Do you know of a reliable way to force
> >firefox, say, (which prints to Xprint) to select a type 3 font via
> >freetype, in such a way that ti->ttheader remains undefined, where ti is
> >a struct ft2info (ttheader is read from FT_Get_Sfnt_Table) ?  Well I
> >guess I can explicitly set the ttheader to null for testing purposes,
> >but I'm not sure about invoking the type 3 font.
> >
> >  
> >
> I guess the simpler way is to use a Type 1 font to display the web page
> (ttheader will be undefined).

I fear that won't do.  ps/psout_ft.c splits the logic, using
psout_ftpstype1.c (and ttf2pt1) if the font is type 1, psout_ftpstype3.c
if it's type3.  Maybe I'll have to try commenting out the type 1
codepath?  

Drew


More information about the xorg-modular mailing list