# italic correction

Lars Hellström Lars.Hellstrom@math.umu.se
Thu, 13 Jan 2000 13:28:15 -0500

December 23 (which is a while ago, but I haven't read my mail for a while),
Hilmar Schlegel wrote:
>Lars Hellström wrote:
>> In fontinst v1.9 the italic correction is computed by two integer
>> expressions \uprightitalcorr and \slanteditalcorr, which you can change
>
>A very good idea.
>
>> yourself using \resetcommand (you've got to read the source comments to see
>> what the arguments are, though; it's in the "converting an AFM file to an
>> MTX file" subsection"). \slanteditalcorr is used for fonts with positive
>> italic slant and \uprightitalcorr is used for all others. Setting
>> \uprightitalcorr equal to \slanteditalcorr would probably achieve what you
>> want.
>>
>> Actually this reminds me of something I thought about a while back, namely
>> that the italic correction fontinst by default computes is probably a bit
>> too small since it doesn't include the standard right leading for the font.
>
>I used for some time the following with acceptable results:
>\def\afm_char{
>   \a_count=-\bbox_lly
>   \if_italic
>      \b_count=-\x_width
>%%%+
>      \ifnum\b_count<0\b_count=0
>      \fi
>   \else
>      \ifisint{fontdimen(13)}\then

Using fontdimen(13) (max depth) at this point seems rather bizarre. The
fontdimen(<number>) variables are normally unset when AFM files are being
converted, instead they are set by an ETX file, since their meaning depends
on the encoding used.

>       \b_count=-\x_width
>       \ifnum\b_count>0\else
>          \b_count=0
>       \fi
>      \else
>      \b_count=-\x_width
>      \ifnum\b_count<0\b_count=0
>%      \ifnum\b_count>-1\else
>%         \b_count=0
>      \fi
>%%%+        \b_count=0
>      \fi
>   \fi
>
>> The problem is that there is no way of getting this information. I believe
>> though that the difference between the advance width and bounding box right
>> edge position for the letter s (in the n shape) should be a good
>
>Why "s" ? It is suboptimal since for example fraktur fonts with "long s"
>have a completely different shape here - essentially an "f". I don't
>know of a good definition of the "standard leading" for a font except a
>qualified guess.

Indeed, it definitely wouldn't be any good for such fraktur fonts. But for
most antiqua and sans serif fonts I believe it is the best qualified guess
you can make based on the information in an AFM file alone. What would make
s suitable is that there are no points on the bounding box that are very
far from the actual ink (unlike the case with for example o), nor are there
any horizontal serifs.

I have no intention of making this observation the basis for some macro for
getting the leading of a font though, I just intended it as a simple
description of what should be a good approximation of the true thing.

>> approximation. The command for doing this would be
>>
>>
>> if one assumes that the leading is 50. In case anyone gives this a try,
>
>This is clearly an advantage to have the parameter defined by a command
>
>BTW, many thanks for your efforts to improve fontinst considerably. It
>is a pity however that still I cannot make use of the new versions due
>to the many changes & adaptions made to latin.mtx (currently 114Kb), OT1
>(currently 157 Kb). Perhaps I find some time to re-implement things for
>the new versions. One major change necessary for me is that composites
>get a width according their resulting bbox (in contrast to having the
>width of the base character). This is essential for things like
>d-quoteright.

I have implemented something in this direction, although it is not the true
thing. \glyphbboxright (no arguments) is an integer expression that will
return the greatest advance width reached so far in the glyph currently
being constructed---thus it will see things inserted by \glyphpcc and the
like. Actually storing the bounding boxes for each glyph would require
reconstructing quite a lot of fontinst, and I don't think it's worth it.

>Something what is/was nasty is that there are problems with .fd files
>which contain non-sequencial ranges of font sizes: one font 5-9 pt, an
>alternative for 10pt and again the first font for 11-pt. This requires
>to process the same fonts twice to get them in order into the fd file. I
>don't know if there is some definition that 5-9pt, 11-pt for one font
>and 10pt for the second one is forbidden - but it won't work.

You mean the resulting FD file contains something like

\DeclareFontShape{OT1}{zaa}{m}{n}{%
<<5-10>> <<11->> zaar7t
<<10>> zaar7t10
}{}

and it doesn't work? fntguide.tex seems to say it should, so if it doesn't
then it looks like an error in LaTeX. The \DeclareFontShape command should
become like that if you use <<5-10>> <<11->> as the last argument of
\installfont.

There is also a command \installfontas on the To Do list which could be
used for this sort of thing. It should basically add an entry to the FD
file, but not write any VPL or PL file itself. Perhaps I should do

>Still it would be nice to have a way to access the character bbox
>dimensions. This would require only one additional parameter in the mtx
>data. I see however that there is probably no simple way for a
>compatible change of the format.
>A last point what was/is nasty is that the specification of minimumkern
>is not global, i.e. if defined before an \installfont command the value
>is lost/not used.

No \setint is global, so all fontinst integers are subject to the same
problem. Setting minimumkern outside the \installfonts ... \endinstallfonts
block or in an MTX file appearing in \installfont's file-list argument will
work.

>Many thanks for your efforts and best wishes for a Merry Christmas and a
>Happy new millenium for you.
>
>Hilmar Schlegel
>###

Well thank you! I wich you the same, even though I might be a bit late.

January 7, Alexei Kostin wrote:
>Dear Lars:
>
>When I tried to use my old install scripts with FI 1.91, I got
>a number of unclear error messages. After debugging I realized that if one
>has an \installfont command where a MTX file is not reachable, than
>FI 1.91 processes such a command without any distinct error message.
>Certainly, problems do occur further but the reason for these
>problems becomes vague.

Noted. I'll do something about it.

Lars Hellström