forked from minhngoc25a/freetype2
201 lines
6.8 KiB
Plaintext
201 lines
6.8 KiB
Plaintext
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
|
||
AUTOHINT-NO-SBITS 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-UNIXXX-NAMES 30-07-2001 David 2.0.5
|
||
GLYPH_TO_BITMAP-BUG 05-12-2001 David 05-12-2001
|
||
|
||
--------------------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).
|
||
|
||
|
||
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!
|
||
|
||
|
||
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-UNIXXX-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<34> (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.
|
||
|
||
|
||
=== end of file ===
|