summaryrefslogtreecommitdiff
path: root/help/virtualfonts.txt
blob: f93fdfc737bd811d6fece0cea71849f89486dd06 (plain)
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