AuroraMiddleware/freetype
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

updating documentation

Browse Source
This commit is contained in:
David Turner 2002-01-07 10:40:48 +00:00
parent 66f894e76c
commit 6096b5a11c
4 changed files with 146 additions and 71 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
ChangeLog
View File

@ -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)

178
docs/BUGS
View File

@ -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 ===

33
docs/CHANGES
View File

@ -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
============================================================================

4
include/freetype/ftimage.h
View File

@ -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 */