xref: /haiku-fatelf/docs/freetype2/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� (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.



--- END OF OPEN BUGS ---



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).

  This has been corrected with a hack in FT_Load_Glyph().  More important
  internal changes should help get rid of it with a clean solution in a
  further release like FreeType 2.1.



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-UNIXXXX-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.)



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.
                  
  The same bug has been fixed in src/raster/ftrender1.c also.
                  


TT-GLYPH-CRASH

  The library crashed when trying to load certain glyphs from an
  automatically generated TrueType file (tt1095m_.ttf submitted by Scott
  Long).
  
  It turned out that the font contained invalid glyph data (i.e. was
  broken), but the TrueType glyph loader in FreeType wasn't paranoid enough,
  which resulted in nasty memory overwrites all over the place.



T1-FONT-CRASH

  The library crashed when trying to load the "Stalingrad Regular" face from
  the "sadn.pfb" font file provided by Anthony Fok (and the Gnome-Print team
  I believe).
  
  This was due to the fact that the font missed a full font name entry,
  though boasted a family name and postscript name.  The Type 1 face loader
  didn't check for these pathetic cases and seg-faulted.



BAD-ADVANCES

  All scalable font drivers returned un-fitted glyph advances when
  FT_LOAD_DEFAULT was used, which was incorrect.  This problem was pretty
  old but hadn't been spotted because all test programs actually explicitly
  or implicitly (i.e. through the cache) rounded the advance widths of
  glyphs.
  
  This resulted in poor rendering of a number of client applications however
  (it is strange to see they took so long to notify the FreeType team).



GLYPH-TO-BITMAP-BUG

  FT_Glyph_To_Bitmap() did incorrectly modify the source glyph in certain
  cases, which resulted in random behaviour and bad text rendering.  This
  was spotted to bugs in both the monochrome and smooth rasterizer.


=== end of file ===