1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
|
List of known FreeType 2 Bugs
-----------------------------
"Identifier" is a string to uniquely identify the bug. A more detailed
description of the bug is found below the table of opened bugs.
"Date" is the date when the bug was first reported or entered in this
document. Dates are in _European_ format, i.e day/month/year.
"Opened By" is the name of the person who first spotted the bug. Note that
we can use abbreviations here, like:
"David" for David Turner
"Werner" for Werner Lemberg
etc.
"Reproduceable" indicates whether the bug could be reproduced by the
development team or not (it can be specific to a given platform), whether it
always happens, or only sporadically, etc.
I. Opened bugs
==============
Identifier Date Opened by Reproduceable
------------------------------------------------------------------------------
NO-CID-CMAPS 13-09-2001 David always
BAD-TT-RENDERING 12-09-2001 Paul Pedriana ?
BAD-THIN-LINES 13-09-2001 David ?
NOT-WINDOWS-METRICS 07-10-2001 David always
ADVANCED-COMPOSITES 25-10-2001 George Williams always
--------------------END-OF-OPENED-BUGS-TABLE----------------------------------
II. Table of closed bugs
========================
Identifier Date Closed by Closure date
------------------------------------------------------------------------------
BAD-TTNAMEID.H 12-09-2001 Antoine N/A
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
--------------------END-OF-CLOSED-BUGS-TABLE----------------------------------
III. Bug descriptions
=====================
NO-CID-CMAPS
Not exactly a bug, but the CFF font driver doesn't build a Unicode charmap
from the contents of font files, which prevents efficiently using fonts in
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
According to Paul Pedriana <PPedriana@maxis.com>, there is a rather
important difference between the rendering of TrueType-hinted glyphs of
current FT2 and old betas.
Tests and comparisons show a _major_ discrepancy of monochrome truetype
bytecode-hinted glyphs! Something seems to be really broken here!
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.
BAD-THIN-LINES
It seems that the anti-aliased renderer in FreeType has problems rendering
extremely thin straight lines correctly, at least when using the
FT_Outline_Render() function.
NOT-WINDOWS-METRICS
FreeType doesn't always return the same metrics as Windows for ascender,
descender, and text height, depending on character pixel sizes. A lot of
testing on Windows is needed to debug this properly. It might be due to a
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
Provided by George Williams <pfaedit@users.sourceforge.net>:
I notice that truetype/ttgload.c only supports Apple's definition of
offsets for composite glyphs. Apple and Microsoft behave differently if
there is a scale factor. OpenType defines some bits to disambiguate.
(A problem in both 2.0.4 and 2.0.5.)
Apple says (http://fonts.apple.com/TTRefMan/RM06/Chap6glyf.html) that if
flags&ARGS_ARE_XY is set then the offsets should be scaled by the scale
factors (as you have done), but they also say something very cryptic
about what happens when the component is rotated at 45° (which you do
not support) -- See the "Important" note at the bottom.
The old truetype spec from Microsoft did not mention this. The OpenType
spec (http://www.microsoft.com/typography/otspec/glyf.htm,
http://partners.adobe.com/asn/developer/opentype/glyf.html) defines two
new bits to disambiguate:
SCALED_COMPONENT_OFFSET 11
Composite designed to have the component offset scaled (designed for
Apple rasterizer)
UNSCALED_COMPONENT_OFFSET 12
Composite designed not to have the component offset scaled (designed
for the Microsoft TrueType rasterizer)
Perhaps you could add a load_flag to allow the user to define the
default setting?
David says:
Wow, I was not even aware of this, it will probably take a little time
to implement since I don't have any font that implement these
"features", and also because I believe that we're running out of bits
for "load_flag", some other way to set preferences is probably needed.
GLYPH_TO_BITMAP-BUG
Calling FT_Glyph_To_Bitmap() sometimes modifies the original glyph
outline, creating weird alignment artefacts.
This subtle bug was really in the file `src/smooth/ftsmooth.c'.
Basically, the outline was shifted before rendering it into a new bitmap
buffer. However, it wasn't properly un-shifted after that operation.
This was only noticeable with certain glyphs or certain fonts; it crept in
a long time ago.
The same bug has been fixed in src/raster/ftrender1.c also.
=== end of file ===
|
