1
List of known FreeType 2 Bugs
2
-----------------------------
4
"Identifier" is a string to uniquely identify the bug. A more detailed
5
description of the bug is found below the table of opened bugs.
7
"Date" is the date when the bug was first reported or entered in this
8
document. Dates are in _European_ format, i.e day/month/year.
10
"Opened By" is the name of the person who first spotted the bug. Note that
11
we can use abbreviations here, like:
13
"David" for David Turner
14
"Werner" for Werner Lemberg
17
"Reproduceable" indicates whether the bug could be reproduced by the
18
development team or not (it can be specific to a given platform), whether it
19
always happens, or only sporadically, etc.
27
Identifier Date Opened by Reproduceable
28
------------------------------------------------------------------------------
29
NO-CID-CMAPS 13-09-2001 David always
30
BAD-TT-RENDERING 12-09-2001 Paul Pedriana ?
31
BAD-THIN-LINES 13-09-2001 David ?
32
NOT-WINDOWS-METRICS 07-10-2001 David always
33
ADVANCED-COMPOSITES 25-10-2001 George Williams always
35
--------------------END-OF-OPENED-BUGS-TABLE----------------------------------
43
Identifier Date Closed by Closure date
44
------------------------------------------------------------------------------
45
BAD-TTNAMEID.H 12-09-2001 Antoine N/A
46
BAD-T1-CHARMAP 15-06-2001 David 2.0.5
47
BAD-UNIXXXX-NAMES 30-07-2001 David 2.0.5
48
GLYPH_TO_BITMAP-BUG 05-12-2001 David 05-12-2001
49
AUTOHINT-NO-SBITS 13-09-2001 David 2.0.6
50
TT-GLYPH-CRASH 01-01-2002 David 2.0.6
51
T1-FONT-CRASH 01-01-2002 David 2.0.6
52
BAD-ADVANCES 30-11-2001 David 2.0.6
53
GLYPH-TO-BITMAP-BUG 15-12-2001 David 2.0.6
54
--------------------END-OF-CLOSED-BUGS-TABLE----------------------------------
62
--- START OF OPEN BUGS ---
67
Not exactly a bug, but the CFF font driver doesn't build a Unicode charmap
68
from the contents of font files, which prevents efficiently using fonts in
75
According to Paul Pedriana <PPedriana@maxis.com>, there is a rather
76
important difference between the rendering of TrueType-hinted glyphs of
77
current FT2 and old betas.
79
Tests and comparisons show a _major_ discrepancy of monochrome truetype
80
bytecode-hinted glyphs! Something seems to be really broken here!
82
Some of this has been fixed in 2.0.6; there was a bug in the TrueType
83
loader that prevented it from loading composites correctly. However,
84
there are still _subtle_ differences between FT1 and FT2 when it comes to
85
monochrome TrueType-hinted glyphs (the major differences are gone though).
91
It seems that the anti-aliased renderer in FreeType has problems rendering
92
extremely thin straight lines correctly, at least when using the
93
FT_Outline_Render() function.
99
FreeType doesn't always return the same metrics as Windows for ascender,
100
descender, and text height, depending on character pixel sizes. A lot of
101
testing on Windows is needed to debug this properly. It might be due to a
102
rounding bug when computing the "x_scale" and "y_scale" values.
108
Provided by George Williams <pfaedit@users.sourceforge.net>:
110
I notice that truetype/ttgload.c only supports Apple's definition of
111
offsets for composite glyphs. Apple and Microsoft behave differently if
112
there is a scale factor. OpenType defines some bits to disambiguate.
114
(A problem in both 2.0.4 and 2.0.5.)
116
Apple says (http://fonts.apple.com/TTRefMan/RM06/Chap6glyf.html) that if
117
flags&ARGS_ARE_XY is set then the offsets should be scaled by the scale
118
factors (as you have done), but they also say something very cryptic
119
about what happens when the component is rotated at 45� (which you do
120
not support) -- See the "Important" note at the bottom.
122
The old truetype spec from Microsoft did not mention this. The OpenType
123
spec (http://www.microsoft.com/typography/otspec/glyf.htm,
124
http://partners.adobe.com/asn/developer/opentype/glyf.html) defines two
125
new bits to disambiguate:
127
SCALED_COMPONENT_OFFSET 11
128
Composite designed to have the component offset scaled (designed for
131
UNSCALED_COMPONENT_OFFSET 12
132
Composite designed not to have the component offset scaled (designed
133
for the Microsoft TrueType rasterizer)
135
Perhaps you could add a load_flag to allow the user to define the
140
Wow, I was not even aware of this, it will probably take a little time
141
to implement since I don't have any font that implement these
142
"features", and also because I believe that we're running out of bits
143
for "load_flag", some other way to set preferences is probably needed.
147
--- END OF OPEN BUGS ---
153
The file "ttnameid.h" contains various constant macro definitions
154
corresponding to important values defined by the TrueType specification.
156
Joe Man <trmetal@yahoo.com.hk> reports that:
158
According to the information from TrueType v1.66:
160
Platform ID = 3 (Microsoft)
161
the Encoding ID of GB2312 = 4
162
the Encoding ID of big5 = 3
164
However, I have found that in ttnameid.h:
169
Which one is correct?
171
Antoine replied that this was a bug in the TT 1.66 specification, and that
172
FreeType followed the most recent TrueType/OpenType specification here.
178
When trying to load a glyph, with the auto-hinter activated (i.e., when
179
using FT_LOAD_FORCE_AUTOHINT, or when the font driver doesn't provide its
180
own hinter), embedded bitmaps are _never_ loaded, unlike the default
181
behaviour described by the API specification.
183
This seems to be a bug in FT_Load_Glyph(), but there is no way to solve it
184
efficiently without making a few important internal changes to the
185
library's design (more importantly, to the font driver interface).
187
This has been corrected with a hack in FT_Load_Glyph(). More important
188
internal changes should help get rid of it with a clean solution in a
189
further release like FreeType 2.1.
195
Type1 driver doesn't read "cacute" and "lslash" characters from iso8859-2
196
charset. Those characters are mapped as MAC-one in glnames.py, so they
197
cannot be shown in Adobe Type1 fonts.
199
(This was due to a bug in the "glnames.py" script used to generate the
200
table of glyph names in 'src/psaux/pstables.h'.)
206
Glyph names like uniXXXX are not recognized as they should be. It seems
207
that code in psmodule.c for uniXXXX glyph names was never tested. The
208
patch is very simple.
210
(A simple bug that was left un-noticed due to the fact that I don't have
211
any Postscript font that use this convention, unfortunately.)
217
Calling FT_Glyph_To_Bitmap() sometimes modifies the original glyph
218
outline, creating weird alignment artefacts.
220
This subtle bug was really in the file `src/smooth/ftsmooth.c'.
221
Basically, the outline was shifted before rendering it into a new bitmap
222
buffer. However, it wasn't properly un-shifted after that operation.
224
This was only noticeable with certain glyphs or certain fonts; it crept in
227
The same bug has been fixed in src/raster/ftrender1.c also.
233
The library crashed when trying to load certain glyphs from an
234
automatically generated TrueType file (tt1095m_.ttf submitted by Scott
237
It turned out that the font contained invalid glyph data (i.e. was
238
broken), but the TrueType glyph loader in FreeType wasn't paranoid enough,
239
which resulted in nasty memory overwrites all over the place.
245
The library crashed when trying to load the "Stalingrad Regular" face from
246
the "sadn.pfb" font file provided by Anthony Fok (and the Gnome-Print team
249
This was due to the fact that the font missed a full font name entry,
250
though boasted a family name and postscript name. The Type 1 face loader
251
didn't check for these pathetic cases and seg-faulted.
257
All scalable font drivers returned un-fitted glyph advances when
258
FT_LOAD_DEFAULT was used, which was incorrect. This problem was pretty
259
old but hadn't been spotted because all test programs actually explicitly
260
or implicitly (i.e. through the cache) rounded the advance widths of
263
This resulted in poor rendering of a number of client applications however
264
(it is strange to see they took so long to notify the FreeType team).
270
FT_Glyph_To_Bitmap() did incorrectly modify the source glyph in certain
271
cases, which resulted in random behaviour and bad text rendering. This
272
was spotted to bugs in both the monochrome and smooth rasterizer.