[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Font naming rears its ugly head again
- To: mackay@cs.washington.edu
- Subject: Re: Font naming rears its ugly head again
- From: alanje@cogs.susx.ac.uk (Alan Jeffrey)
- Date: Tue, 31 Aug 93 12:42 BST
- Cc: tex-fonts@math.utah.edu
- Flags: 000000000000
- In-Reply-To: <9308302047.AA02654@june.cs.washington.edu> (mackay@cs.washington.edu)
Pierre MacKay writes:
>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.
Hmm... goes and investigates...
It turns out that afm2tfm only uses the width of the space character
when the space character is part of the output encoding. So if I say
afm2tfm lbr -O -T adobe.enc -v lbr0.vpl
afm2tfm lbr -O -T T1ulc.enc -v lbrq.vpl
then the Adobe-encoded (with a space characrter) lbr0.vpl has
(SPACE D 304)
(STRETCH D 200)
(SHRINK D 100)
(EXTRASPACE D 111)
and the Cork-encoded (without a space character) lbrq.vpl has:
(SPACE D 500)
(STRETCH D 200)
(SHRINK D 100)
(EXTRASPACE D 111)
Ah, this explains why I've been getting such loose setting from
afm2tfm, since I've been using an output encoding which doesn't have a
space glyph. For reference, the default values produced by fontinst
would be (in points):
(SPACE R 3.04)
(STRETCH R 1.01)
(SHRINK R 1.01)
(EXTRASPACE R 0.0)
These values haven't been extensively road-tested yet, and I may need
to loosen up a bit to avoid overfull boxes everywhere. We shall see.
I chose these values after Richard Southall's talk at Aston, where he
pointed out plain TeX's love of white space, and the resulting visual
fragmentation.
>That will be a great addition, although I suspect that kerning is
>becoming a dangerous mania.
Indeed... but you have to do something with kerning for non-US glyphs.
I suspect what I'll do is fake the kerning for uppercase composites
and lowercase composites with ascenders, but not the kerning for
lowercase composites without ascenders, in order to avoid a collision
with things like <T><oacute>. It's a hack, but what can you do...
>If you make up a special figure-dash you are certainly
>adding more finesse than the commercial fonts I have seen.
Sorry, I should have been clearer about this! There's been some
discussion on the DC list about whether monowidth fonts should include
-- and --- ligatures. The current proposal is that -- should ligature
to a number-range dash and --- should ligature to a puncutation dash.
In many monowidth fonts, the number-range dash will look just like
<hyphen> and the puncutation dash will look just like
<hyphen><hyphen>. This conforms to UK typing of correspondence...
I've asked Rainer Schoepf about this, and we hacked out some code for
verbatim mode which switches off this ligaturing, so -- in verbatim
will still produce <hyphen><hyphen>. Modulo bug-testing, this will
probably be in LaTeX2e.
>I think you may have real trouble automating accent positioning.
Indeed! Most of the accents can be approximated automatically---the
results won't be excellent, but they'll be passable. But there are
some composite glyphs in the Cork encoding that just can't be faked,
notably:
<Aogonek> <Eogonek> <Lacute> <Lcaron>
<aogonek> <dcaron> <lcaron> <tcaron>
Unfortunately, optimizing the last three also changes the tfm file,
drat and bah humbug. Really there's no way to get accent positioning
right without human intervention.
Part of the idea behind the fontinst package (this is turning into an
advert :-) sorry!) is to make hand-tweaking simpler, since the
fontinst package allows for (almost) every part of the VPL file it
generates to be over-ridden by the user. So rather than hand-editing
the VPL file, you just produce a file containing the tweaks, for example:
\setglyph{Lacute} \topaccent{L}{acute}{123} \endsetglyph
\setglyph{lcaron} \glyph{l} \movert{-96} \glyph{quoteright} \endsetglyph
then you run the fontinst package a few times to get the numbers just
right, and hey presto, a tweaked font without any hand-editing of VPL
files. The fontinst package even generates a font table, so you can
even tweak the font without having to run vptovf!
This does produce yet another problem with font naming, of course, as
you now have a parameter for whether the font has been tweaked or not.
And of course, there may be different tweakings of the same font...
Oh if only all AFM files had CC instructions for all the Cork
composite glyphs, life would be so much simpler...
Alan.