diff options
author | David Turner <david@freetype.org> | 2002-01-07 10:40:48 +0000 |
---|---|---|
committer | David Turner <david@freetype.org> | 2002-01-07 10:40:48 +0000 |
commit | 6096b5a11c1c1118b0f99b0929f69b4e5b489034 (patch) | |
tree | f85a6e64d7aaddcf39f4f892abf63e1511aa68d6 | |
parent | 66f894e76cb807dad10f49bb32c7a2e0301c47c3 (diff) |
updating documentation
-rw-r--r-- | ChangeLog | 2 | ||||
-rw-r--r-- | docs/BUGS | 178 | ||||
-rw-r--r-- | docs/CHANGES | 35 | ||||
-rw-r--r-- | include/freetype/ftimage.h | 4 |
4 files changed, 147 insertions, 72 deletions
@@ -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) @@ -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 */ |