1 | List of known FreeType 2 Bugs |
---|
2 | ----------------------------- |
---|
3 | |
---|
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. |
---|
6 | |
---|
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. |
---|
9 | |
---|
10 | "Opened By" is the name of the person who first spotted the bug. Note that |
---|
11 | we 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 |
---|
18 | development team or not (it can be specific to a given platform), whether it |
---|
19 | always happens, or only sporadically, etc. |
---|
20 | |
---|
21 | |
---|
22 | |
---|
23 | I. Open bugs |
---|
24 | ============ |
---|
25 | |
---|
26 | |
---|
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 |
---|
34 | |
---|
35 | --------------------END-OF-OPENED-BUGS-TABLE---------------------------------- |
---|
36 | |
---|
37 | |
---|
38 | |
---|
39 | II. Closed bugs |
---|
40 | =============== |
---|
41 | |
---|
42 | |
---|
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---------------------------------- |
---|
55 | |
---|
56 | |
---|
57 | |
---|
58 | III. Bug descriptions |
---|
59 | ===================== |
---|
60 | |
---|
61 | |
---|
62 | --- START OF OPEN BUGS --- |
---|
63 | |
---|
64 | |
---|
65 | NO-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 | |
---|
73 | BAD-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 | |
---|
89 | BAD-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 | |
---|
97 | NOT-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 | |
---|
106 | ADVANCED-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 | |
---|
151 | BAD-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 | |
---|
176 | AUTOHINT-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 | |
---|
193 | BAD-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 | |
---|
204 | BAD-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 | |
---|
215 | GLYPH_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 | |
---|
231 | TT-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 | |
---|
243 | T1-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 | |
---|
255 | BAD-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 | |
---|
268 | GLYPH-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 === |
---|