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.
Bug reported by Ivan Nincic <inincic@pdftron.com>.
* src/cff/cffgload.c (cff_slot_load): Thinko: Check `xx' element of
`font_matrix' also.
* docs/CHANGES: Updated.
* include/freetype/internal/services/svcid.h add macros to init
instances of FT_Service_CIDRec.
* include/freetype/internal/services/svpsinfo.h add macros to init
instances of FT_Service_PsInfoRec.
* src/cff/cffcmap.h declare cff_cmap_encoding_class_rec
and cff_cmap_unicode_class_rec using macros from
ftobjs.h, when FT_CONFIG_OPTION_PIC is defined create and destroy
functions will be declared.
* src/cff/cffcmap.c when FT_CONFIG_OPTION_PIC is defined
the following structs:
cff_cmap_encoding_class_rec and cff_cmap_unicode_class_rec
will have functions to init or create and destroy them
instead of being allocated in the global scope.
* src/cff/cffdrivr.h declare cff_driver_class using macros from
ftdriver.h, when FT_CONFIG_OPTION_PIC is defined create and destroy
functions will be declared.
* src/cff/cffdrivr.c when FT_CONFIG_OPTION_PIC is defined
the following structs:
cff_service_glyph_dict, cff_service_ps_info, cff_service_ps_name
cff_service_get_cmap_info, cff_service_cid_info, cff_driver_class,
and cff_services array
will have functions to init or create and destroy them
instead of being allocated in the global scope.
And macros will be used from cffpic.h in order to access them
from the pic_container.
Use macros from cffpic.h in order to access the
structs allocated in cffcmap.c
* src/cff/cffobjs.c Use macros from cffpic.h in order to access the
structs allocated in cffcmap.c
* src/cff/parser.c when FT_CONFIG_OPTION_PIC is defined
implement functions to create and destroy cff_field_handlers array
instead of being allocated in the global scope.
And macros will be used from cffpic.h in order to access it
from the pic_container.
New Files:
* src/cff/cffpic.h declare struct to hold PIC globals for cff
driver and macros to access them.
* src/cff/cffpic.c implement functions to allocate, destroy and
initialize PIC globals for cff driver.
* src/cff/cff.c add new file to build: cffpic.c.
* src/cff/jamfile add new files to FT2_MULTI build: cffpic.c.
* src/cff/cffload.c, src/cff/cffload.h, src/cff/cffobjs.c,
src/cff/cffparse.c, src/cff/cffparse.h: Add library pointer to
'CFF_ParserRec' set by `cff_parser_init'.
Route library pointer from 'cff_face_init' to 'cff_subfont_load'
for `cff_parser_init'.
* src/cff/cffparse.c (CFF_Field_Handler): Move it to...
* src/cff/cffparse.h: This file, to be used by other C files.
* include/freetype/ftcid.h (FT_Get_CID_Is_Internally_CID_keyed,
FT_Get_CID_From_Glyph_Index): New functions.
* include/freetype/internal/services/svcid.h
(FT_CID_GetIsInternallyCIDKeyedFunc,
FT_CID_GetCIDFromGlyphIndexFunc): New function typedefs.
(CID Service): Use them.
* src/base/ftcid.c: Include FT_CID_H.
(FT_Get_CID_Is_Internally_CID_keyed, FT_Get_CID_From_Glyph_Index):
New functions.
* src/cff/cffdrivr.c (cff_get_is_cid, cff_get_cid_from_glyph_index):
New functions.
(cff_service_cid_info): Add them.
* src/cff/cffload.c (cff_font_load): Don't free `font->charset.sids'
-- it is needed for access as a CID-keyed font. It gets deleted
later on.
* src/cid/cidriver.c (cid_get_is_cid, cid_get_cid_from_glyph_index):
New functions.
(cid_service_cid_info): Add them.
* docs/CHANGES: Updated.
Instead, we define a new internal PS_FontExtraRec structure to
hold the additionnal field, then place it in various internal
positions of the corresponding FT_Face derived objects.
extern const FT_Module_Class
(or similar for C++). However, the actual types of the variables
being declared are often different, e.g., FT_Driver_ClassRec or
FT_Renderer_Class. (Some are, indeed, FT_Module_Class.)
This works with most C compilers (since those structs begin with an
FT_Module_Class struct), but technically it's undefined behavior.
To quote the ISO/IEC 9899:TC2 final committee draft, section 6.2.7
paragraph 2:
All declarations that refer to the same object or function shall
have compatible type; otherwise, the behavior is undefined.
(And they are not compatible types.)
Most C compilers don't reject (or even detect!) code which has this
issue, but the GCC LTO development branch compiler does. (It
outputs the types of the objects while generating .o files, along
with a bunch of other information, then compares them when doing the
final link-time code generation pass.)
Patch from Savannah bug #25133.
* src/base/ftinit.c (FT_USE_MODULE): Include variable type.
* builds/amiga/include/freetype/config/ftmodule.h,
include/freetype/config/ftmodule.h, */module.mk: Updated to declare
pass correct types to FT_USE_MODULE.
(cff_face_done), src/pfr/pfrobjs.c (pfr_face_done),
src/pcf/pcfdrivr.c (PCF_Face_Done), src/cid/cidobjs.c
(cid_face_done), src/bdf/bdfdrivr. (BDF_Face_Done),
src/sfnt/sfobjs.c (sfnt_face_done): Protect against face == 0.
Reported by Graham Asher.
include/freetype/config/ftconfig.h, builds/unix/ftconfig.in: Minor
beautifying.
* include/freetype/ftadvanc.h, include/freetype/ftgasp.h,
include/freetype/ftlcdfil.h: Protect against FreeType 1.
Some other minor fixes.
* devel/ftoption.h: Synchronize with
include/freetype/config/ftoption.h.
Formatting, documentation improvements.
include/freetype/config/ftheader.h, include/freetype/freetype.h,
src/base/Jamfile, src/base/rules.mk, src/cff/cffdrivr.c,
src/cff/cffgload.c, src/cff/cffgload.h, src/truetype/ttdriver.c,
src/truetype/ttgload.h, src/truetype/ttgload.c, src/type1/t1driver.c,
src/type1/t1gload.h, src/type1/t1gload.c:
Add a new header named FT_ADVANCES_H declaring some new APIs
to extract the advances of one or more glyphs without necessarily
loading their outlines. Also provide 'fast loaders' for the
TrueType, Type1 and CFF font drivers (more to come later)
* autogen.sh: add checks for minimum version of the 'autotools'
stuff.
assume that the first argument on the stack is the bottom-most
element. Two reasons:
o According to people from Adobe it is missing in the Type 2
specification that pushing of additional, superfluous arguments
on the stack is prohibited.
o Acroread in general handles fonts differently, namely by popping
the number of arguments needed for a particular operand (as a PS
interpreter would do). In case of buggy fonts this causes a
different interpretation which of the elements on the stack are
superfluous and which not.
Since there are CFF subfonts (embedded in PDFs) which rely on
Acroread's behaviour, FreeType now does the same.
`dict->units_per_em' value before assigning it to
`cffface->units_per_EM'. Otherwise, CFFs without subfonts are be
scaled incorrectly if the font matrix is non-standard. This fixes
Savannah bug #23630.
* docs/CHANGES: Updated.
=========================
Tag sources with `VER-2-3-6'.
* docs/CHANGES, docs/VERSION.DLL: Update documentation and bump
version number to 2.3.6.
* README, Jamfile (RefDoc), builds/win32/visualc/index.html,
builds/win32/visualc/freetype.dsp,
builds/win32/visualc/freetype.vcproj,
builds/win32/visualce/index.html,
builds/win32/visualce/freetype.dsp,
builds/win32/visualce/freetype.vcproj: s/2.3.5/2.3.6/, s/235/236/.
* include/freetype/freetype.h (FREETYPE_PATCH): Set to 6.
* builds/unix/configure.raw (version_info): Set to 9:17:3.
* include/freetype/internal/psaux.h (T1_BuilderRec): Remove `scale_x'
and `scale_y'.
* src/cff/cffgload.h (CFF_Builder): Remove `scale_x' and `scale_y'.
* src/cff/cffparse.c: Include FT_INTERNAL_DEBUG_H.
* src/cff/cffobjs.h: Include FT_INTERNAL_POSTSCRIPT_HINTS_H.
