1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
|
Return-Path: <spqr@minster.york.ac.uk>
Received: from minster.york.ac.uk by ftp.tex.ac.uk (4.1/SMI-4.1)
id AA16747; Mon, 1 Feb 93 10:52:05 GMT
From: spqr@minster.york.ac.uk
Date: Mon, 1 Feb 93 10:42:10
Message-Id: <swordfish.728563858@minster.york.ac.uk>
To: archive@ftp.tex.ac.uk
In-Reply-To: jeremy@cs.aukuni.ac.nz's message of 28 Jan 93 01:53:05 GMT
Subject: Re: Virtual fonts
Status: R
From: jeremy@cs.aukuni.ac.nz (Jeremy Gibbons)
Newsgroups: comp.text.tex
Date: 28 Jan 93 01:53:05 GMT
Organization: Computer Science Dept. University of Auckland
In <10234580@MVB.SAIC.COM> Ralf Mollenhauer <ENSP067%FRMRS11.BITNET@SHSU.edu> writes:
>Now I would like to know:
>1. Does there exist any documentation about virtual fonts ?
[...]
>4. What are *.vf files for ?
Here is a summary I wrote a while back, complete with comments from
Berthold Horn and Yannis Haralambous.
One of these days I'll get this put in the FAQ.
Jeremy
>Newsgroups: comp.text.tex
>Path: cs18.cs.aukuni.ac.nz!jeremy
>From: jeremy@cs.aukuni.ac.nz (Jeremy Gibbons)
>Subject: Re: Virtual Fonts are...?
>Message-ID: <1992Oct19.235603.9537@cs.aukuni.ac.nz>
>Cc: jeremy@cs.aukuni.ac.nz
>Organization: Computer Science Dept. University of Auckland
>References: <1992Oct16.050908.18407@lugb.latrobe.edu.au>
>Date: Mon, 19 Oct 1992 23:56:03 GMT
In <1992Oct16.050908.18407@lugb.latrobe.edu.au> ecsgrt@luxor.latrobe.edu.au (Geoffrey Tobin) writes:
>1. Exactly what are virtual fonts?
Here is my understanding of virtual fonts. Perhaps others could join in,
and we can put something in the FAQ, or in Geoffrey's "MF for Beginners"?
(I seem to have answered this question half a dozen times recently.)
Knuth discusses virtual fonts in the article "Virtual Fonts: More Fun for
Grand Wizards" in TUGboat 11(1), which was also published in TeXhax,
volume 90, issues 11 and 12. Go and read that article!
In summary, virtual fonts are a solution to the problem of using fonts with
different encodings (in the sense of "mappings from character codes to
character glyphs"). In passing, they also allow you to construct composite
fonts (such as Computer Modern Roman letters with oldstyle digits) and
composite characters (such as accented letters) without having to do
anything clever in TeX. Finally, they provide an elegant solution to the
realisation on one system (eg a previewer) of documents set with fonts
available only on another system (eg a phototypesetter with native fonts),
by substituting available glyphs for unavailable ones. To do all this,
"all we need is a good way to specify a mapping from TeX's notion of a font
character to a device's capabilities for printing".
Corresponding to .pl ("property list") files, there are .vpl ("virtual
property list") files. These describe, in a human-readable format, both the
typesetting information that TeX needs and the information on where to find
specific glyphs that a device driver needs. The format for .vpl files is an
extension of the format for .pl files. All the information on character
metrics (the "metric" information) and ligatures and kerning (the "extra"
information, for want of a better term) that TeX requires in a .tfm file is
there; for every character, there is also information for the device driver
on how to draw the glyph (the "shape" information). The shape information
for a virtual character can take the form of a reference to a character in
another (perhaps also virtual) font, rules or specials, and all of these
can be shifted, scaled and combined. In general, this shape information
"can be any sequence of typesetting commands that might appear in a page of
a DVI file".
There are two programs for processing .vpl files, VPtoVF and VFtoVP; these
convert between the human-readable information and compact machine-readable
data. VPtoVF takes a .vpl file and constructs two files, a .tfm file and a
.vf file; the .tfm file contains the metric and extra information which TeX
needs, and the .vf file contains the metric and shape information which the
device driver needs. VFtoVP takes the .tfm and .vf files and reconstructs
the .vpl file.
Comments?
Jeremy
---
Jeremy Gibbons <jeremy@cs.aukuni.ac.nz> tel: +64 9 373 7599
Department of Computer Science, fax: +64 9 373 7453
University of Auckland, Private Bag 92019, Auckland, New Zealand.
From comp.text.tex Fri Oct 23 18:57:34 1992
From: bkph@kauai.ai.mit.edu (Berthold K.P. Horn)
Date: 21 Oct 92 12:26:30 GMT
Newsgroups: comp.text.tex
Subject: Re: Virtual Fonts are...?
In article <1992Oct19.235603.9537@cs.aukuni.ac.nz> jeremy@cs.aukuni.ac.nz (Jeremy Gibbons) writes:
>1. Exactly what are virtual fonts?
Here is my understanding of virtual fonts. Perhaps others could join in,
and we can put something in the FAQ, or in Geoffrey's "MF for Beginners"?
(I seem to have answered this question half a dozen times recently.)
....
In summary, virtual fonts are a solution to the problem of using fonts with
different encodings (in the sense of "mappings from character codes to
character glyphs").
Just a note on this here: Virtual fonts provide a mechanism for PERMUTING
an encoding vector, not for true reencoding, since they deal only with
numeric codes, not character names. Characters that are not in the base
encoding of the `actual' font, cannot be made accessible by permuting the
mapping. For instance, `Yacute' is not in Adobe StandardEncoding, so if
your DVI driver does not reencode a font using SE, this character is not
accessible, no matter how much you permute the numbers from 0 through 255.
Note also that you do not need necessarily need virtual fonts to reencode a
font. Different DVI drivers provide different mechanisms for doing this.
Some provide instead for on-the-fly reencoding.
There is also a common misconception that one needs virtual fonts in order
to use scalable outline fonts (Type 1, TrueType, etc). This is entirely DVI
driver dependent. Some can deal with scalable outline fonts without virtual
fonts.
In passing, they also allow you to construct composite
fonts (such as Computer Modern Roman letters with oldstyle digits)
This, on the other hand, is something they ARE good for.
and composite characters (such as accented letters) without having to do
anything clever in TeX.
This is less of an issue, since most plain vanilla text fonts in Type 1
format contain 58 standard accented characters (Although some DVI
processors won't let you get at these, however, because of the encoding they
use of the font).
Finally, they provide an elegant solution to the
realisation on one system (eg a previewer) of documents set with fonts
available only on another system (eg a phototypesetter with native fonts),
by substituting available glyphs for unavailable ones.
Again, this has really nothing to do with virtual fonts. Most previewers
(and printer drivers) have a mechanism for substituting existing fonts for
missing ones.
Comments?
See above.
Jeremy
Berthold K.P. Horn
Cambridge, Massachusetts, USA
Date: 26 Jan 1993 13:06:51 +0100
From: yannis@gat.citilille.fr
Subject: virtual fonts
Sender: metafont@dmi.ens.fr
To: Multiple recipients of list <metafont@dmi.ens.fr>
Errors-To: server@dmi.ens.fr
Reply-To: metafont@dmi.ens.fr
Content-Transfer-Encoding: 7BIT
Originator: metafont@dmi.ens.fr
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
Jeremy's description of virtual fonts is very accurate, I would like to add
some comments and thoughts.
A virtual font is a kind of interface between something that is either big
(think of PK files for 2540dpi typesetting machines) or rigid (PostScript
fonts inside some printer) or anyway external to TeX, and TeX itself. As long
as we work with CM/DC fonts everything runs smoothly, but there is the cruel
world of incompatibilities there outside and we shouldn't make a different
version of TeX for every platform or encoding. There is another very important
fact difference between fonts:
-- some of them are made for information exchange
-- some are made to emulate traditional typography
(-- and some are trying to do both, miserably most of the time).
In the first case you only have the characters you need for example for email.
You wan't find there any fi fl ligatures, think of the CM typewriter fonts.
In the second case, you will have characters and/or variants which will serve
only for typographical purposes, that is for the visual representation of your
text.
Most word processors work with one font encoding which aims to cover both needs.
This may still be possible for the Roman script, by making some compromises.
But for other scripts it is impossible (think of Arabic ligatures). In front
of this problem, word processors behave in various ways. For TeX, output quality
is the most important goal. So, in most cases, TeX will use it's own output
fonts, which will take profit of TeX's extraordinary features of box manipu-
lation etc etc.
You see now what I mean: TeX uses it's own fonts for the output (or at least
should use it's own fonts to get the best quality --- a sad counterexample is
Moschovakis' Greek system where quality is sacrified for the sake of IBM's
encoding) and if this output should use external commercail fonts, somebody
must change: either the font, or TeX.
Virtual fonts are there to fill this gap. We can now (and will!!) make
typesetting systems for all languages having typographical quality in our mind
and not compatibility with anything or anyone. A virtual structure will then
insure compatibility with the outside world.
So let me summarize: suppose we want a TeX system for Tomanian.
The input will be done in Tomanian ISO for data exchange, or some equally
important and standardized encoding.
TeX's output will be done using a private encoding, carefully studied so that
all TeX's features having been exploited to insure max typographical quality.
Virtual structures will be used to convert the private encoding found in the
DVI file into any possible encoding of the real Tomanian world.
In my mind, virtual fonts are TeX's passport to travel around the world, and
still remain universal and unique.
Cheers
Yannis
|
