readme

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

gxvalid: TrueType GX validator
==============================


1. What is this
---------------

  `gxvalid' is a module to  validate TrueType GX tables: a collection of
  additional tables  in TrueType  font which are  used by  `QuickDraw GX
  Text',  Apple Advanced  Typography  (AAT).  In  addition, gxvalid  can
  validates `kern'  tables which have  been extended for AAT.   Like the
  otvalid  module,   gxvalid  uses  Freetype   2's  validator  framework
  (ftvalid).

  You can link gxvalid with your program; before running your own layout
  engine, gxvalid validates a font  file.  As the result, you can remove
  error-checking code  from the layout  engine.  It is also  possible to
  use  gxvalid  as a  stand-alone  font  validator;  the `ftvalid'  test
  program  included  in the  ft2demo  bundle  calls gxvalid  internally.
  A stand-alone font validator may be useful for font developers.

  This documents documents the following issues.

  - supported TrueType GX tables
  - fundamental validation limitations
  - permissive error handling of broken GX tables
  - `kern' table issue.


2. Supported tables
-------------------

  The following GX tables are currently supported.

    bsln
    feat
    just
    kern(*)
    lcar
    mort
    morx
    opbd
    prop
    trak

  The following GX tables are currently unsupported.

    cvar
    fdsc
    fmtx
    fvar
    gvar
    Zapf

  The following GX tables won't be supported.

    acnt(**)
    hsty(***)

  The following undocumented tables in TrueType fonts designed for Apple
  platform aren't handled either.

    addg
    CVTM
    TPNM
    umif


  *)   The `kern'  validator handles both  the classic and the  new kern
       formats;  the former  is supported  on both  Microsoft  and Apple
       platforms, while the latter is supported on Apple platforms.

  **)  `acnt' tables are not supported by currently available Apple font
       tools.

  ***) There  is  one more  Apple  extension,  `hsty',  but  it  is  for
       Newton-OS, not GX  (Newton-OS is a platform by  Apple, but it can
       use  sfnt- housed bitmap  fonts only).   Therefore, it  should be
       excluded  from  `Apple  platform'  in the  context  of  TrueType.
       gxvalid ignores it as Apple font tools do so.


  We have  checked 183  fonts bundled with  MacOS 9.1, MacOS  9.2, MacOS
  10.0, MacOS X 10.1, MSIE  for MacOS, and AppleWorks 6.0.  In addition,
  we have  checked 67 Dynalab fonts  (designed for MacOS)  and 189 Ricoh
  fonts (designed for Windows and  MacOS dual platforms).  The number of
  fonts including TrueType GX tables are as follows.

    bsln:  76
    feat: 191
    just:  84
    kern:  59
    lcar:   4
    mort: 326
    morx:  19
    opbd:   4
    prop: 114
    trak:  16

  Dynalab  and Ricoh fonts  don't have  GX tables  except of  `feat' and
  `mort'.


3. Fundamental validation limitations
-------------------------------------

  TrueType  GX  provides  layout   information  to  libraries  for  font
  rasterizers  and text layout.   gxvalid can  check whether  the layout
  data in  a font is conformant  to the TrueType GX  format specified by
  Apple.  But gxvalid cannot check  a how QuickDraw GX/AAT renderer uses
  the stored information.

  3-1. Validation of State Machine activity
  -----------------------------------------

    QuickDraw GX/AAT uses a `State Machine' to provide `stateful' layout
    features,  and TrueType GX  stores the  state transition  diagram of
    this `State  Machine' in a  `StateTable' data structure.   While the
    State  Machine receives  a series  of glyph  IDs, the  State Machine
    starts with `start  of text' state, walks around  various states and
    generates various  layout informations to the  renderer, and finally
    reaches the `end of text' state.

    gxvalid can check essential errors like:

      - possibility of state transitions to undefined states
      - existence of glyph  IDs that the State Machine  doesn't know how
        to handle
      - the  State Machine  cannot compute  the layout  information from
        given diagram

    These errors  can be  checked within finite  steps, and  without the
    State Machine itself, because these are `expression' errors of state
    transition diagram.

    There  is no  limitation  about  how long  the  State Machine  walks
    around,  so validation  of  the algorithm  in  the state  transition
    diagram requires infinite  steps, even if we had  a State Machine in
    gxvalid.   Therefore, the  following errors  and problems  cannot be
    checked.

      - existence of states which the State Machine never transits to
      - the  possibility that the  State Machine  never reaches  `end of
        text'
      - the possibility of stack underflow/overflow in the State Machine
        (in  ligature  and  contextual  glyph substitutions,  the  State
        Machine can store 16 glyphs onto its stack)

    In addition, gxvalid doesn't check `temporary glyph IDs' used in the
    chained State Machines  (in `mort' and `morx' tables).   If a layout
    feature  is  implemented by  a  single  State  Machine, a  glyph  ID
    converted by the State Machine is passed to the glyph renderer, thus
    it  should not  point to  an undefined  glyph ID.   But if  a layout
    feature is implemented by  chained State Machines, a component State
    Machine  (if it  is  not the  final  one) is  permitted to  generate
    undefined glyph IDs for temporary use, because it is handled by next
    component State Machine and not  by the glyph renderer.  To validate
    such temporary glyph IDs, gxvalid must stack all undefined glyph IDs
    which  can occur in  the output  of the  previous State  Machine and
    search  them in  the  `ClassTable' structure  of  the current  State
    Machine.  It is too complex to  list all possible glyph IDs from the
    StateTable, especially from a ligature substitution table.

  3-2. Validation of relationship between multiple layout features
  ----------------------------------------------------------------

    gxvalid does  not validate the relationship  between multiple layout
    features at all.

    If  multiple layout  features  are defined  in  TrueType GX  tables,
    possible  interactions,  overrides,  and  conflicts  between  layout
    features are implicitly  given in the font too.   For example, there
    are several predefined spacing control features:

      - Text Spacing          (Proportional/Monospace/Half-width/Normal)
      - Number Spacing        (Monospaced-numbers/Proportional-numbers)
      - Kana Spacing          (Full-width/Proportional)
      - Ideographic Spacing   (Full-width/Proportional)
      - CJK Roman Spacing     (Half-width/Proportional/Default-roman
                               /Full-width-roman/Proportional)

    If all  layout features are  independently managed, we  can activate
    inconsistent  typographic rules  like  `Text Spacing=Monospace'  and
    `Ideographic Spacing=Proportional' at the same time.

    The combinations  of layout features  is managed by a  32bit integer
    (one bit each for selector  setting), so we can define relationships
    between  up  to 32  features,  theoretically.   But  if one  feature
    setting  affects  another   feature  setting,  we  need  typographic
    priority  rules to  validate the  relationship.   Unfortunately, the
    TrueType GX format specification does not give such information even
    for predefined features.


4. Permissive error handling of broken GX tables
------------------------------------------------

  When  Apple's font  rendering system  finds an  inconsistency,  like a
  specification  violation or  an  unspecified value  in  a TrueType  GX
  table, it does not always  return error.  In most cases, the rendering
  engine silently  ignores such wrong  values or even whole  tables.  In
  fact, MacOS is shipped with  fonts including broken GX/AAT tables, but
  no harmful  effects due to  `officially broken' fonts are  observed by
  end-users.

  gxvalid  is designed  to continue  the validation  process as  long as
  possible.  When gxvalid find wrong  values, gxvalid warns it at least,
  and takes  a fallback procedure  if possible.  The  fallback procedure
  depends on the debug level.

  We used the following three tools to investigate Apple's error handling.

    - FontValidator  (for MacOS 8.5 - 9.2)  resource fork font
    - ftxvalidator   (for MacOS X 10.1 -)   dfont or naked-sfnt
    - ftxdumperfuser (for MacOS X 10.1 -)   dfont or naked-sfnt

  However, all tests were done on a PowerPC based Macintosh; at present,
  we have not checked those tools on a m68k-based Macintosh.

  In total, we checked 183 fonts  bundled to MacOS 9.1, MacOS 9.2, MacOS
  10.0, MacOS X  10.1, MSIE for MacOS, and  AppleWorks 6.0.  These fonts
  are distributed  officially, but many broken GX/AAT  tables were found
  by Apple's font tools.  In the following, we list typical violation of
  the GX specification, in fonts officially distributed with those Apple
  systems.

  4-1. broken BinSrchHeader (19/183)
  ----------------------------------

    `BinSrchHeader' is  a header of a  data array for  m68k platforms to
    access memory efficiently.  Although  there are only two independent
    parameters  for real  (`unitSize' and  `nUnits'),  BinSrchHeader has
    three additional parameters which  can be calculated from `unitSize'
    and  `nUnits',  for  fast  setup.   Apple  font  tools  ignore  them
    silently, so gxvalid warns if it finds and inconsistency, and always
    continues  validation.    The  additional  parameters   are  ignored
    regardless of the consistency.

      19  fonts include  such  inconsistencies; all  breaks  are in  the
      BinSrchHeader structure of the `kern' table.

  4-2. too-short LookupTable (5/183)
  ----------------------------------

    LookupTable format 0  is a simple array to get a  value from a given
    GID (glyph  ID); the index of  this array is a  GID too.  Therefore,
    the length  of the array is expected  to be same as  the maximum GID
    value defined  in the `maxp' table,  but there are  some fonts whose
    LookupTable format 0 is too  short to cover all GIDs.  FontValidator
    ignores  this error silently,  ftxvalidator and  ftxdumperfuser both
    warn and continue.  Similar problems are found in format 3 subtables
    of `kern'.  gxvalid  warns always and abort if  the validation level
    is set to FT_VALIDATE_PARANOID.

      5 fonts include too-short kern format 0 subtables.
      1 font includes too-short kern format 3 subtable.

  4-3. broken LookupTable format 2 (1/183)
  ----------------------------------------

    LookupTable  format  2,  subformat  4  covers the  GID  space  by  a
    collection  of  segments which  are  specified  by `firstGlyph'  and
    `lastGlyph'.   Some  fonts  store  `firstGlyph' and  `lastGlyph'  in
    reverse order,  so the segment specification is  broken.  Apple font
    tools ignore this error silently;  a broken segment is ignored as if
    it  did not  exist.   gxvalid  warns and  normalize  the segment  at
    FT_VALIDATE_DEFAULT, or ignore  the segment at FT_VALIDATE_TIGHT, or