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

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

>Hi:
>
>   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.
>
>I think we have been through this: unlike a remapping scheme, which
>does have to take into account the target encoding, a reencoding is
>*not* system-dependent.

But the precise syntax of the re-encoding file *is* system dependent, no
matter what the aim of the file.

>  It *overwrites* whatever encoding the system
>wants to use, so what the system wants to use becomes irrelevant.
>This is an important point and we'll keep on going round and round if
>it is not understood.

I've understood this point.  We're going round in circles because you seem
to misunderstand the point I'm trying to make.

>  I am not talking about the particular syntax
>some driver uses, but the concept of the encoding vector.

But I *am* talking about the particular syntax some driver uses.  After
all, the fact that the end result of the encoding vector is identical is
*irrelevant*.  The point is that different dvi drivers, in general, use
different syntaxes.

The point that the encoding vectors perform an identical function doesn't
matter in the slightest - the problem is that given that different dvi
drivers need different syntaxes (in general), you get system-dependent
files.  That is: files that differ in form (not function: form) from system
to system.

Never mind the theoretical point that the function of the encoding vector
is identical for all PS dvi drivers, the physical form of the encoding
vector is system dependent, which means you have system dependent files,
even if those files perform an identical function.  The point is that the
file differ from system to system, even if they *do* perform the same
function.

>   With the 8r scheme, you *do* need a system-dependent re-encoding file, but
>   only *one* per system.
>
>No.  The 8r.enc and 8r.vec files are constant.

Yes they are constant: they are system-dependent files used by dvips (and
friends).  Not all dvi drivers can use those files.  Other dvi drivers use
different files: system dependency, you see.

>   >	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.
>
>Well, some systems need to it written out one way, some another.
>But the basic idea is the same: a map from numbers to glyph names.

But that's irrelevant: never mind the basic point, the files differ in form
>From system to system.  Unlike, say, .vf files, which are identical on all
computers.

>   >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.
>
>Yes, unfortunately on the Mac people haven't yet figured out how to
>reencode fonts other than via the PostScrip route.  So they can only
>use what is in Mac standard roman encoding on screen and for non-PS
>printing.  But just because remapping is all that can be done there is
>not to say that this is either a good thing or in any way a substitute for
>true reencoding.

It *is* a good thing and it is a substitute for what you term re-encoding,
because without it, we wouldn't be able to have *any* sort of re-encoding.

>   >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.
>
>Hmm, how about ff, ffi, ffl ligatures in the Lucida fonts?  Can't use them
>on the Mac.

Yes you can: you've got to print using Postscript, though.  But if I were
to spend money buying founts, I expect I'd've spent money so I could print
PostScript.

>   >TeX.
>
>   Hmm...  Accented characters could be faked with fontinst.
>
>Typographically this is not a good thing.  Best to use the ready-made
>accented characters the designer created.

Best, yes.  But it's not necessarily a typographically bad thing, is it?
Surely the faking fontinst does is often nearly indistinguishable from the
`real' thing?

[snip]
>   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.
>
>In which case they are sunk anyway as far as this dicsussion goes...

Why do you say that?

[snip]

>   `charnumber charnumber glyphname' - very different to what dvips wants, and
>   quite system-dependent.
>
>It's just syntax.

Yes - exactly.  The precise details of the syntax are the point, and part
of what gives that file its system-dependency.

Rowland.