summaryrefslogtreecommitdiff
path: root/help/virtualfonts.txt
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
committerNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
commite0c6872cf40896c7be36b11dcc744620f10adf1d (patch)
tree60335e10d2f4354b0674ec22d7b53f0f8abee672 /help/virtualfonts.txt
Initial commit
Diffstat (limited to 'help/virtualfonts.txt')
-rw-r--r--help/virtualfonts.txt233
1 files changed, 233 insertions, 0 deletions
diff --git a/help/virtualfonts.txt b/help/virtualfonts.txt
new file mode 100644
index 0000000000..f93fdfc737
--- /dev/null
+++ b/help/virtualfonts.txt
@@ -0,0 +1,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