readme

winNT技术操作系统,国外开放的原代码和LIUX一样

    abort at FT_VALIDATE_PARANOID.

      1 font includes broken LookupTable format 2, in the `just' table.

    *) It seems  that all fonts manufactured by  ITC for AppleWorks have
       this error.

  4-4. bad bracketing in glyph property (14/183)
  ----------------------------------------------

    GX/AAT defines a  `bracketing' property of the glyphs  in the `prop'
    table,  to control layout  features of  strings enclosed  inside and
    outside  of   brackets.   Some  fonts   give  inappropriate  bracket
    properties  to glyphs.   Apple  font tools  warn  about this  error;
    gxvalid warns too and aborts at FT_VALIDATE_PARANOID.

      14 fonts include wrong bracket properties.


  4-5. invalid feature number (117/183)
  -------------------------------------

    The GX/AAT extension can  include 255 different layout features, but
    popular      layout      features      are      predefined      (see
    http://developer.apple.com/fonts/Registry/index.html).   Some  fonts
    include feature  numbers which are incompatible  with the predefined
    feature registry.

    In our survey, there are 140 fonts including `feat' table.

    a) 67 fonts use a feature number which should not be used.
    b) 117 fonts set the wrong feature range (nSetting).  This is mostly
       found in the `mort' and `morx' tables.

    Apple  font tools give  no warning,  although they  cannot recognize
    what  the feature  is.   At FT_VALIDATE_DEFAULT,  gxvalid warns  but
    continues in both cases (a, b).  At FT_VALIDATE_TIGHT, gxvalid warns
    and aborts for (a), but continues for (b).  At FT_VALIDATE_PARANOID,
    gxvalid warns and aborts in both cases (a, b).

  4-6. invalid prop version (10/183)
  ----------------------------------

    As most TrueType GX tables, the `prop' table must start with a 32bit
    version identifier: 0x00010000,  0x00020000 or 0x00030000.  But some
    fonts  store nonsense binary  data instead.   When Apple  font tools
    find them, they abort the processing immediately, and the data which
    follows is unhandled.  gxvalid does the same.

      10 fonts include broken `prop' version.

    All  of these  fonts are  classic  TrueType fonts  for the  Japanese
    script, manufactured by Apple.

  4-7. unknown resource name (2/183)
  ------------------------------------

    NOTE: THIS IS NOT A TRUETYPE GX ERROR.

    If  a TrueType  font is  stored  in the  resource fork  or in  dfont
    format, the data must be tagged as `sfnt' in the resource fork index
    to invoke TrueType font handler for the data.  But the TrueType font
    data  in   `Keyboard.dfont'  is  tagged   as  `kbd',  and   that  in
    `LastResort.dfont' is tagged as  `lst'.  Apple font tools can detect
    that the data is in  TrueType format and successfully validate them.
    Maybe  this is possible  because they  are known  to be  dfont.  The
    current  implementation  of the  resource  fork  driver of  FreeType
    cannot do that, thus gxvalid cannot validate them.

      2 fonts use an unknown tag for the TrueType font resource.

5. `kern' table issues
----------------------

  In common terminology of TrueType, `kern' is classified as a basic and
  platform-independent table.  But there are Apple extensions of `kern',
  and  there is  an  extension which  requires  a GX  state machine  for
  contextual kerning.   Therefore, gxvalid includes  a special validator
  for  `kern' tables.   Unfortunately, there  is no  exact  algorithm to
  check Apple's extension, so  gxvalid includes a heuristic algorithm to
  find  the proper validation  routines for  all possible  data formats,
  including    the   data    format   for    Microsoft.     By   calling
  classic_kern_validate() instead of gxv_validate(), you can specify the
  `kern' format  explicitly.  However, current  FreeType2 uses Microsoft
  `kern' format  only, others  are ignored (and  should be handled  in a
  library one level higher than FreeType).

  5-1. History
  ------------

    The original  16bit version of `kern'  was designed by  Apple in the
    pre-GX  era, and  it was  also approved  by  Microsoft.  Afterwards,
    Apple designed a  new 32bit version of the  `kern' table.  According
    to  the documentation, the  difference between  the 16bit  and 32bit
    version is only the size of  variables in the `kern' header.  In the
    following,  we call  the original  16bit version  as  `classic', and
    32bit version as `new'.

  5-2. Versions and dialects which should be differentiated
  ---------------------------------------------------------

    The `kern' table  consists of a table header  and several subtables.
    The version number  which identifies a `classic' or  a `new' version
    is  explicitly   written  in  the   table  header,  but   there  are
    undocumented  differences between  Microsoft's and  Apple's formats.
    It is  called a `dialect' in  the following.  There  are three cases
    which  should  be  handled:   the  new  Apple-dialect,  the  classic
    Apple-dialect,  and the classic  Microsoft-dialect.  An  analysis of
    the formats and the auto detection algorithm of gxvalid is described
    in the following.

    5-2-1. Version detection: classic and new kern
    ----------------------------------------------

      According  to Apple  TrueType  specification, there  are only  two
      differences between the classic and the new:

        - The `kern' table header starts with the version number.
          The classic version starts with 0x0000 (16bit),
          the new version starts with 0x00010000 (32bit).

        - In the  `kern' table header,  the number of  subtables follows
          the version number.
          In the classic version, it is stored as a 16bit value.
          In the new version, it is stored as a 32bit value.

      From Apple font tool's output (DumpKERN is also tested in addition
      to  the  three  Apple  font  tools in  above),  there  is  another
      undocumented difference.  In the  new version, the subtable header
      includes a 16bit variable  named `tupleIndex' which does not exist
      in the classic version.

      The new version  can store all subtable formats (0,  1, 2, and 3),
      but the Apple TrueType specification does not mention the subtable
      formats available in the classic version.

    5-2-2. Avaibale subtable formats in classic version
    ---------------------------------------------------

      Although the  Apple TrueType  specification recommends to  use the
      classic version in  the case if the font is  designed for both the
      Apple and Microsoft platforms,  it does not document the available
      subtable formats in the classic version.

      According  to the Microsoft  TrueType specification,  the subtable
      format  assured for  Windows  and OS/2  support  is only  subtable
      format  0.  The  Microsoft TrueType  specification  also describes
      subtable format  2, but does  not mention which  platforms support
      it.  Aubtable formats 1, 3,  and higher are documented as reserved
      for future use.  Therefore, the classic version can store subtable
      formats 0 and 2, at least.  `ttfdump.exe', a font tool provided by
      Microsoft,  ignores the  subtable format  written in  the subtable
      header, and parses the table as if all subtables are in format 0.

      `kern'  subtable format  1  uses  a StateTable,  so  it cannot  be
      utilized without a GX  State Machine.  Therefore, it is reasonable
      to assume  that format 1 (and  3) were introduced  after Apple had
      introduced GX and moved to the new 32bit version.

    5-2-3. Apple and Microsoft dialects
    -----------------------------------

      The  `kern' subtable  has  a 16bit  `coverage'  field to  describe
      kerning attributes, but bit interpretations by Apple and Microsoft
      are different:  For example, Apple  uses bits 0-7 to  identify the
      subtable, while Microsoft uses bits 8-15.

      In  addition, due  to the  output of  DumpKERN  and FontValidator,
      Apple's bit interpretations of coverage in classic and new version
      are  incompatible also.   In  summary, there  are three  dialects:
      classic Apple  dialect, classic  Microsoft dialect, and  new Apple
      dialect.  The classic Microsoft  dialect and the new Apple dialect
      are documented  by each vendors' TrueType  font specification, but
      the documentation for classic Apple dialect is not available.

      For example,  in the  new Apple dialect,  bit 15 is  documented as
      `set to  1 if  the kerning  is vertical'.  On  the other  hand, in
      classic Microsoft dialect, bit 1 is documented as `set to 1 if the
      kerning  is  horizontal'.   From   the  outputs  of  DumpKERN  and
      FontValidator, classic  Apple dialect recognizes  15 as `set  to 1
      when  the kerning  is horizontal'.   From the  results  of similar
      experiments, classic Apple dialect  seems to be the Endian reverse
      of the classic Microsoft dialect.

      As a  conclusion it must be  noted that no font  tool can identify
      classic Apple dialect or classic Microsoft dialect automatically.

    5-2-4. gxvalid auto dialect detection algorithm
    -----------------------------------------------

      The first 16  bits of the `kern' table are  enough to identify the
      version:

        - if  the first  16  bits are  0x0000,  the `kern'  table is  in
          classic Apple dialect or classic Microsoft dialect
        - if the first 16 bits are  0x0001, and next 16 bits are 0x0000,
          the kern table is in new Apple dialect.

      If the `kern'  table is a classic one,  the 16bit `coverage' field
      is checked next.   Firstly, the coverage bits are  decoded for the
      classic Apple dialect using the following bit masks (this is based
      on DumpKERN output):

        0x8000: 1=horizontal, 0=vertical
        0x4000: not used
        0x2000: 1=cross-stream, 0=normal
        0x1FF0: reserved
        0x000F: subtable format

      If  any  of  reserved  bits  are  set  or  the  subtable  bits  is
      interpreted as format 1 or 3, we take it as `impossible in classic
      Apple dialect' and retry, using the classic Microsoft dialect.

        The most popular coverage in new Apple-dialect:         0x8000,
        The most popular coverage in classic Apple-dialect:     0x0000,
        The most popular coverage in classic Microsoft dialect: 0x0001.

  5-3. Tested fonts
  -----------------

    We checked  59 fonts  bundled with MacOS  and 38 fonts  bundled with
    Windows, where all font include a `kern' table.

      - fonts bundled with MacOS
        * new Apple dialect
          format 0: 18
          format 2:  1
          format 3:  1
        * classic Apple dialect
          format 0: 14
        * classic Microsoft dialect
          format 0: 15

      - fonts bundled with Windows
        * classic Microsoft dialect
          format 0: 38

    It looks strange that classic Microsoft-dialect fonts are bundled to
    MacOS: they come from MSIE for MacOS, except of MarkerFelt.dfont.


  ACKNOWLEDGEMENT
  ---------------

  Some parts of gxvalid are  derived from both the `gxlayout' module and
  the `otvalid'  module.  Development of  gxlayout was supported  by the
  Information-technology Promotion Agency(IPA), Japan.

  The detailed analysis of undefined  glyph ID utilization in `mort' and
  `morx' tables is provided by George Williams.

------------------------------------------------------------------------

Copyright 2004, 2005 by
suzuki toshiya, Masatake YAMATO, Red hat K.K.,
David Turner, Robert Wilhelm, and Werner Lemberg.

This  file is  part  of the  FreeType  project, and  may  only be  used,
modified,  and  distributed under  the  terms  of  the FreeType  project
license, LICENSE.TXT.  By continuing  to use, modify, or distribute this
file  you indicate that  you have  read the  license and  understand and
accept it fully.


--- end of README ---