[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] patch requested for freetype2/internal header usage (usin
From: |
Drew Parsons |
Subject: |
Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox) |
Date: |
Tue, 24 Jan 2006 11:55:35 +1100 |
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
- [ft-devel] patch requested for freetype2/internal header usage (using font_bbox), Drew Parsons, 2006/01/22
- Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox), david turner, 2006/01/23
- Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox),
Drew Parsons <=
- Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox), david turner, 2006/01/24
- Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox), Drew Parsons, 2006/01/24
- Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox), david turner, 2006/01/24
- Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox), Drew Parsons, 2006/01/24
- Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox), David Turner, 2006/01/24
- Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox), Drew Parsons, 2006/01/25
- Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox), Drew Parsons, 2006/01/28
- Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox), Werner LEMBERG, 2006/01/28
- Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox), Drew Parsons, 2006/01/29
- Re: [ft-devel] patch requested for freetype2/internal header usage (using font_bbox), Werner LEMBERG, 2006/01/29