[ft-devel] Patch to t1load.c to handle 3-axis Multimaster fonts
While integrating FreeType2 v2.4.10 into our product, we found we needed
to quick-patch t1load.c. I asked the developer who did it to elaborate,
and he spake thus:
That patch is to fix the problem that Freetype2 does not handle the
3-axis MM font FontBBox correctly. What happens is freetype2 tries
to read the 2nd FontBBox and freetype2 does not expect there are 8
components for 3-axis MM font. So it chokes. In an earlier freetype2
version, it does not have this issue because it does not read this
2nd FontBBox. So the patch is to skip the 2nd time action and then
freetype2 is happy. As far as I can see, such 2nd time FontBBox read
is not needed for our usage.
So can we make this into the main line? Maybe not... The real fix is
deeper than this patch addresses. My 2 cents.
I am not currently in tune with the FreeType source, so I don't have a
deeper fix at hand. But I offer this patch to illustrate our current
workaround. Sorry if that's a tad lame - there's only so many hours in
a day.
Thanks,
-Del
diff -Naur freetype-2.4.10/src/type1/t1load.c freetype-2.4.10-new/src/type1/t1load.c
--- freetype-2.4.10/src/type1/t1load.c 2012-06-14 01:35:59.0 -0400
+++ freetype-2.4.10-new/src/type1/t1load.c 2012-11-29 11:27:17.677308964 -0500
@@ -1840,6 +1840,10 @@
FT_Byte *limit, *start_binary = NULL;
FT_Boolhave_integer = 0;
+/* the flag for FontBBox to prevent from reading the second */
+/* FontBBox. 0 means not got it. 1 means already had this*/
+FT_Short fbbox_flag = 0;
+
parser-root.cursor = base;
parser-root.limit = base + size;
@@ -1918,7 +1922,6 @@
{
FT_PtrDist len;
-
cur++;
parser-root.cursor = cur;
@@ -1979,6 +1982,11 @@
? T1_FIELD_DICT_PRIVATE
: T1_FIELD_DICT_FONTDICT;
+ /* specifically skip the 2nd FontBBox */
+ if (fbbox_flag == 1
+ ft_strcmp( (const char*)name, FontBBox ) == 0 )
+ break;
+
if ( !( dict keyword-dict ) )
{
FT_TRACE1(( parse_dict: found `%s' but ignoring it
@@ -2001,6 +2009,13 @@
else
return parser-root.error;
}
+
+ if ( !(parser-root.error) )
+ {
+ /* if this is FontBBox, set up the flag and later we do not read FontBBox again */
+ if ( ft_strcmp( (const char*)name, FontBBox ) == 0 )
+ fbbox_flag = 1;
+ }
}
break;
}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Infinality Release
Eric, In your integrated code you use FT_UInt for the rule scaling factor, with 1000 being a unit. This contradicts the general FreeType practice of using FT_Fixed to represent fractional numbers. I would strongly suggest switching to FT_Fixed, with 0x1 representing a unit. Then all arithmetic will follow naturally with FT_MulFix, and FT_DivFix. Thank you, Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Infinality Release
In your integrated code you use FT_UInt for the rule scaling factor, with 1000 being a unit. This contradicts the general FreeType practice of using FT_Fixed to represent fractional numbers. I would strongly suggest switching to FT_Fixed, with 0x1 representing a unit. Then all arithmetic will follow naturally with FT_MulFix, and FT_DivFix. +1 Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Infinality Release
I had originally been using floating point to handle stretching and emboldening of glyphs, which for obvious reasons Werner didn't want. So, I used 1000 because it was easier to convert to and from percentage. I'm OK converting all this over to FT_Fixed, however I think it will make maintaining it more confusing and tedious. Essentially, it's just a question of representation, not changing the values themselves. Good comments help :-) Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] New Infinality Release
You can do this:
{ DejaVu Sans, 12, Regular Class, 'm', 0.95 * 0x1L },
I think the compiler will get it. See for example
src/cff/cffload.c:1362: priv-expansion_factor = (FT_Fixed)( 0.06
* 0x1L );
src/type1/t1load.c:2091:priv-expansion_factor = (FT_Fixed)( 0.06
* 0x1L );
src/type1/t1load.c:2092:priv-blue_scale = (FT_Fixed)(
0.039625 * 0x1L * 1000 );
That's a pretty clever trick, since it happens at compile time (I'm
guessing). Should make maintaining it not so bad. ;)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
[ft-devel] Fetching bitmap strike size from GlyphSlot
Hi, I like to make cairo resize bitmap strikes when the requested and returned size are drastically different. Think about it this way: You request a glyph at size 80ppem, and FreeType returns an image at 16ppem because that's the biggest size the font had and the font is not scalable. I like to detect that and make cairo resize the image. So far, I have found no way in to detect that easily, short of finding this out myself before asking FreeType to render the glyphs. Any hints? Is this possible? Am I doomed and on my own? Cheers, -- behdad http://behdad.org/ ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Patch to t1load.c to handle 3-axis Multimaster fonts
That patch is to fix the problem that Freetype2 does not handle the 3-axis MM font FontBBox correctly. What happens is freetype2 tries to read the 2nd FontBBox and freetype2 does not expect there are 8 components for 3-axis MM font. So it chokes. In an earlier freetype2 version, it does not have this issue because it does not read this 2nd FontBBox. So the patch is to skip the 2nd time action and then freetype2 is happy. As far as I can see, such 2nd time FontBBox read is not needed for our usage. So can we make this into the main line? Maybe not... The real fix is deeper than this patch addresses. My 2 cents. I am not currently in tune with the FreeType source, so I don't have a deeper fix at hand. But I offer this patch to illustrate our current workaround. Sorry if that's a tad lame - there's only so many hours in a day. Thanks for that. However, a detailed analysis is only possible with a demo font which exhibits the problem. If you can send it (privately to me, if necessary), this would help a lot. For this reason, I can't include the patch in version 2.4.11 (which I'll release today), sorry. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
