summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDavid Turner <david@freetype.org>2002-01-07 10:40:48 +0000
committerDavid Turner <david@freetype.org>2002-01-07 10:40:48 +0000
commit6096b5a11c1c1118b0f99b0929f69b4e5b489034 (patch)
treef85a6e64d7aaddcf39f4f892abf63e1511aa68d6
parent66f894e76cb807dad10f49bb32c7a2e0301c47c3 (diff)
updating documentation
-rw-r--r--ChangeLog2
-rw-r--r--docs/BUGS178
-rw-r--r--docs/CHANGES35
-rw-r--r--include/freetype/ftimage.h4
4 files changed, 147 insertions, 72 deletions
diff --git a/ChangeLog b/ChangeLog
index 942566aa..dd1e8d1f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,7 @@
2002-01-06 David Turner <david@freetype.org>
+ * 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)
diff --git a/docs/BUGS b/docs/BUGS
index 50a32086..e3ef3da1 100644
--- a/docs/BUGS
+++ b/docs/BUGS
@@ -47,7 +47,10 @@ BAD-T1-CHARMAP 15-06-2001 David 2.0.5
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,6 +58,8 @@ AUTOHINT-NO-SBITS 13-09-2001 David 2.0.6
III. Bug descriptions
=====================
+--- START OF OPENED BUGS ---
+
NO-CID-CMAPS
@@ -63,45 +68,6 @@ NO-CID-CMAPS
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 <trmetal@yahoo.com.hk> 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
@@ -115,7 +81,8 @@ BAD-TT-RENDERING
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
@@ -125,6 +92,7 @@ BAD-THIN-LINES
FT_Outline_Render() function.
+
NOT-WINDOWS-METRICS
FreeType doesn't always return the same metrics as Windows for ascender,
@@ -133,25 +101,6 @@ NOT-WINDOWS-METRICS
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
@@ -193,6 +142,70 @@ ADVANCED-COMPOSITES
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 <trmetal@yahoo.com.hk> 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
@@ -208,4 +221,49 @@ GLYPH_TO_BITMAP-BUG
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 ===
diff --git a/docs/CHANGES b/docs/CHANGES
index 7df3ec2c..628e811a 100644
--- a/docs/CHANGES
+++ b/docs/CHANGES
@@ -26,6 +26,16 @@ LATEST CHANGES BETWEEN 2.0.6 and 2.0.5
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 @@ LATEST CHANGES BETWEEN 2.0.6 and 2.0.5
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
+
============================================================================
diff --git a/include/freetype/ftimage.h b/include/freetype/ftimage.h
index 21f320d8..408de79b 100644
--- a/include/freetype/ftimage.h
+++ b/include/freetype/ftimage.h
@@ -893,7 +893,9 @@ FT_BEGIN_HEADER
/* 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 */