[Fontinst] Re: Bug in fontinstversion{1.927}

Lars Hellström Lars.Hellstrom at math.umu.se
Thu Jan 27 12:19:25 CET 2005


At 10.50 +0100 2005-01-27, Peter Dyballa wrote:
>Am 26.01.2005 um 22:06 schrieb Peter Dyballa:
>
>>>> \installfont can work with more than one MTX file, can
>>>> \transformfont do the same?
>>>
>>> The purpose of \transformfont is, in a sense, to create a new base
>>> font (it
>>> will appear as such to the DVI driver).
>>
>> Arggh! There is kind of mapping in fontinst:
>>
>> \installfont   <--> *.mtx
>> \transformfont <--> *.etx

No. You typically need ETXes and MTXes for both commands.

Technically \transformfont needs no ETX if not reecoding, but it always
generates MTX files. In principle you can use \installfont without any MTX
file at all (but that's not very useful), whereas it will always require an
ETX file.

>> I meant the transformation from AFM -> MTX, PL with more than one ETX
>> file (usually 8r.etx for text use, om?.etx for math use), the
>> 'original' 8p.etx plus the variable one with local/font
>> specific/TrueType endemic extra names.
>>
>> This option is not really needed, since right now I have from the
>> ttf2pt1 conversion an 8p encoded PFB and AFM file and create the MTX
>> and PL files via a series of \afmtomtx and \mtxtopl

Note that \installfont looks for metrics in PL, AFM, and VPL formats as
well as MTX format. It will do the AFM->MTX and MTX->PL conversions
automatically if no MTX metrics are available. Hence these explicit
\afmtomtx and \mtxtopl are probably unnecessary (the only practical
difference being if the information in the AFMs changes between different
runs, as fontinst would then still use the information cached in the MTX
files).

>> and then, during
>> \installfont it would work to have one standard set of names in 8p.mtx
>> and another additional set of local/font specific/TrueType endemic
>> extra names.
>
>Thanks to sleep I got a better idea: \translatefont!
>
>8p.etx contains all this used in OT1, T1, TS1 (and a bit of 8x) that is
>not contained in 8r (but usually available in Unicode encoded TrueType
>fonts) and it is the source for 8p.enc, which is the source for 8p.map,
>which tells ttf2pt1 to excerpt ("cite") only the glyphs at these
>Unicode positions. So the AFM and PFB files are already correctly
>encoded (no real use of 8p.enc yet) -- only some names can be wrong! An
>AFM file can look like this (without the last column):
>
>C 57 ; WX 1000 ; N .notdef ; B 346 172 643 516 ;     ’àö
>C 58 ; WX 537 ; N uni00B1 ; B 39 37 498 632 ;        ±
>C 59 ; WX 668 ; N uni00D7 ; B 39 98 621 586 ;        ˆó
>C 60 ; WX 537 ; N uni00F7 ; B 85 145 452 539 ;       ˆ

>C 61 ; WX 691 ; N uni00AC ; B 49 199 643 551 ;       ¬
>C 62 ; WX 254 ; N uni2024 ; B 68 0 186 117 ;         ’ħ
>C 63 ; WX 1000 ; N .notdef ; B 346 172 643 516 ;     ’Ä*
>C 64 ; WX 1000 ; N .notdef ; B 346 172 643 516 ;     ’Ń
>C 65 ; WX 336 ; N uni00B9 ; B 59 391 275 836 ;       ¬¼
>C 66 ; WX 418 ; N uni00B2 ; B 59 391 359 836 ;       ¬¾
>C 67 ; WX 410 ; N uni00B3 ; B 53 391 355 836 ;       ¬„
>C 68 ; WX 402 ; N uni2074 ; B 39 391 365 836 ;       ’Å¥
>C 69 ; WX 1000 ; N .notdef ; B 346 172 643 516 ;     ’ŵ
>
>And here comes \translatefont: it looks up the C slot number in a
>reference and assigns the name found there to the box measures the
>glyph fits into.
>
>No need for any extra names! Splendid, isn't it?

Apart from the thing about encoding positions, this is pretty much
\reglyphfont (which works directly with a mapping from glyph name to glyph
name). Judging from the above, the various .notdefs really seem to be
missing glyph symbols, so one wouldn't want to include those anyway.

If you insist on assigning glyph names by encoding positions (in general a
bad practice; there are lots of fonts out there which are broken because of
that), then there is presently the possibility of converting MTX (using
\installrawfont, to preserve kerns) to PL and from there (using
\generalpltomtx) back to MTX. With some work,one could also generate
settings files for \reglyphfont from MTX and ETX files to simulate this
effect, but presently I don't see a need for that.

Lars Hellström




More information about the fontinst mailing list