Re: Future of the `Karl Berry Font Naming Scheme'...

[Rebecca and Rowland <rebecca@astrid.u-net.com>]

>Rebecca and Rowland <rebecca@astrid.u-net.com> write(s):
>
>>> Adobe has adopted a semi-consistent naming scheme for
>>> fount files on Macs ... It's called the `5+3+3' scheme,
>>> because you take the first 5 characters
>>> from the first element in the name, the first three from the next, and so
>>> on until you run out of name elements.
>
>I wrote a small test program in awk to process the output of
>
>	grep -h ^FullName *.afm
>
>It looks like this:
>
>/^FullName / {
>        name533 = substr($2,1,5) substr($3,1,3) substr($4,1,3)
>        if (name533 in used) collisions++
>        used[name533]++
>}
>
>END {
>  print collisions, "collisions"
>}
>
>For 1036 unique font names from Monotype and Bitstream fonts in my
>file tree, there are 292 collisions.  For a set of 97 unique font
>names in PostScript fonts collected from various UNIX vendor font
>sets, I found 37 collisions.  That is 28% and 38% respectively.
>
>I don't have a similar set of .afm files for Adobe fonts, so I cannot
>make the experiment for them, but at least for non-Adobe fonts, the
>5+3+3 algorithm is unusable.

Yes, but the Adobe scheme is actually 5+3+3+3+3...  until you get sick of it.

What's the result of trying *that* algorithm on a set of fount names?  As
far as I can see, it does produce unique names (except in the case of
different founts having the same name - how common is this?)

>What is wanted here is a perfect hashing algorithm that produces names
>that are short and guaranteed unique.  If it should also be generable
>by a human, then the only algorithm that suffices is to use the full
>name.  But that requirement conflicts with about 200M desktop
>computers that are stuck with 8+3 limits.  That is why font vendors
>have gone to arbitrary names like 1097a___.afm for Bitstream's
>"Venetian 301 Demi", and most PostScript software supports mapping
>files to convert long font names to short file names.

Yes, this much I understand.

>Adobe software, for example, uses the PSres.upr file, which contains
>entries like this:
>
>...
>FontAFM
>AGaramond-Bold=metrics/adobe/adobegar/afm/padb0.afm
>AGaramond-BoldItalic=metrics/adobe/adobegar/afm/padbi0.afm
>AGaramond-Italic=metrics/adobe/adobegar/afm/padri0.afm
>AGaramond-Regular=metrics/adobe/adobegar/afm/padr0.afm
>...
>
>and the mkpsres program (e.g., in the ps2pk15/PSres distribution) can
>build such a file given a top-level directory under which fonts are
>found.

Righto - what sort of software uses this file?  I've used some Adobe
software (ATM is on my Mac at the moment) and I've never met this file.

>I think Karl Berry did an excellent job in his font naming package,
>and we need to stick with it, though, by all means, let us also
>support name mapping files.

I agree with the basic idea that Karl did a good job, but his naming scheme
does have its problems.  It certainly doesn't meet the criteria of
producing unique names for all founts, but given the abominable 8+3 limit,
that's hardly surprising.

I wasn't suggesting the Adobe Mac scheme as a replacement, although if a
replacement *were* produced, I think something similar would be better than
Karl's `long' fontname scheme, which results in names which strike me as
far too long for anyone with a cli to want to touch.  (Come to think of it,
I've got a GUI and I don't want filenames that long).

Rowland.