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

Re: glyph naming problems with MathTime

Ulrik wrote:
> 
> This weekend, I've had a first try at installing a MathTime version of
> the new encodings and promptly ran into a problem with glpyh names.
> 
> The problem is that the MC encoding follows Adobe Symbol in that it
> uses `Upsilon' and `Upsilon1' for the normal and variant Upsilon.
> (`Upsilon' is the one that looks like a Latin `Y', while `Upsilon1' 
> is the one that looks like TeX's `\Upsilon'.)
> 
> Now it happens that MathTime's mtmi uses `Gamma1' ... `Omega1' for 
> the upright version of the Greek capitals (hence `Upsilon1'), while 
> the italics versions are called `Gamma' ... `Omega' (hence `Upsilon').
> The result of this is that the `Upsilon1' is incorrectly recognized 
> as a variant italic Upsilon instead of a non-variant upright Upsilon.

And to make things even worse, lucidabr.sty uses \varGamma etc to 
access the slanted Greek capitals which clashes with the use of the \var
prefix for variants like \varUpsilon.
 
> To sort out this mess I can think of two possible solutions:
> 
> - use a different name in MCraw.etx to distinguish between the normal 
>   and variant Upsilon, e.g. `Upsilon' and `Ypsilon' 
> 
> - create a suitable mtmi.etx encoding file and install the font 
>   from PL instead of AFM  (or edit the glyph names in the AFM files)
> 
> So far, I've experimented with the first alternative, but I wasn't
> completely happy about the situation, since I not only had to rename 
> the glyphs with
> 
>   \setglpyh{Gammaupright}\glyph{Gamma1}{1000}\endsetglyph
> 

In my work on Lucida, I also had to put loads of \replaceglyph{bla}{bla}
statements in the mtx files.

> but also had to reshuffle the kern pairs with
> 
>   \setkern{Gammaupright}{*}{\kerning{Gamma1}{*}}
> 
> (This has to be done for the skewchar (arrowhookright) anyway, but 
> all the other kern pairs would have to be handled this way as well.)

For the time being, I have completely neglected kerning pairs and concentrated
on getting the glyphs in place.  But you are right, this has to be done
as well.
 
> Using the second alternative might be preferable to this, since it
> would help to avoid the reshuffling of kern pairs as `Gammaupright'
> would be recognized as that directly from the .etx file.
> 
> Comments, anyone?
> 

You are probably right that pl+etx is less insane than afm+mtx. If only
fontinst would produce an etx file from the afm file as a starting point. 

> P.S.  For the upright lowercase greek from mtmu, reshuffling the
> glyph names will be necessary anyhow.  Using an mtmu.etx file and
> installing from PL instead of AFM seems to be the easier way to go.
> 
> P.P.S.  Berthold, another question about MathTime: How many versions
> do we really need?  One MC font table with upright lowercase Greek
> included (if MathTime Plus is avilable) and another one with these
> glyphs missing (if restricted to MathTime only)?  Same story about
> MSP with or without mtms (MathScript from MathTime Plus)?
> 

Berthold, the same questions arise wrt to Lucida. lucidabr.sty has three
variants wrt to scaling (lucidascale, lucidasmallscale, lucidanoscale). 
I have implemented these by loading appropriate fd files. There are also 
three variants wrt to math italics, which I have not implemented yet.
These would probably lead to three versions of the MC encoded font. 

Ulrik, what do you think, should we provide the virtual fonts for
MathTime/Lucida in just one size (since the type1 fonts they are using
come in only one design size anyway) ? I have tried this for Lucida
by putting definitions like 

\def\xlasizes{\do{}{}{<->}}
 
in tex/sizes.tex. This causes xla.vpl to be produced; instead of
xla<design size>.vpl

Regards, Matthias
 
-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: clasen@mathematik.uni-freiburg.de
Institut fuer Mathematik, Albert-Ludwigs-Universitaet Freiburg