[ft-devel] A few tiny patches
Hi Werner Co.
Here's a small set of patches I'd like to get in to the official tree.
#1 a broken glyph in a font file that Acrobat allows, but
freetype doesn't: allow for a trailing empty contour
diff -u base/ftoutln.c s:\l\cdoc\src\ftype/ftoutln.c
--- base/ftoutln.c Mon Jul 18 23:20:00 2011
+++ s:\l\cdoc\src\ftype/ftoutln.c Mon Aug 23 20:25:28 2010
@@ -366,7 +366,9 @@
end = outline-contours[n];
/* note that we don't accept empty contours */
-if ( end = end0 || end = n_points )
+/* Acrobat allows this broken glyph, trailing empty contour */
+
+if ( /*end = end0 ||*/ end = n_points )
goto Bad;
end0 = end;
#2 cff font with a funky matrix, running scaling logic where scaling == 0 is
bad news
diff -u cff/cffparse.c s:\l\cdoc\src\ftype/cffparse.c
--- cff/cffparse.cMon Aug 15 20:20:34 2011
+++ s:\l\cdoc\src\ftype/cffparse.c Mon Aug 15 20:27:51 2011
@@ -470,7 +470,9 @@
scaling = -scaling;
- if ( scaling 0 || scaling 9 )
+ /* scaling == 0 is bad */
+
+ if ( scaling = 0 || scaling 9 )
{
/* Return default matrix in case of unlikely values. */
#3 The host software uses the incremental interface, and in one case
can stomp on itself due to convolutions in the font. Save restore the stream:
diff -u truetype/ttgload.c s:\l\cdoc\src\ftype/ttgload.c
--- truetype/ttgload.c Mon Jul 18 23:20:00 2011
+++ s:\l\cdoc\src\ftype/ttgload.c Tue Jul 19 00:35:38 2011
@@ -1231,6 +1231,7 @@
FT_StreamRecinc_stream;
FT_Data glyph_data;
FT_Bool glyph_data_loaded = 0;
+FT_Stream saved_stream = 0; /* saverestore */
#endif
@@ -1290,6 +1291,7 @@
FT_Stream_OpenMemory( inc_stream,
glyph_data.pointer, glyph_data.length );
+ saved_stream = loader-stream;/* saverestore */
loader-stream = inc_stream;
}
else
@@ -1610,6 +1612,9 @@
face-root.internal-incremental_interface-funcs-free_glyph_data(
face-root.internal-incremental_interface-object,
glyph_data );
+
+if ( face-root.internal-incremental_interface saved_stream )
+ loader-stream = saved_stream;/* saverestore */
#endif
Let me know if you have any questions or need more info.
Thanks!
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: Re: [ft-devel] CFF subfont matrix problem
Werner LEMBERG wrote: Hmm. Please have a look at this thread: http://lists.gnu.org/archive/html/freetype-devel/2005-04/msg00059.html and look at the 2048.cff font which is attached to it. This is a font which converts 2048 to 1000 font units in the subfont, but it lacks a top-dict font matrix. On the other hand, Ding Li's test font from http://lists.gnu.org/archive/html/freetype-devel/2008-03/msg00017.html has a both a top-level and subfont font matrix; the former is the standard [0.001 0 0 0.001], while the latter is [1 0 0 1]; with other words, it only gives decent results if you concatenate the matrices. Assuming that both those fonts have been extracted from documents which correctly work with Acroread (Ding Li, Dirck, please confirm) I assume that it has some heuristic code to either select [1 0 0 1] or [0.001 0 0 0.001] as the top-level matrix. Hi Werner, The original font in the PDF file worked correctly in Acrobat. It looks like the PDF file was produced from a OneVision product named Asura, but I don't know what the source material was. The PLRM mentions that when constructing a CID type 0 composite font, the upper level font matrix is set to .001 etc and the lower level matrices are multiplied by 1000. Not sure how this relates to CFF fonts or how they are constructed by the relevant tools. Our system has some heuristics for selecting the 1 or .001 matrix, but I thought it was an artifact of some other impedance mismatch problem in our architecture. It can be quite frustrating. Wish I could be more helpful, d ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] FT_LOAD_FORCE_AUTOHINT and FT_LOAD_FORCE_AUTOHINT
Werner LEMBERG wrote: Well, saying ftgrid -f 1915 20 EPPGLH+DFHSMincho-W3-WIN-RKSJ-H.ttf I get image A. Pressing the `h' key I get image B. BTW, I've compiled FreeType with `make devel', so the images use the native TT bytecode interpreter. That's why it works for Werner - I run into this problem periodically. These kinds of fonts require the native TT bytecode interpreter (#define TT_CONFIG_OPTION_BYTECODE_INTERPRETER) and hinting. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Some fragmentized characters.
DingLi(丁力) wrote: Hello, everyone: When I use Freetype, I found that some phenomenon that some fragmentized characters. For example, the mingliu.tcc(True Collection), is it a bug? Thanks. Bigpin This looks like a bug that I've run into in the past with some asian fonts. They work ok if: #define TT_CONFIG_OPTION_BYTECODE_INTERPRETER is defined in ftoption.h, and if hinting is enabled (no FT_LOAD_NO_HINTING) in the call to FT_Load_Glyph. ___ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
