forked from minhngoc25a/freetype2
110 lines
3.6 KiB
Plaintext
110 lines
3.6 KiB
Plaintext
|
List of known FreeType 2 Bugs
|
||
|
|
-----------------------------
|
||
|
|
|
||
|
|
"Identifier" is a unique string used to uniquely identify the bug
|
||
|
|
A more complete description of the bug is found below the table of
|
||
|
|
opened bugs..
|
||
|
|
|
||
|
|
"Date" is the date where 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 people who first spotted the bug.
|
||
|
|
Note that we can use abbreviations here, like:
|
||
|
|
|
||
|
|
"David" for David Turner
|
||
|
|
"Werner" for Werner Lemberg
|
||
|
|
etc..
|
||
|
|
|
||
|
|
"Reproducable" indicates wether the bug could be reproduced by the
|
||
|
|
development team or not (it can be specific to a given platform),
|
||
|
|
wether it always happen, or only sporadically, etc..
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
I. Opened bugs:
|
||
|
|
===============
|
||
|
|
|
||
|
|
Identifier Date Opened by Reproducable
|
||
|
|
------------------------------------------------------------------------------
|
||
|
|
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 ?
|
||
|
|
|
||
|
|
--------------------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
|
||
|
|
|
||
|
|
|
||
|
|
--------------------END-OF-CLOSED-BUGS-TABLE----------------------------------
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
II. Bug descriptions:
|
||
|
|
=====================
|
||
|
|
|
||
|
|
NO-CID-CMAPS:
|
||
|
|
Not exactly a bug, but the CFF font driver doesn't build a Unicode
|
||
|
|
charmap from the content 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 fucked 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 functions..
|