Some recent developments

[Lars Hellström]

At 23.47 +0100 2000-02-21, jfm wrote:
>After that, the only thing missing for perfect happyness :
>- in this world : some more documentation/tutorial on how to
>customize latinfamily (say via fontinst.rc) to achieve effects
>as in vfinst [eg, a database of errors in afm's; how to customize
>the set of fonts that will be generated, and according to what
>strategy they will be (for example, like those mentioned on p.16
>of fisource.pdf, including "the most promising one"); how to use
>other parameters of the font family (maybe in a different
>weight/width), like the italic slant or the x-height of the
>smallcaps, etc. ; also: how to use the "Alt" fonts].

Ah yes, the old "improve documentation" ToDo. However, I don't think there
are any hooks for customization of \latinfamily when it comes to combining
glyphs differently (correct me if I'm wrong, Ulrik). The possibilities for
customization lies more in the areas of which series and shapes to make
and/or fake, and which raw encodings to use. For using Alt fonts, you have
to use the \installfont interface, and you probably have to write a couple
of MTX and ETX files of your own as well. (It's a pity latin.mtx is such a
monolithic lump; one of my personal ToDos, which I haven't done anything
about for a long time, is to write a family of MTX files that together have
the functionality of latin.mtx---that way it would be much easier to write
alternatives to one of the parts than it is today.)

>- in heaven :
>	1) forget about TeX and 8r and the past and all its
>complications, get us simply fontinst for omega and unicode,
>so we get access to ALL characters, even of superfonts. After
>all, what are all those encodings good for, since in the final
>ps file glyps are anyway just referred to by their name...

I don't know whether OVP (that's the Omega equivalent of a VPL, isn't it?)
files are Knuthian property lists like VPL, but if they are then I see no
reason why it shouldn't be possible to use the current fontinst for
producing such files. (The filename suffices would be wrong, but that is
trivially taken care of.) The only restriction that exists is that you
cannot use slots with numbers that you cannot have as character codes in
the TeX, but if you run fontinst on Omega then that isn't a problem. In
general, I have nothing against adding support for the extensions of TeX.
(In 1.912 I have included some optional code that defines \ifisint and
friends in terms of eTeX's \ifcsname; the normal definition is still using
\ifx, of course.)

>	2) fontinst embedded in MakeTeXtfm and MakeTeXpk...
>	3) Can one get fontinst to "compile through" ; ie, when
>constructing a set of vf's on top of other such sets, give
>instructions to express the final fonts directly in terms of
>the originals ?

Theoretically yes; currently fontinst ignores MAP property lists when
reading VPL files, but you could make it behave differently by redefining
\MAP (and a couple of other control sequences). As it seems, you would like
a CHARACTER property list that contains a MAP to produce a \setglyph
instead of a \setrawglyph. The main problem you would have to face is that
of determining what the glyphs of the base files should be called.

On the other hand, "compiling through" a VF is probably rather something
that you would have a program that operates solely on VFs and TFMs do. I'd
guess Peter Breitenlohner's DVIcopy program would be an easier starting
point than fontinst.

>> Finally a question: I know some people have written to this
>> list about y-scaling a font (\yscalefont). Could someone
>> explain to me how you got the driver to do this transform?
>> Also, I have the impression that this transform isn't
>> supported by most drivers. Does anyone have a different
>> opinion on this?
>>
>
>I've seen your questions on this subject in the tex-fonts
>list ("primarily directed to the maintainers"). I feel even
>much more incompetent than the maintainers of course, but since
>you don't seem to rceived a lot of response besides those in
>that list, I may risk to lose your time with whatever my
>incompetence has to offer.

That's the spirit!

>[And in case of absolute necessity,
>I'm willing to try some experiments (with a lot of guidance)
>with dvips].
If you decide to, I would recommend you start by looking at the file
texps.lpro from the dvips source code. I'm rather leaning towards using a
completely different solution though, see below.

>There I'm fairly convinced it should work out;
>the people that come to my mind as probably knowing "virtually"
>how to go about it would be :
>- Tim van Zandt : he was the first to see how to use and to
>construct header files etc, but maybe a bit hard to convince to
>back into the fray now...
>- Than seems to know dvips at least as well as anybody: he wrote
>the current partial downloading code...
>- I remember having seen in a "textures.def" file (for the
>graphics package) by OGAWA that he had code even for projective
>transformations (of boxes or the like probaby). If one can define
>such a tansformation (ie, as an operator), one can surely put in
>some header file how to use it (rather than say ExtendFont)
>on a font.

>I forgot to mention Malyshev among the people who might have
>an idea on how to go about it...

OK, thanks for the list.

>	Sorry for being so long,
>
>		Jean-François

Oh, I'd say that's no trouble whatsoever.

At 12.07 +0100 2000-02-22, Thierry Bouche wrote:
>» Finally a question: I know some people have written to this
>» list about y-scaling a font (\yscalefont). Could someone
>» explain to me how you got the driver to do this transform?
>
>I've always used xscaling + isotropic scaling in order to achieve
>this. I wonder whether fontinst could do the computations itself
>(yscalefont would be equivalent to xscalefont+modifying the
>designsize, e.g.?)

Yep, that's exactly what I think I'm going to implement. More precisely,
the \recordtransforms file would get the x-scaling component, whereas the
isotropic scaling would be included in each VPL that uses the font (just
insert an extra \raw_scale in the <mapcommands> and <mapfont> for each raw
glyph) and put in the corresponding entry in the FD (if there was an
\installrawfont for the font). Unless you use the TeX primitives to select
the raw font, there's no way of detecting that it isn't y-scaled by the
driver.

>» Also, I have the impression that this transform isn't
>» supported by most drivers. Does anyone have a different
>» opinion on this?
>
>At least dvips & pdftex don't -- the only ones I know of.

Then it seems that reimplementing \yscalefont will only improve the
capabilities for the major drivers. Good!

Lars Hellström