2-Apr-1994 20:18:56-GMT,1433;000000000001 Return-Path: Received: from terminus.cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16521; Sat, 2 Apr 94 13:18:56 MST Received: by terminus.cs.umb.edu id AA27190 (5.65c/IDA-1.4.4); Sat, 2 Apr 1994 15:18:10 -0500 Date: Sat, 2 Apr 1994 15:18:10 -0500 From: "K. Berry" Message-Id: <199404022018.AA27190@terminus.cs.umb.edu> To: texhax@tex.ac.uk, tex-fonts@math.utah.edu, tex-archive@math.utah.edu Subject: fontname document 1.6 available I have released version 1.6 of ``my'' font naming scheme for TeX fonts. You can get it by anonymous ftp from ftp.cs.umb.edu:pub/tex/fontname.tar.gz The fontname document is in Texinfo format, so you will need the TeX macros in the file texinfo.tex to print it; texinfo.tex is included in the distribution, and is also available in most GNU distributions. The rest of that directory contains files showing the naming scheme applied to Adobe, Monotype, Computer Modern, and other sources' fonts. Changes since 1.5: * New variant `8' meaning next-character-is-also-a-variant, giving us another [a-z0-9] to play with. ISO Latin 1, 2, and 5, Windows ANSI, and the Mac standard layouts all assigned. * New typefaces: wi=Wingdings, mg=Marigold, m0=Monospace. * One new alias (Omega=Optima). I am happy to receive additions, criticisms, or other comments. kb@cs.umb.edu Member of the League for Programming Freedom -- write lpf@uunet.uu.net. 7-Apr-1994 16:11:34-GMT,1864;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02888; Thu, 7 Apr 94 10:11:34 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #44) id m0powGh-00003QC; Thu, 7 Apr 94 16:45 BST Message-Id: Date: Thu, 7 Apr 94 16:45 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: tex-fonts@math.utah.edu Subject: Raw font encodings Sigh... it's that time of year again... Sebastian Rahtz and myself are taking another look at the PostScript font support in LaTeX2e, in preparation for the full release of 2e. One outstanding problem is that the Virtual Fonts which are shipped as part of the package don't support glyphs like and very well, because they assume that the raw fonts are in Adobe Standard encoding. We'd like to change this, which means that the raw fonts have to be re-encoded with a new PostScript encoding vector. The question is, what vector to use. To our knowledge, none of the standard encoding vectors contain all of the ISO Latin-1 and Adobe Standard glyphs, so this means using a non-standard encoding. One possibility is to take ISO Latin-1 and add the missing glyphs from Adobe Standard (oh yes, and for Lucida Bright :-) into random slots. So... Is there an existing encoding which we could use for such a task? Any encoding which includes ISO Latin-1 and Adobe Standard is going to need to use some of slots 0--31. Are there still any printer drivers which refuse to use Type 1 fonts which use slots 0--31? Are there any device drivers which can't perform raw font re-encoding by some means or other? Yours, Alan. Alan Jeffrey Tel: +44 273 606755 x 3238 alanje@cogs.susx.ac.uk School of Cognitive and Computing Sciences, Sussex Univ., Brighton BN1 9QH, UK 8-Apr-1994 1:44:59-GMT,11615;000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24036; Thu, 7 Apr 94 19:44:59 MDT Return-Path: Received: (mackay@localhost) by june.cs.washington.edu (8.6.8/7.2ju) id SAA22648; Thu, 7 Apr 1994 18:44:56 -0700 Date: Thu, 7 Apr 1994 18:44:56 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Message-Id: <199404080144.SAA22648@june.cs.washington.edu> To: alanje@cogs.susx.ac.uk, tex-fonts@math.utah.edu Cc: mackay@cs.washington.edu, unixtex.u.washington.edu@cs.washington.edu, ridgeway@blackbox.hacc.washington.edu Subject: Re: raw font encodings One outstanding problem is that the Virtual Fonts which are shipped as part of the package don't support glyphs like and very well, because they assume that the raw fonts are in Adobe Standard encoding. We'd like to change this, which means that the raw fonts have to be re-encoded with a new PostScript encoding vector. The question is, what vector to use. I made this proposal a while ago, and it was grossly misunderstood. It is specifically for a raw font encoding, set up to ensure that all simplex characters are at least available for the output font encoding, which I treat as variable. Doesn't mean that you have to treat it as variable, only that you can. The only virtue that I claim for this is that it ensures that you can get at all the simplex characters if you want to. In the case of really huge Superfonts, like IBM Courier, there are more simplex characters than can be held in a 255-character encoding vector. ( The blue book, p 199 suggests that 0--255 is a genuine limitation.) The only answer there is to extract the obvious pi characters into a different raw-font encoding. I explain below why I do not include composites (except for the characters that might be thought composites in the expert font, but are actually simplex). I have used this scheme for a year, with no ill effects at all. % % This is ASEX encoding. (file ASEX.enc) % % Adobe Standard Encoding Extended. % % Creator: Pierre A. MacKay mackay@cs.washington.edu % Creation Date: Thu Aug 31 08:56:22 PDT 1993 % % This is an input coding file for creation of a "raw font". % It can, for esample be used with Radical Eye Software's % afm2tfm. Use with the -p flag. This same encoding can also be % used with ps2pk to create a complete set of bitmapped % simplex characters. % % The {\em sole} purpose of this file is to ensure that all {\em simplex} % characters in the font are made available in the raw TFM. Therefore % there are no ligatures or any other refinements. The raw TFM % file contains no ligatures or kernings---nothing but character % metrics. We retain Adobe Standard encoding for all mapped % characters in the AFM file, and extend the list by adding % the unmapped simple characters into the empty code positions % from O 200 to O 240. It is assumed that the output coding used % for the TeX tfm will be different from this ( -t flag in afm2tfm ). % % The extended part of this encoding is consistent with the general % run of text fonts from Adobe, BitStream, DTC, Linotype, Monotype, % URW and probably others as well. For SuperFont characters, see below. % In a library of over 300 text fonts, I have found no variants. The only % variant in display fonts is the occasional absence of lowercase. % % Jan Michael Rynnings has pointed out that a few very carefully designed % fonts, e. g. Adobe Garamond and Adobe Caslon, may treat all the accented % characters as simplex glyphs (must make for a large pfa file), and that % this input encoding would not recognize such refinements. True---but % such fonts will be a tiny minority, and can be dealt with by % special encoding files. A couple of tests indicate that it makes % no perceptible difference whether you use composites formed from % the CC recipes in the AFM file or call the characters out directly % from the PFA file. There seems no reason, therefore, to fill the % raw font with characters that are clearly identified as composites % in the AFM file. % % Usage: % afm2tfm .afm -p ASEX.enc -t .enc -v % /ASEXEncoding [ % now 256 chars follow % % The following will replace the characters from 0 to 32 in the raw encoding % if you have access to a SuperFont. There is reason to hope that this % set will be as stable as the unmapped set in current text fonts % If you don't have a SuperFont, and have to create any of these as a % composite, precede the name with a dot, as is done here for % Scedilla and scedilla. The change in name keeps afm2tfm from thinking % that the character already exists when it comes to evaluate the output % (-t flag) encoding. % % 0x00 /Aogonek /Eogonek /Iogonek /Kafii9170 /Lafii9170 /Lcaron /Nafii9170 /Rafii9170 /Safii9170 /.Scedilla /Tafii9170 /Uogonek /.notdef /.notdef /.notdef /.notdef % 0x10 /aogonek /eogonek /iogonek /kafii9170 /lafii9170 /lcaron /nafii9170 /rafii9170 /safii9170 /.scedilla /tafii9170 /uogonek /.notdef /.notdef /.notdef /.notdef % 0x20 % Keep the space, for use as \boundarychar (Give it zero width in vpl) /space /exclam /quotedbl /numbersign /dollar /percent /ampersand /quoteright /parenleft /parenright /asterisk /plus /comma /hyphen /period /slash % 0x30 /zero /one /two /three /four /five /six /seven /eight /nine /colon /semicolon /less /equal /greater /question % 0x40 /at /A /B /C /D /E /F /G /H /I /J /K /L /M /N /O % 0x50 /P /Q /R /S /T /U /V /W /X /Y /Z /bracketleft /backslash /bracketright /asciicircum /underscore % 0x60 /quoteleft /a /b /c /d /e /f /g /h /i /j /k /l /m /n /o % 0x70 /p /q /r /s /t /u /v /w /x /y /z /braceleft /bar /braceright /asciitilde /.notdef % % This is the Extension to Adobe Standard Encoding % % In as many of the next 32 positions as necessary, include % all the unmapped simple (non-composite) characters. The % inclusion of Ccedilla and ccedilla is problematic. These are % composites in some schemes, simple in others. Best to % assume they are simplex. Characters are entered in alphabetical order % by name. If you need to create your own composite for Ccedilla % ccedilla or Eth, precede the name with a dot as indicated above. % % 0x80 /Ccedilla /Eth /Thorn /brokenbar /ccedilla /copyright /degree /divide /eth /logicalnot /minus /mu /multiply /onehalf /onequarter /onesuperior % 0x90 /plusminus /registered /thorn /threequarters /threesuperior /trademark /twosuperior /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef % % From here on the order is again Adobe Standard Encoding % % 0xA0 /.notdef /exclamdown /cent /sterling /fraction /yen /florin /section /currency /quotesingle /quotedblleft /guillemotleft /guilsinglleft /guilsinglright /fi /fl % 0xB0 /.notdef /endash /dagger /daggerdbl /periodcentered /.notdef /paragraph /bullet /quotesinglbase /quotedblbase /quotedblright /guillemotright /ellipsis /perthousand /.notdef /questiondown % 0xC0 /.notdef /grave /acute /circumflex /tilde /macron /breve /dotaccent /dieresis /.notdef /ring /cedilla /.notdef /hungarumlaut /ogonek /caron % 0xD0 /emdash /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef % 0xE0 /.notdef /AE /.notdef /ordfeminine /.notdef /.notdef /.notdef /.notdef /Lslash /Oslash /OE /ordmasculine /.notdef /.notdef /.notdef /.notdef % 0xF0 /.notdef /ae /.notdef /.notdef /.notdef /dotlessi /.notdef /.notdef /lslash /oslash /oe /germandbls /.notdef /.notdef /.notdef /.notdef ] def Same rationale for "Expert Font" encoding % % THis file is ASEXP.enc % % This is ASEXP encoding, for the Monotype Expert character set. % In Baskerville, only the Roman Regular has all the characters. % It appears to be the same as what Adobe uses---who knows? % /ASEXPEncoding [ % now 256 chars follow % 0x00 /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef % 0x10 /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef % 0x20 % The independent accent slash doesn't exist /.notdef /exclamsmall /Hungarumlautsmall /.notdef /dollaroldstyle /dollarsuperior /ampersandsmall /Acutesmall /parenleftsuperior /parenrightsuperior /twodotenleader /onedotenleader /comma /hyphen /period /fraction % 0x30 /zerooldstyle /oneoldstyle /twooldstyle /threeoldstyle /fouroldstyle /fiveoldstyle /sixoldstyle /sevenoldstyle /eightoldstyle /nineoldstyle /colon /semicolon /commasuperior /threequartersemdash /periodsuperior /questionsmall % 0x40 /.notdef /asuperior /bsuperior /centsuperior /dsuperior /esuperior /.notdef /.notdef /.notdef /isuperior /.notdef /.notdef /lsuperior /msuperior /nsuperior /osuperior % 0x50 /.notdef /.notdef /rsuperior /ssuperior /tsuperior /.notdef /ff /fi /fl /ffi /ffl /parenleftinferior /.notdef /parenrightinferior /Circumflexsmall /hyphensuperior % 0x60 /Gravesmall /Asmall /Bsmall /Csmall /Dsmall /Esmall /Fsmall /Gsmall /Hsmall /Ismall /Jsmall /Ksmall /Lsmall /Msmall /Nsmall /Osmall % 0X70 /Psmall /Qsmall /Rsmall /Ssmall /Tsmall /Usmall /Vsmall /Wsmall /Xsmall /Ysmall /Zsmall /colonmonetary /onefitted /rupiah /Tildesmall /.notdef % 0x80 /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef % 0x90 /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef % 0xA0 /.notdef /exclamdownsmall /centoldstyle /Lslashsmall /.notdef /.notdef /Scaronsmall /Zcaronsmall /Dieresissmall /Brevesmall /Caronsmall /.notdef /Dotaccentsmall /.notdef /.notdef /Macronsmall % 0xB0 /.notdef /.notdef /figuredash /hypheninferior /.notdef /.notdef /Ogoneksmall /Ringsmall /Cedillasmall /.notdef /.notdef /.notdef /onequarter /onehalf /threequarters /questiondownsmall % 0xC0 /oneeighth /threeeighths /fiveeighths /seveneighths /onethird /twothirds /.notdef /.notdef /zerosuperior /onesuperior /twosuperior /threesuperior /foursuperior /fivesuperior /sixsuperior /sevensuperior % 0xD0 /eightsuperior /ninesuperior /zeroinferior /oneinferior /twoinferior /threeinferior /fourinferior /fiveinferior /sixinferior /seveninferior /eightinferior /nineinferior /centinferior /dollarinferior /periodinferior /commainferior % 0xE0 /Agravesmall /Aacutesmall /Acircumflexsmall /Atildesmall /Adieresissmall /Aringsmall /AEsmall /Ccedillasmall /Egravesmall /Eacutesmall /Ecircumflexsmall /Edieresissmall /Igravesmall /Iacutesmall /Icircumflexsmall /Idieresissmall % 0xF0 /Ethsmall /Ntildesmall /Ogravesmall /Oacutesmall /Ocircumflexsmall /Otildesmall /Odieresissmall /OEsmall /Oslashsmall /Ugravesmall /Uacutesmall /Ucircumflexsmall /Udieresissmall /Yacutesmall /Thornsmall /Ydieresissmall ] def Email concerned with UnixTeX distribution software should be sent primarily to: UnixTeX@u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center Resident Druid for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 8-Apr-1994 13:33:30-GMT,3040;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01607; Fri, 8 Apr 94 07:33:30 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #44) id m0ppGbG-00003QC; Fri, 8 Apr 94 14:27 BST Message-Id: Date: Fri, 8 Apr 94 14:27 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: mackay@cs.washington.edu Cc: tex-fonts@math.utah.edu, mackay@cs.washington.edu, unixtex.u.washington.edu@cs.washington.edu, ridgeway@blackbox.hacc.washington.edu In-Reply-To: <199404080144.SAA22648@june.cs.washington.edu> (mackay@cs.washington.edu) Subject: Re: raw font encodings >It is specifically for a raw font encoding, set up to ensure that >all simplex characters are at least available for the output font >encoding, which I treat as variable. Yes, this is very close to what we want, *except* that we'd like an encoding which includes the composite glyphs, for two reasons: a) in some fonts, the composite glyphs aren't the same as the glyphs built from the appropriate simplexes, for example and may use a different sized accent. b) in any Type 1 font with hints, there can be no hints between glyphs built from simplexes, so the and in may end up colliding, which they wouldn't in a hinted . c) the PostScript produced by using virtual composite characters is longer. Printing out the Cork alphabet with dvips uses 1.3K with raw composite characters, and 2.1K with virtual ones. So I'd guess that a long PostScript document with heavy accenting would be 20--50% longer if the accents are produced virtually. One possibility (suggested off-line by Don Hosek) would be to have the raw font encoded with the same encoding as the virtual font, so for T1 (Cork) encoded Adobe Times the raw font would contain all the T1 glyphs which Adobe provide, and then the VF would `fill in the gaps'. The problem with this is that if you want to use the same font with a number of different virtual encodings, you need a different raw font each time. Looking (not very far, I hope!) into the future, there are plans for a Text Symbol (TS) encoding to hold glyphs like and which are missing from T1. It would be nice if the T1-encoded and TS-encoded VFs could both point to the same raw font, because this halves the number of raw TFMs needed. So... there's a trade-off between three options: a) Provide a raw encoding containing all the Adobe Standard and ISO Latin-1 glyphs. b) Have the T1 VFs point to a sparse T1-encoded raw font. c) Don't include composite glyphs in the raw encoding. The respective problems are: a) Requires the use of slots 0--31, which some previewers can't handle. b) Requires (at least) twice as much disk space for raw fonts, produces PostScript which uses more raw fonts. c) Doesn't allow hinting or designed glyphs, produces longer PostScript. ... are there other options? ... Alan. 8-Apr-1994 14:12:11-GMT,1224;000000000000 Return-Path: <@aston.ac.uk:spqr@tex.ac.uk> Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA02057; Fri, 8 Apr 94 08:12:11 MDT Via: uk.ac.aston; Fri, 8 Apr 1994 15:11:20 +0100 Received: from ftp.tex.ac.uk by email.aston.ac.uk with SMTP (PP) id <13054-0@email.aston.ac.uk>; Fri, 8 Apr 1994 15:09:30 +0100 Received: by tex.ac.uk (4.1/SMI-4.1) id AA17193; Fri, 8 Apr 94 14:05:40 GMT Date: Fri, 8 Apr 94 14:05:40 GMT From: spqr@tex.ac.uk (Sebastian Rahtz) Message-Id: <9404081405.AA17193@tex.ac.uk> To: alanje@cogs.sussex.ac.uk Cc: mackay@cs.washington.edu, ridgeway@blackbox.hacc.washington.edu, tex-fonts@math.utah.edu, unixtex.u.washington.edu@cs.washington.edu Subject: Re: raw font encodings In-Reply-To: References: <199404080144.SAA22648@june.cs.washington.edu> Sender: spqr@tex.ac.uk alanje@cogs.susx.ac.uk writes: > The respective problems are: > > a) Requires the use of slots 0--31, which some previewers can't > handle. > i'd like to see some hard info on this. is it definitely and still true, as opposed to `was true to older versions of ATM?' sebastian 8-Apr-1994 23:22:32-GMT,6824;000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA09736; Fri, 8 Apr 94 17:22:32 MDT Return-Path: Received: (mackay@localhost) by june.cs.washington.edu (8.6.8/7.2ju) id QAA05244; Fri, 8 Apr 1994 16:22:02 -0700 Date: Fri, 8 Apr 1994 16:22:02 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Message-Id: <199404082322.QAA05244@june.cs.washington.edu> To: alanje@cogs.susx.ac.uk Cc: tex-fonts@math.utah.edu, unixtex.u.washington.edu@cs.washington.edu, ridgeway@blackbox.hacc.washington.edu In-Reply-To: Alan Jeffrey's message of Fri, 8 Apr 94 14:27 BST Subject: Re: raw font encodings a) in some fonts, the composite glyphs aren't the same as the glyphs built from the appropriate simplexes, for example and may use a different sized accent. This is true for a very small number of fonts. I have Rynnings's observation that it happens to be true for Adobe Garamond and Adobe Caslon, but I have not myself seen either of these. For the foreseeable future, I suspect that the pattern I see in my 300 or so text fonts (I get all the Monotype package deals, even though I would not dream of using most of what they contain) is the norm. Is it really possible to make the special cases the basis of a general practice. b) in any Type 1 font with hints, there can be no hints between glyphs built from simplexes, so the and in may end up colliding, which they wouldn't in a hinted . I specifically recommend keeping Ccedilla and ccedilla as simplex, for this and other reasons. I would be quite happy to change the recommendation to an ukaz. c) the PostScript produced by using virtual composite characters is longer. Printing out the Cork alphabet with dvips uses 1.3K with raw composite characters, and 2.1K with virtual ones. So I'd guess that a long PostScript document with heavy accenting would be 20--50% longer if the accents are produced virtually. Undoubtedly true, but is it really a severe impediment. One possibility (suggested off-line by Don Hosek) would be to have the raw font encoded with the same encoding as the virtual font, so for T1 (Cork) encoded Adobe Times the raw font would contain all the T1 glyphs which Adobe provide, and then the VF would `fill in the gaps'. For the single example of Cork encoding to Cork encoding that works. I started out that way, but found that I got seriously tangled up when I needed to make adjustments to supply the two dozen characters which Near Eastern Language scholarship has used for more than a century and which are unavailable even in Unicode. The reason for adopting something as close to Adobe Standard Encoding as possible was that I could then make up virtuals with reasonable assurance that I knew where the original raw characters were The problem with this is that if you want to use the same font with a number of different virtual encodings, you need a different raw font each time. Exactly my reason for using ASE(X) for raw fonts. As I say, I got hopelessly entangled in conflicting codings. Now I know that all type1 test fonts are encoded in the raw form in exactly the same way. a) Provide a raw encoding containing all the Adobe Standard and ISO Latin-1 glyphs. b) Have the T1 VFs point to a sparse T1-encoded raw font. The advantage of sparse coding is that if new characters get added in standard or quasi-standard fonts, there is room to fit them in. A fully populated map can be very frustrating. c) Don't include composite glyphs in the raw encoding. Yup. The respective problems are: a) Requires the use of slots 0--31, which some previewers can't handle. This is surprising, if true. The avoidance of 0--31 and, indeed, much of the oddity of the sparse coding of 128--256 have a lot to do with half-witted keyboard input modules, and so affect the operation of word-processors, but when you get to a previewer that is capable of handling DVI at all, I don't see how you can lose all those code positions. I find it hard to imagine that any marketable postscript interpreter would prevent you from using the entire encoding vector. I should think Adobe might complain about its being given the PostScript name in that case. Early HP printers made you dodge around some holes in the range 0--255, but if we are talking about type1 fonts, we are talking about PostScript, and surely the HP postscript (which is far from faultless) no longer has that problem. b) Requires (at least) twice as much disk space for raw fonts, produces PostScript which uses more raw fonts. That is very true, and it isn't just the use of space. It is the complexity it adds to the problem of managing a huge font library. An additional advantage gained by restricting the size and number of raw fonts is that if they are few and small they can be downloaded into a reasonably capacious lot of ram in the printer, and remain resident for a day's work. c) Doesn't allow hinting or designed glyphs, produces longer PostScript. OK, you can't hint, which is not usually much of a problem at hard-copy resolutions, but can cause difficulties at display resolutions. You can modify glyphs though. For example, I use one font family for both Turkish and Western European documentation. It doesn't have designed accent composites and isn't likely to get them. You will hardly ever see squatty caps and modified cap accents in Turkish books, partly because the choice of accents is limited, and they can be and are pulled down very close to the underlying letter. By contrast, acute, grave and worst of all ring accents can either adjust leading in undesirable ways or risk bleeding into the descenders of the previous line. I keep different virtual fonts for the two instances. In the West European font the caps for composites are subjected to a transform that makes them squat down just a bit, the accents are tilted to a flatter angle, and the circumflex (and hacek) are slightly flattened. (A similar trick could be used to eliminate the rather unfortunate ovoid fullstop and comma in slanted Computer Modern, incidentally. Not easy with the comma, but doable.) All this is done with inline postscript, and involves yet longer PostScript files of course. It also involves repeated makefont operations, which one is usually advised against, but I have timed the operation, and in an admittedly very low-volume operation I find that the hit is not all that serious. PostScript remembers the old transform, and uses very little time after the first effort. ... are there other options? ... I have undoubtedly gone on too long already. Pierre 11-Apr-1994 23:42:48-GMT,1437;000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12749; Mon, 11 Apr 94 17:42:48 MDT Return-Path: Received: (mackay@localhost) by june.cs.washington.edu (8.6.8/7.2ju) id QAA13903; Mon, 11 Apr 1994 16:42:46 -0700 Date: Mon, 11 Apr 1994 16:42:46 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Message-Id: <199404112342.QAA13903@june.cs.washington.edu> To: KYBIC@CSEARN.BITNET.washington.edu Cc: tex-fonts@math.utah.edu In-Reply-To: Jan Kybic's message of Mon, 11 Apr 94 11:03:24 MET <199404110927.CAA20709@june.cs.washington.edu> Subject: Re: afm2tfm - make it preserve kerning Further on your accent problem. afm2tfm will not generate the accented chars where you don't want them if you use something like my ASEX.enc for the input encoding vector. In that case, the output coding will be absolutely governed by the output encoding vector for all characters that are unmentioned in ASEX.enc. That was one of the reasons I worked on ASEX.enc, and one of the chief reasons why I exclude all composites from it Email concerned with UnixTeX distribution software should be sent primarily to: UnixTeX@u.washington.edu Elizabeth Tachikawa otherwise to: mackay@cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Center Resident Druid for Thomson Hall, Mail Stop DR-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 12-Apr-1994 0:10:44-GMT,2003;000000000000 Return-Path: Received: from bluesky.com (bluegate.bluesky.com) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12965; Mon, 11 Apr 94 18:10:44 MDT Received: by bluesky.com (5.65/Inherent1.1Mailhost) id AA14662; Mon, 11 Apr 94 16:20:56 PDT From: Barry Smith Message-Id: <9404112320.AA14662@bluesky.com> Subject: Re: raw font encodings To: alanje@cogs.susx.ac.uk (Alan Jeffrey) Date: Mon, 11 Apr 94 16:20:55 PDT Cc: mackay@cs.washington.edu, tex-fonts@math.utah.edu, unixtex%u.washington.edu-ridgeway@blackbox.hacc.washington.edu In-Reply-To: ; from "Alan Jeffrey" at Apr 11, 94 5:56 pm X-Mailer: ELM [version 2.3 PL10] > There is a third (which appeals quite strongly to me): > > 3. Use Windows ANSI for slots 32--255, and put the missing glyphs > (, , , , , , , > , and ) somewhere in slots 1--31. > These slots can't be used by some Windows applications, but since > the glyphs don't exist in Windows ANSI encoding anyway, this may not > be a problem. > > The problem with this approach is that it means that documents > containing `fi' or `fl' which are printed with TrueType fonts will end > up with missing glyphs. But the only way round this is to have > separate metrics and VFs for the TrueType fonts, without the `fi' and > `fl' ligatures (any better suggestions anyone)? > > Oh, another problem may be with Macs, which do have and , and > some applications may not like having them mapped to slots in the > range 0--31. > > Alan. This one gets a pretty sharp response from here; any "solution" that omits fi and fl ligatures is a non-starter! I understand (vaguely) that TrueType has weird/none abilities for ligatures, but of course the glyphs can be in a TrueType font. Perhaps I've misunderstood the implications; hope so! Barry Smith, Blue Sky Research barry@bluesky.com 12-Apr-1994 10:00:29-GMT,1542;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16667; Tue, 12 Apr 94 04:00:29 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #44) id m0pqf4V-000078C; Tue, 12 Apr 94 10:47 BST Message-Id: Date: Tue, 12 Apr 94 10:47 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: barry@bluesky.com Cc: mackay@cs.washington.edu, tex-fonts@math.utah.edu, unixtex%u.washington.edu-ridgeway@blackbox.hacc.washington.edu In-Reply-To: <9404112320.AA14662@bluesky.com> (message from Barry Smith on Mon, 11 Apr 94 16:20:55 PDT) Subject: Re: raw font encodings >This one gets a pretty sharp response from here; any "solution" that >omits fi and fl ligatures is a non-starter! The and ligatures would be there, but they'd be mapped to slots somewhere in the range 0--31. Sorry if I sounded like I was kicking and out---that certainly wasn't the intension! How does a Textures preview window with a permuted font look to the rest of the Mac world? If I were to cut-and-paste from the Textures preview into another application, and one of the fonts used was a permuted Times Roman, does the other application see the permutation, or does it just see plain old Times Roman? If it's the latter, then this seems to imply Textures can hide the use of glyphs in the range 0--31 from the rest of the Mac environment, so we're just left with PCs as the problem case. Or am I fooling myself :-) Alan. 1-Jul-1994 19:36:08-GMT,7254;000000000000 Return-Path: Received: from terminus.cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26510; Fri, 1 Jul 94 13:36:08 MDT Received: by terminus.cs.umb.edu id AA20293 (5.65c/IDA-1.4.4); Fri, 1 Jul 1994 15:35:51 -0400 Date: Fri, 1 Jul 1994 15:35:51 -0400 From: "K. Berry" Message-Id: <199407011935.AA20293@terminus.cs.umb.edu> To: tex-fonts@math.utah.edu, tex-archive@math.utah.edu, texhax@tex.ac.uk, info-tex@shsu.edu Subject: modes.mf 1.3 available I have released version 1.3 of modes.mf. You can get it by anonymous ftp from ftp.cs.umb.edu:pub/tex/modes.mf You can also get it by email from George Greenwade's (thanks, George!) file server if you cannot ftp: email fileserv@shsu.edu with a body of `sendme modes'. This file is a collection of Metafont mode_def's. It also makes common definitions for write/white printers, `special' information, and landscape mode. There is a new mode for low-resolution G3 fax, g3faxlo. The high-resolution G3 fax now has the resolution 204x196. New modes for the Canon BubbleJet 10ex and the Epson Action. Values for CanonEX changed. As always, thanks to the contributors. If you have mode_def's which are not listed below, or corrections to the existing ones, please send them to me. Improvements to the exposition, particularly in how to create a new mode_def, are also welcome. karl@cs.umb.edu mode_def AgfaFourZeroZero = % AGFA 400PS mode_def amiga = % Commodore Amiga mode_def AtariNineFive = % Atari 95dpi previewer mode_def AtariNineSix = % Atari 96x96 previewer mode_def AtariSLMEightZeroFour = % Atari ST SLM 804 printer mode_def AtariSMOneTwoFour = % Atari ST SM 124 screen mode_def aps = % Autologic APS-Micro5 mode_def ApsSixHi = % Autologic APS-Micro6 mode_def bitgraph = % BBN Bitgraph at 118dpi mode_def bjtenex = % Canon BubbleJet 10ex mode_def boise = % HP 2680A mode_def CanonCX = % Canon CX, SX, LBP-LX mode_def CanonEX = % CanonEX in LaserWriter Pro 630 mode_def CanonLBPTen = % e.g., Symbolics LGP-10 mode_def ChelgraphIBX = % Chelgraph IBX mode_def CItohThreeOneZero = % CItoh 310 mode_def CItohEightFiveOneZero = % CItoh 8510A mode_def CompugraphicEightSixZeroZero = % Compugraphic 8600 mode_def CompugraphicNineSixZeroZero = % Compugraphic 9600 mode_def crs = % Alphatype CRS mode_def DataDisc = % DataDisc mode_def DataDiscNew = % DataDisc with special aspect ratio mode_def DECsmall = % DEC 17-inch, 1024 x 768 mode_def DEClarge = % DEC 19-inch, 1280 x 1024 mode_def dover = % Xerox Dover mode_def epsdraft = % Epson at 120x72dpi mode_def epsfast = % Epson at 60x72dpi mode_def epsonact = % Epson Action Laser 1500 mode_def epsonlo = % Epson at 120x216dpi mode_def EpsonLQFiveZeroZeroMed = % Epson LQ-500, 360x180dpi mode_def EpsonLQFiveZeroZeroLo = % Epson LQ-500, 180x180dpi mode_def EpsonMXFX = % 9-pin Epson MX/FX family mode_def GThreefax = % 204 x 196dpi G3fax mode_def gtfaxlo = % 204 x 98dpi G3fax mode_def HPDeskJet = % HP DeskJet 500 mode_def HPLaserJetIIISi = % HP Laser Jet IIISi mode_def HPrugged = % HP RuggedWriter 480 mode_def ibm_a = % IBM 38xx (\#1) mode_def IBMD = % IBM 38xx (\#2) mode_def IBMFourZeroTwoNine = % IBM 4029-30, 4250 mode_def IBMFourTwoOneSix = % IBM 4216 mode_def IBMFourZeroOneNine = % IBM 4019 mode_def IBMProPrinter = % IBM ProPrinter mode_def IBMSixOneFiveFour = % IBM 6154 display mode_def IBMSixSixSevenZero = % IBM 6670 (Sherpa) mode_def IBMThreeOneSevenNine = % IBM 3179 screen mode_def IBMThreeOneNineThree = % IBM 3193 screen mode_def IBMThreeEightOneTwo = % IBM 3812 mode_def IBMThreeEightTwoZero = % IBM 3820 mode_def IBMEGA = % IBM EGA monitor mode_def IBMVGA = % IBM VGA monitor mode_def imagewriter = % Apple ImageWriter mode_def laserjetfour = % 600dpi HP LaserJet 4 mode_def laserjetlo = % HP LaserJet at 150dpi mode_def lasermaster = % 1000dpi LaserMaster 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 LPSTwoZero = % DEC lps20 mode_def LPSFourZero = % DEC LPS40 mode_def lview = % Sigma L-View monitor mode_def MacMagnified = % Mac screens at magstep 1 mode_def MacTrueSize = % Mac screens at 72dpi mode_def NCD = % NCD 19-inch mode_def NEC = % NEC mode_def NEChi = % NEC-P6 at 360x360dpi mode_def Newgen = % Newgen 400dpi mode_def NeXTprinter = % NeXT 400dpi mode_def NeXTscreen = % 100dpi NeXT monitor mode_def nullmode = % TFM files only mode_def OCESixSevenFiveZeroPS = % OCE 6750-PS mode_def okidata = % Okidata mode_def OneTwoZero = % e.g., high-resolution Suns mode_def phaser = % Tektronix Phaser PXi mode_def PrintwareSevenTwoZeroIQ = % Printware 720IQ mode_def qms = % QMS (Xerox engine) mode_def QMSOneSevenTwoFive = % QMS 1725 mode_def QMSOneSevenZeroZero = % QMS 1700 mode_def RicohFourZeroEightZero = % e.g., TI Omnilaser mode_def RicohLP = % e.g., DEC LN03 mode_def SparcPrinter = % Sun SPARCprinter mode_def StarNLOneZero = % Star NL-10 mode_def sun = % Sun and BBN Bitgraph at 85dpi mode_def supre = % Ultre*setter at 2400dpi mode_def toshiba = % Toshiba 13XX, EpsonLQ mode_def ultre = % Ultre*setter at 1200dpi mode_def VarityperFiveZeroSixZeroW = % Varitype 5060W mode_def VarityperFourThreeZeroZeroLo = % Varityper 4300P at 1200dpi mode_def VarityperFourThreeZeroZeroHi = % Varityper 4300P at 2400dpi mode_def VarityperFourTwoZeroZero = % Varityper 4200 B-P mode_def VarityperSixZeroZero = % Varityper Laser 600 mode_def VAXstation = % VAXstation monitor mode_def XeroxDocutech = % Xerox 8790 or 4045 mode_def XeroxEightSevenNineZero = % Xerox 8790 or 4045 mode_def XeroxFourZeroFiveZero = % Xerox 4050/4075/4090 mode_def XeroxNineSevenZeroZero = % Xerox 9700 mode_def XeroxThreeSevenZeroZero = % Xerox 3700 1-Jul-1994 20:00:16-GMT,820;000000000000 Return-Path: Received: from terminus.cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26789; Fri, 1 Jul 94 14:00:16 MDT Received: by terminus.cs.umb.edu id AA20396 (5.65c/IDA-1.4.4); Fri, 1 Jul 1994 16:00:13 -0400 Date: Fri, 1 Jul 1994 16:00:13 -0400 From: "K. Berry" Message-Id: <199407012000.AA20396@terminus.cs.umb.edu> To: info-tex@shsu.edu, tex-fonts@math.utah.edu, tex-archive@math.utah.edu Subject: Re: modes.mf 1.3 available Do you mean 1.3 ? Wasn't that the version released a couple of months ago? You're absolutely right. How embarrassing! (Somehow the file get left over in my to-be-distributed directory, and I didn't bother to check if I already had.) Never mind. There is no new release of modes.mf. Sorry for the waste of time and bandwidth. 4-Oct-1994 18:28:59-GMT,898;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA14071; Tue, 4 Oct 94 12:28:59 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #44) id m0qsEac-000072C; Tue, 4 Oct 94 19:27 BST Message-Id: Date: Tue, 4 Oct 94 19:27 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: tex-fonts@math.utah.edu Subject: ligature An interesting problem has arisen with the T1 character... if you set \hyphenchar to be rather than and allow hyphenation after then `control-flow' will line break as `control-- flow' since the isn't removed. One solution to this is to add a ligature +=. Is this reasonable? Should I add this to T1.etx? Are there better solutions? Alan. 11-Oct-1994 10:03:28-GMT,1241;000000000000 Return-Path: Received: from vzdmza.zdv.uni-mainz.de by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04002; Tue, 11 Oct 94 04:03:28 MDT Received: from DECNET-DAEMON (KNAPPEN@VKPMZD) by VzdmzA.ZDV.Uni-Mainz.DE (PMDF V4.2-11 #4432) id <01HI4HAKKPWG0008WT@VzdmzA.ZDV.Uni-Mainz.DE>; Mon, 10 Oct 1994 20:28:11 +0100 Date: Mon, 10 Oct 1994 20:28:10 +0100 From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Subject: Hyphenchar ligatures again To: tex-fonts@math.utah.edu Message-Id: <01HI4HAKPJIQ0008WT@VzdmzA.ZDV.Uni-Mainz.DE> X-Envelope-To: tex-fonts@math.utah.edu X-Vms-To: GATEWAY"tex-fonts@math.utah.edu" X-Vms-Cc: VZDMZG::MITTELBACH Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT In a reply about two weeks ago, I stated that the hyphenchar does not form ligatures, if inserted. However, this turns out to be wrong. I now did new tests with iniTeX (!) which show, that the formation of ligatures with the hyphenchar is no problem at all, and they come out correctly. So there is no remaining objection to have the ligature Minus-sign + Hyphenchar -> Hyphenchar in the Cork encoded fonts. Of course, it should be added to the dc-fonts, too. --J"org Knappen 11-Oct-1994 11:29:12-GMT,943;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA04646; Tue, 11 Oct 94 05:29:12 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #47) id m0qufN3-000075C; Tue, 11 Oct 94 12:27 BST Message-Id: Date: Tue, 11 Oct 94 12:27 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Cc: tex-fonts@math.utah.edu In-Reply-To: <01HI4HAKPJIQ0008WT@VzdmzA.ZDV.Uni-Mainz.DE> (KNAPPEN@VKPMZD.kph.Uni-Mainz.DE) Subject: Re: Hyphenchar ligatures again >So there is no remaining objection to have the ligature > Minus-sign + Hyphenchar -> Hyphenchar >in the Cork encoded fonts. Of course, it should be added to the dc-fonts, >too. If nobody objects, I'll add this to T1.etx, which is the encoding file used by fontinst. This means the ligature will end up in all the PS fonts on CTAN. Alan. 12-Oct-1994 16:58:27-GMT,1913;000000000000 Return-Path: Received: from netcomsv.netcom.com (uucp6.netcom.com) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19722; Wed, 12 Oct 94 10:58:27 MDT Received: from clement.UUCP by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1) id JAA05535; Wed, 12 Oct 1994 09:43:03 -0700 Received: by quixote.com (UUPC/extended 1.12b); Tue, 11 Oct 1994 18:30:12 PDT Date: Wed, 12 Oct 94 2:30:10 +1600 From: Don Hosek Message-Id: <2e9b3c25.clement@quixote.com> Subject: Re: Hyphenchar ligatures again To: alanje@cogs.susx.ac.uk (Alan Jeffrey) Cc: tex-fonts@math.utah.edu In-Reply-To: from "Alan Jeffrey" at Oct 11 94 12:27 pm X-Mailer: ELM [version 2.3 PL11] for OS/2 > >So there is no remaining objection to have the ligature > > Minus-sign + Hyphenchar -> Hyphenchar > >in the Cork encoded fonts. Of course, it should be added to the dc-fonts, > >too. > If nobody objects, I'll add this to T1.etx, which is the encoding file > used by fontinst. This means the ligature will end up in all the PS > fonts on CTAN. You also need em-dash+hyphenchar and en-dash+hyphenchar ligatures. Of course, these are complicated if one is doing hanging punctuation since the em-dash and en-dash plus hyphenchar ligatures need to be ligatured to hanging em and en dash characters which of course the Cork designers in their computer-science-inspired myopia left no space for. -dh -- Don Hosek "The Only Solution is Love" Quixote Digital Typography -Dorothy Day Publishers of _Serif: The Magazine of Type and Typography_ 909-621-1291 Current reading: _The Reformation, FAX: 909-625-1342 the Mass and the Priesthood dhosek@quixote.com (Messenger), _On Nature_ (Lucretius) 12-Oct-1994 17:02:54-GMT,1137;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19790; Wed, 12 Oct 94 11:02:54 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #47) id m0qv724-00005aC; Wed, 12 Oct 94 18:00 BST Message-Id: Date: Wed, 12 Oct 94 18:00 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: dhosek@quixote.com Cc: tex-fonts@math.utah.edu In-Reply-To: <2e9b3c25.clement@quixote.com> (message from Don Hosek on Wed, 12 Oct 94 2:30:10 +1600) Subject: Re: Hyphenchar ligatures again >You also need em-dash+hyphenchar and en-dash+hyphenchar ligatures. Of >course, these are complicated if one is doing hanging punctuation >since the em-dash and en-dash plus hyphenchar ligatures need to be >ligatured to hanging em and en dash characters which of course the >Cork designers in their computer-science-inspired myopia left no space >for. If you're feeling sneaky, you can try: + = and then add a kern between and . But that's not exactly part of the Cork standard... Alan.