ref: 6096b5a11c1c1118b0f99b0929f69b4e5b489034
parent: 66f894e76cb807dad10f49bb32c7a2e0301c47c3
author: David Turner <[email protected]>
date: Mon Jan 7 05:40:48 EST 2002
updating documentation
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,7 @@
2002-01-06 David Turner <[email protected]>
+ * docs/BUGS, docs/CHANGES: updating documentation for 2.0.6 release
+
* include/freetype/config/ftoption.h: setting default options for
a release build (debugging off, bytecode interpreter off)
--- a/docs/BUGS
+++ b/docs/BUGS
@@ -47,7 +47,10 @@
BAD-UNIXXXX-NAMES 30-07-2001 David 2.0.5
GLYPH_TO_BITMAP-BUG 05-12-2001 David 05-12-2001
AUTOHINT-NO-SBITS 13-09-2001 David 2.0.6
-
+TT-GLYPH-CRASH 01-01-2002 David 2.0.6
+T1-FONT-CRASH 01-01-2002 David 2.0.6
+BAD-ADVANCES 30-11-2001 David 2.0.6
+GLYPH-TO-BITMAP-BUG 15-12-2001 David 2.0.6
--------------------END-OF-CLOSED-BUGS-TABLE----------------------------------
@@ -55,7 +58,9 @@
III. Bug descriptions
=====================
+--- START OF OPENED BUGS ---
+
NO-CID-CMAPS
Not exactly a bug, but the CFF font driver doesn't build a Unicode charmap
@@ -63,46 +68,7 @@
this format.
-BAD-TTNAMEID.H
- The file "ttnameid.h" contains various constant macro definitions
- corresponding to important values defined by the TrueType specification.
-
- Joe Man <[email protected]> reports that:
-
- According to the information from TrueType v1.66:
-
- Platform ID = 3 (Microsoft)
- the Encoding ID of GB2312 = 4
- the Encoding ID of big5 = 3
-
- However, I have found that in ttnameid.h:
-
- TT_MS_ID_GB2312 = 3
- TT_MS_ID_BIG_5 = 4
-
- Which one is correct?
-
- Antoine replied that this was a bug in the TT 1.66 specification, and that
- FreeType followed the most recent TrueType/OpenType specification here.
-
-
-AUTOHINT-SBITS
-
- When trying to load a glyph, with the auto-hinter activated (i.e., when
- using FT_LOAD_FORCE_AUTOHINT, or when the font driver doesn't provide its
- own hinter), embedded bitmaps are _never_ loaded, unlike the default
- behaviour described by the API specification.
-
- This seems to be a bug in FT_Load_Glyph(), but there is no way to solve it
- efficiently without making a few important internal changes to the
- library's design (more importantly, to the font driver interface).
-
- This has been corrected with a hack in FT_Load_Glyph(). More important
- internal changes should help get rid of it with a clean solution in a
- further release like FreeType 2.1.
-
-
BAD-TT-RENDERING
According to Paul Pedriana <[email protected]>, there is a rather
@@ -115,9 +81,10 @@
Some of this has been fixed in 2.0.6; there was a bug in the TrueType
loader that prevented it from loading composites correctly. However,
there are still _subtle_ differences between FT1 and FT2 when it comes to
- monochrome TrueType-hinted glyphs.
+ monochrome TrueType-hinted glyphs (the major differences are gone though !!)
+
BAD-THIN-LINES
It seems that the anti-aliased renderer in FreeType has problems rendering
@@ -125,6 +92,7 @@
FT_Outline_Render() function.
+
NOT-WINDOWS-METRICS
FreeType doesn't always return the same metrics as Windows for ascender,
@@ -133,26 +101,7 @@
rounding bug when computing the "x_scale" and "y_scale" values.
-BAD-T1-CHARMAP
- Type1 driver doesn't read "cacute" and "lslash" characters from iso8859-2
- charset. Those characters are mapped as MAC-one in glnames.py, so they
- cannot be shown in Adobe Type1 fonts.
-
- (This was due to a bug in the "glnames.py" script used to generate the
- table of glyph names in 'src/psaux/pstables.h'.)
-
-
-BAD-UNIXXXX-NAMES
-
- Glyph names like uniXXXX are not recognized as they should be. It seems
- that code in psmodule.c for uniXXXX glyph names was never tested. The
- patch is very simple.
-
- (A simple bug that was left un-noticed due to the fact that I don't have
- any Postscript font that use this convention, unfortunately.)
-
-
ADVANCED-COMPOSITES
Provided by George Williams <[email protected]>:
@@ -193,6 +142,70 @@
for "load_flag", some other way to set preferences is probably needed.
+
+--- END OF OPENED BUGS ---
+
+
+BAD-TTNAMEID.H
+
+ The file "ttnameid.h" contains various constant macro definitions
+ corresponding to important values defined by the TrueType specification.
+
+ Joe Man <[email protected]> reports that:
+
+ According to the information from TrueType v1.66:
+
+ Platform ID = 3 (Microsoft)
+ the Encoding ID of GB2312 = 4
+ the Encoding ID of big5 = 3
+
+ However, I have found that in ttnameid.h:
+
+ TT_MS_ID_GB2312 = 3
+ TT_MS_ID_BIG_5 = 4
+
+ Which one is correct?
+
+ Antoine replied that this was a bug in the TT 1.66 specification, and that
+ FreeType followed the most recent TrueType/OpenType specification here.
+
+
+AUTOHINT-SBITS
+
+ When trying to load a glyph, with the auto-hinter activated (i.e., when
+ using FT_LOAD_FORCE_AUTOHINT, or when the font driver doesn't provide its
+ own hinter), embedded bitmaps are _never_ loaded, unlike the default
+ behaviour described by the API specification.
+
+ This seems to be a bug in FT_Load_Glyph(), but there is no way to solve it
+ efficiently without making a few important internal changes to the
+ library's design (more importantly, to the font driver interface).
+
+ This has been corrected with a hack in FT_Load_Glyph(). More important
+ internal changes should help get rid of it with a clean solution in a
+ further release like FreeType 2.1.
+
+
+BAD-T1-CHARMAP
+
+ Type1 driver doesn't read "cacute" and "lslash" characters from iso8859-2
+ charset. Those characters are mapped as MAC-one in glnames.py, so they
+ cannot be shown in Adobe Type1 fonts.
+
+ (This was due to a bug in the "glnames.py" script used to generate the
+ table of glyph names in 'src/psaux/pstables.h'.)
+
+
+BAD-UNIXXXX-NAMES
+
+ Glyph names like uniXXXX are not recognized as they should be. It seems
+ that code in psmodule.c for uniXXXX glyph names was never tested. The
+ patch is very simple.
+
+ (A simple bug that was left un-noticed due to the fact that I don't have
+ any Postscript font that use this convention, unfortunately.)
+
+
GLYPH_TO_BITMAP-BUG
Calling FT_Glyph_To_Bitmap() sometimes modifies the original glyph
@@ -207,5 +220,50 @@
The same bug has been fixed in src/raster/ftrender1.c also.
+
+
+TT-GLYPH-CRASH
+
+ The library crashed when trying to load certain glyphs from an
+ automatically generated TrueType file (tt1095m_.ttf submitted by
+ Scott Long).
+
+ It turned out that the font contained invalid glyph data (i.e. was broken),
+ but the TrueType glyph loader in FreeType wasn't paranoid enough, which
+ resulted in nasty memory overwrites all over the place.
+
+
+
+T1-FONT-CRASH
+
+ The library crashed when trying to load the "Stalingrad Regular" face
+ from the "sadn.pfb" font file provided by Anthony Fok (and the Gnome-Print
+ team I believe).
+
+ This was due to the fact that the font missed a full font name entry,
+ though boasted a family name and postscript name. The Type 1 face loader
+ didn't check for these pathetic cases and seg-faulted..
+
+
+
+BAD-ADVANCES
+
+ All scalable font drivers returned un-fitted glyph advances when
+ FT_LOAD_DEFAULT was used, which was incorrect. This problem was pretty
+ old but hadn't been spotted because all test programs actually
+ explicitely or implicitely (i.e. through the cache) rounded the advance
+ widths of glyphs..
+
+ This resulted in poor rendering of a number of client applications
+ however (it's strange to see they took so long to notice the devel team ?)
+
+
+
+GLYPH-TO-BITMAP-BUG
+
+ the FT_Glyph_ToBitmap did incorrectly modify the source glyph in certain
+ cases, which resulted in random behaviour and bad text rendering. This was
+ spotted to bugs in both the monochrome and smooth rasterizer..
+
=== end of file ===
--- a/docs/CHANGES
+++ b/docs/CHANGES
@@ -26,6 +26,16 @@
names for certain glyphs.
+ - the library crashed when loading certain Type 1 fonts like "sadn.pfb"
+ ("Stalingrad Normal"), which appear to contain pathetic font info+ dictionaries..
+
+ - the TrueType glyph loader is now much more paranoid and checks everything
+ when loading a given glyph image. This was necessary to avoid problems
+ (crashes and/or memory overwrites) with broken fonts that came from a
+ really buggy automatic font converter..
+
+
II. IMPORTANT UPDATES AND NEW FEATURES
- Important updates to the Mac-specific parts of the library.
@@ -70,17 +80,20 @@
These are most probably due to small differences in the monochrome
rasterizers and will be worked out in an upcoming release.
- - The next release will be named FreeType 2.1, and will include a
- _major_ rework of the library's internals, both to make the source
- code more consistent, readable, etc. as well as to implement new
- features like:
- - sub-pixel filtering ("ClearType" and "CoolType" like)- - gamma-correction
- - dynamic version and features retrieval
- - important enhancements to the auto-hinter
- - important enhancements to the monochrome rasterizer
- (especially for Postscript-based formats)
+ - We have decided to fork the sources in a "stable" branch, and an
+ "unstable" one, since FreeType is becoming a critical component of
+ many Unix systems.
+
+ The next bug-fix releases of the library will be named 2.0.7,
+ 2.0.8, etc.. while the "2.1" branch will contain a version of the
+ sources where we'll start major reworking of the library's internals,
+ in order to produce FreeType 2.2.0 (or even 3.0) in a more distant
+ future.
+
+ We also hope that this scheme will allow much more frequent releases
+ than in the past
+
============================================================================
--- a/include/freetype/ftimage.h
+++ b/include/freetype/ftimage.h
@@ -893,7 +893,9 @@
/* callback. */
/* */
/* clip_box :: an optional clipping box. It is only used in */
- /* direct rendering mode */
+ /* direct rendering mode. Note that coordinates */
+ /* here should be expressed in _integer_ pixels */
+ /* (and not 26.6 fixed-point units) */
/* */
/* <Note> */
/* An anti-aliased glyph bitmap is drawn if the ft_raster_flag_aa bit */