Return-Path: 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: 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 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 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 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