[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Font naming rears its ugly head again
- To: alanje@cogs.susx.ac.uk
- Subject: Re: Font naming rears its ugly head again
- From: mackay@cs.washington.edu (Pierre MacKay)
- Date: Mon, 30 Aug 93 13:47:42 -0700
- Cc: tex-fonts@math.utah.edu
- Flags: 000000000000
- In-Reply-To: Alan Jeffrey's message of Mon, 30 Aug 93 21:03 BST <m0oXFS6-000EuvC@csrj.crn.cogs.susx.ac.uk>
Indeed. The differences between the Cork encoded Adobe Times generated
by fontinst and that distributed with psnfss are (or rather, will be,
once I've finished the thing!):
* font dimensions: the afm2tfm program produces very sparse setting,
with large values for space, stretch and shrink. The fontinst package
produces much tighter setting
The values for spacing are apparently fixed for stretch and shrink, but the
basic space is taken from the width of the space character in the afm file.
I once tried zeroing out that width in the afm file before inputting
to afm2tfm and got a font with no interword space at all. Anyway, the
loose setting is governed more by what the producer of the afm file
sets than by afm2tfm
* kerning: the composite letters are kerned the same as the
non-composite equivalents, for example <Aacute> kerns like <A>, and
<IJ> kerns like <I> on the left and <J> on the right. This is
necessary because many PostScript fonts (notably those from Adobe)
don't have any kerning for non-American glyphs.
That will be a great addition, although I suspect that kerning is
becoming a dangerous mania. The huge Kern Pair table in my
Monotype BaskervilleMT.afm produces a set so tight it squeeks, and
in medium resolution at least it is impossible to keep letters
>From bleeding into each other in the Italics. Oddly, the afm for this
font is copyrighted by Adobe, not by Monotype. I hope it doesn't
turn out to be a NewBaskerville table hacked mechanically into shape.
Better no kerning at all than that. For now, I relax the entire set
of leftward kern values by 1/2 unit.
In lowercase, the kerning for an accented letter may not be the same
as for the unadorned letter. A heavily accented language like Turkish
gets to look very fussy if kerned as tightly as English text
* monospace fonts: the fontinst package goes out of its way to make sure
the monospaced fonts are monospaced, for example letterspacing the
small caps so that they're the same width as the caps. It also
provides for number-range-dash and punctuation-dash ligatures in
Cork-encoded monowidth fonts.
figuredash is provided as a simple glyph in a lot of expert fonts, but
the width is the same as endash, and more interestingly the charcter bounding
box is the same. If you make up a special figure-dash you are certainly
adding more finesse than the commercial fonts I have seen.
* expert fonts: the fontinst package can produce fonts which mix glyphs
from the standard and expert font, so at a site with the expert fonts,
the <f> and <i> glyphs would come from the standard encoding, and the
<ffi> glyph from the expert encoding.
This is of course possible now, but only by hand editing the vpl file.
* digit styles: the fontinst package can generate fonts with ranging or
oldstyle digits, and with fixed-width or variable-width digits.
Ditto.
* rounding errors: the rounding errors produced by the fontinst package
when converting afm dimensions to TeX dimensions will be slightly
different from those produced by afm2tfm.
There are a few other differences (such as accent positioning)
I think you may have real trouble automating accent positioning.
I have recently worked on a set of under and over accents for
Turkish, and I found no way of getting satisfactory general accent
positioning, especially in italics except by hand editing over about
five passes. The worst, or best, of it is that when egregiously
badly placed accents are corrected, they make some that had previously
looked acceptable look painfully out of place.
but I don't think those make any difference to the tfm file.
Email concerned with UnixTeX distribution software should be sent primarily
to: elisabet@u.washington.edu Elizabeth Tachikawa
otherwise to: mackay@cs.washington.edu Pierre A. MacKay
Smail: Northwest Computing Support Center Resident Druid for
Thomson Hall, Mail Stop DR-10 Unix-flavored TeX
University of Washington
Seattle, WA 98195
(206) 543-6259