Re: [ft-devel] GF + TFM

[Werner LEMBERG]

>> What exactly do you mean with `wrongly filled'?  Please give an
>> example that I can look at with the debugger.
>
> I mean that the which metric data is wrongly allotted in the
> `GF_Glyph_Load' function which is causing these errors in the gf
> output.  Is it only ascender and descender values in the
> `GF_Size_Select' function or anything else.

If you look at the metric information provided by GF and TFM you can
easily see what's missing.  For example, let's take glyphs `f'
(index 102) and `g' (index 103) from `cmr10'.[1]

In file `cmr10.600gf' you can find the following (taken from a dump
done with `gftype -m cmr10.600gf' and omitting not so important
information).

  6861: beginning of char 102: 1<=m<=29 0<=n<=58
  7002: beginning of char 103: 2<=m<=40 -18<=n<=36

  Character 102: dx 1638400 (25), width 320400 (25.36798), loc 6861
  Character 103: dx 2752512 (42), width 524290 (41.51115), loc 7002

  min m = -4, max m = 82             [2]
  min n = -21, max n = 61

In file `cmr10.tfm', the following info is present (taken from a dump
done with `tftopl -charcode-format=ascii cmr10.tfm'):

  (FONTDIMEN
     (SLANT R 0.0)
     (SPACE R 0.333334)
     ...
     (XHEIGHT R 0.430555)
     )

  (CHARACTER C f
     (CHARWD R 0.305557)
     (CHARHT R 0.694445)
     (CHARIC R 0.077779)
     (COMMENT
        ...
        (KRN C ' R 0.077779)
        (KRN C ? R 0.077779)
        (KRN C ! R 0.077779)
        (KRN O 51 R 0.077779)
        (KRN C ] R 0.077779)
        )
     )

  (CHARACTER C g
     (CHARWD R 0.500002)
     (CHARHT R 0.430555)
     (CHARDP R 0.194445)
     (CHARIC R 0.013888)
     (COMMENT
        (KRN C j R 0.027779)
        )
     )

GF alone provide integer metrics and misses kerning info.  Attaching a
TFM provides non-integer metrics and kerning data.  In other words,
attaching a TFM to a GF *refines* the integer metric values to better
ones.

BTW, the exact global bounding box, together with the global ascender
and descender, must be computed by checking all height, depth, and
width values from the TFM.


    Werner


[1] I now see another problem: Currently, the order of glyphs in a GF
    file shown by ftview is based on the value `c' in a glyph's
    `char_loc' op.  However, the glyph order should reflect the
    physical order in the font file, which gftype shows as `A', `B',
    ..., `Y', `Z', `a', `b', ..., for `cmr10.600gf'.  Please change
    this.  Together with the two artificial characters we should
    eventually have

      glyph name   index
      ------------------
      .notdef      0
      space        1
      A            2
      B            3
      ...          ...

    The value `c' is there for synchronization with the corresponding
    TFM file data.

[2] Given that there is a global bbox for the whole font, the vertical
    `jumping' is actually a bug in your code: Based on the global `m'
    and `n' values you can definitely deduce a baseline on which you
    can align all glyphs vertically even without a TFM!