kc3-lang/freetype

diff --git a/ChangeLog b/ChangeLog
index 942566a..dd1e8d1 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 50a3208..e3ef3da 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 7df3ec2..628e811 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 21f320d..408de79 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 */