Since we consider `sbw' for the horizontal direction only, we still have
to synthesize vertical metrics if the user wants to use the vertical
writing direction.
* src/cff/cffgload.c (cff_slot_load), src/cid/cidgload.c
(cid_slot_load_glyph), src/type1/t1gload.c (T1_Load_Glyph):
Synthesize vertical metrics (only) if FT_LOAD_VERTICAL_LAYOUT is
set.
After long discussion, we now consider the character width vector
(wx,wy) returned by the `sbw' Type 1 operator as being part of *one*
direction only. For example, if you are using the horizontal
writing direction, you get the horizontal and vertical components of
the advance width for this direction. Note that OpenType and CFF fonts
don't have such a vertical component; instead, the GPOS table can be
used to generate two-dimensional advance widths (but this isn't
handled by FreeType).
* include/freetype/ftincrem.h (FT_Incremental_MetricsRec): Add
`advance_v' field to hold the vertical component of the advance
value.
* src/truetype/ttgload.c (tt_get_metrics), src/cff/cffgload.c
(cff_slot_load), src/type1/t1gload.c
(T1_Parse_Glyph_And_Get_Char_String), src/cid/cidgload.c
(cid_load_glyph): Use it.
Issue #28226 involved a work-around for a font which used the
`setcurrentpoint' operator in an invalid way; this operator is only
supposed to be used with the result of OtherSubrs, and the font used
it directly. The supplied patch removed the block of code which
checked this usage entirely.
This turns out to be a Bad Thing. If `setcurrentpoint' is being
used correctly it should reset the flex flag in the decoder. If we
don't do this then the flag never gets reset and we omit any further
contours from the glyph (at least until we close the path or
similar).
* src/psaux/t1decode.c (t1_decoder_parse_charstrings)
<op_setcurrentpoint>: Handle `flex_state' correctly.
Ghostscript requires the incremental font interface for handling
some Postscript documents. It is moving to using FreeType as its
primary renderer; supporting this in the default build makes it
Ghostscript to be linked against the system FreeType when one is
available.
* include/freetype/config/ftoption.h (FT_CONFIG_OPTION_INCREMENTAL):
Uncomment.
* src/base/ftglyph.c (FT_Glyph_To_Bitmap) [FT_CONFIG_OPTION_PIC]:
Declare `library' for FT_BITMAP_GLYPH_CLASS_GET.
* src/base/ftinit.c (ft_destroy_default_module_classes,
ft_create_default_module_classes): Use proper casts (needed for C++
compilation).
* src/sfnt/ttcmap.c (tt_cmap13_class_rec): Use FT_DEFINE_TT_CMAP.
Reported by Sean.
* src/base/ftdbgmem.c [!FT_DEBUG_MEMORY]: ANSI C doesn't like empty
source files; however, some compilers warn about an unused variable
declaration. This is now replaced with a typedef.
There exist corrupt, subsetted fonts (embedded in PDF files) which
contain a private dict that ends with an unterminated floating point
number (no operator following). We now ignore this error (as
acrobat does).
* src/cff/cffparse.c (cff_parser_run): Don't emit a syntax error for
unterminated floating point numbers.
This fixes Savannah bug #28226.
At least two wild PostScript files of unknown provenance contain
Type 1 fonts, apparently converted from TrueType fonts in earlier
PDF versions of the files, which use the `setcurrentpoint' operator
inappropriately.
FreeType currently throws an error in this case, but Ghostscript and
Adobe Distiller both accept the fonts and ignore the problem. This
commit #ifdefs out the check so PostScript interpreters using
FreeType can render these files.
The specification says `setcurrentpoint' should only be used to set
the point after a `Subr' call, but these fonts use it to set the
initial point to (0,0). Unnecessarily so, as they correctly use an
`hsbw' operation which implicitly sets the initial point.
Werner Lemberg