Edit
kc3-lang/freetype/docs/BUGS
Werner Lemberg
- docs/BUGS
-
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. Open 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. 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 TT-GLYPH-CRASH 01-01-2002 David 2.0.6 T1-FONT-CRASH 01-01-2002 David 2.0.6 BAD-ADVANCES 30-11-2001 David 2.0.6 GLYPH-TO-BITMAP-BUG 15-12-2001 David 2.0.6 --------------------END-OF-CLOSED-BUGS-TABLE---------------------------------- III. Bug descriptions ===================== --- START OF OPEN BUGS --- 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-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 (the major differences are gone though). 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. 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