14-Feb-1991 17:11:37-GMT,644;000000000011 Return-Path: Received: from uunet.UU.NET by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA00805; Thu, 14 Feb 91 10:11:34 MST Received: from spooky.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA08308; Thu, 14 Feb 91 12:11:33 -0500 Date: Thu, 14 Feb 91 12:11:33 -0500 From: spooky!witr@uunet.UU.NET Message-Id: <9102141711.AA08308@uunet.UU.NET> To: tex-fonts-request@math.utah.edu Subject: Please add me to your mailing list. Content-Type: text Content-Length: 144 Thanks! --- Robert Withrow, R.W. Withrow Associates, Swampscott MA 01907 USA Tel: +1 617 598 4480, Fax: +1 617 598 4430, Email: witr@rwwa.COM 14-Feb-1991 17:38:17-GMT,2199;000000000001 Return-Path: <@cs.umb.edu:karl@ra.cs.umb.edu> Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA01041; Thu, 14 Feb 91 10:38:12 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA28645; Thu, 14 Feb 91 12:37:49 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA02225; Thu, 14 Feb 91 12:37:48 EST Date: Thu, 14 Feb 91 12:37:48 EST From: @cs.umb.edu:karl@ra.cs.umb.edu (Karl Berry) Message-Id: <9102141737.AA02225@ra.cs.umb.edu> To: spooky!witr@uunet.uu.net Cc: tex-fonts@math.utah.edu In-Reply-To: spooky!witr@uunet.uu.net's message of Thu, 14 Feb 91 12:11:30 -0500 <9102141711.AA08291@uunet.UU.NET> Subject: font names Reply-To: karl@cs.umb.edu Robert Withrow posted a message to TeXhax about font names. I wrote back suggesting the font mapping file I brought up before. me> Then some scheme like X's (but I am strongly against wildcards) could be me> developed. Robert> I also discourage the use of wildcards, but they *do* have their uses Robert> (especially in special applications other than normal document Robert> generation. I am specifically thinking of the pixel related values, Robert> but I can imagine valid uses for wildcards in the other fields also). Robert> I think that prohibiting the use of wildcards would be bad Robert> engineering. I don't think X's scheme should be adopted verbatim. Those pixel-related values should disappear entirely in the TeX world, I think. What are the valid uses of the wildcards you can imagine? I can think of two reasons offhand not to allow wildcards: 1) increases complexity of the implementation (you can probably guess that I am speaking as an implementor here); 2) users will inevitably be lazy and specify Av*-book-whatever instead of AvantGarde-book-whatever and then when their site gets `Avenir', their documents will suddenly stop working. I can't imagine any circumstances in which I, as a user, would want to partially specify a font in my document (this might well reflect a lack of imagination on my part). P.S.: I know Nelson said that we shouldn't post anything to tex-fonts until the list membership settles, but, well, I couldn't stop myself. Sorry. 14-Feb-1991 18:39:23-GMT,1975;000000000001 Return-Path: Received: from uunet.UU.NET by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA01452; Thu, 14 Feb 91 11:39:19 MST Received: from spooky.UUCP by uunet.UU.NET (5.61/1.14) with UUCP id AA09883; Thu, 14 Feb 91 13:39:19 -0500 Date: Thu, 14 Feb 91 13:39:19 -0500 From: spooky!witr@uunet.UU.NET Message-Id: <9102141839.AA09883@uunet.UU.NET> To: uunet!ra.cs.umb.edu!karl@uunet.UU.NET (Karl Berry) Cc: tex-fonts@math.utah.edu Subject: Re: font names Content-Type: text Content-Length: 1448 > I don't think X's scheme should be adopted verbatim. Those > pixel-related values should disappear entirely in the TeX world, I > think. Why do you think a user should be prevented from specifing the use of a font that has been pixelated at a specific density? I would certainly find that annoying when I am designing fonts... > What are the valid uses of the wildcards you can imagine? WYSIWYG applications. > I can think of two reasons offhand not to allow wildcards: > 1) increases complexity of the implementation Copy the code from the X-Window distribution. > 2) users will inevitably be lazy...their documents will suddenly > stop working. Lazy TeX users can find a plethora of ways to make their documents ``suddenly stop working''. That's not a good reason to stop unlazy users from doing usefull things. The thing to remember is the even if you and I couldn't think of a reason for someone to use a particular feature (even in our wildest dreams) that is not a reason to delete that feature. The will be someone who *will* think of a use for the feature, and will be rightly disgruntled if you prevent him/her from using it. There *are* good reasons for deleting a feature: a) Impossible to implement, b) easier way to do the same thing, c) performance considerations, Etc etc etc... --- Robert Withrow, R.W. Withrow Associates, Swampscott MA 01907 USA Tel: +1 617 598 4480, Fax: +1 617 598 4430, Email: witr@rwwa.COM 17-Feb-1991 1:19:13-GMT,3921;000000000001 Return-Path: Received: from CC.UTAH.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA01434; Sat, 16 Feb 91 18:19:10 MST Received: from TAMVM1.TAMU.EDU (MAILER@TAMVM1) by CC.UTAH.EDU with PMDF#10043; Sat, 16 Feb 1991 18:18 MST Received: from TAMVM1 (X066TR) by TAMVM1.TAMU.EDU (Mailer R2.07) with BSMTP id 8697; Sat, 16 Feb 91 19:16:53 CST Date: Sat, 16 Feb 91 18:21:39 CST From: "Thomas J. Reid" Subject: Re: more TeX font stuff In-Reply-To: Message of Tue, 5 Feb 1991 18:08 PST from To: Don Hosek , karl@ra.cs.umb.EDU, "Nelson H.F. Beebe" , mackay@june.cs.washington.EDU, barbara beeton , spqr@ecs.soton.ac.UK, Leonard Boyle Message-Id: <432C0EDA8CC04584@CC.UTAH.EDU> X-Envelope-To: beebe@science.utah.EDU Organization: Texas A&M University Computing Services Center On Tue, 5 Feb 1991 18:08 PST Don Hosek said: >Regarding mode_defs, I've been thinking about putting together a >mode_def subdirectory on the ymir archive. I'd be glad to have >you do the work of creating the files. My initial thought was to >include each mode_def twice: once in its own file in a format >suitable for smode (i.e., sans the mode_def..enddef wrapper) and >once in a collected file. The former would be useful for the poor >sods who don't have the necessary privs to add a mode_def to the >plain.bas. > >On write_white devices, multiple mode_defs seem to be the best >way to handle getting the best output. Some work was done at >Texas A&M a few years back (in conjunction with the TeXrox >development) but those who did the work are all gone to >countries bordering the Indian Ocean and haven't been heard from >in quite a while. Not entirely true: I got a letter from Glenn Vanderburg the very day you sent this note. ;-) > Tom Reid should be able to mail something on >this topic to us so I've included him in my list of recipients. > >ttfn >-dh The work that Don refers to consisted of adjusting the blacker and fillin values for each of the Computer Modern fonts. This task was done by Medhi Widjaja (who has since graduated and returned to Indonesia and now works in Jakarta). Medhi came up with a list of blacker/fillin pairs for nearly all of the CM fonts at magstep0. Experiments showed that the same values applied rather well for non-zero magsteps. He actually ran two sets of blacker/fillin pairs; one for our Xerox 4050 printer, and another for our 9700s. Both are writes-white engines, but they use different fusing technologies and have different speeds (50 ppm v. 120 ppm). Glenn Vanderburg's (who has since graduated and moved to Perth, Australia) part in this was to take the list of pairs which Medhi came up with and define a set of modedefs. Of the complete set of pairs, Glenn defined ten to twelve different modedefs; altering some values slightly to "round" to the nearest selected modedef. We then regenerated the complete set of fonts using these modedef values. Medhi subsequently wrote a UNIX shell script and a VM/CMS EXEC file (based on Don Hosek's MFTOOL EXEC, I think) to read a list of font names, magsteps, blacker, and fillin values then run METAFONT to build the fonts. This process uses a single modedef with fairly generic values since the actual values for blacker and fillin are supplied by the script/EXEC. The is work presently being done at the State University of New York at Stony Brook to tune the individual fonts for the Xerox 4650. This is a 50 ppm printer with the same fusing technology as the 4050, but with 600 dots per inch. I have added Len Boyle to the list of recipients to comment on the progress on that project. If anyone is interested in seeing any of the work, let me know and I'll see what files are still around. ---Tom Reid 18-Feb-1991 23:05:30-GMT,571;000000000011 Return-Path: Received: from usc.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09834; Mon, 18 Feb 91 16:05:28 MST Received: from [131.62.7.1] by usc.edu (5.64+/SMI-3.0DEV3) id AA08336; Mon, 18 Feb 91 15:04:21 PST Message-Id: <9102182304.AA08336@usc.edu> Date: 18 Feb 91 14:52:00 PDT From: "JohnM" Subject: mailing list for fonts and tex To: "tex-fonts-request" To: "tex-fonts-request" please put me on the list!!! 20-Feb-1991 19:05:23-GMT,4636;000000000001 Return-Path: Received: from magna.math.utah.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA21242; Wed, 20 Feb 91 12:05:19 MST Date: Wed, 20 Feb 91 12:05:19 MST From: Nelson H.F. Beebe To: tex-fonts Cc: beebe X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: (801) 581-5254 Subject: tex-fonts mailing list now operational Message-Id: At the suggestion of several people, a new mailing list has been created for the discussion of font issues relating to TeX, METAFONT, and other font generation systems, where relevant to use by TeX. This list is tex-fonts@math.utah.edu and following Internet conventions, subscription and/or deletion requests should be sent to tex-fonts-request@math.utah.edu They should NOT be sent to the first address, because that is just an alias for automatic remailing to the entire list; the -request address is an alias for the list maintainer (currently, me). Plurals are always a nuisance, so the word 'fonts' in these two may by replaced by 'font'; the official names are those given above. This list is UNMODERATED; anything posted to the list will be immediately rebroadcast to everyone on it. Proper netmail etiquette is expected. If you want to reply to an individual who will later post a summary of responses to a query, make sure you adjust your outgoing mail header, because most mailers' REPLY commands will otherwise direct it to the entire list. I expect this list to remain small; it will not be restricted like the tex-char@dhdurz1.bitnet and latex-l@dhdurz1.bitnet lists are. However, progress is more likely if the list members are primarily font experts concerned with enhancing the availability of fonts for use by TeX on many different output devices. This list is separate from the tex-char list, which is devoted to the issue of standardizing the encoding of the upper 128 characters of the 256-character sets that became available with TeX 3.0 and METAFONT 2.0. Nevertheless, I expect some overlap in membership. The current membership, some chosen by request, and some by suggestions of other members, is appended to this message. If you wish to have anyone else added, just send a note to tex-fonts-request. Karl Berry has asked whether the creation of this list should be posted on other forums, such as texhax, uk-tex, comp.text.tex, texmag, euro-tex, ... I'm not opposed to doing so, but I fear that it might lead to a large membership, diluting the efforts of the hard core experts. I therefore propose a poll of the current membership on this question; send your votes directly to beebe@math.utah.edu. In any event, archives of all tex-fonts correspondence will be maintained in the tuglib collection (also accessible via anonymous ftp) on math.utah.edu, where they will be accessible to anyone on the Internet with either e-mail or ftp access. The exact name and location of this collection will be posted later. "TeX Font mailing list; last update [20-Feb-1991]": beebe@math.utah.edu, ![12-Feb-1991] Nelson H. F. Beebe! bnb@math.ams.com, ![12-Feb-1991] Barbara N. Beeton! DHosek@ymir.Claremont.edu, ![12-Feb-1991] Don Hosek! dlatex@cmsa.berkeley.edu, ![13-Feb-1991] Doug Henderson! jmr@nada.kth.se, ![12-Feb-1991] Jan Michael Rynning! karl@cs.umb.edu, ![19-Feb-1991] Karl Berry! LenBoyle@sbccvm.bitnet, ![20-Feb-1991] Leonard Boyle! mackay@cs.washington.edu, ![12-Feb-1991] Pierre MacKay! mike@inrs-telecom.uquebec.ca, ![12-Feb-1991] Michael Ferguson! Norbert.Schwarz%ruba.rz.ruhr-uni-bochum.dbp.de@relay.cs.net, ![13-Feb-1991] Norb ert Schwarz! spooky%witr@uunet.uu.net, ![19-Feb-1991] Robert Withrow! S.P.Q.Rahtz@ecs.southampton.ac.uk, ![12-Feb-1991] Sebastian Rahtz! ucir001@frors12.bitnet, ![12-Feb-1991] Bernard Gaulle! x066tr@tamvm1.bitnet, ![20-Feb-1991] Thomas J. Reid! x92@dhdurz1.bitnet, ![12-Feb-1991] Joachim Lammarsch! xitijsch@ddathd21.bitnet ![12-Feb-1991] Joachim Schrod! ======================================================================== Nelson H.F. Beebe Center for Scientific Computing Department of Mathematics 220 South Physics Building University of Utah Salt Lake City, UT 84112 Tel: (801) 581-5254 FAX: (801) 581-4148 Internet: beebe@math.utah.edu ======================================================================== 21-Feb-1991 5:04:23-GMT,834;000000000000 Return-Path: Received: from CCVM.sunysb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA25195; Wed, 20 Feb 91 22:04:18 MST Received: from ccvm.sunysb.edu by CCVM.sunysb.edu (IBM VM SMTP V2R1) with BSMTP id 2227; Thu, 21 Feb 91 00:04:35 EST X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender. Received: from ccvm.sunysb.edu (LENBOYLE) by ccvm.sunysb.edu (Mailer R2.07) with BSMTP id 2287; Thu, 21 Feb 91 00:04:35 EST Date: Thu, 21 Feb 91 00:03:55 EST From: Leonard Boyle To: tex-fonts-request@math.utah.edu Message-Id: <910221.000005.EST.LENBOYLE@ccvm.sunysb.edu> Please subscribe Leonard Boyle to the tex-fonts list. Thanks Len Boyle SUNY at Stony Brook, NY 11794-2400 21-Feb-1991 12:31:11-GMT,29266;000000000001 Return-Path: Received: from life.ai.mit.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA27365; Thu, 21 Feb 91 05:30:45 MST Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA02727; Thu, 21 Feb 91 07:30:26 EST From: bkph@ai.mit.edu (Berthold K.P. Horn) Received: by rice-chex (4.1/AI-4.10) id AA19084; Thu, 21 Feb 91 07:30:20 EST Date: Thu, 21 Feb 91 07:30:20 EST Message-Id: <9102211230.AA19084@rice-chex> To: karl@cs.umb.edu Subject: TeX abbreviated font names - the real problem Cc: dhosek@ai.mit.edu, beebe@csc-sun.math.utah.edu, TeXhax@cs.washington.edu Hi: my previous attempts to mail a message like this appear to have been stymied by our mailer. So here goes again. I apologize if you get this more a second time. Below is an out of data list of AFM files from the Adobe file-server. It is out of date, since I got it a couple of days ago. Did you really come up with abbreviated names for all 770 fonts in this list? And what about other vendors (BitStream has over a thousand fonts)? Are you willing to continually come up with new abbreviations as fonts are converted to electronic form? How can two letter abbreviations of font names be used with vendors that have more than 626 font families in their catalog (presently none do, but this may happen)? It is not enough to come up with names for those fonts that are `important' or `often used' - people don't agree on what is esthetically pleasing or appropriate - otherwise we wouldn't have this plethora of fonts to choose from in the first place. Someone has to take on the responsibility of coming up with abbreviations for TeX use - or at least to act as a clearing house for proposed abbreviations (much like the Adobe Unique ID coordinator assigns numbers to fonts submitted). But why create yet another committee, when vendors already had to come up with abbreviations to use on operating systems that restrict file name length? How about just adopting these abbreviations. Then there is no argument over what obscure 2 or 3 letter combination hasn't been used yet - or delay while some committee mulls the issue. Berthold. Appendix: *_*_*_*_*_* AFM Files *_*_*_*_*_* AGaramond-Bold AGaramond-BoldItalic AGaramond-Italic AGaramond-Regular AGaramond-Semibold AGaramond-SemiboldItalic AGaramond-Titling AGaramondAlt-Italic AGaramondAlt-Regular AGaramondExp-Bold AGaramondExp-BoldItalic AGaramondExp-Italic AGaramondExp-Regular AGaramondExp-Semibold AGaramondExp-SemiboldItalic Aachen-Bold AkzidenzGrotesk-Black AkzidenzGrotesk-Bold AkzidenzGrotesk-Light AkzidenzGrotesk-Roman AmericanTypewriter-Bold AmericanTypewriter-Medium Americana Americana-Bold Americana-ExtraBold Americana-Italic AntiqueOlive-Black AntiqueOlive-Bold AntiqueOlive-BoldCond AntiqueOlive-Compact AntiqueOlive-Italic AntiqueOlive-Light AntiqueOlive-Nord AntiqueOlive-NordItalic AntiqueOlive-Roman ArnoldBoecklin AvantGarde-Book AvantGarde-BookOblique AvantGarde-CondBold AvantGarde-CondBook AvantGarde-CondDemi AvantGarde-CondMedium AvantGarde-Demi AvantGarde-DemiOblique Avenir-Black Avenir-BlackOblique Avenir-Book Avenir-BookOblique Avenir-Heavy Avenir-HeavyOblique Avenir-Light Avenir-LightOblique Avenir-Medium Avenir-MediumOblique Avenir-Oblique Avenir-Roman BauerBodoni-Black BauerBodoni-BlackCond BauerBodoni-BlackItalic BauerBodoni-Bold BauerBodoni-BoldCond BauerBodoni-BoldItalic BauerBodoni-Italic BauerBodoni-Roman Bauhaus-Bold Bauhaus-Demi Bauhaus-Heavy Bauhaus-Light Bauhaus-Medium Belwe-Bold Belwe-Condensed Belwe-Light Belwe-Medium Benguiat-Bold Benguiat-Book Berkeley-Black Berkeley-BlackItalic Berkeley-Bold Berkeley-BoldItalic Berkeley-Book Berkeley-BookItalic Berkeley-Italic Berkeley-Medium Bodoni Bodoni-Bold Bodoni-BoldCondensed Bodoni-BoldItalic Bodoni-Book Bodoni-BookItalic Bodoni-Italic Bodoni-Poster Bodoni-PosterCompressed Bodoni-PosterItalic Bookman-Bold Bookman-BoldItalic Bookman-Demi Bookman-DemiItalic Bookman-Light Bookman-LightItalic Bookman-Medium Bookman-MediumItalic BrushScript BundesbahnPi-One BundesbahnPi-Three BundesbahnPi-Two Candida-Bold Candida-Italic Candida-Roman Carta CascadeScript CaslonFiveForty-Italic CaslonFiveForty-Roman CaslonOpenFace CaslonThree-Italic CaslonThree-Roman Caxton-Bold Caxton-BoldItalic Caxton-Book Caxton-BookItalic Caxton-Light Caxton-LightItalic Centennial-Black Centennial-BlackItalic Centennial-Bold Centennial-BoldItalic Centennial-Italic Centennial-Light Centennial-LightItalic Centennial-Roman Century-Bold Century-BoldCondensed Century-BoldCondensedItalic Century-BoldItalic Century-Book Century-BookCondensed Century-BookCondensedItalic Century-BookItalic Century-Light Century-LightCondensed Century-LightCondensedItalic Century-LightItalic Century-Ultra Century-UltraCondensed Century-UltraCondensedItalic Century-UltraItalic CenturyExpanded CenturyExpanded-Italic CenturyOldStyle-Bold CenturyOldStyle-Italic CenturyOldStyle-Regular Charlemagne-Bold Charlemagne-Regular Cheltenham-Bold Cheltenham-BoldItalic Cheltenham-Book Cheltenham-BookItalic Cheltenham-Light Cheltenham-LightItalic Cheltenham-Ultra Cheltenham-UltraItalic Cheq Clarendon Clarendon-Bold Clarendon-Light Clearface-Black Clearface-BlackItalic Clearface-Bold Clearface-BoldItalic Clearface-Heavy Clearface-HeavyItalic Clearface-Regular Clearface-RegularItalic Cochin Cochin-Bold Cochin-BoldItalic Cochin-Italic Concorde-Bold Concorde-BoldItalic Concorde-Italic Concorde-Roman CooperBlack CooperBlack-Italic Copperplate-ThirtyAB Copperplate-ThirtyBC Copperplate-ThirtyOneAB Copperplate-ThirtyOneBC Copperplate-ThirtyThreeBC Copperplate-ThirtyTwoAB Copperplate-ThirtyTwoBC Copperplate-TwentyNineAB Copperplate-TwentyNineBC Corona Corona-Bold Corona-Italic Cottonwood Courier Courier-Bold Courier-BoldOblique Courier-Oblique DomCasual DomCasual-Bold Doric-Bold Eurostile Eurostile-Bold Eurostile-BoldCondensed Eurostile-BoldExtendedTwo Eurostile-BoldOblique Eurostile-Condensed Eurostile-Demi Eurostile-DemiOblique Eurostile-ExtendedTwo Eurostile-Oblique Excelsior Excelsior-Bold Excelsior-Italic FetteFraktur Folio-Bold Folio-BoldCondensed Folio-ExtraBold Folio-Light Folio-Medium FranklinGothic-Book FranklinGothic-BookOblique FranklinGothic-Condensed FranklinGothic-Demi FranklinGothic-DemiOblique FranklinGothic-ExtraCond FranklinGothic-Heavy FranklinGothic-HeavyOblique FranklinGothic-Roman FreestyleScript FrizQuadrata FrizQuadrata-Bold Frutiger-Black Frutiger-BlackItalic Frutiger-Bold Frutiger-BoldItalic Frutiger-Italic Frutiger-Light Frutiger-LightItalic Frutiger-Roman Frutiger-UltraBlack Futura Futura-Bold Futura-BoldOblique Futura-Book Futura-BookOblique Futura-CondExtraBoldObl Futura-Condensed Futura-CondensedBold Futura-CondensedBoldOblique Futura-CondensedExtraBold Futura-CondensedLight Futura-CondensedLightOblique Futura-CondensedOblique Futura-ExtraBold Futura-ExtraBoldOblique Futura-Heavy Futura-HeavyOblique Futura-Light Futura-LightOblique Futura-Oblique Galliard-Bold Galliard-BoldItalic Galliard-Italic Galliard-Roman Garamond-Bold Garamond-BoldCondensed Garamond-BoldCondensedItalic Garamond-BoldItalic Garamond-Book Garamond-BookCondensed Garamond-BookCondensedItalic Garamond-BookItalic Garamond-Light Garamond-LightCondensed Garamond-LightCondensedItalic Garamond-LightItalic Garamond-Ultra Garamond-UltraCondensed Garamond-UltraCondensedItalic Garamond-UltraItalic GaramondThree GaramondThree-Bold GaramondThree-BoldItalic GaramondThree-Italic GillSans GillSans-Bold GillSans-BoldItalic GillSans-Italic GillSans-Light GillSans-LightItalic Glypha Glypha-Bold Glypha-BoldOblique Glypha-Oblique Gothic-Thirteen GothicBBB-Medium-78-H GothicBBB-Medium-78-H.Zba GothicBBB-Medium-78-V GothicBBB-Medium-78-V.Zba GothicBBB-Medium-83pv-RKSJ-H GothicBBB-Medium-83pv-RKSJ-H.Zba GothicBBB-Medium-Add-H GothicBBB-Medium-Add-H.Zba GothicBBB-Medium-Add-V GothicBBB-Medium-Add-V.Zba GothicBBB-Medium-Ext-H GothicBBB-Medium-Ext-H.Zba GothicBBB-Medium-Ext-V GothicBBB-Medium-Ext-V.Zba GothicBBB-Medium-H GothicBBB-Medium-H.Zba GothicBBB-Medium-V GothicBBB-Medium-V.Zba GothicBBB-Medium.Roman Goudy Goudy-Bold Goudy-BoldItalic Goudy-ExtraBold Goudy-Heavyface Goudy-HeavyfaceItalic Goudy-Italic Helvetica Helvetica-Black Helvetica-BlackOblique Helvetica-Bold Helvetica-BoldOblique Helvetica-Compressed Helvetica-Condensed Helvetica-Condensed-Black Helvetica-Condensed-BlackObl Helvetica-Condensed-Bold Helvetica-Condensed-BoldObl Helvetica-Condensed-Light Helvetica-Condensed-LightObl Helvetica-Condensed-Oblique Helvetica-ExtraCompressed Helvetica-Light Helvetica-LightOblique Helvetica-Narrow Helvetica-Narrow-Bold Helvetica-Narrow-BoldOblique Helvetica-Narrow-Oblique Helvetica-Oblique Helvetica-UltraCompressed HelveticaInserat-Roman HelveticaNeue-Black HelveticaNeue-BlackItalic HelveticaNeue-Bold HelveticaNeue-BoldItalic HelveticaNeue-Heavy HelveticaNeue-HeavyItalic HelveticaNeue-Italic HelveticaNeue-Light HelveticaNeue-LightItalic HelveticaNeue-Medium HelveticaNeue-MediumItalic HelveticaNeue-Roman HelveticaNeue-Thin HelveticaNeue-ThinItalic HelveticaNeue-UltraLight HelveticaNeue-UltraLightItal Hiroshige-Black Hiroshige-BlackItalic Hiroshige-Bold Hiroshige-BoldItalic Hiroshige-Book Hiroshige-BookItalic Hiroshige-Medium Hiroshige-MediumItalic Hobo Impressum-Bold Impressum-Italic Impressum-Roman Ironwood Italia-Bold Italia-Book Italia-Medium ItcEras-Bold ItcEras-Book ItcEras-Demi ItcEras-Light ItcEras-Medium ItcEras-Ultra ItcKabel-Bold ItcKabel-Book ItcKabel-Demi ItcKabel-Medium ItcKabel-Ultra JansonText-Bold JansonText-BoldItalic JansonText-Italic JansonText-Roman Juniper Kaufmann Kaufmann-Bold Korinna-Bold Korinna-KursivBold Korinna-KursivRegular Korinna-Regular KuenstlerScript-Black KuenstlerScript-Medium KuenstlerScript-TwoBold LetterGothic LetterGothic-Bold LetterGothic-BoldSlanted LetterGothic-Slanted Life-Bold Life-Italic Life-Roman Linoscript Linotext Lithos-Black Lithos-Bold Lithos-ExtraLight Lithos-Light Lithos-Regular LubalinGraph-Book LubalinGraph-BookOblique LubalinGraph-Demi LubalinGraph-DemiOblique Lucida Lucida-Bold Lucida-BoldItalic Lucida-Italic LucidaMath-Extension LucidaMath-Italic LucidaMath-Symbol LucidaSans LucidaSans-Bold LucidaSans-BoldItalic LucidaSans-Italic MICR Machine Maximus MediciScript Melior Melior-Bold Melior-BoldItalic Melior-Italic Memphis-Bold Memphis-BoldItalic Memphis-ExtraBold Memphis-Light Memphis-LightItalic Memphis-Medium Memphis-MediumItalic Meridien-Bold Meridien-BoldItalic Meridien-Italic Meridien-Medium Meridien-MediumItalic Meridien-Roman Mesquite Minion-Black Minion-Bold Minion-BoldItalic Minion-DisplayItalic Minion-DisplayRegular Minion-Italic Minion-Ornaments Minion-Regular Minion-Semibold Minion-SemiboldItalic Minion-SwashDisplayItalic Minion-SwashItalic Minion-SwashSemiboldItalic MinionExp-Black MinionExp-Bold MinionExp-BoldItalic MinionExp-DisplayItalic MinionExp-DisplayRegular MinionExp-Italic MinionExp-Regular MinionExp-Semibold MinionExp-SemiboldItalic Minister-Black Minister-BlackItalic Minister-Bold Minister-BoldItalic Minister-Book Minister-BookItalic Minister-Light Minister-LightItalic Mistral NeuzeitS-Book NeuzeitS-BookHeavy NewAster NewAster-Black NewAster-BlackItalic NewAster-Bold NewAster-BoldItalic NewAster-Italic NewAster-SemiBold NewAster-SemiBoldItalic NewBaskerville-Bold NewBaskerville-BoldItalic NewBaskerville-Italic NewBaskerville-Roman NewCaledonia NewCaledonia-Black NewCaledonia-BlackItalic NewCaledonia-Bold NewCaledonia-BoldItalic NewCaledonia-Italic NewCaledonia-SemiBold NewCaledonia-SemiBoldItalic NewCenturySchlbk-Bold NewCenturySchlbk-BoldItalic NewCenturySchlbk-Italic NewCenturySchlbk-Roman NewsGothic NewsGothic-Bold NewsGothic-BoldOblique NewsGothic-Oblique Novarese-Bold Novarese-BoldItalic Novarese-Book Novarese-BookItalic Novarese-Medium Novarese-MediumItalic Novarese-Ultra NuptialScript OCRA OCRB Optima Optima-Bold Optima-BoldOblique Optima-Oblique Orator Orator-Slanted Palatino-Bold Palatino-BoldItalic Palatino-Italic Palatino-Roman Parisian ParkAvenue Peignot-Bold Peignot-Demi Peignot-Light Ponderosa PostAntiqua-Bold PostAntiqua-Roman Present PrestigeElite PrestigeElite-Bold PrestigeElite-BoldSlanted PrestigeElite-Slanted Quorum-Black Quorum-Bold Quorum-Book Quorum-Light Quorum-Medium Raleigh Raleigh-Bold Raleigh-DemiBold Raleigh-Medium Reporter-Two Revue Rockwell Rockwell-Bold Rockwell-BoldItalic Rockwell-Italic Rockwell-Light Rockwell-LightItalic Ryumin-Light-78-H Ryumin-Light-78-H.Zba Ryumin-Light-78-V Ryumin-Light-78-V.Zba Ryumin-Light-83pv-RKSJ-H Ryumin-Light-83pv-RKSJ-H.Zba Ryumin-Light-Add-H Ryumin-Light-Add-H.Zba Ryumin-Light-Add-V Ryumin-Light-Add-V.Zba Ryumin-Light-Ext-H Ryumin-Light-Ext-H.Zba Ryumin-Light-Ext-V Ryumin-Light-Ext-V.Zba Ryumin-Light-H Ryumin-Light-H.Zba Ryumin-Light-V Ryumin-Light-V.Zba Ryumin-Light.Roman Sabon-Bold Sabon-BoldItalic Sabon-Italic Sabon-Roman SerifGothic SerifGothic-Black SerifGothic-Bold SerifGothic-ExtraBold SerifGothic-Heavy SerifGothic-Light Serifa-Black Serifa-Bold Serifa-Italic Serifa-Light Serifa-LightItalic Serifa-Roman Serpentine-Bold Serpentine-BoldOblique Serpentine-Light Serpentine-LightOblique Serpentine-Medium Serpentine-MediumOblique Shelley-AllegroScript Shelley-AndanteScript Shelley-VolanteScript SimonciniGaramond SimonciniGaramond-Bold SimonciniGaramond-Italic SnellRoundhand-BlackScript SnellRoundhand-BoldScript SnellRoundhand-Script Sonata Souvenir-Bold Souvenir-BoldItalic Souvenir-Demi Souvenir-DemiItalic Souvenir-Light Souvenir-LightItalic Souvenir-Medium Souvenir-MediumItalic StempelGaramond-Bold StempelGaramond-BoldItalic StempelGaramond-Italic StempelGaramond-Roman StempelSchneidler-Black StempelSchneidler-BlackItalic StempelSchneidler-Bold StempelSchneidler-BoldItalic StempelSchneidler-Italic StempelSchneidler-Light StempelSchneidler-LightItalic StempelSchneidler-MedItalic StempelSchneidler-Medium StempelSchneidler-Roman Stencil StoneInformal StoneInformal-Bold StoneInformal-BoldItalic StoneInformal-Italic StoneInformal-Semibold StoneInformal-SemiboldItalic StoneSans StoneSans-Bold StoneSans-BoldItalic StoneSans-Italic StoneSans-Semibold StoneSans-SemiboldItalic StoneSerif StoneSerif-Bold StoneSerif-BoldItalic StoneSerif-Italic StoneSerif-Semibold StoneSerif-SemiboldItalic Symbol Syntax-Black Syntax-Bold Syntax-Italic Syntax-Roman Syntax-UltraBlack Tekton Tekton-Bold Tekton-BoldOblique Tekton-Oblique Tempo-HeavyCondensed Tempo-HeavyCondensedItalic Tiffany Tiffany-Demi Tiffany-DemiItalic Tiffany-Heavy Tiffany-HeavyItalic Tiffany-Italic Times-Bold Times-BoldItalic Times-Italic Times-Roman TimesNewRomanPS TimesNewRomanPS-Bold TimesNewRomanPS-BoldItalic TimesNewRomanPS-Italic TimesTen-Bold TimesTen-BoldItalic TimesTen-Italic TimesTen-Roman TradeGothic TradeGothic-Bold TradeGothic-BoldCondTwenty TradeGothic-BoldCondTwentyObl TradeGothic-BoldOblique TradeGothic-BoldTwo TradeGothic-BoldTwoOblique TradeGothic-CondEighteen TradeGothic-CondEighteenObl TradeGothic-Light TradeGothic-LightOblique TradeGothic-Oblique Trajan-Bold Trajan-Regular TrumpMediaeval-Bold TrumpMediaeval-BoldItalic TrumpMediaeval-Italic TrumpMediaeval-Roman Umbra Univers Univers-Black Univers-BlackOblique Univers-Bold Univers-BoldOblique Univers-Condensed Univers-CondensedBold Univers-CondensedBoldOblique Univers-CondensedLight Univers-CondensedLightOblique Univers-CondensedOblique Univers-Light Univers-LightOblique Univers-Oblique Universal-GreekwithMathPi Universal-NewswithCommPi UniversityRoman Utopia-Black Utopia-Bold Utopia-BoldItalic Utopia-Italic Utopia-Ornaments Utopia-Regular Utopia-Semibold Utopia-SemiboldItalic Utopia-Titling UtopiaExp-Black UtopiaExp-Bold UtopiaExp-BoldItalic UtopiaExp-Italic UtopiaExp-Regular UtopiaExp-Semibold UtopiaExp-SemiboldItalic VAGRounded-Black VAGRounded-Bold VAGRounded-Light VAGRounded-Thin Versailles-Black Versailles-BlackItalic Versailles-Bold Versailles-BoldItalic Versailles-Italic Versailles-Light Versailles-LightItalic Versailles-Roman Walbaum-Bold Walbaum-BoldItalic Walbaum-Italic Walbaum-Roman Weidemann-Black Weidemann-BlackItalic Weidemann-Bold Weidemann-BoldItalic Weidemann-Book Weidemann-BookItalic Weidemann-Medium Weidemann-MediumItalic Weiss Weiss-Bold Weiss-ExtraBold Weiss-Italic WoodtypeOrnaments-One ZapfChancery-MediumItalic ZapfDingbats 21-Feb-1991 15:05:47-GMT,2220;000000000000 Return-Path: <@cs.umb.edu:karl@ra.cs.umb.edu> Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA27670; Thu, 21 Feb 91 08:05:33 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA00625; Thu, 21 Feb 91 10:05:12 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA08422; Thu, 21 Feb 91 10:04:38 EST Date: Thu, 21 Feb 91 10:04:38 EST From: @cs.umb.edu:karl@ra.cs.umb.edu (Karl Berry) Message-Id: <9102211504.AA08422@ra.cs.umb.edu> To: bkph@ai.mit.edu Cc: tex-fonts@math.utah.edu In-Reply-To: Berthold K.P. Horn's message of Wed, 20 Feb 91 07:42:57 EST <9102201242.AA09654@wheat-chex> Subject: TeX abbreviated font file names - Reply-To: karl@cs.umb.edu bkph> Did you make up abbreviations for all 770 font file names here? I haven't checked your list against the one I had a few months ago, but yes, I did all the ones on that list (modulo the ones I didn't know what they meant, which you already replied to me about in a private message). > If so, will > you be happy to continue making up names as new fonts are added to this list > on a weekly basis? Yes. Weekly sounds horrible, though. > And the same goes for other vendors, some of whom also > already have hundreds of fonts in their catalogs. That people are using with TeX? > It won't be satisfactory > to only have names for `important' fonts - everyone has different ideas on > what is `important'. Namely, whatever they have! > But why duplicate the effort already being expended by font vendors? > Since they want there fonts to be useable on many different platforms, they > already have been forced to come up with 6 (or sometimes 8) character > abbreviations. If we just use these there is no need for yet another > committee - and no need for the confusion created by having two competing > sets of abbreviations. Do their schemes conflict? E.g., does Bitstream's name scheme coexist happily with Adobe's? No 6 or 8 letter scheme can solve the font name problem. You have to have arbitrary length names before it can be done ``right''; until we 1) ask DEK about a font mapping file, and 2) implement it, we will inevitably have confusion. (I am somewhat depressed about the whole thing.) karl@cs.umb.edu 22-Feb-1991 13:11:01-GMT,578;000000000000 Return-Path: Received: from life.ai.mit.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA05645; Fri, 22 Feb 91 06:10:58 MST Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA05910; Fri, 22 Feb 91 08:10:53 EST From: bkph@ai.mit.edu (Berthold K.P. Horn) Received: by rice-chex (4.1/AI-4.10) id AA25813; Fri, 22 Feb 91 08:10:48 EST Date: Fri, 22 Feb 91 08:10:48 EST Message-Id: <9102221310.AA25813@rice-chex> To: tex-fonts-request@math.utah.edu please sign me up for discussion of font name issues and such. thanks. 24-Feb-1991 2:45:24-GMT,4694;000000000001 Return-Path: Received: from CC.UTAH.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA14990; Sat, 23 Feb 91 19:45:21 MST Received: from TAMVM1.TAMU.EDU (MAILER@TAMVM1) by CC.UTAH.EDU with PMDF#10043; Sat, 23 Feb 1991 19:45 MST Received: from TAMVM1 (X066TR) by TAMVM1.TAMU.EDU (Mailer R2.07) with BSMTP id 1624; Sat, 23 Feb 91 19:20:25 CST Date: Sat, 23 Feb 91 17:30:55 CST From: "Thomas J. Reid" Subject: Re: tex-fonts mailing list now operational In-Reply-To: Your message of Wed, 20 Feb 91 12:05:19 MST To: "Nelson H.F. Beebe" Message-Id: X-Envelope-To: beebe@math.utah.EDU Organization: Texas A&M University Computing Services Center On Wed, 20 Feb 91 12:05:19 MST you said: >... > >Karl Berry has asked whether the creation of this list should be >posted on other forums, such as texhax, uk-tex, comp.text.tex, texmag, >euro-tex, ... I'm not opposed to doing so, but I fear that it might >lead to a large membership, diluting the efforts of the hard core >experts. I therefore propose a poll of the current membership on this >question; send your votes directly to beebe@math.utah.edu. Nelson, I feel that the list should be kept as small as possible so that progress can be made. I think that this has been the main problem with the DRIV-L list and the DVI driver standards process: there has been an attempt to solicit opinions from all TUG members too early in the process. Certainly, all TUG members should be given the opportunity to comment on standards, but I think that its better to have a small working group come up with the standards, then post them to TeXhax, publish them in TUGBoat, or whatever. Regarding my membership in this list: My duties at TAMU have shifted to mainly network applications programming. I am still doing some work on TeXrox, but it is definitely a background project. It is unlikely that I will be contributing very much to the discussion. If you wish to keep the membership limited to those actually defining the standards, feel free to remove my name from the list. I have had some experiences in trying to reduce font names to a naming convention in my TeXrox development. TeXrox can use fonts in two different ways: fonts can be resident on the printer; or TeXrox will build a bitmap image of characters from fots which are not resident. Resident fonts are considerably more efficient than bitmapped ones. However, the names of these resident fonts had to be made to fit Xerox naming conventions. Specifically: o Names can be from one to six characters consisting of letters or digits o Separate resident fonts are required for different orientations o Separate resident fonts are required for different magnifications o For larger fonts, it is necessary to split a single "TeX" font into multiple resident fonts o The names of the fonts needs to be kept distinct from the names of other fonts already on the printer. What I did was to declare that some formula which mapped the name used in TeX to a Xerox name was not practical. Instead, the program which converts PK/GF/PXL files into Xerox fonts assigns the names simply in a sequential fashion. The format of the name is: TFxxxo where "xxx" is a three "digit" hexadecimal number assigned by the conversion utility and "o" indicates the orientation (P for portrait, L for landscape, I for inverse portrait, and J for inverse landscape). "TF" stands for TeX font which distinguishes the font from others on the printer. If the "TeX" font requires multiple Xerox fonts because of size, the conversion program outputs multiple fonts assigning different numbers to the "xxx" portion of the name. To make this mapping of names and handling of split fonts transparent to the TeX user, the font conversion program also outputs an index file under the name and magnification of the font as known by TeX which gives the Xerox name or names. TeXrox uses the index files to do all mapping which makes the process transparent to the TeX user. (Another feature of the index file is that it remaps character codes. This was necessary since codes 0x00 through 0x0f are reserved for Xerox fonts.) I decribe my naming convention merely for your information. I do not think that it would apply to the problem that the tex-fonts list is trying to address. With mine, I have the luxury of being in control of all programs which deal with the convention. Thus, a convention which relies entirely on centralization works. I am also able to conceal the Xerox names from the TeX user in normal circumstances. ---Tom Reid 24-Feb-1991 2:45:24-GMT,4694;000000000011 Return-Path: Received: from CC.UTAH.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA14990; Sat, 23 Feb 91 19:45:21 MST Received: from TAMVM1.TAMU.EDU (MAILER@TAMVM1) by CC.UTAH.EDU with PMDF#10043; Sat, 23 Feb 1991 19:45 MST Received: from TAMVM1 (X066TR) by TAMVM1.TAMU.EDU (Mailer R2.07) with BSMTP id 1624; Sat, 23 Feb 91 19:20:25 CST Date: Sat, 23 Feb 91 17:30:55 CST From: "Thomas J. Reid" Subject: Re: tex-fonts mailing list now operational In-Reply-To: Your message of Wed, 20 Feb 91 12:05:19 MST To: "Nelson H.F. Beebe" Message-Id: X-Envelope-To: beebe@math.utah.EDU Organization: Texas A&M University Computing Services Center On Wed, 20 Feb 91 12:05:19 MST you said: >... > >Karl Berry has asked whether the creation of this list should be >posted on other forums, such as texhax, uk-tex, comp.text.tex, texmag, >euro-tex, ... I'm not opposed to doing so, but I fear that it might >lead to a large membership, diluting the efforts of the hard core >experts. I therefore propose a poll of the current membership on this >question; send your votes directly to beebe@math.utah.edu. Nelson, I feel that the list should be kept as small as possible so that progress can be made. I think that this has been the main problem with the DRIV-L list and the DVI driver standards process: there has been an attempt to solicit opinions from all TUG members too early in the process. Certainly, all TUG members should be given the opportunity to comment on standards, but I think that its better to have a small working group come up with the standards, then post them to TeXhax, publish them in TUGBoat, or whatever. Regarding my membership in this list: My duties at TAMU have shifted to mainly network applications programming. I am still doing some work on TeXrox, but it is definitely a background project. It is unlikely that I will be contributing very much to the discussion. If you wish to keep the membership limited to those actually defining the standards, feel free to remove my name from the list. I have had some experiences in trying to reduce font names to a naming convention in my TeXrox development. TeXrox can use fonts in two different ways: fonts can be resident on the printer; or TeXrox will build a bitmap image of characters from fots which are not resident. Resident fonts are considerably more efficient than bitmapped ones. However, the names of these resident fonts had to be made to fit Xerox naming conventions. Specifically: o Names can be from one to six characters consisting of letters or digits o Separate resident fonts are required for different orientations o Separate resident fonts are required for different magnifications o For larger fonts, it is necessary to split a single "TeX" font into multiple resident fonts o The names of the fonts needs to be kept distinct from the names of other fonts already on the printer. What I did was to declare that some formula which mapped the name used in TeX to a Xerox name was not practical. Instead, the program which converts PK/GF/PXL files into Xerox fonts assigns the names simply in a sequential fashion. The format of the name is: TFxxxo where "xxx" is a three "digit" hexadecimal number assigned by the conversion utility and "o" indicates the orientation (P for portrait, L for landscape, I for inverse portrait, and J for inverse landscape). "TF" stands for TeX font which distinguishes the font from others on the printer. If the "TeX" font requires multiple Xerox fonts because of size, the conversion program outputs multiple fonts assigning different numbers to the "xxx" portion of the name. To make this mapping of names and handling of split fonts transparent to the TeX user, the font conversion program also outputs an index file under the name and magnification of the font as known by TeX which gives the Xerox name or names. TeXrox uses the index files to do all mapping which makes the process transparent to the TeX user. (Another feature of the index file is that it remaps character codes. This was necessary since codes 0x00 through 0x0f are reserved for Xerox fonts.) I decribe my naming convention merely for your information. I do not think that it would apply to the problem that the tex-fonts list is trying to address. With mine, I have the luxury of being in control of all programs which deal with the convention. Thus, a convention which relies entirely on centralization works. I am also able to conceal the Xerox names from the TeX user in normal circumstances. ---Tom Reid 26-Feb-1991 17:19:32-GMT,1317;000000000001 Return-Path: Received: from CC.UTAH.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA04928; Tue, 26 Feb 91 10:19:28 MST Received: from FRORS12.BITNET (MAILER@FRORS12) by CC.UTAH.EDU with PMDF#10043; Tue, 26 Feb 1991 10:19 MST Received: from FRORS12 (UCIR001) by FRORS12.BITNET (Mailer R2.07) with BSMTP id 0430; Tue, 26 Feb 91 18:18:13 EDT Date: Tue, 26 Feb 91 18:07:51 EDT From: Gaulle Bernard Subject: Re: tex-fonts mailing list now operational In-Reply-To: Your message of Wed, 20 Feb 91 12:05:19 MST To: "Nelson H.F. Beebe" Message-Id: X-Envelope-To: beebe@math.utah.EDU Dear Nelson, I think that Yannis Haralambous would be a better Metafontist than me to discuss on the tex-fonts list and to represent GUTenberg if needed. Yannis is OK and his email address is : On another side, I'd be pleased if it would be possible that you send "any support" to those (like me) that will attend the Boston meeting. Times are too difficult, and it's difficult to believe that the president is against... all ideas, all of us... please tell few words now| Bonne continuation et... travaille encore un peu ton francais pour Septembre a Paris| Bernard GAULLE 27-Feb-1991 7:12:57-GMT,13069;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02595; Wed, 27 Feb 91 07:12:49 MST Date: Wed 27 Feb 91 09:16:48-EST From: bbeeton Subject: [Rainer Schoepf : use of PK founts under MS-DOS] To: tex-fonts@math.utah.edu Message-Id: <667664208.0.BNB@MATH.AMS.COM> Mail-System-Version: the following exchange, begun on uktex, has continued on tex-euro. although the motivation for the original question seemed to be access to fonts by multiple device drivers, the question of naming is also raised. although the fonts discussed here are mf fonts, there is a parallel to the problem of like names for the same magnifications for different devices in the case of non-mf fonts >From different foundries with similar "given" names. redundant parts of these messages are edited for brevity. -- bb --------------- 1) 25-Feb Rainer Schoepf use of PK founts under MS-DOS 2) 25-Feb CHAA006%VAX.RHB RE: use of PK founts under MS-DOS 3) 25-Feb Rainer Schoepf Forward from Eberhard Mattes: [us 4) 26-Feb Rainer Schoepf RE: use of PK founts under MS-DOS 5) 27-Feb "Konrad Bernloe Font file conventions / Re: use o Message 1 -- ************************ Date: Mon, 25 Feb 91 14:38:40 CET Reply-To: TeX-Euro Distribution List for European TeX Users From: Rainer Schoepf X-To: UKTeX@tex.AC.UK X-cc: CUDAT@CU.WARWICK.AC.UK, texhax@cs.washington.EDU, tex-euro@dhdurz1 Subject: use of PK founts under MS-DOS From: CUDAT@CU.WARWICK.AC.UK I have recently been setting up LaTeX for someone on an IBM PC compatible. I have been using DVISCRS (version 1.3i) from the emTeX collection as a previewer, and DVITOPS (by James Clark) to convert DVI files to PostScript. Both DVISCRS and DVITOPS use the fount name, printer resolution and fount magnification to find the required PK file for a fount. To do this, DVITOPS can substitute (resolution x magnification) in the name of a file it is looking for (the resolution is in dots per inch). DVISCRS does something similar, but it uses (resolution x magnification x 5). This makes it awkward to have the previewer and the printer driver use the same set of founts. (DVISCRS gives pretty good results with 300 d.p.i. founts and it seems silly to have two sets of PK files when one will do.) Fortunately DVITOPS is persistent enough to look in all the MS-DOS directories it is given until it finds exactly the right fount file, so I name the directories according to emTeX's convention and tell DVITOPS about each directory individually. This is a nuisance as the directory names then need to be kept short so that they can all fit into an MS-DOS environment variable. Is there any chance that developers might be encouraged to agree on the general principles of how to locate a required fount file? This is yet another chapter of a very sad story... The (resolution x magnification x 5) convention is an old one, and I don't see any reason why it should still be used. Actually, I don't see a reason why the directory names should contain the resolution. There should be one directory for every output device (thus implicitly or even explicitly containing the resolution of that particular device), with subdirectories for different magnifications, each one containing the appropriate .PK files. The names of these subdirectories should not contain the resolution, but the magnification, for a very simple reason: I find it very awkward to remember that cmr10 for \magstephalf is contained in, say, pk329 for a HP Laserjet, and in 1395pk for a 1270dpi Linotype. Instead, both directories should be named something like "mag1095". Driver programs should (1) be able to read a font substitution definition file, (2) have settable paths for the pk directories, preferably with variable parts to conform to different conventions, (3) no longer use .PXL files instead of .PK files. I think we should finally put away those old conventions that have ceased to be useful. Rainer Sch\"opf Dr. Rainer Schoepf Konrad-Zuse-Zentrum fuer Informationstechnik Berlin Heilbronner Strasse 10 D-1000 Berlin 31 Federal Republic of Germany or Message 2 -- ************************ Date: Mon, 25 Feb 91 15:55:21 BST Reply-To: RHBNC Philip Taylor Sender: TeX-Euro Distribution List for European TeX Users From: CHAA006%VAX.RHBNC.AC.UK@uga.cc.uga.edu Subject: RE: use of PK founts under MS-DOS Rainer Sch\"opf wrote: >>> There should be one directory for every output device [...] >>> Instead, both >>> directories should be named something like "mag1095". It is with extraordinary trepidation that I dare to cross swords with Rainer in public, but I feel justified on this occasion. His proposed scheme, which has considerable merit, overlooks, I believe, one very important aspect of TeX: one can load fonts at {\stress absolutely} any size (within the limits of integer arithmetic on scaled points/RSUs), and it is therefore possible to load a large but finite number of sizes, all of which can only be approximated by `mag1095'. Users should be able to load fonts at any desired size, expressed in points or whatever units they feel most comfortable with, and indeed users {\stress are} able so to do within TeX proper. But a scheme which seeks to restrict users to only those sizes which can be expressed in integer values of \mag, rather than recognising that a system is needed which allows for arbitrary real font sizes, continues to impose arbitrary restrictions on font size selection. I therefore believe that Rainer's second suggestion: >>> (2) have settable paths for the pk directories, preferably with >>> variable parts to conform to different conventions, has within it the necessary flexibility to allow a totally general solution to the problem. One needs to be able to specify an extensible set of directory hierarchies, with a common theme but varying detail. For example, Rainer's proposal could be expressed as [I am assuming the existence of a hierarchical directory structure, which is essential to the proposed scheme] as ..mag. while a user more comfortable with font sizes expressed in points could use ..pt.. and a poster designer could use ..cm.. or ..in.. In a system which supports file aliases, all of these could be a pointer to files contained in a canonical hierarchy ..sp. I would welcome Rainer's and other's comments on this proposal. Philip Taylor Royal Holloway and Bedford New College, ``The University of London at Windsor'' Message 3 -- ************************ Date: Mon, 25 Feb 91 18:50:12 CET Sender: TeX-Euro Distribution List for European TeX Users From: Rainer Schoepf X-To: texhax@cs.washington.EDU, uktex@tex.AC.UK, tex-euro@dhdurz1 X-cc: mattes@azu.informatik.UNI-STUTTGART.DE Subject: Forward from Eberhard Mattes: [use of PK founts under MS-DOS] > dots per inch). DVISCRS does something similar, but it > uses (resolution x magnification x 5). Use (for instance) /pf\texfonts\canon\$rpk with dviscrs to use resolution x magnification. $r will be replaced with the font size (resolution x magnification). The 1.4d release of dvidrv ceased to use resolution x magnification x 5, but still supports $s for the old (pxl) convention. > Driver programs should > (1) be able to read a font substitution definition file, > (2) have settable paths for the pk directories, preferably with > variable parts to conform to different conventions, > (3) no longer use .PXL files instead of .PK files. All this can be done with the emTeX drivers. The /texfonts/canon/cmr10.300pk font naming scheme will be supported by the next release. You may want to use dvips 5.47, it can read the emTeX font libraries. Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de) Message 4 -- ************************ Date: Tue, 26 Feb 91 16:18:12 CET Reply-To: TeX-Euro Distribution List for European TeX Users From: Rainer Schoepf X-To: P.Taylor@Vax.Rhbnc.AC.UK, TEX-EURO@DHDURZ1 Subject: RE: use of PK founts under MS-DOS From: CHAA006@VAX.RHBNC.ac.uk Reply-To: "RHBNC Philip Taylor" Rainer Sch\"opf wrote: >>> There should be one directory for every output device [...] >>> Instead, both >>> directories should be named something like "mag1095". It is with extraordinary trepidation that I dare to cross swords with Rainer [...] system is needed which allows for arbitrary real font sizes, continues to impose arbitrary restrictions on font size selection. I see your point. My main point is to separate the device-dependent information (resolution) from the device independent information (magnification). Whether these directories are called mag1095 or mag1.095 or mag1095.000 or whatever, I don't care, as long as the names are the same for all output devices. There's another problem: what about machines with a flat file system? Rainer Sch\"opf Message 5 -- ************************ Date: Wed, 27 Feb 91 14:15:00 N Reply-To: TeX-Euro Distribution List for European TeX Users From: "Konrad Bernloehr (BERN@DHDMPI50)" Subject: Font file conventions / Re: use of PK fonts under MS-DOS I agree with Rainer Sch\"opf that there is no reason why the old (resolution * magnification * 5) convention should still be used. In fact that convention (which originated from 200 dpi printers in the early days of TeX) has been used for PXL files only. The convention for PK files is to include the resolution (in dots per inch) at which the characters are at their design size in the directory name. This convention makes sense. Although for 'single-resolution' output devices like most printers a naming convention like the one suggested by Rainer ('mag1095' etc.) may be reasonable as well, only the first one is reasonable for 'multi-resolution' output 'devices' like most (good) previewers. A good previewer should be able to zoom in and out, usually in magsteps but better in any arbitrary steps. While simulating a 300 dpi resolution a font file for 300 dpi might be used at its design size but when a 121 dpi resolution is simulated the same 300 dpi font file would be used at \magstep5. Or is there anybody out there who wants to suggest an independent series of font files for any possible simulated resolution of a previewer? The reason for the numeric part is simply that the device driver can locate the files much easier. An alternative would be to define each directory (or even each font file) and its corresponding \magnification or resolution in a font definition file (and that separately for each device or even each possible resolution of each 'device'). Sounds like a lot of work for setting things up. An alternative (for PK files only) would be to open all files and read the resolutions from the files. But you would probably start such a device driver only before going out for lunch. In addition to Rainer's suggestion that >>> >>> Driver programs should >>> >>> (1) be able to read a font substitution definition file, >>> (2) have settable paths for the pk directories, preferably with >>> variable parts to conform to different conventions, >>> (3) no longer use .PXL files instead of .PK files. >>> I would also like driver programs (4) to use the available nearest neighbours if a font isn't available at the requested size, and ultimately (5) to enlarge or shrink the characters of such fonts to the requested size if requested and available size are too far from each other. (I know that this causes some loss of details but my own experience with that kind of character 'zooming' is very good). Finally a few words to the scheme proposed by Philip Taylor (i.e. >>> ..mag. >>> ..pt.. plus several others of that kind, where file aliases should allow users to use the naming scheme they prefer. Apart from the work to set all those aliases up that sounds nice. The problem is that I know only one group of operating systems (*IX) that could do this job but the subject line of Philip's email is 'RE: use of PK fonts under MS-DOS'. Konrad Bernl\"ohr ------- 28-Feb-1991 15:56:31-GMT,776;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10002; Thu, 28 Feb 91 08:56:21 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA06009; Thu, 28 Feb 91 10:56:05 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA05308; Thu, 28 Feb 91 10:54:53 EST Date: Thu, 28 Feb 91 10:54:53 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9102281554.AA05308@ra.cs.umb.edu> To: tex-fonts@math.utah.edu Subject: font naming proposal Reply-To: karl@cs.umb.edu I have put a revision of my font naming proposal that was printed in the last TUGboat on ftp.cs.umb.edu [192.12.26.23], in pub/tex/fontname. Both the article and several examples are there, including all of the Adobe fonts as of 2/18/91. karl@cs.umb.edu 28-Feb-1991 17:19:46-GMT,817;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10333; Thu, 28 Feb 91 10:19:39 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA07857; Thu, 28 Feb 91 12:19:24 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA07295; Thu, 28 Feb 91 12:18:11 EST Date: Thu, 28 Feb 91 12:18:11 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9102281718.AA07295@ra.cs.umb.edu> To: tex-fonts@math.utah.edu Subject: Metafont modes Reply-To: karl@cs.umb.edu I have collected all the Metafont modes I could find, with Doug Henderson's help, and also auxiliary definitions for write-write printers, GF specials, etc., etc. I hope people will start using this as their ``local'' file. It's on ftp.cs.umb.edu [192.12.26.23] in pub/tex/modes.mf. karl@cs.umb.edu 28-Feb-1991 17:39:52-GMT,1853;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10413; Thu, 28 Feb 91 10:39:32 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA08143; Thu, 28 Feb 91 12:34:00 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA07611; Thu, 28 Feb 91 12:32:25 EST Date: Thu, 28 Feb 91 12:32:25 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9102281732.AA07611@ra.cs.umb.edu> To: tex-fonts@math.utah.edu Cc: bern@dhdmpi50.BITNET, Schoepf@sc.zib-berlin.dbp.de, CHAA006@vax.rhbnc.ac.uk, mattes@azu.informatik.uni-stuttgart.de In-Reply-To: bbeeton's message of Wed 27 Feb 91 09:16:48-EST <667664208.0.BNB@MATH.AMS.COM> Subject: TeX font hierarchies. Reply-To: karl@cs.umb.edu [Barbara forwards messages giving umpteen different schemes to arrange font directories.] I don't think any one scheme will suffice at all sites. (Clearly some schemes are worse than others, on the other hand.) Personally, I have top-level directories named for the typeface family, e.g., `cm' and `euler' or sometimes foundry (`adobe'). Then I put the font files under there, since I don't have to support very many devices. This makes maintenance very easy (according to my way of thinking, I realize other people think differently). No one mentioned that alternative at all (unless I missed it). Instead, I believe drivers should not care what the names of the directories are; instead, they should search subdirectories automatically, to (perhaps) N specified levels. (You definitely don't want to do it fully recursively, because the bottom level always has a zillion files, which you don't want to look at to discover they're not directories.) One of the Unix ports of TeX, web2c, does this for one level now. Then the installer can set up the directories however s/he wants. karl@cs.umb.edu 28-Feb-1991 17:45:35-GMT,1953;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10464; Thu, 28 Feb 91 10:45:31 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA08344; Thu, 28 Feb 91 12:45:17 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA07850; Thu, 28 Feb 91 12:44:05 EST Date: Thu, 28 Feb 91 12:44:05 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9102281744.AA07850@ra.cs.umb.edu> To: tex-archive-request@math.utah.edu Subject: [postmaster@gemini.arc.nasa.gov: Returned mail: User unknown] Reply-To: karl@cs.umb.edu Perhaps this person doesn't exist any more? Date: Thu, 28 Feb 91 09:33:01 PST From: Mail Delivery Subsystem Subject: Returned mail: User unknown To: ----- Transcript of session follows ----- mail11: Error from DECnet MAIL object on node "sat", during mail delivery to . Remote error code is 0x7e8112, message is: %MAIL-E-NOSUCHUSR, no such user OGAWA at node SAT 550 ... User unknown ----- Unsent message follows ----- Received: Thu, 28 Feb 91 09:33:01 PST by gemini.arc.nasa.gov (5.57/1.2) Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA10338; Thu, 28 Feb 91 10:19:50 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA07874; Thu, 28 Feb 91 12:19:36 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA07298; Thu, 28 Feb 91 12:18:24 EST Date: Thu, 28 Feb 91 12:18:24 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9102281718.AA07298@ra.cs.umb.edu> To: tex-archive@math.utah.edu Subject: Metafont modes Reply-To: karl@cs.umb.edu I have collected all the Metafont modes I could find, with Doug Henderson's help, and also auxiliary definitions for write-write printers, GF specials, etc., etc. I hope people will start using this as their ``local'' file. It's on ftp.cs.umb.edu [192.12.26.23] in pub/tex/modes.mf. karl@cs.umb.edu 1-Mar-1991 8:41:47-GMT,3713;000000000001 Return-Path: Received: from serv02.ZIB-Berlin.DE by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA14974; Fri, 1 Mar 91 01:41:13 MST Received: from quattro.ZIB-Berlin.DE by serv02.ZIB-Berlin.DE (4.0/SMI-4.0-serv02/13.11.90) id AA13195; Fri, 1 Mar 91 09:43:28 +0100 Received: by quattro.ZIB-Berlin.DE (4.0/SMI-4.0/4.9.90) id AA20162; Fri, 1 Mar 91 09:43:25 +0100 Date: Fri, 1 Mar 91 09:43:25 +0100 From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) Message-Id: <9103010843.AA20162@sc.zib-berlin.dbp.de> Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin To: karl@cs.umb.edu Cc: tex-fonts@math.utah.edu, bern@dhdmpi50.BITNET, Schoepf@sc.ZIB-Berlin.DE, CHAA006@vax.rhbnc.ac.uk, mattes@azu.informatik.uni-stuttgart.de In-Reply-To: Karl Berry's message of Thu, 28 Feb 91 12:32:25 EST <9102281732.AA07611@ra.cs.umb.edu> Subject: TeX font hierarchies. From: karl@cs.umb.edu (Karl Berry) I don't think any one scheme will suffice at all sites. (Clearly some schemes are worse than others, on the other hand.) Personally, I have top-level directories named for the typeface family, e.g., `cm' and `euler' or sometimes foundry (`adobe'). Then I put the font files under there, since I don't have to support very many devices. This makes maintenance very easy (according to my way of thinking, I realize other people think differently). No one mentioned that alternative at all (unless I missed it). Instead, I believe drivers should not care what the names of the directories are; instead, they should search subdirectories automatically, to (perhaps) N specified levels. (You definitely don't want to do it fully recursively, because the bottom level always has a zillion files, which you don't want to look at to discover they're not directories.) One of the Unix ports of TeX, web2c, does this for one level now. Then the installer can set up the directories however s/he wants. But this does not work if you have different devices, with different mode_def parameters, but the same resolution, unless you have the name of the device in your font file name. Let me state the three guiding principles that led to my proposal: 1. In a Metafont run, I specify three fundamentally different parameters: - the font - the output device - the magnification factor Therefore I propose that the structure of the .pk directories reflect this. Don't forget that the majority of all users are not experts, and having the same structure on all levels is easier to understand. Since it is not possible to mix .pk files for different output devices, it seems the easiest way to have different directories for them. 2. I think that the prevailing convention of using . as a .pk file name is inferior to using . on the simple grounds that a given font specification in a TeX run always maps to the same font file name in the latter convention, irregardless of the output device. Again, I think it is easier to understand for a non-expert. 3. Since we have only 8+3 characters in an MS-DOS file name one has to put part of information into the directory names. Now, I hadn't thought before of putting different foundries into different directories, but I find it very reasonable. Finally, I think we should try to get rid of those drivers that assume fixed directory structures or file names, and that do not support font substitution. (And, of course, we need them to conform to one standard for \special commands very soon, otherwise you can forget about this). Rainer 1-Mar-1991 18:17:29-GMT,1162;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA18502; Fri, 1 Mar 91 11:17:26 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA20822; Fri, 1 Mar 91 10:17:12 -0800 Date: Fri, 1 Mar 91 10:17:12 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9103011817.AA20822@june.cs.washington.edu> To: karl@cs.umb.edu Cc: tex-fonts@math.utah.edu In-Reply-To: Karl Berry's message of Thu, 28 Feb 91 12:18:11 EST <9102281718.AA07295@ra.cs.umb.edu> Subject: Metafont modes The file looks great, and the information at the beginning will be much appreciated. We will replace U_Wash.mf with this and refer to it in the man-page. As soon as I have redone the man page I will send it on. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 2-Mar-1991 13:21:55-GMT,27977;000000000001 Return-Path: Received: from life.ai.mit.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA25430; Sat, 2 Mar 91 06:21:24 MST Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA09298; Sat, 2 Mar 91 08:20:19 EST From: bkph@ai.mit.edu (Berthold K.P. Horn) Received: by rice-chex (4.1/AI-4.10) id AA04335; Sat, 2 Mar 91 08:20:14 EST Date: Sat, 2 Mar 91 08:20:14 EST Message-Id: <9103021320.AA04335@rice-chex> To: TeXhax@cs.washington.edu Cc: dhosek@ymir.claremont.edu, beebe@csc-sun.math.utah.edu, berry@ai.mit.edu Subject: Standardization of TeX names for Adobe PostScript fonts. re: Proposal for standardization of TeX names for Adobe PostScript fonts. Given below are the six character abbreviated file names used by Adobe for their outline fonts. It seems reasonable to simply adopt these short names when refering to Adobe PostScript fonts in TeX (which happens to be limited to six character font names). Need for standardization of names for Adobe fonts used in TeX seems to be the most urgent, since these are the fonts most frequently used (in fact, I have yet to see an author call for a font other than CM, LaTeX, AMS or Adobe). Using the vendor supplied abbreviation has clear advantages: (*) There is no need for a committee to dream up abbreviations for new fonts. (*) There is no need for a clearing house to approve proposed abbreviations. (*) There is no delay between publication of an outline font and availability of a standard abbreviated name for it. (*) The probability of confusion is reduced when only one short name needs to be remembered for a font (instead of the one used by the vendor AND one approved for use in TeX). There are two possible problems with my proposal: (.) Other vendors may use a particular abbreviation for different font. (.) The present scheme allows for only (26 + 10) * (26 * 10) = 1296 font families. Adobe already has about 770 / 4 = 193 font families. So in the distant future they are going to run out of two letter combinations. (.) In TeX there is sometimes a need to remap the encoding of the font. TFM files for the remapped versions must be distinguishable from the `raw' versions. The first problem can be fixed by prefixing these names with a code for the vendor - as suggested by Karl Berry - perhaps `p' for Adobe. The solution of the second problem is to simply adopt whatever scheme the vendor comes up with when that happens (and this won't happen for quite a few years anyway...). The third problem is less of an issue now that TeX can handle character sets with 256 characters. But in any case, a suffix can be added to the name (perhaps `x') to indicate remapping (although this does not tell one HOW the font has been remapped). This, along with the vendor prefix, brings the maximum length of a name to 8 characters, which almost all file systems now are able to deal with. Berthold K.P. Horn P.S. Thanks to Terry O'Donnell for help with generating this list. ========================= acb Aachen-Bold awab ACaslon-AltBold awabi ACaslon-AltBoldItalic awai ACaslon-AltItalic awarg ACaslon-AltRegular awasb ACaslon-AltSemibold awasi ACaslon-AltSemiboldItalic awb ACaslon-Bold awbi ACaslon-BoldItalic axb ACaslonExp-Bold axbi ACaslonExp-BoldItalic axi ACaslonExp-Italic axrg ACaslonExp-Regular axsb ACaslonExp-Semibold axsbi ACaslonExp-SemiboldItalic awi ACaslon-Italic awor ACaslon-Ornaments awrg ACaslon-Regular awsb ACaslon-Semibold awsbi ACaslon-SemiboldItalic awswb ACaslon-SwashBoldItalic awswi ACaslon-SwashItalic awssb ACaslon-SwashSemiboldItalic ggi AGaramondAlt-Italic ggrg AGaramondAlt-Regular gdb AGaramond-Bold gdbi AGaramond-BoldItalic geb AGaramondExp-Bold gebi AGaramondExp-BoldItalic gei AGaramondExp-Italic gerg AGaramondExp-Regular gesb AGaramondExp-Semibold gesbi AGaramondExp-SemiboldItalic gdi AGaramond-Italic gdrg AGaramond-Regular gdsb AGaramond-Semibold gdsbi AGaramond-SemiboldItalic gdttl AGaramond-Titling akbl AkzidenzGrotesk-Black akb AkzidenzGrotesk-Bold akl AkzidenzGrotesk-Light akr AkzidenzGrotesk-Roman amb Americana-Bold ameb Americana-ExtraBold ami Americana-Italic am Americana aqbl AntiqueOlive-Black aqb AntiqueOlive-Bold aqi AntiqueOlive-Italic aql AntiqueOlive-Light aqr AntiqueOlive-Roman aqbc AntiqueOlive-BoldCond aqct AntiqueOlive-Compact aqnr AntiqueOlive-Nord aqnri AntiqueOlive-NordItalic a Arcadia a AAA Arcadia-A ab ArnoldBoecklin ael Avenir-Light aelo Avenir-LightOblique aew Avenir-Book aewo Avenir-BookOblique aer Avenir-Roman aero Avenir-Oblique aem Avenir-Medium aemo Avenir-MediumOblique aeh Avenir-Heavy aeho Avenir-HeavyOblique aebl Avenir-Black aeblo Avenir-BlackOblique bc Banco bbb BauerBodoni-Bold bbbi BauerBodoni-BoldItalic bbbio BauerBodoni-BoldItalicOsF bbbof BauerBodoni-BoldOsF bbi BauerBodoni-Italic bbiof BauerBodoni-ItalicOsF bbr BauerBodoni-Roman bbrsc BauerBodoni-RomanSC bbbl BauerBodoni-Black bbblc BauerBodoni-BlackCond bbbli BauerBodoni-BlackItalic bbbc BauerBodoni-BoldCond bhb Bauhaus-Bold bhd Bauhaus-Demi bhh Bauhaus-Heavy bhl Bauhaus-Light bhm Bauhaus-Medium bwb Belwe-Bold bwc Belwe-Condensed bwl Belwe-Light bwm Belwe-Medium bmb Bembo-Bold bmbi Bembo-BoldItalic bmeb Bembo-ExtraBold bmebi Bembo-ExtraBoldItalic bmi Bembo-Italic bm Bembo bmsb Bembo-Semibold bmsbi Bembo-SemiboldItalic bgb Benguiat-Bold bgw Benguiat-Book bybl Berkeley-Black bybli Berkeley-BlackItalic byb Berkeley-Bold bybi Berkeley-BoldItalic byw Berkeley-Book bywi Berkeley-BookItalic byi Berkeley-Italic bym Berkeley-Medium bdb Bodoni-Bold bdbi Bodoni-BoldItalic bdi Bodoni-Italic bdps Bodoni-Poster bd Bodoni bdbc Bodoni-BoldCondensed bdw Bodoni-Book bdwi Bodoni-BookItalic bdpsc Bodoni-PosterCompressed bdpsi Bodoni-PosterItalic bkb Bookman-Bold bkbi Bookman-BoldItalic bkd Bookman-Demi bkdi Bookman-DemiItalic bkl Bookman-Light bkli Bookman-LightItalic bkm Bookman-Medium bkmi Bookman-MediumItalic j1515 BorderPi-OneFiveOneFiveNine bs BrushScript db1 BundesbahnPi-One db2 BundesbahnPi-Two db3 BundesbahnPi-Three cgb Candida-Bold cgi Candida-Italic cgr Candida-Roman cr Carta ck CascadeScript c2bl CaslonTwoTwentyFour-Black c2bli CaslonTwoTwentyFour-BlackIt c2b CaslonTwoTwentyFour-Bold c2bi CaslonTwoTwentyFour-BoldIt c2w CaslonTwoTwentyFour-Book c2wi CaslonTwoTwentyFour-BookIt c2m CaslonTwoTwentyFour-Medium c2mi CaslonTwoTwentyFour-MediumIt cti CaslonThree-Italic ctr CaslonThree-Roman cfi CaslonFiveForty-Italic cfr CaslonFiveForty-Roman ca CaslonOpenFace cxb Caxton-Bold cxbi Caxton-BoldItalic cxw Caxton-Book cxwi Caxton-BookItalic cxl Caxton-Light cxli Caxton-LightItalic cil Centennial-Light cili Centennial-LightItalic cir Centennial-Roman cii Centennial-Italic cib Centennial-Bold cibi Centennial-BoldItalic cibl Centennial-Black cibli Centennial-BlackItalic cyi CenturyExpanded-Italic cy CenturyExpanded csb CenturyOldStyle-Bold csi CenturyOldStyle-Italic csrg CenturyOldStyle-Regular czb Charlemagne-Bold czrg Charlemagne-Regular cu Charme cq Cheq clb Clarendon-Bold cll Clarendon-Light cl Clarendon cebl Clearface-Black cebli Clearface-BlackItalic ceb Clearface-Bold cebi Clearface-BoldItalic ceh Clearface-Heavy cehi Clearface-HeavyItalic cerg Clearface-Regular cergi Clearface-RegularItalic ccb Cochin-Bold ccbi Cochin-BoldItalic cci Cochin-Italic cc Cochin cjb Concorde-Bold cjbi Concorde-BoldItalic cji Concorde-Italic cjr Concorde-Roman cbi CooperBlack-Italic cb CooperBlack cp29a Copperplate-TwentyNineAB cp29c Copperplate-TwentyNineBC cp30a Copperplate-ThirtyAB cp30c Copperplate-ThirtyBC cp31a Copperplate-ThirtyOneAB cp31c Copperplate-ThirtyOneBC cp32a Copperplate-ThirtyTwoAB cp32c Copperplate-ThirtyTwoBC cp33c Copperplate-ThirtyThreeBC cnb Corona-Bold cni Corona-Italic cn Corona cob Courier-Bold cobo Courier-BoldOblique com Courier coo Courier-Oblique cob Courier-Bold cobo Courier-BoldOblique com Courier coo Courier-Oblique dinen DINEngschrift dinmi DINMittelschrift dngbc DINNeuzeitGrotesk-BoldCond dngl DINNeuzeitGrotesk-Light dcb DomCasual-Bold dc DomCasual drb Doric-Bold du DucDeBerry dudfr DucDeBerry-Dfr erb ItcEras-Bold erbk ItcEras-Book erd ItcEras-Demi erl ItcEras-Light erm ItcEras-Medium eru ItcEras-Ultra euro1 EuropeanPi-One euro2 EuropeanPi-Two euro3 EuropeanPi-Three euro4 EuropeanPi-Four eub Eurostile-Bold eubo Eurostile-BoldOblique eud Eurostile-Demi eudo Eurostile-DemiOblique eu Eurostile euo Eurostile-Oblique eubc Eurostile-BoldCondensed eubex Eurostile-BoldExtendedTwo euc Eurostile-Condensed euex Eurostile-ExtendedTwo exb Excelsior-Bold exi Excelsior-Italic ex Excelsior ff FetteFraktur flblc Flyer-BlackCondensed flebc Flyer-ExtraBlackCondensed fob Folio-Bold fobc Folio-BoldCondensed foeb Folio-ExtraBold fol Folio-Light fom Folio-Medium frw FranklinGothic-Book frwo FranklinGothic-BookOblique frd FranklinGothic-Demi frdo FranklinGothic-DemiOblique frh FranklinGothic-Heavy frho FranklinGothic-HeavyOblique fgc FranklinGothic-Condensed fgec FranklinGothic-ExtraCond fgr FranklinGothic-Roman fs FreestyleScript fqb FrizQuadrata-Bold fq FrizQuadrata ftl Frutiger-Light ftli Frutiger-LightItalic ftr Frutiger-Roman fti Frutiger-Italic ftb Frutiger-Bold ftbi Frutiger-BoldItalic ftbl Frutiger-Black ftbli Frutiger-BlackItalic ftubl Frutiger-UltraBlack fub Futura-Bold fubo Futura-BoldOblique fuw Futura-Book fuwo Futura-BookOblique fuc Futura-Condensed fucb Futura-CondensedBold fucbo Futura-CondensedBoldOblique fuceb Futura-CondensedExtraBold fcebo Futura-CondExtraBoldObl fucl Futura-CondensedLight fuclo Futura-CondensedLightOblique fuco Futura-CondensedOblique fueb Futura-ExtraBold fuebo Futura-ExtraBoldOblique fuh Futura-Heavy fuho Futura-HeavyOblique ful Futura-Light fulo Futura-LightOblique fu Futura fuo Futura-Oblique gmb GaramondThree-Bold gmbi GaramondThree-BoldItalic gmbio GaramondThree-BoldItalicOsF gmbsc GaramondThree-BoldSC gmi GaramondThree-Italic gmio GaramondThree-ItalicOsF gm GaramondThree gmsc GaramondThree-SC ghz GarthGraphic-Black ghb GarthGraphic-Bold ghbc GarthGraphic-BoldCondensed ghbi GarthGraphic-BoldItalic ghc GarthGraphic-Condensed gheb GarthGraphic-ExtraBold ghi GarthGraphic-Italic gh GarthGraphic gnb GillSans-Bold gnbc GillSans-BoldCondensed gnbi GillSans-BoldItalic gnc GillSans-Condensed gneb GillSans-ExtraBold gni GillSans-Italic gnl GillSans-Light gnli GillSans-LightItalic gn GillSans gnub GillSans-UltraBold gnubc GillSans-UltraBoldCondensed gyb Glypha-Bold gybo Glypha-BoldOblique gyo Glypha-Oblique gy Glypha gyt Glypha-Thin gyto Glypha-ThinOblique gyl Glypha-Light gylo Glypha-LightOblique gybl Glypha-Black gyblo Glypha-BlackOblique gtt Gothic-Thirteen gob Goudy-Bold gobi Goudy-BoldItalic goi Goudy-Italic go Goudy goeb Goudy-ExtraBold goh Goudy-Heavyface gohi Goudy-HeavyfaceItalic grb Granjon-Bold gri Granjon-Italic gr Granjon hvbl Helvetica-Black hvblo Helvetica-BlackOblique hvb Helvetica-Bold hvbo Helvetica-BoldOblique hvk Helvetica-Compressed hvc Helvetica-Condensed hvcbl Helvetica-Condensed-Black hvco Helvetica-Condensed-BlackObl hvcb Helvetica-Condensed-Bold hvcbo Helvetica-Condensed-BoldObl hvcl Helvetica-Condensed-Light hvclo Helvetica-Condensed-LightObl hvcdo Helvetica-Condensed-Oblique hvek Helvetica-ExtraCompressed hvl Helvetica-Light hvlo Helvetica-LightOblique hv Helvetica hvn Helvetica-Narrow hvnb Helvetica-Narrow-Bold hvnbo Helvetica-Narrow-BoldOblique hvno Helvetica-Narrow-Oblique hvo Helvetica-Oblique hvuk Helvetica-UltraCompressed hir HelveticaInserat-Roman hlj HelveticaNeue-ExtBlackCond hljo HelveticaNeue-ExtBlackCondObl hlav HelveticaNeue-UltraLigExt hlavo HelveticaNeue-UltraLigExtObl hlul HelveticaNeue-UltraLight hluli HelveticaNeue-UltraLightItal hla HelveticaNeue-UltraLigCond hlao HelveticaNeue-UltraLigCondObl hltv HelveticaNeue-ThinExt hltvo HelveticaNeue-ThinExtObl hlt HelveticaNeue-Thin hlti HelveticaNeue-ThinItalic hltc HelveticaNeue-ThinCond hltco HelveticaNeue-ThinCondObl hllv HelveticaNeue-LightExt hllvo HelveticaNeue-LightExtObl hll HelveticaNeue-Light hlli HelveticaNeue-LightItalic hllc HelveticaNeue-LightCond hllco HelveticaNeue-LightCondObl hlv HelveticaNeue-Extended hlvo HelveticaNeue-ExtendedObl hlr HelveticaNeue-Roman hli HelveticaNeue-Italic hlc HelveticaNeue-Condensed hlco HelveticaNeue-CondensedObl hlmv HelveticaNeue-MediumExt hlmvo HelveticaNeue-MediumExtObl hlm HelveticaNeue-Medium hlmi HelveticaNeue-MediumItalic hlmc HelveticaNeue-MediumCond hlmco HelveticaNeue-MediumCondObl hlbv HelveticaNeue-BoldExt hlbvo HelveticaNeue-BoldExtObl hlb HelveticaNeue-Bold hlbi HelveticaNeue-BoldItalic hlbc HelveticaNeue-BoldCond hlbco HelveticaNeue-BoldCondObl hlhv HelveticaNeue-HeavyExt hlhvo HelveticaNeue-HeavyExtObl hlh HelveticaNeue-Heavy hlhi HelveticaNeue-HeavyItalic hlhc HelveticaNeue-HeavyCond hlhco HelveticaNeue-HeavyCondObl hlzv HelveticaNeue-BlackExt hlzvo HelveticaNeue-BlackExtObl hlbl HelveticaNeue-Black hlbli HelveticaNeue-BlackItalic hlzc HelveticaNeue-BlackCond hlzco HelveticaNeue-BlackCondObl hebl HelveticaRounded-Black heblo HelveticaRounded-BlackObl heb HelveticaRounded-Bold hebc HelveticaRounded-BoldCond hebco HelveticaRounded-BoldCondObl hebo HelveticaRounded-BoldObl herc Herculanum hrbl Hiroshige-Black hrbli Hiroshige-BlackItalic hrb Hiroshige-Bold hrbi Hiroshige-BoldItalic hrw Hiroshige-Book hrwi Hiroshige-BookItalic hrm Hiroshige-Medium hrmi Hiroshige-MediumItalic ho Hobo atb AmericanTypewriter-Bold atm AmericanTypewriter-Medium agw AvantGarde-Book agwo AvantGarde-BookOblique agcb AvantGarde-CondBold agcw AvantGarde-CondBook agcd AvantGarde-CondDemi agcm AvantGarde-CondMedium agd AvantGarde-Demi agdo AvantGarde-DemiOblique beb BenguiatGothic-Bold bebo BenguiatGothic-BoldOblique bew BenguiatGothic-Book bewo BenguiatGothic-BookOblique beh BenguiatGothic-Heavy beho BenguiatGothic-HeavyOblique bem BenguiatGothic-Medium bemo BenguiatGothic-MediumOblique icb Century-Bold icbci Century-BoldCondensedItalic icbc Century-BoldCondensed icbi Century-BoldItalic icw Century-Book icwci Century-BookCondensedItalic icwc Century-BookCondensed icwi Century-BookItalic icl Century-Light iclci Century-LightCondensedItalic iclc Century-LightCondensed icli Century-LightItalic icu Century-Ultra icuci Century-UltraCondensedItalic icuc Century-UltraCondensed icui Century-UltraItalic chb Cheltenham-Bold chbc Cheltenham-BoldCond chbci Cheltenham-BoldCondItalic chbi Cheltenham-BoldItalic chw Cheltenham-Book chwc Cheltenham-BookCond chwci Cheltenham-BookCondItalic chwi Cheltenham-BookItalic chl Cheltenham-Light chlc Cheltenham-LightCond chlci Cheltenham-LightCondItalic chli Cheltenham-LightItalic chu Cheltenham-Ultra chuc Cheltenham-UltraCond chuci Cheltenham-UltraCondItalic chui Cheltenham-UltraItalic iub Cushing-Bold iubi Cushing-BoldItalic iuw Cushing-Book iuwi Cushing-BookItalic iuh Cushing-Heavy iuhi Cushing-HeavyItalic ium Cushing-Medium iumi Cushing-MediumItalic feb Fenice-Bold febo Fenice-BoldOblique fel Fenice-Light felo Fenice-LightOblique ferg Fenice-Regular fergo Fenice-RegularOblique feu Fenice-Ultra feuo Fenice-UltraOblique glbl Galliard-Black glbli Galliard-BlackItalic glb Galliard-Bold glbi Galliard-BoldItalic gli Galliard-Italic glr Galliard-Roman glu Galliard-Ultra glui Galliard-UltraItalic gab Garamond-Bold gabc Garamond-BoldCondensed gabci Garamond-BoldCondensedItalic gabi Garamond-BoldItalic gaw Garamond-Book gawc Garamond-BookCondensed gawci Garamond-BookCondensedItalic gawi Garamond-BookItalic gal Garamond-Light galc Garamond-LightCondensed galci Garamond-LightCondensedItalic gali Garamond-LightItalic gau Garamond-Ultra gauc Garamond-UltraCondensed gauci Garamond-UltraCondensedItalic gaui Garamond-UltraItalic mab Machine-Bold ma Machine nbb NewBaskerville-Bold nbbi NewBaskerville-BoldItalic nbi NewBaskerville-Italic nbr NewBaskerville-Roman isbl ItcSymbol-Black isbli ItcSymbol-BlackItalic isb ItcSymbol-Bold isbi ItcSymbol-BoldItalic isw ItcSymbol-Book iswi ItcSymbol-BookItalic ism ItcSymbol-Medium ismi ItcSymbol-MediumItalic usbl Usherwood-Black usbli Usherwood-BlackItalic usb Usherwood-Bold usbi Usherwood-BoldItalic usw Usherwood-Book uswi Usherwood-BookItalic usm Usherwood-Medium usmi Usherwood-MediumItalic zcb ZapfChancery-Bold zcd ZapfChancery-Demi zci ZapfChancery-Italic zcl ZapfChancery-Light zcli ZapfChancery-LightItalic zcr ZapfChancery-Roman imb Impressum-Bold imi Impressum-Italic imr Impressum-Roman inin Industria-Inline inina Industria-InlineA insd Industria-Solid insda Industria-SolidA ins Insignia insa Insignia-A itb Italia-Bold itw Italia-Book itm Italia-Medium jtb JansonText-Bold jtbi JansonText-BoldItalic jtbio JansonText-BoldItalicOsF jtbof JansonText-BoldOsF jti JansonText-Italic jtiof JansonText-ItalicOsF jtr JansonText-Roman jtrsc JansonText-RomanSC kbb ItcKabel-Bold kbw ItcKabel-Book kbd ItcKabel-Demi kbm ItcKabel-Medium kbu ItcKabel-Ultra kfb Kaufmann-Bold kf Kaufmann krb Korinna-Bold krkb Korinna-KursivBold krkx Korinna-KursivRegular krrg Korinna-Regular ktbl KuenstlerScript-Black ktm KuenstlerScript-Medium kt2b KuenstlerScript-TwoBold lwbl Leawood-Black lwbli Leawood-BlackItalic lwb Leawood-Bold lwbi Leawood-BoldItalic lww Leawood-Book lwwi Leawood-BookItalic lwm Leawood-Medium lwmi Leawood-MediumItalic lgb LetterGothic-Bold lgbsl LetterGothic-BoldSlanted lg LetterGothic lgsl LetterGothic-Slanted lib Life-Bold lii Life-Italic lir Life-Roman lp Linoscript lx Linotext lobl Lithos-Black lob Lithos-Bold loel Lithos-ExtraLight lol Lithos-Light lorg Lithos-Regular luw LubalinGraph-Book luwo LubalinGraph-BookOblique lud LubalinGraph-Demi ludo LubalinGraph-DemiOblique lcb Lucida-Bold lcbi Lucida-BoldItalic lci Lucida-Italic lc Lucida lme LucidaMath-Extension lmi LucidaMath-Italic lms LucidaMath-Symbol lsb LucidaSans-Bold lsbi LucidaSans-BoldItalic lsi LucidaSans-Italic ls LucidaSans mi MICR mh1 MathematicalPi-One mh2 MathematicalPi-Two mh3 MathematicalPi-Three mh4 MathematicalPi-Four mh5 MathematicalPi-Five mh6 MathematicalPi-Six mx Maximus mc MediciScript meb Melior-Bold mebi Melior-BoldItalic mei Melior-Italic me Melior mpb Memphis-Bold mpbi Memphis-BoldItalic mpeb Memphis-ExtraBold mpl Memphis-Light mpli Memphis-LightItalic mpm Memphis-Medium mpmi Memphis-MediumItalic m0b Meridien-Bold m0bi Meridien-BoldItalic m0i Meridien-Italic m0m Meridien-Medium m0mi Meridien-MediumItalic m0r Meridien-Roman mobl Minion-Black mob Minion-Bold mobi Minion-BoldItalic modsi Minion-DisplayItalic mods Minion-DisplayRegular mjbl MinionExp-Black mjb MinionExp-Bold mjbi MinionExp-BoldItalic mjdsi MinionExp-DisplayItalic mjds MinionExp-DisplayRegular mji MinionExp-Italic mjrg MinionExp-Regular mjsb MinionExp-Semibold mjsbi MinionExp-SemiboldItalic moi Minion-Italic moor Minion-Ornaments morg Minion-Regular mosb Minion-Semibold mosbi Minion-SemiboldItalic mosdi Minion-SwashDisplayItalic moswi Minion-SwashItalic mossb Minion-SwashSemiboldItalic mzbl Minister-Black mzbli Minister-BlackItalic mzb Minister-Bold mzbi Minister-BoldItalic mzw Minister-Book mzwi Minister-BookItalic mzl Minister-Light mzli Minister-LightItalic ms Mistral so Sonata new NeuzeitS-Book newh NeuzeitS-BookHeavy nabl NewAster-Black nabli NewAster-BlackItalic nab NewAster-Bold nabi NewAster-BoldItalic nai NewAster-Italic na NewAster nas NewAster-SemiBold nasi NewAster-SemiBoldItalic nlbl NewCaledonia-Black nlbli NewCaledonia-BlackItalic nlb NewCaledonia-Bold nlbi NewCaledonia-BoldItalic nli NewCaledonia-Italic nl NewCaledonia nls NewCaledonia-SemiBold nlsi NewCaledonia-SemiBoldItalic ncb NewCenturySchlbk-Bold ncbi NewCenturySchlbk-BoldItalic nci NewCenturySchlbk-Italic ncr NewCenturySchlbk-Roman ngb NewsGothic-Bold ngbo NewsGothic-BoldOblique ngo NewsGothic-Oblique ng NewsGothic nob Novarese-Bold nobi Novarese-BoldItalic now Novarese-Book nowi Novarese-BookItalic nom Novarese-Medium nomi Novarese-MediumItalic nou Novarese-Ultra nu NuptialScript oa OCRA ob OCRB olb Olympian-Bold olbi Olympian-BoldItalic oli Olympian-Italic ol Olympian omni Omnia opb Optima-Bold opbo Optima-BoldOblique opo Optima-Oblique op Optima or Orator orsl Orator-Slanted pob Palatino-Bold pobi Palatino-BoldItalic poi Palatino-Italic por Palatino-Roman pn Parisian pa ParkAvenue pgb Peignot-Bold pgd Peignot-Demi pgl Peignot-Light psb PostAntiqua-Bold psr PostAntiqua-Roman pr Present peb PrestigeElite-Bold pebsl PrestigeElite-BoldSlanted pe PrestigeElite pesl PrestigeElite-Slanted qobl Quorum-Black qob Quorum-Bold qow Quorum-Book qol Quorum-Light qom Quorum-Medium rab Raleigh-Bold rad Raleigh-DemiBold ram Raleigh-Medium ra Raleigh rp Reporter-Two re Revue rkb Rockwell-Bold rkbc Rockwell-BoldCondensed rkbi Rockwell-BoldItalic rkc Rockwell-Condensed rkeb Rockwell-ExtraBold rki Rockwell-Italic rkl Rockwell-Light rkli Rockwell-LightItalic rk Rockwell rbl RotisSansSerif-Light rbli RotisSansSerif-LightItalic rb RotisSansSerif rbi RotisSansSerif-Italic rbb RotisSansSerif-Bold rbeb RotisSansSerif-ExtraBold rcl RotisSemiSans-Light rcli RotisSemiSans-LightItalic rc RotisSemiSans rci RotisSemiSans-Italic rcb RotisSemiSans-Bold rceb RotisSemiSans-ExtraBold rf RotisSemiSerif rfb RotisSemiSerif-Bold rg RotisSerif rgi RotisSerif-Italic rgb RotisSerif-Bold ruo RussellSquare-Oblique ru RussellSquare sab Sabon-Bold sabi Sabon-BoldItalic sabio Sabon-BoldItalicOsF sabof Sabon-BoldOsF sai Sabon-Italic saiof Sabon-ItalicOsF sar Sabon-Roman sarsc Sabon-RomanSC sass Sassoon-Primary sgbl SerifGothic-Black sgb SerifGothic-Bold sgeb SerifGothic-ExtraBold sgh SerifGothic-Heavy sgl SerifGothic-Light sg SerifGothic sebl Serifa-Black seb Serifa-Bold sei Serifa-Italic sel Serifa-Light seli Serifa-LightItalic ser Serifa-Roman sfb Serpentine-Bold sfbo Serpentine-BoldOblique sfl Serpentine-Light sflo Serpentine-LightOblique sfm Serpentine-Medium sfmo Serpentine-MediumOblique sbb Shannon-Bold sbw Shannon-Book sbeb Shannon-ExtraBold sbo Shannon-Oblique shal Shelley-AllegroScript shan Shelley-AndanteScript shvo Shelley-VolanteScript gib SimonciniGaramond-Bold gii SimonciniGaramond-Italic gir SimonciniGaramond snbl SnellRoundhand-BlackScript snb SnellRoundhand-BoldScript sn SnellRoundhand-Script sud Souvenir-Demi sudi Souvenir-DemiItalic sul Souvenir-Light suli Souvenir-LightItalic sub Souvenir-Bold subi Souvenir-BoldItalic sum Souvenir-Medium sumi Souvenir-MediumItalic sqwcl Spartan-BookClassified sqhcl Spartan-HeavyClassified gsb StempelGaramond-Bold gsbi StempelGaramond-BoldItalic gsi StempelGaramond-Italic gsr StempelGaramond-Roman skbl StempelSchneidler-Black skbli StempelSchneidler-BlackItalic skb StempelSchneidler-Bold skbi StempelSchneidler-BoldItalic ski StempelSchneidler-Italic skl StempelSchneidler-Light skli StempelSchneidler-LightItalic skm StempelSchneidler-Medium skmi StempelSchneidler-MedItalic skr StempelSchneidler-Roman st Stencil sib StoneInformal-Bold sibi StoneInformal-BoldItalic sii StoneInformal-Italic si StoneInformal sisb StoneInformal-Semibold sisbi StoneInformal-SemiboldItalic ssb StoneSans-Bold ssbi StoneSans-BoldItalic ssi StoneSans-Italic ss StoneSans sssb StoneSans-Semibold sssbi StoneSans-SemiboldItalic srb StoneSerif-Bold srbi StoneSerif-BoldItalic sri StoneSerif-Italic sr StoneSerif srsb StoneSerif-Semibold srsbi StoneSerif-SemiboldItalic sy Symbol sxbl Syntax-Black sxb Syntax-Bold sxi Syntax-Italic sxr Syntax-Roman sxubl Syntax-UltraBlack tkb Tekton-Bold tkbo Tekton-BoldOblique tko Tekton-Oblique tkrg Tekton tehc Tempo-HeavyCondensed tehci Tempo-HeavyCondensedItalic tfd Tiffany-Demi tfdi Tiffany-DemiItalic tfh Tiffany-Heavy tfhi Tiffany-HeavyItalic tfi Tiffany-Italic tf Tiffany tib Times-Bold tibi Times-BoldItalic tibio Times-BoldItalicOsF tibsc Times-BoldSC tieb Times-ExtraBold tii Times-Italic tiio Times-ItalicOsF tir Times-Roman tirsc Times-RomanSC tisb Times-Semibold tisbi Times-SemiboldItalic mtb TimesNewRomanPS-Bold mtbi TimesNewRomanPS-BoldItalic mti TimesNewRomanPS-Italic mtr TimesNewRomanPS ttb TimesTen-Bold ttbi TimesTen-BoldItalic ttbio TimesTen-BoldItalicOsF ttbof TimesTen-BoldOsF tti TimesTen-Italic ttiof TimesTen-ItalicOsF ttr TimesTen-Roman ttrsc TimesTen-RomanSC tgb TradeGothic-Bold tgb2 TradeGothic-BoldTwo tgb2o TradeGothic-BoldTwoOblique tgbo TradeGothic-BoldOblique tgl TradeGothic-Light tglo TradeGothic-LightOblique tgo TradeGothic-Oblique tg TradeGothic tgbc TradeGothic-BoldCondTwenty tgbco TradeGothic-BoldCondTwentyObl tgc TradeGothic-CondEighteen tgco TradeGothic-CondEighteenObl tjb Trajan-Bold tjrg Trajan-Regular tmb TrumpMediaeval-Bold tmbi TrumpMediaeval-BoldItalic tmi TrumpMediaeval-Italic tmr TrumpMediaeval-Roman um Umbra uvtuc Univers-ThinUltraCondensed uvluc Univers-LightUltraCondensed uvv Univers-Extended uvvo Univers-ExtendedObl uvuc Univers-UltraCondensed uvbv Univers-BoldExt uvbvo Univers-BoldExtObl uvzv Univers-BlackExt uvzvo Univers-BlackExtObl uvf Univers-ExtraBlack uvfo Univers-ExtraBlackObl uvfv Univers-ExtraBlackExt uvfvo Univers-ExtraBlackExtObl uvbl Univers-Black uvblo Univers-BlackOblique uvb Univers-Bold uvbo Univers-BoldOblique uvc Univers-Condensed uvcb Univers-CondensedBold uvcbo Univers-CondensedBoldOblique uvcl Univers-CondensedLight uvclo Univers-CondensedLightOblique uvcdo Univers-CondensedOblique uvl Univers-Light uvlo Univers-LightOblique uv Univers uvo Univers-Oblique unvmg Universal-GreekwithMathPi unvnc Universal-NewswithCommPi ur UniversityRoman utbl Utopia-Black utb Utopia-Bold utbi Utopia-BoldItalic uebl UtopiaExp-Black ueb UtopiaExp-Bold uebi UtopiaExp-BoldItalic uei UtopiaExp-Italic uerg UtopiaExp-Regular uesb UtopiaExp-Semibold uesbi UtopiaExp-SemiboldItalic uti Utopia-Italic utor Utopia-Ornaments utrg Utopia-Regular utsb Utopia-Semibold utsbi Utopia-SemiboldItalic utttl Utopia-Titling vrbl VAGRounded-Black vrb VAGRounded-Bold vrl VAGRounded-Light vrt VAGRounded-Thin vel Versailles-Light veli Versailles-LightItalic ver Versailles-Roman vei Versailles-Italic veb Versailles-Bold vebi Versailles-BoldItalic vebl Versailles-Black vebli Versailles-BlackItalic wab Walbaum-Bold wabi Walbaum-BoldItalic wabio Walbaum-BoldItalicOsF wabof Walbaum-BoldOsF wai Walbaum-Italic waiof Walbaum-ItalicOsF war Walbaum-Roman warsc Walbaum-RomanSC wdbl Weidemann-Black wdbli Weidemann-BlackItalic wdb Weidemann-Bold wdbi Weidemann-BoldItalic wdw Weidemann-Book wdwi Weidemann-BookItalic wdm Weidemann-Medium wdmi Weidemann-MediumItalic web Weiss-Bold weeb Weiss-ExtraBold wei Weiss-Italic we Weiss wk WilhelmKlingsporGotisch wkdfr WilhelmKlingsporGotisch-Dfr c Cottonwood i Ironwood j Juniper m Mesquite woor WoodtypeOrnaments-One p Ponderosa bi Birch bo Blackoak mq Madrone woor2 WoodtypeOrnaments-Two pp Poplar wi Willow zcmi ZapfChancery-MediumItalic zd ZapfDingbats 2-Mar-1991 19:39:43-GMT,6244;000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA26287; Sat, 2 Mar 91 12:39:38 MST Date: Sat, 2 Mar 1991 11:38 PST From: Don Hosek Subject: Re: Standardization of TeX names for Adobe PostScript fonts. To: bkph@ai.mit.edu, texhax@cs.washington.edu, beebe@science.utah.edu Cc: berry@ai.mit.edu Message-Id: <0B9D3746A460125D@HMCVAX.CLAREMONT.EDU> X-Envelope-To: beebe@science.utah.edu X-Vms-To: IN%"bkph@ai.mit.edu" X-Vms-Cc: TEXHAX,NELSON_BEEBE,IN%"berry@ai.mit.edu" -re: Proposal for standardization of TeX names for Adobe PostScript fonts. -Given below are the six character abbreviated file names used by Adobe for -their outline fonts. It seems reasonable to simply adopt these short names -when refering to Adobe PostScript fonts in TeX (which happens to be limited -to six character font names). -Need for standardization of names for Adobe fonts used in TeX seems to be -the most urgent, since these are the fonts most frequently used (in fact, I -have yet to see an author call for a font other than CM, LaTeX, AMS or Adobe). Oh, there are some of us using PS fonts from other sources (Cassady & Greene) or non-PS fonts (Bitstream) in daily work. The reason you don't see any calls for help in my case, at least is that I have things well under control. -Using the vendor supplied abbreviation has clear advantages: Yes, but the short term view will _always_ lead to big problems. There already lists a canonical list of TeX abbreviations for I believe nearly all of the Adobe library. Addressing your specific points: -(*) There is no need for a committee to dream up abbreviations for new fonts. I dream up the abbreviations I need as I go along. For example, last week I determined that fosr would refer to the Fluent laser fonts [Cassay&Greene] Odessa Script font. -(*) There is no need for a clearing house to approve proposed abbreviations. Until the inevitable time that somebody discovers that they have a conflict between the metrics for Times on their HP LaserJet III and the Times on the typesetter that their final output is going to. Or that the new dingbats font they bought wants to use the same file name as their Garamond font. Don't think short term. Besides, approving proposed abbreviations is simply a matter of checking to see if their already exists an abbreviation for the font or if the proposed abbreviation is already in use. The latter could be done by a computer program, the former could as well, I suppose, but since there is a need to be wary of misspellings, abbreviations, etc. this could be difficult. -(*) There is no delay between publication of an outline font and availability - of a standard abbreviated name for it. Until the times mentioned above. -(*) The probability of confusion is reduced when only one short name needs - to be remembered for a font (instead of the one used by the vendor AND - one approved for use in TeX). How much word processing/DTP/digital typography software do you use? I have seen very little software that uses the abbreviated names in the end-user interface. Even in the case of TeX, the abbreviated names should only come into play when designing a style option for using the font under lfonts.new. Also, people tend to stick to a single application for dealing with printing of this sort anyway so even if the short font names were used at any time other than installation, chances are they'd only come in contact with one version anyway. -There are two possible problems with my proposal: -(.) Other vendors may use a particular abbreviation for different font. Pretty big -(.) The present scheme allows for only (26 + 10) * (26 * 10) = 1296 font - families. Adobe already has about 770 / 4 = 193 font families. So - in the distant future they are going to run out of two letter combinations. Let's see, Adobe has been around for around 10 years. We'll give them an average of 20 families per year. They have 1100 font families left, so we're fine until roughly 2046. I think we might be rid of the eight character restriction by then. I certainly *hope* MS-DOS will have died out by 2046. -(.) In TeX there is sometimes a need to remap the encoding of the font. TFM - files for the remapped versions must be distinguishable from the `raw' - versions. Karl Berry's scheme provides for this. -The first problem can be fixed by prefixing these names with a code -for the vendor - as suggested by Karl Berry - perhaps `p' for Adobe. -The solution of the second problem is to simply adopt whatever scheme the -vendor comes up with when that happens (and this won't happen for quite a -few years anyway...). -The third problem is less of an issue now that TeX can handle character sets -with 256 characters. But in any case, a suffix can be added to the name -(perhaps `x') to indicate remapping (although this does not tell one HOW -the font has been remapped). This, along with the vendor prefix, brings the -maximum length of a name to 8 characters, which almost all file systems now -are able to deal with. At this point your proposal is giving names that are logistically very much like Karl Berry's names. So why not just use Berry's scheme? It was not generated in a vacuum. There were quite a few of us who made suggestions on how to map names; the scheme has already been adapted by one dvi-to-ps system (Rokicki's dvips) and is likely to be adapted by others. Your scheme doesn't approach what to do about vendors who (a) don't supply short names (they exist; there are fonts sold only to the Macintosh community which can, nevertheless, be converted to a more generic PS format) or (b) have short names that are already 8 characters long (Cassady & Greene). Not to mention that Bitstream's short names are catalog numbers! Shall I continue to call Bitstream Dutch Roman "11"? I hope not. In short, I don't think that Vendor-supplied names are adequate in the least (and I say this from experience with quite a few font vendors). Adobe is *not* representative of the rest of the typeface world, so basing assumptions on what can or should be done on what Adobe does is a mistake. -dh 3-Mar-1991 12:58:10-GMT,28198;000000000001 Return-Path: Received: from life.ai.mit.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA01426; Sun, 3 Mar 91 05:58:04 MST Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA29416; Sun, 3 Mar 91 07:57:56 EST From: bkph@ai.mit.edu (Berthold K.P. Horn) Received: by rice-chex (4.1/AI-4.10) id AA08591; Sun, 3 Mar 91 07:57:51 EST Date: Sun, 3 Mar 91 07:57:51 EST Message-Id: <9103031257.AA08591@rice-chex> To: tex-fonts@math.utah.edu Subject: [bkph@ai.mit.edu: Standardization of TeX names for Adobe PostScript fonts.] Return-Path: From: bkph@ai.mit.edu (Berthold K.P. Horn) Date: Sat, 2 Mar 91 08:20:14 EST To: TeXhax@cs.washington.edu Cc: dhosek@ymir.claremont.edu, beebe@csc-sun.math.utah.edu, karl@cs.umd.edu Subject: Standardization of TeX names for Adobe PostScript fonts. re: Proposal for standardization of TeX names for Adobe PostScript fonts. Given below are the six character abbreviated file names used by Adobe for their outline fonts. It seems reasonable to simply adopt these short names when refering to Adobe PostScript fonts in TeX (which happens to be limited to six character font names). Need for standardization of names for Adobe fonts used in TeX seems to be the most urgent, since these are the fonts most frequently used (in fact, I have yet to see an author call for a font other than CM, LaTeX, AMS or Adobe). Using the vendor supplied abbreviation has clear advantages: (*) There is no need for a committee to dream up abbreviations for new fonts. (*) There is no need for a clearing house to approve proposed abbreviations. (*) There is no delay between publication of an outline font and availability of a standard abbreviated name for it. (*) The probability of confusion is reduced when only one short name needs to be remembered for a font (instead of the one used by the vendor AND one approved for use in TeX). There are two possible problems with my proposal: (.) Other vendors may use a particular abbreviation for different font. (.) The present scheme allows for only (26 + 10) * (26 * 10) = 1296 font families. Adobe already has about 770 / 4 = 193 font families. So in the distant future they are going to run out of two letter combinations. (.) In TeX there is sometimes a need to remap the encoding of the font. TFM files for the remapped versions must be distinguishable from the `raw' versions. The first problem can be fixed by prefixing these names with a code for the vendor - as suggested by Karl Berry - perhaps `p' for Adobe. The solution of the second problem is to simply adopt whatever scheme the vendor comes up with when that happens (and this won't happen for quite a few years anyway...). The third problem is less of an issue now that TeX can handle character sets with 256 characters. But in any case, a suffix can be added to the name (perhaps `x') to indicate remapping (although this does not tell one HOW the font has been remapped). This, along with the vendor prefix, brings the maximum length of a name to 8 characters, which almost all file systems now are able to deal with. Berthold K.P. Horn P.S. Thanks to Terry O'Donnell for help with generating this list. ========================= acb Aachen-Bold awab ACaslon-AltBold awabi ACaslon-AltBoldItalic awai ACaslon-AltItalic awarg ACaslon-AltRegular awasb ACaslon-AltSemibold awasi ACaslon-AltSemiboldItalic awb ACaslon-Bold awbi ACaslon-BoldItalic axb ACaslonExp-Bold axbi ACaslonExp-BoldItalic axi ACaslonExp-Italic axrg ACaslonExp-Regular axsb ACaslonExp-Semibold axsbi ACaslonExp-SemiboldItalic awi ACaslon-Italic awor ACaslon-Ornaments awrg ACaslon-Regular awsb ACaslon-Semibold awsbi ACaslon-SemiboldItalic awswb ACaslon-SwashBoldItalic awswi ACaslon-SwashItalic awssb ACaslon-SwashSemiboldItalic ggi AGaramondAlt-Italic ggrg AGaramondAlt-Regular gdb AGaramond-Bold gdbi AGaramond-BoldItalic geb AGaramondExp-Bold gebi AGaramondExp-BoldItalic gei AGaramondExp-Italic gerg AGaramondExp-Regular gesb AGaramondExp-Semibold gesbi AGaramondExp-SemiboldItalic gdi AGaramond-Italic gdrg AGaramond-Regular gdsb AGaramond-Semibold gdsbi AGaramond-SemiboldItalic gdttl AGaramond-Titling akbl AkzidenzGrotesk-Black akb AkzidenzGrotesk-Bold akl AkzidenzGrotesk-Light akr AkzidenzGrotesk-Roman amb Americana-Bold ameb Americana-ExtraBold ami Americana-Italic am Americana aqbl AntiqueOlive-Black aqb AntiqueOlive-Bold aqi AntiqueOlive-Italic aql AntiqueOlive-Light aqr AntiqueOlive-Roman aqbc AntiqueOlive-BoldCond aqct AntiqueOlive-Compact aqnr AntiqueOlive-Nord aqnri AntiqueOlive-NordItalic a Arcadia a AAA Arcadia-A ab ArnoldBoecklin ael Avenir-Light aelo Avenir-LightOblique aew Avenir-Book aewo Avenir-BookOblique aer Avenir-Roman aero Avenir-Oblique aem Avenir-Medium aemo Avenir-MediumOblique aeh Avenir-Heavy aeho Avenir-HeavyOblique aebl Avenir-Black aeblo Avenir-BlackOblique bc Banco bbb BauerBodoni-Bold bbbi BauerBodoni-BoldItalic bbbio BauerBodoni-BoldItalicOsF bbbof BauerBodoni-BoldOsF bbi BauerBodoni-Italic bbiof BauerBodoni-ItalicOsF bbr BauerBodoni-Roman bbrsc BauerBodoni-RomanSC bbbl BauerBodoni-Black bbblc BauerBodoni-BlackCond bbbli BauerBodoni-BlackItalic bbbc BauerBodoni-BoldCond bhb Bauhaus-Bold bhd Bauhaus-Demi bhh Bauhaus-Heavy bhl Bauhaus-Light bhm Bauhaus-Medium bwb Belwe-Bold bwc Belwe-Condensed bwl Belwe-Light bwm Belwe-Medium bmb Bembo-Bold bmbi Bembo-BoldItalic bmeb Bembo-ExtraBold bmebi Bembo-ExtraBoldItalic bmi Bembo-Italic bm Bembo bmsb Bembo-Semibold bmsbi Bembo-SemiboldItalic bgb Benguiat-Bold bgw Benguiat-Book bybl Berkeley-Black bybli Berkeley-BlackItalic byb Berkeley-Bold bybi Berkeley-BoldItalic byw Berkeley-Book bywi Berkeley-BookItalic byi Berkeley-Italic bym Berkeley-Medium bdb Bodoni-Bold bdbi Bodoni-BoldItalic bdi Bodoni-Italic bdps Bodoni-Poster bd Bodoni bdbc Bodoni-BoldCondensed bdw Bodoni-Book bdwi Bodoni-BookItalic bdpsc Bodoni-PosterCompressed bdpsi Bodoni-PosterItalic bkb Bookman-Bold bkbi Bookman-BoldItalic bkd Bookman-Demi bkdi Bookman-DemiItalic bkl Bookman-Light bkli Bookman-LightItalic bkm Bookman-Medium bkmi Bookman-MediumItalic j1515 BorderPi-OneFiveOneFiveNine bs BrushScript db1 BundesbahnPi-One db2 BundesbahnPi-Two db3 BundesbahnPi-Three cgb Candida-Bold cgi Candida-Italic cgr Candida-Roman cr Carta ck CascadeScript c2bl CaslonTwoTwentyFour-Black c2bli CaslonTwoTwentyFour-BlackIt c2b CaslonTwoTwentyFour-Bold c2bi CaslonTwoTwentyFour-BoldIt c2w CaslonTwoTwentyFour-Book c2wi CaslonTwoTwentyFour-BookIt c2m CaslonTwoTwentyFour-Medium c2mi CaslonTwoTwentyFour-MediumIt cti CaslonThree-Italic ctr CaslonThree-Roman cfi CaslonFiveForty-Italic cfr CaslonFiveForty-Roman ca CaslonOpenFace cxb Caxton-Bold cxbi Caxton-BoldItalic cxw Caxton-Book cxwi Caxton-BookItalic cxl Caxton-Light cxli Caxton-LightItalic cil Centennial-Light cili Centennial-LightItalic cir Centennial-Roman cii Centennial-Italic cib Centennial-Bold cibi Centennial-BoldItalic cibl Centennial-Black cibli Centennial-BlackItalic cyi CenturyExpanded-Italic cy CenturyExpanded csb CenturyOldStyle-Bold csi CenturyOldStyle-Italic csrg CenturyOldStyle-Regular czb Charlemagne-Bold czrg Charlemagne-Regular cu Charme cq Cheq clb Clarendon-Bold cll Clarendon-Light cl Clarendon cebl Clearface-Black cebli Clearface-BlackItalic ceb Clearface-Bold cebi Clearface-BoldItalic ceh Clearface-Heavy cehi Clearface-HeavyItalic cerg Clearface-Regular cergi Clearface-RegularItalic ccb Cochin-Bold ccbi Cochin-BoldItalic cci Cochin-Italic cc Cochin cjb Concorde-Bold cjbi Concorde-BoldItalic cji Concorde-Italic cjr Concorde-Roman cbi CooperBlack-Italic cb CooperBlack cp29a Copperplate-TwentyNineAB cp29c Copperplate-TwentyNineBC cp30a Copperplate-ThirtyAB cp30c Copperplate-ThirtyBC cp31a Copperplate-ThirtyOneAB cp31c Copperplate-ThirtyOneBC cp32a Copperplate-ThirtyTwoAB cp32c Copperplate-ThirtyTwoBC cp33c Copperplate-ThirtyThreeBC cnb Corona-Bold cni Corona-Italic cn Corona cob Courier-Bold cobo Courier-BoldOblique com Courier coo Courier-Oblique cob Courier-Bold cobo Courier-BoldOblique com Courier coo Courier-Oblique dinen DINEngschrift dinmi DINMittelschrift dngbc DINNeuzeitGrotesk-BoldCond dngl DINNeuzeitGrotesk-Light dcb DomCasual-Bold dc DomCasual drb Doric-Bold du DucDeBerry dudfr DucDeBerry-Dfr erb ItcEras-Bold erbk ItcEras-Book erd ItcEras-Demi erl ItcEras-Light erm ItcEras-Medium eru ItcEras-Ultra euro1 EuropeanPi-One euro2 EuropeanPi-Two euro3 EuropeanPi-Three euro4 EuropeanPi-Four eub Eurostile-Bold eubo Eurostile-BoldOblique eud Eurostile-Demi eudo Eurostile-DemiOblique eu Eurostile euo Eurostile-Oblique eubc Eurostile-BoldCondensed eubex Eurostile-BoldExtendedTwo euc Eurostile-Condensed euex Eurostile-ExtendedTwo exb Excelsior-Bold exi Excelsior-Italic ex Excelsior ff FetteFraktur flblc Flyer-BlackCondensed flebc Flyer-ExtraBlackCondensed fob Folio-Bold fobc Folio-BoldCondensed foeb Folio-ExtraBold fol Folio-Light fom Folio-Medium frw FranklinGothic-Book frwo FranklinGothic-BookOblique frd FranklinGothic-Demi frdo FranklinGothic-DemiOblique frh FranklinGothic-Heavy frho FranklinGothic-HeavyOblique fgc FranklinGothic-Condensed fgec FranklinGothic-ExtraCond fgr FranklinGothic-Roman fs FreestyleScript fqb FrizQuadrata-Bold fq FrizQuadrata ftl Frutiger-Light ftli Frutiger-LightItalic ftr Frutiger-Roman fti Frutiger-Italic ftb Frutiger-Bold ftbi Frutiger-BoldItalic ftbl Frutiger-Black ftbli Frutiger-BlackItalic ftubl Frutiger-UltraBlack fub Futura-Bold fubo Futura-BoldOblique fuw Futura-Book fuwo Futura-BookOblique fuc Futura-Condensed fucb Futura-CondensedBold fucbo Futura-CondensedBoldOblique fuceb Futura-CondensedExtraBold fcebo Futura-CondExtraBoldObl fucl Futura-CondensedLight fuclo Futura-CondensedLightOblique fuco Futura-CondensedOblique fueb Futura-ExtraBold fuebo Futura-ExtraBoldOblique fuh Futura-Heavy fuho Futura-HeavyOblique ful Futura-Light fulo Futura-LightOblique fu Futura fuo Futura-Oblique gmb GaramondThree-Bold gmbi GaramondThree-BoldItalic gmbio GaramondThree-BoldItalicOsF gmbsc GaramondThree-BoldSC gmi GaramondThree-Italic gmio GaramondThree-ItalicOsF gm GaramondThree gmsc GaramondThree-SC ghz GarthGraphic-Black ghb GarthGraphic-Bold ghbc GarthGraphic-BoldCondensed ghbi GarthGraphic-BoldItalic ghc GarthGraphic-Condensed gheb GarthGraphic-ExtraBold ghi GarthGraphic-Italic gh GarthGraphic gnb GillSans-Bold gnbc GillSans-BoldCondensed gnbi GillSans-BoldItalic gnc GillSans-Condensed gneb GillSans-ExtraBold gni GillSans-Italic gnl GillSans-Light gnli GillSans-LightItalic gn GillSans gnub GillSans-UltraBold gnubc GillSans-UltraBoldCondensed gyb Glypha-Bold gybo Glypha-BoldOblique gyo Glypha-Oblique gy Glypha gyt Glypha-Thin gyto Glypha-ThinOblique gyl Glypha-Light gylo Glypha-LightOblique gybl Glypha-Black gyblo Glypha-BlackOblique gtt Gothic-Thirteen gob Goudy-Bold gobi Goudy-BoldItalic goi Goudy-Italic go Goudy goeb Goudy-ExtraBold goh Goudy-Heavyface gohi Goudy-HeavyfaceItalic grb Granjon-Bold gri Granjon-Italic gr Granjon hvbl Helvetica-Black hvblo Helvetica-BlackOblique hvb Helvetica-Bold hvbo Helvetica-BoldOblique hvk Helvetica-Compressed hvc Helvetica-Condensed hvcbl Helvetica-Condensed-Black hvco Helvetica-Condensed-BlackObl hvcb Helvetica-Condensed-Bold hvcbo Helvetica-Condensed-BoldObl hvcl Helvetica-Condensed-Light hvclo Helvetica-Condensed-LightObl hvcdo Helvetica-Condensed-Oblique hvek Helvetica-ExtraCompressed hvl Helvetica-Light hvlo Helvetica-LightOblique hv Helvetica hvn Helvetica-Narrow hvnb Helvetica-Narrow-Bold hvnbo Helvetica-Narrow-BoldOblique hvno Helvetica-Narrow-Oblique hvo Helvetica-Oblique hvuk Helvetica-UltraCompressed hir HelveticaInserat-Roman hlj HelveticaNeue-ExtBlackCond hljo HelveticaNeue-ExtBlackCondObl hlav HelveticaNeue-UltraLigExt hlavo HelveticaNeue-UltraLigExtObl hlul HelveticaNeue-UltraLight hluli HelveticaNeue-UltraLightItal hla HelveticaNeue-UltraLigCond hlao HelveticaNeue-UltraLigCondObl hltv HelveticaNeue-ThinExt hltvo HelveticaNeue-ThinExtObl hlt HelveticaNeue-Thin hlti HelveticaNeue-ThinItalic hltc HelveticaNeue-ThinCond hltco HelveticaNeue-ThinCondObl hllv HelveticaNeue-LightExt hllvo HelveticaNeue-LightExtObl hll HelveticaNeue-Light hlli HelveticaNeue-LightItalic hllc HelveticaNeue-LightCond hllco HelveticaNeue-LightCondObl hlv HelveticaNeue-Extended hlvo HelveticaNeue-ExtendedObl hlr HelveticaNeue-Roman hli HelveticaNeue-Italic hlc HelveticaNeue-Condensed hlco HelveticaNeue-CondensedObl hlmv HelveticaNeue-MediumExt hlmvo HelveticaNeue-MediumExtObl hlm HelveticaNeue-Medium hlmi HelveticaNeue-MediumItalic hlmc HelveticaNeue-MediumCond hlmco HelveticaNeue-MediumCondObl hlbv HelveticaNeue-BoldExt hlbvo HelveticaNeue-BoldExtObl hlb HelveticaNeue-Bold hlbi HelveticaNeue-BoldItalic hlbc HelveticaNeue-BoldCond hlbco HelveticaNeue-BoldCondObl hlhv HelveticaNeue-HeavyExt hlhvo HelveticaNeue-HeavyExtObl hlh HelveticaNeue-Heavy hlhi HelveticaNeue-HeavyItalic hlhc HelveticaNeue-HeavyCond hlhco HelveticaNeue-HeavyCondObl hlzv HelveticaNeue-BlackExt hlzvo HelveticaNeue-BlackExtObl hlbl HelveticaNeue-Black hlbli HelveticaNeue-BlackItalic hlzc HelveticaNeue-BlackCond hlzco HelveticaNeue-BlackCondObl hebl HelveticaRounded-Black heblo HelveticaRounded-BlackObl heb HelveticaRounded-Bold hebc HelveticaRounded-BoldCond hebco HelveticaRounded-BoldCondObl hebo HelveticaRounded-BoldObl herc Herculanum hrbl Hiroshige-Black hrbli Hiroshige-BlackItalic hrb Hiroshige-Bold hrbi Hiroshige-BoldItalic hrw Hiroshige-Book hrwi Hiroshige-BookItalic hrm Hiroshige-Medium hrmi Hiroshige-MediumItalic ho Hobo atb AmericanTypewriter-Bold atm AmericanTypewriter-Medium agw AvantGarde-Book agwo AvantGarde-BookOblique agcb AvantGarde-CondBold agcw AvantGarde-CondBook agcd AvantGarde-CondDemi agcm AvantGarde-CondMedium agd AvantGarde-Demi agdo AvantGarde-DemiOblique beb BenguiatGothic-Bold bebo BenguiatGothic-BoldOblique bew BenguiatGothic-Book bewo BenguiatGothic-BookOblique beh BenguiatGothic-Heavy beho BenguiatGothic-HeavyOblique bem BenguiatGothic-Medium bemo BenguiatGothic-MediumOblique icb Century-Bold icbci Century-BoldCondensedItalic icbc Century-BoldCondensed icbi Century-BoldItalic icw Century-Book icwci Century-BookCondensedItalic icwc Century-BookCondensed icwi Century-BookItalic icl Century-Light iclci Century-LightCondensedItalic iclc Century-LightCondensed icli Century-LightItalic icu Century-Ultra icuci Century-UltraCondensedItalic icuc Century-UltraCondensed icui Century-UltraItalic chb Cheltenham-Bold chbc Cheltenham-BoldCond chbci Cheltenham-BoldCondItalic chbi Cheltenham-BoldItalic chw Cheltenham-Book chwc Cheltenham-BookCond chwci Cheltenham-BookCondItalic chwi Cheltenham-BookItalic chl Cheltenham-Light chlc Cheltenham-LightCond chlci Cheltenham-LightCondItalic chli Cheltenham-LightItalic chu Cheltenham-Ultra chuc Cheltenham-UltraCond chuci Cheltenham-UltraCondItalic chui Cheltenham-UltraItalic iub Cushing-Bold iubi Cushing-BoldItalic iuw Cushing-Book iuwi Cushing-BookItalic iuh Cushing-Heavy iuhi Cushing-HeavyItalic ium Cushing-Medium iumi Cushing-MediumItalic feb Fenice-Bold febo Fenice-BoldOblique fel Fenice-Light felo Fenice-LightOblique ferg Fenice-Regular fergo Fenice-RegularOblique feu Fenice-Ultra feuo Fenice-UltraOblique glbl Galliard-Black glbli Galliard-BlackItalic glb Galliard-Bold glbi Galliard-BoldItalic gli Galliard-Italic glr Galliard-Roman glu Galliard-Ultra glui Galliard-UltraItalic gab Garamond-Bold gabc Garamond-BoldCondensed gabci Garamond-BoldCondensedItalic gabi Garamond-BoldItalic gaw Garamond-Book gawc Garamond-BookCondensed gawci Garamond-BookCondensedItalic gawi Garamond-BookItalic gal Garamond-Light galc Garamond-LightCondensed galci Garamond-LightCondensedItalic gali Garamond-LightItalic gau Garamond-Ultra gauc Garamond-UltraCondensed gauci Garamond-UltraCondensedItalic gaui Garamond-UltraItalic mab Machine-Bold ma Machine nbb NewBaskerville-Bold nbbi NewBaskerville-BoldItalic nbi NewBaskerville-Italic nbr NewBaskerville-Roman isbl ItcSymbol-Black isbli ItcSymbol-BlackItalic isb ItcSymbol-Bold isbi ItcSymbol-BoldItalic isw ItcSymbol-Book iswi ItcSymbol-BookItalic ism ItcSymbol-Medium ismi ItcSymbol-MediumItalic usbl Usherwood-Black usbli Usherwood-BlackItalic usb Usherwood-Bold usbi Usherwood-BoldItalic usw Usherwood-Book uswi Usherwood-BookItalic usm Usherwood-Medium usmi Usherwood-MediumItalic zcb ZapfChancery-Bold zcd ZapfChancery-Demi zci ZapfChancery-Italic zcl ZapfChancery-Light zcli ZapfChancery-LightItalic zcr ZapfChancery-Roman imb Impressum-Bold imi Impressum-Italic imr Impressum-Roman inin Industria-Inline inina Industria-InlineA insd Industria-Solid insda Industria-SolidA ins Insignia insa Insignia-A itb Italia-Bold itw Italia-Book itm Italia-Medium jtb JansonText-Bold jtbi JansonText-BoldItalic jtbio JansonText-BoldItalicOsF jtbof JansonText-BoldOsF jti JansonText-Italic jtiof JansonText-ItalicOsF jtr JansonText-Roman jtrsc JansonText-RomanSC kbb ItcKabel-Bold kbw ItcKabel-Book kbd ItcKabel-Demi kbm ItcKabel-Medium kbu ItcKabel-Ultra kfb Kaufmann-Bold kf Kaufmann krb Korinna-Bold krkb Korinna-KursivBold krkx Korinna-KursivRegular krrg Korinna-Regular ktbl KuenstlerScript-Black ktm KuenstlerScript-Medium kt2b KuenstlerScript-TwoBold lwbl Leawood-Black lwbli Leawood-BlackItalic lwb Leawood-Bold lwbi Leawood-BoldItalic lww Leawood-Book lwwi Leawood-BookItalic lwm Leawood-Medium lwmi Leawood-MediumItalic lgb LetterGothic-Bold lgbsl LetterGothic-BoldSlanted lg LetterGothic lgsl LetterGothic-Slanted lib Life-Bold lii Life-Italic lir Life-Roman lp Linoscript lx Linotext lobl Lithos-Black lob Lithos-Bold loel Lithos-ExtraLight lol Lithos-Light lorg Lithos-Regular luw LubalinGraph-Book luwo LubalinGraph-BookOblique lud LubalinGraph-Demi ludo LubalinGraph-DemiOblique lcb Lucida-Bold lcbi Lucida-BoldItalic lci Lucida-Italic lc Lucida lme LucidaMath-Extension lmi LucidaMath-Italic lms LucidaMath-Symbol lsb LucidaSans-Bold lsbi LucidaSans-BoldItalic lsi LucidaSans-Italic ls LucidaSans mi MICR mh1 MathematicalPi-One mh2 MathematicalPi-Two mh3 MathematicalPi-Three mh4 MathematicalPi-Four mh5 MathematicalPi-Five mh6 MathematicalPi-Six mx Maximus mc MediciScript meb Melior-Bold mebi Melior-BoldItalic mei Melior-Italic me Melior mpb Memphis-Bold mpbi Memphis-BoldItalic mpeb Memphis-ExtraBold mpl Memphis-Light mpli Memphis-LightItalic mpm Memphis-Medium mpmi Memphis-MediumItalic m0b Meridien-Bold m0bi Meridien-BoldItalic m0i Meridien-Italic m0m Meridien-Medium m0mi Meridien-MediumItalic m0r Meridien-Roman mobl Minion-Black mob Minion-Bold mobi Minion-BoldItalic modsi Minion-DisplayItalic mods Minion-DisplayRegular mjbl MinionExp-Black mjb MinionExp-Bold mjbi MinionExp-BoldItalic mjdsi MinionExp-DisplayItalic mjds MinionExp-DisplayRegular mji MinionExp-Italic mjrg MinionExp-Regular mjsb MinionExp-Semibold mjsbi MinionExp-SemiboldItalic moi Minion-Italic moor Minion-Ornaments morg Minion-Regular mosb Minion-Semibold mosbi Minion-SemiboldItalic mosdi Minion-SwashDisplayItalic moswi Minion-SwashItalic mossb Minion-SwashSemiboldItalic mzbl Minister-Black mzbli Minister-BlackItalic mzb Minister-Bold mzbi Minister-BoldItalic mzw Minister-Book mzwi Minister-BookItalic mzl Minister-Light mzli Minister-LightItalic ms Mistral so Sonata new NeuzeitS-Book newh NeuzeitS-BookHeavy nabl NewAster-Black nabli NewAster-BlackItalic nab NewAster-Bold nabi NewAster-BoldItalic nai NewAster-Italic na NewAster nas NewAster-SemiBold nasi NewAster-SemiBoldItalic nlbl NewCaledonia-Black nlbli NewCaledonia-BlackItalic nlb NewCaledonia-Bold nlbi NewCaledonia-BoldItalic nli NewCaledonia-Italic nl NewCaledonia nls NewCaledonia-SemiBold nlsi NewCaledonia-SemiBoldItalic ncb NewCenturySchlbk-Bold ncbi NewCenturySchlbk-BoldItalic nci NewCenturySchlbk-Italic ncr NewCenturySchlbk-Roman ngb NewsGothic-Bold ngbo NewsGothic-BoldOblique ngo NewsGothic-Oblique ng NewsGothic nob Novarese-Bold nobi Novarese-BoldItalic now Novarese-Book nowi Novarese-BookItalic nom Novarese-Medium nomi Novarese-MediumItalic nou Novarese-Ultra nu NuptialScript oa OCRA ob OCRB olb Olympian-Bold olbi Olympian-BoldItalic oli Olympian-Italic ol Olympian omni Omnia opb Optima-Bold opbo Optima-BoldOblique opo Optima-Oblique op Optima or Orator orsl Orator-Slanted pob Palatino-Bold pobi Palatino-BoldItalic poi Palatino-Italic por Palatino-Roman pn Parisian pa ParkAvenue pgb Peignot-Bold pgd Peignot-Demi pgl Peignot-Light psb PostAntiqua-Bold psr PostAntiqua-Roman pr Present peb PrestigeElite-Bold pebsl PrestigeElite-BoldSlanted pe PrestigeElite pesl PrestigeElite-Slanted qobl Quorum-Black qob Quorum-Bold qow Quorum-Book qol Quorum-Light qom Quorum-Medium rab Raleigh-Bold rad Raleigh-DemiBold ram Raleigh-Medium ra Raleigh rp Reporter-Two re Revue rkb Rockwell-Bold rkbc Rockwell-BoldCondensed rkbi Rockwell-BoldItalic rkc Rockwell-Condensed rkeb Rockwell-ExtraBold rki Rockwell-Italic rkl Rockwell-Light rkli Rockwell-LightItalic rk Rockwell rbl RotisSansSerif-Light rbli RotisSansSerif-LightItalic rb RotisSansSerif rbi RotisSansSerif-Italic rbb RotisSansSerif-Bold rbeb RotisSansSerif-ExtraBold rcl RotisSemiSans-Light rcli RotisSemiSans-LightItalic rc RotisSemiSans rci RotisSemiSans-Italic rcb RotisSemiSans-Bold rceb RotisSemiSans-ExtraBold rf RotisSemiSerif rfb RotisSemiSerif-Bold rg RotisSerif rgi RotisSerif-Italic rgb RotisSerif-Bold ruo RussellSquare-Oblique ru RussellSquare sab Sabon-Bold sabi Sabon-BoldItalic sabio Sabon-BoldItalicOsF sabof Sabon-BoldOsF sai Sabon-Italic saiof Sabon-ItalicOsF sar Sabon-Roman sarsc Sabon-RomanSC sass Sassoon-Primary sgbl SerifGothic-Black sgb SerifGothic-Bold sgeb SerifGothic-ExtraBold sgh SerifGothic-Heavy sgl SerifGothic-Light sg SerifGothic sebl Serifa-Black seb Serifa-Bold sei Serifa-Italic sel Serifa-Light seli Serifa-LightItalic ser Serifa-Roman sfb Serpentine-Bold sfbo Serpentine-BoldOblique sfl Serpentine-Light sflo Serpentine-LightOblique sfm Serpentine-Medium sfmo Serpentine-MediumOblique sbb Shannon-Bold sbw Shannon-Book sbeb Shannon-ExtraBold sbo Shannon-Oblique shal Shelley-AllegroScript shan Shelley-AndanteScript shvo Shelley-VolanteScript gib SimonciniGaramond-Bold gii SimonciniGaramond-Italic gir SimonciniGaramond snbl SnellRoundhand-BlackScript snb SnellRoundhand-BoldScript sn SnellRoundhand-Script sud Souvenir-Demi sudi Souvenir-DemiItalic sul Souvenir-Light suli Souvenir-LightItalic sub Souvenir-Bold subi Souvenir-BoldItalic sum Souvenir-Medium sumi Souvenir-MediumItalic sqwcl Spartan-BookClassified sqhcl Spartan-HeavyClassified gsb StempelGaramond-Bold gsbi StempelGaramond-BoldItalic gsi StempelGaramond-Italic gsr StempelGaramond-Roman skbl StempelSchneidler-Black skbli StempelSchneidler-BlackItalic skb StempelSchneidler-Bold skbi StempelSchneidler-BoldItalic ski StempelSchneidler-Italic skl StempelSchneidler-Light skli StempelSchneidler-LightItalic skm StempelSchneidler-Medium skmi StempelSchneidler-MedItalic skr StempelSchneidler-Roman st Stencil sib StoneInformal-Bold sibi StoneInformal-BoldItalic sii StoneInformal-Italic si StoneInformal sisb StoneInformal-Semibold sisbi StoneInformal-SemiboldItalic ssb StoneSans-Bold ssbi StoneSans-BoldItalic ssi StoneSans-Italic ss StoneSans sssb StoneSans-Semibold sssbi StoneSans-SemiboldItalic srb StoneSerif-Bold srbi StoneSerif-BoldItalic sri StoneSerif-Italic sr StoneSerif srsb StoneSerif-Semibold srsbi StoneSerif-SemiboldItalic sy Symbol sxbl Syntax-Black sxb Syntax-Bold sxi Syntax-Italic sxr Syntax-Roman sxubl Syntax-UltraBlack tkb Tekton-Bold tkbo Tekton-BoldOblique tko Tekton-Oblique tkrg Tekton tehc Tempo-HeavyCondensed tehci Tempo-HeavyCondensedItalic tfd Tiffany-Demi tfdi Tiffany-DemiItalic tfh Tiffany-Heavy tfhi Tiffany-HeavyItalic tfi Tiffany-Italic tf Tiffany tib Times-Bold tibi Times-BoldItalic tibio Times-BoldItalicOsF tibsc Times-BoldSC tieb Times-ExtraBold tii Times-Italic tiio Times-ItalicOsF tir Times-Roman tirsc Times-RomanSC tisb Times-Semibold tisbi Times-SemiboldItalic mtb TimesNewRomanPS-Bold mtbi TimesNewRomanPS-BoldItalic mti TimesNewRomanPS-Italic mtr TimesNewRomanPS ttb TimesTen-Bold ttbi TimesTen-BoldItalic ttbio TimesTen-BoldItalicOsF ttbof TimesTen-BoldOsF tti TimesTen-Italic ttiof TimesTen-ItalicOsF ttr TimesTen-Roman ttrsc TimesTen-RomanSC tgb TradeGothic-Bold tgb2 TradeGothic-BoldTwo tgb2o TradeGothic-BoldTwoOblique tgbo TradeGothic-BoldOblique tgl TradeGothic-Light tglo TradeGothic-LightOblique tgo TradeGothic-Oblique tg TradeGothic tgbc TradeGothic-BoldCondTwenty tgbco TradeGothic-BoldCondTwentyObl tgc TradeGothic-CondEighteen tgco TradeGothic-CondEighteenObl tjb Trajan-Bold tjrg Trajan-Regular tmb TrumpMediaeval-Bold tmbi TrumpMediaeval-BoldItalic tmi TrumpMediaeval-Italic tmr TrumpMediaeval-Roman um Umbra uvtuc Univers-ThinUltraCondensed uvluc Univers-LightUltraCondensed uvv Univers-Extended uvvo Univers-ExtendedObl uvuc Univers-UltraCondensed uvbv Univers-BoldExt uvbvo Univers-BoldExtObl uvzv Univers-BlackExt uvzvo Univers-BlackExtObl uvf Univers-ExtraBlack uvfo Univers-ExtraBlackObl uvfv Univers-ExtraBlackExt uvfvo Univers-ExtraBlackExtObl uvbl Univers-Black uvblo Univers-BlackOblique uvb Univers-Bold uvbo Univers-BoldOblique uvc Univers-Condensed uvcb Univers-CondensedBold uvcbo Univers-CondensedBoldOblique uvcl Univers-CondensedLight uvclo Univers-CondensedLightOblique uvcdo Univers-CondensedOblique uvl Univers-Light uvlo Univers-LightOblique uv Univers uvo Univers-Oblique unvmg Universal-GreekwithMathPi unvnc Universal-NewswithCommPi ur UniversityRoman utbl Utopia-Black utb Utopia-Bold utbi Utopia-BoldItalic uebl UtopiaExp-Black ueb UtopiaExp-Bold uebi UtopiaExp-BoldItalic uei UtopiaExp-Italic uerg UtopiaExp-Regular uesb UtopiaExp-Semibold uesbi UtopiaExp-SemiboldItalic uti Utopia-Italic utor Utopia-Ornaments utrg Utopia-Regular utsb Utopia-Semibold utsbi Utopia-SemiboldItalic utttl Utopia-Titling vrbl VAGRounded-Black vrb VAGRounded-Bold vrl VAGRounded-Light vrt VAGRounded-Thin vel Versailles-Light veli Versailles-LightItalic ver Versailles-Roman vei Versailles-Italic veb Versailles-Bold vebi Versailles-BoldItalic vebl Versailles-Black vebli Versailles-BlackItalic wab Walbaum-Bold wabi Walbaum-BoldItalic wabio Walbaum-BoldItalicOsF wabof Walbaum-BoldOsF wai Walbaum-Italic waiof Walbaum-ItalicOsF war Walbaum-Roman warsc Walbaum-RomanSC wdbl Weidemann-Black wdbli Weidemann-BlackItalic wdb Weidemann-Bold wdbi Weidemann-BoldItalic wdw Weidemann-Book wdwi Weidemann-BookItalic wdm Weidemann-Medium wdmi Weidemann-MediumItalic web Weiss-Bold weeb Weiss-ExtraBold wei Weiss-Italic we Weiss wk WilhelmKlingsporGotisch wkdfr WilhelmKlingsporGotisch-Dfr c Cottonwood i Ironwood j Juniper m Mesquite woor WoodtypeOrnaments-One p Ponderosa bi Birch bo Blackoak mq Madrone woor2 WoodtypeOrnaments-Two pp Poplar wi Willow zcmi ZapfChancery-MediumItalic zd ZapfDingbats 3-Mar-1991 13:50:39-GMT,28439;000000000001 Return-Path: Received: from life.ai.mit.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA01617; Sun, 3 Mar 91 06:50:33 MST Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA29714; Sun, 3 Mar 91 08:50:21 EST From: bkph@ai.mit.edu (Berthold K.P. Horn) Received: by rice-chex (4.1/AI-4.10) id AA08650; Sun, 3 Mar 91 08:50:16 EST Date: Sun, 3 Mar 91 08:50:16 EST Message-Id: <9103031350.AA08650@rice-chex> To: tex-fonts@math.utah.edu Subject: [bkph@ai.mit.edu: [bkph@ai.mit.edu: Standardization of TeX names for Adobe PostScript fonts.]] Return-Path: From: bkph@ai.mit.edu (Berthold K.P. Horn) Date: Sun, 3 Mar 91 07:57:51 EST To: tex-fonts@math.utah.edu Subject: [bkph@ai.mit.edu: Standardization of TeX names for Adobe PostScript fonts.] Return-Path: From: bkph@ai.mit.edu (Berthold K.P. Horn) Date: Sat, 2 Mar 91 08:20:14 EST To: TeXhax@cs.washington.edu Cc: dhosek@ymir.claremont.edu, beebe@csc-sun.math.utah.edu, karl@cs.umd.edu Subject: Standardization of TeX names for Adobe PostScript fonts. re: Proposal for standardization of TeX names for Adobe PostScript fonts. Given below are the six character abbreviated file names used by Adobe for their outline fonts. It seems reasonable to simply adopt these short names when refering to Adobe PostScript fonts in TeX (which happens to be limited to six character font names). Need for standardization of names for Adobe fonts used in TeX seems to be the most urgent, since these are the fonts most frequently used (in fact, I have yet to see an author call for a font other than CM, LaTeX, AMS or Adobe). Using the vendor supplied abbreviation has clear advantages: (*) There is no need for a committee to dream up abbreviations for new fonts. (*) There is no need for a clearing house to approve proposed abbreviations. (*) There is no delay between publication of an outline font and availability of a standard abbreviated name for it. (*) The probability of confusion is reduced when only one short name needs to be remembered for a font (instead of the one used by the vendor AND one approved for use in TeX). There are two possible problems with my proposal: (.) Other vendors may use a particular abbreviation for different font. (.) The present scheme allows for only (26 + 10) * (26 * 10) = 1296 font families. Adobe already has about 770 / 4 = 193 font families. So in the distant future they are going to run out of two letter combinations. (.) In TeX there is sometimes a need to remap the encoding of the font. TFM files for the remapped versions must be distinguishable from the `raw' versions. The first problem can be fixed by prefixing these names with a code for the vendor - as suggested by Karl Berry - perhaps `p' for Adobe. The solution of the second problem is to simply adopt whatever scheme the vendor comes up with when that happens (and this won't happen for quite a few years anyway...). The third problem is less of an issue now that TeX can handle character sets with 256 characters. But in any case, a suffix can be added to the name (perhaps `x') to indicate remapping (although this does not tell one HOW the font has been remapped). This, along with the vendor prefix, brings the maximum length of a name to 8 characters, which almost all file systems now are able to deal with. Berthold K.P. Horn P.S. Thanks to Terry O'Donnell for help with generating this list. ========================= acb Aachen-Bold awab ACaslon-AltBold awabi ACaslon-AltBoldItalic awai ACaslon-AltItalic awarg ACaslon-AltRegular awasb ACaslon-AltSemibold awasi ACaslon-AltSemiboldItalic awb ACaslon-Bold awbi ACaslon-BoldItalic axb ACaslonExp-Bold axbi ACaslonExp-BoldItalic axi ACaslonExp-Italic axrg ACaslonExp-Regular axsb ACaslonExp-Semibold axsbi ACaslonExp-SemiboldItalic awi ACaslon-Italic awor ACaslon-Ornaments awrg ACaslon-Regular awsb ACaslon-Semibold awsbi ACaslon-SemiboldItalic awswb ACaslon-SwashBoldItalic awswi ACaslon-SwashItalic awssb ACaslon-SwashSemiboldItalic ggi AGaramondAlt-Italic ggrg AGaramondAlt-Regular gdb AGaramond-Bold gdbi AGaramond-BoldItalic geb AGaramondExp-Bold gebi AGaramondExp-BoldItalic gei AGaramondExp-Italic gerg AGaramondExp-Regular gesb AGaramondExp-Semibold gesbi AGaramondExp-SemiboldItalic gdi AGaramond-Italic gdrg AGaramond-Regular gdsb AGaramond-Semibold gdsbi AGaramond-SemiboldItalic gdttl AGaramond-Titling akbl AkzidenzGrotesk-Black akb AkzidenzGrotesk-Bold akl AkzidenzGrotesk-Light akr AkzidenzGrotesk-Roman amb Americana-Bold ameb Americana-ExtraBold ami Americana-Italic am Americana aqbl AntiqueOlive-Black aqb AntiqueOlive-Bold aqi AntiqueOlive-Italic aql AntiqueOlive-Light aqr AntiqueOlive-Roman aqbc AntiqueOlive-BoldCond aqct AntiqueOlive-Compact aqnr AntiqueOlive-Nord aqnri AntiqueOlive-NordItalic a Arcadia a AAA Arcadia-A ab ArnoldBoecklin ael Avenir-Light aelo Avenir-LightOblique aew Avenir-Book aewo Avenir-BookOblique aer Avenir-Roman aero Avenir-Oblique aem Avenir-Medium aemo Avenir-MediumOblique aeh Avenir-Heavy aeho Avenir-HeavyOblique aebl Avenir-Black aeblo Avenir-BlackOblique bc Banco bbb BauerBodoni-Bold bbbi BauerBodoni-BoldItalic bbbio BauerBodoni-BoldItalicOsF bbbof BauerBodoni-BoldOsF bbi BauerBodoni-Italic bbiof BauerBodoni-ItalicOsF bbr BauerBodoni-Roman bbrsc BauerBodoni-RomanSC bbbl BauerBodoni-Black bbblc BauerBodoni-BlackCond bbbli BauerBodoni-BlackItalic bbbc BauerBodoni-BoldCond bhb Bauhaus-Bold bhd Bauhaus-Demi bhh Bauhaus-Heavy bhl Bauhaus-Light bhm Bauhaus-Medium bwb Belwe-Bold bwc Belwe-Condensed bwl Belwe-Light bwm Belwe-Medium bmb Bembo-Bold bmbi Bembo-BoldItalic bmeb Bembo-ExtraBold bmebi Bembo-ExtraBoldItalic bmi Bembo-Italic bm Bembo bmsb Bembo-Semibold bmsbi Bembo-SemiboldItalic bgb Benguiat-Bold bgw Benguiat-Book bybl Berkeley-Black bybli Berkeley-BlackItalic byb Berkeley-Bold bybi Berkeley-BoldItalic byw Berkeley-Book bywi Berkeley-BookItalic byi Berkeley-Italic bym Berkeley-Medium bdb Bodoni-Bold bdbi Bodoni-BoldItalic bdi Bodoni-Italic bdps Bodoni-Poster bd Bodoni bdbc Bodoni-BoldCondensed bdw Bodoni-Book bdwi Bodoni-BookItalic bdpsc Bodoni-PosterCompressed bdpsi Bodoni-PosterItalic bkb Bookman-Bold bkbi Bookman-BoldItalic bkd Bookman-Demi bkdi Bookman-DemiItalic bkl Bookman-Light bkli Bookman-LightItalic bkm Bookman-Medium bkmi Bookman-MediumItalic j1515 BorderPi-OneFiveOneFiveNine bs BrushScript db1 BundesbahnPi-One db2 BundesbahnPi-Two db3 BundesbahnPi-Three cgb Candida-Bold cgi Candida-Italic cgr Candida-Roman cr Carta ck CascadeScript c2bl CaslonTwoTwentyFour-Black c2bli CaslonTwoTwentyFour-BlackIt c2b CaslonTwoTwentyFour-Bold c2bi CaslonTwoTwentyFour-BoldIt c2w CaslonTwoTwentyFour-Book c2wi CaslonTwoTwentyFour-BookIt c2m CaslonTwoTwentyFour-Medium c2mi CaslonTwoTwentyFour-MediumIt cti CaslonThree-Italic ctr CaslonThree-Roman cfi CaslonFiveForty-Italic cfr CaslonFiveForty-Roman ca CaslonOpenFace cxb Caxton-Bold cxbi Caxton-BoldItalic cxw Caxton-Book cxwi Caxton-BookItalic cxl Caxton-Light cxli Caxton-LightItalic cil Centennial-Light cili Centennial-LightItalic cir Centennial-Roman cii Centennial-Italic cib Centennial-Bold cibi Centennial-BoldItalic cibl Centennial-Black cibli Centennial-BlackItalic cyi CenturyExpanded-Italic cy CenturyExpanded csb CenturyOldStyle-Bold csi CenturyOldStyle-Italic csrg CenturyOldStyle-Regular czb Charlemagne-Bold czrg Charlemagne-Regular cu Charme cq Cheq clb Clarendon-Bold cll Clarendon-Light cl Clarendon cebl Clearface-Black cebli Clearface-BlackItalic ceb Clearface-Bold cebi Clearface-BoldItalic ceh Clearface-Heavy cehi Clearface-HeavyItalic cerg Clearface-Regular cergi Clearface-RegularItalic ccb Cochin-Bold ccbi Cochin-BoldItalic cci Cochin-Italic cc Cochin cjb Concorde-Bold cjbi Concorde-BoldItalic cji Concorde-Italic cjr Concorde-Roman cbi CooperBlack-Italic cb CooperBlack cp29a Copperplate-TwentyNineAB cp29c Copperplate-TwentyNineBC cp30a Copperplate-ThirtyAB cp30c Copperplate-ThirtyBC cp31a Copperplate-ThirtyOneAB cp31c Copperplate-ThirtyOneBC cp32a Copperplate-ThirtyTwoAB cp32c Copperplate-ThirtyTwoBC cp33c Copperplate-ThirtyThreeBC cnb Corona-Bold cni Corona-Italic cn Corona cob Courier-Bold cobo Courier-BoldOblique com Courier coo Courier-Oblique cob Courier-Bold cobo Courier-BoldOblique com Courier coo Courier-Oblique dinen DINEngschrift dinmi DINMittelschrift dngbc DINNeuzeitGrotesk-BoldCond dngl DINNeuzeitGrotesk-Light dcb DomCasual-Bold dc DomCasual drb Doric-Bold du DucDeBerry dudfr DucDeBerry-Dfr erb ItcEras-Bold erbk ItcEras-Book erd ItcEras-Demi erl ItcEras-Light erm ItcEras-Medium eru ItcEras-Ultra euro1 EuropeanPi-One euro2 EuropeanPi-Two euro3 EuropeanPi-Three euro4 EuropeanPi-Four eub Eurostile-Bold eubo Eurostile-BoldOblique eud Eurostile-Demi eudo Eurostile-DemiOblique eu Eurostile euo Eurostile-Oblique eubc Eurostile-BoldCondensed eubex Eurostile-BoldExtendedTwo euc Eurostile-Condensed euex Eurostile-ExtendedTwo exb Excelsior-Bold exi Excelsior-Italic ex Excelsior ff FetteFraktur flblc Flyer-BlackCondensed flebc Flyer-ExtraBlackCondensed fob Folio-Bold fobc Folio-BoldCondensed foeb Folio-ExtraBold fol Folio-Light fom Folio-Medium frw FranklinGothic-Book frwo FranklinGothic-BookOblique frd FranklinGothic-Demi frdo FranklinGothic-DemiOblique frh FranklinGothic-Heavy frho FranklinGothic-HeavyOblique fgc FranklinGothic-Condensed fgec FranklinGothic-ExtraCond fgr FranklinGothic-Roman fs FreestyleScript fqb FrizQuadrata-Bold fq FrizQuadrata ftl Frutiger-Light ftli Frutiger-LightItalic ftr Frutiger-Roman fti Frutiger-Italic ftb Frutiger-Bold ftbi Frutiger-BoldItalic ftbl Frutiger-Black ftbli Frutiger-BlackItalic ftubl Frutiger-UltraBlack fub Futura-Bold fubo Futura-BoldOblique fuw Futura-Book fuwo Futura-BookOblique fuc Futura-Condensed fucb Futura-CondensedBold fucbo Futura-CondensedBoldOblique fuceb Futura-CondensedExtraBold fcebo Futura-CondExtraBoldObl fucl Futura-CondensedLight fuclo Futura-CondensedLightOblique fuco Futura-CondensedOblique fueb Futura-ExtraBold fuebo Futura-ExtraBoldOblique fuh Futura-Heavy fuho Futura-HeavyOblique ful Futura-Light fulo Futura-LightOblique fu Futura fuo Futura-Oblique gmb GaramondThree-Bold gmbi GaramondThree-BoldItalic gmbio GaramondThree-BoldItalicOsF gmbsc GaramondThree-BoldSC gmi GaramondThree-Italic gmio GaramondThree-ItalicOsF gm GaramondThree gmsc GaramondThree-SC ghz GarthGraphic-Black ghb GarthGraphic-Bold ghbc GarthGraphic-BoldCondensed ghbi GarthGraphic-BoldItalic ghc GarthGraphic-Condensed gheb GarthGraphic-ExtraBold ghi GarthGraphic-Italic gh GarthGraphic gnb GillSans-Bold gnbc GillSans-BoldCondensed gnbi GillSans-BoldItalic gnc GillSans-Condensed gneb GillSans-ExtraBold gni GillSans-Italic gnl GillSans-Light gnli GillSans-LightItalic gn GillSans gnub GillSans-UltraBold gnubc GillSans-UltraBoldCondensed gyb Glypha-Bold gybo Glypha-BoldOblique gyo Glypha-Oblique gy Glypha gyt Glypha-Thin gyto Glypha-ThinOblique gyl Glypha-Light gylo Glypha-LightOblique gybl Glypha-Black gyblo Glypha-BlackOblique gtt Gothic-Thirteen gob Goudy-Bold gobi Goudy-BoldItalic goi Goudy-Italic go Goudy goeb Goudy-ExtraBold goh Goudy-Heavyface gohi Goudy-HeavyfaceItalic grb Granjon-Bold gri Granjon-Italic gr Granjon hvbl Helvetica-Black hvblo Helvetica-BlackOblique hvb Helvetica-Bold hvbo Helvetica-BoldOblique hvk Helvetica-Compressed hvc Helvetica-Condensed hvcbl Helvetica-Condensed-Black hvco Helvetica-Condensed-BlackObl hvcb Helvetica-Condensed-Bold hvcbo Helvetica-Condensed-BoldObl hvcl Helvetica-Condensed-Light hvclo Helvetica-Condensed-LightObl hvcdo Helvetica-Condensed-Oblique hvek Helvetica-ExtraCompressed hvl Helvetica-Light hvlo Helvetica-LightOblique hv Helvetica hvn Helvetica-Narrow hvnb Helvetica-Narrow-Bold hvnbo Helvetica-Narrow-BoldOblique hvno Helvetica-Narrow-Oblique hvo Helvetica-Oblique hvuk Helvetica-UltraCompressed hir HelveticaInserat-Roman hlj HelveticaNeue-ExtBlackCond hljo HelveticaNeue-ExtBlackCondObl hlav HelveticaNeue-UltraLigExt hlavo HelveticaNeue-UltraLigExtObl hlul HelveticaNeue-UltraLight hluli HelveticaNeue-UltraLightItal hla HelveticaNeue-UltraLigCond hlao HelveticaNeue-UltraLigCondObl hltv HelveticaNeue-ThinExt hltvo HelveticaNeue-ThinExtObl hlt HelveticaNeue-Thin hlti HelveticaNeue-ThinItalic hltc HelveticaNeue-ThinCond hltco HelveticaNeue-ThinCondObl hllv HelveticaNeue-LightExt hllvo HelveticaNeue-LightExtObl hll HelveticaNeue-Light hlli HelveticaNeue-LightItalic hllc HelveticaNeue-LightCond hllco HelveticaNeue-LightCondObl hlv HelveticaNeue-Extended hlvo HelveticaNeue-ExtendedObl hlr HelveticaNeue-Roman hli HelveticaNeue-Italic hlc HelveticaNeue-Condensed hlco HelveticaNeue-CondensedObl hlmv HelveticaNeue-MediumExt hlmvo HelveticaNeue-MediumExtObl hlm HelveticaNeue-Medium hlmi HelveticaNeue-MediumItalic hlmc HelveticaNeue-MediumCond hlmco HelveticaNeue-MediumCondObl hlbv HelveticaNeue-BoldExt hlbvo HelveticaNeue-BoldExtObl hlb HelveticaNeue-Bold hlbi HelveticaNeue-BoldItalic hlbc HelveticaNeue-BoldCond hlbco HelveticaNeue-BoldCondObl hlhv HelveticaNeue-HeavyExt hlhvo HelveticaNeue-HeavyExtObl hlh HelveticaNeue-Heavy hlhi HelveticaNeue-HeavyItalic hlhc HelveticaNeue-HeavyCond hlhco HelveticaNeue-HeavyCondObl hlzv HelveticaNeue-BlackExt hlzvo HelveticaNeue-BlackExtObl hlbl HelveticaNeue-Black hlbli HelveticaNeue-BlackItalic hlzc HelveticaNeue-BlackCond hlzco HelveticaNeue-BlackCondObl hebl HelveticaRounded-Black heblo HelveticaRounded-BlackObl heb HelveticaRounded-Bold hebc HelveticaRounded-BoldCond hebco HelveticaRounded-BoldCondObl hebo HelveticaRounded-BoldObl herc Herculanum hrbl Hiroshige-Black hrbli Hiroshige-BlackItalic hrb Hiroshige-Bold hrbi Hiroshige-BoldItalic hrw Hiroshige-Book hrwi Hiroshige-BookItalic hrm Hiroshige-Medium hrmi Hiroshige-MediumItalic ho Hobo atb AmericanTypewriter-Bold atm AmericanTypewriter-Medium agw AvantGarde-Book agwo AvantGarde-BookOblique agcb AvantGarde-CondBold agcw AvantGarde-CondBook agcd AvantGarde-CondDemi agcm AvantGarde-CondMedium agd AvantGarde-Demi agdo AvantGarde-DemiOblique beb BenguiatGothic-Bold bebo BenguiatGothic-BoldOblique bew BenguiatGothic-Book bewo BenguiatGothic-BookOblique beh BenguiatGothic-Heavy beho BenguiatGothic-HeavyOblique bem BenguiatGothic-Medium bemo BenguiatGothic-MediumOblique icb Century-Bold icbci Century-BoldCondensedItalic icbc Century-BoldCondensed icbi Century-BoldItalic icw Century-Book icwci Century-BookCondensedItalic icwc Century-BookCondensed icwi Century-BookItalic icl Century-Light iclci Century-LightCondensedItalic iclc Century-LightCondensed icli Century-LightItalic icu Century-Ultra icuci Century-UltraCondensedItalic icuc Century-UltraCondensed icui Century-UltraItalic chb Cheltenham-Bold chbc Cheltenham-BoldCond chbci Cheltenham-BoldCondItalic chbi Cheltenham-BoldItalic chw Cheltenham-Book chwc Cheltenham-BookCond chwci Cheltenham-BookCondItalic chwi Cheltenham-BookItalic chl Cheltenham-Light chlc Cheltenham-LightCond chlci Cheltenham-LightCondItalic chli Cheltenham-LightItalic chu Cheltenham-Ultra chuc Cheltenham-UltraCond chuci Cheltenham-UltraCondItalic chui Cheltenham-UltraItalic iub Cushing-Bold iubi Cushing-BoldItalic iuw Cushing-Book iuwi Cushing-BookItalic iuh Cushing-Heavy iuhi Cushing-HeavyItalic ium Cushing-Medium iumi Cushing-MediumItalic feb Fenice-Bold febo Fenice-BoldOblique fel Fenice-Light felo Fenice-LightOblique ferg Fenice-Regular fergo Fenice-RegularOblique feu Fenice-Ultra feuo Fenice-UltraOblique glbl Galliard-Black glbli Galliard-BlackItalic glb Galliard-Bold glbi Galliard-BoldItalic gli Galliard-Italic glr Galliard-Roman glu Galliard-Ultra glui Galliard-UltraItalic gab Garamond-Bold gabc Garamond-BoldCondensed gabci Garamond-BoldCondensedItalic gabi Garamond-BoldItalic gaw Garamond-Book gawc Garamond-BookCondensed gawci Garamond-BookCondensedItalic gawi Garamond-BookItalic gal Garamond-Light galc Garamond-LightCondensed galci Garamond-LightCondensedItalic gali Garamond-LightItalic gau Garamond-Ultra gauc Garamond-UltraCondensed gauci Garamond-UltraCondensedItalic gaui Garamond-UltraItalic mab Machine-Bold ma Machine nbb NewBaskerville-Bold nbbi NewBaskerville-BoldItalic nbi NewBaskerville-Italic nbr NewBaskerville-Roman isbl ItcSymbol-Black isbli ItcSymbol-BlackItalic isb ItcSymbol-Bold isbi ItcSymbol-BoldItalic isw ItcSymbol-Book iswi ItcSymbol-BookItalic ism ItcSymbol-Medium ismi ItcSymbol-MediumItalic usbl Usherwood-Black usbli Usherwood-BlackItalic usb Usherwood-Bold usbi Usherwood-BoldItalic usw Usherwood-Book uswi Usherwood-BookItalic usm Usherwood-Medium usmi Usherwood-MediumItalic zcb ZapfChancery-Bold zcd ZapfChancery-Demi zci ZapfChancery-Italic zcl ZapfChancery-Light zcli ZapfChancery-LightItalic zcr ZapfChancery-Roman imb Impressum-Bold imi Impressum-Italic imr Impressum-Roman inin Industria-Inline inina Industria-InlineA insd Industria-Solid insda Industria-SolidA ins Insignia insa Insignia-A itb Italia-Bold itw Italia-Book itm Italia-Medium jtb JansonText-Bold jtbi JansonText-BoldItalic jtbio JansonText-BoldItalicOsF jtbof JansonText-BoldOsF jti JansonText-Italic jtiof JansonText-ItalicOsF jtr JansonText-Roman jtrsc JansonText-RomanSC kbb ItcKabel-Bold kbw ItcKabel-Book kbd ItcKabel-Demi kbm ItcKabel-Medium kbu ItcKabel-Ultra kfb Kaufmann-Bold kf Kaufmann krb Korinna-Bold krkb Korinna-KursivBold krkx Korinna-KursivRegular krrg Korinna-Regular ktbl KuenstlerScript-Black ktm KuenstlerScript-Medium kt2b KuenstlerScript-TwoBold lwbl Leawood-Black lwbli Leawood-BlackItalic lwb Leawood-Bold lwbi Leawood-BoldItalic lww Leawood-Book lwwi Leawood-BookItalic lwm Leawood-Medium lwmi Leawood-MediumItalic lgb LetterGothic-Bold lgbsl LetterGothic-BoldSlanted lg LetterGothic lgsl LetterGothic-Slanted lib Life-Bold lii Life-Italic lir Life-Roman lp Linoscript lx Linotext lobl Lithos-Black lob Lithos-Bold loel Lithos-ExtraLight lol Lithos-Light lorg Lithos-Regular luw LubalinGraph-Book luwo LubalinGraph-BookOblique lud LubalinGraph-Demi ludo LubalinGraph-DemiOblique lcb Lucida-Bold lcbi Lucida-BoldItalic lci Lucida-Italic lc Lucida lme LucidaMath-Extension lmi LucidaMath-Italic lms LucidaMath-Symbol lsb LucidaSans-Bold lsbi LucidaSans-BoldItalic lsi LucidaSans-Italic ls LucidaSans mi MICR mh1 MathematicalPi-One mh2 MathematicalPi-Two mh3 MathematicalPi-Three mh4 MathematicalPi-Four mh5 MathematicalPi-Five mh6 MathematicalPi-Six mx Maximus mc MediciScript meb Melior-Bold mebi Melior-BoldItalic mei Melior-Italic me Melior mpb Memphis-Bold mpbi Memphis-BoldItalic mpeb Memphis-ExtraBold mpl Memphis-Light mpli Memphis-LightItalic mpm Memphis-Medium mpmi Memphis-MediumItalic m0b Meridien-Bold m0bi Meridien-BoldItalic m0i Meridien-Italic m0m Meridien-Medium m0mi Meridien-MediumItalic m0r Meridien-Roman mobl Minion-Black mob Minion-Bold mobi Minion-BoldItalic modsi Minion-DisplayItalic mods Minion-DisplayRegular mjbl MinionExp-Black mjb MinionExp-Bold mjbi MinionExp-BoldItalic mjdsi MinionExp-DisplayItalic mjds MinionExp-DisplayRegular mji MinionExp-Italic mjrg MinionExp-Regular mjsb MinionExp-Semibold mjsbi MinionExp-SemiboldItalic moi Minion-Italic moor Minion-Ornaments morg Minion-Regular mosb Minion-Semibold mosbi Minion-SemiboldItalic mosdi Minion-SwashDisplayItalic moswi Minion-SwashItalic mossb Minion-SwashSemiboldItalic mzbl Minister-Black mzbli Minister-BlackItalic mzb Minister-Bold mzbi Minister-BoldItalic mzw Minister-Book mzwi Minister-BookItalic mzl Minister-Light mzli Minister-LightItalic ms Mistral so Sonata new NeuzeitS-Book newh NeuzeitS-BookHeavy nabl NewAster-Black nabli NewAster-BlackItalic nab NewAster-Bold nabi NewAster-BoldItalic nai NewAster-Italic na NewAster nas NewAster-SemiBold nasi NewAster-SemiBoldItalic nlbl NewCaledonia-Black nlbli NewCaledonia-BlackItalic nlb NewCaledonia-Bold nlbi NewCaledonia-BoldItalic nli NewCaledonia-Italic nl NewCaledonia nls NewCaledonia-SemiBold nlsi NewCaledonia-SemiBoldItalic ncb NewCenturySchlbk-Bold ncbi NewCenturySchlbk-BoldItalic nci NewCenturySchlbk-Italic ncr NewCenturySchlbk-Roman ngb NewsGothic-Bold ngbo NewsGothic-BoldOblique ngo NewsGothic-Oblique ng NewsGothic nob Novarese-Bold nobi Novarese-BoldItalic now Novarese-Book nowi Novarese-BookItalic nom Novarese-Medium nomi Novarese-MediumItalic nou Novarese-Ultra nu NuptialScript oa OCRA ob OCRB olb Olympian-Bold olbi Olympian-BoldItalic oli Olympian-Italic ol Olympian omni Omnia opb Optima-Bold opbo Optima-BoldOblique opo Optima-Oblique op Optima or Orator orsl Orator-Slanted pob Palatino-Bold pobi Palatino-BoldItalic poi Palatino-Italic por Palatino-Roman pn Parisian pa ParkAvenue pgb Peignot-Bold pgd Peignot-Demi pgl Peignot-Light psb PostAntiqua-Bold psr PostAntiqua-Roman pr Present peb PrestigeElite-Bold pebsl PrestigeElite-BoldSlanted pe PrestigeElite pesl PrestigeElite-Slanted qobl Quorum-Black qob Quorum-Bold qow Quorum-Book qol Quorum-Light qom Quorum-Medium rab Raleigh-Bold rad Raleigh-DemiBold ram Raleigh-Medium ra Raleigh rp Reporter-Two re Revue rkb Rockwell-Bold rkbc Rockwell-BoldCondensed rkbi Rockwell-BoldItalic rkc Rockwell-Condensed rkeb Rockwell-ExtraBold rki Rockwell-Italic rkl Rockwell-Light rkli Rockwell-LightItalic rk Rockwell rbl RotisSansSerif-Light rbli RotisSansSerif-LightItalic rb RotisSansSerif rbi RotisSansSerif-Italic rbb RotisSansSerif-Bold rbeb RotisSansSerif-ExtraBold rcl RotisSemiSans-Light rcli RotisSemiSans-LightItalic rc RotisSemiSans rci RotisSemiSans-Italic rcb RotisSemiSans-Bold rceb RotisSemiSans-ExtraBold rf RotisSemiSerif rfb RotisSemiSerif-Bold rg RotisSerif rgi RotisSerif-Italic rgb RotisSerif-Bold ruo RussellSquare-Oblique ru RussellSquare sab Sabon-Bold sabi Sabon-BoldItalic sabio Sabon-BoldItalicOsF sabof Sabon-BoldOsF sai Sabon-Italic saiof Sabon-ItalicOsF sar Sabon-Roman sarsc Sabon-RomanSC sass Sassoon-Primary sgbl SerifGothic-Black sgb SerifGothic-Bold sgeb SerifGothic-ExtraBold sgh SerifGothic-Heavy sgl SerifGothic-Light sg SerifGothic sebl Serifa-Black seb Serifa-Bold sei Serifa-Italic sel Serifa-Light seli Serifa-LightItalic ser Serifa-Roman sfb Serpentine-Bold sfbo Serpentine-BoldOblique sfl Serpentine-Light sflo Serpentine-LightOblique sfm Serpentine-Medium sfmo Serpentine-MediumOblique sbb Shannon-Bold sbw Shannon-Book sbeb Shannon-ExtraBold sbo Shannon-Oblique shal Shelley-AllegroScript shan Shelley-AndanteScript shvo Shelley-VolanteScript gib SimonciniGaramond-Bold gii SimonciniGaramond-Italic gir SimonciniGaramond snbl SnellRoundhand-BlackScript snb SnellRoundhand-BoldScript sn SnellRoundhand-Script sud Souvenir-Demi sudi Souvenir-DemiItalic sul Souvenir-Light suli Souvenir-LightItalic sub Souvenir-Bold subi Souvenir-BoldItalic sum Souvenir-Medium sumi Souvenir-MediumItalic sqwcl Spartan-BookClassified sqhcl Spartan-HeavyClassified gsb StempelGaramond-Bold gsbi StempelGaramond-BoldItalic gsi StempelGaramond-Italic gsr StempelGaramond-Roman skbl StempelSchneidler-Black skbli StempelSchneidler-BlackItalic skb StempelSchneidler-Bold skbi StempelSchneidler-BoldItalic ski StempelSchneidler-Italic skl StempelSchneidler-Light skli StempelSchneidler-LightItalic skm StempelSchneidler-Medium skmi StempelSchneidler-MedItalic skr StempelSchneidler-Roman st Stencil sib StoneInformal-Bold sibi StoneInformal-BoldItalic sii StoneInformal-Italic si StoneInformal sisb StoneInformal-Semibold sisbi StoneInformal-SemiboldItalic ssb StoneSans-Bold ssbi StoneSans-BoldItalic ssi StoneSans-Italic ss StoneSans sssb StoneSans-Semibold sssbi StoneSans-SemiboldItalic srb StoneSerif-Bold srbi StoneSerif-BoldItalic sri StoneSerif-Italic sr StoneSerif srsb StoneSerif-Semibold srsbi StoneSerif-SemiboldItalic sy Symbol sxbl Syntax-Black sxb Syntax-Bold sxi Syntax-Italic sxr Syntax-Roman sxubl Syntax-UltraBlack tkb Tekton-Bold tkbo Tekton-BoldOblique tko Tekton-Oblique tkrg Tekton tehc Tempo-HeavyCondensed tehci Tempo-HeavyCondensedItalic tfd Tiffany-Demi tfdi Tiffany-DemiItalic tfh Tiffany-Heavy tfhi Tiffany-HeavyItalic tfi Tiffany-Italic tf Tiffany tib Times-Bold tibi Times-BoldItalic tibio Times-BoldItalicOsF tibsc Times-BoldSC tieb Times-ExtraBold tii Times-Italic tiio Times-ItalicOsF tir Times-Roman tirsc Times-RomanSC tisb Times-Semibold tisbi Times-SemiboldItalic mtb TimesNewRomanPS-Bold mtbi TimesNewRomanPS-BoldItalic mti TimesNewRomanPS-Italic mtr TimesNewRomanPS ttb TimesTen-Bold ttbi TimesTen-BoldItalic ttbio TimesTen-BoldItalicOsF ttbof TimesTen-BoldOsF tti TimesTen-Italic ttiof TimesTen-ItalicOsF ttr TimesTen-Roman ttrsc TimesTen-RomanSC tgb TradeGothic-Bold tgb2 TradeGothic-BoldTwo tgb2o TradeGothic-BoldTwoOblique tgbo TradeGothic-BoldOblique tgl TradeGothic-Light tglo TradeGothic-LightOblique tgo TradeGothic-Oblique tg TradeGothic tgbc TradeGothic-BoldCondTwenty tgbco TradeGothic-BoldCondTwentyObl tgc TradeGothic-CondEighteen tgco TradeGothic-CondEighteenObl tjb Trajan-Bold tjrg Trajan-Regular tmb TrumpMediaeval-Bold tmbi TrumpMediaeval-BoldItalic tmi TrumpMediaeval-Italic tmr TrumpMediaeval-Roman um Umbra uvtuc Univers-ThinUltraCondensed uvluc Univers-LightUltraCondensed uvv Univers-Extended uvvo Univers-ExtendedObl uvuc Univers-UltraCondensed uvbv Univers-BoldExt uvbvo Univers-BoldExtObl uvzv Univers-BlackExt uvzvo Univers-BlackExtObl uvf Univers-ExtraBlack uvfo Univers-ExtraBlackObl uvfv Univers-ExtraBlackExt uvfvo Univers-ExtraBlackExtObl uvbl Univers-Black uvblo Univers-BlackOblique uvb Univers-Bold uvbo Univers-BoldOblique uvc Univers-Condensed uvcb Univers-CondensedBold uvcbo Univers-CondensedBoldOblique uvcl Univers-CondensedLight uvclo Univers-CondensedLightOblique uvcdo Univers-CondensedOblique uvl Univers-Light uvlo Univers-LightOblique uv Univers uvo Univers-Oblique unvmg Universal-GreekwithMathPi unvnc Universal-NewswithCommPi ur UniversityRoman utbl Utopia-Black utb Utopia-Bold utbi Utopia-BoldItalic uebl UtopiaExp-Black ueb UtopiaExp-Bold uebi UtopiaExp-BoldItalic uei UtopiaExp-Italic uerg UtopiaExp-Regular uesb UtopiaExp-Semibold uesbi UtopiaExp-SemiboldItalic uti Utopia-Italic utor Utopia-Ornaments utrg Utopia-Regular utsb Utopia-Semibold utsbi Utopia-SemiboldItalic utttl Utopia-Titling vrbl VAGRounded-Black vrb VAGRounded-Bold vrl VAGRounded-Light vrt VAGRounded-Thin vel Versailles-Light veli Versailles-LightItalic ver Versailles-Roman vei Versailles-Italic veb Versailles-Bold vebi Versailles-BoldItalic vebl Versailles-Black vebli Versailles-BlackItalic wab Walbaum-Bold wabi Walbaum-BoldItalic wabio Walbaum-BoldItalicOsF wabof Walbaum-BoldOsF wai Walbaum-Italic waiof Walbaum-ItalicOsF war Walbaum-Roman warsc Walbaum-RomanSC wdbl Weidemann-Black wdbli Weidemann-BlackItalic wdb Weidemann-Bold wdbi Weidemann-BoldItalic wdw Weidemann-Book wdwi Weidemann-BookItalic wdm Weidemann-Medium wdmi Weidemann-MediumItalic web Weiss-Bold weeb Weiss-ExtraBold wei Weiss-Italic we Weiss wk WilhelmKlingsporGotisch wkdfr WilhelmKlingsporGotisch-Dfr c Cottonwood i Ironwood j Juniper m Mesquite woor WoodtypeOrnaments-One p Ponderosa bi Birch bo Blackoak mq Madrone woor2 WoodtypeOrnaments-Two pp Poplar wi Willow zcmi ZapfChancery-MediumItalic zd ZapfDingbats 3-Mar-1991 18:42:46-GMT,1104;000000000001 Return-Path: Received: from CBROWN.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02278; Sun, 3 Mar 91 11:42:43 MST Date: Sun, 3 Mar 1991 10:42 PST From: Don Hosek Subject: Re: [bkph@ai.mit.edu: Standardization of TeX names for Adobe PostScript fonts.] To: bkph@ai.mit.edu Cc: tex-fonts@math.utah.edu Message-Id: X-Envelope-To: tex-fonts@math.utah.edu X-Vms-To: IN%"bkph@ai.mit.edu" X-Vms-Cc: IN%"tex-fonts@math.utah.edu" I no longer have my reply to Berthold's first posting of this note (which was sent to myself, Karl Berry, Nelson Beebe and TeXhax, I believe). In short, I pointed out some shortcomings with using vendor-supplied names, pointed out that there is little difference in the information content between his scheme and Karl Berry's, but his scheme will hit shortcomings much sooner than Karl's. If one of the recipients of my reply is willing to send a copy to tex-fonts, I'd appreciate it; otherwise, I guess you'll have to wait for it to show up in TeXhax. -dh 5-Mar-1991 16:27:55-GMT,2340;000000000001 Return-Path: Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA16318; Tue, 5 Mar 91 09:27:45 MST Date: Tue 5 Mar 91 11:29:35-EST From: bbeeton Subject: Re: Standardization of TeX names for Adobe PostScript fonts. To: XITIJSCH@DDATHD21.BITNET Cc: tex-fonts@math.utah.edu Message-Id: <668190575.0.BNB@MATH.AMS.COM> In-Reply-To: <4E53DB371E201FBD@CC.UTAH.EDU> Mail-System-Version: the original tex on the dec-10 had the 6-character limit. the sail computer at stanford ran under waits, but i believe the limit was the same in tops-10. it was never a limit in tops-20, which allowed file names of >30 characters (though i believe early versions were more efficient if names were unique in the first some small number, perhaps 6). i believe there is still one dec-10 in use with tex in germany; i am not aware of any others. by the way, the algorithm for deriving 6-character names was not to take the first 6 characters, but the first 3 and the last 3. that is the reason that cm bold math italic is named cmmib* and not cmbmi*, which would have been the more obvious choice. the latex fonts do reduce satisfactorily to 6 characters with this technique. bart childs once informed me that the limit on length of file names was even more restrictive on the cray, perhaps 5; he was reduced to using a code for the size -- a for 10, b for 11, etc., with unlikely numbers omitted as the size increased. (i can check on this, if anyone is interested.) it's true that the only real reason to use a cray for tex is if you already happen to be using it for all of your other work, and that is the basis on which bart said it was actually being used at los alamos. under those circumstances, it's highly unlikely that anyone will install a typesetter or probably even a competent postscript system on that machine, and that particular restriction can then be ignored. the 8-character limit, on the other hand, is ubiquitous on personal computers, and must therefore be accommodated in some reasonable way. there is also, of course, the problem of flat file systems on ibm mainframes and perhaps other machines. i wouldn't like to see any "solution" adopted that excluded that part of the tex community. -- bb ------- 5-Mar-1991 17:32:56-GMT,1866;000000000001 Return-Path: Received: from CC.UTAH.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA16878; Tue, 5 Mar 91 10:32:52 MST Received: from DDATHD21.BITNET (XITIJSCH@DDATHD21) by CC.UTAH.EDU with PMDF#10043; Tue, 5 Mar 1991 10:32 MST Received: from PCSITI.FB20.THD.DA.EUROPE by DDATHD21.BITNET via GNET with RJE with RCOM ; 05 Mar 91 18:24:04 Date: Tue, 5 Mar 91 18:18:03 MEZ From: XITIJSCH@DDATHD21.BITNET Subject: Re: Standardization of TeX names for Adobe PostScript fonts. To: tex-fonts@math.utah.edu Message-Id: <5DD090F95620213A@CC.UTAH.EDU> X-Envelope-To: tex-fonts@math.utah.edu X-Originally-From: Joachim Schrod X-Munix-To: tex-fonts@math.utah.edu (TeX fonts discussion) X-Mailer: ELM [version 2.3 PL0] Reading Jan's mail I realize that I should be more careful what I write: > Joachim Schrod writes: > > BTW, what operating systems besides TOPS-20 have file name > > restrictions of 6 characters? > > Most others I know of may have names with 8 characters. > > TOPS-20 file names are 39+39 characters. TOPS-10 and WAITS file > names are 6+3 characters. TeX was developed on a WAITS machine. > BSD UNIX, VMS, and Macintosh have file names which can be a lot > longer than 8 characters. Thanks for the hint to the typo, I meant TOPS-10. With my last sentence I wanted to point out that we must regard this limit (names 8+3 chars long) anyhow, the bulk of DOS users force us to do this. I just wanted to ask if we are able to cut ourselves to 8 chars or if we even must consider the 6 chars limit. That there are a lot of other systems which may have longer names (or links, or symbolic links, or additional file entries, ...) is well known to all of us, I think. (I have to manage TeX systems on seven really different operating systems at our campus :-) Joachim 5-Mar-1991 18:30:49-GMT,1698;000000000001 Received: from VAX01.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA17388; Tue, 5 Mar 91 11:30:42 MST Resent-Message-Id: <9103051830.AA17388@math.utah.edu> Return-Path: Date: Tue 5 Mar 91 13:26:15-EST From: bbeeton Subject: font meeting at cuny To: wg8_fontwork@decwrl.dec.com, fonts@math.utah.edu Message-Id: <668197575.0.BNB@MATH.AMS.COM> Mail-System-Version: Resent-Date: Tue 5 Mar 91 13:34:41-EST Resent-From: bbeeton Resent-To: tex-fonts@math.utah.edu this announcement was just brought to my attention by a correspondent at cuny, and i thought you might be interested in the topic, even if it's not possible for any of you to attend. -- bb --------------- Date: Tue, 05 Mar 1991 11:18:23 EST From: Dimitri Vulis To: bnb@math.ams.com Subject: FYI Date: Mon, 04 Mar 91 12:44:22 PST From: "Bur Davis" To: DLV%CUNYVMS1.BITNET@CUNYVM.CUNY.EDU Subject: Font Meeting at CUNY On 25 March 1991, at CUNY Graduate Center (33 West 42d Street, Room 1700), representatives from Adobe, Microsoft, Linotype, Afga- Compugraphic, Monotype and Bitstream will sit on a panel and discuss the Type1 and TrueType font technologies. A fellow named Doug Evans (212-481-9363) is coordinating the meeting. The representatives will (tentatively) be: Dr. Eliyezer Kohen, Microsoft; Dan Mills, Adobe; Bruce Brenner, Linotype; Cynthia Hollandsworth, Agfa-Compugraphic; Jeff Level, Monotype, Louise Domenitz, Bitstream. Thought I'd let you know since you live (or at least study) in the neighborhood. ....... Bur ------- 6-Mar-1991 11:59:55-GMT,1647;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA23595; Wed, 6 Mar 91 04:59:51 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA12322; Wed, 6 Mar 91 06:41:09 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA21655; Wed, 6 Mar 91 06:57:51 EST Date: Wed, 6 Mar 91 06:57:51 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9103061157.AA21655@ra.cs.umb.edu> To: tex-fonts@math.utah.edu Subject: 8+3 char. limit on font names Don, You're right that a fontname mapping file has disadvantages. But 8 characters is not nearly enough. If the PostScript fonts were design-sized properly, many of their names (according to my scheme) would be longer than 8 characters, and it's not hard to imagine them getting longer. I don't think it's possible to compress more information into a rational scheme than what mine does, and mine is not enough. I sent a revised article to TUGboat with all the new abbreviations, and some discussion of the problems that have cropped up. It's also on ftp.cs.umb.edu [192.12.26.23] in pub/tex/fontname (or did I already post this to this list? I've forgotten). The main advantage to mapping, I think, is that then documents are more likely to be portable across sites, despite the different naming conventions at different places. Of course, this will only be true if everyone is using the mapping file! By the way, I asked Knuth if a TeX that did do fontname mapping could still be called TeX (in a letter also expressing my appreciation for 3:16, a book I recommend to you all, if you haven't seen it!). No answer yet. karl@cs.umb.edu 6-Mar-1991 19:53:41-GMT,1606;000000000001 Return-Path: Received: from life.ai.mit.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA25801; Wed, 6 Mar 91 12:53:37 MST Received: from wheat-chex (wheat-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA23683; Wed, 6 Mar 91 14:53:29 EST From: bkph@ai.mit.edu (Berthold K.P. Horn) Received: by wheat-chex (4.1/AI-4.10) id AA03035; Wed, 6 Mar 91 14:53:25 EST Date: Wed, 6 Mar 91 14:53:25 EST Message-Id: <9103061953.AA03035@wheat-chex> To: karl@cs.umd.edu To: dhosek@hmcvax.claremont.edu To: beebe@csc-sun.math.utah.edu Subject: ...while we were discussing font names... Hi: I don't know if you happened to notice, but the list I sent had over 1000 entries, up from 770 when I last sent a message ont his matter. This illustrates one of the problems with `growing your own' names. P.S. I didn't mean to belittle other font sources when I mentioned that generally Adobe fonts are what author's call for. Just an empirical observation of actual DVI files submitted. It does seem reasonable to use some scheme for identifying the foundry. In my experience there is actually rarely a problem with mismatch in metrics, which are usually slavishly copied, but actual character outlines, particularly for `special' non-alphanumeric charcters. For example, BitStream Times-Roman has identical font metrics to Adobe's Times-Roman, and the outlines for alphanumeric characters are virtually identical (except for the distinctive swash on Adobe's Q), but the outlines for non-alphabetic characters are quite different (possibly for some complex copyright related reason). 7-Mar-1991 16:02:04-GMT,734;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA01809; Thu, 7 Mar 91 09:01:59 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA16502; Thu, 7 Mar 91 10:43:17 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA14208; Thu, 7 Mar 91 10:59:54 EST Date: Thu, 7 Mar 91 10:59:54 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9103071559.AA14208@ra.cs.umb.edu> To: tex-fonts@math.utah.edu Subject: Metafont modes Reply-To: karl@cs.umb.edu I've put a new copy of modes.mf (all extant Metafont modes) on ftp.cs.umb.edu [192.12.26.23] in pub/tex/modes.mf, and posted an announcement to texhax and comp.text.tex. Please send along additional ones! karl@cs.umb.edu 8-Mar-1991 12:39:58-GMT,1057;000000000001 Return-Path: Received: from life.ai.mit.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA08032; Fri, 8 Mar 91 05:39:51 MST Received: from wheat-chex (wheat-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA23047; Fri, 8 Mar 91 07:39:41 EST From: bkph@ai.mit.edu (Berthold K.P. Horn) Received: by wheat-chex (4.1/AI-4.10) id AA06109; Fri, 8 Mar 91 07:39:39 EST Date: Fri, 8 Mar 91 07:39:39 EST Message-Id: <9103081239.AA06109@wheat-chex> To: tex-fonts@math.utah.edu Subject: incompatible metrics Hi: I am looking for a documented example where two vendors supply fonts with the same name but different metrics. Generally I have found that some character may be different in fonts from different vendors, but that the character escapements are the same. Are there exceptions? (Actually, frequently even the shapes tend to be very similar for popular fonts - except for non-alphanumeric characters and special flourishes that foundries add to a single character to make their version identifiably different from others). 8-Mar-1991 16:31:06-GMT,3213;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA08891; Fri, 8 Mar 91 09:31:00 MST Date: Fri 8 Mar 91 11:34:35-EST From: bbeeton Subject: Re: incompatible metrics To: bkph@ai.mit.edu Cc: tex-fonts@math.utah.edu Message-Id: <668450075.0.BNB@MATH.AMS.COM> In-Reply-To: <9103081239.AA06109@wheat-chex> Mail-System-Version: berthold horn is looking for a documented example where two vendors supply fonts with the same name but different metrics. although this example doesn't meet the letter of that request, it may still provide useful and relevant information. the math society has had an autologic aps micro-5 typesetter for several years, and in the initial complement of fonts was a family named "times new 2 [roman]". this family exhibits all the characteristics typical of what is usually referred to as "times new [roman]", which was exactly what we had in mind when ordering it. when we ordered the fonts, it was possible to select from several different variations, where the differences were in the font complement. (this is similar to horn's experience with fonts from different vendors, but localizes it to one vendor.) to the best of my knowledge, the particular variations would not be known by different font names or autologic master id number (including the id number on the disk provided for installation), but would be distinguished only by a minor comment on the paperwork. in practice, if user a were to send a job to be set on the typesetter of user b, which might have a different glyph complement for "times new 2 [roman]", the need for checking this might easily be overlooked, as the name and id number match perfectly, and only become apparent through a surprise on the output. autologic has now renamed some of its fonts. what we obtained as "times new 2 roman" (font id 1407) is now listed in autologic's font catalog as "times square roman", with the same id. it appears, however, that the actual content of the font is identical as to shape and metrics. the other idiosyncrasy of this font is the apparent size. we usually specify 10pt for out journal and book work. however, when compared to the 10pt times from almost any other source, the autologic font appears to be nearly equivalent to 11pt. in fact, when set on 12pt baselines, the autologic times looks very dense, and set solid, it looks overly cramped (my opinion). the relative large size of this font has now been incontrovertibly demonstrated by comparison with the presumably equivalent 10pt times font used on our new compugraphic imagesetter (which uses agfa-compugraphic's rendition of the adobe postscript times). granted that compugraphic calls the font "times ten" (id 62p), which is not the same (and in fact, may not be exactly the same as the name adobe uses, although the design is credited as licensed from adobe, and the name "times" credited as being a trademark of linotype), the fact remains: two fonts intended to be comparable are quite different in apparent size at the same nominal size and must therefore have different metrics. -- bb ------- 8-Mar-1991 17:21:20-GMT,1804;000000000001 Return-Path: Received: from life.ai.mit.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09171; Fri, 8 Mar 91 10:21:07 MST Received: from wheat-chex (wheat-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA26867; Fri, 8 Mar 91 12:20:42 EST From: bkph@ai.mit.edu (Berthold K.P. Horn) Received: by wheat-chex (4.1/AI-4.10) id AA00243; Fri, 8 Mar 91 12:20:35 EST Date: Fri, 8 Mar 91 12:20:35 EST Message-Id: <9103081720.AA00243@wheat-chex> To: BNB@math.ams.com Cc: tex-fonts@math.utah.edu In-Reply-To: bbeeton's message of Fri 8 Mar 91 11:34:35-EST <668450075.0.BNB@MATH.AMS.COM> Subject: incompatible metrics Thank you very much for that example! The way I understand it, however, Times-Roman, TimesTen and TimesNewRoman are considered distinct faces (These appear to be the three most widely used variants of the Times Roman concept). And it seems you were comparing TimesNewRoman from Autologic with TimesTen >From CompuGraphic (correct me if I'm wrong). Of course, it is not always easy to tell, given proprietary naming and numbering schemes. This brings up another issue, which is how to make users aware of the fact that there are thousands of fonts and so related fonts are likely to have VERY similar names - despite the fact that they do not have the same glyphs or metrics. All variations on the Times-Roman theme are likely to have the word `Times' in their name, for example. So great care is required in using these names. (This is not unlike the confusion caused by the very close similarity of names given to different DVI processors - was it DVITOPS, DVI2PS, DVIPS, DVI3PS, or ... ?). Thanks again, Berthold. Appendix: Adobe has the following families (with the usual variations): tir Times-Roman mtr TimesNewRomanPS ttr TimesTen-Roman 8-Mar-1991 18:13:39-GMT,2493;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA09605; Fri, 8 Mar 91 11:13:34 MST Date: Fri 8 Mar 91 13:17:19-EST From: bbeeton Subject: Re: incompatible metrics To: bkph@ai.mit.edu Cc: tex-fonts@math.utah.edu Message-Id: <668456240.0.BNB@MATH.AMS.COM> In-Reply-To: <9103081720.AA00243@wheat-chex> Mail-System-Version: berthold, you're correct -- i was comparing two fonts (with three names) that have identifiably different names. i'm still not sure that just "times new [roman]" is the proper name for the autologic font, as the (old) font catalog distinctly contains a "2" in the name. it's really a tough matter, and one on which users really do need to be educated (though i'm not at all sure how) to the fact that there is so much diversity with similar names. and the names aren't necessarily always similar! although you speculated that "all variations on the times-roman theme are likely to have the word `times' in their name", i find the following in one of my reference books (The TypEncyclopedia, by frank j romano): Times New Roman (Monotype) English (Alphatype) English Times (Compugraphic postscript) London Roman (Wang) Pegasus Press Roman (IBM) Times Roman (AM, Autologic, Dymo, Harris, Mergenthaler) TR (Itek) if you think this list is long, the one for helvetica is even longer. this is *all* pre-postscript (the book was published in 1984). i have reason to believe that what talaris calls "dutch" is yet another times-like entry. and i am sure that if i looked carefully enough through old seybold reports, i'd come up with even more. a periodic topic of discussion in the iso fonts working group (a subgroup of sc18/wg8, in the u.s. part of x3v1; i've been a member of this body since 1986) is the problem of automatic font substitution in blind document interchange. (that is, if someone sends out a final-form document, and the receiving site doesn't have the requested font, what should be done.) this is good for many long, often fruitless, hours of indecisive verbiage. the problem existed before i arrived on the scene, and it will certainly continue to exist long after i've set my last piece of type. i don't think we're really going to find a general solution here, but education is certainly part of the answer, and making sure that real distinctions are recognized and accounted for. -- bb ------- 12-Mar-1991 4:36:42-GMT,751;000000000001 Return-Path: Received: from life.ai.mit.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA00331; Mon, 11 Mar 91 21:36:28 MST Received: from rice-chex (rice-chex.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) id AA04735; Mon, 11 Mar 91 23:36:19 EST From: bkph@ai.mit.edu (Berthold K.P. Horn) Received: by rice-chex (4.1/AI-4.10) id AA07755; Mon, 11 Mar 91 23:36:13 EST Date: Mon, 11 Mar 91 23:36:13 EST Message-Id: <9103120436.AA07755@rice-chex> To: tex-fonts@math.utah.edu Subject: informal survey... Something to give pause... There are presently over 7000 (seven THOUSAND) fonts available in Type 1 format (of which over 1000 are in the Adobe Type Library). Anyone know how many fonts are available in TrueType format? 12-Mar-1991 18:34:35-GMT,1330;000000000001 Return-Path: Received: from CBROWN.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA05081; Tue, 12 Mar 91 11:34:27 MST Date: Tue, 12 Mar 1991 09:20 PST From: Don Hosek Subject: Re: informal survey... To: bkph@ai.mit.edu Cc: tex-fonts@math.utah.edu Message-Id: X-Envelope-To: tex-fonts@math.utah.edu X-Vms-To: IN%"bkph@ai.mit.edu" X-Vms-Cc: IN%"tex-fonts@math.utah.edu" -Something to give pause... -There are presently over 7000 (seven THOUSAND) fonts available in Type 1 -format (of which over 1000 are in the Adobe Type Library). Yes, but there's no reason to assume that a two letter code for a typeface under Adobe should have to correspond exactly to a two letter code for a typeface under Conpugraphic. 'twould be nice if they did, but not necessary. Incidentally, one thing has occurred to me regarding vendor-supplied names: with Tom Rokicki's afm2tfm, I can create things like ptmu (Adobe Times Unslanted Italic) or ptmo (Adobe Times Slanted) etc. I haven't looked over the Adobe abbreviations, but is it possible that some of the possible creations of this sort could lead to ambiguities (if I recall correctly, a varying number of characters is used in identifying families, c'est ne pas)? -dh 12-Mar-1991 18:38:45-GMT,1136;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA05098; Tue, 12 Mar 91 11:38:40 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA02716; Tue, 12 Mar 91 13:19:54 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA19882; Tue, 12 Mar 91 13:36:02 EST Date: Tue, 12 Mar 91 13:36:02 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9103121836.AA19882@ra.cs.umb.edu> To: tex-fonts@math.utah.edu In-Reply-To: Don Hosek's message of Tue, 12 Mar 1991 09:20 PST Subject: informal survey... Reply-To: karl@cs.umb.edu Don H.> some of the possible > creations of this sort could lead to ambiguities (if I recall > correctly, a varying number of characters is used in identifying > families, c'est ne pas)? I don't know if Adobe's names are ambiguous or not, but I know mine are in some cases -- if the font has multiple variants and the last variant letter is also a valid expansion letter, you can't tell what's what. The solution would be to always require an expansion letter in those cases. That would make some names too long. 15-Mar-1991 13:31:19-GMT,1864;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA25247; Fri, 15 Mar 91 06:31:12 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA15485; Fri, 15 Mar 91 08:28:32 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA12638; Fri, 15 Mar 91 08:28:22 EST Date: Fri, 15 Mar 91 08:28:22 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9103151328.AA12638@ra.cs.umb.edu> To: tex-fonts@math.utah.edu, tex-implementors@math.ams.com Subject: fontname mapping file for TeX Reply-To: karl@cs.umb.edu In a recent letter to dek, I asked if adding a ``fontname mapping file'' to TeX would compromise its TeX-ness. He said no, that such a feature would be a fine adaptation to local conditions. For those who didn't see the earlier messages on the subject, the idea is this. When TeX sees \font\foo = fname it would look for fname first in this mapping file, which would specify some other, real filename. For example, \font\foo = adobe-times-roman might have an entry adobe-times-roman ptmr and then TeX would actually read ptmr.tfm. Some people have suggested adding wildcards, .e.g, \font\foo = *adobe-times-roman* would match isolatin1-adobe-times-roman-blah-blah-blah as happens in X. I am opposed to this. I realize this idea, whatever the final form, is not without its disadvantages. Don Hosek pointed out some of them. But I still think it would be a useful addition to TeX, because TeX source files could potentially be much more portable and the issue of how to name font files goes away (well, of course you still have to name them something, but it doesn't really matter what the names are, since no one would ever need to use them). But it is only truly useful if the majority of the implementations, on different systems, support it. Hence this message. Comments? karl@cs.umb.edu 15-Mar-1991 16:28:06-GMT,1404;000000000001 Return-Path: Received: from BULLDOG.CS.YALE.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA25932; Fri, 15 Mar 91 09:28:00 MST Received: from lrw.UUCP by BULLDOG.CS.YALE.EDU via UUCP; Fri, 15 Mar 91 11:21:07 EST Message-Id: <9103151621.AA24188@BULLDOG.CS.YALE.EDU> Received: by lrw.UUCP (DECUS UUCP w/Smail); Fri, 15 Mar 91 10:25:43 EDT Date: Fri, 15 Mar 91 10:25:43 EDT From: Jerry Leichter To: TEX-FONTS@math.utah.edu Subject: RE: fontname mapping file for TeX Good going! Obviously, as I wrote about this before, I think it's a good idea. I have may doubts about wild-carding, but it does have one saving grace: If you don't use wild-card characters, it doesn't hurt you. (This assumes that if there are no *'s in the spec you hand to \font, you get ONLY the exact match - not an implicit trailing *, or something like that.) Even with that, I'd find real text wildcarding a bad idea. It's one thing to say "give me Times Roman 10pt normal weight character set TeX-standard from any foundary", quite another to say "give me any font whose name happens to contain the characters TMR10NTS anywhere within it". Perhaps the X font-naming conventions are good enough to support this - I don't know enough about them. Without some control over how the matching is done, pure text wildcarding is just asking for trouble. -- Jerry 15-Mar-1991 17:24:14-GMT,2160;000000000001 Return-Path: Received: from Neon.Stanford.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA26273; Fri, 15 Mar 91 10:24:09 MST Received: by Neon.Stanford.EDU (5.61/25-eef) id AA00775; Fri, 15 Mar 91 09:22:58 -0800 Date: Fri, 15 Mar 91 09:22:58 -0800 From: Tomas G. Rokicki Message-Id: <9103151722.AA00775@Neon.Stanford.EDU> To: karl@cs.umb.edu Cc: tex-fonts@math.utah.edu, tex-implementors@math.ams.com In-Reply-To: Karl Berry's message of Fri, 15 Mar 91 08:28:22 EST <9103151328.AA12638@ra.cs.umb.edu> Subject: fontname mapping file for TeX The font file name mapping within TeX might be okay as an adaption to local conditions, but we should definitely not abandon the standard font file names we are trying to adopt. Ideally, a TeX file using PostScript fonts should be close to as portable as a TeX file using CM fonts. My initial reaction to the idea of implementing a font mapping file in TeX for the implementations I support is the same as that of using the MLTeX charsubdef modification---I hate to do it, because it gives the users one more thing that won't work on their mainframe/PC/whatever; that they can't count on TeX being TeX. If such an idea is ordained by TUG, after more discussion and detailed specification, then I'd almost definitely do it. (Perhaps we should discuss whether the MLTeX/charsubdef stuff should be blessed? How do we distinguish implementations that implement some of this stuff, but maybe not all? It's not like we can say TeX $355/113$ or anything.) For standard PostScript font names---Karl, do you know how Adobe derives the names when it distributes fonts in MSDOS format? Maybe we can adopt those names where they fit and where possible for the ones that don't already have names? Maybe we can get a master list of such names from Adobe. (I'd like to automate the installation of a new PS font on a system---at the moment it requires several runs of afm2tfm, vptovf, edit psfonts.map, rename and copy all over the place.) Maybe I'll even write a macro that reads psfonts.map and generates a font list of available fonts at that site . . . 15-Mar-1991 17:29:42-GMT,2276;000000000001 Return-Path: <@MATH.AMS.COM:rokicki@Neon.Stanford.EDU> Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA26310; Fri, 15 Mar 91 10:29:37 MST Received: from Neon.Stanford.EDU by MATH.AMS.COM via SMTP with TCP; Fri, 15 Mar 91 12:28:09-EDT Received: by Neon.Stanford.EDU (5.61/25-eef) id AA00775; Fri, 15 Mar 91 09:22:58 -0800 Date: Fri, 15 Mar 91 09:22:58 -0800 From: Tomas G. Rokicki Message-Id: <9103151722.AA00775@Neon.Stanford.EDU> To: karl@cs.umb.edu Cc: tex-fonts@math.utah.edu, tex-implementors@math.ams.com In-Reply-To: Karl Berry's message of Fri, 15 Mar 91 08:28:22 EST <9103151328.AA12638@ra.cs.umb.edu> Subject: fontname mapping file for TeX The font file name mapping within TeX might be okay as an adaption to local conditions, but we should definitely not abandon the standard font file names we are trying to adopt. Ideally, a TeX file using PostScript fonts should be close to as portable as a TeX file using CM fonts. My initial reaction to the idea of implementing a font mapping file in TeX for the implementations I support is the same as that of using the MLTeX charsubdef modification---I hate to do it, because it gives the users one more thing that won't work on their mainframe/PC/whatever; that they can't count on TeX being TeX. If such an idea is ordained by TUG, after more discussion and detailed specification, then I'd almost definitely do it. (Perhaps we should discuss whether the MLTeX/charsubdef stuff should be blessed? How do we distinguish implementations that implement some of this stuff, but maybe not all? It's not like we can say TeX $355/113$ or anything.) For standard PostScript font names---Karl, do you know how Adobe derives the names when it distributes fonts in MSDOS format? Maybe we can adopt those names where they fit and where possible for the ones that don't already have names? Maybe we can get a master list of such names from Adobe. (I'd like to automate the installation of a new PS font on a system---at the moment it requires several runs of afm2tfm, vptovf, edit psfonts.map, rename and copy all over the place.) Maybe I'll even write a macro that reads psfonts.map and generates a font list of available fonts at that site . . . 15-Mar-1991 18:17:02-GMT,4457;000000000001 Return-Path: Received: from blackbox.hacc.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA26750; Fri, 15 Mar 91 11:16:54 MST Received: by blackbox.hacc.washington.edu (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.6 ) id AA08206; Fri, 15 Mar 91 10:14:07 PST From: Thomas B. Ridgeway Message-Id: <9103151814.AA08206@blackbox.hacc.washington.edu> Subject: Re: fontmapping files To: tex-fonts@math.utah.edu Date: Fri, 15 Mar 91 10:14:05 PDT X-Mailer: ELM [version 2.2 PL11] In a recent message, Karl Berry writes: > In a recent letter to dek, I asked if adding a ``fontname mapping file'' > to TeX would compromise its TeX-ness. He said no, that such a feature > would be a fine adaptation to local conditions. > > For those who didn't see the earlier messages on the subject, the idea > is this. When TeX sees \font\foo = fname > it would look for fname first in this mapping file, which would specify > some other, real filename. For example, > \font\foo = adobe-times-roman > might have an entry > adobe-times-roman ptmr > and then TeX would actually read ptmr.tfm. Well, I like this idea a lot better than the alternatives, so far. One of the things I liked about Karl's original proposed scheme was that a font name would be decodable without reference to a table (if, of course, you were fairly familiar with foundries, typefaces, etc.); the only problem was that if the entire world was to follow the entire scheme we don't have enough characters to do it in, since 3 chars for foundry+typeface ---> despair, or at least the end of being able to keep the separate chars in the name as separate fields. If we supposed we could make the prospect of standardizing font filenames attractive to system administrators and end-useTeXers I don't know why a standard mapping file could not be equally attractive and susceptible to actual acceptance as a standard. > Some people have suggested adding wildcards, .e.g, > \font\foo = *adobe-times-roman* > would match > isolatin1-adobe-times-roman-blah-blah-blah > as happens in X. > I am opposed to this. Me too; IMHO the proper place for a wildcard function is inside a macro package or via aliasing in the mapfile. Tex's consultation of the font-mapping file ought to look just like (the current) search for a .tfm---either it is there or it isn't. I think we might likely get into tricky portability issues with wild cards again. For instance, on my XYZ9000 at home, I will presumably modify my fontmap file to say -> adobe-times-roman cmr10 -> bitstream-charter cmr10 -> otherwise-velveeta cmss10 -> amr10 cmr10 (since my FX-80 ink-ribbon typesetter has a limited selection of fonts) and locally implement a take-whatever-is-available-and-use-it scheme without necessitating wildcards in the documents I bring home to TeX, or even my editing the font calls in the documents I bring home. How would such a locally implemented scheme interact with a built-in wildcarding? As the local editor of the fontmap file, I would not like to have to weigh the possibility that I might be undoing the intention (if any) of some document's possibly-carefully-crafted wildcard spec for choosing exactly the desired font of all available fonts. I would expect such local aliasing in mapfiles to be fairly common at sites with restricted font availability, i.e. most of them. > > Comments? How to implement? A mapping file, if one exists, presumably would be searched before a .tfm file was searched for; on failing one presumably should still search for a tfm (this would be for the benefit of users on a multiuser system who need fonts which are not installed/supported at the system level---without having to maintain an edited copy of the entire fontmap in their personal disk space--- also for convenient testing of new fonts). Cheers, Tom - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thomas Ridgeway, Director, Humanities and Arts Computing Center/NorthWest Computing Support Center 35 Thomson Hall, University of Washington, DR-10 Seattle, WA 98195 phone: (206)-543-4218 Internet: ridgeway@blackbox.hacc.washington.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - * all the usual disclaimers apply, plus any extras which may be needed to cover anything particularly stupid * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 15-Mar-1991 18:53:14-GMT,2703;000000000001 Return-Path: Received: from blackbox.hacc.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA26957; Fri, 15 Mar 91 11:53:08 MST Received: by blackbox.hacc.washington.edu (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.6 ) id AA08230; Fri, 15 Mar 91 10:50:22 PST From: Thomas B. Ridgeway Message-Id: <9103151850.AA08230@blackbox.hacc.washington.edu> Subject: fontname mapping and standard fontnames To: tex-fonts@math.utah.edu Date: Fri, 15 Mar 91 10:50:20 PDT In-Reply-To: <9103151722.AA00775@Neon.Stanford.EDU>; from "Tomas G. Rokicki" at Mar 15, 91 9:22 am X-Mailer: ELM [version 2.2 PL11] Tom Rocicki says: > but we should definitely not abandon the standard font file names > we are trying to adopt. Ideally, a TeX file using PostScript fonts should be > close to as portable as a TeX file using CM fonts. *Absolutely*; fontmapping isn't worth the bother unless the logical fontnames in the map are standardized and some body takes it upon itself to maintain the list. > My initial reaction to the idea of implementing a font mapping file in TeX > for the implementations I support is the same as that of using the MLTeX > charsubdef modification---I hate to do it, because it gives the users one > more thing that won't work on their mainframe/PC/whatever; that they can't > count on TeX being TeX. With a more sympathetic (for implementors) tone than my keyboard can emit, I think this is just another case of some implementations are better than others, some versions are older than others. We don't have to like it, but we don't have to let it stop us from doing what we need to do to make TeX increasingly useful to the community as a whole. I would assume that implementing the filemapping would be most difficult on the systems that are already crunched for memory and have tiny filenames, i.e. MS/PC-DOS and similarly sized kin. And, for better or worse, those machines have begun---and in the fullness of time will complete--- the move to the big CPU chassis in the sky. Yes, I TeX on such a might-be-mistaken-for-a-toy myself; but, no, I wouldn't want that to limit the capabilities of the version of TeX I will install on my new system in 1994. Well, maybe 1995. cheers, Tom - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thomas Ridgeway, Director, Humanities and Arts Computing Center/NorthWest Computing Support Center 35 Thomson Hall, University of Washington, DR-10 Seattle, WA 98195 phone: (206)-543-4218 Internet: ridgeway@blackbox.hacc.washington.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 16-Mar-1991 0:13:32-GMT,1470;000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA28648; Fri, 15 Mar 91 17:13:28 MST Date: Fri, 15 Mar 1991 16:12 PST From: Don Hosek Subject: Re: fontmapping files To: ridgeway@blackbox.hacc.washington.edu Cc: tex-fonts@math.utah.edu Message-Id: <690E58E560C00522@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-fonts@math.utah.edu X-Vms-To: IN%"ridgeway@blackbox.hacc.washington.edu" X-Vms-Cc: IN%"tex-fonts@math.utah.edu" /I think we might likely get into tricky portability issues with /wild cards again. For instance, on my XYZ9000 at home, I will /presumably modify my fontmap file to say /-> adobe-times-roman cmr10 /-> bitstream-charter cmr10 /-> otherwise-velveeta cmss10 /-> amr10 cmr10 /(since my FX-80 ink-ribbon typesetter has a limited selection of fonts) /and locally implement a take-whatever-is-available-and-use-it scheme /without necessitating wildcards in the documents I bring home to TeX, /or even my editing the font calls in the documents I bring home. Your application of font substitution seems very awkward to me. Presumably you'll want to get a rather complete proofing of the document to be printed, you'd probably want to keep the metrics for the font being proofed and live with awkward inter-letter spacing on your FX-80. If nothing else, don't you want a good idea of how many pages the document will have? -dh 16-Mar-1991 13:21:38-GMT,988;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02247; Sat, 16 Mar 91 06:21:29 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA10300; Sat, 16 Mar 91 08:18:50 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA23650; Sat, 16 Mar 91 08:18:36 EST Date: Sat, 16 Mar 91 08:18:36 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9103161318.AA23650@ra.cs.umb.edu> To: tex-fonts@math.utah.edu, tex-implementors@math.utah.edu Subject: fontname mapping Reply-To: karl@cs.umb.edu (I don't know if this discussion should continue on both lists.) We shouldn't abandon my old (or some, at any rate) filename scheme, because the tfm files have to be named something. They might as well be named something rational. I believe Berthold told me that Adobe's naming scheme is more or less random. I asked him if the list was available electronically, but perhaps my message got lost. bkph, are you there? karl@cs.umb.edu 17-Mar-1991 8:11:58-GMT,5405;000000000001 Return-Path: Received: from CC.UTAH.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA05139; Sun, 17 Mar 91 01:11:26 MST Received: from TAMVM1.TAMU.EDU (MAILER@TAMVM1) by CC.UTAH.EDU with PMDF#10043; Sun, 17 Mar 1991 01:09 MST Received: from TAMVM1 (X066TR) by TAMVM1.TAMU.EDU (Mailer R2.07) with BSMTP id 1932; Sat, 16 Mar 91 22:33:52 CST Date: Sat, 16 Mar 91 15:41:42 CST From: "Thomas J. Reid" Subject: Font name mapping: success on a smaller scale To: TeX fonts discussion Message-Id: <7D1F89832040030D@CC.UTAH.EDU> X-Envelope-To: tex-fonts@math.utah.edu Organization: Texas A&M University Computing Services Center During the development of TeXrox, a DVI driver for Xerox printers, I had to resolve the problem of mapping font names (as given in a DVI file) into font names for the printer. Although this is not the same same problem being faced by the current discussion on this list, it may be constructive to review what I have done and see what ideas, if any, can be applied to the current problem. TeXrox can use fonts in two different ways: fonts can be resident on the printer; or TeXrox will build a bitmap image of characters from fonts which are not resident. Resident fonts are considerably more efficient than bitmapped ones. However, the names of these resident fonts had to be made to fit Xerox naming conventions. Specifically: o Names can be from one to six characters consisting of letters or digits only o Separate resident fonts are required for different orientations o Separate resident fonts are required for different magnifications o For larger fonts, it is necessary to split a single "DVI font" (what TeX and the DVI file see as a single font) into multiple resident fonts o The names of the fonts need to be kept distinct from the names of other fonts already on the printer. The input to my name mapping is, of course, the font name from a DVI file (exclusive of the area portion). At the time I devised my scheme (1986), the input name was effectively unbounded (255 or fewer characters). What I did was to declare that it was not practical to devise a formula to map the names. Instead, the program which converts PK/GF/PXL files into Xerox fonts assigns the names using a sequential counter. The format of the name is: TFxxxo where "xxx" is a three "digit" hexadecimal number assigned by the conversion utility and "o" indicates the orientation (P for portrait, L for landscape, I for inverse portrait, and J for inverse landscape). "TF" stands for TeX font which distinguishes the font from others on the printer. If the "DVI font" requires multiple Xerox fonts because of size, the conversion program outputs multiple fonts assigning different numbers to the "xxx" portion of the name. To make this mapping of names and handling of split fonts transparent to the TeX user, the font conversion program also outputs an index file under the name and magnification of the font as known by TeX which gives the Xerox name or names. TeXrox uses the index files to do all mapping which makes the process transparent to the TeX user. (Another feature of the index file is that it remaps character codes. This was necessary since codes 0x00 through 0x0f are reserved for Xerox fonts.) This system has been successful because one program (the PK/GF/PXL to Xerox font converter) assigns the Xerox names automatically. Further, the Xerox names are hidden from the user (unless one looks at the resultant XRX file---which is only slightly more readable than a DVI file). Further, since maintenance of system files for the printers is already centralized, the use of a central authority to define the mapping of TeX/DVI names to Xerox names does not impose any burden. Users can still create and use their own fonts (TeXrox will bitmap them); they just can't make them printer-resident without going through the central authority. Trying to apply this type of a scheme to mapping "user font names" to "internal names" does introduce some problems: o The need arises for a central authority to assign and distribute the font name mappings. o Changes to TeX and associated programs to use the mapping file need to be made and widely distributed. o It is difficult to insulate the end-user from the assigned (and generally meaningless) names. o Users will have difficulties creating their own fonts unless they register the names or some escape mechanism exists to allow them to use non-standard names. However, some advantages can also be found: o A naming scheme of a letter followed by five letters or digits could easily be used to encode 1.57 thousand million font names; this should be sufficient ;-) and only uses six characters (of course, the dirty words need to be filtered out :-). Other schemes are also possible giving millions of possible names in eight characters or less. o Having a font name mapping file allows a relatively non-system- specific utility to be written to let the user determine what fonts are available. There are, I'm sure, many other pros and cons. Of course, many of the disadvantages and the second advantage will be seen regardless of how the "internal" names are derived. ---Tom Reid 18-Mar-1991 4:13:48-GMT,7181;000000000001 Return-Path: Received: from CC.UTAH.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA08540; Sun, 17 Mar 91 21:13:44 MST Received: from TAMVM1.TAMU.EDU (MAILER@TAMVM1) by CC.UTAH.EDU with PMDF#10043; Sun, 17 Mar 1991 21:11 MST Received: from TAMVM1 (X066TR) by TAMVM1.TAMU.EDU (Mailer R2.07) with BSMTP id 2117; Sun, 17 Mar 91 21:32:54 CST Date: Sun, 17 Mar 91 21:04:06 CST From: "Thomas J. Reid" Subject: Tutorial on file names and usage with IBM systems In-Reply-To: Message of Tue, 5 Mar 1991 10:03 PST from To: "Nelson H.F. Beebe" Message-Id: <250ECBA646400C45@CC.UTAH.EDU> X-Envelope-To: beebe@science.utah.edu Organization: Texas A&M University Computing Services Center Nelson, I have prepared the following note to be sent to the tex-fonts list but thought that I would let you see it first. My concern is over the scope of the tex-fonts list. Although the note corrects some minor errors on file naming conventions on VM/CMS and MVS, the central focus is on how fonts can or should be organized on those two systems, and how a search path mechanism is implemented on each system. This is a topic which relates to fonts, but has not been brought up on tex-fonts. Is this a topic you would like to see covered on the list? If so, I am considering holding off sending it until the topic comes up so as to not divert the attention from the current topic of a font mapping file. What do you think? ---Tom -----------------------------Original message----------------------------- On Tue, 5 Mar 1991 10:03 PST Don Hosek (DH>), Nelson Beebe (NB>), and others wrote about file naming conventions under various operating systems. The information for the IBM systems VM/CMS and MVS contained some minor errors. Along with the file naming conventions comes the issue of accessing the file from programs. This is more of a concern for how fonts are grouped and how searches are performed than it is for the names themselves, but I feel that it is a reasonable topic for discussion on this list. If the topic is to be discussed, it would probably be beneficial to have the site coordinators for different systems/environments join the list and take part. NB> IBM CMS allows 8 + 4; DH> 8+8 actually. No subdirectories. VM/CMS does have directories in a sense. Under VM, disk space is divided into "mini-disks." Mini-disks are assigned to a particular userid, but various options exist for sharing them with other users. Of interest here is that a TeX account could own many disks (for different sets of fonts or something) with the ability for other users to access the disks in read- only mode. To use a mini-disk, it is necessary for a user to link to and access it. (This is typically done in an EXEC file, but can also be done from a program.) When accessing the mini-disk, the user (or EXEC) assigns a single letter of the alphabet to refer to files on that mini-disk. Thus, a user may have up to 26 mini-disks accessed at any moment. A reference to a particular file would be written something like: CMR10 300PK A which refers to a 300 dpi PK file for font cmr10 residing on the disk currently accessed as under disk A. (The final letter, called a file- mode, can also contain a single digit from 0 through 6 indicating a type of a file. However, this is not relevant to the discussion here.) When a new disk is accessed, most EXECs assign the next unused letter in the alphabet to it. Thus, a mini-disk which is accessed as disk C by one user might be called as disk F by another. Because of this, CMS allows a reference to a file to be written as: CMR10 300PK * which calls for a 300 dpi PK file for cmr10 from the first mini-disk in alphabetical order which contains the file. Most programs use a filemode of * so that all accessed mini-disks are searched. An advantage of this is that the order in which the disks are searched can be controlled by the letters assigned as the filemodes; someone working on, say, tuning the blacker and fillin values for the cm fonts could place the newly-created GF or PK file on his or her A disk. The new files would then be used in place of an older version of the font. By dividing fonts into different mini-disks based on the output device, or font foundry, or something, mini-disks serve the same function as subdirectories on other systems. Use of * as a filemode provides a user-controllable search path mechanism which is external to programs. DH> MVS allows 8*8 (that is their can be up to eight parts of the DH> file name, each eight characters long. No element may start with DH> a number). Hmm. Mostly correct, but with an important aspect not mentioned. Dataset names under MVS consist of up to eight levels of up to eight characters each. The first character of each level must be a letter, @ #, or $ while the others can be letters, digits, @, #, or $. The data- set name is written with the levels separated by periods. The whole name including periods cannot exceed 44 characters. Under MVS, each dataset occupies a whole number of tracks on disk. For the disks we use here, this means that datasets come in increments of 48K byte allocations! For things like TFM files, this would be a gross waste of disk space. This leads to the aspect not mentioned: "partitioned datasets" (or PDSs). A PDS is simply a library of multiple "members." In a sense, it is like a subdirectory. Member names follow the standard MVS pattern of being >From one to eight characters with the first being a letter, @, #, or $ and the remaining being letters, digits, @, #, or $. Since multiple members can be written to the same track, this results in a considerable savings of disk space. When datasets or members are referenced from within a program, the dataset name is typically *not* used. Instead, the dataset is associated (externally to the program) with a one-to-eight character "DD name." A program then refers either to the DD name, or the DD name and a member name. (This makes names under MVS be 8+8.) The DD name is fixed, but the program can select different member names as necessary. The exact syntax varies with the programming language and library routines used, but typical syntax would be something like: PK300(CMR10) which references member CMR10 from the dataset defined under the DD name of PK300. The actual dataset name might be something like: USR.X066.TX.FONTS.XEROX.PK300 Although it is possible to access datasets and members by dataset name dynamically within a program (ie, without pre-defining them externally), this would normally not be done when working with the various font files: it is less efficient and it disables an external search path capability. A search path capability exists in that up to sixteen PDSs may be associated with a single DD name. When the system searches for a given member, it searches the directories of each PDS in succession and selects the first one that it finds. This gives MVS an external search path capability similar to that available under CMS. ---Tom Reid 18-Mar-1991 17:22:31-GMT,4119;000000000001 Return-Path: Received: from blackbox.hacc.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA12185; Mon, 18 Mar 91 10:22:27 MST Received: by blackbox.hacc.washington.edu (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.6 ) id AA10008; Mon, 18 Mar 91 09:19:29 PST From: Thomas B. Ridgeway Message-Id: <9103181719.AA10008@blackbox.hacc.washington.edu> Subject: Re: fontmapping files To: tex-fonts@math.utah.edu Date: Mon, 18 Mar 91 9:19:27 PDT In-Reply-To: <690DC7F000C00522@HMCVAX.CLAREMONT.EDU>; from "Don Hosek" at Mar 15, 91 4:12 pm X-Mailer: ELM [version 2.2 PL11] regarding substituting for missing fonts by using a fontmapping scheme, Don Hosek ( > ) comments on my (comment ( > /): > / For instance, on my XYZ9000 at home, I will > /presumably modify my fontmap file to say > /-> adobe-times-roman cmr10 > /-> bitstream-charter cmr10 > /-> otherwise-velveeta cmss10 > /-> amr10 cmr10 > /(since my FX-80 ink-ribbon typesetter has a limited selection of fonts) > /and locally implement a take-whatever-is-available-and-use-it scheme > /without necessitating wildcards in the documents I bring home to TeX, > /or even my editing the font calls in the documents I bring home. > > Your application of font substitution seems very awkward to me. > Presumably you'll want to get a rather complete proofing of the > document to be printed, you'd probably want to keep the metrics > for the font being proofed and live with awkward inter-letter > spacing on your FX-80. If nothing else, don't you want a good > idea of how many pages the document will have? > Good point: since people would be able to conveniently alias fonts this way, they would want to for several different reasons. Don is presumably thinking of running through TeX with tfms in place for fonts which are otherwise not installed so as to be able to see from the log file how it turned out, or to print out a very rough (in terms of appearance, but correct in terms of page breaks etc.) approximation of the output (using some form of fontmapping at the dvi driver stage). This would be what one wants to do in the final proofint stage of a document which is eventually going to be returned to a system with the full set of fonts installed and run off there; at this point one is just checking for awkward page breaks and so forth (using substitute fonts for proofing). I was thinking of different situations: ... working on a document which refers to fonts which are not installed, which one wishes to TeX making wholesale font substituions for correct output with the substituted fonts, e.g. printing an old article with explicit references to am fonts---without having to go into the document to edit the font references. Printing any document with explicit references to Postscript fonts on a non- Postscript printer (without editing the font references). ... Another instance would be wishing to tinker (at home, or at any other site with limited font support) with macros (etc.) to do this or that; simulating the ultimate output with the ultimately-to-be-used fonts would not be important at this stage of the process; producing correct output for the substituted fonts which the previewer/printer is actually using would be what is desired so that any bizarre spacing problems caused by the macros could be identified---i.e. we aren't far enough along to worry about awkward page breaks yet. I mention aliasing, BTW, only because it seems to me that the existence of a fontmap file would lend itself to this use; if we propose adding a new feature, we want to explore a little what people are likely to do with it. cheers, Tom - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thomas Ridgeway, Director, Humanities and Arts Computing Center/NorthWest Computing Support Center 35 Thomson Hall, University of Washington, DR-10 Seattle, WA 98195 phone: (206)-543-4218 Internet: ridgeway@blackbox.hacc.washington.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 19-Mar-1991 3:26:04-GMT,6280;000000000001 Return-Path: Received: from CC.UTAH.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA15752; Mon, 18 Mar 91 20:25:57 MST Received: from TAMVM1.TAMU.EDU (MAILER@TAMVM1) by CC.UTAH.EDU with PMDF#10043; Mon, 18 Mar 1991 20:25 MST Received: from TAMVM1 (X066TR) by TAMVM1.TAMU.EDU (Mailer R2.07) with BSMTP id 2414; Mon, 18 Mar 91 21:23:02 CST Date: Mon, 18 Mar 91 21:22:05 CST From: "Thomas J. Reid" Subject: Tutorial on file names and usage with IBM systems To: TeX fonts discussion Message-Id: X-Envelope-To: tex-fonts@math.utah.edu Organization: Texas A&M University Computing Services Center On Tue, 5 Mar 1991 10:03 PST Don Hosek (DH>), Nelson Beebe (NB>), and others wrote about file naming conventions under various operating systems. The information for the IBM systems VM/CMS and MVS contained some minor errors. Along with the file naming conventions comes the issue of accessing the file from programs. This is more of a concern for how fonts are grouped and how searches are performed than it is for the names themselves, but I feel that it is a reasonable topic for discussion on this list. If the topic is to be discussed, it would probably be beneficial to have the site coordinators for different systems/environments join the list and take part. NB> IBM CMS allows 8 + 4; DH> 8+8 actually. No subdirectories. VM/CMS does have directories in a sense. Under VM, disk space is divided into "mini-disks." Mini-disks are assigned to a particular userid, but various options exist for sharing them with other users. Of interest here is that a TeX account could own many disks (for different sets of fonts or something) with the ability for other users to access the disks in read- only mode. To use a mini-disk, it is necessary for a user to link to and access it. (This is typically done in an EXEC file, but can also be done from a program.) When accessing the mini-disk, the user (or EXEC) assigns a single letter of the alphabet to refer to files on that mini-disk. Thus, a user may have up to 26 mini-disks accessed at any moment. A reference to a particular file would be written something like: CMR10 300PK A which refers to a 300 dpi PK file for font cmr10 residing on the disk currently accessed as under disk A. (The final letter, called a file- mode, can also contain a single digit from 0 through 6 indicating a type of a file. However, this is not relevant to the discussion here.) When a new disk is accessed, most EXECs assign the next unused letter in the alphabet to it. Thus, a mini-disk which is accessed as disk C by one user might be called as disk F by another. Because of this, CMS allows a reference to a file to be written as: CMR10 300PK * which calls for a 300 dpi PK file for cmr10 from the first mini-disk in alphabetical order which contains the file. Most programs use a filemode of * so that all accessed mini-disks are searched. An advantage of this is that the order in which the disks are searched can be controlled by the letters assigned as the filemodes; someone working on, say, tuning the blacker and fillin values for the cm fonts could place the newly-created GF or PK file on his or her A disk. The new files would then be used in place of an older version of the font. By dividing fonts into different mini-disks based on the output device, or font foundry, or something, mini-disks serve the same function as subdirectories on other systems. Use of * as a filemode provides a user-controllable search path mechanism which is external to programs. DH> MVS allows 8*8 (that is their can be up to eight parts of the DH> file name, each eight characters long. No element may start with DH> a number). Hmm. Mostly correct, but with an important aspect not mentioned. Dataset names under MVS consist of up to eight levels of up to eight characters each. The first character of each level must be a letter, @ #, or $ while the others can be letters, digits, @, #, or $. The data- set name is written with the levels separated by periods. The whole name including periods cannot exceed 44 characters. Under MVS, each dataset occupies a whole number of tracks on disk. For the disks we use here, this means that datasets come in increments of 48K byte allocations! For things like TFM files, this would be a gross waste of disk space. This leads to the aspect not mentioned: "partitioned datasets" (or PDSs). A PDS is simply a library of multiple "members." In a sense, it is like a subdirectory. Member names follow the standard MVS pattern of being >From one to eight characters with the first being a letter, @, #, or $ and the remaining being letters, digits, @, #, or $. Since multiple members can be written to the same track, this results in a considerable savings of disk space. When datasets or members are referenced from within a program, the dataset name is typically *not* used. Instead, the dataset is associated (externally to the program) with a one-to-eight character "DD name." A program then refers either to the DD name, or the DD name and a member name. (This makes names under MVS be 8+8.) The DD name is fixed, but the program can select different member names as necessary. The exact syntax varies with the programming language and library routines used, but typical syntax would be something like: PK300(CMR10) which references member CMR10 from the dataset defined under the DD name of PK300. The actual dataset name might be something like: USR.X066.TX.FONTS.XEROX.PK300 Although it is possible to access datasets and members by dataset name dynamically within a program (ie, without pre-defining them externally), this would normally not be done when working with the various font files: it is less efficient and it disables an external search path capability. A search path capability exists in that up to sixteen PDSs may be associated with a single DD name. When the system searches for a given member, it searches the directories of each PDS in succession and selects the first one that it finds. This gives MVS an external search path capability similar to that available under CMS. ---Tom Reid 20-Mar-1991 16:57:21-GMT,1884;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA28637; Wed, 20 Mar 91 09:57:16 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA06726; Wed, 20 Mar 91 11:54:36 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA09177; Wed, 20 Mar 91 11:53:58 EST Date: Wed, 20 Mar 91 11:53:58 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9103201653.AA09177@ra.cs.umb.edu> To: CSCMLV%CCNYVME.BITNET@cunyvm.cuny.edu Cc: tex-fonts@math.utah.edu In-Reply-To: CSCMLV%CCNYVME.BITNET@CUNYVM.CUNY.EDU's message of Tue, 19 Mar 91 16:53 EST <9103192226.AA26204@cs.umb.edu> Subject: fontname mapping file for TeX Reply-To: karl@cs.umb.edu I received this in mail directed to me, and thought it worthy of resending to the list. My reply appears below the message. Date: Tue, 19 Mar 91 16:53 EST From: CSCMLV%CCNYVME.BITNET@CUNYVM.CUNY.EDU Subject: fontname mapping file for TeX To: karl@cs (Karl Berry) Here is an alternative way for achieving the substitution. VTeX implements an \aliasfont primitive. After \aliasfont cmr10 = adobe-times all references to cmr10 are replaced by adobe-times. This mechanism offers two advantages over a text substitution file: 1) It's dynamic (\aliasfont settings can be saved in a .FMT file). 2) Versions of TeX that implement alterations can use \aliasfont to map unneeded fonts. For example, in VTeX you can set \aliasfont cmsl10 = cmr10 slant 233 and discard cmsl10 altogether. (Karl now) This is true, but there is one giant disadvantage to adding \aliasfont -- the result is no longer `TeX', since it's not 100% compatible. It might be worth adding in concert with other new features, but not by itself. Also, an alias file still addresses the problem at the \font name-filename level. This is somewhat different from \aliasfont's uses (as stated above). 20-Mar-1991 17:12:52-GMT,2534;000000000001 Return-Path: Received: from blackbox.hacc.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA28732; Wed, 20 Mar 91 10:12:49 MST Received: by blackbox.hacc.washington.edu (NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.6 ) id AA11326; Wed, 20 Mar 91 09:09:43 PST From: Thomas B. Ridgeway Message-Id: <9103201709.AA11326@blackbox.hacc.washington.edu> Subject: Re: \aliasfont for name-mapping To: tex-fonts@math.utah.edu Date: Wed, 20 Mar 91 9:09:42 PDT In-Reply-To: <9103201653.AA09177@ra.cs.umb.edu>; from "Karl Berry" at Mar 20, 91 11:53 am X-Mailer: ELM [version 2.2 PL11] Karl Berry forwarded a suggestion on a VTeX-inspired way of aliasing . . . > > Here is an alternative way for achieving the substitution. VTeX implements > an \aliasfont primitive. After > > \aliasfont cmr10 = adobe-times > > all references to cmr10 are replaced by adobe-times. This mechanism offers > two advantages over a text substitution file: > > 1) It's dynamic (\aliasfont settings can be saved in a .FMT file). > 2) Versions of TeX that implement alterations can use \aliasfont to > map unneeded fonts. For example, in VTeX you can set > > \aliasfont cmsl10 = cmr10 slant 233 > > and discard cmsl10 altogether. > >> (Karl now) >> This is true, but there is one giant disadvantage to adding \aliasfont >> -- the result is no longer `TeX', since it's not 100% compatible. >> It might be worth adding in concert with other new features, but not by >> itself. > Another problem is that this is using up TeX memory resources in a rather fabulous way if we are considering putting into a format file a standard set of aliases for however-many fonts we are attempting to standardize names for. My view of the operation of the fontmapping scheme we have been thinking about so far, is that at [what is now] tfm-lookup time, the adapted-to-local- conditions TeX would do a database lookup of only the fonts referenced in the document, and refrain from loading the entire database of aliases (which would put us out of the ballpark on any non-virtual-memory OS). cheers, Tom - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thomas Ridgeway, Director, Humanities and Arts Computing Center/NorthWest Computing Support Center 35 Thomson Hall, University of Washington, DR-10 Seattle, WA 98195 phone: (206)-543-4218 Internet: ridgeway@blackbox.hacc.washington.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 20-Mar-1991 21:27:39-GMT,4464;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA00448; Wed, 20 Mar 91 14:25:28 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA10362; Wed, 20 Mar 91 16:22:11 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA14774; Wed, 20 Mar 91 16:21:31 EST Date: Wed, 20 Mar 91 16:21:31 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9103202121.AA14774@ra.cs.umb.edu> To: info-tex@shsu.BITNET, texhax@cs.washington.edu, tex-archive@math.utah.edu Subject: mode_def collection modes.mf 0.4 released Reply-To: karl@cs.umb.edu I have released version 0.4 of modes.mf. You can get it by anonymous ftp from ftp.cs.umb.edu [192.12.26.23]:pub/tex/modes.mf I will also send it to you by email if you cannot ftp. It is about 30K. This file is a collection of Metafont mode_def's (probably close to all of them). It also makes common definitions for write-white printers and `special' information. If you have mode_def's which are not listed below, please send them to me. I would also appreciate getting definitive information on the NEC and/or Epson printers. (Notes in the file reflect the current state of confusion.) karl@cs.umb.edu mode_def AgfaFourZeroZero = % AGFA 400PS mode_def amiga = % Commodore Amiga. mode_def aps = % Autologic APS-Micro5 mode_def bitgraph = % BBN Bitgraph at 118dpi mode_def boise = % HP 2680A mode_def CanonCX = % e.g., Apple LaserWriter mode_def CanonLBPTen = % e.g., Symbolics LGP-10 mode_def CanonSX = % Canon SX mode_def ChelgraphIBX = % Chelgraph IBX mode_def CItohThreeOneZero = % CItoh 310 mode_def CompugraphicEightSixZeroZero = % Compugraphic 8600 mode_def crs = % Alphatype CRS mode_def DataDisc = % DataDisc mode_def DataDiscNew = % DataDisc with special aspect ratio mode_def dover = % Xerox Dover mode_def EpsonMXFX = % 9-pin Epson MX/FX family mode_def epsonlo = % Epson at 120dpi mode_def HPDeskJet = % HP DeskJet 500 mode_def IBMFourTwoFiveZero = % IBM 4250 mode_def IBMFourTwoOneSix = % IBM 4216 mode_def IBMThreeEightOneTwo = % IBM 3812 mode_def IBMThreeEightTwoZero = % IBM 3820 mode_def IBMVGA = % IBM VGA monitor mode_def imagewriter = % Apple ImageWriter mode_def laserjetlo = % HP LaserJet at 150dpi mode_def LASevenFive = % DEC LA75 mode_def LinotypeOneZeroZeroLo = % Linotype Linotronic [13]00 at 635dpi mode_def LinotypeOneZeroZero = % Linotype Linotronic [13]00 at 1270dpi mode_def LinotypeThreeZeroZeroHi = % Linotype Linotronic 300 at 2540dpi mode_def LNZeroOne = % DEC LN01 mode_def lview = % Sigma L-View monitor mode_def MacMagnified = % Mac screens at magstep 1 mode_def MacTrueSize = % Mac screens at 72dpi mode_def NECTwo = % NEC 2 at 120dpi mode_def NECPSixLo = % NEC P6/P7 at 180dpi mode_def NECPSixMed = % NEC P6/P7 at 360x180dpi mode_def NECPSixHi = % NEC P6/P7 at 360dpi mode_def NeXTprinter = % NeXT 400dpi mode_def NeXTscreen = % 100dpi NeXT monitor mode_def OCESixSevenFiveZeroPS = % OCE 6750PS mode_def okidata = % Okidata mode_def OneTwoZero = % e.g., high-resolution Suns mode_def PrintwareSevenTwoZeroIQ = % Printware 720IQ mode_def QMSOneTwoZeroZERO = % QMS 1200 mode_def RicohFourZeroEightZero = % e.g., the TI Omnilaser mode_def RicohLP = % e.g., the DEC LN03 mode_def sun = % Sun and BBN Bitgraph at true size mode_def supre = % Ultre*setter at 2400dpi mode_def toshiba = % Toshiba 13XX mode_def ultre = % Ultre*setter at 1200dpi mode_def VarityperSixZeroZero = % Varityper Laser 600 mode_def VAXstation = % VAXstation monitor mode_def XeroxThreeSevenZeroZero = % Xerox 3700 mode_def help = % What modes are defined? 21-Mar-1991 3:12:07-GMT,1976;000000000001 Return-Path: Received: from FRIGGA.CLAREMONT.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02472; Wed, 20 Mar 91 20:11:18 MST Date: Wed, 20 Mar 1991 19:10 PST From: Don Hosek Subject: MF for old English available from ymir.claremont.edu To: tex-archive@science.utah.edu, texhax@cs.washington.edu, info-tex@shsu.BITNET, jcb@lfcs.edingurgh.ac.uk Message-Id: <6FB30BE878C01164@HMCVAX.CLAREMONT.EDU> X-Envelope-To: tex-archive@science.utah.edu X-Vms-To: TEX_ARCHIVE,TEXHAX,IN%"info-tex@shsu",IN%"jcb@lfcs.edingurgh.ac.uk" Julian Bradfield's old English files are now available from ymir.claremont.edu in [anonymous.tex.mf.cm.oe]. The readme file follows: This directory contains programs for Old English letters. The fonts created have: D capital eth d eth T capital thorn t thorn G capital yogh g yogh n Polish ogonek accent The thorn is the style that looks like p and b combined. The roman derived fonts (i.e. not cmoeti10) also have u lower-case thorn with side bowl pointing top right (the traditional shape; I happen to think that the other shape blends better with CM); this code is Knuth's, from the cmman font. To make the fonts, just run Metafont on cmoer10 etc; other sizes and styles can be make by adapting the CM parameter and driver files in the obvious way. Julian Bradfield jcb@lfcs.ed.ac.uk -dh --- Don Hosek To retrieve files from ymir via the | dhosek@ymir.claremont.edu mailserver, send a message to | Quixote TeX Consulting mailserv@ymir.claremont.edu with a | 714-625-0147 line saying send [DIRECTORY]FILENAME where DIRECTORY is the FTP directory (sans "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt Binary files are not available by this technique. 23-Mar-1991 12:11:33-GMT,1390;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA20294; Sat, 23 Mar 91 05:11:29 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA19355; Sat, 23 Mar 91 07:08:50 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA17256; Sat, 23 Mar 91 07:07:58 EST Date: Sat, 23 Mar 91 07:07:58 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9103231207.AA17256@ra.cs.umb.edu> To: DHOSEK@hmcvax.claremont.edu, tex-fonts@math.utah.edu Subject: Re: Another thought against the font substitution file as an immediate answer to the font naming problem Don is right, of course -- DVI drivers would also have to implement the substitutions, and current DVI drivers use conflicting formats. But I see this as an argument for TeX doing the substitutions, not against -- if TeX uses some file, then the DVI driver people (at least the noncommercial ones) will probably be willing to follow suit. At least some of the DVI driver authors. 100% agreement is impossible in this (and everything else in life). As for a format, I was thinking of something simple, like adobe-times-roman ...spaces or tabs... ptmr and with comments starting with something (%, I guess) and continuing to the end of the line. I can't think of what else might be needed. I think both Beebe's drivers and dvips already read files like this. karl@cs.umb.edu 25-Mar-1991 0:05:02-GMT,1233;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA25529; Sun, 24 Mar 91 17:04:57 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA24215; Sun, 24 Mar 91 16:03:57 -0800 Date: Sun, 24 Mar 91 16:03:57 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9103250003.AA24215@june.cs.washington.edu> To: karl@cs.umb.edu Cc: tex-fonts@math.utah.edu, tex-implementors@math.ams.com In-Reply-To: Karl Berry's message of Fri, 15 Mar 91 08:28:22 EST <9103151328.AA12638@ra.cs.umb.edu> Subject: fontname mapping file for TeX I would support it. I do much the same thing with symbolic links, and I would find it very hard to live on a system without symbolic links. Your scheme is independent of Unix and has DEK's blessing. THat is all the argument I need. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 25-Mar-1991 0:15:44-GMT,1335;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA25538; Sun, 24 Mar 91 17:15:39 MST Received: from june.cs.washington.edu by MATH.AMS.COM via SMTP with TCP; Sun, 24 Mar 91 19:09:10-EDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA24215; Sun, 24 Mar 91 16:03:57 -0800 Date: Sun, 24 Mar 91 16:03:57 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9103250003.AA24215@june.cs.washington.edu> To: karl@cs.umb.edu Cc: tex-fonts@math.utah.edu, tex-implementors@math.ams.com In-Reply-To: Karl Berry's message of Fri, 15 Mar 91 08:28:22 EST <9103151328.AA12638@ra.cs.umb.edu> Subject: fontname mapping file for TeX I would support it. I do much the same thing with symbolic links, and I would find it very hard to live on a system without symbolic links. Your scheme is independent of Unix and has DEK's blessing. THat is all the argument I need. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 25-Mar-1991 0:22:56-GMT,2171;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA25556; Sun, 24 Mar 91 17:22:50 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA24720; Sun, 24 Mar 91 16:21:56 -0800 Date: Sun, 24 Mar 91 16:21:56 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9103250021.AA24720@june.cs.washington.edu> To: rokicki@Neon.Stanford.EDU Cc: karl@cs.umb.edu, tex-fonts@math.utah.edu, tex-implementors@math.ams.com In-Reply-To: Tomas G. Rokicki's message of Fri, 15 Mar 91 09:22:58 -0800 <9103151722.AA00775@Neon.Stanford.EDU> Subject: fontname mapping file for TeX The reason against \charsubdef being a part of TeX (TM) is that however convenient it may be it violates DEK's basic insistence that for any given input there is only one dvi output. Depending on the environment, you will get various dvi outputs from a "TeX" with \charsubdef included, and the differences are subtle and interwoven into the file. I don't see that font name mapping does that. It may be that we have to decide which name goes into the postamble and the font-def commands---in the case of CM, it is obviously going to be the usual cmr10 style name--- but we can remember the time when SAIL used 6-char names while VMS and Unix were already opening them out to longer names. That certainly involved inconsistencies in both the postamble and font-defs, but you could get around it with links, etc., and in that case as in this, DEK did not feel that the inconsistencies invalidated VMS and Unix TeXs. So long as we always end up with a font which has the expected checksum in the tfm, and which maps the characters into the same positions on all systems, the question of its external file name is not so critical. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 25-Mar-1991 0:32:59-GMT,1811;000000000001 Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA25580; Sun, 24 Mar 91 17:32:52 MST Received: from june.cs.washington.edu by MATH.AMS.COM via SMTP with TCP; Sun, 24 Mar 91 19:35:52-EDT Received: by june.cs.washington.edu (5.64/7.0jh) id AA24982; Sun, 24 Mar 91 16:30:47 -0800 Date: Sun, 24 Mar 91 16:30:47 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9103250030.AA24982@june.cs.washington.edu> To: schoepf@sc.ZIB-Berlin.DE Cc: tex-implementors@math.ams.com In-Reply-To: Rainer Schoepf's message of Fri, 15 Mar 91 18:46:15 +0100 <9103151746.AA16043@sc.zib-berlin.dbp.de> Subject: \charsubdef We do, but the font library is far from complete yet, and in some sense the mapping is still not cast in concrete. \charsubdef allows you to bridge the gap by giving you floating accents if you don't yet have a full complement of accented characters. It's a stopgap, but a very pretty stopgap. Incidentally, I made a suggestion about tfm heights and depths for accented characters (essentially that all accented composites have exactly the same tfm heights as their underlying unaccented substrate) and have got a response only from Barbara Beeton. It is something that is going to have to be decided as part of the 256-character general accented font, because there is only a very limited number of tfm-height indices available. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 26-Mar-1991 15:40:39-GMT,4500;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA05284; Tue, 26 Mar 91 08:40:35 MST Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA27722; Tue, 26 Mar 91 10:37:54 EST Received: by ra.cs.umb.edu (4.1/1.34) id AA15106; Tue, 26 Mar 91 10:36:44 EST Date: Tue, 26 Mar 91 10:36:44 EST From: karl@cs.umb.edu (Karl Berry) Message-Id: <9103261536.AA15106@ra.cs.umb.edu> To: tex-fonts@math.utah.edu Subject: the cork font encoding scheme for tex Reply-To: karl@cs.umb.edu I have several comments and questions about the extended TeX Latin encoding scheme: First, has anyone decided what the TFM coding scheme string should be for it? If not, I propose ``Extended TeX Latin''. Also, I am in need of character names (a la PostScript) for the characters in that font scheme. Have those been specified? Sebastian Rahtz's article in Baskerville, Implementing the extended TeX layout using PostScript fonts, uses some of them, but not all. The characters which were not in any of the Adobe coding schemes (and the names I picked, since I had to choose something) are: 027 compoundwordmark 030 zero for per {million,thousand,...} zerolowered 032 the dotless j dotlessj 0177 the hyphen char. hyphenchar and many of the accented and other non-English characters: 0200--0211, 0213--0221, 0223--0227, 0231, 0233--0236, 0240--0251, 0253--0261, 0263--0267, 0271, 0273--0274, 0320, 0335--0337, 0360, 0375--0376. (Their names are obvious, with the possible exception of the capital es-zet, 0337, which I named `germandblS'.) What is character 0211, the L with an apostrophe after it? I'm curious as to if a language uses such a construction, or if it's just an unfinished rendering of something else. Should 0264, the t-followed-by-apostophe, be t-with-a-caron-accent? That is what its uppercase counterpart, 0224, is. Or are these apostrophes some variant of carons I don't know about? I am wondering what the state of that encoding scheme ``standard'' is -- are further changes being contemplated, or is it frozen? For example, Rahtz's article mentioned above suggested that the visible space character is inappropriate for a text font, a suggestion I agree with. An invisible space character would perhaps be more useful. I don't understand why a visible space character is needed in a font at all -- can't it be created entirely from rules? Also, why are the accented A's (for example) in two different places? I'm sure there is a good reason, but I'm ignorant of it. I am fully in favor of Pierre's suggestion that the accented characters all have the height of the unaccented base; in fact, I don't see any serious alternative, given the limitation in TFM heights. (This limitation might be a good thing to remove in the first ``non-TeX'' TeX, if it can be done in an upward compatible way.) This brings up another question -- don't we need to create and distribute a set of macros and recommend standard ligature sequences for the coding scheme? If the TeX input isn't agreed on, some of the advantage of a standard encoding scheme will be lost. The biggest question in my mind is how to take advantage of all the accented characters. I can imagine several alternatives: 1) change \', \`, and the like to produce a \char command if its argument is one of the grave-accented characters in the encoding, and an \accent command otherwise. This would require the least change to existing input files (not an overriding consideration, in my view). 3) define ligatures in the font so that A + grave => Agrave (that is, 0101 + 00 => 0192). Then define a new control sequence \gravechar (e.g.), or perhaps redefine \grave to do \char outside of math mode, so that the user can type `\grave A' anywhere. Then \grave should do \accent, if its argument isn't one of the grave-accented characters in the encoding. 3) make new control sequences \Agrave, \Ntilde, and the like to produce them. This is the easiest thing to do, but the most painful to use. Of course, all of this is unnecessary when keyboards can produce Agrave or whatever directly. The question is what to do when they can't. One more question: are discussions of a math symbol coding scheme (and others, such as a companion to the basic text font to provide many missing symbols, like bullets and daggers and paragraphs) ongoing, and if so, in what forum? If it's open, I'd like to join. Thanks. karl@cs.umb.edu 26-Mar-1991 16:13:46-GMT,2594;000000000001 Return-Path: Received: from MATH.AMS.COM by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA05378; Tue, 26 Mar 91 09:13:40 MST Date: Tue 26 Mar 91 11:15:40-EST From: bbeeton Subject: Re: the cork font encoding scheme for tex To: karl@cs.umb.edu Cc: tex-fonts@math.utah.edu Message-Id: <670004140.0.BNB@MATH.AMS.COM> In-Reply-To: <9103261536.AA15106@ra.cs.umb.edu> Mail-System-Version: i like the coding scheme name "extended tex latin" and will vote for it if there isn't already an existing name. re names for characters, i will see if i can find what the iso and unicode folks do for the lowered zero. for the dotless j, this should be parallel to whatever's used for dotless i. for the hyphen, what's wrong with just plain "hyphen"? (i must be missing something ...) the "L with apostrophe" is actually, i believe, the accepted rendition of the linguistic "L with hacek"; with a little research, i can unearth a list of the languages in which it occurs. actually, the association has already been recognized in the case of t/T. re the usefulness of a visible space character, in a typewriter font, it is most useful, and though it could be made from rules, getting the weights right is a real pain -- they really should be drawn with the uniform-weight metafont pen, and that information isn't available within tex. (i've had to research this sort of thing before, and it's not really fun.) my understanding of the purpose of the extended font is to take advantage of the ability in tex 3.0 to use 8-bit input. of course, until we have machines and networks that can deal with 8-bit encoding uniformly and reliably, it's either a dream or a hoax. in the meantime, though, i guess control sequences and ligature encodings are needed. what's really important is to design some input scheme that can be used reliably with the hyphenation mechanism. that's not likely to use lots of control sequences; the german " model may be useful here. re the matter of a corresponding math symbol encoding scheme, mike ferguson some time ago asked the ams to undertake work on that, which boils down to ralph youngen, mike downes and me, with occasional other kibitzing. we've identified several problems that are making the job much more difficult than it might be, in particular the limit on tfm heights and widths, for which there isn't any obvious solution nearly as nice as the one suggested for accented letters. karl, if you have suggestions, please get in touch with us. -- bb ------- 29-Mar-1991 19:10:23-GMT,986;000000000001 Return-Path: Received: from watson.ibm.com ([129.34.139.4]) by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA07580; Fri, 29 Mar 91 12:10:20 MST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R1) with BSMTP id 3604; Fri, 29 Mar 91 14:10:12 EST Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R1) with TCP; Fri, 29 Mar 91 14:10:13 EST Received: from kundry.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528) id AA13688; Fri, 29 Mar 91 14:10:11 -0500 Received: by kundry.watson.ibm.com (DCE STD CONFIG 2.2 - AIX 2.1.2/2.0) id AA00737; Fri, 29 Mar 91 14:10:14 EST Date: Fri, 29 Mar 91 14:10:14 EST From: rocky@watson.ibm.com (Rocky Bernstein) Message-Id: <9103291910.AA00737@kundry.watson.ibm.com> X-External-Networks: yes To: tex-fonts-request@math.utah.edu In-Reply-To: <9103291753.AA19544@ra.cs.umb.edu> Subject: mode_def names and Advanced-Function printers Reply-To: rocky@watson.ibm.com Subscribe 29-Mar-1991 20:00:19-GMT,8112;000000000001 Return-Path: Received: from watson.ibm.com ([129.34.139.4]) by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA07791; Fri, 29 Mar 91 13:00:15 MST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R1) with BSMTP id 4019; Fri, 29 Mar 91 15:00:10 EST Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R1) with TCP; Fri, 29 Mar 91 15:00:07 EST Received: from kundry.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528) id AA20943; Fri, 29 Mar 91 15:00:04 -0500 Received: by kundry.watson.ibm.com (DCE STD CONFIG 2.2 - AIX 2.1.2/2.0) id AA00759; Fri, 29 Mar 91 15:00:07 EST Date: Fri, 29 Mar 91 15:00:07 EST From: rocky@watson.ibm.com (Rocky Bernstein) Message-Id: <9103292000.AA00759@kundry.watson.ibm.com> To: Nelson H.F. Beebe In-Reply-To: Subject: tex-fonts list, submitting something Reply-To: rocky@watson.ibm.com Gee that was fast. Is it possible to get say just the last 50 pages or so. I'm new to this game. What I really was trying to do was submit the below to TeXhax. Karl Berry gave me your address and suggested that this would be a better place for such a posting. (We have an NNTP server around here, but tex-fonts is not on it.) How do I submit something? Subject: What's in a (mode_def) name? A mode by any other name... I would like to make a proposal and solicit comments for a new scheme for selecting MetaFont mode_def names. But first let me review what I believe has been the trend for naming mode_defs. In the olden days, the name of a printer was used as the name of the mode_def, e.g. imagen or dover. This had the definite advantage that it was easy to determine what mode_def one should use for a printer. Well, almost... As time went on (and printer manufacturers made more kinds of printers), the model name was included in the mode name. Model names often include numbers. However, MetaFont's scanning rules are somewhat akin to TeX's scanning rules---identifiers are not normally allowed to contain numbers. So someone had the bright idea to write out the numbers in English, e.g. IBMThreeTwoOneSix. (Or was that IBMThirtyTwoSixteen as it is more commonly pronounced? I believe the former was used for regularity.) Then it was observed that many printers have a common print engine. In the case of the Imagen 8/300 and the Apple Laserwriter, I believe the print engine is made by Canon. Also, the same print engine is often used across models, for example the HP LaserJet, and the HP LaserJet Series IIp. Perhaps this is one reason that one could get by for a long time by just specifying a printer name without a model. Looking at some of the current collection of mode_def files (U_Wash.mf and modes.mf), I believe this is where things stand now. However there are problems with using the print engine name. Unlike the printer and/or model names, printer manufacturers often are not as anxious to reveal the print engine as they would be to give the resolution of the printer. There is good reason for this. One printer manufacturer and vendor that I am familiar with, marketed a printer which in the early stages of manufacturing used a 300 dot-per-inch print engine made by Canon. In order to cut manufacturing costs, they subsequently switched to a cheaper 300 dot-per-inch printer made by Ricoh. But then Ricoh realized that it could cut its cost by redesigning its print mechanism. In all cases though, the printer name (and perhaps model) stayed the same! The print engine one might find in this printer is merely a function of when and where the printer bought. Another problem with specifying the printer name or printer engine is that there may be variations within a single printer engine. The printer may act differently when it is low on toner, or when it is just turned on or left on for long periods of time. Perhaps there are even variations depending on the kind of toner cartridge used. An extreme case of print-engine variation is in the IBM 3825 and IBM 3835 printers. These printers have a knob that allows a service engineer to specify one of up to ten settings. Don't get me wrong---I don't think that this is a bad thing. It does allow the customer to set the type of output he/she wants or is willing to pay for in toner. It does however make a font librarian's job harder. I believe what would be the most helpful is to have the characteristics of the print engine rather than the vendor of the print engine encoded in the mode name. In particular, I believe the pixels-per-inch, the blackness, aspect-ratio, white-writeness, and perhaps the fillin are important. (I suspect the o_correction is largely a function of the other parameters, particularly the pixels_per_inch.) These fields inside a name should probably not take on exact values as they must be in a mode definition but should represent a range of values. For example, ``light'' might mean a value anywhere from 0.0 to 0.3. Here is a scenario: I want to get some TeX fonts off a server for my FooBar model XYZZY printer. This is a very new printer for which there is no mode_def around yet. (And even if there were, my server doesn't have rasters generated for these yet; I also am unable to run MetaFont.) I don't have time to wait until a mode_def is decided on and raster are created---I need something now. I am clever and know that Gitsu makes the print engine. Okay, quick. Am I better off with the FooBar model Plugh printer or the Banana printer which also has a print engine made by Gitsu? Note that in modes.mf, the CanonCX printer is a 300 dpi printer while the CanonLBPTen is a 240 dpi printer. There is a big difference between 240 dpi printers and 300 dpi printers. I would doubt if one would be happy using one mode for the other. Similarly, although the CanonCX and CanonSX printers are 300dpi, the CanonSX printer has a fillin of -.2 (which is probably wrong) and is white-write, while the SX printer has a fillin of .2 and is not. Again, I doubt whether one would be that happy substituting one for the other. (I bet it would be better to substitue mode RicohA for CanonCX.) On the other hand, if names for the CanonCX, CanonSX, and CanonLBPTen modes were something like 030xDPI-Light-FillinLight, 030xDPI-Light-FillinNeg-WriteWhite, and 024xDPI-Light-FillinLight (I know these are illegal names and too long for my needs), I would would have a good idea which I should use say for the IBM 4216 printer which I may or may not know to in fact have a Ricoh engine. If I print out something and the output looks too light, simple: I look for the next darker mode_def name. Even if I don't know a priori what the resolution the printer I have is, I can again print something out (like CMINCH) and see if it meets my expectations. If not, it is clear how I would change the font library or search for a different mode_def. I know this puts a little more complication up front. But it is more straightforward and ultimately easier for users to comprehend. I'd hate to set things up so that for my Canon SuperDuper printer I have to specify RicohB (rather than CanonCX, CanonSX, or CanonLBPTen) to get the best output. While on my Ricoh Tried-and-True printer I have to specify CanonSX rather than ... My last comment is about the length of mode_def names. I believe it is useful to put the EXACT mode name as a directory name under the font path e.g. /usr/local/lib/tex/fonts/CanonCX/... (or as a disk name CANONCX:...) Some operating systems limit the number of characters in a directory entry or disk name. And even on those systems that allow longer names, people do not like to type in or be confronted with such a long directory name. A suggestion is that the size of the real mode_def names be kept relatively short. One can always have additional variables, as modes.mf does, to map full printer names and or printer models and or printer engines to a relatively short name for the convenience of users. Comments? R. Bernstein IBM Research Thanks to Paul Dantzig for the info on IBM printers. 30-Mar-1991 0:07:37-GMT,5057;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA08891; Fri, 29 Mar 91 17:07:34 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA06459; Fri, 29 Mar 91 16:07:28 -0800 Date: Fri, 29 Mar 91 16:07:28 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9103300007.AA06459@june.cs.washington.edu> To: karl@cs.umb.edu, ridgeway@blackbox.hacc.washington.edu, tex-fonts@math.utah.edu Subject: [karl@cs.umb.edu: the cork font encoding scheme for tex] > What is character 0211, the L with an apostrophe after it? I'm > curious as to if a language uses such a construction, or if it's just an > unfinished rendering of something else. > Should 0264, the t-followed-by-apostophe, be t-with-a-caron-accent? > That is what its uppercase counterpart, 0224, is. Or are these > apostrophes some variant of carons I don't know about? Both of these are indications of palatalization in slavic languages especially. The apostrophe character indicates a consonantal y offglide from the consonant, which also forces the following vowel forward in the mouth. L'et == lyet, bilo == b(w)ilo (with a back of the mouth pronunciation of l. > I am wondering what the state of that encoding scheme ``standard'' is -- > are further changes being contemplated, or is it frozen? For example, > Rahtz's article mentioned above suggested that the visible space > character is inappropriate for a text font, a suggestion I agree with. > An invisible space character would perhaps be more useful. I don't > understand why a visible space character is needed in a font at all -- > can't it be created entirely from rules? Also, why are the accented A's > (for example) in two different places? I'm sure there is a good reason, > but I'm ignorant of it. Somebody (bb?) later in this mail list argues in favor of the visible space character in some faces, and if we are going to make this mapping cover a wide variety of text categories, then the cell needs to be reserved for that character. It might be argued that the character in that cell can be in fact invisible in the case of a font that is not monospace. > I am fully in favor of Pierre's suggestion that the accented characters > all have the height of the unaccented base; in fact, I don't see any > serious alternative, given the limitation in TFM heights. (This > limitation might be a good thing to remove in the first ``non-TeX'' TeX, > if it can be done in an upward compatible way.) Barbara argues that it is not really necessary to consider it a limitation. If the accented characters have the height and depth of the entire glyph, rather than just the height and depth of the unaccented base, they cause unexpected and often undesirable things to happen at the point of \topskip and at interlineskip in tightly leaded formats. > This brings up another question -- don't we need to create and > distribute a set of macros and recommend standard ligature sequences for > the coding scheme? If the TeX input isn't agreed on, some of the > advantage of a standard encoding scheme will be lost. The biggest > question in my mind is how to take advantage of all the accented > characters. I can imagine several alternatives: > 1) change \', \`, and the like to produce a \char command if its > argument is one of the grave-accented characters in the encoding, and > an \accent command otherwise. This would require the least change to > existing input files (not an overriding consideration, in my view). > 2) define ligatures in the font so that A + grave => Agrave (that is, > 0101 + 00 => 0192). Then define a new control sequence \gravechar > (e.g.), or perhaps redefine \grave to do \char outside of math mode, > so that the user can type `\grave A' anywhere. Then \grave should do > \accent, if its argument isn't one of the grave-accented characters > in the encoding. I am strongly in favor of this one. (I renumbered it 2) > 3) make new control sequences \Agrave, \Ntilde, and the like to produce > them. This is the easiest thing to do, but the most painful to use. > Of course, all of this is unnecessary when keyboards can produce Agrave > or whatever directly. The question is what to do when they can't. > One more question: are discussions of a math symbol coding scheme (and > others, such as a companion to the basic text font to provide many > missing symbols, like bullets and daggers and paragraphs) ongoing, and > if so, in what forum? If it's open, I'd like to join. send a message to Beebe@math.utah.edu Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 1-Apr-1991 21:04:43-GMT,3345;000000000001 Return-Path: Received: from watson.ibm.com ([129.34.139.4]) by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA23169; Mon, 1 Apr 91 14:04:36 MST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R1) with BSMTP id 4684; Mon, 01 Apr 91 16:02:58 EST Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R1) with TCP; Mon, 01 Apr 91 16:02:59 EST Received: from kundry.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528) id AA16989; Mon, 1 Apr 91 16:02:59 -0500 Received: by kundry.watson.ibm.com (DCE STD CONFIG 2.2 - AIX 2.1.2/2.0) id AA01231; Mon, 1 Apr 91 16:03:02 EST Date: Mon, 1 Apr 91 16:03:02 EST From: rocky@watson.ibm.com (Rocky Bernstein) Message-Id: <9104012103.AA01231@kundry.watson.ibm.com> X-External-Networks: yes To: tex-fonts@math.utah.edu Subject: maintaining modes.mf Reply-To: rocky@watson.ibm.com I was asked, and considered helping out in the maintanance of modes.mf. Some thoughts on the matter of how modes.mf could be handled: For myself, what I'd like to do is first settle on how modes.mf works. That is how names will be given, do we redefine end, allow/force flexible mode_def setting?, and set some guidelines or standards for submitting a mode_def. Perhaps we could give some guidance in how to determine the mode_def. Once we have this foundation, I believe we will be in a better position to handle the complexity of the task. If someone wants to submit a mode_def, I'd sort of like to know what criteria were used (or if the guidelines that were set were followed), and would ask *that* person to be responsible for say a class of printers that the mode_def claims to serve. If there are questions or problems concerning the mode_def presumably that person would handle them. (I would personally like fewer well-considered mode settings than a lot of half-baked ones.) So although I can't take over all of the modes.mf activity, here is what I probably could handle: I volunteer to field or coordinate all mode_def-related question concerning the following IBM printers: IBM 4216, IBM 4019, IBM 3800, IBM 3820, IBM 3827, IBM 3825, IBM 3812, IBM 3816, IBM 4250. (I am hoping you don't notice my not offering to take over Proprinter-type or IBM graphic a.k.a Epson FX/MX-type printers.) I think it is great to have people volunteer and mail in information (or numbers and code that perhaps they pulled off a bulletin board). But unless people are willing to take some sort of responsibility, I think what winds up is just more chaos of the sort I am well familiar with being at a Research organization. (Perhaps academicians can sympathize with this too.) While I am volunteering time I don't have, I would also say that I would volunteer to help write the set of guidelines I outlined above and a guide to assist in debugging a MetaFont mode_def for a printer. With respect to the last item, Pierre Mackay seems to have a good handle on how to set the o_correction. I hope this gets written into the guide, (or into modes.mf until a guide is written.) Which reminds me, I would volunteer to redo modes.mf in the few changes that I have suggested and add the comments I have received or read on the matter. But before I would redo all of modes.mf, I should probably wait a bit for opinions the suggestions. rocky 2-Apr-1991 9:44:05-GMT,1607;000000000001 Return-Path: Received: from CC.UTAH.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA00530; Tue, 2 Apr 91 02:44:02 MST Received: from DDATHD21.BITNET (XITIJSCH@DDATHD21) by CC.UTAH.EDU with PMDF#10043; Tue, 2 Apr 1991 02:43 MST Received: from PCSITI.FB20.THD.DA.EUROPE by DDATHD21.BITNET via GNET with RJE with RCOM ; 02 Apr 91 11:42:53 Date: Tue, 2 Apr 91 11:36:50 MSZ From: XITIJSCH@DDATHD21.BITNET Subject: Re: maintaining modes.mf To: tex-fonts@math.utah.edu Message-Id: <1CFC58B05E4037BA@CC.UTAH.EDU> X-Envelope-To: tex-fonts@math.utah.edu X-Originally-From: Joachim Schrod X-Munix-To: tex-fonts@math.utah.edu (TeX fonts discussion) X-Mailer: ELM [version 2.3 PL0] A first question which comes in my mind: Shall a mode_def be used for the creation of all fonts for one device, or shall there be different mode_def's for some fonts? I know that Bart Childs has taken the latter approach for at least one output device -- I prefer the former one. It's just trading efficiency of work against output quality of ugly output devices. Besides, can anyone contact me who had experiences with the mode_def for a Ricoh4080? We have a TI Omnilaser, and in our opinion the glyphs were not ok. We tried about 75 combinations of new values to get an other mode_def. I want to share experiences before posting this new one. -- Joachim =========================================================================== Joachim Schrod Computer Science Department Technical University of Darmstadt, Germany 2-Apr-1991 16:27:26-GMT,4288;000000000001 Return-Path: Received: from watson.ibm.com ([129.34.139.4]) by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02571; Tue, 2 Apr 91 09:27:13 MST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R1) with BSMTP id 3609; Tue, 02 Apr 91 11:25:58 EST Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R1) with TCP; Tue, 02 Apr 91 11:27:01 EST Received: from kundry.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528) id AA19541; Tue, 2 Apr 91 11:27:01 -0500 Received: by kundry.watson.ibm.com (DCE STD CONFIG 2.2 - AIX 2.1.2/2.0) id AA01536; Tue, 2 Apr 91 11:27:04 EST Date: Tue, 2 Apr 91 11:27:04 EST From: rocky@watson.ibm.com (Rocky Bernstein) Message-Id: <9104021627.AA01536@kundry.watson.ibm.com> X-External-Networks: yes To: tex-fonts@math.utah.edu Cc: XITIJSCH@DDATHD21.BITNET In-Reply-To: <1CFC58B05E4037BA@CC.UTAH.EDU> Subject: Re: maintaining modes.mf Reply-To: rocky@watson.ibm.com >A first question which comes in my mind: Shall a mode_def be used for >the creation of all fonts for one device, or shall there be different >mode_def's for some fonts? Good point, but this is yet another reason to use characteristics rather than printer engine or printer model. (No one has yet to suggest printer *name*, i.e. ``Fred'' or ``Tania.'' Sorry, I haven't been getting enought sleep.) I know that for the 240 dpi printers I've played with, cmtt's diagonals for M's and W's looked better with less blacker. However, the font then didn't match in weight with the rest of the fonts. I also couldn't get agreement that it was that much better either. What I did was have a smarter program calling Metafont to look up in a table what mode name to use given the font name, device and magnification. However the proposal of using the font characteristics in the name is independent of whether one mode_def is used for a device or not. By using the characteristics, the mode names would probably be close for a given printer: e.g. 240DPI-Black.5... vs. 240DPI-Black.4... On the train in today, I was spec.ing out name spaces. I figure, I can easily fit in all the information I need in eight characters and simply letters. To wit: Two letters for the pixels_per_inch One letter for the blacker One letter for the fillin One letter for the aspect_ratio One letter for the whether write_white or not, One letter for different variations of the above that fall within the same name This leaves 1 letter left! (Karl, eat your heart out.) With two letters for the pixels per inch, this gives 26 * 26 = 676 possibilities. Using one combination for a range of 10 pixels per inch I think should be enough. (Even if 6760 dpi is not large enough, at that resolution, you know the what the blacker, o_correction, and fillin are going to be and can use these fields.) Blacker increments of .1 between 0 and 1 might be okay. For safety I suppose we could go with .05. Comments? For fillin increments, we would probably have to accommodate the negative numbers that are already there. Increments of .1 between -1 and 1? Or between -.2 and 1? Again, I have no feel for what ranges and increments should be used. To map aspect ratios into one of 10 or 20 (or 26) values a a suggestion is something like 1/1, 1/2, 1/3, ... and 2/1, 3/1, where 1/1 really means between 1/2 and 2/1. I just throw this out as an idea. I think one would want to have a lot more granularity around 1 than what I have here. For example, 10/10, 9/10, 8/10, ... and 11/10, 12/10, ... Although I hate complex codes where simple ones will do (perhaps this is due to an overexposure in the environment I am in) I don't see any way around a coded mode_def naming scheme. I have it in the back of my mind that if such a scheme were used, I would to modify the ? macro in modes.mf to display in more verbose terms what each mode meant. Also, I would try to provide a program that decodes/encodes a name. (I was thinking I'd write it in TeX or Metafont so it would be portable.) Also, I would suggest (this is independent of the name) that modes_def's in modes.mf be sorted by pixels_per_inch and within that by blacker. (After this I don't care if it is by write_whiteness next or fillin, or o_correction or name.) rocky 2-Apr-1991 16:55:54-GMT,4447;000000000001 Return-Path: Received: from watson.ibm.com ([129.34.139.4]) by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02675; Tue, 2 Apr 91 09:55:51 MST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R1) with BSMTP id 4184; Tue, 02 Apr 91 11:54:39 EST Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R1) with TCP; Tue, 02 Apr 91 11:55:44 EST Received: from kundry.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528) id AA23560; Tue, 2 Apr 91 11:55:43 -0500 Received: by kundry.watson.ibm.com (DCE STD CONFIG 2.2 - AIX 2.1.2/2.0) id AA01539; Tue, 2 Apr 91 11:55:46 EST Date: Tue, 2 Apr 91 11:55:46 EST From: rocky@watson.ibm.com (Rocky Bernstein) Message-Id: <9104021655.AA01539@kundry.watson.ibm.com> X-External-Networks: yes To: tex-fonts@math.utah.edu Subject: Some Miscellaneous MetaFont hacks Reply-To: rocky@watson.ibm.com Tom Jennings has suggested the following change to the Punk fonts: reduce the randomness allowed on numbers to make them more legible. I also think that the randomness on the X, should be reduced too to make it less like a V or an A. In running a program I wrote to check the consistency of PK font libraries using \mode_special information, Jim Hafner noticed that a couple of the fonts didn't have this. On further investigation, I noticed that the reason for this is that is that a number of the MetaFont sources (such as a number of the AMS fonts) use ``end'' rather than ``bye'' to finish MetaFont execution. Looking at the MetaFont book, I notice that there are *two* definitions for bye, one in Plain MF on page 278 which just does a let bye = end. And another on page 321 which is more like what is in U_Wash.mf. Given the double definition of bye in the MetaFont book, I believe that even if we could convince all the MetaFont authors to switch over to ``bye'' instead of ``end,'' there is going to be future confusion by people writing MetaFont code. Therefore, I propose we keep ``bye'' as a redefinition of end (like it is in Plain MetaFont) and redefine ``end'' to do the additional things we want. To be more concrete, I propose the following changing the code that deals with ``bye'' in U_Wash.mf and modes.mf to: inner end; let realend = end; % We're about to redefine end. Save the primitive one. def end= if fontmaking > 0: font_family font_identifier_; coding_scheme font_coding_scheme_; font_face_byte max(0,254-round 2designsize); font_mode_specials; fi realend enddef; outer end,realend; This fixed the problems I had with all of the MetaFont sources, except the slur and beam from MuTeX (which also appear in MusicTeX). Suggestions follow. If anyone has an e-mail address for Andrea Steinbach or Angelika Schofer, I'd appreciate it if you could forward this to me, or forward everything after the next paragraph of this note. Even if you only have a external mail address (sometimes referred to as a ``snail-mail'' address) I'd appreciate receiving this. (I have tried looking at old TUGBoat Membership lists like Karl Berry suggested, to no avail.) First and foremost I would like to thank all the people who have contributed to MTeX (aka MuTeX), especially its authors Andrea Steinbach and Angelika Schofer. I have a couple of suggestions concerning the MetaFont sources. In a number of the MetaFont files, such as the MetaFont code for the slurs and beams, there is a numeric variable called ``length.'' Unfortunately, length is also a MetaFont primitive, and is also used in some code suggested on page 320 of the MetaFont book for putting font information into a GF or PK file. My suggestion then, is to change the use of these variables to something else (such as s_length or slur_length and b_length or beam_length). Another very minor change I would suggest is to set the variables font_identifier and font_coding_scheme. Although get passed merely as comments in a GF, PK and TFM files, they allow automatic interpretation by programs somewhat easier. For example, a program that tries to display or render information about a font could use this information to try to understand how to do its job. I would be happy to provide changed sources on request to make this very concrete. Feel free to reply in German. I would be happy to provide a translation of this into German on request---I thought however it might be dangerous to try to do so initially. Sincerely, Rocky Bernstein 2-Apr-1991 16:55:54-GMT,4447;000000000011 Return-Path: Received: from watson.ibm.com ([129.34.139.4]) by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA02675; Tue, 2 Apr 91 09:55:51 MST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R1) with BSMTP id 4184; Tue, 02 Apr 91 11:54:39 EST Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R1) with TCP; Tue, 02 Apr 91 11:55:44 EST Received: from kundry.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528) id AA23560; Tue, 2 Apr 91 11:55:43 -0500 Received: by kundry.watson.ibm.com (DCE STD CONFIG 2.2 - AIX 2.1.2/2.0) id AA01539; Tue, 2 Apr 91 11:55:46 EST Date: Tue, 2 Apr 91 11:55:46 EST From: rocky@watson.ibm.com (Rocky Bernstein) Message-Id: <9104021655.AA01539@kundry.watson.ibm.com> X-External-Networks: yes To: tex-fonts@math.utah.edu Subject: Some Miscellaneous MetaFont hacks Reply-To: rocky@watson.ibm.com Tom Jennings has suggested the following change to the Punk fonts: reduce the randomness allowed on numbers to make them more legible. I also think that the randomness on the X, should be reduced too to make it less like a V or an A. In running a program I wrote to check the consistency of PK font libraries using \mode_special information, Jim Hafner noticed that a couple of the fonts didn't have this. On further investigation, I noticed that the reason for this is that is that a number of the MetaFont sources (such as a number of the AMS fonts) use ``end'' rather than ``bye'' to finish MetaFont execution. Looking at the MetaFont book, I notice that there are *two* definitions for bye, one in Plain MF on page 278 which just does a let bye = end. And another on page 321 which is more like what is in U_Wash.mf. Given the double definition of bye in the MetaFont book, I believe that even if we could convince all the MetaFont authors to switch over to ``bye'' instead of ``end,'' there is going to be future confusion by people writing MetaFont code. Therefore, I propose we keep ``bye'' as a redefinition of end (like it is in Plain MetaFont) and redefine ``end'' to do the additional things we want. To be more concrete, I propose the following changing the code that deals with ``bye'' in U_Wash.mf and modes.mf to: inner end; let realend = end; % We're about to redefine end. Save the primitive one. def end= if fontmaking > 0: font_family font_identifier_; coding_scheme font_coding_scheme_; font_face_byte max(0,254-round 2designsize); font_mode_specials; fi realend enddef; outer end,realend; This fixed the problems I had with all of the MetaFont sources, except the slur and beam from MuTeX (which also appear in MusicTeX). Suggestions follow. If anyone has an e-mail address for Andrea Steinbach or Angelika Schofer, I'd appreciate it if you could forward this to me, or forward everything after the next paragraph of this note. Even if you only have a external mail address (sometimes referred to as a ``snail-mail'' address) I'd appreciate receiving this. (I have tried looking at old TUGBoat Membership lists like Karl Berry suggested, to no avail.) First and foremost I would like to thank all the people who have contributed to MTeX (aka MuTeX), especially its authors Andrea Steinbach and Angelika Schofer. I have a couple of suggestions concerning the MetaFont sources. In a number of the MetaFont files, such as the MetaFont code for the slurs and beams, there is a numeric variable called ``length.'' Unfortunately, length is also a MetaFont primitive, and is also used in some code suggested on page 320 of the MetaFont book for putting font information into a GF or PK file. My suggestion then, is to change the use of these variables to something else (such as s_length or slur_length and b_length or beam_length). Another very minor change I would suggest is to set the variables font_identifier and font_coding_scheme. Although get passed merely as comments in a GF, PK and TFM files, they allow automatic interpretation by programs somewhat easier. For example, a program that tries to display or render information about a font could use this information to try to understand how to do its job. I would be happy to provide changed sources on request to make this very concrete. Feel free to reply in German. I would be happy to provide a translation of this into German on request---I thought however it might be dangerous to try to do so initially. Sincerely, Rocky Bernstein 5-Apr-1991 4:11:59-GMT,1700;000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AB24590; Thu, 4 Apr 91 21:11:54 MST Received: from TAMVM1.TAMU.EDU (MAILER@TAMVM1) by CC.UTAH.EDU with PMDF#10043; Thu, 4 Apr 1991 18:56 MST Received: from TAMVM1 (X066TR) by TAMVM1.TAMU.EDU (Mailer R2.07) with BSMTP id 6885; Thu, 04 Apr 91 19:53:35 CST Date: Thu, 04 Apr 91 19:36:28 CST From: "Thomas J. Reid" Subject: Re: maintaining modes.mf In-Reply-To: Message of Tue, 2 Apr 91 11:27:04 EST from To: TeX fonts discussion Message-Id: <37454D96DC40812B@CC.UTAH.EDU> X-Envelope-To: tex-fonts@math.utah.edu Organization: Texas A&M University Computing Services Center >... >What I did was have a smarter program >calling Metafont to look up in a table what mode name to use given >the font name, device and magnification. >... > >rocky At Texas A&M, we took a similar approach to tuning fonts for our Xerox printers. At first, we had a file that listed each font name and the corresponding mode_def name to be used. (There were about ten different mode_defs.) Later, we wrote a shell script (for UNIX) and an EXEC (for VM/CMS) which took a file of font names, blacker, and fillin value and ran METAFONT with a generic mode_def which set the "constant" values such as resolution, aspect ratio, etc. I think that instead of trying to come up with a relatively cryptic scheme which maps parameter values to mode_def names, we should use a single mode_ def name for all fonts for a given device and have a "smart program" (when needed) which reads a file of names and blacker/fillin values. ---Tom Reid 5-Apr-1991 17:58:35-GMT,4834;000000000001 Return-Path: Received: from watson.ibm.com ([129.34.139.4]) by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA29640; Fri, 5 Apr 91 10:57:51 MST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R1) with BSMTP id 2829; Fri, 05 Apr 91 12:56:27 EST Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R1) with TCP; Fri, 05 Apr 91 12:57:33 EST Received: from kundry.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528) id AA20403; Fri, 5 Apr 91 12:57:31 -0500 Received: by kundry.watson.ibm.com (DCE STD CONFIG 2.2 - AIX 2.1.2/2.0) id AA02060; Fri, 5 Apr 91 12:57:35 EST Date: Fri, 5 Apr 91 12:57:35 EST From: rocky@watson.ibm.com (Rocky Bernstein) Message-Id: <9104051757.AA02060@kundry.watson.ibm.com> X-External-Networks: yes To: tex-fonts@math.utah.edu Cc: "Thomas J. Reid" In-Reply-To: <37454D96DC40812B@CC.UTAH.EDU> Subject: Re: maintaining modes.mf Reply-To: rocky@watson.ibm.com >I think that instead of trying to come up with a relatively cryptic scheme >which maps parameter values to mode_def names, we should use a single mode_ >def name for all fonts for a given device and have a "smart program" (when >needed) which reads a file of names and blacker/fillin values. >---Tom Reid One problem I am trying to address is: How do I organize font directories or servers which make fonts available, so that users can determine which fonts would be best for a given printer (or device). I would like to set things up as simply as possible, with the least amount of confusion, and in a way that minimizes operating-system dependencies. Factors: Often servers provide fonts in only rasterized form, such as in PK format, no MetaFont source is around. It would be nice to have a scheme that does not rely on the existence of modes.mf (or access to the mode_def file, the program used by creator of the rasters, or an auxiliary program). I may not have access to these files/programs, or access only to a different version that doesn't contain the necessary information, e.g. New devices spring into existence. Also having a scheme gives regularity and assistance when new names (or MetaFont parameters) are needed. Many people are not MetaFont wizards. It is desirable to make things as explicit as possible. Who's going to know that you really have to run another program to extract information? And currently, many of the servers that provide PK fonts do not even have this information in the PK files. For example, because most of the AMS fonts use ``end'' rather than ``bye'', and given the way waits.mf, modes.mf, or U_Wash.mf used to/currently work, this information is not in the file. For these kinds of rasters, one can still provide help to users by just putting the fonts in a directory that has a useful name. One approach that has been tried before is to create directories which list the dots-per-inch of the device (e.g. ..tex/fonts/300dpi/... That Tom Reid, myself, and others use multiple settings of blacker, fillin, ... for a given pixels_per_inch, suggests the inadequacy of such a scheme. I don't see how using a single mode_def name improves anything. In fact it looks like it makes things harder unnecessarily. If you can create a mode_def on the fly, is it that much harder to create on the fly a useful name? If you hypothesize ``smart programs'' to extract the information, then from your standpoint it shouldn't matter what format of name others might find useful. Compared with the problems involved with providing a ``smart'' program for every operating system and hypothesizing that mode_special information will be in GF and PK files, it seems easier just to standardize names that convey what kinds of devices a given rasterized font file would be most useful on. Perhaps one shouldn't think of the proposal as a way to to assign mode_def names, but as way to assign a part of the directory or disk name to give a rough idea of how the MetaFont rasters were created; however I that think that it is convenient for using as the mode_def name. Clarification on why modes.mf should be might sorted by pixels_per_inch and then by blacker: My thought was merely to make it easy for someone to find the next used value in the sequence. Currently modes.mf is sorted alphabetically. (Sorting alphabetically is not inconsistent with sorting by pixels_per_inch and within that blacker---it depends on the encoding.) It might be helpful to give printer models alphabetically or by logical printer group for the purpose of making it easier to find a given device. This can be done by collecting the additional variable assignments in one place rather than have them interspersed with the mode_def, and organizing the assignments in a convenient way. rocky 5-Apr-1991 19:45:08-GMT,2268;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA00575; Fri, 5 Apr 91 12:45:04 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA23115; Fri, 5 Apr 91 11:44:41 -0800 Date: Fri, 5 Apr 91 11:44:41 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9104051944.AA23115@june.cs.washington.edu> To: XITIJSCH%DDATHD21.BITNET@UWAVM.U.Washington.EDU Cc: tex-fonts@math.utah.edu In-Reply-To: XITIJSCH@DDATHD21.BITNET's message of Tue, 2 Apr 91 11:36:50 MSZ <1CFC58B05E4037BA@CC.UTAH.EDU> Subject: maintaining modes.mf How well I know the Omnilaser, though we don't have one here any longer. I use it as an example in a paper which will be coming out in conference proceedings fairly soon. The existing mode-def is probably wrong. I would caution very strongly against the use of negative values for fillin. It either produces gross effects or none at all. In the case of the RicohFourZeroEightZero mode_def it mostly produces gross effects. But even when you use an adjusted mode def, you get the shrinking font effect. Because the black area is etched away on a write-white printer you get the effect of the loss of an entire pixel in height and width by comparison with a write-black font at the same resolution. When you have a maximum of 18 pixels top to bottom in a ten-point lower-case o that gets very noticeable. You would have to reposition the vertical values in the parameter file to correct the effect, which would further distort the character, since you can't safely change the horizontals without the risk of mucking up the leading and trailing side bearings. Also, I suspect that the print-engine is inherently sloppy. Try comparing a standard Adobe font from the Omnilaser with the same font from a Canon, such as a Laserwriter, and you will get rather a shock. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 5-Apr-1991 20:17:40-GMT,1451;000000000001 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA00830; Fri, 5 Apr 91 13:17:37 MST Received: by june.cs.washington.edu (5.64/7.0jh) id AA25598; Fri, 5 Apr 91 12:17:22 -0800 Date: Fri, 5 Apr 91 12:17:22 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9104052017.AA25598@june.cs.washington.edu> To: rocky@watson.ibm.com Cc: tex-fonts@math.utah.edu In-Reply-To: Rocky Bernstein's message of Tue, 2 Apr 91 11:55:46 EST <9104021655.AA01539@kundry.watson.ibm.com> Subject: Some Miscellaneous MetaFont hacks Rocky Bernstein's suggestion to use a temporary redefinition of end to ensure that the mode_special information gets included even when the font ends with end rather than bye sounds to me like a winner. Now, how can we get it across to contributors of mf source code that the font_identifier and font_coding_scheme should always be included. It looks as if we need some sort of registry of known font_coding_schemes so that thay will not proliferate unnecessarily. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@max.u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center TUG Site Coordinator for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 8-Apr-1991 11:23:02-GMT,5492;000000000001 Return-Path: Received: from CC.UTAH.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA14016; Mon, 8 Apr 91 05:22:59 MDT Received: from DDATHD21.BITNET (XITIJSCH@DDATHD21) by CC.UTAH.EDU with PMDF#10043; Mon, 8 Apr 1991 05:22 MST Received: from PCSITI.FB20.THD.DA.EUROPE by DDATHD21.BITNET via GNET with RJE with RCOM ; 08 Apr 91 13:21:23 Date: Mon, 8 Apr 91 13:08:34 MSZ From: XITIJSCH@DDATHD21.BITNET Subject: What's in a name? To: tex-fonts@math.utah.edu Message-Id: X-Envelope-To: tex-fonts@math.utah.edu X-Originally-From: Joachim Schrod X-Munix-To: tex-fonts@math.utah.edu (TeX fonts discussion) X-Mailer: ELM [version 2.3 PL0] There were lots of postings on the coding of mode_def's in file names. Rocky explained that he want to code the mode_def rather cryptic in some file name part. I'm strongly opposed to this proposal, an explanation follows. The explanation is a little bit longer :-) STRUCTURE OF FONT NAMES ======================= Mode_def parts in font file names concerns only GF or PK (partly VF) format. MF will not produce these mode_def parts. (At least it does not do it up to now. Furthermore it will be difficult to alter it's behaviour in a portable [e.g., covering more than UNIX directories] fashion.) The move of the MF output to a different place is usually done by a font generation script, or MF is already started at the location where the font shall reside. The software piece which must deal mainly with font names are DVI drivers. As a member of the DVI standards committee I want to summarize a long discussion on this topic. (For further reading you may get the original postings to driv-l from different TeX archives.) Complete font file names consist of three to four parts, which may be, but are not necessarily, ordered like below: 1. A base location where all fonts for a specific device reside. This may not be one place (e.g., one directory), there may be a list of different places to look at. But the places have in common, that all fonts which reside there may be used for this output device. 2. A size specification. This is often called the scaling factor, the magnification, or the resolution. 3. The type name. E.g., cmr10. 4. The font file format. A coding for the format (PK, GF, ...). This part is optional as font codings may be detected from the magic numbers within the font files. Please note that Rocky's UNIX example .../tex/fonts/300dpi/... is not covered by the scheme above, item 1 is missing. .../tex/fonts will not be a practical valid specification for a specific device. There was the proposal that the base location includes the mode_def name (somehow). (E.g., .../tex/fonts/canon_cx might be a valid base location: Here reside fonts used for printers based on the Canon CX print engine.) But this proposal assumes that the mode_def hints to a device, not to the mode_def implementation. I.e., show the specification, not the implementation. For me, it's just the usage of a well known principle of software engineering. MODE_DEF PARTS IN FONT FILE NAMES MUST BE SPECIFIC TO PRINT ENGINES =================================================================== All drivers assume that all fonts at a given base location will be usable for one output device. It is possible that different fonts for one device are created by different mode_def's. Then all these fonts must be collected at one place. (Note that `place' here is not identical to directory; `place' might be a directory list.) A driver is otherwise not able to discover which fonts shall be used. Of course we could have a separate fontname mapping which tells which fonts are to be used with which output device. But why? We have such a mapping: It's our file system! Please don't make things more complicated as they are! Keep them plain and simple :-) FONT FILE NAMES MUST BE UNDERSTANDABLE BY HUMANS ================================================ A TeX administrator wants to know which fonts are available in which sizes for a device. He wants to do this fast, not searching through a bunch of files which explains which XYZZY fonts and what GAGTGE fonts are used for a Canon CX engine! (XYZZY and GAGTGE are ``constructed mode_def names.'') Just have a look in the file system and say ls, dir, listc; whatever your operating system supplies. For a TeX user (well, we should not forget them :-) the same holds: Have you ever met a user who wanted to know which fonts he may use? I've met a lot of them. Then I explain the file structure and they may just look at the files -- something they know already how to do it. I don't want to explain them how they shall combine a constructed mode_def with an external file to discover which fonts are available. SUMMARY ======= -- We must collect fonts for different devices at different places, and then we may choose device-specific names for these places. -- These names should be understandable for humans, as they will look at the files. Comments? Suggestions? Please don't forget the drivers! -- Joachim =========================================================================== Joachim Schrod Secretary of the TUG DVI driver standards committee Driver coordinator of DANTE Email: xitijsch@ddathd21.bitnet 8-Apr-1991 14:07:20-GMT,21966;000000000001 Return-Path: Received: from CC.UTAH.EDU by math.utah.edu (4.1/SMI-4.0-utah-csc-server) id AA14385; Mon, 8 Apr 91 08:07:14 MDT Received: from DDATHD21.BITNET (XITIJSCH@DDATHD21) by CC.UTAH.EDU with PMDF#10043; Mon, 8 Apr 1991 08:06 MST Received: from PCSITI.FB20.THD.DA.EUROPE by DDATHD21.BITNET via GNET with RJE with RCOM ; 08 Apr 91 15:47:59 Date: Mon, 8 Apr 91 15:35:27 MSZ From: XITIJSCH@DDATHD21.BITNET Subject: generating MF fonts To: tex-fonts@math.utah.edu Message-Id: <012514B47840A231@CC.UTAH.EDU> X-Envelope-To: tex-fonts@math.utah.edu X-Originally-From: Joachim Schrod X-Munix-To: tex-fonts@math.utah.edu (TeX fonts discussion) X-Mailer: ELM [version 2.3 PL0] Note: This posting is of no use for you if you do not work on DOS or UNIX systems. Below I attach a perl script which runs MF to produce a set of fonts. Complete LOGs are put into one file. In addition warnings and errors are copied to another file. (This allows a quick look on the results.) The script has one disadvantage: It does not allow the specification of different mode_def's for different fonts because it is mode_def independent. But for those of you who just want to create a whole family rather fast it is usable. The script reads a table to discover which fonts are to be created. An example of such a table looks like this: >> ::HEADER:: >> DIR /usr/mf/modern/computer % directory where parameter files are >> COMMAND cmmf % command to use >> MFINPUTS /usr/mf/modern/program % env var to set >> >> ::FONTS:: >> s0 *.mf % all MF files in magstep 0 >> 1.315 cmb10 % cmb10 scaled 1315 (for texinfo) In the header section information on the run is concentrated, the fonts section specifies which fonts to create. Wild carding on font names and specification of magsteps is supported. An example table for the family Computer Modern is enclosed. For those of you who don't know perl: It's a prototyping language which combines features of awk, sed, sh, C, and gives access to the UNIX system calls. I don't want to recommend it for `real sw projects,' but as an admin help tool, it's ok. You may get it from the usual FTP archives, a nice DOS port is available from simtel-20. Bitnet folks may fetch it via trickle. ================ genfam ==================================================== #! /usr/local/bin/perl # $Id: genfam,v 1.5 1991/04/08 13:22:36 tex Exp tex $ #------------------------------------------------------------ # (c) 1991 by Joachim Schrod . # # genfam device family # # creates a font set for device as specified in Table/. # This file has the following line structure: # # :- # preambel with arbitrary text #
# # #
:- # '::HEADER::' new_line+ # # [ ] # [ { } ] # :- 'DIR' not_white_space+ new_line+ # :- 'COMMAND' rest_of_line new_line+ # :- env_var_name not_white_space+ new_line+ # # :- # '::FONTS::' new_line+ # { } # :- file_pattern {new line}+ # :- | real_number # :- 's'real_number # # Comments start with `%' and end with the last character on the line. # Unlike in TeX the new_line does NOT belong to the comment. # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 1, or (at your option) # any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. # # $Log: genfam,v $ # Revision 1.5 1991/04/08 13:22:36 tex # included copyright notice for distribution. # # Revision 1.4 1991/02/08 20:32:29 tex # New TFM file that cannot be found is saved in subdirectory tfm. # # Revision 1.3 1991/02/08 20:10:06 tex # Directory with font sources is always included in MFINPUTS path. # On differences in dpi values our own value is used for the directory # name. # The TFM file is search in the TEXFONTS path and is compared to if # a file is found. If the new TFM differs it is not deleted. # # Revision 1.2 1991/02/08 12:41:14 tex # perl is now in /usr/local/bin instead of /software/bin. # Include dpi in separator of LOG files to distinguish different fonts. # $#errors is -1 when no errors were found. # $real_dpi must be computed with round() instead of trunc(). # Check differences between MF dpi values and own computed values. # # Revision 1.1 91/02/01 19:33:42 schrod # Initial revision # # name: table_line # pre: TABLE is open # ret: next non-empty line of TABLE, comments are deleted # leading and trailing white space is discarded # empty line if eof sub table_line { if ( eof(TABLE) ) { return ""; } while ( ) { chop; # throw away new_line s/%.*$//o; # discard comments s/^\s*(.*)\s*$/$1/o; # discard leading and trailing white space if ( $_ eq "" ) { # skip blank lines next; } return $_; # We've found a non-empty line! } return ""; # end of file reached. } # name: info() # pre: TABLE is open and at beginning # ret: (dir, command) # dir is family directory # command is MF command for create_font() # post: set env vars if necessary # ::FONTS:: is already read # err: exits if family directory is not given or does not exist sub info { local ($line); # next non-empty line local ($key, $value); # (key, value) pair from table header while ( ($line=&table_line()) ne "::HEADER::" && $line ne "" ) {} if ( $line eq "" ) { print "! There is no header in $table."; exit 2; } $line = &table_line(); ($key, $value) = split(/\s+/o, $line); if ( $key eq "DIR" ) { $dir = $value; if ( ! -d $dir ) { print "! Directory $dir does not exist."; exit 2; } if ( $ENV{"MFINPUTS"} ne "" ) { $ENV{"MFINPUTS"} .= ":$dir"; } else { $ENV{"MFINPUTS"} .= "$dir"; } } else { print "! Source directory must be specified in $table."; exit 2; } $line = &table_line(); ($key, $value) = split(/\s+/o, $line, 2); if ( $key eq "COMMAND" ) { $command = $value; $line = &table_line(); } else { $command = "mf"; } while ( $line ne "::FONTS::" && $line ne "" ) { ($key, $value) = split(/\s+/o, $line); if ( $key eq "MFINPUTS" ) { $value .= ":$dir"; } $ENV{$key} = $value; $line = &table_line(); } } # name: resolution(MF_command, mode_def) # pre: MF is callable with MF_command # mode_def exists with the used base # ret: resolution in dpi sub resolution { local ($command, $mode_def) = @_; local (@log, $out_markup, $dpi); # First build a MF call: # MF shall not ask the (non-existent) user if an error has occured, # it shall switch to the mode definition, # and shall output the respective resolution. # stdin is /dev/null # -- this will cause an emergency stop if all else fails. $command .= " '\\scrollmode;". "mode=$mode_def;$mode_def"."_;". "show pixels_per_inch;end;' ". ">') # in the MF output. The respective # line is stored in $out_markup. If no such line is found, $out_markup # is "! Error message", simulating a MF error in this way. $out_markup = "! Error message"; foreach ( @log ) { $line_no += 1; if ( /^>>/o ) { $out_markup = $_; last; } } # We split the found line. Then $out_mark is hopefully ">>", otherwise # it's an error. ($out_markup, $dpi) = split(/\s+/, $out_markup); if ( $out_markup eq "!" || grep(/^!/, @log) > 0 ) { print "! There was an error while calling METAFONT."; print " Perhaps the device is no valid mode definition?"; print " Let's have a look at the MF output:"; print "-" x 70; print @log; unlink "mfput.log"; exit 2; } # Of course the output should be a real number. if ( $dpi !~ /\d+(\.\d*)?/o ) { print "! METAFONT did not tell me a resolution for this device."; print " I'm stymied. Perhaps you should take a look at the MF output:"; print "-" x 70; print @log; unlink "mfput.log"; exit 2; } # MF produced mfput.log and mfput.tfm, we will delete them before returning. unlink ; return($dpi); } # name: create_dir(dir) # pre: --- # post: directory dir exists sub create_dir { local ($dir) = @_; if ( -e $dir ) { if ( -d _ ) { return; } print "! File $dir exists but is no directory."; do finish(); } mkdir($dir, 0777) || die "$0: mkdir $dir: $!.\n"; } # name: base_dir(mode_def) # pre: --- # ret: full path name of base directory (i.e. new current directory) # post: base directory for mode_def is created if necessary # is now current directory sub base_dir { local ($mode_def) = @_; do create_dir($mode_def); chdir($mode_def); chop( $mode_def=`pwd` ); return $mode_def; } # name: lookup(file, path) # pre: $file is a name of a regular file # @path is an array with directory names # ret: full path name of $file if found in one directory # "" if not found sub lookup { local ($file, @path) = @_; local ($dir); foreach $dir ( @path ) { next if $dir eq ""; if ( -f "$dir/$file" ) { return "$dir/$file"; } } return ""; } # name: create_font(mag, file) # pre: mag holds the mag string for MF call # file is a MF program and is found by $MFINPUTS # $command holds the MF call # $device holds the mode definition # $real_dpi is the dpi value we have computed # LOGerror is open for writing # LOGwarning is open for writing # post: PK file is created in subdir dpi/. # LOG file is analyzed, # errors are appended to LOGerror, # warnings are appended to LOGwarning, # whole LOG is appended to LOGall. # no GF file exists. # @font_count[0..1] is incremented; sub create_font { local ($mag, $file) = @_; local (@log, @errors, $error, $dpi); local ($font) = split(/\./, $file); local ($font_msg) = $font." at ".$real_dpi." dpi"; local ($separator)= "=" x 20." ".$font_msg." "."=" x (58-length($font_msg)); $font_count[0] += 1; # we try the next font @log = `$command '\\scrollmode; mode=$device; mag=$mag; input $file`; { @errors = grep(/^!/, @log); if ( ($error=$#errors) == -1 ) { last; } @errors = grep(!/^! Strange path/, @errors); if ( $#errors != $error ) { print LOGwarning $separator; print LOGwarning $error-$#errors, " strange paths have occured."; } if ( $#errors == -1 ) { last; } print LOGerror $separator; $error = 0; foreach ( @log ) { if ( $error ) { chop; print LOGerror $_; if ( $error == 2 ) { $error = 0; } elsif ( /^l.\d+/o ) { $error = 2; } } elsif ( /^!/o && ! /^! Strange/o ) { chop; print LOGerror $_; $error = 1; } } } system "echo '$separator' >>LOGall"; system "cat $font.log >>LOGall"; $dpi = $log[$#log - 1]; if ( $dpi !~ /^Output/o ) { print LOGerror "!" x 20, " No output!"; return; } ($dpi) = ( $dpi =~ /$font\.(\d+)gf/ ); if ( $dpi != $real_dpi ) { print "! Dpi-differences between MF ($dpi dpi) and me ($real_dpi dpi)."; } system "gftopk", "$font.${dpi}gf", "dpi$real_dpi/$font" || print LOGerror "!" x 20," Problems with gftopk on $font.${dpi}gf"; $old_tfm = &lookup("$font.tfm", @tfm_path); if ( $old_tfm eq "" ) { print "! New TFM file: tfm/$font.tfm"; rename("$font.tfm", "tfm/$font.tfm"); } elsif ( system("cmp", "-s", "$font.tfm", $old_tfm) ) { print "! Different TFMs for type $font,"; print " new one stored as $old_tfm.$device.$real_dpi."; system "mv", "$font.tfm", "$old_tfm.$device.$real_dpi"; } unlink( grep(!/\.mf/, <$font.*>) ); $font_count[1] += 1; # well, we succeeded } # name: create_mag(mag, pattern) # pre: mag is the magnification of the font set # $dpi is the base resolution of the device # $cwd is the current directory, i.e., the base directory # $dir is the directory where the MF programs reside # pattern are files in $dir which shall be created in mag # create_font(file) with file from {pattern} is callable # post: for all files create_font() is called sub create_mag { local ($mag, $pattern) = @_; local (@files, $file, $MF_mag, $real_dpi); chdir $dir; @files = <${pattern}>; chdir $cwd; if ( $#files == -1 ) { return; } $MF_mag = $mag; if ( $MF_mag =~ s/^s(\d+(\.\d*)?)/$1/o ) { $real_dpi = 1.2 ** $MF_mag; $MF_mag = "magstep(".$MF_mag.")"; } else { $real_dpi = $MF_mag; } if ( $real_dpi == 0 ) { print "! Hmm, the magnification $mag is not valid."; return; } $real_dpi = int( $real_dpi * $dpi + 0.5 ); # round does not exist... do create_dir("dpi".$real_dpi); foreach $file ( @files ) { do create_font($MF_mag, $file); } } # name: finish() # pre: $init_phase is set # post: no return sub finish { local ($log_msg); if ( $init_phase ) { exit 2; } # We are finished and tell now how long we have run. $log_msg = "=" x 79; print LOGerror $log_msg; print LOGwarning $log_msg; print LOGall $log_msg; ($user, $system, $cuser, $csystem) = times; $total = sprintf("%.2f", $user + $system + $cuser + $csystem); $user = sprintf("%.2f", $user); $system = sprintf("%.2f", $system); $cuser = sprintf("%.2f", $cuser); $csystem = sprintf("%.2f", $csystem); chop( $time = &ctime(time) ); $log_msg = <) eq ""; } {} $ENV{"LOGNAME"} = $name; } } $name = $ENV{"LOGNAME"}; do create_dir("tfm"); @tfm_path = split(/:/, $ENV{"TEXFONTS"}); push(@tfm_path, ".", "/usr/tex/fonts/tfm", "tfm"); # check arguments if ( $#ARGV != 1 ) { print "usage: ",$0," device family"; exit 1; } # give them names ($device, $family) = @ARGV; # open table file $table = "Table/".$family; if ( ! -f $table || ! -r _ ) { print "! Cannot read $table."; exit 2; } open(TABLE,"<".$table); # read table header, compute base resolution and generate base directory do info(); $dpi = &resolution($command, $device); $cwd = &base_dir($device); # Now we are in the base directory. # All initializations are done, MF ran already, and we may now assume that # the rest is computer's work. So we fork of a process, disconnect it from # our main process and start the whole stuff :::: print <nohup.out"); open(STDERR, ">&STDOUT"); # Create files LOGerror and LOGwarning because they will be written # by this script. # But delete LOGall as this will be written by cat. This deletion is not # done by unlink because this file may be linked to somewhere else due to # space reasons. So we use an open and a close. But before we write a # header to the LOG files so that the reader will know what we have done. $log_msg = "Started creation of family $family on ".&ctime(time). "Skript activated by $name\n"; # two NL's !! open(LOGerror, ">LOGerror"); open(LOGwarning, ">LOGwarning"); open(LOGall, ">LOGall"); print LOGerror $log_msg; print LOGwarning $log_msg; print LOGall $log_msg; close(LOGall); # Read each font set from TABLE, split it, setup mag specification # string for MF, and call create_mag(). @font_count = (0, 0); while ( ($_ = &table_line()) ne "" ) { ($mag, $pattern) = split; do create_mag($mag, $pattern); } # cleanup do finish(); ================ end of genfam ============================================= ================ Table/modern ============================================== % $Id: modern,v 1.1 1991/03/21 18:29:57 tex Exp tex $ %------------------------------------------------------------ % % table of the used fonts of the family Computer Modern % % $Log: modern,v $ % Revision 1.1 1991/03/21 18:29:57 tex % Initial revision % ::HEADER:: DIR /usr/mf/modern/computer COMMAND cmmf MFINPUTS /usr/mf/modern/driver:/usr/mf/modern/program ::FONTS:: % first a few reduced fonts as substitutions for missing small fonts 0.5 cmbsy10.mf 0.5 cmbxsl10.mf 0.5 cmcsc10.mf 0.5 cmitt10.mf 0.5 cmmib10.mf 0.5 cmsl10.mf 0.5 cmsltt10.mf 0.5 cmss10.mf 0.5 cmssbx10.mf 0.5 cmssi10.mf 0.5 cmti10.mf 0.5 cmtt10.mf 0.5 cmu10.mf 0.6 cmbsy10.mf 0.6 cmbxsl10.mf 0.6 cmcsc10.mf 0.6 cmitt10.mf 0.6 cmmib10.mf 0.6 cmsl10.mf 0.6 cmsltt10.mf 0.6 cmss10.mf 0.6 cmssbx10.mf 0.6 cmssi10.mf 0.6 cmti10.mf 0.6 cmtt10.mf 0.6 cmu10.mf 0.7 cmbsy10.mf 0.7 cmbxsl10.mf 0.7 cmcsc10.mf 0.7 cmitt10.mf 0.7 cmmib10.mf 0.7 cmsl10.mf 0.7 cmsltt10.mf 0.7 cmss10.mf 0.7 cmssbx10.mf 0.7 cmssi10.mf 0.7 cmtt10.mf 0.7 cmu10.mf 0.8 cmbsy10.mf 0.8 cmbxsl10.mf 0.8 cmcsc10.mf 0.8 cmitt10.mf 0.8 cmmib10.mf 0.8 cmsltt10.mf 0.8 cmssbx10.mf 0.8 cmu10.mf 0.9 cmbsy10.mf 0.9 cmbxsl10.mf 0.9 cmcsc10.mf 0.9 cmitt10.mf 0.9 cmmib10.mf 0.9 cmsltt10.mf 0.9 cmssbx10.mf 0.9 cmu10.mf % next complete steps s0 *.mf s0.5 *.mf s1 *.mf s2 *.mf s3 *.mf s4 *.mf s5 *.mf % these fonts are needed by SliTeX s6 cmmi8.mf s6 cmsy8.mf s6 cmtt8.mf s7 cmmi8.mf s7 cmsy8.mf s7 cmtt8.mf s8 cmmi8.mf s8 cmsy8.mf s8 cmtt8.mf % these by texinfo 1.315 cmb10 1.315 cmti10 1.315 cmsl10 1.315 cmtt10 1.315 cmss10 % and these by our own macros s6 cmcsc10.mf s7 cmcsc10.mf ================ end of Table/modern ======================================= -- Joachim =========================================================================== Joachim Schrod Computer Science Department Technical University of Darmstadt, Germany 13-Apr-1991 22:33:44-GMT,5715;000000000001 Return-Path: Received: from watson.ibm.com ([129.34.139.4]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00395; Sat, 13 Apr 91 16:33:42 MDT Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R1) with BSMTP id 6174; Fri, 12 Apr 91 18:42:44 EDT Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R1) with TCP; Fri, 12 Apr 91 18:42:43 EDT Received: from kundry.watson.ibm.com by cyst.watson.ibm.com (AIX 1.3/900528) id AA22855; Fri, 12 Apr 91 18:42:40 -0400 Received: by kundry.watson.ibm.com (DCE STD CONFIG 2.2 - AIX 2.1.2/2.0) id AA03382; Fri, 12 Apr 91 18:42:47 EDT Date: Fri, 12 Apr 91 18:42:47 EDT From: rocky@watson.ibm.com (Rocky Bernstein) Message-Id: <9104122242.AA03382@kundry.watson.ibm.com> X-External-Networks: yes To: tex-fonts@math.utah.edu Cc: XITIJSCH@DDATHD21.BITNET In-Reply-To: Subject: What's in a name? A mode by any other name... Reply-To: rocky@watson.ibm.com There seems to be a miscommunication somewhere between Joachim Schrod (and perhaps others) and me. Perhaps people haven't received the all of the notes sent---every now and then I get messages from ``MAILER-DAEMON@uunet.uu.net'' about undelivered mail. Perhaps I haven't been very clear. For example, I never advocated using a fonts scheme such as ../tex/fonts/300dpi... Just that such schemes have been used and they are inadequate. (Here is where I think Joachim and I agree though.) However in the same vein, I feel that a ``printer engine'' name is inadequate as well. And I am not sure I completely understand Joachim. For example is a ``specific device'' a single piece of hardware or many of them? If the idea is that a ``specific device'' is any of the set of devices that makes the rasters in it look good, then again we are not in disagreement. I however think it a mistake to call that directory something like ../fonts/CanonCX.... (I confess though that the servers I've have set up here in fact use that name.) A reiteration of the points. There are problems with using the ``print engine'' as the mode_def name. 1) The print engine is often not known. Some printer vendors conceal this so as to have the flexibility to vary this. (See Barbara Beeton's comment in TUGBoat Volume 8 No. 2 on page 132.) It is true that some printer vendors list a ``print engine'' name and model. However if you open up the printer, it is not likely that you will find a designation such as ``CanonCX'' anywhere. I will give Joachim (or anyone else) a case of smoked herring from Lubec Maine if (s)he can tell me the print engine for the IBM 4216 model 031 printer. (Astute readers might suspect that this is a trick question.) 2) (related to 1) There are variations within a given print engine. Specifying the resolution, darkness of the font, aspect ratio, write whiteness, is actually more abstract and more helpful to someone trying to select a font library than using a printer model or print engine. PK and GF fonts are for raster devices. Therefore it makes sense to refer to their abstract properties. This is why I don't understand Joachim's comment about specification versus implementation. If the same sets of rasters look good on two output devices, it doesn't matter to me whether the devices were made by different manufacturers or are referred to as different print engines. Similarly, it is irrelevant to me that two specific printers have the same or a common name if I have to use vastly different sets of rasters to get the best quality output on each of the printers. The closest analogy I can think of is with shoe sizes. It used to be around here that when one went into a shoe store, they had a gadget you plopped your foot down into which gave a ``shoe size.'' (I hear Joachim yelling ``specification, not implementation---I want Converse sneakers, not that I need a 14A shoe.'') Although it was assumed that the output of such a measuring device was one's true shoe size, it didn't necessarily mean that one would walk out wearing a shoe of that size, say 14A. First, the store might not have had that particular show size. (Likewise a font repository might not have the exact rasters that make a given output device render the best.) But second, even if the store had the ``right size,'' shoes were typically tried on first. If the customer complained that a shoe was to tight, appealing to the scientific accuracy of the machine (or a shoe-standardization committee) probably wouldn't have had any effect; trying a looser shoe would. However this is where the ``cryptic'' name is useful: 14B is wider than 14A; 13A is smaller than 14A. Likewise for raster fonts. I believe a good mode_def naming proposal should: 1) Take into account the fact that there may be variations in a single printer (or class of printers) 2) Take into account variation of individual's tastes 3) Expose the issues and not conceal or confuse them. (If one believes modes.mf, then RicohFourZeroEightZero is an exact replacement for CanonSX and is to be preferred over CanonCX. However the latter two have deceptively close names, and the former is made by a different vendor.) 4) Be easily determinable without reference to anything other than the the output of such a device 5) Give assistance for finding the right ``size'' rasters and 6) Give assistance in assigning a new name, since names will probably be given in a distributed fashion. With respect to the above, a ``print engine'' name does not do as well as one proposed before. I've probably beat these points into the ground, so I'll stop. I'd really like to hear other points of view and other proposals. rocky IBM Research 19-Apr-1991 14:34:51-GMT,6497;000000000001 Return-Path: Received: from BIIVAX.DP.BECKMAN.COM (beckman.com) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25384; Fri, 19 Apr 91 08:34:48 MDT Date: Fri, 19 Apr 1991 7:34:34 PDT From: DAHOSEK@beckman.com (DON HOSEK) Message-Id: <910419073434.2060baa6@beckman.com> Subject: RFC -- a TeX font naming system To: tex-fonts@csc-sun.math.utah.edu X-Vmsmail-To: bv8500::smtp%"tex-fonts@science.utah.edu" X-News: bv8500 comp.text.tex:2885 From: Damian.Cugley@prg.ox.ac.uk (Damian Cugley) Subject:RFC -- a TeX font naming system Date: 17 Apr 91 15:34:01 GMT Message-ID: This article describes an alternative approach to naming TeX fonts -- I would be interested to see if anyone thinks it has anything going for it. ------------------------------------------------------------------------ If we stick to the 6- or 8-character names we have to resort to outrageous abbreviations -- Karl Berry's gallant efforts notwithstanding. These in turn either have to be centrally controlled so that everyone uses the same names (which is a pain when new fonts become available). What we need is a system whereby the TeX name for a font can be deduced >From its external name without any ambiguity, and where TeX names are relatively intelligible. Here is a system that I think has some merits; afterwards I will show how I think it can be implemented on top of different sorts of filing system. Font names have a fixed syntax which goes like this: --> [ - [ - ] ] --> --> --> --> { | }. Here "-" stands for a hyphen token and and for letters or digits respectively. [...] enclose optional material and stuff in {...} can appear zero or more times. For example: Adobe-Courier-cbo Courier Bold Oblique Bistream-Charter-chi Charter Italic pdc-mabx10 Malvern Bold Expanded 10pt pdc-ditc18 Ditko Compressed 18pt cmr12 Computer Modern Roman 12pt cmmi10 Computer Modern Math Italic 10pt The form -- is used for fonts from commerical manufacturers, who have a large number of families each with several individual font files (which I will eccentrically refer to as cuts). Usually the company will not be directly involved with porting their fonts to the TeX world. The second form, - is used for typefaces where the "foundry" is a single person or small institution. Generally these will turn out to be PD fonts created using METAFONT or PostScript directly. The third form is for fonts supplied with TeX as part of the CMR "meta-family" or one-off fonts that supply specialized symbols -- in other words, almost all of currently existing TeX fonts. WHAT A CUT IS USED TO MEAN The name for a font looks like an old-style TeX name and will generally be along these lines -- where --> -- one size font | [ p ] -- size in points -- 7p5 == 7.5 pt | m [ ] -- size in mm -- 3m5 == 3.5 mm The is a 1-, 2- or 3- letter abbrev for the family name. For the 3-part font names this is just a placeholder taken from the initials of the family name. For 2-part and 1-part s, this will be chosen by the designer. The is the usual "bold italic" or "thin oblique" type stuff, and possibly things like "csc" or "mi" meaning it is a different selection of symbols from a particular face. For fonts imported from outside the TeX world (which will have 3-part names), the is derrived from the font designer's description of the font, [table of abbreviations for goes here]. Someone designing a new METAFONT family can use whatever es takes their fancy. Certain combinations of long suffixes, long s and 3-letter font names might be able to lead to s more than 8 chars long. This can be avoided by using a Univers-style numeric system ("68c" for semibold condensed italic caps-&-s.caps instead of "sbcicsc"), or simply shoved under the carpet... FAMILIES and FOUNDRIES Foundries and families allow different designers to not have to worry about their fonts having overlapping names -- so long as the foundries are unique! [Rules for shortening company names go here.] For 2-part names, which usually have a named after a person or academic institution, normally the "foundry" will be involved with making them available and can make their own decision about what name should be used! HOW TeX INTERPRETS THESE NAMES The munging of file names is part of the system-dependent part of TeX. All this system requires is that "-" be given a special meaning. What meaning exactly depends on implemntation. It should be assumed that the MS-DOS limit of 8 case-folded characters of each are significant. Some examples. \\ A HAL 9000 has a filing system with a flat namespace of 40-character monocase names. It can map the up to 24 significant characters of a font name onto a filename like "TEXFONT@ADOBE@TIMES@TBI" or "TEXFONT@PDC@MA24". \\ A Lose-O-Matic 770 has a directory structure with short (8-char) names. By interpreting the "-" as a directory separator, it sees Adobe-Times-tbi as a file TBI in a subdirectory TIMES of a directory ADOBE of the TeX font area. \\ A BSD UNIX system has a directory structure *and* long names. It can use whatever sysem is most convenient (I favour mapping "-" to "/"). \\ A Creton-X50 has a flat name space *and* short names. All fonts are given a code number when installed and are put in files with names f0000, f0001, f0002, ...; a "directory file" contains a list of font names and font code numbers. s and have associated directory files referenced from the top level directory file. In other words, the hapless Creton-X50 implementors have to "roll their own" directory structure. (This is why I limited s to three s.) //- Damian Cugley ----\ /--- Oxford University Computing Laboratory, -\ || pdc@prg.ox.ac.uk || \--- 11 Keble Rd, Oxford, UK OX1 3QD --------/ || pdc@uk.ac.ox.prg || \--------------------// "His feet are the wrong size for his shoes." 30-Apr-1991 17:30:14-GMT,8237;000000000001 Return-Path: Received: from cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26946; Tue, 30 Apr 91 11:30:03 MDT Received: from ra.cs.umb.edu by cs.umb.edu (4.1/1.34) id AA05128; Tue, 30 Apr 91 10:16:45 EDT Received: by ra.cs.umb.edu (4.1/1.34) id AA20645; Tue, 30 Apr 91 10:15:20 EDT Date: Tue, 30 Apr 91 10:15:20 EDT From: karl@cs.umb.edu (Karl Berry) Message-Id: <9104301415.AA20645@ra.cs.umb.edu> To: tex-fonts@math.utah.edu Cc: damian.cugley@prg.oxford.ac.uk Subject: filenames for fonts Reply-To: karl@cs.umb.edu This is a pretty long article, in response to Damian Cugley's recent posting, and Liam Quin's response thereto, about a font naming scheme. It has lots of quotes from those articles. Sorry. Damian> If we stick to the 6- or 8-character [font] names we have to resort to > outrageous abbreviations This much is true. 8 characters are not enough to unambiguously represent all (perhaps even most) fonts, as my TUGboat article points out. Since we are stuck with 8 character filenames, however, we have to make the best of it. I think there is some value, however, to trying to semi-rationalize the naming schemes for the actual files, even if we adopt some name mapping scheme like yours. So I am going to continue to maintain the lists for 8 character filenames. (This is not anything against another scheme for longer names; in fact, I suggested a somewhat similar scheme a couple months ago, and asked DEK if it was ok to introduce font mapping files into TeX [he said yes]). > Certain combinations of long suffixes, long s and > 3-letter font names might be able to lead to s more than 8 chars > long. This can be avoided by using a Univers-style numeric system > ("68c" for semibold condensed italic caps-&-s.caps instead of > "sbcicsc"), or simply shoved under the carpet... I don't think this leaves us any better off than the current situation. It's useless to try to make anything fit in 8 characters; it won't. We have to give up 8 characters (and therefore introduce mapping files) to get complete unambiguity. > The munging of file names is part of the system-dependent part of TeX. > All this system requires is that "-" be given a special meaning. What > meaning exactly depends on implemntation. As above, I don't think it's plausible to map fontnames given to TeX directly onto the filesystem, although it's a nice idea, and might work in some cases. For one thing, I personally don't like to have lots of subdirectories for my fonts; instead, I put all the Adobe fonts, all the CM fonts together, and so on. So any prescriptive mapping of `-' to `/' (i.e., directories) under Unix will make me unhappy, either at the fontname end or the filename end. > \\ A Creton-X50 has a flat name space *and* short names. All fonts are > given a code number when installed and are put in files with names > f0000, f0001, f0002, ...; a "directory file" contains a list of font > names and font code numbers. s and have > associated directory files referenced from the top level directory > file. In other words, the hapless Creton-X50 implementors have to > "roll their own" directory structure. (This is why I limited name>s to three s.) I don't think we lose much by making everybody ``roll their own'' directory structure, and require ``directory files'' (what I've been calling mapping files, and we gain a lot (I think) by getting rid of the limitation of s to three components (as Lee said). Lee> Note that it is useful to separate weight (bold, medium) from face Lee> (roman, oblique, slanted, italic), so that using "cbo" for Lee> Courier-Bold-Oblique is probably bad. Damian> I am combining the "face" info into one word for several Damian> reasons: firstly, TeX has no useful way to treat weight, width, Damian> slant etc. separately; TeX doesn't have a useful way to treat the variants differently, but people do (it helps them parse; also, it could help programs parse). Also, such combinations will lead to ambiguity once you try to come up with a reasonably complete set of variants (believe me, I know). > secondly, it's shorter; True, but if you're already saying Adobe-NewCenturySchoolbook, length is already clearly not much of an issue. As always, it's tradeoff: convenience (short names) for completeness (unambiguous names) It's been ``convenience'' ever since the TeX project began (no reflection on the designers, of course); if short names were good enough, then we wouldn't be discussing this issue right now! Damian> thirdly, it allows the old fonts -- cmr12 etc. -- to remain unchanged. Also true, but I think the old fontnames are horrendous, and we shouldn't cripple ourselves trying to be compatible with them. Damian> the XLFD name > -Adobe-New Century Schoolbook-Medium-I-Normal--24-240-75-75-P-136-ISO8859-1 I don't think we want the X naming scheme unchanged. In particular, I don't think the pixel parts of the name are relevant. Damian> The extra "c" at the front is so that Courier doesn't get > called "Adobe-Courier-", with nothing after the final "-". There's nothing wrong with this, in my mind. Lee> I don't see any advantage in limiting font names to three components. Damian> My scheme isn't supposed to classify every aspect of fonts in their > names, (not useful IMO) but to help divide the huge namespace of possible > fonts into useful chunks: Fair enough, but I think one of the ways a font naming scheme can help users is by giving users some kind of consistency between fonts -- Helvetica foo-bar-baz and Times foo-bar-baz should mean the same thing. Too many fonts will fall into the ``miscellanous'' category if you use single letters (that's what's happening to me). (End of quotes.) Also, there is another advantage to having consistent names -- then one can write TeX macros which take advantage of the consistency to build the names, without having to special case everything in sight (as, say, lfonts.tex does). TeX's handling of fonts has always been bad for users; they just want to replace Computer Modern with Times by saying something like \typefacefamily = Times (or ptm, or something) \resetfonts Up to now, though, every new font family to come out requires new macros to get at them. I'm very sorry that I didn't require variant letters to be alphabetical in my ``short filename'' scheme; now there are some fonts which have the same variants but give them in different orders (because Adobe did it that way). My own proposal for a naming scheme goes like this : -----