[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What's the relationship between vfs and tfms?
Hi:
Concernant « Re: What's the relationship between vfs and tfms? », Berthold K.P. Horn écrit :
« Agreed. But that still doesn't address the question of why yet another layer
« of remapping is needed (VF).
historically, afm2tfm was not able to produce ligfull & kernfull TFMs
for reencoded fontes, VFS were mandatory. There has been an interim
state of the art, where 8r fontes were made by a patched afm2tfm,
could someone tell if afm2tfm is still able to do ligfull 8r TFMs or not?
I believe you may have this back to front. AFM2TFM *was* able to
produce proper TFM files complete with ligatures and kerning long
ago. Unless I am mistaken, this capability was purposefully removed.
Some of it was later reintroduced - as you say.
Now the remaining reason is obviously fontinst's ability of faking
missing charachters. this heavily requires VF machinery, hence a base
TFM from which building fakable chars. The point of 8r here is simply
to have all charachters accessible (encoded) and to minimize problems
for systems that do not support reencoding or `deviant' encodings
(windows & textures were cited, if i recall?).
Actually, not all Windows systems need VF or support it.
Also, while Textures now supports VF, it is not used or needed
(except for cute examples and for MTMI in MathTime).
So the widespread misuse of VF for simple text fonts
should not be blamed on Mac or IBM PC compatibles :-)
There was some confusion on this point at the TUG meeting in
Santa Barbara - and I am responsible for being too tired to
try and fight the rising tide there :-) Other people being
much more persuasive...
I know that Berthold prefers the `buy Y&Y font manipulation tools
software' scheme which in my opinion is not a bad idea if you have
some money to spare, and like manipulating fontes.
Well, as you know, you *don't* need any of that for simple use of text fonts.
And I know that *you* specifically do complex things that cannot be handled
without VF or the FMP.
What is the real discussion underlying this? it's not tex related
indeed. It is true that what a program like fontinst can do on
metrics, a program like y&y's can do on PFBs (using SEAC?). Let's talk
I don't think that is what I was getting at. You don't need any
of the tools in the FMP. Many people happily use Type 1 fonts
on a variety of platforms without VF and lead happy lives
(being able to hyphenate in `foreign' languages and all that).
For this no complex tools are required. No changes to the font files.
of some T1 charachter missing in the `standard glyph set' like
Abreve in Palatino-Roman. And imagine you're talking a language that
requires that one.
Precisely, for *your* complex requirements you must have either VF
or the FMP.
If you use some external program to draw figures, and you (of course)
want the words in the figure to be set in the same fonte as the ones
in your text, (and of course the names in your diagrams require the
letter Abreve...) you need that this letter be _real_ so you have to
modify your fonte.
By chance, this is not needed with TeX thanks to VFs! Remember that
Palatino is resident, and of course not editable: if you do the faking
with VFs you can share your PS files with anybody, and they will print
on any PS device: no need to even buy palatino's PFB to alter it! for
writing on figures, you still have the psfrag or 0-surface picture
approach...
I was not taking about something so complex. I acknowledged that for
complex work VF has power that you can use. My point is that it is a
mistake to force use of this complex and unneccessary machinery
on a simple problem. Since you have to reencode the font in any
case in the DVI processor, you can determine its layout fully.
Why add another layer of rearranging of the character layout?
Why kill a flea with a steam-press :-)?
Regards, Berthold.
P.S. I am sorry this has taken us so far away from the documentation
for fontinst, but maybe it will clarify some font related issues
as a side effect.