c8ad30a7a0
purposes..
* src/smooth/ftsmooth.c (ft_smooth_render): fixed a nasty hidden bug where
outline shifting wasn't correctly undone after bitmap rasterization. this
created problems with certain glyphs (like '"' of certain fonts..) and
the cache system..
202 lines
6.8 KiB
Plaintext
202 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 and crept
|
||
for a long time here..
|
||
|
||
|
||
|
||
=== end of file ===
|