[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