From @syma.sussex.ac.uk:alanje@cogs.sussex.ac.uk Thu Mar 11 02:20:55 1993 Flags: 000000000000 Return-Path: <@syma.sussex.ac.uk:alanje@cogs.sussex.ac.uk> Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29623; Thu, 11 Mar 93 02:20:55 MST Via: uk.ac.sussex.syma; Thu, 11 Mar 1993 09:20:31 +0000 Received: from csrj by syma.sussex.ac.uk; Thu, 11 Mar 93 04:04:33 GMT Message-Id: <1128.9303082203@csrj.crn.cogs.susx.ac.uk> From: Alan Jeffrey Date: Mon, 8 Mar 93 22:03:41 GMT To: metafont@dmi.ens.fr, tex-fonts@math.utah.edu Cc: NTOMCZAK@vm.ucs.UAlberta.CA Subject: VPL tools available for anonymous ftp Our anonymous ftp server is now up and running, so I can now announce that my collection of VPL tools is now available for anonymous ftp from: ftp.cogs.susx.ac.uk [192.33.16.70] in: pub/tex/vpltools/* The VPL tools include: * A VPL parser and writer, written in AWK. * A VPL parser and writer, written in TeX. * A VPL creator, written in TeX. Note that only the first of these is maintained! The others are made available because of frequent requests, but should be used with caution. If anyone wants to take over the maintainence of these programs, drop me a line. Cheers, Alan. Alan Jeffrey Tel: +44 273 606755 x 3238 alanje@cogs.sussex.ac.uk School of Cognitive and Computing Sciences, Sussex Univ., Brighton BN1 9QH, UK From karl@cs.umb.edu Mon Apr 12 09:27:18 1993 Flags: 000000000000 Return-Path: Received: from claude.cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25181; Mon, 12 Apr 93 09:27:18 MDT Received: by claude.cs.umb.edu id AA13074 (5.65c/IDA-1.4.4); Mon, 12 Apr 1993 11:27:16 -0400 Date: Mon, 12 Apr 1993 11:27:16 -0400 From: Karl Berry Message-Id: <199304121527.AA13074@claude.cs.umb.edu> To: info-tex@shsu.bitnet, tex-archive@math.utah.edu, tex-fonts@math.utah.edu Subject: sauter fonts 2.0 available Reply-To: karl@cs.umb.edu I've updated my distribution of John Sauter's Metafont files to make Computer Modern fonts at any point size. You can get version 2.0 by ftp from ftp.cs.umb.edu:pub/tex/sauter.tar.z Please notice the `.z' instead `.Z' -- I am now using gzip instead of compress. See below for a blurb about gzip. This release makes the sauter fonts match the AMS ``extracm'' fonts (cmbsy5-9, cmcsc8-9, cmex7-9, cmmib5-9). Thus, the TFM files do not match those of previous release, hence the incremented major version number. For all of the standard Computer Modern fonts, these files produce the same TFM files as Knuth's sources. So it is ok to call the output from these `cm...'. Besides the Computer Modern and the Glonti/Samarin Cyrillic, the distribution also includes Sauter parameter files for the LaTeX symbol fonts, contributed by Friedrich Haubensak. The distribution includes an lfonts.tex for LaTeX and a MakeTeXPK for dvips which take advantage of these fonts, as well as an NFSS fontdef.sau. Let me know if you have questions or suggestions. karl@cs.umb.edu Member of the League for Programming Freedom---write to lpf@uunet.uu.net. Distribution information: You can get LaTeX from rusmv1.rus.uni-stuttgart.de and dvips from labrea.stanford.edu:pub/dvips*. (Alternatively, you can get ftp.cs.umb.edu:pub/tex/dvipsk.tar.z, which is a version of dvips I have modified to use the same font searching code as TeX, the GNU font utilities, and my modified xdvi.) Information about gzip: gzip is faster and compresses better than compress. In addition to its technical virtues, it is not subject (so far) to any (alleged) software patents. Here is an extract from the README file: > gzip is free software, you can redistribute it and/or modify it under > the terms of the GNU General Public License, a copy of which is > provided under the name COPYING. The latest version of the gzip > sources can always be found in prep.ai.mit.edu:/pub/gnu/gzip-*.tar* > or any of the prep mirror sites. An MSDOS lha self-extracting exe is in > hal.gnu.ai.mit.edu:/tmp/gzip*.exe. Instead of prep, I suggest you get gzip from one of the following less heavily loaded servers: Asia: ftp.cs.titech.ac.jp, utsun.s.u-tokyo.ac.jp:/ftpsync/prep, cair.kaist.ac.kr:/pub/gnu Australia: archie.oz.au:/gnu (archie.oz or archie.oz.au for ACSnet) Europe: src.doc.ic.ac.uk:/gnu, ftp.informatik.tu-muenchen.de, ftp.informatik.rwth-aachen.de:/pub/gnu, nic.funet.fi:/pub/gnu, ugle.unit.no, isy.liu.se, ftp.stacken.kth.se, ftp.win.tue.nl, ftp.denet.dk, ftp.eunet.ch, nic.switch.ch:/mirror/gnu, archive.eu.net, irisa.irisa.fr:/pub/gnu United States: wuarchive.wustl.edu, ftp.cs.widener.edu, uxc.cso.uiuc.edu, col.hp.com:/mirrors/gnu, gatekeeper.dec.com:/pub/GNU, ftp.uu.net:/systems/gnu For more information about software patents, please email me or lpf@uunet.uu.net. From karl@cs.umb.edu Mon Apr 12 09:28:02 1993 Flags: 000000000000 Return-Path: Received: from claude.cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25190; Mon, 12 Apr 93 09:28:02 MDT Received: by claude.cs.umb.edu id AA13077 (5.65c/IDA-1.4.4); Mon, 12 Apr 1993 11:27:51 -0400 Date: Mon, 12 Apr 1993 11:27:51 -0400 From: Karl Berry Message-Id: <199304121527.AA13077@claude.cs.umb.edu> To: info-tex@shsu.bitnet, tex-archive@math.utah.edu, tex-fonts@math.utah.edu, rivlinj@watson.ibm.com, rokicki@cs.stanford.edu Subject: fontname scheme 1.4 available Reply-To: karl@cs.umb.edu I have released version 1.4 of ``my'' font naming scheme for TeX fonts. You can get it by anonymous ftp from ftp.cs.umb.edu:pub/tex/fontname.tar.z I will also send it to you by email if you cannot ftp. Please notice the `.z' instead `.Z' -- I am now using gzip instead of compress. See below for a blurb about gzip. The fontname document is in Texinfo format, so you will need the TeX macros in the file texinfo.tex (available with most GNU programs) to be able to print it; the directory pub/tex/fontname on the above machine has a texinfo.tex, as well as a number of other files with name lists. The rest of that directory contains files showing the naming scheme applied to Adobe, Monotype, Computer Modern, and other sources' fonts. The changes since version 1.3 are minimal: a couple of additional typefaces, variants, and sources. I am happy to receive additions, criticisms, or other comments. karl@cs.umb.edu Member of the League for Programming Freedom -- write lpf@uunet.uu.net. Information about gzip: gzip is faster and compresses better than compress. In addition to its technical virtues, it is not subject (so far) to any (alleged) software patents. Here is an extract from the README file: > gzip is free software, you can redistribute it and/or modify it under > the terms of the GNU General Public License, a copy of which is > provided under the name COPYING. The latest version of the gzip > sources can always be found in prep.ai.mit.edu:/pub/gnu/gzip-*.tar* > or any of the prep mirror sites. An MSDOS lha self-extracting exe is in > hal.gnu.ai.mit.edu:/tmp/gzip*.exe. Instead of prep, I suggest you get gzip from one of the following less heavily loaded servers: Asia: ftp.cs.titech.ac.jp, utsun.s.u-tokyo.ac.jp:/ftpsync/prep, cair.kaist.ac.kr:/pub/gnu Australia: archie.oz.au:/gnu (archie.oz or archie.oz.au for ACSnet) Europe: src.doc.ic.ac.uk:/gnu, ftp.informatik.tu-muenchen.de, ftp.informatik.rwth-aachen.de:/pub/gnu, nic.funet.fi:/pub/gnu, ugle.unit.no, isy.liu.se, ftp.stacken.kth.se, ftp.win.tue.nl, ftp.denet.dk, ftp.eunet.ch, nic.switch.ch:/mirror/gnu, archive.eu.net, irisa.irisa.fr:/pub/gnu United States: wuarchive.wustl.edu, ftp.cs.widener.edu, uxc.cso.uiuc.edu, col.hp.com:/mirrors/gnu, gatekeeper.dec.com:/pub/GNU, ftp.uu.net:/systems/gnu For more information about software patents, please email me or lpf@uunet.uu.net. From alanje@cogs.susx.ac.uk Wed Apr 28 08:48:10 1993 Flags: 000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24838; Wed, 28 Apr 93 08:48:10 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #4) id m0noDMk-000Ev1C; Wed, 28 Apr 93 15:44 BST Message-Id: Date: Wed, 28 Apr 93 15:44 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: tex-fonts@math.utah.edu, dcfont-l@dhdurz1.bitnet, metafont@DMI.ENS.FR Subject: PostScript font installation in TeX, alpha release. Dear TeX font users, A prototype font installation package is available by anonymous ftp >From ftp.cogs.susx.ac.uk (192.33.16.70) in pub/tex/fontinst/*. This package allows you to install PostScript fonts (or any other fonts given in AFM format) in arbitrary encodings. Features of this font installer are that it: * Is written in TeX, for maximum portabilty (at the cost of speed). * Supports the full Cork encoding (as much as one can with PostScript fonts). * Allows fonts to be generated in an arbitrary encoding, with arbitrary `fake' characters---for example the `ij' character can be faked if necessary by putting an `i' next to a `j'. * Allows caps and small caps fonts with letter spacing and kerning. * Allows kerning to be shared between characters, for example `ij' can be kerned on the left as if it were an `i' and on the right as if it were a `j'. This is useful, since many PostScript fonts only include kerning information for characters without diacriticals. * Allows the generation of math fonts with nextlarger, varchar, and arbitrary font dimensions. * Allows more than one PostScript font to contribute to a TeX font, for example the `ffi' ligatures for a font can be taken from the Expert encoding, if you have it. * Automatically generates an fd file for use with version 2 of the New Font Selection Scheme. * Can be customized by the user to deal with arbitrary font encodings. At the moment, it's still being prototyped, so don't rely on it too much! I'll be talking about this package at the Aston TUG meeting, and I'd appreciate any feedback you can give me before (or indeed after) then. Cheers, Alan. Alan Jeffrey Tel: +44 273 606755 x 3238 alanje@cogs.sussex.ac.uk School of Cognitive and Computing Sciences, Sussex Univ., Brighton BN1 9QH, UK From karl@cs.umb.edu Fri May 28 12:47:40 1993 Flags: 000000000000 Return-Path: Received: from eris.cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00649; Fri, 28 May 93 12:47:40 MDT Received: by eris.cs.umb.edu id AA07860 (5.65c/IDA-1.4.4); Fri, 28 May 1993 14:47:08 -0400 Date: Fri, 28 May 1993 14:47:08 -0400 From: Karl Berry Message-Id: <199305281847.AA07860@eris.cs.umb.edu> To: tex-fonts@math.utah.edu, info-tex@shsu.bitnet, tex-archive@math.utah.edu, texhax@cs.washington.edu Subject: fontname 1.5/utopia 1.0/modes 0.13/urwfonts 1.0 Reply-To: karl@cs.umb.edu I've updated some of font-related TeX distributions. The font naming scheme (to version 1.5), the Adobe Utopia and Bitstream Charter fonts (version 1.0), modes.mf (version 0.13), and a new distribution, the fonts URW donated to Ghostscript. ftp.cs.umb.edu:pub/tex/{fontname,utopia,urwfonts.tar.z,modes.mf} Please notice the `.z' instead `.Z' -- I am now using gzip instead of compress. Adobe/Charter changes: match the latest dvips[k]. Fontname changes: The changes since version 1.4 are minimal: a couple of additional typefaces, variants, and sources. I also made two incompatible changes: 1) source `u' is now for URW instead of `user'. The latter seemed of dubious utility, and URW has contributed four fonts to the world (ftp.cs.umb.edu:pub/tex/urwfonts.tar.z). 2) Plantin is now pn instead of pi. Apparently most people were using pn anyway, and since it was free ... modes.mf changes: New modes for the Canon EX, QMS 1700, LPS 20, and Xerox Docutech devices, and a `null' mode to make only a TFM file. As always, thanks to the contributors. Let me know if you have questions or suggestions. karl@cs.umb.edu Member of the League for Programming Freedom---write to lpf@uunet.uu.net. From Martin.Ward@durham.ac.uk Mon Jun 7 08:39:57 1993 Flags: 000000000000 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24866; Mon, 7 Jun 93 08:39:57 MDT Via: uk.ac.durham; Mon, 7 Jun 1993 15:28:21 +0100 Received: from easby.dur.ac.uk by durham.ac.uk; Mon, 7 Jun 93 15:28:40 +0100 Received: from ws-csm3.durham.ac.uk (ws-csm3.dur) by uk.ac.durham.easby; Mon, 7 Jun 93 15:27:03 BST From: Martin Ward Date: Mon, 7 Jun 93 15:27:04 BST Message-Id: To: tex-fonts@math.utah.edu Subject: Problems with Longrightarrow and friends I have done some more experimentation with the \Longrightarrow problem. \Longrightarrow is constructed from a normal = (which I believe comes from the text fonts) and a \Rightarrow (from the cmsy font). These are placed side-to-side without overlapping. This leads to three potential problems: (1) With the dc fonts, digitised at 300dpi, the = comes out much thinner than the cm fonts. This means that it doesn't line up with the Rightarrow in cmsy. (2) There is a cmr17 but no cmsy17. At \huge or \Huge sizes, the = comes >From cmr17 but the Rightarrow comes from a scaled cmsy10. At these sizes, the symbols no longer match. (3) The Rightarrow and the = have slightly rounded ends to their horizontal bars. If these are abutted without overlapping, the result has one or more missing pixels in the horizontal bars. A quick fix for (3) is to replace \joinrel in the definition of \Longrightarrow, \Longleftarrow, Longleftrightarrow, etc. by \overlaprel which is defined: \def\overlaprel{\mathrel{\mkern-5mu}} \joinrel is defined: \def\joinrel{\mathrel{\mkern-3mu}} I don't have fixes for (1) and (2), can anyone help? Enclosed is a file which illustrates the problem. Martin. JANET: Martin.Ward@uk.ac.durham Internet (eg US): Martin.Ward@durham.ac.uk or if that fails: Martin.Ward%uk.ac.durham@nsfnet-relay.ac.uk or even: Martin.Ward%DURHAM.AC.UK@CUNYVM.CUNY.EDU BITNET: Martin.Ward%durham.ac.uk@UKACRL UUCP:...!uknet!durham!Martin.Ward \documentstyle{article} % Also try with [11pt] and [12pt]. \def\implies{\;\Longrightarrow\;} \begin{document} \noindent \scriptsize scriptsize: \[\implies\quad=\quad\iff\] \small small: \[\implies\quad=\quad\iff\] \normalsize normalsize: \[\implies\quad=\quad\iff\] \large large: \[\implies\quad=\quad\iff\] \Large Large: \[\implies\quad=\quad\iff\] \LARGE LARGE: \[\implies\quad=\quad\iff\] \huge huge: \[\implies\quad=\quad\iff\] \Huge Huge: \[\implies\quad=\quad\iff\] \end{document} From rocky@watson.ibm.com Fri Jul 23 13:04:05 1993 Flags: 000000000000 Return-Path: Received: from watson.ibm.com by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06147; Fri, 23 Jul 93 13:04:05 MDT Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9767; Fri, 23 Jul 93 15:04:04 EDT Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 2815; Fri, 23 Jul 1993 15:04:04 EDT Received: from rs6ktext.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Fri, 23 Jul 93 15:04:03 EDT Received: by rs6ktext.watson.ibm.com (AIX 3.2/UCB 5.64/920123) id AA16938; Fri, 23 Jul 1993 15:00:21 -0400 Date: Fri, 23 Jul 1993 15:00:21 -0400 From: rocky@watson.ibm.com (Rocky Bernstein) Message-Id: <9307231900.AA16938@rs6ktext.watson.ibm.com> X-External-Networks: yes To: tex-fonts@math.utah.edu Cc: ken@rchester.edu, , droms@bucknell.edu Subject: A small addition to dvidoc, txt, or crudetype Reply-To: rocky@watson.ibm.com I recently looked at the various packages to make the TeX system typeset for a crude ASCII typewriter (\'a l\`a nroff). Various packages on the net---dvidoc, txt and crudetype---all seem to have a similar style option or similar macro definitions. The macros change font definitions to use a (hypothetical?) monospace font called ``doc.'' Many of these package also come with doc.tfm. In none of these packages that I have come across is there a doc.mf, or doc.vf, or doc.300pk. In fact, I haven't found any of these on the net separately either. Well, you may be thinking ``Of course not, you are supposed to use the dvi file with crudetype (or dvi2tty, or...). It does the job of ignoring that non-existent font!'' But there are reasons why one might want to have a printable font around even though a corresponding dvi formatter only looks at the doc.tfm file. (Actually, perhaps there is just one reason with ramifications): 1) One might not have such a converter (dvi2tty, crudetype, etc.). I might just like to see what such programs might produce. 2) Related to this, I have a DVI file around created by a ``doc'' style (such as distributed in the ``txt'' package) and I'd just like to preview this. 3) Related to this, rather than go through the process of converting to ASCII text and printing this, I'd rather print in the fashion that I normally use for La/TeX or DVI files. For example, one might use the Emacs-oriented package auctex. Well, it didn't take long for me to turn doc.tfm into doc.vf to solve my problems. Basically, I mapped all of the characters in this font to the corresponding characters in cmtt10. Ideally one would want a font which is designed to be monospace; cmtt10 is not. For example, I had considered using an Adobe font, but decided against it for generality: there are many DVI drivers that don't understand or care about Adobe fonts. One might also argue that there are a number of dvi drivers that don't understand virtual fonts either. However, since virtual fonts should become more prevalent in the future and since dvicopy can be used to ``unvirtualize'' a virtual dvi file, it didn't strike me as a big issue. The other attractive alternative is to modify cmtt10, such as to remove ligatures and turn it into monospace. Is there a monospace MetaFont font already around? Comments? Be happy to share the vf. Really though, it was a trivial exercise in using tftopl, vptovf and a text editor. Regards, R. Bernstein From mackay@cs.washington.edu Mon Jul 26 16:27:31 1993 Flags: 000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11743; Mon, 26 Jul 93 16:27:31 MDT Received: by june.cs.washington.edu (5.65b/7.1ju) id AA15126; Mon, 26 Jul 93 15:27:25 -0700 Date: Mon, 26 Jul 93 15:27:25 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9307262227.AA15126@june.cs.washington.edu> To: rocky@watson.ibm.com Cc: tex-fonts@math.utah.edu, ken@rchester.edu, Schoepf@sc.ZIB-Berlin.de, droms@bucknell.edu In-Reply-To: Rocky Bernstein's message of Fri, 23 Jul 1993 15:00:21 -0400 <9307231900.AA16938@rs6ktext.watson.ibm.com> Subject: Re: A small addition to dvidoc, txt, or crudetype This is a great idea. I have often needed such output when better printers have broken down. Since Courier has been released for general use through the X consortium, why not use Courier. It is perhaps the single most successful monospaced design available to day. The glyphs can be supplied as bitmaps. They don't have to be in Type 1 format. ps2pk will do a neat job of making a sort of general bitmap (not fitted to any specific printer, but that doesn't matter too much with Courier). If you want some Courier.???pk files, let me know. I have ps2pk pretty well tamed now. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@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 From alanje@cogs.susx.ac.uk Tue Aug 3 11:35:31 1993 Flags: 000000000000 Return-Path: Received: from csuna.crn.cogs.susx.ac.uk (csuna-gw.susx.ac.uk) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10779; Tue, 3 Aug 93 11:35:31 MDT Received: by csuna.crn.cogs.susx.ac.uk (Smail3.1.28.1 #40) id m0oNQHH-00005yC; Tue, 3 Aug 93 18:35 BST Message-Id: Date: Tue, 3 Aug 93 18:35 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: dcfont-l@dhdurz1.bitnet, metafont@DMI.ENS.FR, tex-fonts@math.utah.edu Subject: Math font discussion list After the discussion about proposed new encodings for TeX math fonts at the Aston TUG meeting, I've set up a discussion list for TeX's math fonts, and the math font group's proposals. If you would like to be included on the list, please mail me at: math-font-request@cogs.susx.ac.uk See you on the net, 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 From alanje@cogs.susx.ac.uk Wed Aug 25 07:39:13 1993 Flags: 000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00534; Wed, 25 Aug 93 07:39:13 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #37) id m0oVL49-000EuvC; Wed, 25 Aug 93 14:39 BST Message-Id: Date: Wed, 25 Aug 93 14:39 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: tex-fonts@math.utah.edu Subject: Font naming rears its ugly head again Dear all, I'm currently working on v1.x of the fontinst package for creating Virtual Fonts out of AFM or TFM files. A preliminary (very user-unfriendly!) version was described at the Aston meeting, and is available from CTAN in fonts/utilities/fontinst. The fontinst package produces rather different VFs from afm2tfm or Sebastian's PSNFSS, most noticably in the c&sc fonts, which are letterspaced. So, I've been thinking about what I should call these fonts in the ghastly 8+3 format we all know and... er... love. At the moment, I'm using Karl's scheme, so the Adobe Times Roman fonts are: ptmrq Adobe Times Roman u&lc Cork ptmrcq Adobe Times Roman c&sc Cork But this isn't totally satisfactory, since it makes dvi files rather unportable... if you receive a dvi file containing the font ptmrq, whose ptmrq should you use? To get round this, what I'd like to do is use a `unique' prefix for the fonts I generate (say `f1' for `fontinst') and then use my own scheme for the remaining 6 characters. For example: f1ptmXXX Adobe Times Roman u&lc Cork, made with fontinst f1ptmYYY Adobe Times Roman c&sc Cork, made with fontinst I was planning to use the remaining three characters (after the `f1' prefix and the 3-letter family name) to encode a 15-bit number, with something like: 5 bits for weight 1 bit for slanted / upright 1 bit for roman / italic 2 bits for u&lc / c&sc / all-caps / all-small-caps 1 bit for lining / non-lining digits 1 bit for whether it was created with an expert set 4 bits for encoding Would anyone object to this? I'm sorry to have to break the mold of Karl's scheme, but I can't see any other way of avoiding clashing font names... Alan. From DHOSEK@HMCVAX.Ac.HMC.Edu Wed Aug 25 12:41:22 1993 Flags: 000000000000 Return-Path: Received: from HMCVAX.AC.HMC.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03754; Wed, 25 Aug 93 12:41:22 MDT Received: from HMCVAX.Ac.HMC.Edu by HMCVAX.Ac.HMC.Edu (PMDF #4220 ) id <01H25SYIFUVU9N4533@HMCVAX.Ac.HMC.Edu>; Wed, 25 Aug 1993 11:41:18 PST Date: 25 Aug 1993 11:41:18 -0800 (PST) From: Don Hosek Subject: Re: Font naming rears its ugly head again To: alanje@cogs.susx.ac.uk Cc: tex-fonts@math.utah.edu Message-Id: <01H25SYIFUVW9N4533@HMCVAX.Ac.HMC.Edu> X-Vms-To: IN%"alanje@cogs.susx.ac.uk" X-Vms-Cc: IN%"tex-fonts@math.utah.edu" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT I've discussed this with a number of people. A few thoughts: -DVI files tend not to be distributed except under controlled circumstances. Far more common is the distribution of TeX input files or printer output files (e.g. PostScript). Therefore, the point is moot. -Because of the above point, rather than a generic naming system, a mapping of the TeX font name to a generic description might be more useful. e.g., for the simple case of Times Roman, Adobe Standard Encoding which I might call rptmr and you might call Times-Roman, we could have a system along the following lines: Everybody has maintained a mapping file from local TeX name to a more generic name. This could be generated by a program like fontinst, for example. A possible format might be rptmr TimesRoman-Regular-AdobeStandardEncoding-*-* Before I send you a DVI file, I process it with a program which replaces instances of rptmr with Times-Romanetc. You then run on your system a program which reverses the process and creates a DVI file where the names Times-Romanetc. is replaced with Times-Roman. Lack of correlation could be taken care of at this point. -VF files probably should be part of the exchange when DVI files are exchanged. As an aside, on my system, I use a modified Berry scheme for font naming and not entirely consistently. Effort has been taken to maintain a database mapping TeX font names to something more user-friendly. -dh From alanje@cogs.susx.ac.uk Wed Aug 25 14:24:31 1993 Flags: 000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA05759; Wed, 25 Aug 93 14:24:31 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #37) id m0oVROR-000EuvC; Wed, 25 Aug 93 21:24 BST Message-Id: Date: Wed, 25 Aug 93 21:24 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: tex-fonts@math.utah.edu Subject: Re: Font naming rears its ugly head again Don Hosek writes: >-DVI files tend not to be distributed except under controlled >circumstances. Far more common is the distribution of TeX input >files or printer output files (e.g. PostScript). Therefore, the >point is moot. I only wish this were true! Our department swaps dvi files by anonymous ftp all over the place---I know about this because I'm the one they complain to when things go wrong! I try to encourage people to send PostScript instead, but to no avail... >-Because of the above point, rather than a generic naming system, >a mapping of the TeX font name to a generic description might be >more useful. In the long term, I think we need to come up with some standard system like this. Even something as simple as an agreement between TeX implementors as to a standard character to use as a directory separator would do---then I would know that the font: fontinst.adobe.times.roman.medium.cork would be: fontinst/adobe/times/roman/medium/cork on UNIX fontinst:adobe:times:roman:medium:cork on Macintosh fontinst\adobe\times\roman\medium\cork on MS-DOS etc. But such a system really needs to be inside TeX in order to be transparent to the end user. >-VF files probably should be part of the exchange when DVI files >are exchanged. I'm lucky if I can persuade some of the users here to remove the read protection from their DVI files when they ask other people to read them! The only way I'll persuade anyone here to use fonts other than CM is if their use is completely transparent. And this means that they'll carry on swapping dvi files around. I'd just like to make sure that when they do this, and some fonts are missing, that they get a `font missing' error rather than an incomprehensible checksum error. Alan. From leafusa!owl.HQ.Ileaf.COM!karl@uunet.UU.NET Mon Aug 30 10:33:13 1993 Flags: 000000000000 Return-Path: Received: from relay2.UU.NET by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23485; Mon, 30 Aug 93 10:33:13 MDT Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05053; Mon, 30 Aug 93 12:33:04 -0400 Received: from leafusa.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 123153.6791; Mon, 30 Aug 1993 12:31:53 EDT Received: from owl.HQ.Ileaf.COM by HQ.Ileaf.COM (4.1/SMI-4.0-leafusa) for tex-fonts@math.utah.edu id AA09988; Mon, 30 Aug 93 12:26:48 EDT Received: by owl.HQ.Ileaf.COM (4.1/SMI-4.0-hq) for tex-fonts@math.utah.edu id AA01620; Mon, 30 Aug 93 12:26:26 EDT Date: Mon, 30 Aug 93 12:26:26 EDT From: karl@owl.HQ.Ileaf.COM (Karl Berry) Message-Id: <9308301626.AA01620@owl.HQ.Ileaf.COM> To: tex-fonts@math.utah.edu In-Reply-To: (alanje@cogs.susx.ac.uk) Subject: Re: Font naming rears its ugly head again Reply-To: karl@cs.umb.edu if you receive a dvi file containing the font ptmrq, whose ptmrq should you use? ptmrq defines a unique font -- Adobe Times Roman in the Cork encoding. It shouldn't matter what generated it. If it does matter, then there must be some other difference in the font. In your case, I guess it is letterspacing. So the way to fit this into the Karl scheme (which I wish we could call something else :-) is to make a new variant letter for whether the thing is letterspaced or not. I suppose I could give up one of my precious two remaining variant characters (7 and 8) for that, if you are really married to letterspacing your font, which I bet you are ... use a `unique' prefix for the fonts I generate (say `f1' for `fontinst') Can't one generate a font that would be identical with the current ptmr.tfm (say) using fontinst? Conversely, I bet one can get a TFM/VF identical with yours using afm2tfm. I think the method of generation is not important to encode -- it's the final resulting font that counts. use the remaining three characters (after the `f1' prefix and the 3-letter family name) to encode a 15-bit number As long as you realize this doesn't cover the possibilities, either ... The only way to do that is to do what Don (and you) suggest elsewhere, just go to variable length names. If you adopt this, I advise a single character for the source; I'm not even close to using up the 36 possibilities for the source yet. Don> Before I send you a DVI file, I process it with a program which replaces instances of rptmr with Times-Roman-etc. You then run on your system a program which reverses the process and creates a DVI file where the names Times-Roman-etc. is replaced with Times-Roman. I think this is a good idea. web2c and my other programs have had a mapping file (texfonts.map) to allow precisely this for a couple of releases now, but as far as I know no one is using it. (I'm not.) The only problem is that the long Times-Roman-etc filenames have to be replaced with *something* for the actual filename -- and so why not make the actual filenames the same on different systems? At least, that's the reasoning I make to myself. Alan> simple as an agreement between TeX implementors as to a standard character to use as a directory separator That doesn't sound simple to me, because why do TeX fontnames necessarily have to map onto particular directory structures? Unless you want to limit names to 8 characters, they won't ... From alanje@cogs.susx.ac.uk Mon Aug 30 14:03:52 1993 Flags: 000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26433; Mon, 30 Aug 93 14:03:52 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #37) id m0oXFS6-000EuvC; Mon, 30 Aug 93 21:03 BST Message-Id: Date: Mon, 30 Aug 93 21:03 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: tex-fonts@math.utah.edu Subject: Re: Font naming rears its ugly head again >ptmrq defines a unique font -- Adobe Times Roman in the Cork encoding. >It shouldn't matter what generated it. If it does matter, then there >must be some other difference in the font. Indeed. The differences between the Cork encoded Adobe Times generated by fontinst and that distributed with psnfss are (or rather, will be, once I've finished the thing!): * font dimensions: the afm2tfm program produces very sparse setting, with large values for space, stretch and shrink. The fontinst package produces much tighter setting * kerning: the composite letters are kerned the same as the non-composite equivalents, for example kerns like , and kerns like on the left and on the right. This is necessary because many PostScript fonts (notably those from Adobe) don't have any kerning for non-American glyphs. * monospace fonts: the fontinst package goes out of its way to make sure the monospaced fonts are monospaced, for example letterspacing the small caps so that they're the same width as the caps. It also provides for number-range-dash and punctuation-dash ligatures in Cork-encoded monowidth fonts. * expert fonts: the fontinst package can produce fonts which mix glyphs from the standard and expert font, so at a site with the expert fonts, the and glyphs would come from the standard encoding, and the glyph from the expert encoding. * digit styles: the fontinst package can generate fonts with ranging or oldstyle digits, and with fixed-width or variable-width digits. * rounding errors: the rounding errors produced by the fontinst package when converting afm dimensions to TeX dimensions will be slightly different from those produced by afm2tfm. There are a few other differences (such as accent positioning) but I don't think those make any difference to the tfm file. The problem is that even just looking at the fonts generated by the fontinst package, there's: * the encoding (Cork, text symbol, math symbol, etc.) * the digit styles (lining/oldstyle and fixed-width/variable-width) * the letter styles (u&lc, c&sc, all-caps) * whether the font was generated using the expert font or not * the weight (light, medium, demi-bold, bold, ultra-bold, etc.) * the width (condensed, semi-condensed, medium, semi-expanded, etc.) * the shape (roman, italic, oblique, etc.) Just by giving each of these parameters a letter, plus three letters for the font family, I'd already have used ten letters! This is a real pain :-( because I think your naming scheme is pretty impressive, and I'd like to use it if possible. I'm just worried about hitting the 8+3 MessyDOS wall pretty soon. >Can't one generate a font that would be identical with the current >ptmr.tfm (say) using fontinst? One can, by switching off most of the extra features of the fontinst package. >Conversely, I bet one can get a TFM/VF identical with yours using >afm2tfm. If that was possible I wouldn't have written the fontinst package! >As long as you realize this doesn't cover the possibilities, either ... Indeed it won't, but then nothing stuck to an 8+3 filename will. I'd just like a naming scheme that will cope with the fonts generated by v1.x of the fontinst package, and have as much scope for expansion as I can get away with using the silly 8+3 filenames we're stuck with for the moment. I'll see if I can get away with just 6 characters for this, but I might end up needing 7. >That doesn't sound simple to me, because why do TeX fontnames >necessarily have to map onto particular directory structures? Unless >you want to limit names to 8 characters, they won't ... Yes, I was expecting a limit to 8 characters between directory separators. This is still a pain, but it's better than 8 characters for the entire filename! Alan. From mackay@cs.washington.edu Mon Aug 30 14:47:43 1993 Flags: 000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27167; Mon, 30 Aug 93 14:47:43 MDT Received: by june.cs.washington.edu (5.65b/7.1ju) id AA02654; Mon, 30 Aug 93 13:47:42 -0700 Date: Mon, 30 Aug 93 13:47:42 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9308302047.AA02654@june.cs.washington.edu> To: alanje@cogs.susx.ac.uk Cc: tex-fonts@math.utah.edu In-Reply-To: Alan Jeffrey's message of Mon, 30 Aug 93 21:03 BST Subject: Re: Font naming rears its ugly head again Indeed. The differences between the Cork encoded Adobe Times generated by fontinst and that distributed with psnfss are (or rather, will be, once I've finished the thing!): * font dimensions: the afm2tfm program produces very sparse setting, with large values for space, stretch and shrink. The fontinst package produces much tighter setting The values for spacing are apparently fixed for stretch and shrink, but the basic space is taken from the width of the space character in the afm file. I once tried zeroing out that width in the afm file before inputting to afm2tfm and got a font with no interword space at all. Anyway, the loose setting is governed more by what the producer of the afm file sets than by afm2tfm * kerning: the composite letters are kerned the same as the non-composite equivalents, for example kerns like , and kerns like on the left and on the right. This is necessary because many PostScript fonts (notably those from Adobe) don't have any kerning for non-American glyphs. That will be a great addition, although I suspect that kerning is becoming a dangerous mania. The huge Kern Pair table in my Monotype BaskervilleMT.afm produces a set so tight it squeeks, and in medium resolution at least it is impossible to keep letters >From bleeding into each other in the Italics. Oddly, the afm for this font is copyrighted by Adobe, not by Monotype. I hope it doesn't turn out to be a NewBaskerville table hacked mechanically into shape. Better no kerning at all than that. For now, I relax the entire set of leftward kern values by 1/2 unit. In lowercase, the kerning for an accented letter may not be the same as for the unadorned letter. A heavily accented language like Turkish gets to look very fussy if kerned as tightly as English text * monospace fonts: the fontinst package goes out of its way to make sure the monospaced fonts are monospaced, for example letterspacing the small caps so that they're the same width as the caps. It also provides for number-range-dash and punctuation-dash ligatures in Cork-encoded monowidth fonts. figuredash is provided as a simple glyph in a lot of expert fonts, but the width is the same as endash, and more interestingly the charcter bounding box is the same. If you make up a special figure-dash you are certainly adding more finesse than the commercial fonts I have seen. * expert fonts: the fontinst package can produce fonts which mix glyphs from the standard and expert font, so at a site with the expert fonts, the and glyphs would come from the standard encoding, and the glyph from the expert encoding. This is of course possible now, but only by hand editing the vpl file. * digit styles: the fontinst package can generate fonts with ranging or oldstyle digits, and with fixed-width or variable-width digits. Ditto. * rounding errors: the rounding errors produced by the fontinst package when converting afm dimensions to TeX dimensions will be slightly different from those produced by afm2tfm. There are a few other differences (such as accent positioning) I think you may have real trouble automating accent positioning. I have recently worked on a set of under and over accents for Turkish, and I found no way of getting satisfactory general accent positioning, especially in italics except by hand editing over about five passes. The worst, or best, of it is that when egregiously badly placed accents are corrected, they make some that had previously looked acceptable look painfully out of place. but I don't think those make any difference to the tfm file. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@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 From mackay@cs.washington.edu Mon Aug 30 15:10:38 1993 Flags: 000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27425; Mon, 30 Aug 93 15:10:38 MDT Received: by june.cs.washington.edu (5.65b/7.1ju) id AA07225; Mon, 30 Aug 93 14:10:35 -0700 Date: Mon, 30 Aug 93 14:10:35 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9308302110.AA07225@june.cs.washington.edu> To: alanje@cogs.susx.ac.uk Cc: tex-fonts@math.utah.edu In-Reply-To: Alan Jeffrey's message of Mon, 30 Aug 93 21:03 BST Subject: Re: Font naming rears its ugly head again I plan to propose this in TeXhax, since Tom Rokicki assures me that I have not misunderstood afm2tfm. It should be relevant to fontinst too *********************************************************** Over the course of a rich discussion of virtual fonts, I have finally come to understand and appreciate the full usefulness of Tom Rokicki's careful distinction between input encoding and output encoding in afm2tfm. In a virtual font environment it answers the questions that have recently been raised about the proper encoding of a {\em raw} tfm file. The raw tfm should contain references to every simple (non-composite) character in the actual list of glyphs, and it need not contain anything else. Dozens of possible output encodings are possible, among which DC will of course be a major player, but all those reencodings will be easier and more portable if there is only one {\em raw} encoding. The raw encoding should provide for {\em every} simple character in the font, including all the unmapped characters. Fortunately, the list of unmapped characters is almost as consistent as Adobe Standard Encoding at least in text fonts. I propose therefore the following ASEX.enc (Adobe Standard Coding Extended) to be used with the -p flag in afm2tfm. What is used for the -t flag is wide open, but it can certainly include DC.enc There remains the question of what to do about the various Superfont layouts: Courier in its most prolific version has 352 simple characters and the Monotype TimesNewRomanSF Superfont has 337 simple characters. In the case of TimesNewRoman, the excess is the result of combining the regular with the expert font, and all that is needed is to code the expert part back out into an expert raw TFM file. Then there are only 11 pairs of additional simple characters. A similar approach can be taken with Courier; many of the symbol characters, together with the borders and dingbats do not belong in a tex encoding anyway. % ------------------------------------------------------------------------- % % This is ASEX encoding. (file ASEX.enc) % % Adobe Standard Encoding Extended. % % Creator: Pierre A. MacKay mackay@cs.washington.edu % Creation Date: Thu Aug 26 09:42:27 PDT 1993 % % This is an input coding file for use with Radical Eye Software's % afm2tfm. Use with the -p flag. This file should also be % used with ps2pk to create a complete set of bitmapped % characters. % % The sole purpose of this file is to ensure that all non-composite % 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 on 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. % % Usage: % afm2tfm .afm -p ASEX.enc -t .enc -v % /ASEXEncoding [ % 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 % Keep the space, for use as \boundarychar (Zero width in vpl) /space /exclam /quotedb /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 % include them here. Characters are entered in alphabetical order % by name. % % 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 % % The following may 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 % % 0x00 % /Aogonek /Iogonek /Kafii9170 /Lafii9170 /Lcaron /Nafii9170 /Rafii9170 /Safii9170 % /Scedilla /Tafii9170 /Uogonek /.notdef /.notdef /.notdef /.notdef /.notdef % 0x10 % /aogonek /iogonek /kafii9170 /lafii9170 /lcaron /nafii9170 /rafii9170 /safii9170 % /scedilla /tafii9170 /uogonek /.notdef /.notdef /.notdef /.notdef /.notdef Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@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 From alanje@cogs.susx.ac.uk Tue Aug 31 05:42:27 1993 Flags: 000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12552; Tue, 31 Aug 93 05:42:27 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #37) id m0oXU6E-000EuvC; Tue, 31 Aug 93 12:42 BST Message-Id: Date: Tue, 31 Aug 93 12:42 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: mackay@cs.washington.edu Cc: tex-fonts@math.utah.edu In-Reply-To: <9308302047.AA02654@june.cs.washington.edu> (mackay@cs.washington.edu) Subject: Re: Font naming rears its ugly head again Pierre MacKay writes: >The values for spacing are apparently fixed for stretch and shrink, but the >basic space is taken from the width of the space character in the afm file. Hmm... goes and investigates... It turns out that afm2tfm only uses the width of the space character when the space character is part of the output encoding. So if I say afm2tfm lbr -O -T adobe.enc -v lbr0.vpl afm2tfm lbr -O -T T1ulc.enc -v lbrq.vpl then the Adobe-encoded (with a space characrter) lbr0.vpl has (SPACE D 304) (STRETCH D 200) (SHRINK D 100) (EXTRASPACE D 111) and the Cork-encoded (without a space character) lbrq.vpl has: (SPACE D 500) (STRETCH D 200) (SHRINK D 100) (EXTRASPACE D 111) Ah, this explains why I've been getting such loose setting from afm2tfm, since I've been using an output encoding which doesn't have a space glyph. For reference, the default values produced by fontinst would be (in points): (SPACE R 3.04) (STRETCH R 1.01) (SHRINK R 1.01) (EXTRASPACE R 0.0) These values haven't been extensively road-tested yet, and I may need to loosen up a bit to avoid overfull boxes everywhere. We shall see. I chose these values after Richard Southall's talk at Aston, where he pointed out plain TeX's love of white space, and the resulting visual fragmentation. >That will be a great addition, although I suspect that kerning is >becoming a dangerous mania. Indeed... but you have to do something with kerning for non-US glyphs. I suspect what I'll do is fake the kerning for uppercase composites and lowercase composites with ascenders, but not the kerning for lowercase composites without ascenders, in order to avoid a collision with things like . It's a hack, but what can you do... >If you make up a special figure-dash you are certainly >adding more finesse than the commercial fonts I have seen. Sorry, I should have been clearer about this! There's been some discussion on the DC list about whether monowidth fonts should include -- and --- ligatures. The current proposal is that -- should ligature to a number-range dash and --- should ligature to a puncutation dash. In many monowidth fonts, the number-range dash will look just like and the puncutation dash will look just like . This conforms to UK typing of correspondence... I've asked Rainer Schoepf about this, and we hacked out some code for verbatim mode which switches off this ligaturing, so -- in verbatim will still produce . Modulo bug-testing, this will probably be in LaTeX2e. >I think you may have real trouble automating accent positioning. Indeed! Most of the accents can be approximated automatically---the results won't be excellent, but they'll be passable. But there are some composite glyphs in the Cork encoding that just can't be faked, notably: Unfortunately, optimizing the last three also changes the tfm file, drat and bah humbug. Really there's no way to get accent positioning right without human intervention. Part of the idea behind the fontinst package (this is turning into an advert :-) sorry!) is to make hand-tweaking simpler, since the fontinst package allows for (almost) every part of the VPL file it generates to be over-ridden by the user. So rather than hand-editing the VPL file, you just produce a file containing the tweaks, for example: \setglyph{Lacute} \topaccent{L}{acute}{123} \endsetglyph \setglyph{lcaron} \glyph{l} \movert{-96} \glyph{quoteright} \endsetglyph then you run the fontinst package a few times to get the numbers just right, and hey presto, a tweaked font without any hand-editing of VPL files. The fontinst package even generates a font table, so you can even tweak the font without having to run vptovf! This does produce yet another problem with font naming, of course, as you now have a parameter for whether the font has been tweaked or not. And of course, there may be different tweakings of the same font... Oh if only all AFM files had CC instructions for all the Cork composite glyphs, life would be so much simpler... Alan. From mackay@cs.washington.edu Tue Aug 31 09:29:56 1993 Flags: 000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16894; Tue, 31 Aug 93 09:29:56 MDT Received: by june.cs.washington.edu (5.65b/7.1ju) id AA13843; Tue, 31 Aug 93 08:29:48 -0700 Date: Tue, 31 Aug 93 08:29:48 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9308311529.AA13843@june.cs.washington.edu> To: alanje@cogs.susx.ac.uk Cc: tex-fonts@math.utah.edu In-Reply-To: Alan Jeffrey's message of Tue, 31 Aug 93 12:42 BST Subject: Re: Font naming rears its ugly head again Oh if only all AFM files had CC instructions for all the Cork composite glyphs, life would be so much simpler... Can I interest you in a toolkit that uses awk to create both C -1 lines for new composites and also CC lines for the actual recipe? It even creates a pseudo-afm file for METAFONT fonts. Why would one want to do that? Because afm is more compact than the various alternatives and easier to edit. Besides, it is the natural raw material for conversions to vpl. The CC lines created by the toolkit are really good for upright fonts, and an adequate base for hacking in the case of italic or obliqued fonts. logarithms are built into awk, bit trigonometry is not. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@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 From alanje@cogs.susx.ac.uk Tue Aug 31 09:40:58 1993 Flags: 000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16977; Tue, 31 Aug 93 09:40:58 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #37) id m0oXXp5-000EuvC; Tue, 31 Aug 93 16:40 BST Message-Id: Date: Tue, 31 Aug 93 16:40 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: mackay@cs.washington.edu Cc: tex-fonts@math.utah.edu In-Reply-To: <9308311529.AA13843@june.cs.washington.edu> (mackay@cs.washington.edu) Subject: Re: Font naming rears its ugly head again >Can I interest you in a toolkit that uses awk to create >both C -1 lines for new composites and also CC >lines for the actual recipe? It even creates >a pseudo-afm file for METAFONT fonts. This sounds very useful for use with afm2tfm! It's not quite so useful for fontinst, since it's doing much of the same work (automatically generating composite characters from AFM files). What's really needed is for font producers to provide CC instructions for more glyphs in their AFM files! But that's not very likely (sigh). Perhaps I should have a look at the SuperFont AFMs, and see if I can steal the CC instructions out of those. Is there an ftp site I can have a look at the SuperFonts for the standard Adobe fonts? This would (I think) solve the problem for fonts with SuperFont AFMs, but the rest of the world is still rather stuck! Alan. From DHOSEK@HMCVAX.Ac.HMC.Edu Tue Aug 31 11:32:06 1993 Flags: 000000000000 Return-Path: Received: from HMCVAX.AC.HMC.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20451; Tue, 31 Aug 93 11:32:06 MDT Received: from HMCVAX.Ac.HMC.Edu by HMCVAX.Ac.HMC.Edu (PMDF #4220 ) id <01H2E4E44ZWS91VT1J@HMCVAX.Ac.HMC.Edu>; Tue, 31 Aug 1993 10:32:02 PST Date: 31 Aug 1993 10:32:02 -0800 (PST) From: Don Hosek Subject: Re: Font naming rears its ugly head again To: alanje@cogs.susx.ac.uk Cc: tex-fonts@math.utah.edu Message-Id: <01H2E4E459JY91VT1J@HMCVAX.Ac.HMC.Edu> X-Vms-To: IN%"alanje@cogs.susx.ac.uk" X-Vms-Cc: IN%"tex-fonts@math.utah.edu" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT - Sorry, I should have been clearer about this! There's been some - discussion on the DC list about whether monowidth fonts should include - -- and --- ligatures. The current proposal is that -- should ligature - to a number-range dash and --- should ligature to a puncutation dash. - In many monowidth fonts, the number-range dash will look just like - and the puncutation dash will look just like - . This conforms to UK typing of correspondence... I did this in my CMPICA fonts. Only one spare glyph is needed really. -- becomes a character which only looks like a hyphen but has its own code. That plus a hyphen yields (guess what!) something that looks like --. However, I think that their is a real need to distinguish a monospace font for text usage vs. a monospace font for listing usage. The following characteristics (roughly speaking) should be only in the former: -- == - --- == -- ' == ' (straight single quote) ` == ' (straight single quote) '' == " (straight double quote) `` == " (straight double quote) cf. cmpica. What is really needed is TeX-settable encoding, kerning and ligaturing. Incidentally, an interesting note. I believe only TeX is capable of ligatures along the lines of AB == DB which could have real uses (e.g., a variant r in a sans serif font for the rn combination which keeps it from looking too much like m. q.v. the discussion in typo-l). -dh From mackay@cs.washington.edu Tue Aug 31 11:57:44 1993 Flags: 000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21295; Tue, 31 Aug 93 11:57:44 MDT Received: by june.cs.washington.edu (5.65b/7.1ju) id AA23773; Tue, 31 Aug 93 10:57:42 -0700 Date: Tue, 31 Aug 93 10:57:42 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9308311757.AA23773@june.cs.washington.edu> To: alanje@cogs.susx.ac.uk Cc: tex-fonts@math.utah.edu In-Reply-To: Alan Jeffrey's message of Tue, 31 Aug 93 16:40 BST Subject: Re: Font naming rears its ugly head again I doubt there is a public-domain superfont available. It looks as if what we are doing constitutes fair use according to the article in the latest ACM journal so I will send you separately a copy of the TimesNewRomanSF.afm. If you can explain to me why there are five copies if the kerning data I will be interested in the answer. On second thought, however, I will remove the redundancy to ease the load on the mailing service. (Can the repetition have something to do with the awful habit if tracking?) Apologies to Kernighan et al. The only documentation I have had available, which isn't bad as far as it goes, gives what you would expect to be a comprehensive list of built-in functions for awk, and it doesn't include trig. Is it possible that trig is a more recent addition? Oh well, one more title to be added to the bookshelf. I wonder whether a peek at the coding of the eexec part of pfa files using eexec.en.de.code would give a clue to which characters are composites and which simple? Some afm's are pretty close-mouthed about it. I don't think the CharterBT.afm offers any information at all. We mustn't be ungrateful, but I think I may look into the mouth of that gift horse. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@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 From jmr@nada.kth.se Tue Aug 31 13:45:48 1993 Flags: 000000000000 Return-Path: Received: from cyklop.nada.kth.se by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22820; Tue, 31 Aug 93 13:45:48 MDT Received: by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA22932; Tue, 31 Aug 93 21:45:39 +0200 Date: Tue, 31 Aug 93 21:45:37 +0200 From: Jan Michael Rynning To: mackay@cs.washington.edu (Pierre MacKay) Cc: tex-fonts@math.utah.edu Subject: Re: Font naming rears its ugly head again In-Reply-To: Your message of Mon, 30 Aug 93 14:10:35 -0700 Message-Id: Pierre MacKay writes: > Over the course of a rich discussion of virtual fonts, I have > finally come to understand and appreciate the full usefulness > of Tom Rokicki's careful distinction between input encoding > and output encoding in afm2tfm. In a virtual font environment > it answers the questions that have recently been raised about > the proper encoding of a {\em raw} tfm file. The raw tfm > should contain references to every simple (non-composite) > character in the actual list of glyphs, and it need not contain > anything else. Dozens of possible output encodings are > possible, among which DC will of course be a major player, > but all those reencodings will be easier and more portable > if there is only one {\em raw} encoding. The raw encoding should > provide for {\em every} simple character in the font, including > all the unmapped characters. Fortunately, the list of > unmapped characters is almost as consistent as Adobe Standard > Encoding at least in text fonts. I propose therefore > the following ASEX.enc (Adobe Standard Coding Extended) > to be used with the -p flag in afm2tfm. What is used for > the -t flag is wide open, but it can certainly include DC.enc In your raw encoding you have left out all the accented letters. There are two important reasons why I think they should be encoded in the raw font: 1. In some high-quality fonts, which Adobe obviously put more work into than others, like Adobe Garamond and Adobe Caslon, the accented letters are not composite characters. If you look at them you'll see that most of the accents have a different shape for upper and lower case letters. These well-designed accented letters should not be replaced by much worse-looking composite characters created by dvips. 2. In fonts where the accented letters are composite characters, the accents are usually more accurately positioned, especially at low resolution, in the built-in ones than in the ones created by dvips. Most of Adobe's fonts, regardless of whether the accented letters are composite characters, have the same set of 228 glyphs. I have created a true superset of Adobe's StandardEncoding, which has the following properties: 1. All the glyphs in Adobe's StandardEncoding are present and have the same position in the encoding. 2. All the other glyphs from that ``standard'' set of 228 are put into unused positions in Adobe's StandardEncoding. I've tried to keep ``similar'' characters together, so my encoding isn't completely arbitrary. Here it is: % % This is adobe228, a superset of Adobe's StandardEncoding which maps all % the 228 glyphs which are included in most of Adobe's fonts. % % Created by Jan Michael Rynning 1992-09-12. % /adobe228 [ % now 256 chars follow % 0x00 /Aacute /Acircumflex /Adieresis /Agrave /Aring /Atilde /Ccedilla /Eacute /Ecircumflex /Edieresis /Egrave /Eth /Iacute /Icircumflex /Idieresis /Igrave % 0x10 /Ntilde /Oacute /Ocircumflex /Odieresis /Ograve /Otilde /Scaron /Thorn /Uacute /Ucircumflex /Udieresis /Ugrave /Yacute /Ydieresis /Zcaron /.notdef % 0x20 /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 % 0x80 /aacute /acircumflex /adieresis /agrave /aring /atilde /ccedilla /eacute /ecircumflex /edieresis /egrave /eth /iacute /icircumflex /idieresis /igrave % 0x90 /ntilde /oacute /ocircumflex /odieresis /ograve /otilde /scaron /thorn /uacute /ucircumflex /udieresis /ugrave /yacute /ydieresis /zcaron /.notdef % 0xA0 /.notdef /exclamdown /cent /sterling /fraction /yen /florin /section /currency /quotesingle /quotedblleft /guillemotleft /guilsinglleft /guilsinglright /fi /fl % 0xB0 /brokenbar /endash /dagger /daggerdbl /periodcentered /degree /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 /onesuperior /twosuperior /threesuperior /onequarter /onehalf /threequarters /logicalnot /plusminus /minus /multiply /divide /copyright /registered /trademark /mu % 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 Jan Michael Rynning Email: jmr@nada.kth.se Department of Numerical Analysis and Computing Science Voice: +46-8-7906288 Royal Institute of Technology Fax: +46-8-7900930 S-100 44 Stockholm Sweden Normal host: jmr.nada.kth.se From karl@cs.umb.edu Tue Aug 31 13:55:01 1993 Flags: 000000000000 Return-Path: Received: from terminus.cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22863; Tue, 31 Aug 93 13:55:01 MDT Received: by terminus.cs.umb.edu id AA17439 (5.65c/IDA-1.4.4 for tex-fonts@math.utah.edu); Tue, 31 Aug 1993 15:54:41 -0400 Date: Tue, 31 Aug 1993 15:54:41 -0400 From: Karl Berry Message-Id: <199308311954.AA17439@terminus.cs.umb.edu> To: alanje@cogs.susx.ac.uk Cc: tex-fonts@math.utah.edu In-Reply-To: Alan Jeffrey's message of Mon, 30 Aug 93 21:03 BST Subject: Font naming rears its ugly head again Reply-To: karl@cs.umb.edu Just by giving each of these parameters a letter, plus three letters for the font family, I'd already have used ten letters! Have to combine. This is a real pain :-( Tell me about it :-( :-( I think your naming scheme is pretty impressive I don't; I think it stinks! I just don't see any way to do better. hitting the 8+3 MessyDOS wall pretty soon. Oh, we were splatted against this wall long long ago ... * the encoding (Cork, text symbol, math symbol, etc.) * the digit styles (lining/oldstyle and fixed-width/variable-width) * the letter styles (u&lc, c&sc, all-caps) * whether the font was generated using the expert font or not * the shape (roman, italic, oblique, etc.) These are all combined in to the variant. I think the only thing in the above that's not covered now is all-caps. Oh, and ``text symbol'', since there is no such thing in existing fonts (is there?). * the weight (light, medium, demi-bold, bold, ultra-bold, etc.) * the width (condensed, semi-condensed, medium, semi-expanded, etc.) These got their own letters, so they should be fine. From karl@cs.umb.edu Tue Aug 31 13:57:34 1993 Flags: 000000000000 Return-Path: Received: from terminus.cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22882; Tue, 31 Aug 93 13:57:34 MDT Received: by terminus.cs.umb.edu id AA17465 (5.65c/IDA-1.4.4 for tex-fonts@math.utah.edu); Tue, 31 Aug 1993 15:57:30 -0400 Date: Tue, 31 Aug 1993 15:57:30 -0400 From: Karl Berry Message-Id: <199308311957.AA17465@terminus.cs.umb.edu> To: alanje@cogs.susx.ac.uk Cc: tex-fonts@math.utah.edu In-Reply-To: Alan Jeffrey's message of Mon, 30 Aug 93 21:03 BST Subject: Font naming rears its ugly head again Reply-To: karl@cs.umb.edu 8 characters between directory separators. This is still a pain, but it's better than 8 characters for the entire filename! I don't think imposing a directory structure on installers will go over at all well. Beyond that, if the filenames themselves are not unique (i.e., independent of what directory they're in), I bet most TeX implementations won't be able to deal with them. web2c won't, anyway. From jmr@nada.kth.se Tue Aug 31 14:02:08 1993 Flags: 000000000000 Return-Path: Received: from cyklop.nada.kth.se by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22917; Tue, 31 Aug 93 14:02:08 MDT Received: by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA25718; Tue, 31 Aug 93 22:02:02 +0200 Date: Tue, 31 Aug 93 22:02:01 +0200 From: Jan Michael Rynning To: mackay@cs.washington.edu (Pierre MacKay) Cc: tex-fonts@math.utah.edu Subject: Re: Font naming rears its ugly head again In-Reply-To: Your message of Tue, 31 Aug 93 08:29:48 -0700 Message-Id: Pierre MacKay writes: > Can I interest you in a toolkit that uses awk to create > both C -1 lines for new composites and also CC > lines for the actual recipe? Yes, you can. I started to write an afm-to-afm C program which would add C -2 (to distinguish them from C -1 which are actually present in the font) and CC for accented letters not present in the font and KRN for accented letters which didn't have KRN values specified. I never finished the automatic KRN generation, but the program did generate reasonable CC. You can have a look at it if you're interested. Can I have a look at yours, please? Jan Michael Rynning Email: jmr@nada.kth.se Department of Numerical Analysis and Computing Science Voice: +46-8-7906288 Royal Institute of Technology Fax: +46-8-7900930 S-100 44 Stockholm Sweden Normal host: jmr.nada.kth.se From mackay@cs.washington.edu Tue Aug 31 20:42:06 1993 Flags: 000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA03374; Tue, 31 Aug 93 20:42:06 MDT Received: by june.cs.washington.edu (5.65b/7.1ju) id AA00847; Tue, 31 Aug 93 19:42:03 -0700 Date: Tue, 31 Aug 93 19:42:03 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9309010242.AA00847@june.cs.washington.edu> To: jmr@nada.kth.se Cc: tex-fonts@math.utah.edu In-Reply-To: Jan Michael Rynning's message of Tue, 31 Aug 93 21:45:37 +0200 Subject: Re: Font naming rears its ugly head again In your raw encoding you have left out all the accented letters. There are two important reasons why I think they should be encoded in the raw font: This may well be a necessary alternative coding, but it has to be an alternative coding. The reason is that once you stick Aacute into the raw (-p flag) encoding, it pre-empts the creation of a VPL composite recipe. Adobe Garamond and Caslon may create the accented glyphs as simple (non-composite) characters, but the vast majority of fonts from the vast majority of vendors use composites. Special cases require special files. That said, I fully appreciate the point about variations in accent shape. The defects of the normal approach are: 1. Accents over Uppercase ought to have less slope than accents over lowercase. (I do this in my adaptation of CM for Turkish.) 2. Many accented character sets provide for squatty uppercase so that accented glyphs will not ride way above the type shoulder. It is a common complaint (is it not?) of Swedish TeX users that Aring is impossibly oversized for the taste of Swedish readers. I use a parameter in METAFONT to crush down uppercase so that the accent comes near to or within the limits of the type shoulder. These effects are relatively easy to achieve with METAFONT but can also be achieved in type1 fonts, at the price of a lot of VPL editing. We must be grateful for the existence of carefully designed fonts such as JMR alerts us to, but I suspect we must also allow that the vast majority of available fonts will not be created with such care. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@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 From alanje@cogs.susx.ac.uk Wed Sep 1 03:41:10 1993 Flags: 000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07820; Wed, 1 Sep 93 03:41:10 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #37) id m0oXogP-000EuvC; Wed, 1 Sep 93 10:40 BST Message-Id: Date: Wed, 1 Sep 93 10:40 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: tex-fonts@math.utah.edu In-Reply-To: <01H2E4E459JY91VT1J@HMCVAX.Ac.HMC.Edu> (message from Don Hosek on 31 Aug 1993 10:32:02 -0800 (PST)) Subject: Re: Font naming rears its ugly head again >I did this in my CMPICA fonts. Only one spare glyph is needed >really. You can actually do this without using a separate glyph for the number range if you've got a compound word mark. In pseudo-PL code: (LIGLABEL ) (/LIG ) (LIGSTOP) This will ligature: -> -> -> >However, I think that their is a real need to distinguish a >monospace font for text usage vs. a monospace font for listing >usage. The following characteristics (roughly speaking) should be >only in the former: In an ideal world, these might be separate fonts. But since the TeX hackery to switch off ligaturing in verbatim mode is so simple, its probably easier just to use the correspondence fonts for listings, as long as they've got distinct glyphs for ', and `. >Incidentally, an interesting note. I believe only TeX is capable >of ligatures along the lines of AB == DB Yes, although at the moment you have to use a non-standard encoding for it, since the Cork encoding doesn't allow for font-specific ligatures. But that's another issue! Alan. From alanje@cogs.susx.ac.uk Wed Sep 1 03:49:25 1993 Flags: 000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07882; Wed, 1 Sep 93 03:49:25 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #37) id m0oXooX-000EuvC; Wed, 1 Sep 93 10:49 BST Message-Id: Date: Wed, 1 Sep 93 10:49 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: tex-fonts@math.utah.edu In-Reply-To: <199308311954.AA17439@terminus.cs.umb.edu> (message from Karl Berry on Tue, 31 Aug 1993 15:54:41 -0400) Subject: Re: Font naming rears its ugly head again > Have to combine. Yes, this is why I was proposing to use a base-32 number as the last 3 letters of the filename, to make it easier to combine parameters together into one letter. Yuk yuk yuk... >These are all combined in to the variant. I think the only thing in the >above that's not covered now is all-caps. Oh, and ``text symbol'', >since there is no such thing in existing fonts (is there?). The Cork encoding really needs a text symbol companion font, to hold things like currency symbols, oblique fractions, and all the other bits and pieces missing from the Cork encoding. I'll repost a message I sent to the math-font-discuss group about this a while ago. My apologies to those of you who'll be getting this twice! Alan. From alanje@cogs.susx.ac.uk Wed Sep 1 03:54:48 1993 Flags: 000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07913; Wed, 1 Sep 93 03:54:48 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #37) id m0oXoti-000EuvC; Wed, 1 Sep 93 10:54 BST Message-Id: Date: Wed, 1 Sep 93 10:54 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: tex-fonts@math.utah.edu Subject: text symbol This is a repost of a message I sent out to the math-font-discuss group. Alan --- cut here for chat about text symbol encodings --- Okay folks, what do you want out of a text symbol encoding? Reasons for introducing TS: * There are currently some text glyphs (such as or ) sitting in the math fonts. Some of these (for example ) are sufficiently rare in mathematics as to warrant removing from the math fonts and placing in a text symbol encoding. They will still be accessable in math mode, either by loading a TS-encoded font as a math family, or by clever tricks with \mathchoice. * There are a number of symbols in the Adobe standard and Expert encoding (such as or ) that aren't in the Cork encoding. These can be placed in the TS encoding. * There are three glyphs in the Cork encoding (, and
) that do not have to be present for kerning or ligaturing reasons, and which might be better off in the TS encoding. (This point is currently being discussed on the DC fonts list, so *please* take any discussions about the Cork encoding there :-) The plan is to introduce a new text symbol encoding, which will (hopefully) be available for every font that is available for use with TeX. With appropriate macros, these glyphs will then change shape with the main text font, for example `\section{On the \yen--\pounds\ exchange rate}' will produce a and in a style matching the surrounding text. The glyphs we've looked at already are: * The text symbols from the Adobe Standard and Expert encodings, including inferior glyphs, superior glyphs, oblique fractions, copyright, trademark, punctuation and currency glyphs. * Oldstyle and lining digits. * The open triangle, open square, open circle, open diamond, filled triangle, filled square, filled circle, filled diamond, star and asterisk bullets. * The tie accent, musical notation, daggers, and playing cards from CM. * The check mark, yen and Maltese cross from MS. * A cross mark and box to go with the check mark. * The Catalan lower and upper case centered dot. * The La and TeX glyphs for building the TeX and LaTeX logos (this is my entry for the `A in LaTeX' TTN competition). * a/c and c/o (are there similar non-English glyphs?) * The planets. * The `prescription' glyph (R with a oblique dash through the tail). * and Not all of these will be included in the final encoding! The glyphs we're not interested in are: * alphabetics, which should be in the main text encoding. * mathematical symbols, which should be in a math font. * dingbats, which should be in a dingbat font, unless they're *very* common (such as the bullets). * non-Latin glyphs, which should have their own encoding. I'll send out some more detailed documents later. At the moment, we need input on: * Glyphs. * Glyphs. * More glyphs. I'd especially like input from people in the publishing industry and from non-English speaking countries. * Any other features a text symbol font could possibly have. All input is welcome! Alan. From beebe Wed Sep 1 08:50:02 1993 Flags: 000000000000 Return-Path: Received: from sandy.math.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA13990; Wed, 1 Sep 93 08:50:02 MDT Date: Wed, 1 Sep 93 08:50:02 MDT From: "Nelson H. F. Beebe" To: tex-fonts@math.utah.edu Cc: beebe X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112" X-Telephone: +1 801 581 5254 X-Fax: +1 801 581 4148 Subject: tex-fonts list archives and administration issues Message-Id: The tex-fonts mailing list is maintained by Nelson H. F. Beebe at math.utah.edu; requests for list addition or deletion should be mailed to tex-fonts-request@math.utah.edu so as to reach administration staff, rather than the whole list. The tex-fonts list is unmoderated, so postings are forwarded immediately to the entire membership (28 addresses as of 1-Sep-1993). Archives of the tex-fonts list postings are maintained on ftp.math.utah.edu in the anonymous ftp directory pub/tex/mail in these files: -rw-rw-r-- 1 daemon 80952 Sep 1 03:55 tex-fonts.txt -rw-rw-r-- 1 beebe 389318 Jul 11 1991 tex-fonts_910701.txt -rw-rw-r-- 1 beebe 82635 Nov 18 1991 tex-fonts_910816.txt -rw-rw-r-- 1 beebe 52704 Nov 18 1991 tex-fonts_911101.txt -rw-rw-r-- 1 beebe 91265 Feb 27 1992 tex-fonts_920131.txt -rw-rw-r-- 1 beebe 36620 Jun 19 1992 tex-fonts_920601.txt All mail sent to tex-fonts@math.utah.edu is automatically copied to the tex-fonts.txt file in pub/tex/mail as it is transferred, so you should always be able to find up-to-date archives there. The mailing list and archive directory are on the same machine, so correspondence should never be lost; if the machine is down, mail and ftp are too. The mail file is stored in UNIX mbox format, which means that messages are simply appended to the file with headers intact, and no intervening separator lines to allow identification of the start of a message (like those provided by TOPS-20 mm and UNIX mm /txt format). Consequently, message bodies are munged to change initial "From " to ">From " (yucch!! there are 20 such changes in the above files, with unpleasant results if the contents get typeset without zapping the > chars). Periodically, the contents of mail .txt files are moved to a file originalbasename_yymmdd.txt, where yymmdd marks the date of the LAST posting to the file. An alphabetical sort of file names is then also a chronological sort. If you lack Internet anonymous ftp access, you can retrieve the archives by e-mail; send a message to tuglib@math.utah.edu with the text help send index from tex/mail to get started, or send tex-fonts.txt from tex/mail to get a particular file. ======================================================================== Nelson H. F. Beebe Tel: +1 801 581 5254 Center for Scientific Computing FAX: +1 801 581 4148 Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu University of Utah Salt Lake City, UT 84112, USA ======================================================================== From mackay@cs.washington.edu Wed Sep 1 12:40:54 1993 Flags: 000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18428; Wed, 1 Sep 93 12:40:54 MDT Received: by june.cs.washington.edu (5.65b/7.1ju) id AA02793; Wed, 1 Sep 93 11:40:46 -0700 Date: Wed, 1 Sep 93 11:40:46 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9309011840.AA02793@june.cs.washington.edu> To: jmr@nada.kth.se Cc: tex-fonts@math.utah.edu In-Reply-To: Jan Michael Rynning's message of Tue, 31 Aug 93 22:02:01 +0200 Subject: Re: Font naming rears its ugly head again I will be sending you the awk scripts shortly. I'd like to compress and encode them if possible, Do you have uudecode available? From mackay@cs.washington.edu Wed Sep 1 12:50:03 1993 Flags: 000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA18552; Wed, 1 Sep 93 12:50:03 MDT Received: by june.cs.washington.edu (5.65b/7.1ju) id AA03861; Wed, 1 Sep 93 11:50:03 -0700 Date: Wed, 1 Sep 93 11:50:03 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9309011850.AA03861@june.cs.washington.edu> To: alanje@cogs.susx.ac.uk Cc: tex-fonts@math.utah.edu In-Reply-To: Alan Jeffrey's message of Wed, 1 Sep 93 10:54 BST Subject: Re: text symbol Right off, I would add dagger, double dagger and degree (even though degree can be done with an oversized ring accent) Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@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 From witr@rwwa.COM Wed Sep 1 17:01:03 1993 Flags: 000000000000 Return-Path: Received: from relay1.UU.NET by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA23666; Wed, 1 Sep 93 17:01:03 MDT Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA01391; Wed, 1 Sep 93 19:01:01 -0400 Date: Wed, 1 Sep 93 19:01:01 -0400 From: witr@rwwa.COM Message-Id: <9309012301.AA01391@relay1.UU.NET> Received: from spooky.UUCP by uucp2.uu.net with UUCP/RMAIL (queueing-rmail) id 185905.23606; Wed, 1 Sep 1993 18:59:05 EDT To: tex-fonts@math.utah.edu Subject: Again, should use XLFD Content-Type: text Content-Length: 676 I've said it before, and nobody agreed with me. I'll say it again, and nobody will agree with me. Fonts should be named using XLFD, and translated into actual font file names just like X does it, using font directories. All of these ad-hoc font naming schemes are inferior to this approach. This is proven by the fact that new schemes are being decided/developed perenially, whereas X has had the same fine method for almost 5 years now. I'll never understand why TeX types insist upon re-re-re-inventing wheels. --- Robert Withrow, Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM R.W. Withrow Associates, 21 Railroad Ave, Swampscott MA 01907-1821 USA From mackay@cs.washington.edu Wed Sep 1 17:28:28 1993 Flags: 000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA24282; Wed, 1 Sep 93 17:28:28 MDT Received: by june.cs.washington.edu (5.65b/7.1ju) id AA27981; Wed, 1 Sep 93 16:28:27 -0700 Date: Wed, 1 Sep 93 16:28:27 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9309012328.AA27981@june.cs.washington.edu> To: witr@rwwa.COM Cc: tex-fonts@math.utah.edu In-Reply-To: witr@rwwa.COM's message of Wed, 1 Sep 93 19:01:01 -0400 <9309012301.AA01391@relay1.UU.NET> Subject: Re: Again, should use XLFD This is exactly what Karl Berry is trying to do with texfonts.map. In the interim, there are a lot of PC users out there who need the stopgap. Personally, when I want BaskervilleMT-SemiBoldItalic-nepcoded8 I like to ask for it, but that is on a Unix system. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@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 From alanje@central.sussex.ac.uk Thu Sep 2 12:04:00 1993 Flags: 000000000000 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10874; Thu, 2 Sep 93 12:04:00 MDT Via: uk.ac.sussex.central; Thu, 2 Sep 1993 13:44:28 +0100 From: Alan Jeffrey Date: Thu, 2 Sep 93 13:44:08 +0100 Message-Id: <18438.9309021244@solx1.central.sussex.ac.uk> To: tex-fonts@math.utah.edu Subject: Re: Again, should use XLFD >Fonts should be named using XLFD, and translated into actual font file >names just like X does it, using font directories. We agree with you! But until every TeX implementation supports XLFD, we need a temporary hack. And I'm not holding my breath for all the TeX implementations to support XLFD... Alan. From alanje@central.sussex.ac.uk Thu Sep 2 13:22:22 1993 Flags: 000000000000 Return-Path: Received: from sun2.nsfnet-relay.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB11683; Thu, 2 Sep 93 13:22:22 MDT Via: uk.ac.sussex.central; Thu, 2 Sep 1993 19:18:07 +0100 From: Alan Jeffrey Date: Thu, 2 Sep 93 19:17:47 +0100 Message-Id: <19677.9309021817@solx1.central.sussex.ac.uk> To: tex-fonts@math.utah.edu In-Reply-To: Alan Jeffrey's message of Thu, 2 Sep 93 13:44:08 +0100 <18438.9309021244@solx1.central.sussex.ac.uk> Oh dear, my modem doesn't like this temporary machine very much! What I tried to say was... >Fonts should be named using XLFD, and translated into actual font file >names just like X does it, using font directories. We agree with you! But until every TeX implementation supports XLFD, we need a temporary hack. And I'm not holding my breath for all the TeX implementations to support XLFD... Alan. ------------ Alan Jeffrey TEMPORARY ADDRESS: alanje@central.susx.ac.uk MAIL WILL STILL REACH ME FROM: alanje@cogs.susx.ac.uk Normal service will be resumed as soon as possible... From jmr@nada.kth.se Thu Sep 2 14:29:26 1993 Flags: 000000000000 Return-Path: Received: from cyklop.nada.kth.se by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12482; Thu, 2 Sep 93 14:29:26 MDT Received: by cyklop.nada.kth.se (5.61-bind 1.4+ida/nada-mx-1.0) id AA28653; Thu, 2 Sep 93 22:29:14 +0200 Date: Thu, 2 Sep 93 22:29:12 +0200 From: Jan Michael Rynning To: mackay@cs.washington.edu (Pierre MacKay) Cc: tex-fonts@math.utah.edu Subject: Re: Font naming rears its ugly head again In-Reply-To: Your message of Tue, 31 Aug 93 19:42:03 -0700 Message-Id: Pierre MacKay writes: > In your raw encoding you have left out all the accented letters. > There are two important reasons why I think they should be encoded > in the raw font: > > This may well be a necessary alternative coding, but it has to > be an alternative coding. The reason is that once you stick > Aacute into the raw (-p flag) encoding, it pre-empts the > creation of a VPL composite recipe. > > Adobe Garamond and Caslon may create the accented glyphs > as simple (non-composite) characters, but the vast majority > of fonts from the vast majority of vendors use composites. > > Special cases require special files. > > ... > > We must be grateful for the existence of carefully designed > fonts such as JMR alerts us to, but I suspect we must also > allow that the vast majority of available fonts will not > be created with such care. I don't quite get your point, Pierre. The way I do it works for _all_ PostScript fonts which have the ``standard'' set of 228 glyphs. It makes no difference if the accented letter has a ``seac'' instruction in its type1 font program (that's what Adobe refers to as a composite character, and that's what the CC in the AFM files stands for), if it uses ``callsubr'' instructions to put the base letter and the accent together or if it's all done inline in the type1 font program. It's true that afm2tfm will use the accented letter from the font, if you put it into the PostScript encoding vector, rather than generating a VPL composite recipe. The accented letters from the fonts usually look better (even if they aren't specially designed, especially at low resolution) than what you can produce with a VPL composite recipe. So, I can see no reason not to use the accented letters from the font. But if you for some special reason don't want to do that you can edit the VPL font by hand (you'll have to do that anyway if you e.g. want to position the accents differently) or you can use another PostScript encoding for that font. Jan Michael Rynning Email: jmr@nada.kth.se Department of Numerical Analysis and Computing Science Voice: +46-8-7906288 Royal Institute of Technology Fax: +46-8-7900930 S-100 44 Stockholm Sweden Normal host: jmr.nada.kth.se From mackay@cs.washington.edu Fri Sep 3 17:29:45 1993 Flags: 000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07527; Fri, 3 Sep 93 17:29:45 MDT Received: by june.cs.washington.edu (5.65b/7.1ju) id AA00736; Fri, 3 Sep 93 16:29:41 -0700 Date: Fri, 3 Sep 93 16:29:41 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9309032329.AA00736@june.cs.washington.edu> To: jmr@nada.kth.se Cc: tex-fonts@math.utah.edu In-Reply-To: Jan Michael Rynning's message of Thu, 2 Sep 93 22:29:12 +0200 Subject: Re: Font naming rears its ugly head again In virtually all the text fonts that are available, with the very specific exceptions you have mentioned, it is clear from a quick inspection of the PFA file that the composites mentioned in the AFM as sent out by the foundry are composites in the PFA file as well. Unless the foundry is trying to be deliberately misleading, when it specifies in its own AFM file CC aacute 2 ; PCC a 0 0 ; PCC acute 42 -8 ; it is essentially putting in a human-readable form the very same information that is coded into unreadable binaries in the PFA file. There are only 16--18 bytes of binary in any of the composite recipes I have seen; four of them are invariant for the entire class of composites, and four more for any group of accented letters. It doesn't leave much remaining for the effort of repositioning accents and recording the width. So I am lead to the conviction that what is specified in the PFA file is essentially the same as what is specified in the VF file. If it isn't, the conclusion must be that the information in the AFM file is in some sense a lie. I hope I doubt that. I don't understand entirely your strictures about dvips. dvips does what it is told to by the VF file, and the VF file contains a translation of what was in the AFM. It may be that at some point there have to be grid-fitting adjustments, but since those are presumably taken care of by the hints in the simplex characters I really doubt that there is any change between the way dvips lays down a composite and the way the postscript interpreter lays down the same character from the PFA file. I haven't had time to make the experiment, but I might try setting some composites at 96 points with the VF file and the same characters directly from the PFA. 300dpi is coarse enough that one-pixel offsets might just be visible, but I shall be astonished if there is anything worse. Allow me to stipulate for the argument that the composites generated by the VF mechanism are the same as the composites generated by the recipes in the PFA. If that is the case I can save a considerable amount of space in display bitmaps for xdvi or dvipage by leaving out the six redundant bitmaps for the letter a. Given the size of available font resources even in the public domain fonts, the saving is significant. For the PC users I am trying to prepare files for, it mattters even more. That is a constraint that is not likely to go away in the near future. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@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 From karl@cs.umb.edu Mon Sep 6 16:59:12 1993 Flags: 000000000000 Return-Path: Received: from ra.cs.umb.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA21950; Mon, 6 Sep 93 16:59:12 MDT Received: by ra.cs.umb.edu id AA00406 (5.65c/IDA-1.4.4 for tex-fonts@math.utah.edu); Mon, 6 Sep 1993 18:59:05 -0400 Date: Mon, 6 Sep 1993 18:59:05 -0400 From: Karl Berry Message-Id: <199309062259.AA00406@ra.cs.umb.edu> To: karl@cs.umb.edu, tex-fonts@math.utah.edu Subject: TeX & XLFD Fonts should be named using XLFD, and translated into actual font file names just like X does it, using font directories. The capability has been there to do this (under Unix, anyway), ever since I released 5.851d. Maybe it was in 5.851c. If you want to set up the mapping files and start writing TeX documents using them, go ahead. No one will start until someone starts :-) Many of the things in XLFD are irrelevant to TeX fonts, but whatever. This is proven by the fact that new schemes are being decided/developed perenially, I don't think this is true. (At the filename level; at the TeX macro level, the LaTeX folks have invented some new ways to refer to fonts, I think.) I'll never understand why TeX types insist upon re-re-re-inventing wheels. I don't think this is true, either. Anyway, sometimes what's out there is wrong or not enough. From mackay@cs.washington.edu Thu Sep 9 17:42:41 1993 Flags: 000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20978; Thu, 9 Sep 93 17:42:41 MDT Received: by june.cs.washington.edu (5.65b/7.1ju) id AA07529; Thu, 9 Sep 93 16:42:42 -0700 Date: Thu, 9 Sep 93 16:42:42 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9309092342.AA07529@june.cs.washington.edu> To: karl@cs.umb.edu Cc: karl@cs.umb.edu, tex-fonts@math.utah.edu In-Reply-To: Karl Berry's message of Mon, 6 Sep 1993 18:59:05 -0400 <199309062259.AA00406@ra.cs.umb.edu> Subject: Re: TeX & XLFD It is somewhat bizarre for TeX, which established its font namings back in the very early 80s to be accused of reinventing things by a relative newcomer like X. In any case, as karl points out, texfonts.map can alias font names of any reasonable sort. The problem does not lie there, it continues to lie in the wretched limitations of the 8+3 filename. You can't even use the basic -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* XLFD string (have I lost count?) in an 8+3 environment. If you have a good aliasing mechanism, and a reasonable filename space, it really doesn't matter very much. Show an XLFD string to a traditional typesetting firm (which may just have some knowledge about fonts) and see where it gets you. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@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 From alanje@cogs.susx.ac.uk Thu Sep 23 13:56:52 1993 Flags: 000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16361; Thu, 23 Sep 93 13:56:52 MDT Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.28.1 #43) id m0ofwl3-000KJUC; Thu, 23 Sep 93 20:55 BST Message-Id: Date: Thu, 23 Sep 93 20:55 BST From: alanje@cogs.susx.ac.uk (Alan Jeffrey) To: tex-fonts@math.utah.edu Subject: fontinst v1.13 alpha release Dear all, I've now finished the alpha-release of version 1 of the fontinst package, and it's ready for testing! The fontinst package can build Virtual Fonts from Adobe Font Metric files, and: \item Is written in \TeX, for maximum portabilty (at the cost of speed). \item Supports the full T1 (Cork) encoding. \item Allows fonts to be generated in an arbitrary encoding, with arbitrary `fake' characters---for example the `ij' character can be faked if necessary by putting an `i' next to a `j'. \item Allows caps and small caps fonts with letter spacing and kerning. \item Allows kerning to be shared between characters, for example `ij' can be kerned on the left as if it were an `i' and on the right as if it were a `j'. This is useful, since many PostScript fonts only include kerning information for characters without diacriticals. \item Allows the generation of math fonts with \verb|nextlarger|, \verb|varchar|, and arbitrary font dimensions. \item Allows more than one PostScript font to contribute to a \TeX\ font, for example the `ffi' ligatures for a font can be taken from the Expert encoding, if you have it. \item Automatically generates a \verb|fd| file for use with version~2 of the New Font Selection Scheme. \item Can be customized by the user to deal with arbitrary font encodings. The main difference between this release and version 0.19 is the font installer's interface, which is a huge improvement, IMHO. It shouldn't be long before fontinst becomes a useful tool rather than a TeX-hackers toy! If you'd like to be an alpha-tester, please send me some email, and I'll send you release 1.13. I'm afraid our ftp server is still suffering from being `upgraded' to Solaris 2.2, so I can't make it available for anonymous ftp. Cheers, 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 From mackay@cs.washington.edu Fri Sep 24 14:55:13 1993 Flags: 000000000000 Received: from june.cs.washington.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19548; Fri, 24 Sep 93 14:55:13 MDT Received: by june.cs.washington.edu (5.65b/7.1ju) id AA15450; Fri, 24 Sep 93 13:55:17 -0700 Date: Fri, 24 Sep 93 13:55:17 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Return-Path: Message-Id: <9309242055.AA15450@june.cs.washington.edu> To: alanje@cogs.susx.ac.uk Cc: tex-fonts@math.utah.edu In-Reply-To: Alan Jeffrey's message of Thu, 23 Sep 93 20:55 BST Subject: Re: fontinst v1.13 alpha release Please send a copy. I have just finished an awk script which expands the KernPairs to account for aacute wherever a occurs. It also checks to see whether the first letter in a kern is uppercase EFKTUVWXY of f, and relaxes the kernin by .5 unit for the uppercase instances and inserts a +.05 unit kern in the instance of f. Crude but serviceable. I really like the feature you mention of drawing on more than one Postscript font for a single run. I had to stick with hand editing for that. Email concerned with UnixTeX distribution software should be sent primarily to: elisabet@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 From DHOSEK@HMCVAX.Ac.HMC.Edu Fri Sep 24 15:05:01 1993 Flags: 000000000000 Return-Path: Received: from HMCVAX.AC.HMC.EDU by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20049; Fri, 24 Sep 93 15:05:01 MDT Received: from HMCVAX.Ac.HMC.Edu by HMCVAX.Ac.HMC.Edu (PMDF #4220 ) id <01H3BUWM5DIO8ZDZ2J@HMCVAX.Ac.HMC.Edu>; Fri, 24 Sep 1993 14:04:57 PST Date: 24 Sep 1993 14:04:57 -0800 (PST) From: Don Hosek Subject: Font mapping and virtual fonts in general To: tex-fonts@math.utah.edu Message-Id: <01H3BUWM5DIQ8ZDZ2J@HMCVAX.Ac.HMC.Edu> X-Vms-To: IN%"tex-fonts@math.utah.edu" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT A few miscellaneous thoughts, largely brought on from reading Richard Bringhurst and working with "art" typography a bit more. VFs can be thought of, among other things, as keyboard map files. As such, they can be considered document-dependent in some cases. The VF search path for a device driver should begin with the current directory. One of the more useful VF manipulation tools would be an on-screen VF editor which would allow manually assigning characters or character combinations to different slots, using direct manipulation to position accents, affect kerning pairs etc. -dh From "DCFONT-L Discussion list for DC-fonts working group " Wed Jul 28 17:43:37 2027 Flags: 000000000001 Return-Path: <@VM.GMD.DE:DCFONT-L@DHDURZ1.BITNET> Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA11175; Tue, 3 Aug 93 11:58:24 MDT Received: from VM.GMD.DE (MAILER@DEARN) by CC.UTAH.EDU with PMDF#10043; Tue, 3 Aug 1993 11:52 MST Received: from VM.GMD.DE (NJE origin LISTSERV@DEARN) by VM.GMD.DE (LMail V1.1d/1.7f) with BSMTP id 7844; Tue, 3 Aug 1993 19:35:58 +0200 Date: Tue, 3 Aug 93 18:35:00 BST From: Alan Jeffrey Subject: Math font discussion list Sender: DCFONT-L Discussion list for DC-fonts working group To: "Nelson H.F. Beebe" Reply-To: DCFONT-L Discussion list for DC-fonts working group Message-Id: <7D30309F0C00A44C@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: dcfont-l@dhdurz1.BITNET, metafont@DMI.ENS.FR, tex-fonts@math.utah.edu After the discussion about proposed new encodings for TeX math fonts at the Aston TUG meeting, I've set up a discussion list for TeX's math fonts, and the math font group's proposals. If you would like to be included on the list, please mail me at: math-font-request@cogs.susx.ac.uk See you on the net, 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