Edit

kc3-lang/freetype/docs/BUGS

Branch :

  • Show log

    Commit

  • Author : Werner Lemberg
    Date : 2001-12-07 21:56:32
    Hash : e9e130c0
    Message : Formatting.

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