~ubuntu-branches/ubuntu/jaunty/texlive-bin/jaunty-security

« back to all changes in this revision

Viewing changes to build/TeX/libs/freetype2/docs/BUGS

  • Committer: Bazaar Package Importer
  • Author(s): Norbert Preining
  • Date: 2008-06-26 23:14:59 UTC
  • mfrom: (2.1.30 intrepid)
  • Revision ID: james.westby@ubuntu.com-20080626231459-y02rjsrgtafu83yr
Tags: 2007.dfsg.2-3
add missing source roadmap.fig of roadmap.eps in fontinst documentation
(Closes: #482915) (urgency medium due to RC bug)
(new patch add-missing-fontinst-source)

Show diffs side-by-side

added added

removed removed

Lines of Context:
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 ===