I. IMPORTANT BUG FIXES
- A variant of vulnerability CVE-2014-2240 was identified
(cf. http://savannah.nongnu.org/bugs/?43661) and fixed in the
new CFF driver. All users should upgrade.
- The new auto-hinter code using HarfBuzz crashed for some invalid
fonts.
- Many fixes to better protect against malformed input.
II. IMPORTANT CHANGES
- Full auto-hinter support of the Devanagari script.
- Experimental auto-hinter support of the Telugu script.
- CFF stem darkening behaviour can now be controlled at build time
using the eight macros
CFF_CONFIG_OPTION_DARKENING_PARAMETER_{X,Y}{1,2,3,4} .
- Some fields in the `FT_Bitmap' structure have been changed from
signed to unsigned type, which better reflects the actual usage.
It is also an additional means to protect against malformed
input.
This change doesn't break the ABI; however, it might cause
compiler warnings.
III. MISCELLANEOUS
- Improvements to the auto-hinter's algorithm to recognize stems
and local extrema.
- Function `FT_Get_SubGlyph_Info' always returned an error even in
case of success.
- Version 2.5.1 introduced major bugs in the cjk part of the
auto-hinter, which are now fixed.
- The `FT_Sfnt_Tag' enumeration values have been changed to
uppercase, e.g. `FT_SFNT_HEAD'. The lowercase variants are
deprecated. This is for orthogonality with all other
enumeration (and enumeration-like) values in FreeType.
- `cmake' now supports builds of FreeType as an OS X framework and
for iOS.
- Improved project files for vc2010, introducing a property file.
- The documentation generator for the API reference has been
updated to produce better HTML code (with proper CSS). At the
same time, the documentation got a better structure.
- The FT_LOAD_BITMAP_CROP flag is obsolete; it is not used by any
driver.
- The TrueType DELTAP[123] bytecode instructions now work in
subpixel hinting mode as described in the ClearType whitepaper
(i.e., for touched points in the non-subpixel direction).
- Many small improvements to the internal arithmetic routines.
FreeType 2.5.3
2014-03-08
FreeType 2.5.3 has been released. All users should upgrade due to fixed
vulnerability in the CFF driver (CVE-2014-2240).
Its main new feature is much enhanced support of auto-hinting SFNT fonts
(i.e., TrueType and CFF fonts) due to the use of the HarfBuzz library.
A more detailed description of this and other changes can be found here.
FreeType 2.5.2
2013-12-08
FreeType 2.5.2 has been released. It fixes a serious bug introduced
in version 2.5.1; all users should upgrade.
A listing of the changes can be found here.
FreeType 2.5.1
2013-11-25
FreeType 2.5.1 has been released, providing three major new features.
- Support for the WOFF font format, contributed by Behdad Esfahbod.
- The auto-hinter now supports Hebrew, together with improved support
for Cyrillic and Greek.
- The directory layout of the (installed) FreeType header files has
been simplified.
Among other changes I want to mention that FreeType's TrueType debugger
(ttdebug) has been made more versatile. An exhaustive list of changes
can be found here.
FreeType 2.5
2013-06-19
FreeType 2.5 has been released. A major new feature is support for
color embedded bitmaps (eg. color emoji), contributed by Behdad Esfahbod
on behalf of Google. Additionally, Adobe's CFF engine is now the default,
which makes a good reason to change from the 2.4.x to the 2.5.x series.
On the technical side, the property API to access FreeType module
parameters (FT_Property_Set and FT_Property_Get) is now declared as
stable.
As usual, see this file for the complete release notes, which give
more details. And we have again blog entries from Adobe and Google.
FreeType 2.4.12
2013-05-08
FreeType 2.4.12 has been released. A major new feature is a new parsing
and hinting engine for CFF fonts, contributed by Adobe in collaboration
with Google. It was my job the last few months to fully adapt the code
to FreeType, and we are very pleased with the results. You might also
read the blog entries from Adobe and Google.
In connection with the new CFF engine, the demo programs, especially
ftview and ftdiff, have been improved a lot; as usual, more details
on the changes can be found in the release notes.
Reduce "freetype2" API dependence to version 2.4.5 which is what
NetBSD 6.1 and NetBSD-current ship with. This version is new enough
even for the latest "pango" package.
This fixes problems under NetBSD-current where pkgsrc tried to use
the native "fontconfig" and pkgsrc "freetype2" which doesn't work
very well.
to address issues with NetBSD-6(and earlier)'s fontconfig not being
new enough for pango.
While doing that, also bump freetype2 dependency to current pkgsrc
version.
Suggested by tron in PR 47882
This changes the buildlink3.mk files to use an include guard for the
recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS,
BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new
variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of
enter/exit marker, which can be used to reconstruct the tree and
to determine first level includes. Avoiding := for large variables
(BUILDLINK_ORDER) speeds up parse time as += has linear complexity.
The include guard reduces system time by avoiding reading files over and
over again. For complex packages this reduces both %user and %sys time to
half of the former time.
and add a new helper target and script, "show-buildlink3", that outputs
a listing of the buildlink3.mk files included as well as the depth at
which they are included.
For example, "make show-buildlink3" in fonts/Xft2 displays:
zlib
fontconfig
iconv
zlib
freetype2
expat
freetype2
Xrender
renderproto
RECOMMENDED is removed. It becomes ABI_DEPENDS.
BUILDLINK_RECOMMENDED.foo becomes BUILDLINK_ABI_DEPENDS.foo.
BUILDLINK_DEPENDS.foo becomes BUILDLINK_API_DEPENDS.foo.
BUILDLINK_DEPENDS does not change.
IGNORE_RECOMMENDED (which defaulted to "no") becomes USE_ABI_DEPENDS
which defaults to "yes".
Added to obsolete.mk checking for IGNORE_RECOMMENDED.
I did not manually go through and fix any aesthetic tab/spacing issues.
I have tested the above patch on DragonFly building and packaging
subversion and pkglint and their many dependencies.
I have also tested USE_ABI_DEPENDS=no on my NetBSD workstation (where I
have used IGNORE_RECOMMENDED for a long time). I have been an active user
of IGNORE_RECOMMENDED since it was available.
As suggested, I removed the documentation sentences suggesting bumping for
"security" issues.
As discussed on tech-pkg.
I will commit to revbump, pkglint, pkg_install, createbuildlink separately.
Note that if you use wip, it will fail! I will commit to pkgsrc-wip
later (within day).
in the process. (More information on tech-pkg.)
Bump PKGREVISION and BUILDLINK_DEPENDS of all packages using libtool and
installing .la files.
Bump PKGREVISION (only) of all packages depending directly on the above
via a buildlink3 include.
built-in or not into a separate builtin.mk file. The code to deal
checking for built-in software is much simpler to deal with in pkgsrc.
The buildlink3.mk file for a package will be of the usual format
regardless of the package, which makes it simpler for packagers to
update a package.
The builtin.mk file for a package must define a single yes/no variable
USE_BUILTIN.<pkg> that is used by bsd.buildlink3.mk to decide whether
to use the built-in software or to use the pkgsrc software.
as PREFER_PKGSRC. Preferences are determined by the most specific
instance of the package in either PREFER_PKGSRC or PREFER_NATIVE. If
a package is specified in neither or in both variables, then PREFER_PKGSRC
has precedence over PREFER_NATIVE.
Even 2.0.9 is not good enough for newer fontconfig; for example,
gtk2 won't buildlink correctly (and will use older X version of
include/freetype2/freetype/ftbdf.h) and libfontconfig needs
FT_Get_BDF_Property which is not defined.
No PKGREVISION bump is needed, because would not even build in
first place.
BUILDLINK_PREFER_PKGSRC
This variable determines whether or not to prefer the pkgsrc
versions of software that is also present in the base system.
This variable is multi-state:
defined, or "yes" always prefer the pkgsrc versions
not defined, or "no" only use the pkgsrc versions if
needed by dependency requirements
This can also take a list of packages for which to prefer the
pkgsrc-installed software. The package names may be found by
consulting the value added to BUILDLINK_PACKAGES in the
buildlink[23].mk files for that package.
