source: trunk/third/freetype/docs/BUGS @ 17198

Revision 17198, 9.2 KB checked in by ghudson, 23 years ago (diff)
This commit was generated by cvs2svn to compensate for changes in r17197, which included commits to RCS files with non-trunk default branches.
Line 
1List of known FreeType 2 Bugs
2-----------------------------
3
4"Identifier" is a string to uniquely identify the bug.  A more detailed
5description of the bug is found below the table of opened bugs.
6
7"Date" is the date when the bug was first reported or entered in this
8document.  Dates are in _European_ format, i.e day/month/year.
9
10"Opened By" is the name of the person who first spotted the bug.  Note that
11we can use abbreviations here, like:
12
13  "David" for David Turner
14  "Werner" for Werner Lemberg
15  etc.
16
17"Reproduceable" indicates whether the bug could be reproduced by the
18development team or not (it can be specific to a given platform), whether it
19always happens, or only sporadically, etc.
20
21
22
23I. Open bugs
24============
25
26
27Identifier                 Date       Opened by                Reproduceable
28------------------------------------------------------------------------------
29NO-CID-CMAPS            13-09-2001     David                     always
30BAD-TT-RENDERING        12-09-2001     Paul Pedriana             ?
31BAD-THIN-LINES          13-09-2001     David                     ?
32NOT-WINDOWS-METRICS     07-10-2001     David                     always
33ADVANCED-COMPOSITES     25-10-2001     George Williams           always
34
35--------------------END-OF-OPENED-BUGS-TABLE----------------------------------
36
37
38
39II. Closed bugs
40===============
41
42
43Identifier                Date         Closed by                Closure date
44------------------------------------------------------------------------------
45BAD-TTNAMEID.H          12-09-2001     Antoine                   N/A
46BAD-T1-CHARMAP          15-06-2001     David                     2.0.5
47BAD-UNIXXXX-NAMES       30-07-2001     David                     2.0.5
48GLYPH_TO_BITMAP-BUG     05-12-2001     David                     05-12-2001
49AUTOHINT-NO-SBITS       13-09-2001     David                     2.0.6
50TT-GLYPH-CRASH          01-01-2002     David                     2.0.6
51T1-FONT-CRASH           01-01-2002     David                     2.0.6
52BAD-ADVANCES            30-11-2001     David                     2.0.6
53GLYPH-TO-BITMAP-BUG     15-12-2001     David                     2.0.6
54--------------------END-OF-CLOSED-BUGS-TABLE----------------------------------
55
56
57
58III. Bug descriptions
59=====================
60
61
62--- START OF OPEN BUGS ---
63
64
65NO-CID-CMAPS
66
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
69  this format.
70
71
72
73BAD-TT-RENDERING
74
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.
78
79  Tests and comparisons show a _major_ discrepancy of monochrome truetype
80  bytecode-hinted glyphs!  Something seems to be really broken here!
81
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).
86
87
88
89BAD-THIN-LINES
90
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.
94
95
96
97NOT-WINDOWS-METRICS
98
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.
103
104
105
106ADVANCED-COMPOSITES
107
108  Provided by George Williams <pfaedit@users.sourceforge.net>:
109
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.
113   
114    (A problem in both 2.0.4 and 2.0.5.)
115   
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.
121   
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:
126
127      SCALED_COMPONENT_OFFSET 11
128      Composite designed to have the component offset scaled (designed for
129      Apple rasterizer)
130
131      UNSCALED_COMPONENT_OFFSET 12
132      Composite designed not to have the component offset scaled (designed
133      for the Microsoft TrueType rasterizer)
134   
135    Perhaps you could add a load_flag to allow the user to define the
136    default setting?
137
138  David says:
139 
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.
144
145
146
147--- END OF OPEN BUGS ---
148
149
150
151BAD-TTNAMEID.H
152
153  The file "ttnameid.h" contains various constant macro definitions
154  corresponding to important values defined by the TrueType specification.
155
156  Joe Man <trmetal@yahoo.com.hk> reports that:
157
158    According to the information from TrueType v1.66:
159
160      Platform ID = 3 (Microsoft)
161      the Encoding ID of GB2312 = 4
162      the Encoding ID of big5 = 3
163
164    However, I have found that in ttnameid.h:
165
166      TT_MS_ID_GB2312 = 3
167      TT_MS_ID_BIG_5 = 4
168
169    Which one is correct?
170
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.
173
174
175
176AUTOHINT-SBITS
177
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.
182
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).
186
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.
190
191
192
193BAD-T1-CHARMAP
194
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.
198
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'.)
201
202
203
204BAD-UNIXXXX-NAMES
205
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.
209 
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.)
212
213
214
215GLYPH_TO_BITMAP-BUG
216
217  Calling FT_Glyph_To_Bitmap() sometimes modifies the original glyph
218  outline, creating weird alignment artefacts.
219 
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.
223
224  This was only noticeable with certain glyphs or certain fonts; it crept in
225  a long time ago.
226                 
227  The same bug has been fixed in src/raster/ftrender1.c also.
228                 
229
230
231TT-GLYPH-CRASH
232
233  The library crashed when trying to load certain glyphs from an
234  automatically generated TrueType file (tt1095m_.ttf submitted by Scott
235  Long).
236 
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.
240
241
242
243T1-FONT-CRASH
244
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
247  I believe).
248 
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.
252
253
254
255BAD-ADVANCES
256
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
261  glyphs.
262 
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).
265
266
267
268GLYPH-TO-BITMAP-BUG
269
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.
273
274
275=== end of file ===
Note: See TracBrowser for help on using the repository browser.