ttf2afm problems solved 

Ulrik Vieth vieth@thphy.uni-duesseldorf.de 
Fri, 29 May 1998 13:57:05 +0200 

       Previous message: explanation of test message 
       Next message: ttf2afm problems solved 
       Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 



After all this discussion, I've downloaded and tried out ttfdump
myself, and I think it is clear now, what needs to be done:

> ; TrueType v1.0 Dump Program - v1.60, Jul 10 1995, rrt, dra, gch, ddb, lcp
> ; Copyright (C) 1991 ZSoft Corporation. All rights reserved.
> ; Portions Copyright (C) 1991-1995 Microsoft Corporation. All rights reserved.
> 
> ; Dumping file '\windows\system\times.ttf'
> 
> 
> 'head' Table - Font Header
> --------------------------
> Size = 54 bytes (expecting 54 bytes)
>   'head' version:      1.0
>   fontRevision:        1.0
>   checkSumAdjustment:  0xA92387E7
>   magicNumber:         0x5F0F3CF5
>   flags:               0x0019- baseline(y)=0 - int ppem - nonlin aw
>   unitsPerEm:          2048

This seems to be the scale factor that needs to applied to all values
written to AFM file.  In the examples I checked, I have seen values 
of 1000 as well 2048, so it appears that 'unitsPerEm' doesn't always
have to be a power of 2.

>   created:             Mon Aug 06 21:14:42 1990
>   modified:            Fri Jan 31 04:26:07 1992
>   xMin:                -157
>   yMin:                -442
>   xMax:                2066
>   yMax:                1797

These might be the FontBBox values in scaled units.  Are they really?
(yMin and xMax match ttf2afm's values, but xMin and yMax are different.)

>   macStyle bits:       0x0000
>   lowestRecPPEM:       11
>   fontDirectionHint:   1
>   indexToLocFormat:    0
>   glyphDataFormat:     0
> 
> 'hhea' Table - Horizontal Header
> --------------------------------
> Size = 36 bytes (expecting 36 bytes)
>       'hhea' version:         1.0
>       yAscender:            1825
>       yDescender:           -443

These are not quite the values of Ascender and Descender we need 
for the AFM files.  There are better elsewhere, see below.

>       yLineGap:             87
>       advanceWidthMax:      2048
>       minLeftSideBearing:   -157
>       minRightSideBearing:  -208
>       xMaxExtent:           2066
>       horizCaretSlopeNum:   1
>       horizCaretSlopeDenom: 0
>       reserved0:            0
>       reserved1:            0
>       reserved2:            0
>       reserved3:            0
>       reserved4:            0
>       metricDataFormat:     0
>       numOf_LongHorMetrics: 220
> 
> 'OS/2' Table - OS/2 and Windows Metrics
> ---------------------------------------
> Size = 78 bytes (expecting 78 bytes)
>   'OS/2' version:      0
>   xAvgCharWidth:       821
>   usWeightClass:       400
>   usWidthClass:        5
>   fsType:              0x0000
>   ySubscriptXSize:     1434
>   ySubscriptYSize:     1331
>   ySubscriptXOffset:   0
>   ySubscriptYOffset:   293
>   ySuperscriptXSize:   1434
>   ySuperscriptYSize:   1331
>   ySuperscriptXOffset: 0
>   ySuperscriptYOffset: 928
>   yStrikeoutSize:      102
>   yStrikeoutPosition:  530

This is potentially interesting information for math fonts.
Unfortunately, there doesn't seem to be standard method for
representing these values in AFM files.

  1434 * 10.00 / 2048 = 7.00pt = scriptsize width ratio
  1331 * 10.00 / 2048 = 6.49pt = scriptsize height ratio

   293 * 10.00 / 2048 = 1.43pt = top(?) of superscript
   928 * 10.00 / 2048 = 4.53pt = bottom of superscript

   102 * 10.00 / 2048 = 0.49pt = rule_thickness
   530 * 10.00 / 2048 = 2.58pt = math_axis

>   sFamilyClass:        1    subclass = 5
>   PANOSE:              2  2  6  3  5  4  5  2  3  4
>   Character Range:     0x00000000000000000000000000000000
>   achVendID:           'Mono'
>   fsSelection          0x0040
>   usFirstCharIndex:    0x0020
>   usLastCharIndex:     0x2219
>   sTypoAscender        1420
>   sTypoDescender       -442

These are the good values of Ascender and Descender in scaled units.

  1420 * 1000 / 2048 =  693  (height of 'f')
  -442 * 1000 / 2048 = -215  (depth of 'g')

>   sTypoLineGap         307
>   usWinAscent          1825
>   usWinDescent         443

These are the values of Ascender and Descender which have been used 
so far. Apart from missing the scale factor 'usWinAscent' is quite
different from 'sTypeAscender', so these are not what we want.

> 
> 'post' Table - PostScript Metrics
> ---------------------------------
> Size = 492 bytes
>       'post' version:         2.0
>       italicAngle:            0.0000
>       underlinePosition:      -223
>       underlineThickness:     100
>       isFixedPitch:           0

These are the values copied to the AFM file.  Again, the scale
factor (of 2048) needs to be applied to get consistent results.

That's all.  Hope it is clear now, what needs to be done to get
the remaining ttf2afm problems fixed, once and for all.

Cheers, Ulrik.