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

Re: 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.

Hello Lars, I have indeed finished my thesis some to weeks ago, but
I've been busy with other things such as preparing for my final exam
(next Friday), writing job applications and doing job interviews.

All I did so far was too process my accumulated fontinst mail into
hypertext format in order to get an overview over what has been 
going on during the past months.

http://www.tug.org/~vieth/fontinst/mail-html/1998/ 

> 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.)

I suppose I got your code somewhere, but never really looked at it.
I'm afraid I won't get to it before the Christmas holidays, but I
promise that I will try to take care of it as soon as I can.

> 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:

I suppose it would be helpful to separate bug fixes and new features.
As for bug fixes, I'd be happy to integrate whatever you have. 
As for new features, it depends on whether or not they might break
old fontinst applications, and whether they are generally accepted
by the user community.

>  * 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.

So far, you're talking bug fixes, right?

>  * 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.

Nice idea, indeed.  I'll probably have to take a closer look.

>  * 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.

I'm confused.  Is this a bug fix or a new feature?

> 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.

Not being backwards compatible might be a problem, indeed.

> 3. How is the update coming along in general?

Not very well, right now, but I hope I'll get to it sooner or later.
Sometime between Christimas and new year might be a good estimate.

Cheers, Ulrik.