[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Next fontinst version and code I once sent

Hello, Ulrik.

As it is now over five weeks since you said you wouldn't have time to do
anything about fontinst during the next few weeks, since you had to finish
your thesis within two, I would believe that you may now at least have
enough spare time to answer some questions I have about it.

1. Whatever became of the code I sent you a few months ago? (I suppose I
had expected some kind of a "Thank you for your contribution. I will look
at it when I get time." in reply.) Have you had any time to look at it? (I
hope it doesn't make you "thouroughly confused", as you once wrote my
multislots package did.)

2. Is it too late, or in any other way not appropriate at this time, to
come with another contribution? I am currently testing some changes I have
made and so far they seem to work fine. It all started with a
reimplementation of the boundarychar support in .etx files (as I wrote a
little about on the fontinst list last week), but while I was working with
that, I also noticed and fixed (with reservation for the fact that I am not
done testing yet) the following bugs and problems in fontinst:

 * Correct interpretation of (LABEL BOUNDARYCHAR) in the LIGTABLE of a .pl
file being converted to a .mtx.

 * Errors in LABEL instructions in a .pl file will be reported when that
instruction is read, not at every kern in the program following it.

 * Only kerns between two slots that are actually mensioned in the encoding
will be written to the .mtx. Currently, there is a check before writing a
\setrawglyph, but not before writing a \setkern.

 * I implemented a command \pltomtxgivenetx{PL}{MTX}{ETX} which allows a
user to override the CODINGSCHEME instruction in the .pl file, by
explicitly selecting an encoding file. (I suggested such an instruction as
a solution to a problem Vladimir Volovich had with the encoding of cmr5 a
while back.) It shares almost all code with the ordinary \pltomtx.

 * I reimplemented the way fontinst remembers assignments of glyphs to
slots. As it is now, fontinst knows at most one slot number per glyph. This
causes a problem if you are making an all-caps fonts the trivial way, i.e.,
having \lc equal to the normal \uc and so on, because at most one of the
slots in which a glyph is used will have a KRN instruction written for it.
(NB: This affects the right glyph in a kerning pair, not the left.) Thus AV
and Av in such an all-caps font will kern differently. The reimplementation
fixes this problem.

Apart from these fixes, I have as mensioned implemented a new syntax for
boundarychar support. This new implementation currently has the drawback of
not being backward compatible, but it actually occured to me while I was
writing this that it can easily be made backward compatible. I intend to do
so this weekend.

3. How is the update coming along in general?

Lars Hellström