Re: What's the relationship between vfs and tfms?

[Rebecca and Rowland <rebecca@astrid.u-net.com>]

>Hi:
>
>   >That is, the psfonts.map has two entries to force reencoding of the `raw'
>   >font to anything you want, no need to add additional reshuffling using VF.
>
>   But that does mean you need different encoding vectors for each occurrance
>   of a different encoding *and* each different dvi driver.  The nice thing
>   about the vf approach is that you need one 8r encoding vector for each dvi
>
>Not sure I see the difference.  The DVI processor has to reencode the
>font in any case.  Whether it reencodes to 8r or the encoding the user
>actually wants (LY1 say) doesn't make much difference (other than not
>needing VF in the latter case).

But it does make a difference, because you need a vector to re-encode from
T1, from OT1, from LY1, from TS1, etc., and any other encoding you feel the
need to use.  And all these encoding vectors are system-dependent: they are
not portable across the entire TeX world.

With the 8r scheme, you *do* need a system-dependent re-encoding file, but
only *one* per system.

>	Also, the encoding vector is a *constant* --- it does not depend
>	on the platform.

The encoding vector might have a constant *effect* if you are using PS
founts; but it's not necessarily an identical file on all TeX systems.

[snip]
>It is *NOT* a mapping from one set of numbers in the range (0-255)to
>another ser of numbers in the range of (0-255).  (Which is all VF can do).

Yes, I understand this.  You might like to consider that OzTeX uses
re-mapping for non-PS printing, because re-encoding is (I'm told) rather
difficult under those circumstances.

>   driver (rather than OT1, T1, and any others that are in use); and the
>   OT1->8r and T1->8r mapping is handled by a single encoding vector (for each
>   encoding) that works for all TeX installations.  If everyone used dvips and
>   the same PostScript founts, then this non-vf approach wouldn't have any
>   drawbacks.  But what of those of us who use TrueType founts on Macintoshes,
>   without using dvips?
>
>Then you are in trouble in any case, since there is no way to reencode
>a TrueType font on the Mac (other than changing the actual font file).
>You are stuck with what is in Mac standard roman encoding.  This means
>you won't have access to 21 of the `standard' 228 glyphs (like eth, thorn).

To use an argument you used elsewhere: for `simple' use, this doesn't
matter.  After all, I've never been known to write in Icelandic; and
virtually all Mac users who *do* write in Icelandic *do* have access to
these characters.

>(Unlike Windows NT where some software can reencode the TrueType vectors
>just like Type 1 and make even f-ligatures accessible in TT fonts).
[snip]

Now that would be handy.  I suppose I'll have to wait for Unicode.

[snip]

>Sigh.  Which means you do not have 58 accented characters and about 30
>other special characters!

Yep.

>  No hyphenation in `foreign' languages in
>TeX.

Hmm...  Accented characters could be faked with fontinst.

> Not sure what you are getting at here.  Surely nobody used it
>that way (In prehistoric times, DVIPS had its own hard-wired
>unadvertized internal encoding which it applied to  text fonts -
>so at that point in history you wouldn't mention an encoding vector
>in psfonts.map).

This is how it was done according to Alan Jeffrey's documentation for
fontinst v1.335.

[snip]
>See above.  The encoding vector is not *different* for different drivers,
>since it does *not* depend on the underlying encoding of the text font
>(or whatever the operating system reencodes the text font to).

But the precise form of each encoding vector file *does* depend on the
syntax required by the particular dvi driver you are using.  And not all
TeX dvi drivers can handle re-encoding; some of them must use re-mapping,
which is entirely system-dependent.

>The encoding vector *replaces* whatever was there.  The original encoding
>might as well be a null vector for all it matters.
>
>For example, many people happily use LY1 (TeX 'n ANSI encoding) - even
>on Unix.  All you need do is \usepackage[LY1]{fontenc} and no need for
>`text companion' fonts. These people all use the *same* encoding vector.
>(Modulo different drivers requiring it in slightly different formats:
>DVIPS wants an actual PostScript array, OzTeX wants a `charnumber glyphname'
>format).

Which is the problem.

Actually, OzTeX wants a re-mapping vector looking like this:

\005 $FD     /hungarumlaut
\006 "L"     /Lslash            approximation
\007 "l"     /lslash            approximation

`charnumber charnumber glyphname' - very different to what dvips wants, and
quite system-dependent.

[snip]

>   Can anyone who helped make this particular design decision explain it?  As
>   I see it (in my ignorance), the vf re-mapping is used because it's portable
>   and works on all TeX systems.
>
>Yes, all systems that use DVIPS :-)

Not only dvips - OzTeX's non-PS driver can use vfs, as can all other
current dvi drivers I've heard of.  And if your dvi driver doesn't handle
vfs, you can use dvicopy. (? my memory might be at fault here).

> And even there it is not needed for
>this purpose.
>
>   The extra re-mapping to 8r strikes me as
>   more of a necessary evil, and is only put up with because you only need one
>   single re-encoding vector file for each dvi driver, so it doesn't add too
>   much to the mess of system-dependent files we've got anyway.
>
>No.  As explained above, the encoding vector is always the same.

No it's not - see your own comment below.  Nor is your comment terribly
relevant: the 8r encoding vector is, in general, system dependent, but you
only need one per system, rather than dozens of system-dependent files per
system if you drop vfs.

>It simply says what glyph you are going to get for each numeric
>character code.  (The physical expression of the encoding vector
>may differ because different drivers may like to see it in different
>forms - but the mapping from number to glyph is constant).

Precisely - so the actual encoding file *in general* differs between
systems, even though each version might have the same effect in the case of
PostScript Type 1 founts.  Which means that you need system-dependent
files.  I don't see that it matters that the files are intended to have an
identical effect; if the files are not actually identical in form, they're
system-dependent.

[snip]

Rowland.