On LLP64 platforms (e.g. Win64), long (32-bit) cannot cover
the memory address (64-bit). Also the casts from the pointer
type to long int should be removed to preserve the address
correctly.
* src/raster/ftraster.c (New_Profile): Replace "%lx" by "%p".
(End_Profile) Ditto.
* src/truetype/ttinterp.c (Init_Context): Ditto.
* src/truetype/ttpload.c (tt_face_get_location): If `pos1', the
offset to the requested entry in `glyf' exceeds the end of the
table, return offset=0, length=0. If `pos2', the offset to the
next entry in `glyf' exceeds the end of the table, truncate
the entry length at the end of `glyf' table.
See Savannah bug #31040.
* src/truetype/ttinterp.c (free_buffer_in_size): Don't duplicate
FT_GlyphZoneRec size->twilight to be freed. If duplicated,
FT_FREE() erases the duplicated pointers only and leave original
pointers. They can cause the double-free crash when the burst
errors occur in TrueType interpreter and free_buffer_in_size()
is invoked repeatedly. See Savannah bug #31040 for detail.
* src/truetype/ttinterp.c (TT_RunIns): Decrease the trace level
showing the error when the interpreter returns with an error,
from FT_TRACE7() to FT_TRACE1().
* src/truetype/ttinterp.c (free_buffer_in_size): New function to
free the buffer allocated during the interpretation of this glyph.
(TT_RunIns): Unset FT_Face->size->{cvt_ready,bytecode_ready} if
an error occurs in the bytecode interpretation. The interpretation
of invalid bytecode may break the function definitions and referring
them in later interpretation is danger. By unsetting these flags,
`fpgm' and `prep' tables are executed again in next interpretation.
Fix Savannah bug #30798, reported by Robert Swiecki.
* src/truetype/ttinterp.c (BOUNDSL): New macro.
Change `BOUNDS' to `BOUNDSL' where appropriate.
* src/truetype/ttinterp.h (TT_ExecContextRec): Fix type of
`cvtSize'.
Acroread does the same.
* src/truetype/ttgload.c (TT_Process_Composite_Glyph): Call
`Update_Max' to adjust size of instructions array if necessary and
add a rough safety check.
(load_truetype_glyph): Save `loader->byte_len' before recursive
call.
* src/truetype/ttinterp.h, src/truetype/ttinterp.c (Update_Max):
Declare it as FT_LOCAL.
Initialize phantom points before calling the incremental interface
to update glyph metrics.
* src/truetype/ttgload.c (tt_get_metrics_incr_overrides)
[FT_CONFIG_OPTION_INCREMENTAL]: New function, split off from...
(tt_get_metrics): This.
Updated.
(load_truetype_glyph): Use tt_get_metrics_incr_overrides.
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.
Reported by Jeremy Manson <jeremy.manson@gmail.com>.
src/truetype/ttgload.c (load_truetype_glyph): Add parameter to
quickly load the glyph header only.
Update all callers.
(tt_loader_init): Add parameter to quickly load the `glyf' table
only.
Update all callers.
(TT_Load_Glyph): Compute linear advance values for embedded bitmap
glyphs too.
The calculation of `vertBearingX' is not defined in the OTF font
spec so FreeType does a `best effort' attempt. However, this value
is defined in the PDF and PostScript specs, and that algorithm is
better than the one FreeType currently uses:
FreeType: Use the middle of the bounding box as the X coordinate
of the vertical origin.
Adobe PDF spec: Use the middle of the horizontal advance vector as
the X coordinate of the vertical origin.
FreeType's algorithm goes wrong if you have a really small glyph
(like the full-width, circle-like dot at the end of the sentence, as
used in CJK scripts) with large bearings. With the FreeType
algorithm this dot gets centered on the baseline; with the PDF
algorithm it gets the correct location (in the top right). Note
that this is a serious issue, it's like printing the dot at the end
of a Roman sentence at the center of the textline instead of on the
baseline like it should. So i believe the PDF spec's algorithm
should be used in FreeType as well.
The `vertBearingY' value for such small glyphs is also very strange
if no `vmtx' information is present, since the height of the bbox is
not representable for the height of the glyph visually (the
whitespace up to the baseline is part of the glyph). The fix also
includes some code for a better estimate of `vertBearingY'.
* src/base/ftobjs.c (ft_synthesize_vertical_metrics): `vertBearingX'
is now calculated as described by the Adobe PDF Spec. Estimate for
`vertBearingY' now works better for small glyphs completely above or
below the baseline into account.
* src/cff/cffgload.c (cff_slot_load): `vertBearingX' is now
calculated as described by the Adobe PDF Spec. Vertical metrics
information was always ignored when FT_CONFIG_OPTION_OLD_INTERNALS
was not defined.
* src/truetype/ttgload.c (compute_glyph_metrics): `vertBearingX' is
now calculated as described by the Adobe PDF Spec.
