Re: Fontinst modifications

[Lars Hellström <Lars.Hellstrom@math.umu.se>]

I'm happy to see that my suggestion for a discussion caused so much
positive activity. Having the creation of a new, official, DOCed,
well-documented fontinst v1.8 on the way is certainly more than I had hoped
for when I wrote my email.


As there has been some interest in my packages, I will send them to Ulrik
Vieth and Sebastian Rahtz (these two seems to be the ones most likely to be
the ones who will be involved in writing the next version of fontinst). If
there is a wider demand for them, I could also post them to other people or
to the fontinst mailing list. But be warned: The only documentation there
is is the comments in the source code (very fontinst style, perhaps a
little longer at times) and I have only had the time to use them with
fontinst v1.504 so I cannot tell whether they will work with the newer
versions. (In case they will be posted to the mailing list, can anyone tell
me whether it delivers attachments or should I include the files in in the
main body?)


(As I do happen to be particular about such things, I do want to point out
to some people that when the genitive form of a noun ending in `s' is
formed in English, then this is done by adding 's or only ' to the end of
the word. Thus my forename would become Lars's or Lars', not Lar's.)


As for all this stuff about what various font variants should be called,
isn't it time the fontname scheme is given a major update? As far as I
understand it, much of the reason there are so many alternative names is
that there is not room for full specifications even of quite common fonts
within the eight character limit imposed by some CD file system standard. I
have also heard that some new standard for file systems will allow
filenames up to 255 characters, thus effectively rendering the eight
character limit obsolete. Another observation I have made about "Filenames
for fonts" is that it is primarily written for people who want to decode
font filenames, not for people who want to find out what to name a font.


The question about oldstyle figures or not has many aspects, and I would
like to point out some that are of a more typographical origin. First
however, an opinion: I think all fonts that were originally designed before
the invention of newstyle digits in the 18th century should be implemented
with oldstyle digits as the default, since that is how the font designer
made them. They usually look much better that way. (On the other hand, the
oldstyle digits of some modern fonts look terrible and should be avoided.)

Now the typography: No matter how nice the oldstyle digits may be, there
are a couple of situations when they should not be used. The first is when
the digit appears as part of a "word" (usually some kind of abbreviation)
that is otherwise all upper case. It seems engineers a particularly fond of
coining these by replacing repeated letters by some kind of
pseudo-exponent, but there are other examples: Every room at my university
seems to be given a name consisting of two letters and three digits, my
room being ME316. Names of roads is another frequent source of such names.

The second situation is when the digits appear on a line which is otherwise
all-caps (not uncommon in headlines) and the third is numbers in
mathematical formulae. The last case is certainly no problem in TeX as math
fonts and text fonts are usually different, and the second case could also
be taken care of through the use of all-caps fonts (the typographically
concerned editor certainly should), but the first case remains as a
troublesome one.

I usually handle this by putting newstyle digits in the small caps variant
and oldstyle digits in the normal (for fonts with oldstyle digits as
default), but doing so is clearly not a general solution. I therefore
suggest the following approach:
   Extend the character set of the TS1 encoding so that it always
   contains one full set of oldstyle digits and one full set of
   newstyle digits.
Then the people who care can always get the right kind of digit in a
portable way and the ones who don't need not mind. From what I see in
ltoutenc.dtx, there certainly seems to be enough room to accomodate another
set of digits.


Hilmar Schlegel wrote:
>One major problem is that set(right/left)kerning is applied to ALL
>existing kerns of the template character. Since you do not like fakes -
>you'll agree that the Ta kern is usually quite different from the T
>a-diearesis kern. To improve the situation the introduction of different
>types of kern partners would be necessary, i.e. the category "low" and
>"high" for making v using the same kern with a-diearesis like the one
>given by the pair v a but V is "high" and therefore excluded as a kern
>partner for a-diearesis. Another difficulty are the huge numbers of
>useless kerns generated by formal analogy. If there was a category
>"accented" then one could exclude kerns between accented characters
>(like between a-diearesis and y-acute). This reduces the number of kerns
>considerably.
>
>All this would require non-trivial changes to introduce the additional
>attributes/classification of character groups. Any ideas?

In order to unset kerns that have been set, the code in rekern.sty expands
\l-GLYPH and \r-GLYPH macros with \k defined in such a way that
  \k#1#2 -> \noexpand\k\noexpand#1\noexpand#2
(the \noexpands are because all this is done in an \edef) if the kern
should not be removed and
  \k#1#2 ->
otherwise (note: I'm only showing the idea, this is not what \show\k would
print). This approach could be used in copying kerns too, but it is not
very fast. BTW: I better include you in my list of people to send the
packages to as well, but that will have to wail till tomorrow, as I
probably should inculde a few examples of usage as well.

/Lars