8-Jan-1997 15:33:16-GMT,1457;000000000001 Return-Path: Received: from tug.cs.umb.edu (root@tug.cs.umb.edu [158.121.106.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA00178 for ; Wed, 8 Jan 1997 08:33:15 -0700 (MST) Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by tug.cs.umb.edu (8.8.0/8.8.0) with SMTP id LAA25470 for ; Wed, 8 Jan 1997 11:37:08 -0500 Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from leucin.chemie.fu-berlin.de (160.45.24.34) with smtp id ; Wed, 8 Jan 97 16:32 MET Received: by leucin.chemie.fu-berlin.de (Smail3.1.28.1) id ; Wed, 8 Jan 97 16:32 MET Date: Wed, 8 Jan 1997 16:32:36 +0100 (MET) From: Ali Hafezi Moghadam To: tex-fonts@tug.cs.umb.edu Subject: yinit-Initialen Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Lieber Leser, mir will es nicht gelingen, die yinit Initialen die von Yannis Haralambous definiert sind, zu benutzen. Das Paket "oldgerm" ist installiert, weiterhin lassen sich mit \gothfamily, \frakfamily und \swabfamily die entsperchenden Schriften erzeugen. Bitte, teilen Sie mir mit, wie man die Initialen erzeugen kann, oder weitere Packete dazu installiert werden m"ussen. Vielen Dank und alles Gute f"ur das neue Jahr. 8-Jan-1997 17:32:37-GMT,2484;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA03142 for ; Wed, 8 Jan 1997 10:32:31 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id SAA25686 for ; Wed, 8 Jan 1997 18:32:19 +0100 (MET) Received: (from texadmin@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id SAA04165 for tex-fonts@math.utah.edu; Wed, 8 Jan 1997 18:41:55 +0100 (MET) From: Thierry Bouche Message-Id: <199701081741.SAA04165@mozart.ujf-grenoble.fr> Subject: Re: Bitstream Gill Sans - a question To: tex-fonts@math.utah.edu Date: Wed, 8 Jan 1997 18:41:54 +0100 (MET) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > I just downloaded the metrics files for Bitstream's "Humanist 521" (=Gill > > Sans), and I noticed that only some of the fonts in the family were > > used. In particular, instead of using the Bitstream's italic versions the > > metrics apply the "SlantFont" transform to the roman versions. Can anyone > > tell me why? > > > > The fonts on CTAN, and their real names, are: > > > > bgsl8a.afm Humanist 521 Light > > bgsr8a.afm Humanist 521 Roman > > bgsr8ac.afm Humanist 521 Roman Condensed > > bgsu8a.afm Humanist 521 Ultra Bold > > bgsx8a.afm Humanist 521 Extra Bold > > bgsx8ac.afm Humanist 521 Extra Bold Condensed > > > > yes these fonts came from Corel Gallery 2 and not the Bitstream 500. I > have now Corel draw 4 that comes with the full family. If there is an > interest (and room on CTAN) I can supply the complete interface for the > most usefull families. please tell me. > > > > Can anyone cast any light on this? I suppose I can just modify the "build" > > file and run fontinst myself, but I was wondering whether there's some > > yes > > > reason for this that I'm missing. > > > > Thanks! > > > > Fernando > > > > -- > > > > Fernando Q. Gouvea > > Chair, Dept. of Math & CS Editor, MAA Online > > Colby College http://www.maa.org > > fqgouvea@colby.edu fqgouvea@maa.org > > ========================================================== > > > > If you cannot convince them, confuse them. > > -- Harry S Truman > > > > 8-Jan-1997 20:55:19-GMT,1488;000000000000 Return-Path: Received: from smtp-gw01.ny.us.ibm.net (smtp-gw01.ny.us.ibm.net [165.87.194.252]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id NAA08349 for ; Wed, 8 Jan 1997 13:55:18 -0700 (MST) Received: (from uucp@localhost) by smtp-gw01.ny.us.ibm.net (8.6.9/8.6.9) id UAA87560 for < tex-fonts@math.utah.edu>; Wed, 8 Jan 1997 20:55:16 GMT Message-Id: <199701082055.UAA87560@smtp-gw01.ny.us.ibm.net> Received: from slip139-92-42-144.ut.nl.ibm.net(139.92.42.144) by smtp-gw01.ny.us.ibm.net via smap (V1.3mjr) id sma5dkC92; Wed Jan 8 20:55:03 1997 Date: Wed, 08 Jan 97 21:53:17 EST From: wschmi@ibm.net (Walter Schmidt) Reply-To: wschmi@ibm.net (Walter Schmidt) To: tex-fonts@math.utah.edu X-Mailer: PMMail v1.1 UNREGISTERED SHAREWARE Subject: Re: yinit-Initialen On Wed, 8 Jan 1997 16:32:36 +0100 (MET) ahafezim@chemie.fu-berlin.de wrote: >mir will es nicht gelingen, die yinit Initialen, die von Yannis >Haralambous definiert sind, zu benutzen. Die yinit-Fonts enthalten zahlreiche Fehler. Es gibt eine von Andreas Schrell verbesserte Version mit dem Namen yinitas. Sie befindet sich im CTAN in einem der Unterverzeichnisse von fonts/gothic. Die Makros aus dem oldgerm-Paket sind fuer yinitas nicht geeignet; auf Wunsch koennte ich entsprechende Makros zur Verfuegung stellen, die ich fuer mich programmiert habe. Viele Gruesse Walter =================== Walter Schmidt Schornbaumstrasse 2 91052 Erlangen Germany 10-Jan-1997 15:25:42-GMT,1455;000000000000 Return-Path: Received: from tug.cs.umb.edu (root@tug.cs.umb.edu [158.121.106.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA04913 for ; Fri, 10 Jan 1997 08:25:34 -0700 (MST) Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by tug.cs.umb.edu (8.8.0/8.8.0) with SMTP id LAA26649 for ; Fri, 10 Jan 1997 11:29:27 -0500 Received: from vit.ifi.uio.no (vit.ifi.uio.no [129.240.64.211]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id ; Fri, 10 Jan 1997 16:25:23 +0100 From: Dag Langmyhr Received: from localhost (dag@localhost) by vit.ifi.uio.no ; Fri, 10 Jan 1997 15:25:22 GMT Date: Fri, 10 Jan 1997 15:25:22 GMT Message-Id: <199701101525.20192.vit@ifi.uio.no> To: tex-fonts@tug.cs.umb.edu Subject: Mode def for new printer We have bought a Tektronix Phaser 350 colour laser printer, and I could find no entry for this in the latest modes-3.2.mf. After some experimenting, I decided that the following parameters were the best I could find. It is too fat at small sizes (5 pt) but looks OK for 8pt and more. Dag Langmyhr % Tektronix Phaser 350 is a 600-by-300 colour wax printer. mode_def phascccx = mode_param (pixels_per_inch, 600); mode_param (aspect_ratio, 300/pixels_per_inch); mode_param (blacker, 0); mode_param (fillin, 0); mode_param (o_correction, .6); mode_common_setup_; enddef; %%\bye 13-Jan-1997 20:14:52-GMT,1742;000000000000 Return-Path: Received: from smtp-gw01.ny.us.ibm.net (smtp-gw01.ny.us.ibm.net [165.87.194.252]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id NAA04554 for ; Mon, 13 Jan 1997 13:14:52 -0700 (MST) Received: (from uucp@localhost) by smtp-gw01.ny.us.ibm.net (8.6.9/8.6.9) id UAA62334 for < tex-fonts@math.utah.edu>; Mon, 13 Jan 1997 20:14:49 GMT Message-Id: <199701132014.UAA62334@smtp-gw01.ny.us.ibm.net> Received: from slip139-92-42-162.ut.nl.ibm.net(139.92.42.162) by smtp-gw01.ny.us.ibm.net via smap (V1.3mjr) id smaaWMDFW; Mon Jan 13 20:14:44 1997 Date: Mon, 13 Jan 97 21:12:01 EST From: wschmi@ibm.net (Walter Schmidt) Reply-To: wschmi@ibm.net (Walter Schmidt) To: tex-fonts@math.utah.edu X-Mailer: PMMail v1.1 UNREGISTERED SHAREWARE Subject: LaTeX support for yinitas font Hello, there had been a complaint about the old german initials font `yinit', which contains numerous bugs. The corrected version `yinitas', however, is not supported by the official LaTeX package `oldgerm.sty', so I have decided to put my private package `fraktur.sty' into the CTAN. It supports the old german fonts `Fraktur' and `Schwabacher' and the `yinitas' initials. In contrast to oldgerm.sty the fonts are completely integrated into the NFSS and the package works together with german.sty. The package comes as a dtx (source) file, together with an installation script, full documentation (in german -- sorry) and a test file. The files may be found in the directory /tex-archive/macros/latex/contrib/other/fraktur at ftp.tex.ac.uk or the CTAN mirror sites. Walter ============================= Walter Schmidt (wschmi@ibm.net) Schornbaumstrasse 2 91052 Erlangen Germany 21-Jan-1997 10:02:31-GMT,2832;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmzc.zdv.Uni-Mainz.DE [134.93.8.34]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA11366 for ; Tue, 21 Jan 1997 03:02:28 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IEH0NSZMZKD6IHY1@MZDMZA.ZDV.UNI-MAINZ.DE>; Tue, 21 Jan 1997 11:00:17 +0100 Date: Tue, 21 Jan 1997 11:00:17 +0100 Subject: Release: ec fonts version 1.0 To: ctan-ann@urz.uni-heidelberg.de, tex-fonts@math.utah.edu, info-tex@shsu.edu, metafont@ens.fr Message-id: <01IEH0NSZTKYD6IHY1@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: IN"ctan-ann@urz.uni-heidelberg.de", IN"tex-fonts@math.utah.edu",IN"info-tex@shsu.edu",IN"metafont@ens.fr" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Announcement: Stable ec fonts available now There are now the stable ec fonts Version 1.0 available from the CTAN archives in directory tex-archive/fonts/jknappen/ec The ec fonts support the complete LaTeX T1 encoding, as defined at the 1990 TUG conference hold at Cork/Ireland. They are intended to be as stable as the cm fonts are, i. e. there shall be no more changes to the tfm files. The ec fonts also contain a Text Companion Symbol font, called tc, featuring many usefull characters needed in typesetting, for example oldstyle digits, currency symbols (including the newly created Euro symbol), the permille sign, copyright, trade mark and servicemark as well as a copyleft sign, and many others. The upcoming release of LaTeX2e will support the ec fonts. The dc fonts, which were termed as preliminary versions, will dissappear >From the archives soon. It is suggested, that you replace them entirely by the ec fonts. Let me thank to all the people who have contributed to the success of the ec font project. They are too numerous to mention all of them, but some of them should have a place here: Donald E. Knuth and Richard Southall for designing and coding the cm fonts, which are the base of the ec fonts Babrbara Beeton, Michael Ferguson, and Jan-Michael Rynning for pushing the project into existence Norbert Schwarz for the first two releases of the dc fonts Yannis Haralambous for numerous contributions to the METAFONT code Boguslaw Jackowsky and Marek Rycko for designing and programming the polish letters Andreas Schwab for finding and fixing some very bad bugs Daniel Taupin and Denis Roegel for fine-tuning of the accented letters needed in french The remaining errors and bugs in the distribution are all mine, no one of the persons credited above and the other unnamed contributors should be blamed for them. --J"org Knappen. 21-Jan-1997 18:17:54-GMT,1740;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA23140 for ; Tue, 21 Jan 1997 11:17:54 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.4/8.8.4) with ESMTP id KAA02273; Tue, 21 Jan 1997 10:17:42 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id KAA14639; Tue, 21 Jan 1997 10:17:40 -0800 (PST) Message-Id: <199701211817.KAA14639@alonzo.cs.sfu.ca> Subject: Re: Release: ec fonts version 1.0 To: KNAPPEN@vkpmzd.kph.uni-mainz.de Date: Tue, 21 Jan 1997 10:17:39 -0800 (PST) Cc: ctan-ann@urz.uni-heidelberg.de, tex-fonts@math.utah.edu, info-tex@shsu.edu, metafont@ens.fr In-Reply-To: <01IEH0NSZTKYD6IHY1@MZDMZA.ZDV.UNI-MAINZ.DE> from "KNAPPEN@VKPMZD.kph.Uni-Mainz.DE" at Jan 21, 97 11:00:17 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit J"org Knappen writes: > There are now the stable ec fonts Version 1.0 available from the CTAN > archives in directory This is very nice to see, thank you J"org. One issue for me, however, is that I'm not likely to switch over to the ec fonts until they're freely available as PostScript Type 1 fonts rather than having to use metafont generated bitmaps. Is Basil K. Malyshev still participating in TeX font issues and prepared to run his miracle conversion software on the ec fonts as he did for the cm and ams fonts (and an earlier version of the dc fonts)? It would be certainly be excellent if this could happen. Hoping someone knows... Melissa. 29-Jan-1997 16:40:19-GMT,2693;000000000000 Return-Path: Received: from ifm.liu.se (root@ifm.liu.se [130.236.160.6]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA07913 for ; Wed, 29 Jan 1997 09:40:18 -0700 (MST) Received: from superman.ifm.liu.se (mangc@superman.ifm.liu.se [130.236.161.3]) by ifm.liu.se (8.8.5/8.8.5) with SMTP id RAA15705; Wed, 29 Jan 1997 17:40:14 +0100 (MET) Sender: mangc@ifm.liu.se Message-ID: <32EF7D6E.67D4@ifm.liu.se> Date: Wed, 29 Jan 1997 17:40:14 +0100 From: Simon Mang CAO Organization: IFM, =?iso-8859-1?Q?Link=F6ping?= University of Technology X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: tex-fonts@math.utah.edu CC: mangc@ifm.liu.se Subject: Fontinst and FranklinGothic Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! TeXperts, I tried to use fontinst by Sebastian Rahtz and et. al to install FranklinGothic type1 fonts for use with LaTeX. I have come across some problems. Can somebody help! I have a font family including these type1 fonts: FranklinGothic-Demi frankgth FranklinGothic-DemiOblique frankgth FranklinGothic-Heavy frankgth FranklinGothic-HeavyOblique frankgth FranklinGothic-Book frankgth FranklinGothic-BookOblique frankgth FranklinGothic-Condensed frankgth FranklinGothic-ExtraCond frankgth The problem is that fontinst created only TeX-files for the Demi and Book weights, but not Heavy and Condensed! I tried to look up the tools directory and add above lines into the fontnames.map file where the abbreviation "frankgth" comes from the line fg@frankgth@Franklin Gothic in the typeface.map file. After I correctly changed the AFM filenames into their standard names as pfgd8a.afm pfgdo8a.afm pfgh8a.afm pfgho8a.afm pfgk8a.afm pfgko8a.afm pfgr8ac.afm pfgr8aq.afm I placed them in the right place. Than I run the script using make-fam -out ../adobe -sans -download pfg frankgth adobe according to the line in the Makefile used for the GillSans family. What I got is the files for the weights of Demi and Book only. I can't find the solution to let fontinst accept more weight variations. However, fontinst can automatically process the GillSans family, which includes some variants like UltraBold and UltraBoldCondensed. Does any know how to modify fontinst for my propose? Thanks! -- Simon Mang Cao (~{2\C#~}) Phone : +46 13-28 17 27 | FAX : +46 13-13 75 68 | Linkoping University of Technology E-mail: mangc@ifm.liu.se | IFM http://www.ifm.liu.se/~mangc | S-581 83 Linkoping Telex: 812 6154361 SICS | SWEDEN ------------------------------------------------------------------ 30-Jan-1997 8:34:05-GMT,4075;000000000000 Return-Path: Received: from tug.cs.umb.edu (root@tug.cs.umb.edu [158.121.106.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id BAA01627 for ; Thu, 30 Jan 1997 01:34:03 -0700 (MST) Received: from nansen.nrsc.no (nansen.nrsc.no [129.177.42.35]) by tug.cs.umb.edu (8.8.0/8.8.0) with SMTP id EAA28491 for ; Thu, 30 Jan 1997 04:37:46 -0500 Received: from fram.nrsc.no by nansen.nrsc.no with SMTP id AA08331 (5.67b8/IDA-1.4.4 for ); Thu, 30 Jan 1997 09:30:11 +0100 Received: by fram.nrsc.no (5.67b8/Uninett-C-1.4) id AA28954; Thu, 30 Jan 1997 09:36:25 +0100 Message-Id: <199701300836.AA28954@fram.nrsc.no> Subject: mode_def for canon bj200 To: tex-fonts@tug.cs.umb.edu Date: Thu, 30 Jan 1997 09:36:23 +0100 (MET) From: "Alastair D. Jenkins" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Charset: LATIN1 X-Char-Esc: 29 To: tex-fonts@math.utah.edu From: Alastair Jenkins Alastair.Jenkins@nrsc.no Here is a mode for the Canon BJ200 printer (tested on a BJC210 in BJ mode), and also a corresponding config.ps for dvips . ============ file modes.mf.bj200 ==================== % % This is a mode_def which I found to work for a Canon BJC210 printer in % BJ200 mode. The "default" blacker/fillin/o_correction values % seemed to work reasonably well, so I didn't spend too much more % time fiddling about. (Tested on the modes.mf test LaTeX code, T1 % font encoding (dc fonts) % % I would be very grateful for information on ghostscript drivers for % the "Canon Extended Mode" of the BJC210 - my printer documentation % says that you can only get the latter (which includes colour printing) % from windows3.1 or later. % % Alastair D. Jenkins % 1997 Jan 29 % % mode_def bjtzz = %\[ Canon BubbleJet 200 (720x360 dpi) mode_param (pixels_per_inch, 720); mode_param( aspect_ratio , 0.5); mode_param (blacker, 0.0); mode_param (fillin, 0); mode_param (o_correction, 1.0); mode_common_setup_; enddef; CanonBJTwoZeroZero := bjtzz; mode_def bjtzzl = %\[ Canon BubbleJet 200 landscape (360x720 dpi) bjtzz_; landscape; enddef; % End of Canon BJ200 mode ============ end file modes.mf.bj200 ================ ============ file config.ps.bj200 =================== % % dvips config.ps file for Canon Bubble Jet BJ200 printer, 720x360 dpi. % % Works OK for the Canon BJC210 colour printer in BJ200 mode (black-and-white % only!) % % I would be very grateful for information on ghostscript drivers for % the "Canon Extended Mode" of the BJC210 - my printer documentation % says that you can only get the latter (which includes colour printing) % from windows3.1 or later. % % Alastair D. Jenkins % 1997 Jan 29 % % Memory available. m 1000000 % Font search path % % How to print. % o % default resolution D 720 M bjtzz % NB you need to specify different horizontal and vertical resolutions % adj1997jan29 % X 720 Y 360 % Also look for this list of resolutions. % %R ??? ??? % The printer offsets the output by this much. O 3mm,10mm @ a4 210mm 297mm @+ %%PaperSize: A4 @+ ! %%DocumentPaperSizes: A4 @ a3 297mm 420mm @+ %%PaperSize: A3 @+ ! %%DocumentPaperSizes: A3 @ letter 8.5in 11in @+ %%PaperSize: Letter @+ ! %%DocumentPaperSizes: Letter @ legal 8.5in 14in @+ %%PaperSize: Legal @+ ! %%DocumentPaperSizes: Legal @ ledger 17in 11in @+ %%PaperSize: Ledger @+ ! %%DocumentPaperSizes: Ledger @ tabloid 11in 17in @+ %%PaperSize: Tabloid @+ ! %%DocumentPaperSizes: Tabloid ============ end file config.ps.bj200 =============== === end of message ================================ -- Alastair D. Jenkins Do/renberg, Ho/go/y, Postboks 72, N-5350 Brattholmen, Norway Phone: +47-56 32 03 77 (listed under Sotra, not Bergen) At work: phone +47-55 29 72 88 fax +47-55 20 00 50 email: Alastair.Jenkins@nrsc.no URL: http://www.nrsc.no:8001/~jenkins/ 30-Jan-1997 10:38:47-GMT,1766;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA03999 for ; Thu, 30 Jan 1997 03:38:46 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA18217 for ; Thu, 30 Jan 1997 10:37:13 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Thu, 30 Jan 1997 10:38:13 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA12372; Thu, 30 Jan 1997 10:38:07 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id KAA22714; Thu, 30 Jan 1997 10:36:08 GMT Date: Thu, 30 Jan 1997 10:36:08 GMT Message-Id: <199701301036.KAA22714@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: mangc@ifm.liu.se Cc: tex-fonts@math.utah.edu Subject: Re: Fontinst and FranklinGothic In-Reply-To: <32EF7D6E.67D4@ifm.liu.se> References: <32EF7D6E.67D4@ifm.liu.se> Simon Mang writes: > I tried to use fontinst by Sebastian Rahtz and et. al to install dont blame me for fontinst :-} > What I got is the files for the weights of Demi and Book only. > I can't find the solution to let fontinst accept more weight variations. > However, fontinst can automatically process the GillSans family, > which includes some variants like UltraBold and UltraBoldCondensed. it ought to simply work; i am puzzled i am redoing those tools at present - can you send me your afm files to test? sebastian 30-Jan-1997 15:10:26-GMT,2451;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA09761 for ; Thu, 30 Jan 1997 08:10:24 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id PAA26760 for ; Thu, 30 Jan 1997 15:08:56 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Thu, 30 Jan 1997 15:09:42 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id PAA14612; Thu, 30 Jan 1997 15:09:29 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id PAA25377; Thu, 30 Jan 1997 15:07:31 GMT Date: Thu, 30 Jan 1997 15:07:31 GMT Message-Id: <199701301507.PAA25377@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: tex-fonts@math.utah.edu cc: robin.fairbairns@cl.cam.ac.uk, carlisle@ma.man.ac.uk, rcpt@urc.tue.nl Subject: psnfss and lw35nfss In-Reply-To: <32EF7D6E.67D4@ifm.liu.se> References: <32EF7D6E.67D4@ifm.liu.se> I would be grateful if some readers of this list could scan my psnfss/fontinst/psfonts setup for the new LaTeX. What I did was - changed fontinst to emit lowercase .fd files - cleaned up problems of unncessary MOVERIGHT 0 commands in the virtual fonts - redid all the checksum derivation code, and hope things are clean now - added TS1 virtual fonts (this is preliminary; it needs some decisions by Them about how to support the PS subset of TS1) - rewrote all the tools in Perl, hopefully making them useable (with the downside that you need to be using teTeX or web2c 7) - (finally!) added a new set of PK files for the 35 fonts at various sizes You can download most of this set of stuff from the directory psnfss-beta in incoming on ftp.tex.ac.uk (Robin, please note! dont delete) - the pk files will be ready soon Note that the Lucida support will be revised soon, so it has not been changed much; it'll be brought into line with the new work done by David Carlisle and Frank Mittelbach for MathTime NOTE: I am more or less committed to burning a new TeX Live CD-ROM in 4 weeks. So I have to get this finalized quite quickly Sebastian Rahtz 30-Jan-1997 18:20:49-GMT,2166;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA15494 for ; Thu, 30 Jan 1997 11:20:48 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id TAA14631; Thu, 30 Jan 1997 19:20:44 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id TAA26633; Thu, 30 Jan 1997 19:23:43 +0100 (MET) Date: Thu, 30 Jan 1997 19:23:43 +0100 (MET) Message-Id: <199701301823.TAA26633@mozart.ujf-grenoble.fr> From: Thierry Bouche To: Sebastian Rahtz cc: tex-fonts@math.utah.edu, robin.fairbairns@cl.cam.ac.uk Subject: psnfss and lw35nfss In-Reply-To: <199701301507.PAA25377@lochnagarn.elsevier.co.uk> References: <32EF7D6E.67D4@ifm.liu.se> <199701301507.PAA25377@lochnagarn.elsevier.co.uk> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « psnfss and lw35nfss », Sebastian Rahtz écrit : > - cleaned up problems of unncessary MOVERIGHT 0 commands in the virtual > fonts great news > - added TS1 virtual fonts (this is preliminary; it needs some > decisions by Them about how to support the PS subset of TS1) a few glyphs from expert sets are never encoded by any standard TeX encoding, should there be a 8x.sty? (of course unsupported!) the bits of CTAN:fonts/psfonts that are under my control, if any should be cleaned up (let's remove the softkey directories, and I'll provide sooner or later a bunch of bitstream fontsmore complete and attractive than what I did with corel gallery). > NOTE: I am more or less committed to burning a new TeX Live CD-ROM in > 4 weeks. So I have to get this finalized quite quickly > web2c 7 will be out ? > Sebastian Rahtz > cheers Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 30-Jan-1997 19:11:09-GMT,2638;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id MAA16965 for ; Thu, 30 Jan 1997 12:11:08 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id LAA11117; Thu, 30 Jan 1997 11:10:48 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id LAA11849; Thu, 30 Jan 1997 11:10:47 -0800 (PST) Message-Id: <199701301910.LAA11849@alonzo.cs.sfu.ca> Subject: Re: psnfss and lw35nfss To: s.rahtz@elsevier.co.uk (Sebastian Rahtz) Date: Thu, 30 Jan 1997 11:10:46 -0800 (PST) Cc: tex-fonts@math.utah.edu, robin.fairbairns@cl.cam.ac.uk, carlisle@ma.man.ac.uk, rcpt@urc.tue.nl In-Reply-To: <199701301507.PAA25377@lochnagarn.elsevier.co.uk> from "Sebastian Rahtz" at Jan 30, 97 03:07:31 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I downloaded the psnfss-beta package and played about with it and found the following... - famtool.pl tries to invoke something called `cs', which failed on my system -- cs does not seem to be a standard part of Unix (I checked NEXTSTEP and Solaris) or teTeX 0.4. - I don't understand why fonts like Times Roman get special treatment in this setup. For example, Narrow and Extended versions of Times Roman and Platino Roman are created, but no Narrow and Extended versions of New Century Schoolbook or Bookman. Similarly (and possibly less importantly?), we only have a mathptm package, and no mathppl, mathpnc or mathpbk. In my opinion, Times Roman is at least as over-exposed as Computer Modern, and so having to use it to get some features doesn't seem right. Also, the Narrow and Extended versions even for Times are just made for the Roman set. Having a Bold Extended version seems like it might be very nice. (And possibly doing the all the series including Itialic in Narrow and Extended would make sense). - I'd love to see something explaining the naming conventions used for fonts. I'm sure there probably is something somewhere on CTAN but I couldn't make anything appropriate out in this distribution. For example, why is Helvetica-Narrow phvr8rn and not phvrn8r? - Naming Perl scripts '.pl' can be a bit confusing since '.pl' is used by the very scripts themselves to refer to property list files. Anyway, these are just my initial thoughts... Opinions welcome... Melissa. 30-Jan-1997 19:59:57-GMT,2002;000000000000 Return-Path: Received: from hp9000.hrz.uni-oldenburg.de (hp9000.hrz.uni-oldenburg.de [134.106.40.3]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id MAA18287 for ; Thu, 30 Jan 1997 12:59:56 -0700 (MST) Received: from mathematik.uni-oldenburg.de (mathematik.uni-oldenburg.de [134.106.104.2]) by hp9000.hrz.uni-oldenburg.de (8.8.5/8.8.5/24.01.97) with ESMTP id VAA27488; Thu, 30 Jan 1997 21:01:14 +0100 (MET) Received: from FB6/MAILQUEUE by mathematik.uni-oldenburg.de (Mercury 1.21); 30 Jan 97 20:59:55 MEZ-1MESZ Received: from MAILQUEUE by FB6 (Mercury 1.21); 30 Jan 97 20:59:28 MEZ-1MESZ From: "Peter Harmand" To: tex-fonts@math.utah.edu, Sebastian Rahtz Date: Thu, 30 Jan 1997 20:59:19 MET-1 Subject: Re: psnfss and lw35nfss CC: robin.fairbairns@cl.cam.ac.uk, carlisle@ma.man.ac.uk, rcpt@urc.tue.nl Priority: normal X-mailer: Pegasus Mail v3.22 Message-ID: > I would be grateful if some readers of this list could scan my > psnfss/fontinst/psfonts setup for the new LaTeX. [...] It seems that I am the only one who uses (also only very rarely) the 8r- encoded fonts for typesetting. Is the claim is still valid, that they provide a ligful set of metrics for installations that don't support virtual fonts? In the psnfss-beta distribution (and in the official one on CTAN since January 96) the 8r-encoded fonts for the standard 35 contain no ligatures. (Strange, because it seems that they are essentially build by a \latinfamily command.) Only ptmr's tested. I get checksum complaints from xdvi when using ptmr7t/8t. I deleted all old pk's and renamed the old tfm's and vf's -- but I might have missed something in the first quick test. Nice to see some dotlessj files in the tools directory. How do I use them? The 7t/8t/8r/8c metrics don't seem to contain a dotlessj. Peter 30-Jan-1997 23:07:00-GMT,1163;000000000000 Return-Path: Received: from cs.umb.edu (root@cs.umb.edu [158.121.104.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id QAA22962 for ; Thu, 30 Jan 1997 16:06:59 -0700 (MST) Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA18511 (5.65c/IDA-1.4.4 for ); Thu, 30 Jan 1997 18:07:06 -0500 From: "K. Berry" Received: (from kb@localhost) by terminus.cs.umb.edu (8.8.0/8.8.0) id SAA22037; Thu, 30 Jan 1997 18:05:38 -0500 (EST) Date: Thu, 30 Jan 1997 18:05:38 -0500 (EST) Message-Id: <199701302305.SAA22037@terminus.cs.umb.edu> To: oneill@cs.sfu.ca, tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss - I'd love to see something explaining the naming conventions used for fonts. I'm sure there probably is something somewhere on CTAN but I couldn't make anything appropriate out in this distribution. http://www.tug.org/fontname/ or ftp://ftp.tug.org/tex/fontname.tar.gz or CTAN:info/fontname. For example, why is Helvetica-Narrow phvr8rn and not phvrn8r? No particular reason. That's just how the names evolved. 31-Jan-1997 0:53:52-GMT,2037;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id RAA25654 for ; Thu, 30 Jan 1997 17:53:51 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id QAA28402; Thu, 30 Jan 1997 16:53:48 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id QAA12290; Thu, 30 Jan 1997 16:53:46 -0800 (PST) Message-Id: <199701310053.QAA12290@alonzo.cs.sfu.ca> Subject: Re: psnfss and lw35nfss To: kb@cs.umb.edu (K. Berry) Date: Thu, 30 Jan 1997 16:53:45 -0800 (PST) Cc: tex-fonts@math.utah.edu In-Reply-To: <199701302305.SAA22037@terminus.cs.umb.edu> from "K. Berry" at Jan 30, 97 06:05:38 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I wrote: >> - I'd love to see something explaining the naming conventions used >> for fonts. I'm sure there probably is something somewhere on CTAN >> but I couldn't make anything appropriate out in this distribution. and Karl Berry replied: > http://www.tug.org/fontname/ or ftp://ftp.tug.org/tex/fontname.tar.gz > or CTAN:info/fontname. Well, looking at this it still doesn't explain to me the naming from the following line in psnfss.map: ptmrre8r Times-Roman " 1.2 ExtendFont TeXBase1Encoding ReEncodeFont " <8r.enc I can break this down into: p <- Adobe tm <- Times Roman r <- Regular roman re8r <- Regular Engraved/Copperplate/Elite TeXBase1Encoding ... whereas I would have expected ptmr8re or ptmrr8re, i.e. p <- Adobe or p <- Adobe tm <- Times Roman tm <- Times Roman r <- Regular roman r <- Regular roman 8r <- TeXBase1Encoding r8r <- Regular TeXBase1Encoding e <- Expanded e <- Expanded So, clearly there is something I'm not understanding here (or a mistake has been made)... Melissa. 31-Jan-1997 13:14:40-GMT,2463;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA11409 for ; Fri, 31 Jan 1997 06:14:35 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id OAA06609; Fri, 31 Jan 1997 14:14:25 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id OAA11260; Fri, 31 Jan 1997 14:17:30 +0100 (MET) Date: Fri, 31 Jan 1997 14:17:30 +0100 (MET) Message-Id: <199701311317.OAA11260@mozart.ujf-grenoble.fr> From: Thierry Bouche To: "Peter Harmand" Cc: tex-fonts@math.utah.edu, Subject:Re:psnfss.and.lw35nfss@mozart.ujf-grenoble.fr In-Reply-To: References: Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: psnfss and lw35nfss », Peter Harmand écrit : > > I would be grateful if some readers of this list could scan my > > psnfss/fontinst/psfonts setup for the new LaTeX. [...] > > It seems that I am the only one who uses (also only very rarely) the 8r- > encoded fonts for typesetting. Is the claim is still valid, that they > provide a ligful set of metrics for installations that don't support virtual > fonts? In the psnfss-beta distribution (and in the official one on CTAN > since January 96) the 8r-encoded fonts for the standard 35 contain no > ligatures. (Strange, because it seems that they are essentially build by a > \latinfamily command.) Only ptmr's tested. > idem for pagd8r... > Nice to see some dotlessj files in the tools directory. How do I use them? > The 7t/8t/8r/8c metrics don't seem to contain a dotlessj. > You didn't keep the mail of B. Desruisseaux ? essentially his awk script adds a dotlessj line in the afm, then you run the usual installation procedure, you have to modify the psfonts.map file to call the AddDotlessj operator & download dotlessj.pro. It's unfortunately incompatible with ps2pk, and, without modifying render.ps with gsftopk (although gsftopk is able to make the bitmap of this ATM-illegal dotlessj!) > Peter > Thierry > > > 2-Feb-1997 10:48:21-GMT,2417;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA09978 for ; Sun, 2 Feb 1997 03:48:15 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA20378 for ; Sun, 2 Feb 1997 10:46:44 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Sun, 2 Feb 1997 10:47:36 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA03235; Sun, 2 Feb 1997 10:47:15 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id KAA23655; Sun, 2 Feb 1997 10:45:14 GMT Date: Sun, 2 Feb 1997 10:45:14 GMT Message-Id: <199702021045.KAA23655@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: harmand@math.uni-oldenburg.de Cc: tex-fonts@math.utah.edu, rcpt@urc.tue.nl Subject: Re: psnfss and lw35nfss In-Reply-To: References: Peter Harmand writes: > encoded fonts for typesetting. Is the claim is still valid, that they > provide a ligful set of metrics for installations that don't support virtual > fonts? In the psnfss-beta distribution (and in the official one on CTAN > since January 96) the 8r-encoded fonts for the standard 35 contain no > ligatures. (Strange, because it seems that they are essentially build by a > \latinfamily command.) Only ptmr's tested. ok, so i am going mad. i agree they have no ligatures. disaster. i shall investigate tonight and find out what is going wrong > I get checksum complaints from xdvi when using ptmr7t/8t. I deleted all > old pk's and renamed the old tfm's and vf's -- but I might have missed > something in the first quick test. i despair of checksums. > Nice to see some dotlessj files in the tools directory. How do I use them? > The 7t/8t/8r/8c metrics don't seem to contain a dotlessj. read the comments in the .sh file. i considered implementing this as standard for all fonts, but i got cold feet thinking about checksums and the like. do people think its vital to get it done? sebastian 2-Feb-1997 10:53:27-GMT,3491;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA10052 for ; Sun, 2 Feb 1997 03:53:26 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA20422 for ; Sun, 2 Feb 1997 10:51:56 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Sun, 2 Feb 1997 10:52:48 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA03250; Sun, 2 Feb 1997 10:52:43 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id KAA23671; Sun, 2 Feb 1997 10:50:42 GMT Date: Sun, 2 Feb 1997 10:50:42 GMT Message-Id: <199702021050.KAA23671@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: oneill@cs.sfu.ca Cc: tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199701301910.LAA11849@alonzo.cs.sfu.ca> References: <199701301507.PAA25377@lochnagarn.elsevier.co.uk> <199701301910.LAA11849@alonzo.cs.sfu.ca> Melissa O'Neill writes: > - famtool.pl tries to invoke something called `cs', which failed on my > system -- cs does not seem to be a standard part of Unix (I checked > NEXTSTEP and Solaris) or teTeX 0.4. sorry, its in the checksums/ directory. compile and install it > - I don't understand why fonts like Times Roman get special treatment > in this setup. For example, Narrow and Extended versions of Times > Roman and Platino Roman are created, but no Narrow and Extended > versions of New Century Schoolbook or Bookman. Similarly (and its simply duplicating the original dvips setup, no more no less > possibly less importantly?), we only have a mathptm package, and > no mathppl, mathpnc or mathpbk. In my opinion, Times Roman is you get luctimes though :-} to be honest, i dont have the time or inclination to do things like mathppl; mathptm fulfils a rather specific need. feel free to contribute more! > Also, the Narrow and Extended versions even for Times are just > made for the Roman set. Having a Bold Extended version seems like > it might be very nice. (And possibly doing the all the series > including Itialic in Narrow and Extended would make sense). see above. left to myself i wouldnt do any of these at all. i just supply whats needed for compatibility. making bold extended for all fonts would make a lot more files :-} but if everyone thinks its a good idea i'll do it > - I'd love to see something explaining the naming conventions used > for fonts. I'm sure there probably is something somewhere on fontname > but I couldn't make anything appropriate out in this distribution. > For example, why is Helvetica-Narrow phvr8rn and not phvrn8r? as Karl says it seems to be a mistake... > - Naming Perl scripts '.pl' can be a bit confusing since '.pl' is used > by the very scripts themselves to refer to property list files. Yannis Haralambous curiously enough was complaining about this to me in another context. the two meanings for .pl are both so well established there is little one can do about it, i am afraid. i'll rename the Perl ones .perl if you like sebastian 2-Feb-1997 12:29:46-GMT,1437;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmza.zdv.Uni-Mainz.DE [134.93.178.30]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA11810 for ; Sun, 2 Feb 1997 05:29:44 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IEXX9CIRHCC7K5I7@MZDMZA.ZDV.UNI-MAINZ.DE>; Sun, 02 Feb 1997 13:30:13 +0100 Date: Sun, 02 Feb 1997 13:30:13 +0100 Subject: Re: psnfss and lw35nfss To: s.rahtz@elsevier.co.uk, tex-font@math.utah.edu Message-id: <01IEXX9CJKEQC7K5I7@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: MZDMZA::IN%"s.rahtz@elsevier.co.uk" X-VMS-Cc: IN"tex-font@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Sebastian: > do people think its vital to get it done? I think, having a dotless j is vital. It has been in the standadr TeX glyph set for 15 years, and I need it from time to time to typeset some text in esperanto. I also think (though not with the same strong affection) that glyphs which cannot be faked with resonable effort (like the letter eng, or the perthousandzero) should be completely absent from the tfm file and not point to black boxen. The rationale behind this is, that the error should occur at TeX run time and not as late as proofreading time. Yours, J"org Knappen. 2-Feb-1997 12:42:13-GMT,1972;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmza.zdv.Uni-Mainz.DE [134.93.178.30]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA12067 for ; Sun, 2 Feb 1997 05:42:12 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IEXXFFEIDSC7K5I7@MZDMZA.ZDV.UNI-MAINZ.DE>; Sun, 02 Feb 1997 13:42:39 +0100 Date: Sun, 02 Feb 1997 13:42:39 +0100 Subject: Query: Should there be additional ligatures -- and ---? To: dcfont-l@vm.urz.uni-heidelberg.de, tex-fonts@math.utah.edu Message-id: <01IEXXFFFKYQC7K5I7@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: IN"dcfont-l@vm.urz.uni-heidelberg.de",IN"tex-fonts@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT The following problem was reported to me: If you are using T1 encoded fonts (it doesn't matter which flavour) and set the \defaulthyphenchar to 127, as recommended, and you are using Bernd Raichle's extensions to the hyphenation pattern (t1hyph.tex), Then the following situation can occur: If your are setting an emdash without spaces between the words, and it falls at a line break, then there is a inserted after the emdash, which is obviously an error. It is not clear to me, how to resolve this unfortunate situation: (a) Change the hyphenation pattern to disallow a line break in this situation and similar ones. If there should be a line break, it needs to be explicitly requested by the user. (b) Add ligatures -> and an analogous one for the . Unfortunately, this means changing the metrics of all T1 encoded fonts. (c) Other solutions? (Use endashes with spaces instead of the victorian looking emdashes ;) (d) Are there unwanted side effects of proposals (a) or (b)? Yours, J"org Knappen. 3-Feb-1997 8:52:02-GMT,2272;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id BAA06286 for ; Mon, 3 Feb 1997 01:51:58 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id JAA09927 for ; Mon, 3 Feb 1997 09:51:46 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id JAA19363; Mon, 3 Feb 1997 09:55:14 +0100 (MET) Date: Mon, 3 Feb 1997 09:55:14 +0100 (MET) Message-Id: <199702030855.JAA19363@mozart.ujf-grenoble.fr> From: Thierry Bouche To: tex-font@math.utah.edu Subject: 8r fonts Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII Er... before you redo your 8r fonts, could you check 8r.mtx? I'm not pleased at all with all these automatic kernings for accented letters. It seems to me that the ones contained in latin.mtx are _exactly_ the most you can automatically do. For instance it's a bad idea to \setleftrightkerning{egrave}{e}{1000} as in many fonts the kerning between f - egrave should the _opposite_ of the one between f - e! Sometimes f\"i is OK without kerns, but unreadable if you apply the f i pair to this one... As is, these should prevent me from using 8r fonts for real typesetting. Also someone raised the problem that a few fonts miss some accents (like breve or macron) so that \zerodepth{breve} can break things (which is'nt the case with latin.mtx because of the \unfakable commands that define the missing charachters in any case). As 8r is supposed to be raw, I suppose these zerodepth should be put inside an \ifisglyph test as someone suggested. Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ PS concerning dotlessj's they're _required_ in maths fonts, probably less usefull for text fonts. What would be nice would be to know if this setup is usefull/(partially) working under which configurations... I'm not sure the lw35nfss should be only aimed at teTeX users... 3-Feb-1997 9:38:09-GMT,1973;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA07258 for ; Mon, 3 Feb 1997 02:38:08 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA02903 for ; Mon, 3 Feb 1997 09:36:36 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 3 Feb 1997 09:37:55 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA00904; Mon, 3 Feb 1997 09:37:48 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id JAA02451; Mon, 3 Feb 1997 09:35:48 GMT Date: Mon, 3 Feb 1997 09:35:48 GMT Message-Id: <199702030935.JAA02451@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: KNAPPEN@vkpmzd.kph.uni-mainz.de Cc: tex-font@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <01IEXX9CJKEQC7K5I7@MZDMZA.ZDV.UNI-MAINZ.DE> References: <01IEXX9CJKEQC7K5I7@MZDMZA.ZDV.UNI-MAINZ.DE> KNAPPEN@vkpmzd.kph.uni-mainz.de writes: > I think, having a dotless j is vital. It has been in the standadr TeX glyph > set for 15 years, and I need it from time to time to typeset some text in > esperanto. esperanto?! i rest my case.... cant you think of a better reason? > I also think (though not with the same strong affection) that glyphs which > cannot be faked with resonable effort (like the letter eng, or the > perthousandzero) should be completely absent from the tfm file and not > point to black boxen. The rationale behind this is, that the error should > occur at TeX run time and not as late as proofreading time. i could agree with this. what do others think? sebastian 3-Feb-1997 11:11:18-GMT,1718;000000000000 Return-Path: Received: from babe.globecomm.net (babe.globecomm.net [207.51.48.8]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id EAA09008 for ; Mon, 3 Feb 1997 04:11:18 -0700 (MST) Received: from [195.68.10.82] (isdn3.lille.imaginet.fr [195.68.10.82]) by babe.globecomm.net (8.8.5/8.8.0) with SMTP id GAA09755; Mon, 3 Feb 1997 06:07:58 -0500 (EST) Message-Id: <199702031107.GAA09755@babe.globecomm.net> Subject: Re: psnfss and lw35nfss Date: Lun, 3 Fv 97 12:12:09 -0000 x-mailer: Claris Emailer 1.1 From: Yannis Haralambous To: "Sebastian Rahtz" , cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" >esperanto?! i rest my case.... cant you think of a better reason? Unicode 0135 LATIN SMALL LETTER J WITH CIRCUMFLEX, 01F0 LATIN SMALL LETTER J WITH CARON but that stuff is better handled by omega anyway :-) +--------------------------------------------------------------------+ | Yannis Haralambous, Ph.D. yannis@null.net | +--------------------------------------------------------------------+ | 187, rue Nationale fax: +33 (0)3.20.40.28.64 | | 59800 Lille, France ISDN/Numeris: +33 (0)3.20.15.81.77 | +--------------------------------------------------------------------+ ...pour distinguer l'exterieur d'un aquarium, mieux vaut n'etre pas poisson ...the ball I threw while playing in the park has never reached the ground 3-Feb-1997 11:18:01-GMT,1814;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id EAA09135 for ; Mon, 3 Feb 1997 04:17:59 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id LAA07102 for ; Mon, 3 Feb 1997 11:16:24 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 3 Feb 1997 11:17:19 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id LAA08164; Mon, 3 Feb 1997 11:17:11 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id LAA10650; Mon, 3 Feb 1997 11:15:08 GMT Date: Mon, 3 Feb 1997 11:15:08 GMT Message-Id: <199702031115.LAA10650@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: yannis@null.net Cc: KNAPPEN@vkpmzd.kph.uni-mainz.de, tex-font@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702031107.GAA09755@babe.globecomm.net> References: <199702031107.GAA09755@babe.globecomm.net> Yannis Haralambous writes: > >esperanto?! i rest my case.... cant you think of a better reason? > Unicode 0135 LATIN SMALL LETTER J WITH CIRCUMFLEX, > 01F0 LATIN SMALL LETTER J WITH CARON Sorry, Yannis, i meant i wanted a real-world reason for having to have dotless j faked in all fonts. i can think of airy-fairy academic reasons for myself.... The bottom line, as Thierry pointed out to me, is that Bernard's method is not demonstrated to be portable to eg Textures, so i think we have to hold off on it for now Sebastian 3-Feb-1997 11:42:49-GMT,2135;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id EAA09634 for ; Mon, 3 Feb 1997 04:42:48 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id LAA08057 for ; Mon, 3 Feb 1997 11:41:17 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 3 Feb 1997 11:42:20 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id LAA09954; Mon, 3 Feb 1997 11:42:14 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id LAA12726; Mon, 3 Feb 1997 11:40:11 GMT Date: Mon, 3 Feb 1997 11:40:11 GMT Message-Id: <199702031140.LAA12726@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: thierry.bouche@ujf-grenoble.fr Cc: tex-fonts@math.utah.edu, robin.fairbairns@cl.cam.ac.uk Subject: Re: psnfss and lw35nfss In-Reply-To: <199701301823.TAA26633@mozart.ujf-grenoble.fr> References: <32EF7D6E.67D4@ifm.liu.se> <199701301507.PAA25377@lochnagarn.elsevier.co.uk> <199701301823.TAA26633@mozart.ujf-grenoble.fr> Thierry Bouche writes: > > a few glyphs from expert sets are never encoded by any standard TeX > encoding, should there be a 8x.sty? (of course unsupported!) you should ask Jorg to add them to the TS1 encoding, i think. then they could be accessed (the textcomp support here isnt finished yet, by the way) > > the bits of CTAN:fonts/psfonts that are under my control, if any > should be cleaned up (let's remove the softkey directories, and I'll > provide sooner or later a bunch of bitstream fontsmore complete and > attractive than what I did with corel gallery). dont do anything yet; there are problems with what i sent out > > web2c 7 will be out ? it is more or less out. if its a total disaster i will delay the CD sebastian 3-Feb-1997 11:52:55-GMT,1352;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmza.zdv.Uni-Mainz.DE [134.93.178.30]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id EAA09815 for ; Mon, 3 Feb 1997 04:52:52 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IEZAA34RKGDK7JSY@MZDMZA.ZDV.UNI-MAINZ.DE>; Mon, 03 Feb 1997 12:53:08 +0100 Date: Mon, 03 Feb 1997 12:53:08 +0100 Subject: Re: psnfss and lw35nfss To: s.rahtz@elsevier.co.uk, yannis@null.net, tex-font@math.utah.edu Message-id: <01IEZAA34Y5UDK7JSY@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: MZDMZA::IN%"s.rahtz@elsevier.co.uk" X-VMS-Cc: IN"yannis@null.net",IN"tex-font@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I don't think, that support for esperanto is a purely academic thing: There is an active book production in esperanto which needs either a ready-made \^\j or the \j itself. Furthermore, I think, that TeXtures and Y&Y don't have the right to block a possible progress. It can be done with dvips, and it should be done. I am pretty sure, that the commercial TeX vendors will incorporate support for the dotless j, as soon as their customers demand it. --J"org Knappen. 3-Feb-1997 12:02:59-GMT,2159;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA10040 for ; Mon, 3 Feb 1997 05:02:58 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA08716 for ; Mon, 3 Feb 1997 12:01:27 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 3 Feb 1997 12:02:20 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA11569; Mon, 3 Feb 1997 12:02:16 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id MAA15244; Mon, 3 Feb 1997 12:00:13 GMT Date: Mon, 3 Feb 1997 12:00:13 GMT Message-Id: <199702031200.MAA15244@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: KNAPPEN@vkpmzd.kph.uni-mainz.de Cc: yannis@null.net, tex-font@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <01IEZAA34Y5UDK7JSY@MZDMZA.ZDV.UNI-MAINZ.DE> References: <01IEZAA34Y5UDK7JSY@MZDMZA.ZDV.UNI-MAINZ.DE> KNAPPEN@vkpmzd.kph.uni-mainz.de writes: > I don't think, that support for esperanto is a purely academic thing: There > is an active book production in esperanto which needs either a ready-made > \^\j or the \j itself. i didnt mean Esperanto is academic; but it is mildly obscure. why not just use a font which has dotlessj, if you need it? > Furthermore, I think, that TeXtures and Y&Y don't have the right to block a > possible progress. It can be done with dvips, and it should be done. I am i dont entirely agree. solutions should not depend on idiosyncracies of one driver > pretty sure, that the commercial TeX vendors will incorporate support for > the dotless j, as soon as their customers demand it. the problem is not the TeX vendors, but the font vendors. if a font has dotless j, it'll be used. The Lucida fonts have it, for instance. sebastian 3-Feb-1997 12:11:05-GMT,1269;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmza.zdv.Uni-Mainz.DE [134.93.178.30]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA10253 for ; Mon, 3 Feb 1997 05:11:04 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IEZAUJHERKC51JNZ@MZDMZA.ZDV.UNI-MAINZ.DE>; Mon, 03 Feb 1997 13:11:27 +0100 Date: Mon, 03 Feb 1997 13:11:27 +0100 Subject: Re: psnfss and lw35nfss To: s.rahtz@elsevier.co.uk, tex-fonts@math.utah.edu Message-id: <01IEZAUJHN8YC51JNZ@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: MZDMZA::IN%"s.rahtz@elsevier.co.uk" X-VMS-Cc: IN"tex-fonts@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Sebastian wrote: > the problem is not the TeX vendors, but the font vendors. if a font > has dotless j, it'll be used. The Lucida fonts have it, for instance. It is, however, far easier to persuade half a dozen of TeX vendors to support a certain special in their drivers than to persuade 100+ font vendors to change 1500+ fonts. And dvips is the most often used dvi driver with a huge market share. --J"org Knappen. 3-Feb-1997 12:17:57-GMT,1757;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA10412 for ; Mon, 3 Feb 1997 05:17:56 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA09145 for ; Mon, 3 Feb 1997 12:16:25 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 3 Feb 1997 12:17:14 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA12770; Mon, 3 Feb 1997 12:17:08 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id MAA16396; Mon, 3 Feb 1997 12:15:04 GMT Date: Mon, 3 Feb 1997 12:15:04 GMT Message-Id: <199702031215.MAA16396@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: KNAPPEN@vkpmzd.kph.uni-mainz.de Cc: tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <01IEZAUJHN8YC51JNZ@MZDMZA.ZDV.UNI-MAINZ.DE> References: <01IEZAUJHN8YC51JNZ@MZDMZA.ZDV.UNI-MAINZ.DE> KNAPPEN@vkpmzd.kph.uni-mainz.de writes: > It is, however, far easier to persuade half a dozen of TeX vendors to > support a certain special in their drivers than to persuade 100+ font > vendors to change 1500+ fonts. true. but thats TeX-as-ghetto-attitude. anyway, the fact that the ps2pk/gsftopk dont yet support the thing is still an obstacle > And dvips is the most often used dvi driver with a huge market share. Textures and Y&Y users are very vocal, however! sebastian 3-Feb-1997 12:35:49-GMT,1962;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk (csrj.crn.cogs.susx.ac.uk [192.33.16.212]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id FAA10877 for ; Mon, 3 Feb 1997 05:35:45 -0700 (MST) Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0vrNUw-0000YqC; Mon, 3 Feb 97 12:27 GMT Message-Id: Date: Mon, 3 Feb 97 12:27 GMT From: Alan Jeffrey To: KNAPPEN@vkpmzd.kph.uni-mainz.de Cc: s.rahtz@elsevier.co.uk, tex-font@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <01IEXX9CJKEQC7K5I7@MZDMZA.ZDV.UNI-MAINZ.DE> References: <01IEXX9CJKEQC7K5I7@MZDMZA.ZDV.UNI-MAINZ.DE> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII > I think, having a dotless j is vital. It has been in the standadr TeX glyph > set for 15 years, and I need it from time to time to typeset some text in > esperanto. On the other hand I'm rather worried about PostScript-specific info getting into the VFs, since they're meant to work with arbitrary print engines: TrueType, QuickDraw, ActiveZzzz, etc etc. PSnfss is a bad name which we're stuck with... > I also think (though not with the same strong affection) that glyphs which > cannot be faked with resonable effort (like the letter eng, or the > perthousandzero) should be completely absent from the tfm file and not > point to black boxen. The rationale behind this is, that the error should > occur at TeX run time and not as late as proofreading time. Problem is that the default TeX behaviour is to put a warning in the log file but not on the screen, so if you use a missing glyph then you get no visible warning---the only way to find it is to check the proofs by eye. At least the black boxes produce a warning at the dvi-processing level and produce a very visible `something's gone wrong' indicator. Alan. 3-Feb-1997 12:43:25-GMT,1354;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmza.zdv.Uni-Mainz.DE [134.93.178.30]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA11098 for ; Mon, 3 Feb 1997 05:43:24 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IEZBDODMAOC7K8QP@MZDMZA.ZDV.UNI-MAINZ.DE>; Mon, 03 Feb 1997 13:43:01 +0100 Date: Mon, 03 Feb 1997 13:43:01 +0100 Subject: Re: psnfss and lw35nfss To: s.rahtz@elsevier.co.uk, tex-fonts@math.utah.edu, thierry.bouche@ujf-grenoble.fr Message-id: <01IEZBDOE5KYC7K8QP@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: MZDMZA::IN%"s.rahtz@elsevier.co.uk" X-VMS-Cc: IN"tex-fonts@math.utah.edu",IN"thierry.bouche@ujf-grenoble.fr" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > you should ask Jorg to add them to the TS1 encoding, i think. then > they could be accessed (the textcomp support here isnt finished yet, > by the way) There are some Adode characters which I purposefully left out of the TS1 encoding. It is a volunteer task (volunteer needed) to fill them into another encoding called TSA (Text symbols Adobe). Those symbols contain specially the sub or superscripted signs. --J"org Knappen. 3-Feb-1997 12:45:28-GMT,2477;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA11156 for ; Mon, 3 Feb 1997 05:45:27 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA10054 for ; Mon, 3 Feb 1997 12:43:56 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 3 Feb 1997 12:44:47 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA14524; Mon, 3 Feb 1997 12:44:42 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id MAA18547; Mon, 3 Feb 1997 12:42:39 GMT Date: Mon, 3 Feb 1997 12:42:39 GMT Message-Id: <199702031242.MAA18547@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: alanje@cogs.susx.ac.uk Cc: tex-font@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: References: <01IEXX9CJKEQC7K5I7@MZDMZA.ZDV.UNI-MAINZ.DE> > On the other hand I'm rather worried about PostScript-specific info > getting into the VFs, since they're meant to work with arbitrary print > engines: TrueType, QuickDraw, ActiveZzzz, etc etc. PSnfss is a bad > name which we're stuck with... a bad concept even. i wish it would go away but Bernard's dotlessj solution doesnt out any special stuff in the vf file, which is why its the best solution i have seen so far. it leaves it up to the driver to do the work > Problem is that the default TeX behaviour is to put a warning in the > log file but not on the screen, so if you use a missing glyph then you > get no visible warning---the only way to find it is to check the it depends on the implementation, doesnt it? it seems to me a failing in `normal' TeX systems that this isnt flagged as a fatal error > proofs by eye. At least the black boxes produce a warning at the > dvi-processing level and produce a very visible `something's gone > wrong' indicator. I lean both ways on this. Karl and Jorg want to dump the black boxes, Alan maintains his original decision was right, what do others think? On the whole i would side with the dumpers sebastian 3-Feb-1997 12:58:10-GMT,2286;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA11457 for ; Mon, 3 Feb 1997 05:58:09 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id HAA17243; Mon, 3 Feb 1997 07:56:29 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id HAA14230; Mon, 3 Feb 1997 07:56:23 -0500 (EST) Date: Mon, 3 Feb 1997 07:56:23 -0500 (EST) Message-Id: <199702031256.HAA14230@kauai.ai.mit.edu> To: s.rahtz@elsevier.co.uk, tex-font@math.utah.edu Subject: [KNAPPEN@VKPMZD.kph.Uni-Mainz.DE: Re: psnfss and lw35nfss] Reply-to: bkph@ai.mit.edu From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Date: Sun, 02 Feb 1997 13:30:13 +0100 Subject: Re: psnfss and lw35nfss To: s.rahtz@elsevier.co.uk, tex-font@math.utah.edu X-VMS-To: MZDMZA::IN%"s.rahtz@elsevier.co.uk" X-VMS-Cc: IN"tex-font@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Knappen writes: > Sebastian: > > do people think its vital to get it done? > I think, having a dotless j is vital. It has been in the standadr TeX glyph > set for 15 years, and I need it from time to time to typeset some text in > esperanto. Well the UNICODE people have decided there is no such character as `dotlessj' in any language. The closest are `dotlessjdash' and `dotlessjinverteddash'. The fact that it has been in CM fonts is about as significant as that the `currency' symbol has been in Adobe fonts. It's only use is as a base for making composites/accented characters. And these - like jcircumflex - should be in the font as glyphs in their own right (as they are in WGL4 fonts or `Latin' fonts like Lucida Bright Latin, Lucida Sans Latin and Lucida Sans Typewriter Latin). Note that in distinction, dotlessi is in UNICODE - not because it can be used as the base for various accented characters - but because it is a glyph in its own right in Turkish. Whereas no language uses dotlessj. Correct me (and the ISO 10646 and UNICODE folks) if I am wrong. Regards, Berthold. 3-Feb-1997 13:00:42-GMT,2080;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA11521 for ; Mon, 3 Feb 1997 06:00:40 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA10479 for ; Mon, 3 Feb 1997 12:59:09 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 3 Feb 1997 12:59:59 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA15611; Mon, 3 Feb 1997 12:59:50 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id MAA19689; Mon, 3 Feb 1997 12:57:48 GMT Date: Mon, 3 Feb 1997 12:57:48 GMT Message-Id: <199702031257.MAA19689@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: KNAPPEN@vkpmzd.kph.uni-mainz.de Cc: tex-fonts@math.utah.edu, thierry.bouche@ujf-grenoble.fr, robin.fairbairns@cl.cam.ac.uk Subject: Re: psnfss and lw35nfss In-Reply-To: <01IEZBDOE5KYC7K8QP@MZDMZA.ZDV.UNI-MAINZ.DE> References: <01IEZBDOE5KYC7K8QP@MZDMZA.ZDV.UNI-MAINZ.DE> KNAPPEN@vkpmzd.kph.uni-mainz.de writes: > > you should ask Jorg to add them to the TS1 encoding, i think. then > > they could be accessed (the textcomp support here isnt finished yet, > > by the way) > > There are some Adode characters which I purposefully left out of the TS1 > encoding. It is a volunteer task (volunteer needed) to fill them into > another encoding called TSA (Text symbols Adobe). > > Those symbols contain specially the sub or superscripted signs. Frank Mittelbach and Chris Rowley were arguing about this, how to best support the true TS1, the adobe subset, and the expert extras. Please, if anyone can work on it, it would be great, but make sure you talk to Jorg and the LaTeX3 people! sebastian 3-Feb-1997 13:03:29-GMT,1913;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA11605 for ; Mon, 3 Feb 1997 06:03:28 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id IAA17363; Mon, 3 Feb 1997 08:02:07 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA14236; Mon, 3 Feb 1997 08:02:06 -0500 (EST) Date: Mon, 3 Feb 1997 08:02:06 -0500 (EST) Message-Id: <199702031302.IAA14236@kauai.ai.mit.edu> To: tex-fonts@math.utah.edu, rcpt@urc.tue.nl cc: s.rahtz@elsevier.co.uk In-reply-to: <199702021045.KAA23655@lochnagarn.elsevier.co.uk> (message from Sebastian Rahtz on Sun, 2 Feb 1997 10:45:14 GMT) Subject: Re: psnfss and lw35nfss Reply-to: bkph@ai.mit.edu > Nice to see some dotlessj files in the tools directory. How do I use them? > The 7t/8t/8r/8c metrics don't seem to contain a dotlessj. read the comments in the .sh file. i considered implementing this as standard for all fonts, but i got cold feet thinking about checksums and the like. do people think its vital to get it done? No. Because PostScript trickery is only of use on UNIX or if you don't care about preview. After all what are called `PostScript' fonts on comp.text.tex are called `ATM fonts' in the rest of the world, and while ATM provides better by far rasterization than any PS interpreter - public domain or commercial - ATM does not include a PS interpreter and so cannot handle `PS trickery'. Hence on IBM PC/Windows and Macintosh such `fonts' (Type 3) are useless. Also, as pointed out in my other message, there is no such character as `dotlessj' :=) Check it out, read UNICODE 2.0. Regards, Berthold. 3-Feb-1997 13:06:30-GMT,2045;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA11671 for ; Mon, 3 Feb 1997 06:06:29 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id OAA01914; Mon, 3 Feb 1997 14:05:13 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id OAA29307; Mon, 3 Feb 1997 14:08:42 +0100 (MET) Date: Mon, 3 Feb 1997 14:08:42 +0100 (MET) Message-Id: <199702031308.OAA29307@mozart.ujf-grenoble.fr> From: Thierry Bouche To: Sebastian Rahtz Cc: KNAPPEN@vkpmzd.kph.uni-mainz.de, tex-font@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702031200.MAA15244@lochnagarn.elsevier.co.uk> References: <01IEZAA34Y5UDK7JSY@MZDMZA.ZDV.UNI-MAINZ.DE> <199702031200.MAA15244@lochnagarn.elsevier.co.uk> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: psnfss and lw35nfss », Sebastian Rahtz écrit : > > > Furthermore, I think, that TeXtures and Y&Y don't have the right to block a > > possible progress. It can be done with dvips, and it should be done. I am > i dont entirely agree. solutions should not depend on idiosyncracies > of one driver > Well, concerning lw35nfss, as these will be the reference vf/tfm's available for download on CTAN they should be as widely compatible/portable as TeX is, no? Having documented (optionnal?) support for dotless j's in the tools would be nice though. Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ PS I personnally agree with the idea that inexistant charachters should be really inexistant. The only thing this could break is font tables, isn't it? 3-Feb-1997 13:19:52-GMT,2683;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA11982 for ; Mon, 3 Feb 1997 06:19:51 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id IAA17786; Mon, 3 Feb 1997 08:18:30 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA14253; Mon, 3 Feb 1997 08:18:29 -0500 (EST) Date: Mon, 3 Feb 1997 08:18:29 -0500 (EST) Message-Id: <199702031318.IAA14253@kauai.ai.mit.edu> To: s.rahtz@elsevier.co.uk, yannis@null.net, tex-font@math.utah.edu In-reply-to: <01IEZAA34Y5UDK7JSY@MZDMZA.ZDV.UNI-MAINZ.DE> (KNAPPEN@VKPMZD.kph.Uni-Mainz.DE) Subject: Re: psnfss and lw35nfss Reply-to: bkph@ai.mit.edu I don't think, that support for esperanto is a purely academic thing: There is an active book production in esperanto which needs either a ready-made \^\j or the \j itself. Right. And that is why Cork is inadequate. You need at least the 600 glyphs of WGL4 to cover the European Latin fonts. And in Europe the claim is that a *minimal* ISO European glyph set has over 900, with an extended set having over 3000. Or are you saying that the very reason you want people to abandon CM is now to be ignored when adding jcircumflex by overprinting? What I am saying is that T1 is nice because it has ready-made accented characters, you don't need to construct them. By analogy, if you work in a language that is not covered by T1 you should use an encoding (and a font) that has the ready-made accented characters for that font. Furthermore, I think, that TeXtures and Y&Y don't have the right to block a possible progress. The problem is that (1) 30,000 fonts out there have dotlessi but not dotlessj (2) it is not something that can be `fixed' in the application. System level font support is a wonderful thing if you have it, but it also means you have to live with its little quirks. It can be done with dvips, and it should be done. I am pretty sure, that the commercial TeX vendors will incorporate support for the dotless j, as soon as their customers demand it. Since there is no way to do using ATM and since there is no way to do it using UNICODE, you can see this will not happen except in the very restricted world where everything is done using PostScript. Hmm, you can't access Lslash, lslash, Eth, eth etc on the Mac. Nobody has `fixed' that. And that problem has been around for years. --J"org Knappen. 3-Feb-1997 13:23:46-GMT,1159;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA12071 for ; Mon, 3 Feb 1997 06:23:45 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id IAA17471; Mon, 3 Feb 1997 08:06:17 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA14242; Mon, 3 Feb 1997 08:06:16 -0500 (EST) Date: Mon, 3 Feb 1997 08:06:16 -0500 (EST) Message-Id: <199702031306.IAA14242@kauai.ai.mit.edu> To: tex-font@math.utah.edu cc: thierry.bouche@ujf-grenoble.fr In-reply-to: <199702030855.JAA19363@mozart.ujf-grenoble.fr> (message from Thierry Bouche on Mon, 3 Feb 1997 09:55:14 +0100 (MET)) Subject: Re: 8r fonts Reply-to: bkph@ai.mit.edu PS concerning dotlessj's they're _required_ in maths fonts, probably less usefull for text fonts. What would be nice would be to know if Yes, and math italic fonts have their own dotlessi and dotlessj for math. 3-Feb-1997 13:29:05-GMT,1417;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmzb.zdv.Uni-Mainz.DE [134.93.8.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA12205 for ; Mon, 3 Feb 1997 06:29:04 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IEZDLNHJFKDDYOCN@MZDMZA.ZDV.UNI-MAINZ.DE>; Mon, 03 Feb 1997 14:29:28 +0100 Date: Mon, 03 Feb 1997 14:29:27 +0100 Subject: Re: psnfss and lw35nfss To: s.rahtz@elsevier.co.uk, tex-fonts@math.utah.edu Message-id: <01IEZDLNIM0IDDYOCN@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: MZDMZA::IN%"s.rahtz@elsevier.co.uk" X-VMS-Cc: IN"tex-fonts@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Unfortunately, Alan is right: It is currently impossible to make a lost char a true error which stops TeX. One can improve the situation a little by setting \tracingonline=1 to have the Warning also in the screen output, but that's all one can get. I still think, this kind of behaviour is better than having no warning at all, since it allows for searching the error message in the log-file (but who thinks of that, really?). Making lost characters an error by setting \tracinglostchars=2 seems a sensible extension to suggest to the e-TeX team. --J"org Knappen. 3-Feb-1997 13:32:31-GMT,3242;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA12314 for ; Mon, 3 Feb 1997 06:32:31 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id IAA18309; Mon, 3 Feb 1997 08:32:20 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA14260; Mon, 3 Feb 1997 08:32:19 -0500 (EST) Date: Mon, 3 Feb 1997 08:32:19 -0500 (EST) Message-Id: <199702031332.IAA14260@kauai.ai.mit.edu> To: KNAPPEN@vkpmzd.kph.uni-mainz.de, tex-font@math.utah.edu cc; s.rahtz@elsevier.co.uk In-reply-to: <199702031115.LAA10650@lochnagarn.elsevier.co.uk> (message from Sebastian Rahtz on Mon, 3 Feb 1997 11:15:08 GMT) Subject: Re: psnfss and lw35nfss Reply-to: bkph@ai.mit.edu BCC: bkph Yannis Haralambous writes: > >esperanto?! i rest my case.... cant you think of a better reason? > Unicode 0135 LATIN SMALL LETTER J WITH CIRCUMFLEX, > 01F0 LATIN SMALL LETTER J WITH CARON Sorry, Yannis, i meant i wanted a real-world reason for having to have dotless j faked in all fonts. i can think of airy-fairy academic reasons for myself.... No, no. This is not airy-fairy! What *is* wrong with it is that those character should be in the font, not the pieces they are constructed from. Have you guys forgotten why you went for T1 encoding :=)! The bottom line, as Thierry pointed out to me, is that Bernard's method is not demonstrated to be portable to eg Textures, so i think we have to hold off on it for now It is not just Textures, it is any system that uses fonts that do not have dotlessj without invoking a PS interpreter. Don't be so myopic please. Using PS for everything is what you do on UNIX and it makes everything device dependent. On Macintosh and IBM PC/Windows we try and do things in a device independent way. It should work on *any* display driver not just display PostScript, and *any* supported printer not just PS. Keep in mind that Windows e.g. currently supports over 3,500 output devices/printers --- no need to write a separate DVI-to-XXXX driver for each of these. The advantage of this device independence bring with it limitations: you can't assume PostScript! Sigh, I feel like i am beating a dead horse :=) Looking towards the future, it is also a problem with any system that uses UNICODE since there is no dotlessj in UNICODE (yes i know, UNICODE is a character encoding not a glyph encoding, but since there is no decent glyph encoding we all know what is going to be used). But actually I could care less. This is purely academic for me. (1) I don't use dotlessj, (2) the fonts I most use do have a dotlessj, (3) DVIWindo can reencode Type 1 fonts to expose the dotlessj (even though they are not in Mac or Windows standard character set) and (4) if i needed jcircumflex or jcaron I would use Lucida Bright Latin, Lucida Sans Latin, and Lucida Sans Typewriter families, which cover all Latin code pages and have those glyphs already wired in. Regards, Berthold. 3-Feb-1997 13:35:12-GMT,2211;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA12387 for ; Mon, 3 Feb 1997 06:35:11 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id OAA04736; Mon, 3 Feb 1997 14:35:04 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id OAA00313; Mon, 3 Feb 1997 14:38:36 +0100 (MET) Date: Mon, 3 Feb 1997 14:38:36 +0100 (MET) Message-Id: <199702031338.OAA00313@mozart.ujf-grenoble.fr> From: Thierry Bouche To: Sebastian Rahtz CC: tex-font@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702031215.MAA16396@lochnagarn.elsevier.co.uk> References: <01IEZAUJHN8YC51JNZ@MZDMZA.ZDV.UNI-MAINZ.DE> <199702031215.MAA16396@lochnagarn.elsevier.co.uk> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: psnfss and lw35nfss », Sebastian Rahtz écrit : > anyway, the fact that the ps2pk/gsftopk dont yet support the thing is > still an obstacle ps2pk will never be supported I'm afraid, but this is done for gsftopk, if this is the way you make your bitmaps, you could easily provide dotlessj bitmaps as well. So hopefully, this setup could be usefull with bitmaps-based previewers & dvips. Bernard sent me yesterday an improved header that defines AddDotlessj in a way suitable for both gsftopk and dvips. I think that the fact that it makes the right bitmap for MinionMM is a sufficient torture test;-) Concernant « Re: psnfss and lw35nfss », Sebastian Rahtz écrit : > but Bernard's dotlessj solution doesnt out any special stuff in the > vf file, which is why its the best solution i have seen so far. it > leaves it up to the driver to do the work > yes & the more robust too, and the more general. Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 3-Feb-1997 13:38:42-GMT,1318;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmzb.zdv.Uni-Mainz.DE [134.93.8.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA12497 for ; Mon, 3 Feb 1997 06:38:41 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IEZDYLWWF4C50UFX@MZDMZA.ZDV.UNI-MAINZ.DE>; Mon, 03 Feb 1997 14:39:09 +0100 Date: Mon, 03 Feb 1997 14:39:09 +0100 Subject: Re: [KNAPPEN@VKPMZD.kph.Uni-Mainz.DE: Re: psnfss and lw35nfss] To: bkph@ai.mit.edu, tex-fonts@math.utah.edu Message-id: <01IEZDYLX4WIC50UFX@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: MZDMZA::IN%"bkph@ai.mit.edu" X-VMS-Cc: IN"tex-fonts@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > Well the UNICODE people have decided there is no such character as > `dotlessj' > in any language. The closest are `dotlessjdash' and `dotlessjinverteddash'. I have even refences for the contrastive use of both dotted and dotless j, but those are truely far out: They occur in Lenin-aera latin alphabets for some minority languages in the Soviet union. All those alphabets were replaced by cyrillic ones under Stalin's rule. --J"org Knappen 3-Feb-1997 13:43:03-GMT,1785;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA12612 for ; Mon, 3 Feb 1997 06:43:01 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id OAA05263; Mon, 3 Feb 1997 14:42:22 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id OAA00732; Mon, 3 Feb 1997 14:45:54 +0100 (MET) Date: Mon, 3 Feb 1997 14:45:54 +0100 (MET) Message-Id: <199702031345.OAA00732@mozart.ujf-grenoble.fr> From: Thierry Bouche To: bkph@ai.mit.edu CC: tex-font@math.utah.edu Subject: [KNAPPEN@VKPMZD.kph.Uni-Mainz.DE: Re: psnfss and lw35nfss] In-Reply-To: <199702031256.HAA14230@kauai.ai.mit.edu> References: <199702031256.HAA14230@kauai.ai.mit.edu> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII correct me if I'm wrong, but the unicode people have defined the lonely accent circumflex? & it's not a linguistic glyph (never used for itself) & They can't prevent mathematicians from inventing thousands of new notations when required ? You for sure know that the \hat / \vector accents are used over any letters , resulting in composite glyphs never seen in any language? So forgetting a dotlessj in Unicode, as base for any accented variations of \j is an error. I don't know abroad, but here in France, any teenager has used the basis (\vec \i, \vec\j) of the euclidean plane once. Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 3-Feb-1997 13:50:59-GMT,1679;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA12824 for ; Mon, 3 Feb 1997 06:50:57 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id OAA05893; Mon, 3 Feb 1997 14:50:54 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id OAA01051; Mon, 3 Feb 1997 14:54:26 +0100 (MET) Date: Mon, 3 Feb 1997 14:54:26 +0100 (MET) Message-Id: <199702031354.OAA01051@mozart.ujf-grenoble.fr> From: Thierry Bouche To: bkph@ai.mit.edu Cc: tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702031302.IAA14236@kauai.ai.mit.edu> References: <199702021045.KAA23655@lochnagarn.elsevier.co.uk> <199702031302.IAA14236@kauai.ai.mit.edu> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: psnfss and lw35nfss », Berthold K.P. Horn écrit : > After all what are called `PostScript' > fonts on comp.text.tex are called `ATM fonts' in the rest of the > world, and while ATM provides better by far rasterization than any > PS interpreter - public domain or commercial - ATM does not include > a PS interpreter and so cannot handle `PS trickery'. how would you call AJenson, then ? an ATM4+ font ? and MinionMM ATM3.02 font ? It was definitely not an ATM2 font. No doubt this dotlessj will be an ATM-300\varepsilon font! 3-Feb-1997 13:51:47-GMT,2723;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA12856 for ; Mon, 3 Feb 1997 06:51:46 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id IAA18804; Mon, 3 Feb 1997 08:51:43 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA14296; Mon, 3 Feb 1997 08:51:41 -0500 (EST) Date: Mon, 3 Feb 1997 08:51:41 -0500 (EST) Message-Id: <199702031351.IAA14296@kauai.ai.mit.edu> To: thierry.bouche@ujf-grenoble.fr CC: tex-font@math.utah.edu In-reply-to: <199702031345.OAA00732@mozart.ujf-grenoble.fr> (message from Thierry Bouche on Mon, 3 Feb 1997 14:45:54 +0100 (MET)) Subject: Re: [KNAPPEN@VKPMZD.kph.Uni-Mainz.DE: Re: psnfss and lw35nfss] Reply-to: bkph@ai.mit.edu correct me if I'm wrong, but the unicode people have defined the lonely accent circumflex? & it's not a linguistic glyph (never used for itself) The UNICODE people - like any good committee - are not of one mind on this. On the one hand they explicitly state (at least in earlier versions) that the `non spacing' accents are provided for constructing composites, yet also insist on listing all composites that actually occur. There are also `spacing' accents, by the way, whatever that is. And the non-spacing ones are non-sense since they are meant to accent the character that comes before - nobody has though about the spacing / kerning issues. & They can't prevent mathematicians from inventing thousands of new notations when required ? You for sure know that the \hat / \vector accents are used over any letters , resulting in composite glyphs never seen in any language? So forgetting a dotlessj in Unicode, as base for any accented variations of \j is an error. I don't know abroad, but here in France, any teenager has used the basis (\vec \i, \vec\j) of the euclidean plane once. That is math. And yes, there should be a dotlessj in a math font. UNICODE only half-heartedly covers math. Lucida New Math and Lucida New Math Expert covers many more glyphs than are in UNICODE. In fact, I have the feeling that the UNICODE committee may have decided to orphan math support, thinking it is a msitake they put it in in the first place. Maybe barbara beeton knows more. But you know, *anyone* can propose new characters to the UNICODE committee :=) Maybe we should lobby for dotlessj. Perhaps form a non profit organization to give dotlessj its proper rights? Regards, Berthold. 3-Feb-1997 13:52:46-GMT,1253;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmza.zdv.Uni-Mainz.DE [134.93.178.30]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA12869 for ; Mon, 3 Feb 1997 06:52:46 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IEZEGZJQXCC7K79B@MZDMZA.ZDV.UNI-MAINZ.DE>; Mon, 03 Feb 1997 14:53:13 +0100 Date: Mon, 03 Feb 1997 14:53:13 +0100 Subject: Re: psnfss and lw35nfss To: bkph@ai.mit.edu, tex-fonts@math.utah.edu Message-id: <01IEZEGZKJV6C7K79B@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: MZDMZA::IN%"bkph@ai.mit.edu" X-VMS-Cc: IN"tex-fonts@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > What a waste. Yet another encoding. And with all the holes in TS1... The wholes in TS1 are filling faster than I had expected. And there some new candidates showing up every week. There are reasons not to have certain Adobe glyphs in TS1 -- but to have them in a so-called scalable font. I talked about those reasons on the 1995 EuroTeX conference at Arnhem, it can be found in the proceedings. --J"org Knappen. 3-Feb-1997 13:55:32-GMT,1797;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA12940 for ; Mon, 3 Feb 1997 06:55:31 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id IAA18886; Mon, 3 Feb 1997 08:55:27 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA14303; Mon, 3 Feb 1997 08:55:26 -0500 (EST) Date: Mon, 3 Feb 1997 08:55:26 -0500 (EST) Message-Id: <199702031355.IAA14303@kauai.ai.mit.edu> To: thierry.bouche@ujf-grenoble.fr In-reply-to: <199702031354.OAA01051@mozart.ujf-grenoble.fr> (message from Thierry Bouche on Mon, 3 Feb 1997 14:54:26 +0100 (MET)) Cc: tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss Reply-to: bkph@ai.mit.edu Concernant « Re: psnfss and lw35nfss », Berthold K.P. Horn écrit : > After all what are called `PostScript' > fonts on comp.text.tex are called `ATM fonts' in the rest of the > world, and while ATM provides better by far rasterization than any > PS interpreter - public domain or commercial - ATM does not include > a PS interpreter and so cannot handle `PS trickery'. how would you call AJenson, then ? an ATM4+ font ? and MinionMM ATM3.02 font ? It was definitely not an ATM2 font. No doubt this dotlessj will be an ATM-300\varepsilon font! I am not sure I get your point. Like some things aren't supported by PS level 1, does that mean something? Like level 2 is evil? Also, ATM has no trouble with dotlessj if (1) the font has it and (2) the TeX system knows how to reencode the font on the fly. 3-Feb-1997 14:24:43-GMT,1471;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA13790 for ; Mon, 3 Feb 1997 07:24:42 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id IAA18421; Mon, 3 Feb 1997 08:37:02 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA14272; Mon, 3 Feb 1997 08:36:55 -0500 (EST) Date: Mon, 3 Feb 1997 08:36:55 -0500 (EST) Message-Id: <199702031336.IAA14272@kauai.ai.mit.edu> To: s.rahtz@elsevier.co.uk, tex-fonts@math.utah.edu cc: KNAPPEN@vkpmzd.kph.uni-mainz.de In-reply-to: <01IEZBDOE5KYC7K8QP@MZDMZA.ZDV.UNI-MAINZ.DE> (KNAPPEN@VKPMZD.kph.Uni-Mainz.DE) Subject: Re: psnfss and lw35nfss Reply-to: bkph@ai.mit.edu > you should ask Jorg to add them to the TS1 encoding, i think. then > they could be accessed (the textcomp support here isnt finished yet, > by the way) There are some Adode characters which I purposefully left out of the TS1 encoding. It is a volunteer task (volunteer needed) to fill them into another encoding called TSA (Text symbols Adobe). What a waste. Yet another encoding. And with all the holes in TS1... Those symbols contain specially the sub or superscripted signs. --J"org Knappen. 3-Feb-1997 14:30:46-GMT,1955;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA13944 for ; Mon, 3 Feb 1997 07:30:45 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA13419 for ; Mon, 3 Feb 1997 14:29:13 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 3 Feb 1997 14:29:19 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA03960; Mon, 3 Feb 1997 14:29:09 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id OAA08194; Mon, 3 Feb 1997 14:27:08 GMT Date: Mon, 3 Feb 1997 14:27:08 GMT Message-Id: <199702031427.OAA08194@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: bkph@ai.mit.edu Cc: KNAPPEN@vkpmzd.kph.uni-mainz.de, tex-font@math.utah.edu In-Reply-To: <199702031332.IAA14260@kauai.ai.mit.edu> References: <199702031332.IAA14260@kauai.ai.mit.edu> Berthold K. P. Horn writes: > It is not just Textures, it is any system that uses fonts that do > not have dotlessj without invoking a PS interpreter. Don't be so agreed > > Sigh, I feel like i am beating a dead horse :=) no, i at least am on your side here > But actually I could care less. This is purely academic for me. > (1) I don't use dotlessj, (2) the fonts I most use do have a > dotlessj, (3) DVIWindo can reencode Type 1 fonts to expose the > dotlessj (even though they are not in Mac or Windows standard > character set) and (4) if i needed jcircumflex or jcaron > I would use Lucida Bright Latin, Lucida Sans Latin, and Lucida i am in your camp with this as well..... sebastian 3-Feb-1997 14:35:10-GMT,2349;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA14115 for ; Mon, 3 Feb 1997 07:35:08 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA13593 for ; Mon, 3 Feb 1997 14:33:35 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 3 Feb 1997 14:34:50 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA04176; Mon, 3 Feb 1997 14:34:40 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id OAA09591; Mon, 3 Feb 1997 14:32:39 GMT Date: Mon, 3 Feb 1997 14:32:39 GMT Message-Id: <199702031432.OAA09591@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: thierry.bouche@ujf-grenoble.fr Cc: bkph@ai.mit.edu, tex-font@math.utah.edu Subject: Re: [KNAPPEN@VKPMZD.kph.Uni-Mainz.DE: Re: psnfss and lw35nfss] In-Reply-To: <199702031345.OAA00732@mozart.ujf-grenoble.fr> References: <199702031256.HAA14230@kauai.ai.mit.edu> <199702031345.OAA00732@mozart.ujf-grenoble.fr> Thierry Bouche writes: > & They can't prevent mathematicians from inventing thousands of new > notations when required ? You for sure know that the \hat / \vector you cant prevent people doing what they like, sure. > never seen in any language? So forgetting a dotlessj in Unicode, as > base for any accented variations of \j is an error. I don't know my attitude is that we should be mainstream in TeX world, not go our own way because we think Unicode isnt right. we should do through the normal channels to change it, not just rage in the outer darkness and implement ghetto solutions (do i sound like Berthold yet?) > abroad, but here in France, any teenager has used the basis > (\vec \i, \vec\j) of the euclidean plane once. when i was a teenager a) i didnt typeset *anything* b) i didnt know what a euclidean plane was (still dont, in fact) c) i spent my time reading literature not thinking about maths notation funny lot your young people are! sebastian 3-Feb-1997 14:49:12-GMT,2479;000000000000 Return-Path: Received: from babe.globecomm.net (babe.globecomm.net [207.51.48.8]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA14479 for ; Mon, 3 Feb 1997 07:49:11 -0700 (MST) Received: from [195.68.10.82] (isdn3.lille.imaginet.fr [195.68.10.82]) by babe.globecomm.net (8.8.5/8.8.0) with SMTP id JAA03308 for ; Mon, 3 Feb 1997 09:49:03 -0500 (EST) Message-Id: <199702031449.JAA03308@babe.globecomm.net> Subject: Re: psnfss and lw35nfss Date: Lun, 3 Fv 97 15:53:15 -0000 x-mailer: Claris Emailer 1.1 From: Yannis Haralambous To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" >Since there is no way to do using ATM and since there is no way to do >it using UNICODE, you can see this will not happen except in the >very restricted world where everything is done using PostScript. Sure you can: that's the approach we use in omega, small "real" PostScript fonts compatible with ATM, or TrueType or anything you want, and big virtual fonts > >Hmm, you can't access Lslash, lslash, Eth, eth etc on the Mac. >Nobody has `fixed' that. And that problem has been around for years. Sure you can, if you have a Polish OS or an Icelandic one (they are easy to get) or if you use a simple utility like FontMongler. BTW, concerning the dotlessj one can write a Perl script that generates out of readable type1 code for j, the code for dotlessj (the outline describing the dot is necessarily the highest one, just check which is the highest and erase it, and bingo). So, for those 15,000 fonts without dotlessj we can automatically write the code for them to get it [and also think of all necessary kernings, etc.] +--------------------------------------------------------------------+ | Yannis Haralambous, Ph.D. yannis@null.net | +--------------------------------------------------------------------+ | 187, rue Nationale fax: +33 (0)3.20.40.28.64 | | 59800 Lille, France ISDN/Numeris: +33 (0)3.20.15.81.77 | +--------------------------------------------------------------------+ ...pour distinguer l'exterieur d'un aquarium, mieux vaut n'etre pas poisson ...the ball I threw while playing in the park has never reached the ground 3-Feb-1997 14:55:00-GMT,1708;000000000000 Return-Path: Received: from babe.globecomm.net (babe.globecomm.net [207.51.48.8]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA14696 for ; Mon, 3 Feb 1997 07:54:59 -0700 (MST) Received: from [195.68.10.82] (isdn3.lille.imaginet.fr [195.68.10.82]) by babe.globecomm.net (8.8.5/8.8.0) with SMTP id JAA03988 for ; Mon, 3 Feb 1997 09:54:45 -0500 (EST) Message-Id: <199702031454.JAA03988@babe.globecomm.net> Subject: Re: [KNAPPEN@VKPMZD.kph.Uni-Mainz.DE: Re: psnfss and lw35nfss] Date: Lun, 3 Fv 97 15:58:57 -0000 x-mailer: Claris Emailer 1.1 From: Yannis Haralambous To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" >But you know, *anyone* can propose new characters to the UNICODE >committee :=) I have tried that once with Greek: there are some total inconsistencies in the Greek Extended part. Nobody ever replied or did anything. +--------------------------------------------------------------------+ | Yannis Haralambous, Ph.D. yannis@null.net | +--------------------------------------------------------------------+ | 187, rue Nationale fax: +33 (0)3.20.40.28.64 | | 59800 Lille, France ISDN/Numeris: +33 (0)3.20.15.81.77 | +--------------------------------------------------------------------+ ...pour distinguer l'exterieur d'un aquarium, mieux vaut n'etre pas poisson ...the ball I threw while playing in the park has never reached the ground 3-Feb-1997 15:02:56-GMT,449;000000000000 Return-Path: Received: from linax1 (linax1.mpae.gwdg.de [134.76.29.69]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id IAA14975 for ; Mon, 3 Feb 1997 08:02:53 -0700 (MST) From: michels@linax1.mpae.gwdg.de Date: Mon, 3 Feb 1997 16:03:46 +0100 Message-Id: <97020316034671@linax1.mpae.gwdg.de> To: TEX-FONTS@math.utah.edu Subject: unsubscribe X-VMS-To: TEX-FONTS@MATH.UTAH.EDU 3-Feb-1997 15:21:18-GMT,1843;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA15534 for ; Mon, 3 Feb 1997 08:21:17 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id PAA15642 for ; Mon, 3 Feb 1997 15:19:45 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 3 Feb 1997 15:20:50 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id PAA08352; Mon, 3 Feb 1997 15:20:41 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id PAA17244; Mon, 3 Feb 1997 15:18:40 GMT Date: Mon, 3 Feb 1997 15:18:40 GMT Message-Id: <199702031518.PAA17244@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: yannis@null.net Cc: tex-font@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702031449.JAA03308@babe.globecomm.net> References: <199702031449.JAA03308@babe.globecomm.net> > BTW, concerning the dotlessj one can write a Perl script that generates > out of readable type1 code for j, the code for dotlessj (the outline > describing the dot is necessarily the highest one, just check which is > the highest and erase it, and bingo). So, for those 15,000 fonts without > dotlessj we can automatically write the code for them to get it [and also > think of all necessary kernings, etc.] you mean your EberhardGothicDemi will not be the same as mine, because you have doctored yours with a Perl script? Wonderful portability that will bring to the world sebastian 3-Feb-1997 15:23:21-GMT,1447;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA15598 for ; Mon, 3 Feb 1997 08:23:20 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id KAA22894; Mon, 3 Feb 1997 10:23:09 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA14421; Mon, 3 Feb 1997 10:23:01 -0500 (EST) Date: Mon, 3 Feb 1997 10:23:01 -0500 (EST) Message-Id: <199702031523.KAA14421@kauai.ai.mit.edu> To: yannis@null.net cc: tex-font@math.utah.edu In-reply-to: <199702031454.JAA03988@babe.globecomm.net> (message from Yannis Haralambous on Lun, 3 Fv 97 15:58:57 -0000) Subject: Re: [KNAPPEN@VKPMZD.kph.Uni-Mainz.DE: Re: psnfss and lw35nfss] Reply-to: bkph@ai.mit.edu >But you know, *anyone* can propose new characters to the UNICODE >committee :=) I have tried that once with Greek: there are some total inconsistencies in the Greek Extended part. Nobody ever replied or did anything. I am very sorry to hear that, I was somehow hoping one day to do something about the mess relating to math... Sigh. Maybe one needs to be a multi- million dollar company, or willing to go to endless boring committee meetings. Regards, Berthold. 3-Feb-1997 15:55:56-GMT,1436;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk (csrj.crn.cogs.susx.ac.uk [192.33.16.212]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id IAA16657 for ; Mon, 3 Feb 1997 08:54:48 -0700 (MST) Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0vrQYf-0000YqC; Mon, 3 Feb 97 15:43 GMT Message-Id: Date: Mon, 3 Feb 97 15:43 GMT From: Alan Jeffrey To: KNAPPEN@vkpmzd.kph.uni-mainz.de Cc: s.rahtz@elsevier.co.uk, tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <01IEZDLNIM0IDDYOCN@MZDMZA.ZDV.UNI-MAINZ.DE> References: <01IEZDLNIM0IDDYOCN@MZDMZA.ZDV.UNI-MAINZ.DE> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII > I still think, this kind of behaviour is better than having no warning at > all, since it allows for searching the error message in the log-file (but > who thinks of that, really?). Currently you *do* get a warning error, but it's produced by the dvi-driver rather than TeX. Dvips prints out a very nice `Warning: glyph foo missing' message every time you process a document containing a black box. > Making lost characters an error by setting \tracinglostchars=2 seems a > sensible extension to suggest to the e-TeX team. Or allow VFs to contain arbitrary TeX code and not just \special's :-) Alan. 3-Feb-1997 16:05:54-GMT,1314;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk (root@csrj.crn.cogs.susx.ac.uk [192.33.16.212]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id JAA16933 for ; Mon, 3 Feb 1997 09:05:10 -0700 (MST) Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0vrQe0-0000ajC; Mon, 3 Feb 97 15:49 GMT Message-Id: Date: Mon, 3 Feb 97 15:49 GMT From: Alan Jeffrey To: "Berthold K.P. Horn" Cc: KNAPPEN@vkpmzd.kph.uni-mainz.de, tex-font@math.utah.edu In-Reply-To: <199702031332.IAA14260@kauai.ai.mit.edu> References: <199702031332.IAA14260@kauai.ai.mit.edu> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII > It is not just Textures, it is any system that uses fonts that do > not have dotlessj without invoking a PS interpreter. Don't be so > myopic please. Using PS for everything is what you do on UNIX > and it makes everything device dependent. Exactly: psnfss isn't just (despite the name) for PostScript fonts, it's for any font / driver technology that uses fonts which come with AFM files. If a glyph isn't in the font, and can't be easily faked with VF code, then tough, use a different font. Alan. 3-Feb-1997 16:53:27-GMT,1845;000000000000 Return-Path: Received: from major.globecomm.net (major.globecomm.net [207.51.48.5]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA18150 for ; Mon, 3 Feb 1997 09:53:26 -0700 (MST) Received: from [195.68.10.82] (isdn3.lille.imaginet.fr [195.68.10.82]) by major.globecomm.net (8.8.5/8.8.0) with SMTP id LAA14565; Mon, 3 Feb 1997 11:51:51 -0500 (EST) Message-Id: <199702031651.LAA14565@major.globecomm.net> Subject: Re: psnfss and lw35nfss Date: Lun, 3 Fv 97 17:56:01 -0000 x-mailer: Claris Emailer 1.1 From: Yannis Haralambous To: "Sebastian Rahtz" cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" >you mean your EberhardGothicDemi will not be the same as mine, because >you have doctored yours with a Perl script? Wonderful portability that >will bring to the world Not necessarily: you can very well build a virtual font pointing to a real font having only the new characters (and thus a new name :-) This can be done automatically (and will work even with Textures). +--------------------------------------------------------------------+ | Yannis Haralambous, Ph.D. yannis@null.net | +--------------------------------------------------------------------+ | 187, rue Nationale fax: +33 (0)3.20.40.28.64 | | 59800 Lille, France ISDN/Numeris: +33 (0)3.20.15.81.77 | +--------------------------------------------------------------------+ ...pour distinguer l'exterieur d'un aquarium, mieux vaut n'etre pas poisson ...the ball I threw while playing in the park has never reached the ground 4-Feb-1997 9:18:13-GMT,1751;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA12949 for ; Tue, 4 Feb 1997 02:18:12 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA03126 for ; Tue, 4 Feb 1997 09:16:39 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Tue, 4 Feb 1997 09:17:10 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA04242; Tue, 4 Feb 1997 09:16:56 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id JAA24980; Tue, 4 Feb 1997 09:14:56 GMT Date: Tue, 4 Feb 1997 09:14:56 GMT Message-Id: <199702040914.JAA24980@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: yannis@null.net Cc: tex-font@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702031651.LAA14565@major.globecomm.net> References: <199702031651.LAA14565@major.globecomm.net> Yannis Haralambous writes: > Not necessarily: you can very well build a virtual font pointing to a > real font > having only the new characters (and thus a new name :-) This can be done > automatically (and will work even with Textures). so now when i send you a document mentioning font FooBar, i have to make sure to send you the tiny font FooBarExtras which you have to install in ATM. sounds like a simple system. i'm with Berthold, i'll use fonts which have a dotlessj in them sebastian 4-Feb-1997 9:55:17-GMT,1337;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmzb.zdv.Uni-Mainz.DE [134.93.8.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA13713 for ; Tue, 4 Feb 1997 02:55:16 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IF0KDZWHZKDROVHC@MZDMZA.ZDV.UNI-MAINZ.DE>; Tue, 04 Feb 1997 10:55:45 +0100 Date: Tue, 04 Feb 1997 10:55:45 +0100 Subject: Re: psnfss and lw35nfss To: s.rahtz@elsevier.co.uk, tex-fonts@math.utah.edu Message-id: <01IF0KDZWPIQDROVHC@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: MZDMZA::IN%"s.rahtz@elsevier.co.uk" X-VMS-Cc: IN"tex-fonts@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT At last, free software is anarchy. Everyone does, what they want. So if Alan and Sebastian want to do virtual fonts without dotless j, they'll do it. And maybe someone else will do virtual fonts with dotless j, too, and place them on some ftp or web site somewhere in the net (preferably CTAN, but an anarchist doesn't care really about this point). The only point in arguing here is to avoid double work and double fonts. And to avoid cluttering up fontname even more. --J"org Knappen 4-Feb-1997 10:15:51-GMT,2071;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA14158 for ; Tue, 4 Feb 1997 03:15:50 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA04900 for ; Tue, 4 Feb 1997 10:14:13 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Tue, 4 Feb 1997 10:15:03 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA14975; Tue, 4 Feb 1997 10:14:48 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id KAA29374; Tue, 4 Feb 1997 10:12:47 GMT Date: Tue, 4 Feb 1997 10:12:47 GMT Message-Id: <199702041012.KAA29374@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: KNAPPEN@vkpmzd.kph.uni-mainz.de Cc: tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <01IF0KDZWPIQDROVHC@MZDMZA.ZDV.UNI-MAINZ.DE> References: <01IF0KDZWPIQDROVHC@MZDMZA.ZDV.UNI-MAINZ.DE> KNAPPEN@vkpmzd.kph.uni-mainz.de writes: > At last, free software is anarchy. a feature not a bug > Alan and Sebastian want to do virtual fonts without dotless j, they'll do > it. And maybe someone else will do virtual fonts with dotless j, too, and .. > The only point in arguing here is to avoid double work and double fonts. > And to avoid cluttering up fontname even more. excuse me, but thats what this list is for, why we are discussing it! if i may say so, you are the person who is most open to criticism of working entirely on your own.. :-} it seems to me that we all want dotlessj if we can have it. but we dont have a portable way of doing it yet. so surely its sensible to have virtual fonts which *everyone* can use, rather than backing further into our corner? sebastian 4-Feb-1997 11:57:39-GMT,1132;000000000000 Return-Path: Received: from tigger.jvnc.net (tigger.jvnc.net [128.121.50.145]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id EAA16114 for ; Tue, 4 Feb 1997 04:57:37 -0700 (MST) Received: from cze.com (ron.jvnc.net) by tigger.jvnc.net with SMTP id AA09759 (5.65c/IDA-1.4.4 for tex-fonts@math.utah.edu); Tue, 4 Feb 1997 06:57:17 -0500 Received: from matt by cze.com (SMI-8.6/SMI-SVR4) id QAA09117; Mon, 3 Feb 1997 16:56:27 -0600 Sender: ron@cze.com Message-Id: <32F66D1A.386A@cze.com> Date: Mon, 03 Feb 1997 16:56:26 -0600 From: Ron Calzone Organization: CZ Engineering, Inc. X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4m) Mime-Version: 1.0 To: tex-fonts@math.utah.edu Subject: Stone fonts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greetings! I have been looking for a font that resembles rock or stone. Is that what your "stone" font is about? Which file(s) would I want to use the font with our Solaris 2.5 or Windows OS? Any help would be appreciated! - Ron ron@cze.com Ron Calzone CZ Engineering, Inc. Dixon, MO 4-Feb-1997 12:33:41-GMT,1307;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA16888 for ; Tue, 4 Feb 1997 05:33:32 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id NAA21746; Tue, 4 Feb 1997 13:32:32 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id NAA24144; Tue, 4 Feb 1997 13:36:08 +0100 (MET) Date: Tue, 4 Feb 1997 13:36:08 +0100 (MET) Message-Id: <199702041236.NAA24144@mozart.ujf-grenoble.fr> From: Thierry Bouche To: Sebastian Rahtz Cc: KNAPPEN@vkpmzd.kph.uni-mainz.de, tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702041012.KAA29374@lochnagarn.elsevier.co.uk> References: <01IF0KDZWPIQDROVHC@MZDMZA.ZDV.UNI-MAINZ.DE> <199702041012.KAA29374@lochnagarn.elsevier.co.uk> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII if we spend the same amount of time & energy on any charachter as what we did for dotlessj, I'm quite anxious for the day we go unicode! Thierry 4-Feb-1997 12:42:48-GMT,1797;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA17075 for ; Tue, 4 Feb 1997 05:42:47 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA09141 for ; Tue, 4 Feb 1997 12:41:13 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Tue, 4 Feb 1997 12:42:13 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA01208; Tue, 4 Feb 1997 12:42:06 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id MAA13217; Tue, 4 Feb 1997 12:40:04 GMT Date: Tue, 4 Feb 1997 12:40:04 GMT Message-Id: <199702041240.MAA13217@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: thierry.bouche@ujf-grenoble.fr Cc: KNAPPEN@vkpmzd.kph.uni-mainz.de, tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702041236.NAA24144@mozart.ujf-grenoble.fr> References: <01IF0KDZWPIQDROVHC@MZDMZA.ZDV.UNI-MAINZ.DE> <199702041012.KAA29374@lochnagarn.elsevier.co.uk> <199702041236.NAA24144@mozart.ujf-grenoble.fr> Thierry Bouche writes: > if we spend the same amount of time & energy on any charachter as what > we did for dotlessj, I'm quite anxious for the day we go unicode! > and its obscured the important questions (for me) which are a) do we want black boxen for missing characters in a font? or just TeX and dvips warnings b) are the kermings in 8r.mtx bad, as Thierry suggests sebastian 4-Feb-1997 13:09:38-GMT,1608;000000000000 Return-Path: Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA17632; Tue, 4 Feb 1997 06:09:37 -0700 (MST) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.4/8.8.4) id GAA22191; Tue, 4 Feb 1997 06:09:36 -0700 (MST) Date: Tue, 4 Feb 1997 06:09:36 -0700 (MST) To: Ron Calzone Cc: beebe@math.utah.edu, tex-fonts@math.utah.edu X-US-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: Stone fonts In-Reply-To: Your message of Mon, 03 Feb 1997 16:56:26 -0600 Message-ID: >> I have been looking for a font that resembles rock or stone. >> Is that what your "stone" font is about? I don't think so. The Adobe Stone font family is named after its designer, Sumner Stone. That typeface is used in the red Adobe PostScript Language Reference Manual as the main body font. ======================================================================== 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 URL: http://www.math.utah.edu/~beebe Salt Lake City, UT 84112, USA ======================================================================== 4-Feb-1997 14:02:16-GMT,1852;000000000000 Return-Path: Received: from major.globecomm.net (major.globecomm.net [207.51.48.5]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA18801 for ; Tue, 4 Feb 1997 07:02:15 -0700 (MST) Received: from [195.68.10.82] (isdn3.lille.imaginet.fr [195.68.10.82]) by major.globecomm.net (8.8.5/8.8.0) with SMTP id JAA08281; Tue, 4 Feb 1997 09:00:20 -0500 (EST) Message-Id: <199702041400.JAA08281@major.globecomm.net> Subject: Re: psnfss and lw35nfss Date: Mar, 4 Fv 97 15:04:32 -0000 x-mailer: Claris Emailer 1.1 From: Yannis Haralambous To: , "Sebastian Rahtz" cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" >if we spend the same amount of time & energy on any charachter as what >we did for dotlessj, I'm quite anxious for the day we go unicode! TUGboat vol. 17, no 2, June 1996, pp. 126-146, "$\Omega$Times and $\Omega$ Helvetica fonts under development: Step One" is desperately waiting for your comments +--------------------------------------------------------------------+ | Yannis Haralambous, Ph.D. yannis@null.net | +--------------------------------------------------------------------+ | 187, rue Nationale fax: +33 (0)3.20.40.28.64 | | 59800 Lille, France ISDN/Numeris: +33 (0)3.20.15.81.77 | +--------------------------------------------------------------------+ ...pour distinguer l'exterieur d'un aquarium, mieux vaut n'etre pas poisson ...the ball I threw while playing in the park has never reached the ground 4-Feb-1997 14:06:47-GMT,1760;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA18935 for ; Tue, 4 Feb 1997 07:06:46 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA11547 for ; Tue, 4 Feb 1997 14:05:13 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Tue, 4 Feb 1997 14:06:10 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA02627; Tue, 4 Feb 1997 14:05:53 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id OAA17656; Tue, 4 Feb 1997 14:03:50 GMT Date: Tue, 4 Feb 1997 14:03:50 GMT Message-Id: <199702041403.OAA17656@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: yannis@null.net Cc: thierry.bouche@ujf-grenoble.fr, KNAPPEN@vkpmzd.kph.uni-mainz.de, tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702041400.JAA08281@major.globecomm.net> References: <199702041400.JAA08281@major.globecomm.net> Yannis Haralambous writes: > TUGboat vol. 17, no 2, June 1996, pp. 126-146, "$\Omega$Times and > $\Omega$ Helvetica > fonts under development: Step One" is desperately waiting for your > comments The TUGboat production team is desperately waiting for an Omega implementation that can process Yannis' article on Omega that should also have appeared in that issue. Its the first `TeX' I have ever used that crashed. Sebastian 4-Feb-1997 14:17:15-GMT,1952;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk (root@csrj.crn.cogs.susx.ac.uk [192.33.16.212]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id HAA19181 for ; Tue, 4 Feb 1997 07:17:12 -0700 (MST) Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0vrlZA-0000YqC; Tue, 4 Feb 97 14:09 GMT Message-Id: Date: Tue, 4 Feb 97 14:09 GMT From: Alan Jeffrey To: Sebastian Rahtz Cc: thierry.bouche@ujf-grenoble.fr, KNAPPEN@vkpmzd.kph.uni-mainz.de, tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702041240.MAA13217@lochnagarn.elsevier.co.uk> References: <01IF0KDZWPIQDROVHC@MZDMZA.ZDV.UNI-MAINZ.DE> <199702041012.KAA29374@lochnagarn.elsevier.co.uk> <199702041236.NAA24144@mozart.ujf-grenoble.fr> <199702041240.MAA13217@lochnagarn.elsevier.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII > and its obscured the important questions (for me) which are Indeed. My opinions... > a) do we want black boxen for missing characters in a font? > or just TeX and dvips warnings This is confusing the issue a bit. The options are: a) not having the characters in the tfm files, which means: * no visible warning from TeX (only in the log file) * no warning from dvips/xdvi/etc * nothing obviously wrong in the .dvi file b) having black boxes (the current solution) which means: * no visible warning from TeX (not in the log file either) * a warning from dvips/xdvi/etc * an obvious black box in the .dvi file So option (b) is better on all three fronts (with the exception about not putting a warning in the log file, but nobody reads that...) > b) are the kermings in 8r.mtx bad, as Thierry suggests I reckon so. The kernings in latin.mtx are the best list I could manage... Alan. 4-Feb-1997 14:29:34-GMT,2056;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA19484 for ; Tue, 4 Feb 1997 07:29:33 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA12473 for ; Tue, 4 Feb 1997 14:28:01 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Tue, 4 Feb 1997 14:29:21 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA02867; Tue, 4 Feb 1997 14:29:08 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id OAA21378; Tue, 4 Feb 1997 14:27:06 GMT Date: Tue, 4 Feb 1997 14:27:06 GMT Message-Id: <199702041427.OAA21378@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: alanje@cogs.susx.ac.uk Cc: tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: References: <01IF0KDZWPIQDROVHC@MZDMZA.ZDV.UNI-MAINZ.DE> <199702041012.KAA29374@lochnagarn.elsevier.co.uk> <199702041236.NAA24144@mozart.ujf-grenoble.fr> <199702041240.MAA13217@lochnagarn.elsevier.co.uk> Alan Jeffrey writes: > a) not having the characters in the tfm files, which means: ... > b) having black boxes (the current solution) which means: > > So option (b) is better on all three fronts (with the exception about > not putting a warning in the log file, but nobody reads that...) but as has been said, it *is* a TeX error, and *should* appear in the log > > b) are the kermings in 8r.mtx bad, as Thierry suggests > > I reckon so. The kernings in latin.mtx are the best list I could > manage... why has no-one said this for 2 years? i see it has Constantin's name on.... sebastian 4-Feb-1997 16:22:56-GMT,1903;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA22329 for ; Tue, 4 Feb 1997 09:22:54 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id LAA18896; Tue, 4 Feb 1997 11:21:23 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id LAA15006; Tue, 4 Feb 1997 11:21:22 -0500 (EST) Date: Tue, 4 Feb 1997 11:21:22 -0500 (EST) Message-Id: <199702041621.LAA15006@kauai.ai.mit.edu> To: thierry.bouche@ujf-grenoble.fr CC: s.rahtz@elsevier.co.uk, KNAPPEN@vkpmzd.kph.uni-mainz.de, tex-fonts@math.utah.edu In-reply-to: <199702041236.NAA24144@mozart.ujf-grenoble.fr> (message from Thierry Bouche on Tue, 4 Feb 1997 13:36:08 +0100 (MET)) Subject: Re: psnfss and lw35nfss Reply-to: bkph@ai.mit.edu if we spend the same amount of time & energy on any charachter as what we did for dotlessj, I'm quite anxious for the day we go unicode! Thierry I am strangely reminded of the long discussion in the DVI driver standards committee on such topics as what to do about TeX's limit of 65536 pages in any one job and whether to print a blank page or just leave it out. And whether the minimum acceptable DVI push down stack should be 64 or 100 deep (most jobs use 3 to 7 levels). Which is perhaps why today we do not have standardization of \special{...}, not even for inclusion of EPS figures (DVIPSONE and DVIWindo have to support *twelve* different ways as a result). Not to mention fontnaming and font encoding issues which still hang around to haunt us. Ah well, it so much easier to discuss dotlessj than any real substantive issues, so lets get on with it :=) 4-Feb-1997 16:26:18-GMT,1841;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA22410 for ; Tue, 4 Feb 1997 09:26:17 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id LAA19114; Tue, 4 Feb 1997 11:25:03 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id LAA15011; Tue, 4 Feb 1997 11:25:02 -0500 (EST) Date: Tue, 4 Feb 1997 11:25:02 -0500 (EST) Message-Id: <199702041625.LAA15011@kauai.ai.mit.edu> To: s.rahtz@elsevier.co.uk CC: thierry.bouche@ujf-grenoble.fr, KNAPPEN@vkpmzd.kph.uni-mainz.de, tex-fonts@math.utah.edu In-reply-to: <199702041240.MAA13217@lochnagarn.elsevier.co.uk> (message from Sebastian Rahtz on Tue, 4 Feb 1997 12:40:04 GMT) Subject: Re: psnfss and lw35nfss Reply-to: bkph@ai.mit.edu Thierry Bouche writes: > if we spend the same amount of time & energy on any charachter as what > we did for dotlessj, I'm quite anxious for the day we go unicode! > and its obscured the important questions (for me) which are a) do we want black boxen for missing characters in a font? or just TeX and dvips warnings b) are the kermings in 8r.mtx bad, as Thierry suggests sebastian In own opinion a TFM file should not lie. If there is no character this should be what the TFM file says. And TeX should announce the missing character *and* its context on screen. I know this goes against modifying TeX in any way, but surely this is just useful informational stuff added on that does not affect the TRIP test? Naturally it would be a while before all TeX implementations do this... 4-Feb-1997 16:34:17-GMT,2040;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA22652 for ; Tue, 4 Feb 1997 09:34:13 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id QAA16921 for ; Tue, 4 Feb 1997 16:32:36 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Tue, 4 Feb 1997 16:33:24 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id QAA04523; Tue, 4 Feb 1997 16:33:13 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id QAA09463; Tue, 4 Feb 1997 16:31:11 GMT Date: Tue, 4 Feb 1997 16:31:11 GMT Message-Id: <199702041631.QAA09463@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: bkph@ai.mit.edu Cc: tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702041625.LAA15011@kauai.ai.mit.edu> References: <199702041240.MAA13217@lochnagarn.elsevier.co.uk> <199702041625.LAA15011@kauai.ai.mit.edu> Berthold K. P. Horn writes: > > In own opinion a TFM file should not lie. If there is no character > this should be what the TFM file says. i think its a good principle. > And TeX should announce the missing character *and* its context on > screen. I know this goes against modifying TeX in any way, but surely > this is just useful informational stuff added on that does not affect well, here you have it. Alan wants a practical system that warns people in the most obvious way, because TeX has this curious blind spot. what is the best principle? > Naturally it would be a while before all TeX > implementations do this... i gather that one implementation already does it... who supports Alan's view of all this? sebastian 4-Feb-1997 16:52:46-GMT,2382;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA23218 for ; Tue, 4 Feb 1997 09:52:45 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id LAA20505; Tue, 4 Feb 1997 11:52:29 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id LAA15035; Tue, 4 Feb 1997 11:52:25 -0500 (EST) Date: Tue, 4 Feb 1997 11:52:25 -0500 (EST) Message-Id: <199702041652.LAA15035@kauai.ai.mit.edu> To: tex-font@math.utah.edu Subject: [BNB@MATH.AMS.ORG: Re: [KNAPPEN@VKPMZD.kph.Uni-Mainz.DE: Re: psnfss and lw35nfss]] Reply-to: bkph@ai.mit.edu Hi: I got this from barbara and she has since informed me that she had intenbed to send it to the whole list. So here goes :=) berthold. From: bbeeton berthold writes Well the UNICODE people have decided there is no such character as `dotlessj' in any language. The closest are `dotlessjdash' and `dotlessjinverteddash'. and (to the best of my knowledge) i agree with the unicode people. however, may i repeat once again, ****unicode is not a font standard**** many people are trying to make it one. they are wrong. i don't know what the solution is, but it's not to adopt unicode as the basis for all fonts. unicode hasn't got two (or three) different sizes of sums or integral signs, *and* *shouldn't*. same principle. however, font creators/vendors don't, by and large, give a damn about math, because it's just too small a piece of the market. as i read the other day (on the electronic math journal list?), whereas the math community may represent a market of tens of thousands, most vendors these days are aiming at tens of millions. the only thing that's going to make (most of) them look twice is money, hard cash, up front. lucida contains the math complement because chuck bigelow was lifted from the rules of the marketplace by his macarthur grant. adobe, provided with essentially the same fonts and glyphs by chuck, botched it royally -- and rejected serious offers of free help to get it right from people who knew what they were talking about. -- bb 4-Feb-1997 17:03:17-GMT,2891;000000000000 Return-Path: Received: from hp9000.hrz.uni-oldenburg.de (hp9000.hrz.uni-oldenburg.de [134.106.40.3]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA23528 for ; Tue, 4 Feb 1997 10:03:14 -0700 (MST) Received: from mathematik.uni-oldenburg.de (mathematik.uni-oldenburg.de [134.106.104.2]) by hp9000.hrz.uni-oldenburg.de (8.8.5/8.8.5/24.01.97) with ESMTP id SAA08153; Tue, 4 Feb 1997 18:03:09 +0100 (MET) Received: from FB6/MAILQUEUE by mathematik.uni-oldenburg.de (Mercury 1.21); 4 Feb 97 18:01:45 MEZ-1MESZ Received: from MAILQUEUE by FB6 (Mercury 1.21); 4 Feb 97 18:01:33 MEZ-1MESZ From: "Peter Harmand" To: Sebastian Rahtz , tex-fonts@math.utah.edu Date: Tue, 4 Feb 1997 18:01:31 MET-1 Subject: Re: psnfss and lw35nfss Priority: normal X-mailer: Pegasus Mail v3.22 Message-ID: > > > b) are the kermings in 8r.mtx bad, as Thierry suggests They are very bad for German typesetting: the kerning pairs T-udieresis and W-odieresis are quite frequent (eg. in doors and words). With fonts which use a lot of kerning, like Bitstream's, the result looks terrible. > > > > I reckon so. The kernings in latin.mtx are the best list I could > > manage... > why has no-one said this for 2 years? i see it has Constantin's name > on.... Because somewhere it is said that 8r is TOTALLY UNSUPPORTED and nobody is using it. And the stake is high (at least for a beginner): * write 8renc.def (and notice that you lost all support by Them) * realize the kerning problems in 8r.mtx (no \latinfamily for fontinst, do everything by hand) * realize that fontinst isn't well prepared to fake small caps in 8r (write 8rc.etx) * realize the following warning if you finally try \usepackage{times} \usepackage[8r]{fontenc} .. LaTeX Font Warning: Font shape `8r/cmr/m/n' undefined (Font) using `8r/ptm/m/n' instead on input line 87. .. I gave up at this point -- even though this is merely an unwanted warning. (But I'm still interested in a solution. The command \rmfamily\selectfont between the two \usepackage lines avoids the warning, but I wanted to use 8r like T1. A \rmfamily before \fontencoding\encodingdefault\selectfont in fontenc.sty would also do. But I don't know if this is a sensible change request.) However, more important for giving up was that as a texadmin you have to provide OT1 and T1. A ligful 8r doesn't save tons of tfm's and vf's. (The only thing I might miss are the original \ldots.) When I made my remark about the missing ligatures in the 8r-encoded metrics in the psnfss-beta distribution, it was really meant as a question: Should one abandon the idea of a ligful 8r-encoding? Peter 4-Feb-1997 17:10:33-GMT,2218;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA23765 for ; Tue, 4 Feb 1997 10:10:32 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id RAA18088 for ; Tue, 4 Feb 1997 17:08:59 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Tue, 4 Feb 1997 17:09:52 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id RAA04875; Tue, 4 Feb 1997 17:09:45 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id RAA13652; Tue, 4 Feb 1997 17:07:43 GMT Date: Tue, 4 Feb 1997 17:07:43 GMT Message-Id: <199702041707.RAA13652@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: harmand@math.uni-oldenburg.de Cc: tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: References: Peter Harmand writes: > They are very bad for German typesetting: the kerning pairs T-udieresis > and W-odieresis are quite frequent (eg. in doors and words). With fonts > which use a lot of kerning, like Bitstream's, the result looks terrible. i'll change them then... > * write 8renc.def (and notice that you lost all support by Them) They are not That Powerful > * realize the kerning problems in 8r.mtx (no \latinfamily for > fontinst, do everything by hand) we can fix that > * realize that fontinst isn't well prepared to fake small caps in 8r > (write 8rc.etx) ah yes. could be done > > When I made my remark about the missing ligatures in the 8r-encoded > metrics in the psnfss-beta distribution, it was really meant as a > question: Should one abandon the idea of a ligful 8r-encoding? > pass. i'll improve the kerning things, others can decide if the thing deserves a future in its own right. sebastian 4-Feb-1997 18:04:20-GMT,1467;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA25333 for ; Tue, 4 Feb 1997 11:04:19 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id NAA23510; Tue, 4 Feb 1997 13:04:08 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id NAA15060; Tue, 4 Feb 1997 13:04:06 -0500 (EST) Date: Tue, 4 Feb 1997 13:04:06 -0500 (EST) Message-Id: <199702041804.NAA15060@kauai.ai.mit.edu> To: s.rahtz@elsevier.co.uk CC: harmand@math.uni-oldenburg.de, tex-fonts@math.utah.edu In-reply-to: <199702041707.RAA13652@lochnagarn.elsevier.co.uk> (message from Sebastian Rahtz on Tue, 4 Feb 1997 17:07:43 GMT) Subject: Re: psnfss and lw35nfss Reply-to: bkph@ai.mit.edu > When I made my remark about the missing ligatures in the 8r-encoded > metrics in the psnfss-beta distribution, it was really meant as a > question: Should one abandon the idea of a ligful 8r-encoding? pass. i'll improve the kerning things, others can decide if the thing deserves a future in its own right. sebastian I vote for making these `full citizens.' It doesn't cost anything to stick in the ligatures. (Unless I misunderstood what you are talking about :-). 4-Feb-1997 18:10:45-GMT,3401;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA25510 for ; Tue, 4 Feb 1997 11:10:44 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id TAA18288; Tue, 4 Feb 1997 19:10:09 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id TAA06749; Tue, 4 Feb 1997 19:13:50 +0100 (MET) Date: Tue, 4 Feb 1997 19:13:50 +0100 (MET) Message-Id: <199702041813.TAA06749@mozart.ujf-grenoble.fr> From: Thierry Bouche To: Sebastian Rahtz Cc: bkph@ai.mit.edu, tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702041631.QAA09463@lochnagarn.elsevier.co.uk> References: <199702041240.MAA13217@lochnagarn.elsevier.co.uk> <199702041625.LAA15011@kauai.ai.mit.edu> <199702041631.QAA09463@lochnagarn.elsevier.co.uk> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: psnfss and lw35nfss », Sebastian Rahtz écrit : > Berthold K. P. Horn writes: > > > > In own opinion a TFM file should not lie. If there is no character > > this should be what the TFM file says. > > i think its a good principle. > I think there is no alternative principle. It's The Truth! > > And TeX should announce the missing character *and* its context on > > screen. I know this goes against modifying TeX in any way, but surely > > this is just useful informational stuff added on that does not affect > well, here you have it. Alan wants a practical system that warns > people in the most obvious way, but, > because TeX has this curious blind spot. it is a dilemna. I remember the old days when there were a t1enc.sty but not yet an inputenc.sty, all the time spent in debugging lost 8bits charachters! All people whining on the news because they had lost accented letters! The behaviour of TeX is really faulty here. > who supports Alan's view of all this? > Users must be warned in some way, I'm not satisfied with the `every drivers emits a warning' method as it frightens uselessly end-users in most cases (hence my first reaction), but if it's the only method available, I think we should keep it > > * realize that fontinst isn't well prepared to fake small caps in 8r > > (write 8rc.etx) > ah yes. could be done > it's a bit contradictory with the `raw'ness of 8r, no? I think if you go 8r and like small caps, you should either use a 8r true small caps font, or do something like S{\fontsize{.8\f@size}{\f@baselineskip}MALL} which really fits the `raw' aesthetic? Notice that there is no need of dotlessj in small caps fonts (which is a relief;-) but we could maybe discuss how to put a dot on capital I/J... Regarding dotlessj, the real question is: is it possible to hide the dot (by any mechanism) automatically with any system for fonts having an AFM? PS is OK thanks to BD. Truetype is probably not ok but I never heard of truetype fonts with afm. What else? Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 4-Feb-1997 18:16:31-GMT,1767;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA25646 for ; Tue, 4 Feb 1997 11:16:30 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id NAA23945; Tue, 4 Feb 1997 13:15:08 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id NAA15073; Tue, 4 Feb 1997 13:15:06 -0500 (EST) Date: Tue, 4 Feb 1997 13:15:06 -0500 (EST) Message-Id: <199702041815.NAA15073@kauai.ai.mit.edu> To: thierry.bouche@ujf-grenoble.fr CC: s.rahtz@elsevier.co.uk, tex-fonts@math.utah.edu In-reply-to: <199702041813.TAA06749@mozart.ujf-grenoble.fr> (message from Thierry Bouche on Tue, 4 Feb 1997 19:13:50 +0100 (MET)) Subject: Re: psnfss and lw35nfss Reply-to: bkph@ai.mit.edu Regarding dotlessj, the real question is: is it possible to hide the dot (by any mechanism) automatically with any system for fonts having an AFM? PS is OK thanks to BD. Truetype is probably not ok but I never heard of truetype fonts with afm. What else? Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ By the way, I don't think I like the qualification that font support is only for fonts with AFM files. It should be fonts for which TFMs can be generated --- and that includes TrueType (DVIWindo happens to write out an intermediary AFM files for TT fonts, but this is just a convenience). Unfortunately TT is less portable than T1 (= Type 1 fonts), but still useful on Macintosh and Windows.... 4-Feb-1997 18:31:07-GMT,1435;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA26131 for ; Tue, 4 Feb 1997 11:31:06 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id TAA19026; Tue, 4 Feb 1997 19:27:42 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id TAA06868; Tue, 4 Feb 1997 19:31:23 +0100 (MET) Date: Tue, 4 Feb 1997 19:31:23 +0100 (MET) Message-Id: <199702041831.TAA06868@mozart.ujf-grenoble.fr> From: Thierry Bouche To: bkph@ai.mit.edu Cc: thierry.bouche@ujf-grenoble.fr, s.rahtz@elsevier.co.uk, tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702041815.NAA15073@kauai.ai.mit.edu> References: <199702041813.TAA06749@mozart.ujf-grenoble.fr> <199702041815.NAA15073@kauai.ai.mit.edu> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: psnfss and lw35nfss », Berthold K.P. Horn écrit : > By the way, I don't think I like the qualification that font support > is only for fonts with AFM files. It should be fonts for which TFMs you remember we're discussing PSnfss? 4-Feb-1997 22:47:08-GMT,3525;000000000000 Return-Path: Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id PAA03308 for ; Tue, 4 Feb 1997 15:47:07 -0700 (MST) Received: from [130.75.249.55] (actually h55.ts1.uni-hannover.de) by mgate with SMTP (PP); Tue, 4 Feb 1997 23:46:37 +0100 X-Sender: nhadkahn@popserver.rrzn.uni-hannover.de Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 4 Feb 1997 23:45:43 +0100 To: Sebastian Rahtz From: Constantin Kahn Subject: Re: psnfss and lw35nfss Cc: tex-fonts@math.utah.edu Sebastian Rahtz writes: >Alan Jeffrey writes: > > > b) are the kermings in 8r.mtx bad, as Thierry suggests > > > > I reckon so. The kernings in latin.mtx are the best list I could > > manage... >why has no-one said this for 2 years? i see it has Constantin's name >on.... Sebastian, Could it be that no one is using 8r-fonts? Could this be related to the fact that the metrics on CTAN were essentially useless for 8r-typesetting since at least February last year (when I first told you about inconsistent character dimensions and LIGTABLE problems in psfonts)? And, yes, 8r.mtx indeed has my name on it. You may remember that the purpose of this file (along with some internal changes to fontinst) was to create 8r-fonts with fontinst rather than with afm2tfm (or afmtotfm? I mean the one that's associated with dvips, just can't remember which) which was your first approach. To this end I essentially created a stripped-down version of latin.mtx sufficient to do fonts in 8r encoding, plus kerning pairs for lower-case accented glyphs analogous to those for upper case glyphs. This addition of the lower-case kerning pairs was done to mimic the results obtained with afm2tfm if memory serves me right (and it also seemed more natural). However, I've just run tftopl on your new ptmr8r.tfm file. The resulting ptmr8r.pl doesn't contain a LIGTABLE at all! So there are *no* kern pairs (and of course no ligatures which was observed before). Funnier yet, there aren't even FONTDIMENs in this tfm. (Didn't know this was possible...) [Note: I checked this with DirectTeX and with OzMF on a Macintosh; my own Unix box presently is a shameful mess and not up to the task, so you may wish to check for yourself.] (Incidentally, the only 8r-psnfss-metrics available for downloading these days which actually incorporate the kerning pairs/ligatures from 8r.mtx seem to be the ports to Textures' proprietary metrics format which I've put on CTAN. And that's just because I've never updated them to the screwed up psfonts released early last year... ;-) Sebastian, before jumping to conclusions and messing with the 8r.mtx file (which may not be the culprit after all) can you *please* (double-)check your scripts/methods? If at all possible then please reissue correct 8r-metrics which are *truly* based on 8r.mtx (which the current ones in psfonts-beta definitely aren't), so that people can verify their claims about deficiencies in the 8r kerning pairs. Thanks. (Otherwise, I would not object to any decision to remove the lower-case kerning pairs from 8r.mtx if they really cause visual quality problems.) Constantin -- Constantin Kahn, Am Fuhrenkampe 80, 30419 Hannover, Germany Phone: (+49) 511-762-5380 or (+49) 511-758528 (home) Email: kahn@math.uni-hannover.de 5-Feb-1997 9:30:53-GMT,2874;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA18300 for ; Wed, 5 Feb 1997 02:30:52 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA01545 for ; Wed, 5 Feb 1997 09:29:16 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Wed, 5 Feb 1997 09:30:09 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA13212; Wed, 5 Feb 1997 09:29:59 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id JAA12645; Wed, 5 Feb 1997 09:27:56 GMT Date: Wed, 5 Feb 1997 09:27:56 GMT Message-Id: <199702050927.JAA12645@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: kahn@math.uni-hannover.de Cc: tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: References: Constantin Kahn writes: > Could it be that no one is using 8r-fonts? Could this be related to the > fact that the metrics on CTAN were essentially useless for 8r-typesetting > since at least February last year (when I first told you about inconsistent probably both true. i have do defense > version of latin.mtx sufficient to do fonts in 8r encoding, plus kerning > pairs for lower-case accented glyphs analogous to those for upper case > glyphs. This addition of the lower-case kerning pairs was done to mimic the > results obtained with afm2tfm if memory serves me right (and it also seemed hmm, that would explain it. I have _pro tem_ commented out those that are extra to latin.mtx > However, I've just run tftopl on your new ptmr8r.tfm file. The resulting > ptmr8r.pl doesn't contain a LIGTABLE at all! So there are *no* kern pairs yes. there was a serious screw-up which I dont fully understand, but it has has now gone away, so i will put up a new set of files later today. ignore everything in earlier release > (which may not be the culprit after all) can you *please* (double-)check > your scripts/methods? If at all possible then please reissue correct one method i used which threw me for a long time was to test foo.tfm by saying tftopl foo.tfm foo.pl without realizing that my setup searched the TEXMF tree *before* ".", so foo.tfm was not read from the current directory! > (Otherwise, I would not object to any decision to remove the lower-case > kerning pairs from 8r.mtx if they really cause visual quality problems.) there are isolated now, anyway, so we can find out sebastian 5-Feb-1997 10:13:25-GMT,1907;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA19136 for ; Wed, 5 Feb 1997 03:13:25 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA02968 for ; Wed, 5 Feb 1997 10:11:52 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Wed, 5 Feb 1997 10:13:01 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA14290; Wed, 5 Feb 1997 10:12:51 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id KAA16404; Wed, 5 Feb 1997 10:10:48 GMT Date: Wed, 5 Feb 1997 10:10:48 GMT Message-Id: <199702051010.KAA16404@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: thierry.bouche@ujf-grenoble.fr Cc: tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702041813.TAA06749@mozart.ujf-grenoble.fr> References: <199702041240.MAA13217@lochnagarn.elsevier.co.uk> <199702041625.LAA15011@kauai.ai.mit.edu> <199702041631.QAA09463@lochnagarn.elsevier.co.uk> <199702041813.TAA06749@mozart.ujf-grenoble.fr> Thierry Bouche writes: > it's a bit contradictory with the `raw'ness of 8r, no? I think if you > go 8r and like small caps, you should either use a 8r true small caps > font, or do something like S{\fontsize{.8\f@size}{\f@baselineskip}MALL} > which really fits the `raw' aesthetic? i think people who want to typeset in 8r should buy small caps fonts if they want smallcaps. i agree that mixing faked smallcaps with the 8r game is silly. it could be done, but i dont want to sebastian 5-Feb-1997 12:17:45-GMT,2600;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA21748 for ; Wed, 5 Feb 1997 05:17:44 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id HAA03733; Wed, 5 Feb 1997 07:16:18 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id HAA15372; Wed, 5 Feb 1997 07:16:17 -0500 (EST) Date: Wed, 5 Feb 1997 07:16:17 -0500 (EST) Message-Id: <199702051216.HAA15372@kauai.ai.mit.edu> To: thierry.bouche@ujf-grenoble.fr CC: thierry.bouche@ujf-grenoble.fr, s.rahtz@elsevier.co.uk, tex-fonts@math.utah.edu In-reply-to: <199702041831.TAA06868@mozart.ujf-grenoble.fr> (message from Thierry Bouche on Tue, 4 Feb 1997 19:31:23 +0100 (MET)) Subject: Re: psnfss and lw35nfss Reply-to: bkph@ai.mit.edu Concernant « Re: psnfss and lw35nfss », Berthold K.P. Horn écrit : > By the way, I don't think I like the qualification that font support > is only for fonts with AFM files. It should be fonts for which TFMs you remember we're discussing PSnfss? Yes, which is LaTeX 2e support for *fonts*. The fact that it is called `PS'NFSS is a unfortunate --- just as it is unfortunate that Type 1 fonts are called `PostScript' fonts in the TeX world (*). There is no problem for example writing `PSNFSS' support for TrueType fonts. All that TeX or LaTex care about are TFMs, so as long as you can get the font's metrics and have a DVI driver (previewer or printer) you should be able to use such fonts. (*) So called `PS' fonts (i) do not require a PS interpreter for rasterization, and in fact (ii) the best rasterizers are not those in PS interpreters. Also, (iii) there are two layers of encryption and (iv) a numeric encoding at the bottom, which if you wish you can rewrite in pseudo PS (or Forth if you like), but (v) it contains instructions like SEAC, HSBW, VSTEM3, CALLSUBR, ENDCHAR etc that don't look like PS to me and then it has instructions that do sort of look like PS but aren't quite, like hvcurveto, rrcurveto, and so on. Most improtantly, (vi) the implicit `fill' operator in Type 1 is totally different from the `top level' user accessible `fill' operator. For a start it implements drop-out control and `erosion'. Of course on a platform where the only way to use ATM fonts is with a PS interpreters you may see things differently :=) 5-Feb-1997 12:26:14-GMT,1887;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA21909 for ; Wed, 5 Feb 1997 05:26:13 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA06897 for ; Wed, 5 Feb 1997 12:24:39 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Wed, 5 Feb 1997 12:26:00 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA09639; Wed, 5 Feb 1997 12:25:55 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id MAA04213; Wed, 5 Feb 1997 12:23:51 GMT Date: Wed, 5 Feb 1997 12:23:51 GMT Message-Id: <199702051223.MAA04213@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: bkph@ai.mit.edu Cc: thierry.bouche@ujf-grenoble.fr, tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702051216.HAA15372@kauai.ai.mit.edu> References: <199702041831.TAA06868@mozart.ujf-grenoble.fr> <199702051216.HAA15372@kauai.ai.mit.edu> Berthold K. P. Horn writes: > Yes, which is LaTeX 2e support for *fonts*. The fact that it is called > `PS'NFSS is a unfortunate --- just as it is unfortunate that Type 1 fonts psnfss is designed to provide support for fonts found in PostScript printers, actually. no more no less. > Of course on a platform where the only way to use ATM fonts is with > a PS interpreters you may see things differently :=) > i feel sorry for people whose only interface to PostScript is via the crippled route of ATM letting them rasterize Type1 fonts.... sebastian 5-Feb-1997 12:33:39-GMT,2175;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA22081 for ; Wed, 5 Feb 1997 05:33:38 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id HAA04234; Wed, 5 Feb 1997 07:32:35 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id HAA15391; Wed, 5 Feb 1997 07:32:14 -0500 (EST) Date: Wed, 5 Feb 1997 07:32:14 -0500 (EST) Message-Id: <199702051232.HAA15391@kauai.ai.mit.edu> To: s.rahtz@elsevier.co.uk CC: thierry.bouche@ujf-grenoble.fr, tex-fonts@math.utah.edu In-reply-to: <199702051223.MAA04213@lochnagarn.elsevier.co.uk> (message from Sebastian Rahtz on Wed, 5 Feb 1997 12:23:51 GMT) Subject: Re: psnfss and lw35nfss Reply-to: bkph@ai.mit.edu Berthold K. P. Horn writes: > Yes, which is LaTeX 2e support for *fonts*. The fact that it is called > `PS'NFSS is a unfortunate --- just as it is unfortunate that Type 1 fonts psnfss is designed to provide support for fonts found in PostScript printers, actually. no more no less. Which I suppose is why there is PSNFSS support for Lucida Bright and Lucida New Math and Lucida Bright Expert and MathTime 1.1 and MathTime Plus :=)? What are we talking about here? The stuff in the PSNFSS package in LaTeX 2e? The basic mechanism for providing support for `new' fonts? Or those huge trees of TFM, VF and whatever files that are lying around in a different part of the CTAN directory structure (I don't know where since I never use that stuff). Maybe its just in the definition of what PSNFSS is... > Of course on a platform where the only way to use ATM fonts is with > a PS interpreters you may see things differently :=) i feel sorry for people whose only interface to PostScript is via the crippled route of ATM letting them rasterize Type1 fonts.... i feel sorry for people whose only way of dealing with preview is to use a PS rasterizer :=) sebastian 5-Feb-1997 12:50:50-GMT,2466;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA22460 for ; Wed, 5 Feb 1997 05:50:49 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA07550 for ; Wed, 5 Feb 1997 12:49:15 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Wed, 5 Feb 1997 12:50:01 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA13604; Wed, 5 Feb 1997 12:49:53 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id MAA07896; Wed, 5 Feb 1997 12:47:49 GMT Date: Wed, 5 Feb 1997 12:47:49 GMT Message-Id: <199702051247.MAA07896@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: bkph@ai.mit.edu Cc: thierry.bouche@ujf-grenoble.fr, tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702051232.HAA15391@kauai.ai.mit.edu> References: <199702051223.MAA04213@lochnagarn.elsevier.co.uk> <199702051232.HAA15391@kauai.ai.mit.edu> Berthold K. P. Horn writes: > Which I suppose is why there is PSNFSS support for Lucida Bright and > Lucida New Math and Lucida Bright Expert and MathTime 1.1 and MathTime > Plus :=)? they are loaded in my printer, on the hard disk! > What are we talking about here? The stuff in the PSNFSS package in > LaTeX 2e? > The basic mechanism for providing support for `new' fonts? i think we are talking about AFM to TFM conversion, actually, to be honest. thats what started this thread, me asking people to comment on my new set of TFM/VF files for the 35 LW fonts. so yes > Or those huge trees of TFM, VF > i feel sorry for people whose only way of dealing with preview is to > use a PS rasterizer :=) who cares (much) about preview? thats not the product. what i want is paper, or PDF (ie more or less full PostScript), or SGML. Much as I respect ATM, and your excellent previewer that uses it I am looking forward to using it seriously when my new computer arrives), I think it is the tail wagging the dog. I can't imagine going back to the bad old days before my pages were described in PostScript, thanks. Sebastian 5-Feb-1997 13:50:50-GMT,2962;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA23976 for ; Wed, 5 Feb 1997 06:50:49 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id OAA10591; Wed, 5 Feb 1997 14:46:39 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id OAA24200; Wed, 5 Feb 1997 14:50:26 +0100 (MET) Date: Wed, 5 Feb 1997 14:50:26 +0100 (MET) Message-Id: <199702051350.OAA24200@mozart.ujf-grenoble.fr> From: Thierry Bouche To: bkph@ai.mit.edu Cc: thierry.bouche@ujf-grenoble.fr, s.rahtz@elsevier.co.uk, tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702051216.HAA15372@kauai.ai.mit.edu> References: <199702041831.TAA06868@mozart.ujf-grenoble.fr> <199702051216.HAA15372@kauai.ai.mit.edu> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: psnfss and lw35nfss », Berthold K.P. Horn écrit : > > Yes, which is LaTeX 2e support for *fonts*. The fact that it is called > `PS'NFSS is a unfortunate --- just as it is unfortunate that Type 1 fonts > are called `PostScript' fonts in the TeX world (*). I'm far away from my domain of reasonnable knowledge to argue with you on such technicalities, but I thought PFA meant Postscript Font Ascii, the fact that so many legal type 1 fonts are NOT ATM fonts (being an ATM font depends on versions of ATM as I already remarked, although being a legal, printable, T1 font is only something that didn't evolve since level 1) > There is no problem > for example writing `PSNFSS' support for TrueType fonts. > if they have an afm. I used fontinst to get metrics for F3 fonts on the Sun (with f3totex & MakeTeXPK, things were smooth:-) i agree with sebastian that being interested in fonts means looking at the printed output (essentially PDF or PS now), preview is an auxiliary stage that has not to be perfectly accurate. thus my last entry on dotlessj: if it is harmless to have charachters in the TFM that do not match real charachters (like black boxes...) we could put a warning in the TFM similar to what fontints does for missing chars (could be: "warning, this font has not a genuine dotlessj glyph, look at the printed output to know if your driver is clever enough..."). the only question is: would this crash some TeX system, or be so much uncomfortable on some TeX systems that it is preferable not to do it? If everybody argues while nobody tests actually, I don't see the point in the discussion. Have a nice day Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 5-Feb-1997 15:14:58-GMT,1280;000000000000 Return-Path: Received: from nottingham.ac.uk (pat.ccc.nottingham.ac.uk [128.243.40.194]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id IAA25918 for ; Wed, 5 Feb 1997 08:14:55 -0700 (MST) Received: from granby.ccc.nottingham.ac.uk [128.243.40.43] by nottingham.ac.uk with esmtp (Exim 1.58 #10) id 0vs93X-0000xc-00; Wed, 5 Feb 1997 15:14:39 +0000 Received: from ([128.243.201.13]) by granby.ccc.nottingham.ac.uk (8.6.12/8.6.12) with SMTP id PAA20509 for ; Wed, 5 Feb 1997 15:14:39 GMT Message-ID: <32F91463.3F8C@unix.ccc.nottingham.ac.uk> Date: Wed, 05 Feb 1997 15:14:43 -0800 From: Conrad Truedson Reply-To: rsxct@unix.ccc.nottingham.ac.uk Organization: Shell Centre for Mathematical Education X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: tex-fonts@math.utah.edu Subject: please unsubscribe me. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please get me off this list. This endless number of articles on psnfss is getting ridiculous. Conrad Truedson -- Conrad Truedson tel +44 115 951 4991 fax +44 115 979 1813 rsxct@unix.ccc.nottingham.ac.uk Timeo Danaos et dona ferentis. -Sean Connery 1996- 5-Feb-1997 16:25:37-GMT,3177;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA27810 for ; Wed, 5 Feb 1997 09:25:36 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id LAA13443; Wed, 5 Feb 1997 11:25:17 -0500 (EST) From: "Berthold K.P. Horn" Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id LAA15525; Wed, 5 Feb 1997 11:25:15 -0500 (EST) Date: Wed, 5 Feb 1997 11:25:15 -0500 (EST) Message-Id: <199702051625.LAA15525@kauai.ai.mit.edu> To: s.rahtz@elsevier.co.uk In-reply-to: <199702051247.MAA07896@lochnagarn.elsevier.co.uk> (message from Sebastian Rahtz on Wed, 5 Feb 1997 12:47:49 GMT) Cc: thierry.bouche@ujf-grenoble.fr, tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss Reply-to: bkph@ai.mit.edu > Which I suppose is why there is PSNFSS support for Lucida Bright and > Lucida New Math and Lucida Bright Expert and MathTime 1.1 and MathTime > Plus :=)? they are loaded in my printer, on the hard disk! OK, funny man! You and how many others do this? (Also, if you are using partial font downloading there seems little point). who cares (much) about preview? Naturally you wouldn't care if the `preview' is low quality :=) and slow. Personally I dislike the term PREview. On a high res screen (admidtly expensive) the quality can be superb. And it feel just as comfortable reading that as paper (without wasting trees or filling my waste-basket). thats not the product. what i want is paper, or PDF (ie more or less full PostScript), or SGML. Well, I can see your perspective. You are working for a publisher, who (still) is making a certain end product. Although that also will change to some degree real soon now. And PDF doesn't mean `PostScript' fonts. It can handle TrueType for example (although personally I wouldn't do this). I was pleasantly surprised just recently when I got onto AMS web site http://www.ams.org and checked out their free MathSciNet trial. This has DVI and PS (no PDF :=(. As soon as I clicked on the DVI file, Netscape loaded up DVIWindo and I had a clear view of the article in about two seconds (these are very just reviews - not long papers)! While I sing the praises of PDF, I have to say that if you have no included figures and only use CM fonts this is pretty neat and fast since DVI is so compact. And you sure care about `preview' in this situation (yes, you can also print it from DVIWindo, but why bother?) Much as I respect ATM, and your excellent previewer that uses it I am looking forward to using it seriously when my new computer arrives), I think it is the tail wagging the dog. I can't imagine going back to the bad old days before my pages were described in PostScript, thanks. By the way, don't badmouth ATM: what do you think is in Acrobat Reader :=) Depending on the version, it either links to an external ATM or has ATM built in. Which is why it looks so good :=). Sebastian 5-Feb-1997 16:29:37-GMT,1427;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA27912 for ; Wed, 5 Feb 1997 09:29:36 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id QAA14937 for ; Wed, 5 Feb 1997 16:27:22 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Wed, 5 Feb 1997 16:28:17 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id QAA27446 for ; Wed, 5 Feb 1997 16:28:12 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id QAA02912; Wed, 5 Feb 1997 16:26:06 GMT Date: Wed, 5 Feb 1997 16:26:06 GMT Message-Id: <199702051626.QAA02912@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: tex-font@math.utah.edu Subject: Re: 8r fonts In-Reply-To: <199702030855.JAA19363@mozart.ujf-grenoble.fr> References: <199702030855.JAA19363@mozart.ujf-grenoble.fr> Do interested parties want to try ftp.tex.ac.uk:incoming/psnfss-beta/*.zip and tear it to pieces again? the 8r.mtx is changed as Thierry suggested. Comments? sebastian 5-Feb-1997 16:35:21-GMT,2496;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA28068 for ; Wed, 5 Feb 1997 09:35:20 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id QAA15101 for ; Wed, 5 Feb 1997 16:33:41 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Wed, 5 Feb 1997 16:34:33 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id QAA27572; Wed, 5 Feb 1997 16:34:27 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id QAA03364; Wed, 5 Feb 1997 16:32:22 GMT Date: Wed, 5 Feb 1997 16:32:22 GMT Message-Id: <199702051632.QAA03364@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: bkph@ai.mit.edu Cc: tex-fonts@math.utah.edu Subject: Re: psnfss and lw35nfss In-Reply-To: <199702051625.LAA15525@kauai.ai.mit.edu> References: <199702051247.MAA07896@lochnagarn.elsevier.co.uk> <199702051625.LAA15525@kauai.ai.mit.edu> Berthold K. P. Horn writes: > On a high res screen (admidtly expensive) the quality can be superb. > And it feel just as comfortable reading that as paper (without wasting trees > or filling my waste-basket). thats what PDF is for, with all the facilities of PostScript! > Well, I can see your perspective. You are working for a publisher, > who (still) is making a certain end product. Although that also > will change to some degree real soon now. is that a threat :-} who do you propose to replace publishers? (no, lets not start that debate on here!) > And PDF doesn't mean > `PostScript' fonts. It can handle TrueType for example (although > personally I wouldn't do this). true. fine by me > on the DVI file, Netscape loaded up DVIWindo and I had a clear view > of the article in about two seconds (these are very just reviews - > not long papers)! or graphics.... (and dont say TIFF to me) > While I sing the praises of PDF, I have to say that if you have no > included figures and only use CM fonts this is pretty neat and fast since which rules out more or less every article we (Elsevier, teh largest scientific publisher in the world) generate... sebastian 6-Feb-1997 14:42:55-GMT,2811;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA28068 for ; Thu, 6 Feb 1997 07:42:50 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id PAA13714; Thu, 6 Feb 1997 15:42:29 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id PAA16865; Thu, 6 Feb 1997 15:46:18 +0100 (MET) Date: Thu, 6 Feb 1997 15:46:18 +0100 (MET) Message-Id: <199702061446.PAA16865@mozart.ujf-grenoble.fr> From: Thierry Bouche To: Sebastian Rahtz CC: tex-font@math.utah.edu Subject: Re: 8r fonts In-Reply-To: <199702051626.QAA02912@lochnagarn.elsevier.co.uk> References: <199702030855.JAA19363@mozart.ujf-grenoble.fr> <199702051626.QAA02912@lochnagarn.elsevier.co.uk> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit there is a pb with compwordmark in T1 fonts: here is what you find in ptmr8t.vpl (CHARACTER O 27 (CHARWD R 0.0) (MAP ) ) also I thought cwm should be 1ex high? apart from this, found no bug. Regarding 8r.mtx, it's obvious in times for fè that suppressing the automatic kern is an improvement. Unfortunately, it's not enough for fï (BTW I'm building a gs35nfss based on urw fonts: they have much more kern pairs for accented letters but forget fï as well, on the other hand they have _positive_ kerns fi rather than faking the lig so that the automatic ff ligs by fontinst are completely different and are not width compatible with those of ptm (although individual chars are...) and _in this case_ using the kern pair f i would improve the fï problem as opposed to what happens with adobe's afm). Maybe one day foundries will provide good afms and all this discussion will loose its object. [here is what I got with my tools: (CHARACTER D 23 (COMMENT compwordmark) (CHARWD R 0.0) (CHARHT R 0.0) (CHARDP R 0.0) (MAP ) ) ] I propose to do a dotlessj gs35nfss archive so that everybody can test it. Fot this purpose, the only technical detail involved would be the following: how can I have fontinst believe that the font ptmr8r.mtx has a raw glyph whose metrics are defined like this \setglyph{dotlessj} \resetitalic{\italic{dotlessi}} \resetdepth{\depth{j}} \resetwidth{\width{j}} \resetitalic{\italic{dotlessi}} \resetheight{\height{dotlessi}} \endsetglyph if it's not in the AFM. would it be easy to add an \adddotlessj to the \transformfont sugar? or is there a better way? 6-Feb-1997 15:35:44-GMT,2220;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA29263 for ; Thu, 6 Feb 1997 08:35:39 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id PAA11500 for ; Thu, 6 Feb 1997 15:34:03 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Thu, 6 Feb 1997 15:35:09 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id PAA05914; Thu, 6 Feb 1997 15:34:52 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id PAA07990; Thu, 6 Feb 1997 15:32:49 GMT Date: Thu, 6 Feb 1997 15:32:49 GMT Message-Id: <199702061532.PAA07990@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: thierry.bouche@ujf-grenoble.fr Cc: tex-font@math.utah.edu Subject: Re: 8r fonts In-Reply-To: <199702061446.PAA16865@mozart.ujf-grenoble.fr> References: <199702030855.JAA19363@mozart.ujf-grenoble.fr> <199702051626.QAA02912@lochnagarn.elsevier.co.uk> <199702061446.PAA16865@mozart.ujf-grenoble.fr> Thierry Bouche writes: > there is a pb with compwordmark in T1 fonts: > here is what you find in ptmr8t.vpl > > (CHARACTER O 27 > (CHARWD R 0.0) is this actually wrong? > also I thought cwm should be 1ex high? yes, its true, Jorg changed that in EC didnt he. rats > opposed to what happens with adobe's afm). Maybe one day foundries > will provide good afms and all this discussion will loose its object. bleeargh. but do i leave 8r.mtx as it is? Constantin, can you look? > following: how can I have fontinst believe that the font ptmr8r.mtx > has a raw glyph whose metrics are defined like this preprocess the AFM file? i started looking at this too and gave up after a short while > if it's not in the AFM. would it be easy to add an \adddotlessj to the > \transformfont sugar? or is there a better way? maybe ALan can comment sebastian 6-Feb-1997 15:58:19-GMT,2644;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA29853 for ; Thu, 6 Feb 1997 08:58:03 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id QAA19883; Thu, 6 Feb 1997 16:58:01 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id RAA20531; Thu, 6 Feb 1997 17:01:56 +0100 (MET) Date: Thu, 6 Feb 1997 17:01:56 +0100 (MET) Message-Id: <199702061601.RAA20531@mozart.ujf-grenoble.fr> From: Thierry Bouche To: Sebastian Rahtz CC: tex-font@math.utah.edu Subject: Re: 8r fonts In-Reply-To: <199702061532.PAA07990@lochnagarn.elsevier.co.uk> References: <199702030855.JAA19363@mozart.ujf-grenoble.fr> <199702051626.QAA02912@lochnagarn.elsevier.co.uk> <199702061446.PAA16865@mozart.ujf-grenoble.fr> <199702061532.PAA07990@lochnagarn.elsevier.co.uk> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: 8r fonts », Sebastian Rahtz écrit : > Thierry Bouche writes: > > there is a pb with compwordmark in T1 fonts: > > here is what you find in ptmr8t.vpl > > > > (CHARACTER O 27 > > (CHARWD R 0.0) > is this actually wrong? humm this is not wrong, what is wrong (I believe) is the MAP not followed by anything: I've a message `there's no char 23 in ptmr8t!' >From xdvi) shouldn't the cwm be a rule of width zero ? > > > opposed to what happens with adobe's afm). Maybe one day foundries > > will provide good afms and all this discussion will loose its object. > bleeargh. but do i leave 8r.mtx as it is? Constantin, can you look? > yes it's better however, what I said is there is no absolute solution anyway. > > following: how can I have fontinst believe that the font ptmr8r.mtx > > has a raw glyph whose metrics are defined like this > preprocess the AFM file? i started looking at this too and > gave up after a short while > well yes: me too, whence my question;-) would be better however not to change the AFM. I'm able with a dotlessj.mtx to have the good ptmr8r.pl but not ptmr8r.mtx. or I do AFM -> mtx + dotlessj.mtx -> pl -> mtx?? > > if it's not in the AFM. would it be easy to add an \adddotlessj to the > > \transformfont sugar? or is there a better way? > maybe ALan can comment I'd like that yes... > > sebastian > 6-Feb-1997 18:21:38-GMT,2837;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA03993 for ; Thu, 6 Feb 1997 11:21:37 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id TAA28845; Thu, 6 Feb 1997 19:21:34 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id TAA24406; Thu, 6 Feb 1997 19:25:29 +0100 (MET) Date: Thu, 6 Feb 1997 19:25:29 +0100 (MET) Message-Id: <199702061825.TAA24406@mozart.ujf-grenoble.fr> From: Thierry Bouche To: tex-font@math.utah.edu, fontinst@cogs.susx.ac.uk Subject: dotlessj in 8r fonts Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII Sebastian Rahtz : > > > how can I have fontinst believe that the font ptmr8r.mtx > > > has a raw glyph whose metrics are defined like this > > preprocess the AFM file? i started looking at this too and > > gave up after a short while > > > > well yes: me too, whence my question;-) would be better however not to > change the AFM. I'm able with a dotlessj.mtx to have the good > ptmr8r.pl but not ptmr8r.mtx. or I do AFM -> mtx + dotlessj.mtx -> pl > -> mtx?? > > > > if it's not in the AFM. would it be easy to add an \adddotlessj to the > > > \transformfont sugar? or is there a better way? > > maybe ALan can comment > well here is the worst piece of fontinst code I've ever used. It does the job however. %% fontinst.rc \let\DESIGNUNITS=\ignore_parens \def\installbasefont#1#2#3#4#5#6#7{ \transformfont{#18rX}{\reencodefont{8r}{\fromafm{#18a}}} \install_font{#18rX}{#18rX,dotlessj,8r}{#2}{#3}{#4}{#5}{#6}{#7}{\etxtopl} \transformfont{#18r}{\scalefont{100}\frompl{#18rX}} \install_font{#18r}{#18r,dotlessj,8r}{#2}{#3}{#4}{#5}{#6}{#7}{\etxtopl} } %% build_utmb \installbasefont{utmb}{8r}{8r}{utm}{b}{n}{} \pltomtx{utmb8r}{utmb8r} \installfont{utmb7t}{utmb8r,latin}{OT1}{OT1}{utm}{b}{n}{} \installfont{utmb8t}{utmb8r,latin}{T1}{T1}{utm}{b}{n}{} %% dotlessj.mtx \relax \metrics \needsfontinstversion{1.6} \setglyph{dotlessj} \resetitalic{\italic{dotlessi}} \resetdepth{\depth{j}} \resetwidth{\width{j}} \resetitalic{\italic{dotlessi}} \resetheight{\height{dotlessi}} \endsetglyph \endmetrics also I had to modify fontinst.sty so that \catcode`\_=\underscorecatcode is reset _after_ \primitiveinput fontinst.rc isn't it what's expected? have a good evening Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 6-Feb-1997 19:01:08-GMT,2193;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk (root@csrj.crn.cogs.susx.ac.uk [192.33.16.212]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id MAA05082 for ; Thu, 6 Feb 1997 12:01:02 -0700 (MST) Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0vsYwk-0000YqC; Thu, 6 Feb 97 18:53 GMT Message-Id: Date: Thu, 6 Feb 97 18:53 GMT From: Alan Jeffrey To: Sebastian Rahtz Cc: thierry.bouche@ujf-grenoble.fr, tex-font@math.utah.edu Subject: Re: 8r fonts In-Reply-To: <199702061532.PAA07990@lochnagarn.elsevier.co.uk> References: <199702030855.JAA19363@mozart.ujf-grenoble.fr> <199702051626.QAA02912@lochnagarn.elsevier.co.uk> <199702061446.PAA16865@mozart.ujf-grenoble.fr> <199702061532.PAA07990@lochnagarn.elsevier.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII > Thierry Bouche writes: > > there is a pb with compwordmark in T1 fonts: > > here is what you find in ptmr8t.vpl > > > > (CHARACTER O 27 > > (CHARWD R 0.0) > is this actually wrong? Ooops, that empty MAP is a byproduct of a different bug fix---lots of people complained about fontinst generating large numbers of MOVERIGHT R 0.0 instructions, so I wrote a bit of code which got rid of them. Unfortunately this also got rid of the MOVERIGHT in cwm, leaving an empty MAP which DEK interprets differently than some of us might expect (eg me)... > > also I thought cwm should be 1ex high? > yes, its true, Jorg changed that in EC didnt he. rats Grumble mutter I guess I can include this into latin.mtx: \setglyph{compwordmark} \glyphrule{0}{\int{xheight}} \endsetglyph > > if it's not in the AFM. would it be easy to add an \adddotlessj to the > > \transformfont sugar? or is there a better way? > maybe ALan can comment I guess doing it at the \transformfont level is as good as any, but really I think the right thing to do is not bother, at least as far as the fonts on CTAN is concerned. What people get up to in the privacy of their own disk space is up to them. Alan. 7-Feb-1997 10:12:59-GMT,2303;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA26475 for ; Fri, 7 Feb 1997 03:12:57 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA29768 for ; Fri, 7 Feb 1997 10:11:22 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Fri, 7 Feb 1997 10:12:39 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA10151; Fri, 7 Feb 1997 10:12:26 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id KAA11058; Fri, 7 Feb 1997 10:12:26 GMT Date: Fri, 7 Feb 1997 10:12:26 GMT Message-Id: <199702071012.KAA11058@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: alanje@cogs.susx.ac.uk Cc: tex-font@math.utah.edu Subject: Re: 8r fonts In-Reply-To: References: <199702030855.JAA19363@mozart.ujf-grenoble.fr> <199702051626.QAA02912@lochnagarn.elsevier.co.uk> <199702061446.PAA16865@mozart.ujf-grenoble.fr> <199702061532.PAA07990@lochnagarn.elsevier.co.uk> > Unfortunately this also got rid of the MOVERIGHT in cwm, leaving an > empty MAP which DEK interprets differently than some of us might > expect (eg me)... oh so *that* explains it. > Grumble mutter I guess I can include this into latin.mtx: > > \setglyph{compwordmark} > \glyphrule{0}{\int{xheight}} > \endsetglyph i have hacked the latin.mt in my finst directory (sorry about this stuff, Alan, but it seems more honest to simply include my hacked copy of fontinst) > really I think the right thing to do is not bother, at least as far as > the fonts on CTAN is concerned. What people get up to in the privacy > of their own disk space is up to them. my current deadline is more or the less the end of this month to burn 2000 CD-ROMs with this stuff on. with that in mind, i am 99% sure i should leave dotlessj alone for this time sebastian 7-Feb-1997 10:46:45-GMT,2117;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA27162 for ; Fri, 7 Feb 1997 03:46:44 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA00669 for ; Fri, 7 Feb 1997 10:45:06 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Fri, 7 Feb 1997 10:46:12 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA12752 for ; Fri, 7 Feb 1997 10:46:04 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id KAA21401; Fri, 7 Feb 1997 10:46:02 GMT Date: Fri, 7 Feb 1997 10:46:02 GMT Message-Id: <199702071046.KAA21401@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: tex-font@math.utah.edu Subject: Re: 8r fonts In-Reply-To: <199702061446.PAA16865@mozart.ujf-grenoble.fr> References: <199702030855.JAA19363@mozart.ujf-grenoble.fr> <199702051626.QAA02912@lochnagarn.elsevier.co.uk> <199702061446.PAA16865@mozart.ujf-grenoble.fr> Joerg reminds me that `T1' PS fonts should include extra fontdimens to be compatible with the EC fonts. It doesnt seem that this will do any harm, and it could be useful some day. does anyone with a few hours to spare fancy working out the fontinst code for these? sebastian def font_cap_height expr x = fontdimen 8: x enddef; def font_asc_height expr x = fontdimen 9: x enddef; def font_acc_cap_height expr x = fontdimen 10: x enddef; def font_desc_depth expr x = fontdimen 11: x enddef; def font_max_height expr x = fontdimen 12: x enddef; def font_max_depth expr x = fontdimen 13: x enddef; def font_digit_width expr x = fontdimen 14: x enddef; def font_cap_stem expr x = fontdimen 15: x enddef; def font_baselineskip expr x = fontdimen 16: x enddef; 7-Feb-1997 16:55:50-GMT,1772;000000000000 Return-Path: Received: from hp9000.hrz.uni-oldenburg.de (hp9000.hrz.uni-oldenburg.de [134.106.40.3]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA05667 for ; Fri, 7 Feb 1997 09:55:45 -0700 (MST) Received: from mathematik.uni-oldenburg.de (mathematik.uni-oldenburg.de [134.106.104.2]) by hp9000.hrz.uni-oldenburg.de (8.8.5/8.8.5/24.01.97) with ESMTP id RAA09331; Fri, 7 Feb 1997 17:55:48 +0100 (MET) Received: from FB6/MAILQUEUE by mathematik.uni-oldenburg.de (Mercury 1.21); 7 Feb 97 17:54:27 MEZ-1MESZ Received: from MAILQUEUE by FB6 (Mercury 1.21); 7 Feb 97 17:54:18 MEZ-1MESZ From: "Peter Harmand" To: Sebastian Rahtz , tex-fonts@math.utah.edu Date: Fri, 7 Feb 1997 17:54:13 MET-1 Subject: Re: 8r fonts Priority: normal X-mailer: Pegasus Mail v3.22 Message-ID: > Do interested parties want to try ftp.tex.ac.uk:incoming/psnfss-beta/*.zip > and tear it to pieces again? No need. I can confirm: checksums ok, kerning and ligatures in 8r ok, character 23 not defined in 8t. > the 8r.mtx is changed as Thierry suggested. Comments? Major improvement. However, may I ask for the opinion about the following (not new in the beta- release): the faked small caps contain the pseudo-ligatures ff, fi, etc at the correct positions, but they also *use* them by ligs in the tfm. Is this really intended? It is not what is done in eccc (of course, these are *real* small caps). Compare the visual appearence and the result of \textsc{Office Of{}f{}ice \char'33 ff} in ecc and ptmrc8t. (Is this a hidden punishment for people using faked small caps? ;-) Peter 7-Feb-1997 16:59:45-GMT,1723;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA05766 for ; Fri, 7 Feb 1997 09:59:44 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id QAA12369 for ; Fri, 7 Feb 1997 16:57:55 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Fri, 7 Feb 1997 16:59:11 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id QAA06765; Fri, 7 Feb 1997 16:59:05 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id QAA11709; Fri, 7 Feb 1997 16:59:04 GMT Date: Fri, 7 Feb 1997 16:59:04 GMT Message-Id: <199702071659.QAA11709@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: harmand@math.uni-oldenburg.de Cc: tex-fonts@math.utah.edu Subject: Re: 8r fonts In-Reply-To: References: Peter Harmand writes: > character 23 not defined in 8t. ok, thats fixed with Alan's code. will regenerate all again, adding Thierry's fixes for ec fontdimens > However, may I ask for the opinion about the following (not new in the beta- > release): the faked small caps contain the pseudo-ligatures ff, fi, etc at > the correct positions, but they also *use* them by ligs in the tfm. Is this i see what you mean. yes its a punishment. any other views? sebastian 7-Feb-1997 17:28:59-GMT,2307;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA06658 for ; Fri, 7 Feb 1997 10:28:54 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id SAA16964 for ; Fri, 7 Feb 1997 18:28:42 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id SAA17371; Fri, 7 Feb 1997 18:32:46 +0100 (MET) Date: Fri, 7 Feb 1997 18:32:46 +0100 (MET) Message-Id: <199702071732.SAA17371@mozart.ujf-grenoble.fr> From: Thierry Bouche To: tex-font@math.utah.edu Subject: gs35nfss (was: for sake of internet's anarch\j) Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII Well i've done a independant distribution using the most recent tools of A. Jeffrey/S. Rahtz & based on the 35 standard PS fonts in their URW version that is distributed with ghostscript 4. The purpose of this is to provide a set of usable metrics (resp. packages) so that people on any platform can play with them and test the new features like BD's dotlessj. The names of the fonts are the usual ones except that the leading p is replaced by an u. True charachters are width compatible with the lw35 distribution but not necessarily faked ones. URW has a much improved kerning scheme (at least for german) so that it could be worth using these metrics even with the standard printer fonts (a map file is provided to do that). I also provide a times.sty for (in)compatibility. The full archive (it's not a TDS tree: you could have to move some files by hand &/or use the CTAN-to-TDS script by sebastian) contains a README file, it's on ftp://fourier.ujf-grenoble.fr/pub/contrib-tex/psfonts/gs35nfss.tar.gz Thanks for commenting on this issue _after_ the tests, and thanks for testing this interface on platforms it's not made for a priori. PS J%org, I've added the 16 fontdimen, but what the hell is cap_stem? Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 7-Feb-1997 18:37:53-GMT,1925;000000000000 Return-Path: Received: from cs.umb.edu (root@cs.umb.edu [158.121.104.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id LAA08586 for ; Fri, 7 Feb 1997 11:37:51 -0700 (MST) Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA28440 (5.65c/IDA-1.4.4 for ); Fri, 7 Feb 1997 13:38:05 -0500 From: "K. Berry" Received: (from kb@localhost) by terminus.cs.umb.edu (8.8.0/8.8.0) id NAA26917; Fri, 7 Feb 1997 13:36:33 -0500 (EST) Date: Fri, 7 Feb 1997 13:36:33 -0500 (EST) Message-Id: <199702071836.NAA26917@terminus.cs.umb.edu> To: tex-fonts@math.utah.edu, thierry.bouche@ujf-grenoble.fr Subject: Re: gs35nfss (was: for sake of internet's anarch\j) Well i've done a independant distribution using the most recent tools Great! of A. Jeffrey/S. Rahtz & based on the 35 standard PS fonts in their It would be good to include Charter and Utopia, too, if possible. (And the two other oddball free fonts from URW if you want to go all out.) Does it include PK's? Having prebuilt PK's at some reasonable set of sizes would be much appreciated by many people. URW has a much improved kerning scheme (at least for german) so that it could be worth using these metrics even with the standard printer It would probably be good for u*.tfm to have URW's improved metrics, and p*.tfm to have the standard metrics. That way people can choose. The full archive (it's not a TDS tree: you could It would be good to make an archive that people can simply download and unpack; better for one person to put in the work to make it tds-compliant than every installer. ftp://fourier.ujf-grenoble.fr/pub/contrib-tex/psfonts/gs35nfss.tar.gz BTW, I've never understood what `nfss' had to do with this stuff, necessarily. Can't it just be `gstexfonts.tar.gz' or some such? Whatever. Thanks for all the work, 7-Feb-1997 21:06:03-GMT,2678;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id OAA12450 for ; Fri, 7 Feb 1997 14:06:02 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id WAA25721; Fri, 7 Feb 1997 22:05:58 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id WAA18961; Fri, 7 Feb 1997 22:10:02 +0100 (MET) From: Thierry Bouche Message-Id: <199702072110.WAA18961@mozart.ujf-grenoble.fr> Subject: Re: gs35nfss To: kb@cs.umb.edu (K. Berry) Date: Fri, 7 Feb 1997 22:10:02 +0100 (MET) Cc: tex-fonts@math.utah.edu, thierry.bouche@ujf-grenoble.fr In-Reply-To: <199702071836.NAA26917@terminus.cs.umb.edu> from "K. Berry" at "Feb 7, 97 01:36:33 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit hmmm what i've done was never meant to be an alternative or whatever to sebastian's work, it's simply given as an example of concrete implementation of the things we talked about. *so that people can test* instead of discussing endlessly more or less accurate philosophies. Is there really a point in doing once more the charter/utopia fonts? i choosed to install from the urw fonts because dotlessj requires more or less ghostscript, so it's the rasterized fonts however, also to test their kerning. What you find is the tex interface for the urw fonts, but as the pfb's are more or less equivalent, I think you can use this interface for printing with adobe fonts as well (you use the same tfm's/vf's but you change the dvips' map). i agree that most of this has nothing to do with nfss, i've put 8r bitmaps as sebastian (made with gsftopk, they have a dotlessj, and they are complete for a 600dpi use of latex at 10pt, i would be gratefull if someone reports testing these on non postscript devices). i must say that as is, my archive is maybe not mature for wide publication, its purpose is really an actual basis for discussion, but without deadline, and we shouldn't disturb sebastian's more serious work with this. as it is now, it's large (16Mb) because it contains PS test files showing the bitmaps of all the fonts at 11pt, so that you could compare with what you are able to preview/rasterize with the corresponding DVI on your system. Thank you for your attention. -- Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 7-Feb-1997 22:34:11-GMT,1856;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id PAA14751 for ; Fri, 7 Feb 1997 15:34:09 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id WAA18262 for ; Fri, 7 Feb 1997 22:32:25 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Fri, 7 Feb 1997 22:33:21 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id WAA13314; Fri, 7 Feb 1997 22:33:12 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id WAA06582; Fri, 7 Feb 1997 22:33:09 GMT Date: Fri, 7 Feb 1997 22:33:09 GMT Message-Id: <199702072233.WAA06582@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: kb@cs.umb.edu Cc: tex-fonts@math.utah.edu, thierry.bouche@ujf-grenoble.fr Subject: Re: gs35nfss (was: for sake of internet's anarch\j) In-Reply-To: <199702071836.NAA26917@terminus.cs.umb.edu> References: <199702071836.NAA26917@terminus.cs.umb.edu> > Does it include PK's? Having prebuilt PK's at some reasonable set of > sizes would be much appreciated by many people. i'm going to make my set of PKs tonight i hope > It would be good to make an archive that people can simply download and > unpack; better for one person to put in the work to make it > tds-compliant than every installer. yes indeed > BTW, I've never understood what `nfss' had to do with this stuff, > necessarily. its nfss because it includes .fd files and because the .sty files are LaTeX-specific sebastian 8-Feb-1997 0:41:07-GMT,1478;000000000000 Return-Path: Received: from dnai.com (dnai.com [140.174.162.28]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id RAA17840 for ; Fri, 7 Feb 1997 17:41:06 -0700 (MST) Received: from texsupp.dnai.com (marin-np1-63.np.dnai.com [204.188.28.63]) by dnai.com (8.7.5/8.7.3) with SMTP id QAA17558 for ; Fri, 7 Feb 1997 16:40:34 -0800 (PST) Message-Id: <2.2.32.19970208004558.006fe28c@mail.dnai.com> X-Sender: texsupp@mail.dnai.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 07 Feb 1997 16:45:58 -0800 To: tex-fonts@math.utah.edu From: Technical Support Subject: Unsubscribe Dear Sirs, It appears that whenever you receive an email, so do we. We're being inundated with non-important, non-conclusive, emails. We want to be abreast of new developments, but we don't want to have to go through dozens of emails to do so (they are typically banter back and forth between different parties). Please remove us from your CC list. Thank you for your consideration. Best regards, +=============================+ | Technical Support | |.............................| | Personal TeX, Inc. | | 12 Madrona Street | | Mill Valley, CA 94941 | | Sales: texsales@pctex.com | | Support: texsupp@pctex.com | | WWW:http://www.pctex.com | +=============================+ 8-Feb-1997 1:14:42-GMT,1621;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id SAA18564 for ; Fri, 7 Feb 1997 18:14:40 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id BAA20106 for ; Sat, 8 Feb 1997 01:13:03 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Sat, 8 Feb 1997 01:14:00 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id BAA02758; Sat, 8 Feb 1997 01:13:54 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id BAA12704; Sat, 8 Feb 1997 01:13:52 GMT Date: Sat, 8 Feb 1997 01:13:52 GMT Message-Id: <199702080113.BAA12704@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: texsupp@pctex.com Cc: tex-fonts@math.utah.edu Subject: Re: Unsubscribe In-Reply-To: <2.2.32.19970208004558.006fe28c@mail.dnai.com> References: <2.2.32.19970208004558.006fe28c@mail.dnai.com> hate to add to your burden but if you think *this* is a busy email discussion list.... but seriously, this isnt a game. i dont mail here because i like banter, i want to get useable stuff out to people who ask for it. i want PCTeX users to be able to use it too. instead of lurking, how about putting the perspective of your customers and your drivers? sebastian 8-Feb-1997 1:55:09-GMT,2045;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id SAA19403 for ; Fri, 7 Feb 1997 18:55:08 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id RAA26908 for ; Fri, 7 Feb 1997 17:55:06 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id RAA06942 for tex-fonts@math.utah.edu; Fri, 7 Feb 1997 17:55:04 -0800 (PST) Message-Id: <199702080155.RAA06942@alonzo.cs.sfu.ca> Subject: Why some readers may not be happy... To: tex-fonts@math.utah.edu Date: Fri, 7 Feb 1997 17:55:03 -0800 (PST) In-Reply-To: <199702080113.BAA12704@lochnagarn.elsevier.co.uk> from "Sebastian Rahtz" at Feb 8, 97 01:13:52 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sebastian, I think the problem is, some people like to be on list that just have announcements (I'm on just such a list for NeXTSTEP PPP, for example). A difficulty arrises when a list is really for discussion but some of its readers think it is an announcments list. I've long since lost the reference that pointed me to this list and so I really can't remember whether it said anything that would lead people to believe this was an announcments list; but I can say that this is often a very low traffic list and that that certainly can give the list an annoucement list like feel for extended periods. Sometimes though, it doesn't feel that much like a discussion list either. The regular participants can come over as somewhat imperious making it a little intimidating to send e-mail to the list if you're not an all-knowing font genius. Regards, Melissa. P.S. If you're reading this list, and you don't want to be on it, the correct address to mail to is tex-fonts-request@math.utah.edu. Please don't send your messages here. 8-Feb-1997 14:24:26-GMT,2276;000000000000 Return-Path: Received: from maildeliver0.tiac.net (maildeliver0.tiac.net [199.0.65.19]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA04333 for ; Sat, 8 Feb 1997 07:24:20 -0700 (MST) Received: from mailnfs0.tiac.net (mailnfs0.tiac.net [199.0.65.17]) by maildeliver0.tiac.net (8.8.0/8.8) with ESMTP id JAA30265; Sat, 8 Feb 1997 09:24:17 -0500 (EST) Received: from yandy.tiac.net (p1.ts19.metro.MA.tiac.com [206.119.198.98]) by mailnfs0.tiac.net (8.8.0/8.8) with SMTP id JAA18102; Sat, 8 Feb 1997 09:24:16 -0500 (EST) Message-Id: <3.0.32.19970208092940.007c3670@tiac.net> X-Sender: yandy@tiac.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 08 Feb 1997 09:29:43 -0500 To: bkph@ai.mit.edu From: Y&Y Inc Subject: Re: [s.rahtz@elsevier.co.uk: Re: 8r fonts] Cc: tex-font@math.utah.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:12 AM 2/8/97 -0500, you wrote: >Date: Fri, 7 Feb 1997 10:46:02 GMT >From: Sebastian Rahtz >To: tex-font@math.utah.edu >Subject: Re: 8r fonts >In-Reply-To: <199702061446.PAA16865@mozart.ujf-grenoble.fr> >References: <199702030855.JAA19363@mozart.ujf-grenoble.fr> <199702051626.QAA02912@lochnagarn.elsevier.co.uk> <199702061446.PAA16865@mozart.ujf-grenoble.fr> >Joerg reminds me that `T1' PS fonts should include extra fontdimens to >be compatible with the EC fonts. It doesnt seem that this will do any >harm, and it could be useful some day. Could someonbe explain what on earth this is about? What does it mean to be `compatible' with the EC fonts? And why would anyone care :=)? >does anyone with a few hours to spare fancy working out the fontinst >code for these? Berthold (working at Y&Y on the weekend) >def font_cap_height expr x = fontdimen 8: x enddef; >def font_asc_height expr x = fontdimen 9: x enddef; >def font_acc_cap_height expr x = fontdimen 10: x enddef; >def font_desc_depth expr x = fontdimen 11: x enddef; >def font_max_height expr x = fontdimen 12: x enddef; >def font_max_depth expr x = fontdimen 13: x enddef; >def font_digit_width expr x = fontdimen 14: x enddef; >def font_cap_stem expr x = fontdimen 15: x enddef; >def font_baselineskip expr x = fontdimen 16: x enddef; 8-Feb-1997 16:10:28-GMT,1118;000000000000 Return-Path: Received: from cs.umb.edu (root@cs.umb.edu [158.121.104.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id JAA06321 for ; Sat, 8 Feb 1997 09:10:27 -0700 (MST) Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA18568 (5.65c/IDA-1.4.4 for ); Sat, 8 Feb 1997 11:10:44 -0500 From: "K. Berry" Received: (from kb@localhost) by terminus.cs.umb.edu (8.8.0/8.8.0) id LAA13741; Sat, 8 Feb 1997 11:09:12 -0500 (EST) Date: Sat, 8 Feb 1997 11:09:12 -0500 (EST) Message-Id: <199702081609.LAA13741@terminus.cs.umb.edu> To: tex-fonts@math.utah.edu Subject: Re: Why some readers may not be happy... A difficulty arrises when a list is really for discussion but some of its readers think it is an announcments list. If you want announcements only, subscribe to tex-archive@math.utah.edu. I always send announcements (and nothing else) there, and so do many other people. ctan-ann@... where is it now ... is probably the other notable announcements-only list. (Probably more notable, in fact.) 8-Feb-1997 21:19:47-GMT,1878;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id OAA12521 for ; Sat, 8 Feb 1997 14:19:46 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id VAA29003 for ; Sat, 8 Feb 1997 21:18:09 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Sat, 8 Feb 1997 21:19:08 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id VAA23752; Sat, 8 Feb 1997 21:18:57 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id VAA25853; Sat, 8 Feb 1997 21:18:54 GMT Date: Sat, 8 Feb 1997 21:18:54 GMT Message-Id: <199702082118.VAA25853@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: help@YandY.com Cc: bkph@ai.mit.edu, tex-font@math.utah.edu Subject: Re: [s.rahtz@elsevier.co.uk: Re: 8r fonts] In-Reply-To: <3.0.32.19970208092940.007c3670@tiac.net> References: <3.0.32.19970208092940.007c3670@tiac.net> help@yandy.com writes: > >Joerg reminds me that `T1' PS fonts should include extra fontdimens to > >be compatible with the EC fonts. It doesnt seem that this will do any > >harm, and it could be useful some day. > > Could someonbe explain what on earth this is about? > What does it mean to be `compatible' with the EC fonts? Jorg added about 8 extra fontdimens to all the European Computer Modern fonts. since these are the reference fonts for the T1/Cork encoding, it seems sensible if the PSNFSS fonts could follow suit > And why would anyone care :=)? there you have me sebastian 9-Feb-1997 17:07:23-GMT,2834;000000000000 Return-Path: Received: from kim.teleport.com (kim.teleport.com [192.108.254.26]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA05215 for ; Sun, 9 Feb 1997 10:07:22 -0700 (MST) Received: from 205.138.224.94 ([205.138.224.94]) by kim.teleport.com (8.8.5/8.7.3) with SMTP id JAA24238 for ; Sun, 9 Feb 1997 09:07:13 -0800 (PST) Message-ID: <32FD8DF9.7147@teleport.com> Date: Sun, 09 Feb 1997 08:42:38 +0000 From: Arthur Ogawa Reply-To: Ogawa@teleport.com Organization: TeX Consultants X-Mailer: Mozilla 3.0Gold (Macintosh; I; PPC) MIME-Version: 1.0 To: tex-fonts@math.utah.edu Subject: The 8r strategy (Was: Unsubscribe) References: <2.2.32.19970208004558.006fe28c@mail.dnai.com> <199702080113.BAA12704@lochnagarn.elsevier.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sebastian Rahtz wrote: >...how > about putting [in] the perspective of your customers and your drivers? PTI now bundles dvips with their product, FYI. But I'll take Sebastian's suggestion to PTI's tech support to heart on behalf of Textures users instead. In the wake of the recent flap over the 8r encoding support for psnfss-class fonts, I understand, possibly inaccurately, that Sebastian, in a recent change to his fontinst work had inadvertently lost ligatures entirely. I expect that he has reinstalled or will reinstall those ligatures. Please correct me if I err? But Constantine Kahn raised an issue that's very crucial to Textures users, who depend entirely on his 8r encoding file, namely whether or not the use of such an encoding is and will be supported by the developers of the psnfss font metrics and others who might post metrics based on Sebastian's fontinst work. I'd like to know for the sake of future planning WRT Textures, 1. Whether users of Texture can depend on continuing to use Constantine's 8r encoding work in the form of his 8r.mtx, that is, will psnfss metrics and their like continue to be compatible with 8r.mtx? 2. Who else uses the 8r-fonts approach? Dvips? Dvipsone? And purely for my own edification: 3. What means do dvips users employ that avoids their use of 8r.mtx? Is it the TeXBase1Encoding.pro file? 4. More generally: it appears that the 8r-fonts work represents a bifurcation point. I'm trying to understand the implications of this bifurcation, which apps go to which side, and what methods are used along each path. I appreciate your help in understanding these points. If there exists any documentation of same, please point me at it. TIA. -- Arthur Ogawa/TeX Consultants voice: +1 209 561-4585 Fax: +1 209 561-4584 mailto:ogawa@teleport.com http://www.teleport.com/~ogawa ftp://ftp.teleport.com/users/ogawa PGP key: finger -l ogawa@teleport.com 9-Feb-1997 23:38:19-GMT,5146;000000000000 Return-Path: Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id QAA13152 for ; Sun, 9 Feb 1997 16:38:17 -0700 (MST) Received: from [130.75.249.56] (actually h56.ts1.uni-hannover.de) by mgate with SMTP (PP); Mon, 10 Feb 1997 00:37:47 +0100 X-Sender: nhadkahn@popserver.rrzn.uni-hannover.de Message-Id: In-Reply-To: <32FD8DF9.7147@teleport.com> References: <2.2.32.19970208004558.006fe28c@mail.dnai.com> <199702080113.BAA12704@lochnagarn.elsevier.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Feb 1997 00:32:28 +0100 To: Ogawa@teleport.com From: Constantin Kahn Subject: Re: The 8r strategy (Was: Unsubscribe) Cc: tex-fonts@math.utah.edu Arthur Ogawa writes: >But I'll take Sebastian's suggestion to PTI's tech support to heart on >behalf of Textures users instead. > >In the wake of the recent flap over the 8r encoding support for >psnfss-class fonts, I understand, possibly inaccurately, that Sebastian, >in a recent change to his fontinst work had inadvertently lost ligatures >entirely. I expect that he has reinstalled or will reinstall those >ligatures. > >Please correct me if I err? It was a long-standing bug, and not the biggest problem with the present psfonts release, which is why Textures users were never exposed to it. Not by me, anyway. >But Constantine Kahn raised an issue that's very crucial to Textures >users, who depend entirely on his 8r encoding file, namely whether or >not the use of such an encoding is and will be supported by the >developers of the psnfss font metrics and others who might post metrics >based on Sebastian's fontinst work. The 8r *encoding* (which is all which my "8r reencoding" suitcase file provides) was never in question; the discussion was about the present implementation of 8r encoded fonts. Whether these fonts have ligatures or kerns at all doesn't matter for users who use the psfonts with the vanilla LaTeX support (i.e., in OT1 or T1 encoding via virtual fonts). A change to ligatures/kerns in 8r fonts *will* matter for people who use these fonts *directly*; this is most likely the case for users of TeX implementations which don't support virtual fonts (directly). For Textures users I don't see this as a problem. If it is the case for your customers, then you should speak up, indeed... >I'd like to know for the sake of future planning WRT Textures, > >1. Whether users of Texture can depend on continuing to use >Constantine's 8r encoding work in the form of his 8r.mtx, that is, will >psnfss metrics and their like continue to be compatible with 8r.mtx? Maybe you could clarify whether you are referring to (a) psfonts in their "user-friendly" 7t/8t incarnation, or to (b) the 8r encoding itself, or to (c) the particular ligatures and kerns in 8r.mtx? For all I know, (a) and (b) are not supposed to change; with respect to (c): the current release of psfonts didn't even use 8r.mtx (by mistake) while the next one is likely to (but with a changed 8r.mtx). >3. What means do dvips users employ that avoids their use of 8r.mtx? Is >it the TeXBase1Encoding.pro file? 8r.mtx is used by fontinst only, by some internal command within \latinfamily, maybe called \installrawfont or something. I put that in (blush), but you do not expect that I remember my own hacks, do you? (Fortunately, Alan never documented it ;-) Nobody who wants to use (whatever) fonts with the 8r encoding is required to use fontinst. So much for 8r.mtx. >4. More generally: it appears that the 8r-fonts work represents a >bifurcation point. I'm trying to understand the implications of this >bifurcation, which apps go to which side, and what methods are used >along each path. It's really just a discussion about the best kerns in 8r encoded fonts. For Textures users there's likely to be a change to the metrics of 8r-fonts with the next release (assuming that I create a new release which I didn't promise to do!) but only with respect to kerns involving lower-case diacritical characters. If you care about Textures users (I trust that you do!), then you could use whatever influence you have to convince Blue Sky Research to support the 8r encoding, at last. As things are nowadays, it's still possible that someone puts out his own set of (say) Chinese font encodings for Textures which wipe out 8r just because they occupy the same internal slot (of the very few free ones). *That's* bothering me. (Not that I would hope for anything constructive from BS Research- I just had to deal with a person who was told by their Tech Support that the psfonts metrics were based on TrueType font metrics. Sigh. The thought.) Constantin PS: Art, note: no 'e' at the end. (But you are still doing better than my fellow countrymen (and my bank) who try to spell my first name with a 'K'.) -- Constantin Kahn, Am Fuhrenkampe 80, 30419 Hannover, Germany Phone: (+49) 511-762-5380 or (+49) 511-758528 (home) Email: kahn@math.uni-hannover.de 9-Feb-1997 23:38:25-GMT,3290;000000000000 Return-Path: Received: from mgate.uni-hannover.de (mgate.uni-hannover.de [130.75.2.3]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id QAA13159 for ; Sun, 9 Feb 1997 16:38:23 -0700 (MST) Received: from [130.75.249.56] (actually h56.ts1.uni-hannover.de) by mgate with SMTP (PP); Mon, 10 Feb 1997 00:38:02 +0100 X-Sender: nhadkahn@popserver.rrzn.uni-hannover.de Message-Id: In-Reply-To: <199702061532.PAA07990@lochnagarn.elsevier.co.uk> References: <199702061446.PAA16865@mozart.ujf-grenoble.fr> <199702030855.JAA19363@mozart.ujf-grenoble.fr> <199702051626.QAA02912@lochnagarn.elsevier.co.uk> <199702061446.PAA16865@mozart.ujf-grenoble.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Feb 1997 00:37:57 +0100 To: Sebastian Rahtz From: Constantin Kahn Subject: Re: 8r fonts Cc: tex-fonts@math.utah.edu Sebastian Rahtz writes: >bleeargh. but do i leave 8r.mtx as it is? Constantin, can you look? I tend to think that Thierry (and other supporters of his views) are right. However, there haven't been any text samples for others to view, there hasn't been a comprehensive discussion of the kerning pairs of any single font (not even Times for which only selected pairs of characters were quoted), and there hasn't been any discussion of how this issue affects fonts from different vendors (other than references to URW fonts). While I find the underlying argument *very* plausible I must say that I find the data to back up the claim utterly unconvincing. (E.g., I believe that I could find poorly kerned pairs in practically every font if I look long enough; if URW fonts are noticeably affected, then it's only more important to check whether other vendor's fonts suffer from the same problems; finally, I don't think that having a lot of kerning pairs is necessarily an indication of quality for a font: it could as well be an indication of sloppy design- not to slighten URW's offerings which I don't have any experience with!) Unfortunately, I don't have the time now and I don't have a font archive of sufficient breadth to "look", sorry. On the other hand, I think that font metrics from a single source (in this case: Sebastian) should be consistent across encodings. In particular, kerning pairs shouldn't change when changing encodings (as long as a character pair is present in both encodings). The old 8r.mtx (mine) violated this principle (for reasons which I've tried to explain in an earlier post), the new one seems to adhere to it. As long as Alan doesn't intend to change latin.mtx the new 8r.mtx is better and the old one should be considered a mistake. So I am with Thierry, only for different reasons (while sympathizing with his views). Is this good enough? Besides, despite the fact that it has my name on it I do not demand custody of 8r.mtx. I've always considered it a one-time contribution (and I remember that I was surprised when it found its way into psfonts unchallenged and unchanged). Constantin -- Constantin Kahn, Am Fuhrenkampe 80, 30419 Hannover, Germany Phone: (+49) 511-762-5380 or (+49) 511-758528 (home) Email: kahn@math.uni-hannover.de 10-Feb-1997 2:19:20-GMT,2305;000000000000 Return-Path: Received: from comet.connix.com (comet.connix.com [198.69.10.4]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id TAA16374 for ; Sun, 9 Feb 1997 19:19:19 -0700 (MST) Received: from kale.connix.com (root@kale.connix.com [204.183.64.34]) by comet.connix.com (8.8.4/8.7.3) with ESMTP id VAA28203 for ; Sun, 9 Feb 1997 21:19:16 -0500 (EST) Received: by kale.connix.com id (Debian Smail-3.2 1996-Jul-4 #2); Sun, 9 Feb 1997 21:21:24 -0500 (EST) Message-Id: Date: Sun, 9 Feb 1997 21:21:24 -0500 (EST) From: Richard Tietjen To: tex-fonts@math.utah.edu Subject: quotesingle and quoteright in PSNFSS Mime-Version: 1.0 (generated by tm-edit 7.93) Content-Type: text/plain; charset=US-ASCII On my system I have the 0.2 version of 8r.enc. My question now is why we're using quotesingle instead of quoteright for the apostrophe character. I prefer the quoteright character, but don't see how to get it. The only thing I can think of is to change the 8r.enc and regenerate ALL my psnfss fonts, a daunting task. Is there a make file for this purpose? But surely there's something I'm missing. Do I have an out-of-date psnfss distribution? % @psencodingfile{ % author = "P. MacKay, Alan Jeffrey, S. Rahtz, K. Berry, B. Horn", % version = "0.2", % date = "7 September 94", % filename = "8r.enc", % email = "kb@cs.umb.edu", % address = "135 Center Hill Rd. // Plymouth, MA 02360", % codetable = "ISO/ASCII", % checksum = "xx", % docstring = "Encoding for TrueType or Type 1 fonts to be used with TeX." % } ... % 0x20 (ASCII begins) /space /exclam /quotedbl /numbersign /dollar /percent /ampersand /quotesingle /parenleft /parenright /asterisk /plus /comma /hyphen /period /slash and the Times Roman fd header, for instance, here currently is: %Filename: 8rptm.fd %Created by: tex 14160times %Created using fontinst v1.335 %THIS FILE SHOULD BE PUT IN A TEX INPUTS DIRECTORY \ProvidesFile{8rptm.fd} [1995/08/11 Fontinst v1.335 font definitions for 8r/ptm.] \DeclareFontFamily{8r}{ptm}{} 10-Feb-1997 9:38:46-GMT,3182;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA25860 for ; Mon, 10 Feb 1997 02:38:45 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA16594 for ; Mon, 10 Feb 1997 09:37:07 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 10 Feb 1997 09:38:07 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA27020; Mon, 10 Feb 1997 09:38:01 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id JAA24294; Mon, 10 Feb 1997 09:38:00 GMT Date: Mon, 10 Feb 1997 09:38:00 GMT Message-Id: <199702100938.JAA24294@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: Ogawa@teleport.com Cc: tex-fonts@math.utah.edu Subject: Re: The 8r strategy (Was: Unsubscribe) In-Reply-To: <32FD8DF9.7147@teleport.com> References: <2.2.32.19970208004558.006fe28c@mail.dnai.com> <199702080113.BAA12704@lochnagarn.elsevier.co.uk> <32FD8DF9.7147@teleport.com> Arthur Ogawa writes: > PTI now bundles dvips with their product, FYI. thats interesting > psnfss-class fonts, I understand, possibly inaccurately, that Sebastian, > in a recent change to his fontinst work had inadvertently lost ligatures > entirely. I expect that he has reinstalled or will reinstall those > ligatures. yes i lost them; yes, i got them back; but this was only in a unadvertised beta release > not the use of such an encoding is and will be supported by the > developers of the psnfss font metrics and others who might post metrics > based on Sebastian's fontinst work. > > I'd like to know for the sake of future planning WRT Textures, the *encoding* is fixed. no problem. the fonts will continue to be issued, and their existence is supported. If someone wants to write style files based on using them directly, they are very welcome. I dont think the LaTeX2e support team will do so, however. > 1. Whether users of Texture can depend on continuing to use > Constantine's 8r encoding work in the form of his 8r.mtx, that is, will > psnfss metrics and their like continue to be compatible with 8r.mtx? yes, definitely. i see no reason to change > 2. Who else uses the 8r-fonts approach? Dvips? Dvipsone? I am not sure what Tom's plans are. dvipsone can use 8r, of course, but Y&Y prefer their texnansi > 3. What means do dvips users employ that avoids their use of 8r.mtx? Is > it the TeXBase1Encoding.pro file? yes > 4. More generally: it appears that the 8r-fonts work represents a > bifurcation point. I'm trying to understand the implications of this not entirely sure i see your point. why is it a bifurcation? > I appreciate your help in understanding these points. If there exists > any documentation of same, please point me at it. see the LaTeX Graphics Companion :-} sebastian 10-Feb-1997 12:02:36-GMT,2518;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA28600 for ; Mon, 10 Feb 1997 05:02:35 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA20839 for ; Mon, 10 Feb 1997 12:00:57 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 10 Feb 1997 12:02:00 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA27801; Mon, 10 Feb 1997 12:01:53 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id MAA06482; Mon, 10 Feb 1997 12:01:50 GMT Date: Mon, 10 Feb 1997 12:01:50 GMT Message-Id: <199702101201.MAA06482@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: kahn@math.uni-hannover.de Cc: tex-fonts@math.utah.edu Subject: Re: 8r fonts In-Reply-To: References: <199702061446.PAA16865@mozart.ujf-grenoble.fr> <199702030855.JAA19363@mozart.ujf-grenoble.fr> <199702051626.QAA02912@lochnagarn.elsevier.co.uk> <199702061532.PAA07990@lochnagarn.elsevier.co.uk> Constantin Kahn writes: > I tend to think that Thierry (and other supporters of his views) are right. > However, there haven't been any text samples for others to view, there > hasn't been a comprehensive discussion of the kerning pairs of any single ... true. > On the other hand, I think that font metrics from a single source (in this > case: Sebastian) should be consistent across encodings. In particular, > kerning pairs shouldn't change when changing encodings (as long as a > character pair is present in both encodings). The old 8r.mtx (mine) > violated this principle (for reasons which I've tried to explain in an ok, thats an important principle, which i think should definitely guide us here > So I am with Thierry, only for different reasons (while sympathizing with > his views). Is this good enough? yes > of 8r.mtx. I've always considered it a one-time contribution (and I > remember that I was surprised when it found its way into psfonts > unchallenged and unchanged). i doubt if its the first time such a thing has happened! sebasian 10-Feb-1997 13:36:51-GMT,2622;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA00599 for ; Mon, 10 Feb 1997 06:36:46 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id OAA26689; Mon, 10 Feb 1997 14:33:13 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id OAA10612; Mon, 10 Feb 1997 14:37:39 +0100 (MET) Date: Mon, 10 Feb 1997 14:37:39 +0100 (MET) Message-Id: <199702101337.OAA10612@mozart.ujf-grenoble.fr> From: Thierry Bouche To: Sebastian Rahtz Cc: kahn@math.uni-hannover.de, tex-fonts@math.utah.edu Subject: Re: 8r fonts In-Reply-To: <199702101201.MAA06482@lochnagarn.elsevier.co.uk> References: <199702061446.PAA16865@mozart.ujf-grenoble.fr> <199702030855.JAA19363@mozart.ujf-grenoble.fr> <199702051626.QAA02912@lochnagarn.elsevier.co.uk> <199702061532.PAA07990@lochnagarn.elsevier.co.uk> <199702101201.MAA06482@lochnagarn.elsevier.co.uk> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: 8r fonts », Sebastian Rahtz écrit : > Constantin Kahn writes: > > I tend to think that Thierry (and other supporters of his views) are right. > > However, there haven't been any text samples for others to view, there > > hasn't been a comprehensive discussion of the kerning pairs of any single > ... true. but is this the point? I propose a third principle: automating kerning is something that should be prevented. When designers adjust the kern pairs for one font, it's a job that's done by hand; it (should?) cover the whole set of glyphs they provide, so a missing kern pair can also be a positive decision (not only an omission). & the point of the descriptions I posted was that it cannot be decided generically how to kern diacrited glyphs depending on the accent and the other letter. Now with T1, we add a few faked glyphs, so it seems natural to try to find the right kern pairs for them, algorithmically if necessary... A question for future releases: a font like Times-Roman looks much better under 8pt when it's track-kerned: why not break the designsize axis in 2 or more pieces? Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 10-Feb-1997 13:41:55-GMT,969;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk (csrj.crn.cogs.susx.ac.uk [192.33.16.212]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id GAA00705 for ; Mon, 10 Feb 1997 06:41:41 -0700 (MST) Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0vtvuG-0000ZaC; Mon, 10 Feb 97 13:36 GMT Message-Id: Date: Mon, 10 Feb 97 13:36 GMT From: Alan Jeffrey To: Richard Tietjen Cc: tex-fonts@math.utah.edu Subject: quotesingle and quoteright in PSNFSS In-Reply-To: References: Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII The current version of 8r.enc is (I believe): % version = "0.6", % date = "14 April 1995", It has at the usual ASCII position. Alan. 10-Feb-1997 13:47:58-GMT,1658;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk (root@csrj.crn.cogs.susx.ac.uk [192.33.16.212]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id GAA00828 for ; Mon, 10 Feb 1997 06:47:52 -0700 (MST) Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0vtvxo-0000ZaC; Mon, 10 Feb 97 13:40 GMT Message-Id: Date: Mon, 10 Feb 97 13:40 GMT From: Alan Jeffrey To: Sebastian Rahtz Cc: harmand@math.uni-oldenburg.de, tex-fonts@math.utah.edu Subject: Re: 8r fonts In-Reply-To: <199702071659.QAA11709@lochnagarn.elsevier.co.uk> References: <199702071659.QAA11709@lochnagarn.elsevier.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII > > However, may I ask for the opinion about the following (not new in the beta- > > release): the faked small caps contain the pseudo-ligatures ff, fi, etc at > > the correct positions, but they also *use* them by ligs in the tfm. Is this > i see what you mean. yes its a punishment. any other views? The etc. ligatures ought to be just the same as an pair. If they're not then it's a bug with latin.mtx. As far as I can see, the following code should put the `right' amount of space between the two s. Is smallcapsextraspace not being set correctly? \setglyph{FFsmall} \glyph{Fsmall}{1000} \movert{\add{\kerning{Fsmall}{Fsmall}} {\mul{2}{\int{smallcapsextraspace}}}} \glyph{Fsmall}{1000} \endsetglyph Alan. 10-Feb-1997 13:49:43-GMT,2622;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA00890 for ; Mon, 10 Feb 1997 06:49:41 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id OAA26689; Mon, 10 Feb 1997 14:33:13 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id OAA10612; Mon, 10 Feb 1997 14:37:39 +0100 (MET) Date: Mon, 10 Feb 1997 14:37:39 +0100 (MET) Message-Id: <199702101337.OAA10612@mozart.ujf-grenoble.fr> From: Thierry Bouche To: Sebastian Rahtz Cc: kahn@math.uni-hannover.de, tex-fonts@math.utah.edu Subject: Re: 8r fonts In-Reply-To: <199702101201.MAA06482@lochnagarn.elsevier.co.uk> References: <199702061446.PAA16865@mozart.ujf-grenoble.fr> <199702030855.JAA19363@mozart.ujf-grenoble.fr> <199702051626.QAA02912@lochnagarn.elsevier.co.uk> <199702061532.PAA07990@lochnagarn.elsevier.co.uk> <199702101201.MAA06482@lochnagarn.elsevier.co.uk> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: 8r fonts », Sebastian Rahtz écrit : > Constantin Kahn writes: > > I tend to think that Thierry (and other supporters of his views) are right. > > However, there haven't been any text samples for others to view, there > > hasn't been a comprehensive discussion of the kerning pairs of any single > ... true. but is this the point? I propose a third principle: automating kerning is something that should be prevented. When designers adjust the kern pairs for one font, it's a job that's done by hand; it (should?) cover the whole set of glyphs they provide, so a missing kern pair can also be a positive decision (not only an omission). & the point of the descriptions I posted was that it cannot be decided generically how to kern diacrited glyphs depending on the accent and the other letter. Now with T1, we add a few faked glyphs, so it seems natural to try to find the right kern pairs for them, algorithmically if necessary... A question for future releases: a font like Times-Roman looks much better under 8pt when it's track-kerned: why not break the designsize axis in 2 or more pieces? Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 10-Feb-1997 16:29:32-GMT,1411;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id JAA05124 for ; Mon, 10 Feb 1997 09:29:30 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <01425-0@venus.open.ac.uk>; Mon, 10 Feb 1997 16:28:17 +0000 Received: by fell.open.ac.uk (SMI-8.6/SMI-SVR4) id QAA15343; Mon, 10 Feb 1997 16:27:45 GMT Date: Mon, 10 Feb 1997 16:27:45 GMT Message-Id: <199702101627.QAA15343@fell.open.ac.uk> From: Chris Rowley To: bkph@ai.mit.edu Cc: tex-font@math.utah.edu Subject: Re: [KNAPPEN@VKPMZD.kph.Uni-Mainz.DE: Re: psnfss and lw35nfss] In-Reply-To: <199702031523.KAA14421@kauai.ai.mit.edu> References: <199702031454.JAA03988@babe.globecomm.net> <199702031523.KAA14421@kauai.ai.mit.edu> Berthold wrote -- > > I am very sorry to hear that, I was somehow hoping one day to do something > about the mess relating to math... Sigh. My understanding of The Unicode Standard suggests that it is not appropriate for encoding all mathematical notations. In what sense is there, at present, a "mess realting to math"? Note: this is probably not the correct forum for discussing uses and deficiencies of Unicode or math notation but it does contain several people with an interest in these subjects. chris 10-Feb-1997 17:06:12-GMT,2609;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id KAA06143 for ; Mon, 10 Feb 1997 10:06:09 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <03907-0@venus.open.ac.uk>; Mon, 10 Feb 1997 17:00:03 +0000 Received: by fell.open.ac.uk (SMI-8.6/SMI-SVR4) id QAA15366; Mon, 10 Feb 1997 16:59:43 GMT Date: Mon, 10 Feb 1997 16:59:43 GMT Message-Id: <199702101659.QAA15366@fell.open.ac.uk> From: Chris Rowley To: bkph@ai.mit.edu Cc: tex-font@math.utah.edu Subject: Unicode and composite characters In-Reply-To: <199702031351.IAA14296@kauai.ai.mit.edu> References: <199702031345.OAA00732@mozart.ujf-grenoble.fr> <199702031351.IAA14296@kauai.ai.mit.edu> Berthold wrote -- > > correct me if I'm wrong, but the unicode people have defined the > lonely accent circumflex? & it's not a linguistic glyph > (never used for itself) > > The UNICODE people - like any good committee - are not of one mind on this. > > On the one hand they explicitly state (at least in earlier versions) > that the `non spacing' accents are provided for constructing composites, > yet also insist on listing all composites that actually occur. > > There are also `spacing' accents, by the way, whatever that is. And > the non-spacing ones are non-sense since they are meant to accent the > character that comes before - nobody has though about the spacing / > kerning issues. That is because the details of spacing and kerning are properties related to typography and glyphs and as such are explicitly and wisely not the concern of a character encoding. At an abstract level, the reason why the Unicode standard needs to contain, and to define the _use_ of, what it calls "non-spacing marks" and "combining characters" is described in Sections 3.9 of 5.9 of The Unicode Standard Version 2.9 (A-W 1996). Particular applications that make use of the decomposed forms are sorting and searching (see section 5.15); these are (normally, at least) independent of typographic conventions and glyphs and are the concern of a character encoding. Please do not interpret my defence of Unicode as meaning that I think that Unicode "gets it all right"; it certainly does not! But the existence of a dotless j (or i, or anything else) in Unicode is not closely related to whether a font needs to contain this glyph: it is only relevant to whether applications concerned only with characters need them. chris 11-Feb-1997 17:20:15-GMT,2150;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA11399 for ; Tue, 11 Feb 1997 10:20:14 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id MAA26940; Tue, 11 Feb 1997 12:19:59 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id MAA00328; Tue, 11 Feb 1997 12:19:57 -0500 (EST) Date: Tue, 11 Feb 1997 12:19:57 -0500 (EST) Message-Id: <199702111719.MAA00328@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: C.A.Rowley@open.ac.uk CC: tex-font@math.utah.edu In-reply-to: <199702101627.QAA15343@fell.open.ac.uk> (message from Chris Rowley on Mon, 10 Feb 1997 16:27:45 GMT) Subject: Re: [KNAPPEN@VKPMZD.kph.Uni-Mainz.DE: Re: psnfss and lw35nfss] Reply-to: bkph@ai.mit.edu > I am very sorry to hear that, I was somehow hoping one day to do something > about the mess relating to math... Sigh. My understanding of The Unicode Standard suggests that it is not appropriate for encoding all mathematical notations. Then why did they bother at all :=) I think they changed there mind at some point but then couldn't undo what was already there... In what sense is there, at present, a "mess realting to math"? (1) It covers only about half of the mathematical symbols available in some Type 1 fonts. (2) It is very spotty, picking some blackboard bold characters and not others e.g. Note: this is probably not the correct forum for discussing uses and deficiencies of Unicode or math notation but it does contain several people with an interest in these subjects. (3) I know that UNICODE is not a glyph standard. Nevertheless it would be extremely beneficial to future developments of mathematical typsetting software if it could be used for all basic symbols. Yes I know you can't expect to do a `math extension' font that way, but certainly, italic, symbols, arrows, blackboard bold, what is in MSAM and MSBM etc. 11-Feb-1997 22:04:11-GMT,1159;000000000000 Return-Path: Received: from cs.umb.edu (root@cs.umb.edu [158.121.104.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id PAA19354 for ; Tue, 11 Feb 1997 15:04:07 -0700 (MST) Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA27563 (5.65c/IDA-1.4.4 for ); Tue, 11 Feb 1997 17:03:53 -0500 From: "K. Berry" Received: (from kb@localhost) by terminus.cs.umb.edu (8.8.0/8.8.0) id RAA28393; Tue, 11 Feb 1997 17:02:14 -0500 (EST) Date: Tue, 11 Feb 1997 17:02:14 -0500 (EST) Message-Id: <199702112202.RAA28393@terminus.cs.umb.edu> To: alanje@cogs.susx.ac.uk Cc: rtietjen@kale.connix.com, tex-fonts@math.utah.edu Subject: Re: quotesingle and quoteright in PSNFSS The current version of 8r.enc is (I believe): % version = "0.6", % date = "14 April 1995", It has at the usual ASCII position. Actually, the current version is % version = "0.6", % date = "22 June 1996", But I believe the changes are cosmetic. I presume Sebastian's new fonts will have quoteright at the ASCII quotesingle position. 17-Feb-1997 17:55:01-GMT,1578;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA17957 for ; Mon, 17 Feb 1997 10:54:36 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id RAA18448 for ; Mon, 17 Feb 1997 17:52:30 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 17 Feb 1997 17:53:34 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id LAA16280 for ; Mon, 17 Feb 1997 11:34:57 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id LAA22829; Mon, 17 Feb 1997 11:34:51 GMT Date: Mon, 17 Feb 1997 11:34:51 GMT Message-Id: <199702171134.LAA22829@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: tex-fonts@math.utah.edu Subject: psnfss etc updated I have now loaded the new set of PSNFSS, font metrics, and my tools on to CTAN, in macros/latex/packages/psnfss fonts/psfonts/... fonts/psfonts/tools The PSNFSS set now includes the new MathTime support by Frank Mittelbach and David Carlisle, and David's revision of Lucida Bright support. These were commissioned by Y&Y, to whom many thanks. The tools, by default, assume you are using a Web2c 7.0 system Sebastian 18-Feb-1997 12:41:42-GMT,2329;000000000000 Return-Path: Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.5]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA11397 for ; Tue, 18 Feb 1997 05:41:41 -0700 (MST) Received: from asterix.urc.tue.nl [131.155.5.10] by mailhost.tue.nl (8.8.5) id NAA18959 (ESMTP). Tue, 18 Feb 1997 13:40:21 +0100 (MET) Received: from rcpt@localhost by asterix.urc.tue.nl (8.8.5) id NAA14998. Tue, 18 Feb 1997 13:40:20 +0100 (MET) From: Piet Tutelaers Message-Id: <199702181240.NAA14998@asterix.urc.tue.nl> Subject: Re: 8r fonts To: tex-fonts@math.utah.edu (TeX fonts mailing list) Date: Tue, 18 Feb 1997 13:40:20 +0100 (MET) Cc: s.rahtz@elsevier.co.uk (Sebastian Rahtz), rcpt@urc.tue.nl (Piet Tutelaers) In-Reply-To: <199702051626.QAA02912@lochnagarn.elsevier.co.uk> from "Sebastian Rahtz" at Feb 5, 97 04:26:06 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text > > Do interested parties want to try ftp.tex.ac.uk:incoming/psnfss-beta/*.zip > and tear it to pieces again? > > sebastian > Here a summary of problems, as reported by my new verifycs PERL Script, found the second beta-release of Sebastian's psfonts (as of 970212): (1) dvips/psnfss.map some names are defined more than once, either with identical definitions (psyr, pzcmi8r) or with different definitions (phvro8rn). (2) a whole bunch of `missing FONTCHECKSUM' errors in VF files. When a VF file references another font it should contain the checksum of the TFM file. For example the ptmr.vpl references the ptmr8r font without such a FONTCHECKSUM line. (MAPFONT D 0 (FONTNAME ptmr8r) (FONTCHECKSUM O ooooooooo) <=== missing (FONTAT R 1.0) (FONTDSIZE R 10.0) ) (3) incorrect checksums are reported for phvb8r.tfm (and some other Helvetica fonts). Problem may be caused by the fact that mine versions of AFM files differ from those Sebastian is using. If you send me Helvetica-Bold.afm I will check. (4) different versions of verifycs. Let us keep the latest one. Because the place for 8r.enc has changed from tools/8r.enc to ./8r.enc I changed the default for ENCPATH into $ENCPATH = ".:tools//"; Success with solving the problems, --Piet Piet Tutelaers 19-Feb-1997 14:08:58-GMT,1154;000000000000 Return-Path: Received: from CUNYVM.CUNY.EDU (cunyvm.cuny.edu [128.228.1.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id HAA16060 for ; Wed, 19 Feb 1997 07:08:57 -0700 (MST) Message-Id: <199702191408.HAA16060@csc-sun.math.utah.edu> Received: from CUNYVM.CUNY.EDU by CUNYVM.CUNY.EDU (IBM VM SMTP V2R3) with BSMTP id 0172; Wed, 19 Feb 97 09:09:04 EST Received: from CUNYVM.CUNY.EDU (NJE origin AJHJJ@CUNYVM) by CUNYVM.CUNY.EDU (LMail V1.2c/1.8c) with RFC822 id 7353; Wed, 19 Feb 1997 09:09:05 -0500 Date: Wed, 19 Feb 97 09:06:51 EST From: Alan Hoenig Subject: New font installation software To: tex-fonts@MATH.UTAH.EDU I've had a set of tools called VFinst loaded onto CTAN in the area fonts/utilities/vfinst. They aim to install outline fonts for use by TeX in a pain-free way (if possible!). As part of the process, VFinst tries to automatically construct and assign the fontname2.1 names of the fonts, which is why this material may be of interest to members of this list. I would be grateful for any comments, feedback, bug reports, etc. 20-Feb-1997 21:00:13-GMT,828;000000000000 Return-Path: Received: from cs.umb.edu (root@cs.umb.edu [158.121.104.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id OAA27673 for ; Thu, 20 Feb 1997 14:00:03 -0700 (MST) Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA03225 (5.65c/IDA-1.4.4 for ); Thu, 20 Feb 1997 15:59:36 -0500 From: "K. Berry" Received: (from kb@localhost) by terminus.cs.umb.edu (8.8.0/8.8.0) id PAA08453; Thu, 20 Feb 1997 15:57:51 -0500 (EST) Date: Thu, 20 Feb 1997 15:57:51 -0500 (EST) Message-Id: <199702202057.PAA08453@terminus.cs.umb.edu> To: P.T.H.Tutelaers@urc.tue.nl Cc: tex-fonts@math.utah.edu, s.rahtz@elsevier.co.uk Subject: Re: 8r fonts (FONTCHECKSUM O ooooooooo) <=== missing vptovf doesn't put this in? 21-Feb-1997 9:31:48-GMT,1911;000000000000 Return-Path: Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.5]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA14996 for ; Fri, 21 Feb 1997 02:31:46 -0700 (MST) Received: from asterix.urc.tue.nl [131.155.5.10] by mailhost.tue.nl (8.8.5) id KAA11265 (ESMTP). Fri, 21 Feb 1997 10:31:33 +0100 (MET) Received: from rcpt@localhost by asterix.urc.tue.nl (8.8.5) id KAA17688. Fri, 21 Feb 1997 10:31:32 +0100 (MET) From: Piet Tutelaers Message-Id: <199702210931.KAA17688@asterix.urc.tue.nl> Subject: Re: 8r fonts To: tex-fonts@math.utah.edu (TeX fonts mailing list) Date: Fri, 21 Feb 1997 10:31:32 +0100 (MET) Cc: kb@cs.umb.edu (K. Berry) In-Reply-To: <199702202057.PAA08453@terminus.cs.umb.edu> from "K. Berry" at Feb 20, 97 03:57:51 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text > > (FONTCHECKSUM O ooooooooo) <=== missing > > vptovf doesn't put this in? > VPtoVF *can* put them into the VF font. One has to be carefull that the TFM search path includes the (correct) fonts. The VPL and PL psfonts are generated with fontinst. The checksums were generated with addchecksum (a PERL script) in combination with the cs utility. I remember that one has to be very carefull with generating virtual fonts. Especially the order in which fonts are generated is very important. And one has to be very carefull with cleaning fonts because they may be referenced elsewhere. Virtual fonts are complex by there nature. A lot of the complexity in generating them is caused by the fact that fontinst can not generate proper checksums. PERL would be a much better tool to handle all the PS font stuff. And it is not too late to rewrite fontinst into PERL. With the help of VERIFYCS (and cs) it should now be possible to trace all incorrect and/or missing checksums. --Piet 21-Feb-1997 10:10:57-GMT,2454;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA15723 for ; Fri, 21 Feb 1997 03:10:56 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA28378 for ; Fri, 21 Feb 1997 10:09:03 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Fri, 21 Feb 1997 10:10:19 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA07110; Fri, 21 Feb 1997 10:10:07 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id KAA23327; Fri, 21 Feb 1997 10:10:01 GMT Date: Fri, 21 Feb 1997 10:10:01 GMT Message-Id: <199702211010.KAA23327@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: P.T.H.Tutelaers@urc.tue.nl Cc: tex-fonts@math.utah.edu, kb@cs.umb.edu Subject: Re: 8r fonts In-Reply-To: <199702210931.KAA17688@asterix.urc.tue.nl> References: <199702202057.PAA08453@terminus.cs.umb.edu> <199702210931.KAA17688@asterix.urc.tue.nl> Piet Tutelaers writes: > VPtoVF *can* put them into the VF font. if the included fonts have checksums, presumably > The VPL and PL psfonts are generated with fontinst. The checksums were > generated with addchecksum (a PERL script) in combination with the cs the majority of the `psnfss' metrics were generated with my Perl scripts (incorporating addchecksum) which use fontinst. with them there is no problem. then we have that small renegade band of non-8r-named fonts which are generated using afm2tfm and the script afm-to-tfm. thats what i never checked when i rebuilt the whole lot, and havent done so yet > Virtual fonts are complex by there nature. A lot of the complexity in > generating them is caused by the fact that fontinst can not generate > proper checksums. PERL would be a much better tool to handle all the PS > font stuff. And it is not too late to rewrite fontinst into PERL. trouble is, so few people work in this area that it isnt anyone's high priority to make it work. using web2c 7's new ability to do system commands might be the quickest answer, as then fontinst could run cs as needed sebastian 21-Feb-1997 11:25:50-GMT,1614;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk (root@csrj.crn.cogs.susx.ac.uk [192.33.16.212]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id EAA17070 for ; Fri, 21 Feb 1997 04:25:42 -0700 (MST) Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0vxt5c-0000ZfC; Fri, 21 Feb 97 11:24 GMT Message-Id: Date: Fri, 21 Feb 97 11:24 GMT From: Alan Jeffrey To: Piet Tutelaers Cc: tex-fonts@math.utah.edu (TeX fonts mailing list), kb@cs.umb.edu (K. Berry) Subject: Re: 8r fonts In-Reply-To: <199702210931.KAA17688@asterix.urc.tue.nl> References: <199702202057.PAA08453@terminus.cs.umb.edu> <199702210931.KAA17688@asterix.urc.tue.nl> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII > PERL would be a much better tool to handle all the PS > font stuff. And it is not too late to rewrite fontinst into PERL. Ho ho ho, very droll... Yes, perl would have been a better language to start off with (in fact some of the postprocessing of fontinst fonts is done with perl) but I think it's too late to port fontinst. You could do it if you were prepared to change the syntax of .mtx and .etx files, but as it stands they are very TeX-specific, and writing a perl parser for them would be tantamount to writing a TeX-mouth interpreter in perl. If I were doing it all again I'd do it differently, but these days I tend to have a `not (very) broken so don't fix it (much)' feeling about fontinst. Alan. 21-Feb-1997 12:07:07-GMT,1895;000000000000 Return-Path: Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.5]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA17847 for ; Fri, 21 Feb 1997 05:07:05 -0700 (MST) Received: from asterix.urc.tue.nl [131.155.5.10] by mailhost.tue.nl (8.8.5) id NAA18031 (ESMTP). Fri, 21 Feb 1997 13:06:54 +0100 (MET) Received: from rcpt@localhost by asterix.urc.tue.nl (8.8.5) id NAA00799. Fri, 21 Feb 1997 13:06:50 +0100 (MET) From: Piet Tutelaers Message-Id: <199702211206.NAA00799@asterix.urc.tue.nl> Subject: Re: 8r fonts To: tex-fonts@math.utah.edu (TeX fonts mailing list) Date: Fri, 21 Feb 1997 13:06:49 +0100 (MET) Cc: alanje@cogs.susx.ac.uk (Alan Jeffrey) In-Reply-To: from "Alan Jeffrey" at Feb 21, 97 11:24:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text > > > PERL would be a much better tool to handle all the PS > > font stuff. And it is not too late to rewrite fontinst into PERL. > > Ho ho ho, very droll... Yes, perl would have been a better language > to start off with (in fact some of the postprocessing of fontinst > fonts is done with perl) but I think it's too late to port fontinst. > You could do it if you were prepared to change the syntax of .mtx and > .etx files, but as it stands they are very TeX-specific, and writing a > perl parser for them would be tantamount to writing a TeX-mouth > interpreter in perl. > > If I were doing it all again I'd do it differently, but these days I > tend to have a `not (very) broken so don't fix it (much)' feeling > about fontinst. > > Alan. > In order to get a feeling for the effort needed to rewrite fontinst into PERL: (1) What exact role plays the .etx and .mtx files in the fontinst process? (2) Which parts can only be handled in TeX's mouth? --Piet 21-Feb-1997 12:36:10-GMT,3332;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA18461 for ; Fri, 21 Feb 1997 05:36:10 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id HAA19862; Fri, 21 Feb 1997 07:36:02 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id HAA04738; Fri, 21 Feb 1997 07:36:01 -0500 (EST) Date: Fri, 21 Feb 1997 07:36:01 -0500 (EST) Message-Id: <199702211236.HAA04738@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: P.T.H.Tutelaers@urc.tue.nl CC: tex-fonts@math.utah.edu, kb@cs.umb.edu In-reply-to: <199702210931.KAA17688@asterix.urc.tue.nl> (message from Piet Tutelaers on Fri, 21 Feb 1997 10:31:32 +0100 (MET)) Subject: Re: 8r fonts Reply-to: bkph@ai.mit.edu > (FONTCHECKSUM O ooooooooo) <=== missing > vptovf doesn't put this in? The VPL and PL psfonts are generated with fontinst. The checksums were generated with addchecksum (a PERL script) in combination with the cs utility. I remember that one has to be very carefull with generating virtual fonts. Especially the order in which fonts are generated is very important. And one has to be very carefull with cleaning fonts because they may be referenced elsewhere. Virtual fonts are complex by there nature. No kidding. Two TFMs + one VF per font. And in one of the TFMs kerning and ligatures can be junk because they are not used etc. A lot of the complexity in generating them is caused by the fact that fontinst can not generate proper checksums. PERL would be a much better tool to handle all the PS font stuff. And it is not too late to rewrite fontinst into PERL. Checksums seem to be a mess. People are getting checksum errors all the time and typically do not know what it means. And so they are ignored and people ask about ways of turning off the warnings. Plus over the years the algorithms used have drifted. Plus it is driver specific. What *is* the algorithm for checksums used by fontinst? What *is* the algorithm for checksums used by AFM2TFM? What does PCTeX use? I personally think that checksums can serve a much better purpose than they do now: hide the encoding information there. This is critically important since TFMs are encoding sensitive and if you have the wrong TFM you are hosed and you can't tell from looking at this binary mess what it is. This is even more important with drivers who (because they do not produce resolution independent output) refer to TFM files. Which is why AFMtoTFM hides the name of the encoding vector used to generate the TFM in the checksum. Not only can you later decode this to find out what the encoding vector was, but since this is passed into the DVI file by TeX, it can be checked at the driver/previewer level to see whether it matches what encoding *it* is set up for. Solves many nightmarish debugging problems! Just as important as having TeX announce on screen that there are `missing characters'. With the help of VERIFYCS (and cs) it should now be possible to trace all incorrect and/or missing checksums. --Piet Berthold. 21-Feb-1997 12:41:25-GMT,2469;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk (root@csrj.crn.cogs.susx.ac.uk [192.33.16.212]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id FAA18546 for ; Fri, 21 Feb 1997 05:41:22 -0700 (MST) Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0vxuH6-0000alC; Fri, 21 Feb 97 12:40 GMT Message-Id: Date: Fri, 21 Feb 97 12:40 GMT From: Alan Jeffrey To: Piet Tutelaers Cc: tex-fonts@math.utah.edu (TeX fonts mailing list), alanje@cogs.susx.ac.uk (Alan Jeffrey) Subject: Re: 8r fonts In-Reply-To: <199702211206.NAA00799@asterix.urc.tue.nl> References: <199702211206.NAA00799@asterix.urc.tue.nl> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII Piet Tutelaers writes: > In order to get a feeling for the effort needed to rewrite fontinst into > PERL: > (1) What exact role plays the .etx and .mtx files in the fontinst process? The .etx files describe the font encoding, and the .mtx files describe the metrics, in a TeX-friendly format. Both of them make heavy use of TeX's macro language to provide control structures such as if-statements and commands. For example the command which defines an `unfakable' glyph (a black box with a `missing glyph' special) is: \setcommand\unfakable#1{ \setglyph{#1} \ifisglyph{#1-not}\then \moveup{\neg{\depth{#1-not}}} \glyphrule{ \width{#1-not} }{ \add{\depth{#1-not}}{\height{#1-not}} } \resetitalic{\italic{#1-not}} \moveup{\depth{#1-not}} \else \glyphrule{500}{500} \fi \glyphwarning{missing glyph `#1'} \endsetglyph } > (2) Which parts can only be handled in TeX's mouth? Fontinst does have a published API for the syntax of commands like \setcommand, \ifisglyph etc. etc. but writing a parser and interpreter for it would effectively mean reinventing TeX's mouth. One of the reasons why it's implemented in TeX in the first place is to make use of the macro language. Fontinst itself is only ~2.5kLOC, but once you include all the .mtx and .etx files which come with it it's ~12kLOC. Porting it would be a major enterprise for not terribly much gain compared to using perl scripts to postprocess fontinst output. Alan. 21-Feb-1997 15:32:08-GMT,5994;000000000000 Return-Path: Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.5]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA22104 for ; Fri, 21 Feb 1997 08:32:06 -0700 (MST) Received: from asterix.urc.tue.nl [131.155.5.10] by mailhost.tue.nl (8.8.5) id QAA28564 (ESMTP). Fri, 21 Feb 1997 16:30:28 +0100 (MET) Received: from rcpt@localhost by asterix.urc.tue.nl (8.8.5) id QAA26419. Fri, 21 Feb 1997 16:30:27 +0100 (MET) From: Piet Tutelaers Message-Id: <199702211530.QAA26419@asterix.urc.tue.nl> Subject: Re: 8r fonts To: tex-fonts@math.utah.edu (TeX fonts mailing list) Date: Fri, 21 Feb 1997 16:30:26 +0100 (MET) Cc: bkph@ai.mit.edu In-Reply-To: <199702211236.HAA04738@kauai.ai.mit.edu> from "Berthold K.P. Horn" at Feb 21, 97 07:36:01 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text > > > > (FONTCHECKSUM O ooooooooo) <=== missing > > vptovf doesn't put this in? > > The VPL and PL psfonts are generated with fontinst. The checksums were > generated with addchecksum (a PERL script) in combination with the cs > utility. I remember that one has to be very carefull with generating > virtual fonts. Especially the order in which fonts are generated is > very important. And one has to be very carefull with cleaning fonts because > they may be referenced elsewhere. > > Virtual fonts are complex by there nature. > > No kidding. Two TFMs + one VF per font. And in one of the TFMs > kerning and ligatures can be junk because they are not used etc. > The world for TeX-users and TeX-maintainers would have been a lot better when Knuth (or somebody else) had written a WEB-module (is that possible?) or C-module that contains all functions a decent DVI-driver needs. What we now have are a lot of programs all using there own methods for reading TFM and VF files. By providing this module it could have been the standard for everybody. > A lot of the complexity in > generating them is caused by the fact that fontinst can not generate > proper checksums. PERL would be a much better tool to handle all the PS > font stuff. And it is not too late to rewrite fontinst into PERL. > > Checksums seem to be a mess. People are getting checksum errors > all the time and typically do not know what it means. > And so they are ignored and people ask about ways of turning off the warnings. > Plus over the years the algorithms used have drifted. > Plus it is driver specific. > What *is* the algorithm for checksums used by fontinst? > What *is* the algorithm for checksums used by AFM2TFM? > What does PCTeX use? Checksums for CMR fonts always have been working properly. A mismatch is an indication that your METAFONT source differs from the one used for generating the TFM file. For PS fonts Tom Rokicki has designed a similar algorithm which was in use till the `thirth' PS fonts generation. Unfortunately this algorithm used a left shift so that PS fonts derived from different AFM files could get the same checksum. That was the reason I have proposed a new algorithm based upon a cyclic shift. This algorithm is accepted by Karl in web2c derived software (afm2tfm) and fontinst. The last package via the CS utility (source available) I wrote for this purpose. I don't know what PCTeX uses. I have heard that they don't have implemented virtual fonts so perhaps they don't need checksums at all. Your question makes one thing very clear. There is no way the TeX community can garantee that a new standard gets implemented by all PD software and vendors. In the beginning we had something like TRIP and TRAP tests. But we don't have anything similar for DVI drivers and fonts. Perhaps we should make the above checksum algorithm part of the DVI driver standard? > I personally think that checksums can serve a much better purpose than > they do now: hide the encoding information there. This is critically > important since TFMs are encoding sensitive and if you have the wrong > TFM you are hosed and you can't tell from looking at this binary mess > what it is. This is even more important with drivers who (because they > do not produce resolution independent output) refer to TFM files. The current CS algorithm for TFM fonts derived from PS fonts is: unsigned long s1 = 0, s2 = 0; /* unsigned long! */ for (i=0; i<256; i++) { if (ev[i] == NULL) continue; s1 = ((s1<<1) ^ (s1>>31)) ^ width[i]; /* cyclic left shift */ for (p=ev[i]; *p; p++) s2 = s2 * 3 + *p ; } return (s1<<1) ^ s2 ; Here ev[i] contains a pointer to the character name of the current encoding and width[i] its corresponding WX value in the AFM file. So its is clear that a checksum depends upon (1) the encoding vector (2) the WX values from the AFM file for the characters selected through this encoding vector. People who use a different AFM file than the one used to generate the TFM file on CTAN can get `checksum mismatch' warnings. They have either to use the AFM files from CTAN or regenerate the TFM files with their AFM files. > Which is why AFMtoTFM hides the name of the encoding vector used to > generate the TFM in the checksum. Not only can you later decode this > to find out what the encoding vector was, but since this is passed > into the DVI file by TeX, it can be checked at the driver/previewer > level to see whether it matches what encoding *it* is set up for. > Solves many nightmarish debugging problems! Just as important as > having TeX announce on screen that there are `missing characters'. > > With the help of VERIFYCS (and cs) it should now be possible to trace > all incorrect and/or missing checksums. > > --Piet > > Berthold. > I don't understand what you mean by `hiding the encoding vector'. In the current implementation in TFM/VF fonts the checksum is a 32-bit number. So there is not much to hide. --Piet 21-Feb-1997 16:25:24-GMT,4798;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA23464 for ; Fri, 21 Feb 1997 09:25:22 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id LAA29080; Fri, 21 Feb 1997 11:25:17 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id LAA04849; Fri, 21 Feb 1997 11:25:11 -0500 (EST) Date: Fri, 21 Feb 1997 11:25:11 -0500 (EST) Message-Id: <199702211625.LAA04849@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: P.T.H.Tutelaers@urc.tue.nl CC: tex-fonts@math.utah.edu In-reply-to: <199702211530.QAA26419@asterix.urc.tue.nl> (message from Piet Tutelaers on Fri, 21 Feb 1997 16:30:26 +0100 (MET)) Subject: Re: 8r fonts Reply-to: bkph@ai.mit.edu From: Piet Tutelaers Checksums for CMR fonts always have been working properly. A mismatch is an indication that your METAFONT source differs from the one used for generating the TFM file. I wouldn't know since I don't use PK fonts. The current CS algorithm for TFM fonts derived from PS fonts is: unsigned long s1 = 0, s2 = 0; /* unsigned long! */ for (i=0; i<256; i++) { if (ev[i] == NULL) continue; s1 = ((s1<<1) ^ (s1>>31)) ^ width[i]; /* cyclic left shift */ for (p=ev[i]; *p; p++) s2 = s2 * 3 + *p ; } return (s1<<1) ^ s2 ; Here ev[i] contains a pointer to the character name of the current encoding and width[i] its corresponding WX value in the AFM file. Thank you. I see. (1) what happens if WX is non-integer (as it is in all CM, AMS etc fonts --- or at least if it isn't fractional then you do not have good fonts!)? So its is clear that a checksum depends upon (1) the encoding vector (2) the WX values from the AFM file for the characters selected through this encoding vector. People who use a different AFM file than the one used to generate the TFM file on CTAN can get `checksum mismatch' warnings. They have either to use the AFM files from CTAN or regenerate the TFM files with their AFM files. OK, but it seems that the AFM file (apparently already reencoded as defined by you above) itself is fully determined by the font and the encoding. Hence actually you only need the name of the encoding in the checksum to achieve the same effect. See below. > Your question makes one thing very clear. There is no way the TeX > community can garantee that a new standard gets implemented by all PD > software and vendors. In the beginning we had something like TRIP and > TRAP tests. But we don't have anything similar for DVI drivers and > fonts. Perhaps we should make the above checksum algorithm part of the > DVI driver standard? Please don't. Why freeze in methods appropriate mostly for older technology like PK fonts? > Which is why AFMtoTFM hides the name of the encoding vector used to > generate the TFM in the checksum. Not only can you later decode this > to find out what the encoding vector was, but since this is passed > into the DVI file by TeX, it can be checked at the driver/previewer > level to see whether it matches what encoding *it* is set up for. > Solves many nightmarish debugging problems! Just as important as > having TeX announce on screen that there are `missing characters'. I don't understand what you mean by `hiding the encoding vector'. In the current implementation in TFM/VF fonts the checksum is a 32-bit number. So there is not much to hide. Using mod 40 representation you can `hide' 6 characters (a-z 0-9 and some others). My idea is not so much to make the checksum unique (which is not important if you don't use PK files and don't use TFMs in the driver, instead using the font itself to supply metric information if it is needed). * The idea is to provide some information beyond the single bit: * checksums don't match - which means nothing to most people * (like debugging PS errors without ehandler.ps :=) * With the above encoding-name-hiding scheme, you can recover * the encoding vector and announce some meaningful message like: ERROR: encoding mismatch, your TFM file was made for `8r' encoding, but your printer driver is set up for `tex256' encoding. You can't do that with a complex hashing scheme for checksum. And a compelx hashing scheme should not be needed since the AFM file is fixed (should always have the same collection of char names and advance widths). True you can get only 6 characters, but then 32 bits is all TeX transfers form the TFM file into the DVI file... Regards, Berthold. 21-Feb-1997 16:34:24-GMT,3890;000000000000 Return-Path: Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.5]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA23673 for ; Fri, 21 Feb 1997 09:34:23 -0700 (MST) Received: from asterix.urc.tue.nl [131.155.5.10] by mailhost.tue.nl (8.8.5) id RAA00916 (ESMTP). Fri, 21 Feb 1997 17:34:18 +0100 (MET) Received: from rcpt@localhost by asterix.urc.tue.nl (8.8.5) id RAA29861. Fri, 21 Feb 1997 17:34:17 +0100 (MET) From: Piet Tutelaers Message-Id: <199702211634.RAA29861@asterix.urc.tue.nl> Subject: Re: 8r fonts To: tex-fonts@math.utah.edu (TeX fonts mailing list) Date: Fri, 21 Feb 1997 17:34:16 +0100 (MET) Cc: alanje@cogs.susx.ac.uk (Alan Jeffrey) In-Reply-To: from "Alan Jeffrey" at Feb 21, 97 12:40:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text > > Piet Tutelaers writes: > > In order to get a feeling for the effort needed to rewrite fontinst into > > PERL: > > (1) What exact role plays the .etx and .mtx files in the fontinst process? > > The .etx files describe the font encoding, and the .mtx files describe > the metrics, in a TeX-friendly format. Both of them make heavy use of > TeX's macro language to provide control structures such as > if-statements and commands. For example the command which defines an > `unfakable' glyph (a black box with a `missing glyph' special) is: > > \setcommand\unfakable#1{ > \setglyph{#1} > \ifisglyph{#1-not}\then > \moveup{\neg{\depth{#1-not}}} > \glyphrule{ > \width{#1-not} > }{ > \add{\depth{#1-not}}{\height{#1-not}} > } > \resetitalic{\italic{#1-not}} > \moveup{\depth{#1-not}} > \else > \glyphrule{500}{500} > \fi > \glyphwarning{missing glyph `#1'} > \endsetglyph > } PERL provides nice features for reading binary files (VF and TFM files) through pipes, for example: open(VF, "vftovp $vffontname $tfmfontname |"); while ( { "process next line of VPL file derived from VF"; } So reading the metrics for all characters in a TFM file (your .mtx) and the information in an encoding file (like 8r.enc) is not difficult. And with that information above function (it looks like it writes something to a PL and/or VPL file) seems no real problem. Macros do form real pitfalls for programmers. That is the reason C++ has abondoned them in favour of inline functions (whose use can be checked at compile time). In PERL you can write powerfull functions. But perhaps you can think of more difficult issues? > > Fontinst does have a published API for the syntax of commands like > \setcommand, \ifisglyph etc. etc. but writing a parser and interpreter > for it would effectively mean reinventing TeX's mouth. One of the > reasons why it's implemented in TeX in the first place is to make use > of the macro language. > > Fontinst itself is only ~2.5kLOC, but once you include all the .mtx > and .etx files which come with it it's ~12kLOC. Porting it would be a > major enterprise for not terribly much gain compared to using perl > scripts to postprocess fontinst output. > > Alan. > In my opinion the benefits are: (1) better understandability (2) as a consequence a better maintainability (3) no postprocessing needed to generate checksums (4) PERL can use all memory your computer has onboard (no fixed arrays like TeX). For most people TeX programming is like assembler programming. The abstraction level is very low. TeX was never ment to be a general purpose programming language. After all this propaganda for PERL I realise that writing PERL needs to be learned. That takes time (not that much as in TeX). If you decide to rewrite fontinst in PERL I am willing to help you with the design. --Piet 21-Feb-1997 17:21:20-GMT,3021;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA25226 for ; Fri, 21 Feb 1997 10:21:19 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id RAA12202 for ; Fri, 21 Feb 1997 17:19:28 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Fri, 21 Feb 1997 17:21:13 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id RAA20724; Fri, 21 Feb 1997 17:21:08 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id RAA16661; Fri, 21 Feb 1997 17:21:02 GMT Date: Fri, 21 Feb 1997 17:21:02 GMT Message-Id: <199702211721.RAA16661@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: P.T.H.Tutelaers@urc.tue.nl Cc: tex-fonts@math.utah.edu, alanje@cogs.susx.ac.uk Subject: Re: 8r fonts In-Reply-To: <199702211634.RAA29861@asterix.urc.tue.nl> References: <199702211634.RAA29861@asterix.urc.tue.nl> > PERL provides nice features for reading binary files (VF and TFM > files) through pipes, for example: not sure of the relevance. the vf and tfm files dont exist > So reading the metrics for all characters in a TFM file (your .mtx) and > the information in an encoding file (like 8r.enc) is not difficult. but thats not what the .etx and .mtx files are > Macros do > form real pitfalls for programmers. That is the reason C++ has > abondoned them in favour of inline functions (whose use can be checked > at compile time). In PERL you can write powerfull functions. hmm, better redo TeX in Perl as well then.... > But perhaps you can think of more difficult issues? yes, you havent addressed the issue! you have got to read and parse Alan's definition of a glyph in Perl > In my opinion the benefits are: > (1) better understandability > (2) as a consequence a better maintainability depends on who the reader is. > (3) no postprocessing needed to generate checksums true > (4) PERL can use all memory your computer has onboard (no fixed arrays like > TeX). dont let Berthold see this. Y&Y has dynamic memory, so do Textures. OzTeX and Web2c have config files to bump up memory. its not a problem. *speed* is the problem with fontinst > For most people TeX programming is like assembler programming. The > abstraction level is very low. TeX was never ment to be a general sadly true. but we all know TeX already > be learned. That takes time (not that much as in TeX). If you decide to > rewrite fontinst in PERL I am willing to help you with the design. but whats the incentive for Alan to take 3 months off his real work to do fontinst again? sebastian 22-Feb-1997 0:17:24-GMT,2918;000000000000 Return-Path: Received: from rsuna.crn.cogs.susx.ac.uk (root@rsuna.crn.cogs.susx.ac.uk [192.33.16.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id RAA05423 for ; Fri, 21 Feb 1997 17:17:21 -0700 (MST) Received: by rsuna.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0vy594-000003C; Sat, 22 Feb 97 00:16 GMT Message-Id: Date: Sat, 22 Feb 97 00:16 GMT From: Alan Jeffrey To: Piet Tutelaers Cc: tex-fonts@math.utah.edu (TeX fonts mailing list), alanje@cogs.susx.ac.uk (Alan Jeffrey) Subject: Re: 8r fonts In-Reply-To: <199702211634.RAA29861@asterix.urc.tue.nl> References: <199702211634.RAA29861@asterix.urc.tue.nl> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII Piet Tutelaers writes: > So reading the metrics for all characters in a TFM file (your .mtx) and > the information in an encoding file (like 8r.enc) is not difficult. An .mtx or .etx file contains a lot more information than a .tfm or .enc file, for example algorithms for faking glyphs or kern pairs. One of the important points of fontinst is that there's a published .mtx and .etx format, which (for better or worse) I promised that all future fontinst releases would be compatible with. > And with that information above function (it looks like it writes > something to a PL and/or VPL file) seems no real problem. Macros do > form real pitfalls for programmers. That is the reason C++ has > abondoned them in favour of inline functions (whose use can be checked > at compile time). In PERL you can write powerfull functions. I've published the file formats for .etx and .mtx files, and future versions will be upward compatible... in particular I'm not going to change from TeX syntax to Perl syntax. > In my opinion the benefits are: > (1) better understandability > (2) as a consequence a better maintainability > (3) no postprocessing needed to generate checksums > (4) PERL can use all memory your computer has onboard (no fixed arrays like > TeX). And add (5) runs in something like real time on a Sparc Ultra. But also: (1) There's 12kLOC to port. (2) There's 12kLOC to port. (3) There's 12kLOC to port. (4) There's 12kLOC to port. (5) The current version isn't broken, and any attempt to fix it will introduce more bugs than it will cure. > After all this propaganda for PERL I realise that writing PERL needs to > be learned. That takes time (not that much as in TeX). If you decide to > rewrite fontinst in PERL I am willing to help you with the design. If you want to do it, then go ahead, but this porting effort would take something like 3 months (fontinst is > 4 years old now) and I really don't see a big gain for the effort. Alan. 22-Feb-1997 15:12:07-GMT,3099;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id IAA22409 for ; Sat, 22 Feb 1997 08:12:06 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <14433-0@venus.open.ac.uk>; Sat, 22 Feb 1997 15:11:52 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id PAA14393; Sat, 22 Feb 1997 15:11:17 GMT Date: Sat, 22 Feb 1997 15:11:17 GMT Message-Id: <199702221511.PAA14393@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bkph@ai.mit.edu Cc: tex-font@math.utah.edu, "Martin J. Duerst" Subject: Re: Unicode and math symbols In-Reply-To: <199702131801.SAA00694@fell.> References: <199702101627.QAA15343@fell.open.ac.uk> <199702131801.SAA00694@fell.> I may have missed some messages as I had mail problems last week. Berthold wrote -- > My understanding of The Unicode Standard suggests that it is not > appropriate for encoding all mathematical notations. > > Then why did they bother at all :=) I think they changed their mind > at some point but then couldn't undo what was already there... > Quite right to, IMHO. > > (2) It is very spotty, picking some blackboard bold characters and not > others e.g. I looked at that set and, as mathematcian it was quite clear why only those BB characters are included. As a documemt processsor, I think that all such "alphabetic glyphs" should be handled via font-changes, not by defining new characters. Otherwise, you also need to put in all the blackletter glyphs (there are about 2 of these alrady there) all the bold glyphs, all the sans-serif glyphs etc etc. > Note: this is probably not the correct forum for discussing uses and > deficiencies of Unicode or math notation but it does contain several > people with an interest in these subjects. Trues, but how can we maintain their interest:-)? > (3) I know that UNICODE is not a glyph standard. Nevertheless it would > be extremely beneficial to future developments of mathematical typsetting > software if it could be used for all basic symbols. What does this benefit come from? Is it the association of every math symbol with a number? Or the standardisation of the name? > Yes I know you can't expect to do a `math extension' font that way, > but certainly, italic, symbols, arrows, blackboard bold, what is in > MSAM and MSBM etc. But if you need to use Unicode as a standard for glyphs, then you should put in the math-extension charcaters too. One big problem with discussing this is that Unicode contains such a lot of rubbish, eg box-drawing glyphs, so it is always possible to argue for putting more in. So we should, perhaps, first look at how math should be coded for exchange, storage, searching etc (all of whch are the concern of Unicode) before trying to make Unicode into a pseudo-glyph-registry. chris 24-Feb-1997 7:20:28-GMT,1573;000000000000 Return-Path: Received: from mail.danbbs.dk (root@mail.danbbs.dk [194.255.36.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id AAA06821 for ; Mon, 24 Feb 1997 00:20:26 -0700 (MST) Received: from lars (local43.danbbs.dk [194.255.36.43]) by mail.danbbs.dk (8.8.5/8.7.3) with SMTP id IAA09140; Mon, 24 Feb 1997 08:26:48 +0100 Message-ID: <33115CAC.591E@danbbs.dk> Date: Mon, 24 Feb 1997 08:17:32 -0100 From: Lars Otto Reply-To: lars@dina.kvl.dk X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Piet Tutelaers CC: TeX fonts mailing list Subject: Re: 8r fonts References: <199702211634.RAA29861@asterix.urc.tue.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Piet Tutelaers writes: > > ... > > After all this propaganda for PERL I realise that writing PERL needs to > > be learned. That takes time (not that much as in TeX). If you decide to > > rewrite fontinst in PERL I am willing to help you with the design. > > If you want to do it, then go ahead, but this porting effort would > take something like 3 months (fontinst is > 4 years old now) and I > really don't see a big gain for the effort. > I anyone recodes this into PERL please remember that use of process operations does not work that well under DOS/Windows. And that the .bat file is more of a joke compared to UNIX shell-script Lars Otto 24-Feb-1997 12:03:11-GMT,2441;000000000000 Return-Path: Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id FAA11718 for ; Mon, 24 Feb 1997 05:03:09 -0700 (MST) Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <04461-0@josef.ifi.unizh.ch>; Mon, 24 Feb 1997 13:03:26 +0100 Date: Mon, 24 Feb 1997 13:03:25 +0100 (MET) From: "Martin J. Duerst" Sender: mduerst@enoshima To: Chris Rowley cc: bkph@ai.mit.edu, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199702221511.PAA14393@fell.open.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 22 Feb 1997, Chris Rowley wrote: > One big problem with discussing this is that Unicode contains such a > lot of rubbish, eg box-drawing glyphs, so it is always possible to > argue for putting more in. The "rubish" parts are usually due to backwards compatibility issues. I.e. there is some national standard or some industry or company encoding that contains these things. In general, I agree with Chris that for systematic form changes in the alphabet, additional information (such as font information on a lower level, or structural information on a higher level) should be used. On the other hand, if there is a well-used Math symbol that isn't in UNicode, I would suggest to make a formal proposal for putting it in, with all the necessary data. One thing not really clear in the Math area is the distinction between semantics and abstract form. For example, should there be one codepoint for "set difference", and this could look like "-" or like "\" or whatever, depending on the font (and maybe other setting), while there is another "-" for subtraction, one for hyphen, and so on, or should there be one and the same "-" for various purposes, and one and the same "\" for various purposes, and the slight differences in shape, size, and placement be dealt with depending on circumstances (e.g. Math or not). I guess we certainly need some amount of both (the later e.g. to distinguish between a hyphen and a dash), but in general, on the level of character encoding, it's easier for most people to deal with "one shape, one code", and so that will probably prevail in the long run. Regards, Martin. 24-Feb-1997 14:03:42-GMT,2936;000000000000 Return-Path: Received: from math.ams.org (MATH.AMS.ORG [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id HAA14093 for ; Mon, 24 Feb 1997 07:03:41 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 24 Feb 1997 14:03:39 UT Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V5.1-6 #16534) id <01IFSCBJIK4W0004RO@AXP14.AMS.ORG> for tex-font@math.utah.edu; Mon, 24 Feb 1997 09:03:22 EST Date: Mon, 24 Feb 1997 09:03:21 -0500 (EST) From: bbeeton Subject: Re: Unicode and math symbols In-reply-to: To: "Martin J. Duerst" Cc: Chris Rowley , bkph@ai.mit.edu, tex-font@math.utah.edu Message-id: <856793001.783019.BNB@MATH.AMS.ORG> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Mail-system-version: unicode (and other codes) deal with *meaning*, not form. there is a separate font/glyph standard, and a glyph registry for dealing with form; essentially all the math symbols associated with tex from computer modern, the ams extra symbol fonts, and the latex fonts are registered (i was involved, and i checked carefully). by "essentially", i mean that all "singular" symbols are included -- the pieces that make up a pieced brace, or the various sizes of radical signs -- and that includes separate and distinct text-class and display-class sums and integrals because of their differing treatment in those two environments. also, when the same shape can appear both as an ordinary symbol and as a relation, there are two different glyphs registered; the justification i used was that the side bearings are different, since a difference in meaning wasn't permitted. unicode does not at present incorporate all the distinct symbols that have been registered as glyphs. whether it should or not, i have still (after many years) not made up my mind; unicode is not, and never will be, suited to carry along anything but the basic identification -- any knowledge about positioning, relation to embellishments or adjacent symbols, etc., etc., is simply outside its scope, and therefore inclusion of something like an extensible radical sign must be by definition overly simplistic. on the other hand, all the symbols that have been registered as glyphs have also been included in the sgml public entity sets, where there is at least a chance of carrying along this extra baggage. i'm firmly against "one shape, one code"; without a lot of extra information provided in a non-code manner, it will never yield publishable math, and it's unclear to me that it will be intelligible either, in the sense required for systems that must be rendered in other than visual form. -- barbara beeton 24-Feb-1997 16:19:52-GMT,3967;000000000000 Return-Path: Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.5]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA17067 for ; Mon, 24 Feb 1997 09:19:44 -0700 (MST) Received: from asterix.urc.tue.nl [131.155.5.10] by mailhost.tue.nl (8.8.5) for id RAA03196 (ESMTP). Mon, 24 Feb 1997 17:19:37 +0100 (MET) Received: from rcpt@localhost by asterix.urc.tue.nl (8.8.5) for tex-fonts@math.utah.edu id RAA17752. Mon, 24 Feb 1997 17:19:35 +0100 (MET) From: Piet Tutelaers Message-Id: <199702241619.RAA17752@asterix.urc.tue.nl> Subject: Checksums (was re: 8r fonts) To: tex-fonts@math.utah.edu (TeX fonts mailing list) Date: Mon, 24 Feb 1997 17:19:35 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Here a reaction to some checksum issues: > Berthold: > (1) what happens if WX is non-integer (as it is in all CM, AMS etc fonts > --- or at least if it isn't fractional then you do not have good > fonts!)? Non-integers are currently *not* supported. They were not foreseen by Tom Rokicki. Perhaps Berthold wants to learn us why we need them "uberhaupt? According to the ``Adobe Font Metrics File Format Specification'' (version 4.0 / 14 feb 1992) WX values can be numbers (pp 26). Numbers are defined as (pp 6) as Numbers can be either a real number or an integer, and signed or unsigned, that is, it may or may not contain a decimal point or a leading minus sign. How do we generate checksums for non-integer WX values? Preferable in such a way that the current values still are valid. And let us keep in mind what the original idea of the checksum was (TeX the program, pp 217) header[0] (part of a TFM file, added Piet) is a 32-bit check sum that TeX will copy into the DVI output file. Later on when the DVI file is printed, possible on another computer, the actual font that gets used is supposed to have a check sum that agrees with the one in the TFM file used by TeX. In this way, users will be warned about possible incompatibilities. (However, if the the check sum is zero in either the font file or the TFM file, no check is made.) The actal relation between this check sum and the rest of the TFM file is not important; the check sum is simply an identification number with the property that incompatible fonts almost always have distinct sums. > Berthold: > Using mod 40 representation you can `hide' 6 characters (a-z 0-9 and > some others). My idea is not so much to make the checksum unique > (which is not important if you don't use PK files and don't use > TFMs in the driver, instead using the font itself to supply metric > information if it is needed). I don't see how your implementation of check sums can fullfill the requirements as explained above. > * The idea is to provide some information beyond the single bit: > * checksums don't match - which means nothing to most people > * (like debugging PS errors without ehandler.ps :=) > > * With the above encoding-name-hiding scheme, you can recover > * the encoding vector and announce some meaningful message like: > > ERROR: encoding mismatch, your TFM file was made for `8r' > encoding, but your printer driver is set up for `tex256' encoding. Pierre MacKay has proposed a special for PK fonts generated from PS fonts which can help to debug font incompatibilty problems. For example: 27828: Special: 'ps2pk options: -R600 -O -e8r.enc -E.82 -X72 0 -Y864' 27880: Special: 'fontid=Utopia-Regular' 27903: Special: 'codingscheme=TeXBase1Encoding' 27934: Special: 'fontfacebyte' 27948: Num special: 15335424 27953: Special: 'pixels_per_inch=600' 27974: Special: 'mag=magstep(1.0)' 27992: Special: 'aspect ratio=720 / 600' 28016: Postamble Let us make *one* standard checksum algorithm for PS fonts! --Piet 24-Feb-1997 16:22:12-GMT,2132;000000000000 Return-Path: Received: from mailhost.tue.nl (mailhost.tue.nl [131.155.2.5]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA17128 for ; Mon, 24 Feb 1997 09:22:11 -0700 (MST) Received: from asterix.urc.tue.nl [131.155.5.10] by mailhost.tue.nl (8.8.5) for id RAA03278 (ESMTP). Mon, 24 Feb 1997 17:22:08 +0100 (MET) Received: from rcpt@localhost by asterix.urc.tue.nl (8.8.5) for tex-fonts@math.utah.edu id RAA17892. Mon, 24 Feb 1997 17:22:07 +0100 (MET) From: Piet Tutelaers Message-Id: <199702241622.RAA17892@asterix.urc.tue.nl> Subject: Improving fontinst (was re: 8r fonts) To: tex-fonts@math.utah.edu (TeX fonts mailing list) Date: Mon, 24 Feb 1997 17:22:07 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Thanks to the reactions to the threath I started about rewriting fontinst into PERL I have I now have a vague feeling about the amount of work that needs to be done. If porting is worth the effort will also depend on what the future of PS fonts will bring us. Will the PS fonts ever stabilize or do we expect many changes? At the moment fontinst it is a hybrid package consisting of TeX code (generating PL and VPL files), PERL code (checksums), C-code (cs utility) tied together via Makefile's. My greatest concern is the fact that its use and maintenance is very tedious and error prone. Also for the people who wrote it. Culminating in beta-releases with missing ligatures and incorrect or missing checksums. Whenever Alan and Sebastian, who is already using PERL instead of UNIX shell scripts in parts of the process, want to port fontinst to PERL I want to help. Not by painfully studying and converting TeX code into PERL code. But by starting from scratch with the main program structure that we need in order to generate PS fonts with correct check sums. And for that part I need his knowledge about the total process. I can bring in some experience with PERL and checksums. Let us hope the best for fontinst and the fonts created with it! --Piet 24-Feb-1997 17:06:35-GMT,1479;000000000000 Return-Path: Received: from csrj.crn.cogs.susx.ac.uk (csrj.crn.cogs.susx.ac.uk [192.33.16.212]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id KAA18266 for ; Mon, 24 Feb 1997 10:06:26 -0700 (MST) Received: by csrj.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0vz3qC-0000ZpC; Mon, 24 Feb 97 17:05 GMT Message-Id: Date: Mon, 24 Feb 97 17:05 GMT From: Alan Jeffrey To: Piet Tutelaers Cc: tex-fonts@math.utah.edu (TeX fonts mailing list) Subject: Checksums (was re: 8r fonts) In-Reply-To: <199702241619.RAA17752@asterix.urc.tue.nl> References: <199702241619.RAA17752@asterix.urc.tue.nl> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII Piet Tutelaers writes: > > (1) what happens if WX is non-integer (as it is in all CM, AMS etc fonts > > --- or at least if it isn't fractional then you do not have good > > fonts!)? > > Non-integers are currently *not* supported. They were not foreseen by Tom > Rokicki. Perhaps Berthold wants to learn us why we need them "uberhaupt? Fontinst supports them, but only by brute force truncation after the decimal point. They were introduced by Adobe at the same time as MM fonts, and I suspect that that's not a coincidence! MM AFMs are generated by interpolating, so it's not surprising you need non-integer AFM values. Alan. 24-Feb-1997 18:33:36-GMT,1342;000000000000 Return-Path: Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id LAA20548 for ; Mon, 24 Feb 1997 11:33:34 -0700 (MST) Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <14836-0@josef.ifi.unizh.ch>; Mon, 24 Feb 1997 19:33:55 +0100 Date: Mon, 24 Feb 1997 19:33:54 +0100 (MET) From: "Martin J. Duerst" Sender: mduerst@enoshima To: bbeeton cc: Chris Rowley , bkph@ai.mit.edu, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <856793001.783019.BNB@MATH.AMS.ORG> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 24 Feb 1997, barbara beeton wrote: > unicode (and other codes) deal with *meaning*, not form. Please note that for one area where you would assume that dealing with "meaning" would be especially easy, the character/glyph model that is the general base of Unicode/ISO 10646 had to be changed somewhat (to come closer to "glyph" than for other scripts) to accomodate for present practice and user expectations. Similar things may apply to math (or may not apply). Regards, Martin. 24-Feb-1997 19:11:54-GMT,1531;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id MAA21551 for ; Mon, 24 Feb 1997 12:11:50 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <18020-0@venus.open.ac.uk>; Mon, 24 Feb 1997 19:10:58 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id TAA16690; Mon, 24 Feb 1997 19:10:17 GMT Date: Mon, 24 Feb 1997 19:10:17 GMT Message-Id: <199702241910.TAA16690@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Martin J. Duerst" Cc: bbeeton , bkph@ai.mit.edu, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: References: <856793001.783019.BNB@MATH.AMS.ORG> Martin > > Please note that for one area where you would assume that > dealing with "meaning" would be especially easy, the > character/glyph model that is the general base of > Unicode/ISO 10646 had to be changed somewhat (to > come closer to "glyph" than for other scripts) to > accomodate for present practice and user expectations. Sounds interesting: to what do you refer? > Similar things may apply to math (or may not apply). Indeed: See next message:-). chris 24-Feb-1997 19:13:38-GMT,6135;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id MAA21614 for ; Mon, 24 Feb 1997 12:13:36 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <18147-0@venus.open.ac.uk>; Mon, 24 Feb 1997 19:13:12 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id TAA16698; Mon, 24 Feb 1997 19:12:31 GMT Date: Mon, 24 Feb 1997 19:12:31 GMT Message-Id: <199702241912.TAA16698@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Martin J. Duerst" Cc: bkph@ai.mit.edu, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: References: <199702221511.PAA14393@fell.open.ac.uk> Martin wrote -- > > The "rubish" parts are usually due to backwards compatibility issues. > I.e. there is some national standard or some industry or company > encoding that contains these things. Which may well also explain why the set of math symbols is so bizarre. > In general, I agree with Chris that for systematic form changes > in the alphabet, additional information (such as font information > on a lower level, or structural information on a higher level) > should be used. On the other hand, if there is a well-used > Math symbol that isn't in UNicode, I would suggest to make > a formal proposal for putting it in, with all the necessary > data. What makes it well-used;? If you look at something like formal methods or logic, you find all sorts of symbols and the number increases rapidly: are these "well-used"? are they "maths"? The general problem is that mathematical notation is by its nature not standardised, in either form or meaning. > One thing not really clear in the Math area is the distinction > between semantics and abstract form. And also the relationship between them. Please do not let Unicode become caught up in the problem of expressing the semantics of mathematical notation. The only semantics that Unicode gives to 0061 is a standard name and the fact that most people expect something with that name to look like "a" or "the rounder form used in some fonts"; it does not say that "when used in English as the only letter in a word it is the definite article", nor should it. So please leave the meaning of math symbols (which is also highly context-dependent) to the mathematical reader. Another reason for keeping such discussions out of the Unicode area right now is that a lot of effort is going into decding what can and should be standardised at the DTD level (in particular HTML-math). I think that this fits in with bb's comment that there are standard SGML public-entities for math notation and with the way users are used to encoding maths: at least for the moment it should be the only place where we try to standardise any sort of semantics. One reason for this is that the natural structure of even quite simple typeset maths is visually much more complex than the Unicode model (for Latin-based systems) of "base+diacritics" and it is not closely related to the more complex visual structure of other writing systems. It may well be possible to extend Unicode to cope with this but again this woul only cover some math notation, never all of it, so it does not seem to me to be a worthwhile activity, at least not right now. > For example, should there > be one codepoint for "set difference", and this could look > like "-" or like "\" or whatever, depending on the font (and > maybe other setting), No, that is not a font-dependent thing (at least I would shoot any editor who decide it was:-). I can also easily find places where both would be needed (for very similar operations that had to be distinguished in a certain context) or inded 3 or more similar things (at some stage one would stop using different symbols and instead use (TeX notaion): \mathbin{\setminus_n} ...in other words, I think that this is the wrong question. > while there is another "-" for subtraction, > one for hyphen, and so on, or should there be one and the same > "-" for various purposes, and one and the same "\" for various > purposes, and the slight differences in shape, size, and placement > be dealt with depending on circumstances (e.g. Math or not). This is a much better question: one reason is that I suspect that "minus" needs to be used in places that really do not require to be labelled "language=math" (but some would argue with this). And if something that should look like a minus sign is used outside math then it would be a great blessing if the right symbol was used. Within maths, based on my opinion above, I think that the canonical form should be an SGML entity called "minus" (or possibly two: one called "unary-minus" and one called "binary-minus", but not one called "set-minus"; and here we get dangerously close to the question: how much of the mathematical semantics should/can be encoded at any level). This would not preclude a unicode character called "minus" appearing within math, but it means that when it appears there it is a short-form for an entity (in the abstract model, I am not saying that SGML's contorted syntax will allow this). > I guess we certainly need some amount of both (the later e.g. > to distinguish between a hyphen and a dash), but in general, > on the level of character encoding, it's easier for most > people to deal with "one shape, one code", and so that will > probably prevail in the long run. How much longer must a dash become before its shape changes?:-) Yes, I agree with you: let pragmatism rule; which is why I asked some time ago (maybe I missed the answer?): What are the practical benefits of having some set of mathemtical symbols in Unicode? Is it the canonical name that is important? Or assigning a standard code-value to that name, or both? chris 24-Feb-1997 19:55:20-GMT,1683;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id MAA22592 for ; Mon, 24 Feb 1997 12:55:14 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <19782-0@venus.open.ac.uk>; Mon, 24 Feb 1997 19:54:51 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id TAA16752; Mon, 24 Feb 1997 19:54:11 GMT Date: Mon, 24 Feb 1997 19:54:11 GMT Message-Id: <199702241954.TAA16752@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bkph@ai.mit.edu Cc: tex-font@math.utah.edu Subject: composite characters and dotless ones In-Reply-To: <199702041652.LAA15035@kauai.ai.mit.edu> References: <199702041652.LAA15035@kauai.ai.mit.edu> I am not sure if I mentioned this before, but in Unicode the canonical decomposition of, for example is + not . Indeed, page 6-7 explicitly states that these combinations give two distinct characters. Further, it states that in cases where the dot is preserved and the diacritic is added above the dot, the decomposition is as a double diacritic: + hmmmm. Such decomposition is necessary and for many purposes the canonical Unicode one is the only correct one; its being "wrong" for making a composite glyph is, of course, irrelevant to Unicode itself (but not to typesetting applications that process Unicode documents). chris 25-Feb-1997 11:04:09-GMT,2380;000000000000 Return-Path: Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id EAA12652 for ; Tue, 25 Feb 1997 04:04:08 -0700 (MST) Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <01115-0@josef.ifi.unizh.ch>; Tue, 25 Feb 1997 12:04:14 +0100 Date: Tue, 25 Feb 1997 12:04:13 +0100 (MET) From: "Martin J. Duerst" Sender: mduerst@enoshima Reply-To: "Martin J. Duerst" To: Chris Rowley cc: bbeeton , bkph@ai.mit.edu, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199702241910.TAA16690@fell.open.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 24 Feb 1997, Chris Rowley wrote: > Martin > > > > > Please note that for one area where you would assume that > > dealing with "meaning" would be especially easy, the > > character/glyph model that is the general base of > > Unicode/ISO 10646 had to be changed somewhat (to > > come closer to "glyph" than for other scripts) to > > accomodate for present practice and user expectations. > > Sounds interesting: to what do you refer? Well, there is a draft for an explanation of the character/ glyph model with respect to CJK, which will probably become an informative annex to 10646. The main point where "shape" is preferred over "meaning" is where characters have been simplified so much as to lead to totally different shapes that cannot easily be identified, and where simplifications have lead to merging of several originally different characters. In both cases, "simulating paper" in the sense that there are different codepoints for the major shape differences is the better solution, because users mostly are not aware anymore e.g. about originally differentiated characters. > > Similar things may apply to math (or may not apply). > > Indeed: See next message:-). The "may not apply" refers to the fact that for the same symbol shape, simbolic operations and such might differ depending on the semantics. For CJK, this is not an issue, it is equally difficult to do reasoning on Chinese or Japanese texts as it is for English and such. Regards, Martin. 25-Feb-1997 11:14:36-GMT,4330;000000000000 Return-Path: Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id EAA12855 for ; Tue, 25 Feb 1997 04:14:33 -0700 (MST) Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <01859-0@josef.ifi.unizh.ch>; Tue, 25 Feb 1997 12:14:50 +0100 Date: Tue, 25 Feb 1997 12:14:49 +0100 (MET) From: "Martin J. Duerst" Sender: mduerst@enoshima To: Chris Rowley cc: bkph@ai.mit.edu, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199702241912.TAA16698@fell.open.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello Chris, On Mon, 24 Feb 1997, you wrote: > Martin wrote -- > > In general, I agree with Chris that for systematic form changes > > in the alphabet, additional information (such as font information > > on a lower level, or structural information on a higher level) > > should be used. On the other hand, if there is a well-used > > Math symbol that isn't in UNicode, I would suggest to make > > a formal proposal for putting it in, with all the necessary > > data. > > What makes it well-used;? If you look at something like formal methods > or logic, you find all sorts of symbols and the number increases > rapidly: are these "well-used"? are they "maths"? > > The general problem is that mathematical notation is by its nature > not standardised, in either form or meaning. Well, what was in TeX, at a certain stage, got accepted as "well-used". If you can come up with textbooks, journal articles, reccomendations from some standard bodies,... (e.g. Z), then you should have a strong case. > > One thing not really clear in the Math area is the distinction > > between semantics and abstract form. > > And also the relationship between them. > > Please do not let Unicode become caught up in the problem of > expressing the semantics of mathematical notation. > > The only semantics that Unicode gives to 0061 is a standard name and > the fact that most people expect something with that name to look like > "a" or "the rounder form used in some fonts"; it does not say that > "when used in English as the only letter in a word it is the definite > article", nor should it. > > So please leave the meaning of math symbols (which is also highly > context-dependent) to the mathematical reader. > > Another reason for keeping such discussions out of the Unicode area > right now is that a lot of effort is going into decding what can and > should be standardised at the DTD level (in particular HTML-math). > > I think that this fits in with bb's comment that there are standard > SGML public-entities for math notation and with the way users are used > to encoding maths: at least for the moment it should be the only place > where we try to standardise any sort of semantics. I agree very much with you. However, I read Barbara's comments as to that she wants to be closer to semantics than we would. > One reason for this is that the natural structure of even quite simple > typeset maths is visually much more complex than the Unicode model > (for Latin-based systems) of "base+diacritics" and it is not closely > related to the more complex visual structure of other writing systems. If you mean *text* writing systems, then they all use lines/columns. Many of them have some more complicated structure on a micro-level (i.e. Tibetan stacks, ligatures, diacritics,...) which Unicode deals case-by-case (you need separate rendering logic for each of the more complicated scripts, or a very general mechanism). If you mean other symbolic writing systems, such as mathematical notation and musical notation, then you are right. Unicode is not designed for them nor plans to address these. > What are the practical benefits of having some set of mathemtical > symbols in Unicode? Is it the canonical name that is important? > Or assigning a standard code-value to that name, or both? The practical value may be that you can use such symbols in text. You won't be able to write nice formulae, but you will be able to write formulae with lots of parentheses. Regards, Martin. 25-Feb-1997 12:22:01-GMT,5067;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id FAA14107 for ; Tue, 25 Feb 1997 05:21:51 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <29513-0@venus.open.ac.uk>; Tue, 25 Feb 1997 12:20:25 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id MAA17383; Tue, 25 Feb 1997 12:19:44 GMT Date: Tue, 25 Feb 1997 12:19:44 GMT Message-Id: <199702251219.MAA17383@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Martin J. Duerst" Cc: bkph@ai.mit.edu, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: References: <199702241912.TAA16698@fell.open.ac.uk> Martin > > Well, what was in TeX, at a certain stage, got accepted as > "well-used". If you can come up with textbooks, journal articles, > reccomendations from some standard bodies,... (e.g. Z), then > you should have a strong case. This seems to me to imply that some mathematical body has to police what people are using and make cases as the notation changes. But why? I have seen no arguments that I could put to the IMU or national organisations to convince them that this is a sensible activity. And I would certainly not tell authors and editors that they should not use a new symbol because it is not in Unicode. This is, as I see it, completely different from TeX or SGML where it is easy to declare a new bit of notation; all you need to do is say what its name is (and give some method of typesetting an approximation to it if that is important). This may well result after some time in this notation becoming common enough that typesetters/publishers see a need for it becoming something to add to the glyph registry; but that need not involve mathematicians at all. > > I agree very much with you. However, I read Barbara's comments > as to that she wants to be closer to semantics than we would. But it seems that, eg Berthold and Richard (Kinch) do not: and they are at the coal face (running the mine even?) so we need to know why. I too was puzzled by what Barbara meant by "meaning" in the context of math symbols. > > > One reason for this is that the natural structure of even quite simple > > typeset maths is visually much more complex than the Unicode model > > (for Latin-based systems) of "base+diacritics" and it is not closely > > related to the more complex visual structure of other writing systems. > > If you mean *text* writing systems, then they all use lines/columns. > Many of them have some more complicated structure on a micro-level > (i.e. Tibetan stacks, ligatures, diacritics,...) which Unicode > deals case-by-case (you need separate rendering logic for each of the > more complicated scripts, or a very general mechanism). Yes, that is what I mean: some of these local mechanisms seem to me to be similar (some in nature, others in complexity) to those needed in math typestting. So here I was just pointing out to bb that it would be technically possible to include "simple math typestting" within this paradigm; I hope I made it clear that I was not suggesting that this should be done. > If you mean other symbolic writing systems, such as mathematical > notation and musical notation, then you are right. Unicode is > not designed for them nor plans to address these. The "local mechanisms" for music are more complex than "simple math typesetting", as are some parts of maths (eg commutative diagrams) and structural formulas. But music is perhaps a good analogy: Unicode does not even try to contain all "well-used musical characters" as it easily could do. So why should it try to do so for maths? > The practical value may be that you can use such symbols in > text. You won't be able to write nice formulae, but you will > be able to write formulae with lots of parentheses. That is a reason, but the number of symbols one might want to use in this way (ie outside what is, or should be within "language=math-notation" elements) is probably far smaller than what is already there. My example of the minus sign is probably a good paradigm here; ie something that needs to be clearly distinguished from similar characters and allows simple things like "-5" to appear as text and be rendered usefully and sensibly without using a math-formatting engine [Also, as you say, it can already be encased in any number of amazing "parenthetical symbols" (many of which I have never heard of before [but which do include one that I claim is very well-used but is not in the AMS repertoire: the "open-face bracket" (probably not the Unicode name but it is there, [in TeX-speak it might be called a double-bracket or even a Blackboard-bold bracket \Bbbrack])]).] chris 25-Feb-1997 13:57:11-GMT,5516;000000000000 Return-Path: Received: from math.ams.org (MATH.AMS.ORG [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id GAA15818 for ; Tue, 25 Feb 1997 06:57:10 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 25 Feb 1997 13:57:08 UT Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V5.1-6 #16534) id <01IFTQLJOAAO000C7P@AXP14.AMS.ORG> for tex-font@math.utah.edu; Tue, 25 Feb 1997 08:56:31 EST Date: Tue, 25 Feb 1997 08:56:30 -0500 (EST) From: bbeeton Subject: Re: Unicode and math symbols In-reply-to: <199702251219.MAA17383@fell.open.ac.uk> To: Chris Rowley Cc: "Martin J. Duerst" , bkph@ai.mit.edu, tex-font@math.utah.edu Message-id: <856878990.798001.BNB@MATH.AMS.ORG> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Mail-system-version: martin: > I agree very much with you. However, I read Barbara's comments > as to that she wants to be closer to semantics than we would. chris: I too was puzzled by what Barbara meant by "meaning" in the context of math symbols. here's the context in which i used "meaning". unicode (and other codes) deal with *meaning*, not form. unfortunately, someone has borrowed my (partial) copy of iso 10646, so i can't check to see how the columns are labeled. but what i meant here is the words that get put into the description column. ... also, when the same shape can appear both as an ordinary symbol and as a relation, there are two different glyphs registered; the justification i used was that the side bearings are different, since a difference in meaning wasn't permitted. same here, except the column in the glyph registry is headed "glyph name or description". a pure shape description isn't adequate (although that's often what's present); this also gets into usage and (minimally) presentation context. here are several out-of-context quotes from an early version of the draft character-glyph model generated by members of the u.s. technical committees x3v1 (counterpart of international sc18/wg8) and x3l2 (international sc2/wg2). these show the association i have with the meaning of "meaning". From a historical perspective, few differences have been traditionally attributed to the notions of "character" and "glyph". If used at all, the term "glyph" was associated with "the" visual image of a "character". Most frequently, the term "character" has been (and still is) used to refer to both a unit of information and a visual shape associated with that unit of information. -------------------- Consider for a moment the case with the unit of information meaning "one". In ISO/IEC 10646 not only are there a large number of characters which conceivably "represent" this "unit of information", but there are also a number of "characters" which represent a particular form associated with this meaning, i.e., the Arabic digit <1> form itself. -------------------- In specifying characters for inclusion in a character set standard, SC2 normally has recourse to the meaning of a character, and, in particular, has the option of unifying two or more forms if it is determined that those forms do not represent distinctions in meaning within a particular written language, or that the forms represent merely stylistic differences. On the other hand, the glyph registration authority of ISO/IEC 10036 does not have recourse to such an analysis, and must, if so requested, register all elements of any font so that a unique identification for all glyph representations within a font is possible. ... If there is a set of criteria for distinguishing among two glyphs, it cannot be based on distinctions in meaning, but distinctions of form. -------------------- 1. A character conveys distinctions in meaning. A character has no intrinsic appearance. 2. A glyph conveys distinctions in form. A glyph has no intrinsic meaning. 3. One or more characters may be depicted by one or more glyph representations (instances of an abstract glyph) in a possibly context dependent fashion. This last point spells out the possible relationship between characters and glyph representations. In its fully general form, this relationship is a context sensitive M to N mapping, M>0, N>0. In practice, because ISO/IEC 10646 contains "glyph-like" characters, it is expected that implementations may choose to "canonicalize" or "normalize" such characters by translating them to normative characters. A display subsystem which employs such a technique may require character data be normalized prior to display. 5.1 - Processing Domains: Content and Appearance Two primary processing domains may be applied to character information. The first pertains to the processing of the content, or meaning of the information; and, the second, to the presentation or imaging of the content. (this draft was dated september 1993, and i was part of the joint committee that drafted it. i should also note that it has changed a great deal since then, and i haven't seen the most recent versions.) sorry, i should have been more precise. -- bb 25-Feb-1997 14:35:32-GMT,2542;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id HAA16615 for ; Tue, 25 Feb 1997 07:35:29 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <10365-0@venus.open.ac.uk>; Tue, 25 Feb 1997 14:35:02 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id OAA17544; Tue, 25 Feb 1997 14:34:23 GMT Date: Tue, 25 Feb 1997 14:34:23 GMT Message-Id: <199702251434.OAA17544@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bbeeton Cc: "Martin J. Duerst" , bkph@ai.mit.edu, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <856878990.798001.BNB@MATH.AMS.ORG> References: <199702251219.MAA17383@fell.open.ac.uk> <856878990.798001.BNB@MATH.AMS.ORG> Barbara wrote (or quoted)-- > the term "character" has been (and still is) used to refer to > both a unit of information and a visual shape associated with > that unit of information. For latin/cyrrilic wrting systems, at least, this makes sense to me and encapsulates much of what is in the Unicode book; but i think it may be that in some areas (outsiide text) too much emphasis is placed on being precise about the visual shape (thus it would perhaps have been better to say ".. and a collection of interchangable visual shapes associated ...". Note that it does not say that every unit of information should correspond to a single character (and thus to a Unicode slot). Nor does it say that every glyph is the visual realisation of a single unit of information; this is perhaps relevant to where I would disagree with those who wish to put all math symbols into Unicode sots. > 1. A character conveys distinctions in meaning. A character has no > intrinsic appearance. > > 2. A glyph conveys distinctions in form. A glyph has no > intrinsic meaning. My epistemological level is nowhere near accomodating beasts such as these in its zoo. It conjures up in my mind the idea that we should communicate by muttering sequences of deeply meaningful 16-bit number rather than writng meaningless glyphs or uttering meaningless sounds; why not just code everything by using the Goedel number of each statement? Thanks for the enlightenment, Barbara chris 25-Feb-1997 15:08:49-GMT,2978;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA17392 for ; Tue, 25 Feb 1997 08:08:49 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id KAA11030; Tue, 25 Feb 1997 10:08:45 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA06443; Tue, 25 Feb 1997 10:08:39 -0500 (EST) Date: Tue, 25 Feb 1997 10:08:39 -0500 (EST) Message-Id: <199702251508.KAA06443@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: P.T.H.Tutelaers@urc.tue.nl CC: tex-fonts@math.utah.edu In-reply-to: <199702241619.RAA17752@asterix.urc.tue.nl> (message from Piet Tutelaers on Mon, 24 Feb 1997 17:19:35 +0100 (MET)) Subject: Re: Checksums (was re: 8r fonts) Reply-to: bkph@ai.mit.edu > Berthold: > Using mod 40 representation you can `hide' 6 characters (a-z 0-9 and > some others). My idea is not so much to make the checksum unique > (which is not important if you don't use PK files and don't use > TFMs in the driver, instead using the font itself to supply metric > information if it is needed). I don't see how your implementation of check sums can fullfill the requirements as explained above. It does. You code as many characters as possible (namely 6) into the checksum. Obviously you can't stick in the full encoding vector, because there is an infinite number possible. So some naming of vector files has to be agreed upon. The key part is not that it is unique, but that it is *decodable*. > * The idea is to provide some information beyond the single bit: > * checksums don't match - which means nothing to most people > * (like debugging PS errors without ehandler.ps :=) > * With the above encoding-name-hiding scheme, you can recover > * the encoding vector and announce some meaningful message like: > ERROR: encoding mismatch, your TFM file was made for `8r' > encoding, but your printer driver is set up for `tex256' encoding. Pierre MacKay has proposed a special for PK fonts generated from PS fonts which can help to debug font incompatibilty problems. Nice, but who cares anbout PK fonts :=) Let us make *one* standard checksum algorithm for PS fonts! Great idea! But I know what will happen. It will be just like Tex 'n ANSI encoding => 8r. Because it `wasn't invented here' it has to be changed - at least enough to make it useless for the original purpose or at least incompatible :=) Same will happen here. Fortunately I could care less, since I have used the scheme described above for years with great success and don't plan to change :=). Your milage may vary. But getting totally worthless checksum mismatch error messages is not my idea of fun... --Piet 25-Feb-1997 15:10:30-GMT,1922;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA17433 for ; Tue, 25 Feb 1997 08:10:29 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id KAA11127; Tue, 25 Feb 1997 10:10:26 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA06452; Tue, 25 Feb 1997 10:10:20 -0500 (EST) Date: Tue, 25 Feb 1997 10:10:20 -0500 (EST) Message-Id: <199702251510.KAA06452@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: C.A.Rowley@open.ac.uk CC: tex-font@math.utah.edu In-reply-to: <199702241954.TAA16752@fell.open.ac.uk> (message from Chris Rowley on Mon, 24 Feb 1997 19:54:11 GMT) Subject: Re: composite characters and dotless ones Reply-to: bkph@ai.mit.edu Right, and this explains why there is no dotlessj even though there is a jcircumflex. Their view is that jcircumlex is j + circumflex, not doltessj + circumflex. Bummer. I am not sure if I mentioned this before, but in Unicode the canonical decomposition of, for example is + not . Indeed, page 6-7 explicitly states that these combinations give two distinct characters. Further, it states that in cases where the dot is preserved and the diacritic is added above the dot, the decomposition is as a double diacritic: + hmmmm. Such decomposition is necessary and for many purposes the canonical Unicode one is the only correct one; its being "wrong" for making a composite glyph is, of course, irrelevant to Unicode itself (but not to typesetting applications that process Unicode documents). chris 25-Feb-1997 15:25:19-GMT,1054;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id IAA17813 for ; Tue, 25 Feb 1997 08:25:15 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <14217-0@venus.open.ac.uk>; Tue, 25 Feb 1997 15:23:25 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id PAA17642; Tue, 25 Feb 1997 15:22:40 GMT Date: Tue, 25 Feb 1997 15:22:40 GMT Message-Id: <199702251522.PAA17642@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bkph@ai.mit.edu Cc: tex-font@math.utah.edu Subject: Re: composite characters and dotless ones In-Reply-To: <199702251510.KAA06452@kauai.ai.mit.edu> References: <199702241954.TAA16752@fell.open.ac.uk> <199702251510.KAA06452@kauai.ai.mit.edu> > Bummer. Only for those who wish to abuse it as a font-encoding:-). 25-Feb-1997 15:25:33-GMT,2247;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA17826 for ; Tue, 25 Feb 1997 08:25:32 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id KAA10808; Tue, 25 Feb 1997 10:03:07 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA06430; Tue, 25 Feb 1997 10:03:01 -0500 (EST) Date: Tue, 25 Feb 1997 10:03:01 -0500 (EST) Message-Id: <199702251503.KAA06430@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: alanje@cogs.susx.ac.uk CC: P.T.H.Tutelaers@urc.tue.nl, tex-fonts@math.utah.edu In-reply-to: (message from Alan Jeffrey on Mon, 24 Feb 97 17:05 GMT) Subject: Re: Checksums (was re: 8r fonts) Reply-to: bkph@ai.mit.edu Piet Tutelaers writes: > > (1) what happens if WX is non-integer (as it is in all CM, AMS etc fonts > > --- or at least if it isn't fractional then you do not have good > > fonts!)? > Non-integers are currently *not* supported. They were not foreseen by Tom > Rokicki. Perhaps Berthold wants to learn us why we need them "uberhaupt? Because some fonts (such as most of Knuth's fonts) do not have integer advance widths when expressed in 1/1000-th of an em. And those CM fonts out there that round advance widths off, well they just are approximations, not the real thing! For example, in some CM fonts, Knuth worked mostly in multiples of 1/36 th of a point. Fontinst supports them, but only by brute force truncation after the decimal point. They were introduced by Adobe at the same time as MM fonts, and I suspect that that's not a coincidence! MM AFMs are generated by interpolating, so it's not surprising you need non-integer AFM values. That is not quote correct, I think. The CM fonts had AFM files with fractional widths ever since they first came out somewhere between 1988 and 1990. True, some software choked on those numbers, but then there is always software around that makes unwarranted assumptions. Alan. 25-Feb-1997 15:55:56-GMT,2319;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmza.zdv.Uni-Mainz.DE [134.93.178.30]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA18689 for ; Tue, 25 Feb 1997 08:55:55 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IFU90L3YU868QZGB@MZDMZA.ZDV.UNI-MAINZ.DE> for tex-fonts@math.utah.edu; Tue, 25 Feb 1997 16:56:26 +0100 Date: Tue, 25 Feb 1997 16:56:26 +0100 Subject: Re: Checksums (was re: 8r fonts) To: tex-fonts@math.utah.edu Message-id: <01IFU90L45FM68QZGB@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: IN"tex-fonts@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT If one can encode about six letters in the checksum, we should think very carefull about which information should be encoded there. IMHO, encoding the font encoding is a particularly bad idea, since the tfm file format already has a place for a string called CODINGSCHEME. This string should be as precise as possible and can of course be examined by dvi drivers. It can -- with pk fonts at least -- also be compared to the special information stored there. METAFONT *always* put the codingscheme special into the gf file, not only with mode defined specials. There is other information which one likes to check (e.g. Version numbers) and which is otherwise not accessible through the tfm file. --J"org Knappen. [knappen@goofy] tftopl logo10 (FAMILY MFLOGO) (FACE O 352) (CODINGSCHEME AEFMNOPST ONLY) (DESIGNSIZE R 10.0) (COMMENT DESIGNSIZE IS IN POINTS) (COMMENT OTHER SIZES ARE MULTIPLES OF DESIGNSIZE) (CHECKSUM O 37045067476) [...] [knappen@goofy] pktype logo10.300pk This is PKtype, Version 2.3 (C version 6.1) 'METAFONT output 1996.12.11:1503' Design size = 10485760 Checksum = -124489922 [...] 330: Special: 'fontid=MFLOGO' 345: Special: 'codingscheme=AEFMNOPST only' 374: Special: 'fontfacebyte' 388: Num special: 15335424 393: Special: 'jobname=logo10' 409: Special: 'mag=1' 416: Special: 'mode=cx' 425: Special: 'pixels_per_inch=300' 446: Special: 'blacker=0' 457: Special: 'fillin=0.2' 469: Special: 'o_correction=0.6' 487: Postamble 488 bytes read from packed file. 25-Feb-1997 16:09:44-GMT,1928;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA19036 for ; Tue, 25 Feb 1997 09:09:43 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id QAA06114 for ; Tue, 25 Feb 1997 16:07:51 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Tue, 25 Feb 1997 16:08:51 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id QAA05791; Tue, 25 Feb 1997 16:08:47 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id QAA22487; Tue, 25 Feb 1997 16:08:42 GMT Date: Tue, 25 Feb 1997 16:08:42 GMT Message-Id: <199702251608.QAA22487@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: bkph@ai.mit.edu Cc: P.T.H.Tutelaers@urc.tue.nl, tex-fonts@math.utah.edu Subject: Re: Checksums (was re: 8r fonts) In-Reply-To: <199702251508.KAA06443@kauai.ai.mit.edu> References: <199702241619.RAA17752@asterix.urc.tue.nl> <199702251508.KAA06443@kauai.ai.mit.edu> > Great idea! But I know what will happen. It will be just like > Tex 'n ANSI encoding => 8r. Because it `wasn't invented here' > it has to be changed - at least enough to make it useless for the oh, thats not fair, Berthold. 8r wasnt a deliberate contravention of texnansi. maybe we misunderstood texnansi (your name is on 8r, dont forget) but it was as cynical as you suggest. > Your milage may vary. But getting totally worthless checksum mismatch > error messages is not my idea of fun... yes, checksum error messages are one of the worst ways of filling the day sebastian 25-Feb-1997 16:12:31-GMT,1188;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmza.zdv.Uni-Mainz.DE [134.93.178.30]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA19082 for ; Tue, 25 Feb 1997 09:12:29 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IFU9P465M8FI4COR@MZDMZA.ZDV.UNI-MAINZ.DE> for tex-fonts@math.utah.edu; Tue, 25 Feb 1997 17:13:10 +0100 Date: Tue, 25 Feb 1997 17:13:10 +0100 Subject: Values for Codingscheme To: tex-fonts@math.utah.edu Message-id: <01IFU9P46YJMFI4COR@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: IN"tex-fonts@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Here are some values for CODINGSCHEME: ec fonts: EXTENDED TEX FONT ENCODING - LATIN tc fonts: TEX TEXT COMPANION SYMBOLS 1---TS1 fc fonts: AFRICAN LATIN /FC/ logo fonts: AEFMNOPST ONLY cmr/ti/...: TEX TEXT cmtt: TEX TYPEWRITER TEXT cmtex: TEX EXTENDED ASCII Hmmm....the value for ec fonts does not look like a very lucky choice, but now it is as it reads above. --J"org Knappen. 25-Feb-1997 17:04:17-GMT,3556;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA20589 for ; Tue, 25 Feb 1997 10:04:16 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id MAA16142; Tue, 25 Feb 1997 12:03:34 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id MAA06513; Tue, 25 Feb 1997 12:03:33 -0500 (EST) Date: Tue, 25 Feb 1997 12:03:33 -0500 (EST) Message-Id: <199702251703.MAA06513@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: mduerst@ifi.unizh.ch CC: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu In-reply-to: (mduerst@ifi.unizh.ch) Subject: Re: Unicode and math symbols Reply-to: bkph@ai.mit.edu > Martin > > Please note that for one area where you would assume that > > dealing with "meaning" would be especially easy, the > > character/glyph model that is the general base of > > Unicode/ISO 10646 had to be changed somewhat (to > > come closer to "glyph" than for other scripts) to > > accomodate for present practice and user expectations. > Sounds interesting: to what do you refer? Well, there is a draft for an explanation of the character/ glyph model with respect to CJK, which will probably become an informative annex to 10646. The main point where "shape" is preferred over "meaning" is where characters have been simplified so much as to lead to totally different shapes that cannot easily be identified, and where simplifications have lead to merging of several originally different characters. In both cases, "simulating paper" in the sense that there are different codepoints for the major shape differences is the better solution, because users mostly are not aware anymore e.g. about originally differentiated characters. I think I have read this although I was so confused I don't quite recognize your reference. They spend 26 (twenty-six) pages not quite defining the difference between glyph and character. It is on the UNICODE 2.0 CD-ROM. Let me stick my neck out here: I know this was not the intent of UNICODE, and UNICODE has many features that make it non-ideal for this, but UNICODE *is* a de facto glyph standard. (1) Which is why we have the `alphabetic presentation forms' ff, ffi, ffl, fi, fl, slongt, st etc. in UNICODE. (2) Software like Framemaker and MathType could not use anything but the Adobe Symbol font *until* they got UNICODE numbers for glyphs in other math fonts from Adobe, Y&Y, Monotype etc. They do not want to have the TeX nightmare of complex metric structures to be built for ever new font they come across. And yes: they can't use half of the glyphs in LucidaNewMath because they don't have UNICODE numbers. Which is a serious failing of UNICODE, IMHO. (3) It is what happens in Windows NT. Yes, you can access glyphs in a font by their numeric position within the font, but I don't know of any software that does that. Access is via UNICODE. The exception are `pi' fonts. And of course right now we mostly deal with math fonts in that mode. Yes, you want font switches to cover stylistic variations, but wouldn't it be nice if `contour integral' as accessible to same way in a regular font and a bold font, in a font from Adobe and a font from Monotype. etc. Berthold. 25-Feb-1997 17:31:51-GMT,2405;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA21339 for ; Tue, 25 Feb 1997 10:31:34 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id MAA17799; Tue, 25 Feb 1997 12:31:31 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id MAA06527; Tue, 25 Feb 1997 12:31:25 -0500 (EST) Date: Tue, 25 Feb 1997 12:31:25 -0500 (EST) Message-Id: <199702251731.MAA06527@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: KNAPPEN@vkpmzd.kph.uni-mainz.de CC: tex-fonts@math.utah.edu In-reply-to: <01IFU90L45FM68QZGB@MZDMZA.ZDV.UNI-MAINZ.DE> (KNAPPEN@VKPMZD.kph.Uni-Mainz.DE) Subject: Re: Checksums (was re: 8r fonts) Reply-to: bkph@ai.mit.edu Hi: J"org writes: If one can encode about six letters in the checksum, we should think very carefull about which information should be encoded there. IMHO, encoding the font encoding is a particularly bad idea, since the tfm file format already has a place for a string called CODINGSCHEME. Which is useless, since it is not carried over to the DVI file. You can hide all sorts of things in the TFM file, but it does no good unless it gets put in the DVI file. And the only thing that is, is the CheckSum. This string should be as precise as possible and can of course be examined by dvi drivers. It can -- with pk fonts at least -- also be compared to the special information stored there. METAFONT *always* put the codingscheme special into the gf file, not only with mode defined specials. There is other information which one likes to check (e.g. Version numbers) and which is otherwise not accessible through the tfm file. You can only squezze that much into 6 characters. And the encoding is the most important by a long shot. This was not an issue hen TeX started since all CM fonts have fixed-hard wired encoding. Today it is a *big* issue. Just like missing characters were not an issue in the good old days because CM fonts were `full' now it is a big deal. We need to give users tools to help debug encoding problems and missing character problems (which result from encoding problems). --J"org Knappen. 25-Feb-1997 17:36:10-GMT,2212;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA21493 for ; Tue, 25 Feb 1997 10:36:09 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id MAA18021; Tue, 25 Feb 1997 12:35:55 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id MAA06530; Tue, 25 Feb 1997 12:35:53 -0500 (EST) Date: Tue, 25 Feb 1997 12:35:53 -0500 (EST) Message-Id: <199702251735.MAA06530@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: s.rahtz@elsevier.co.uk CC: P.T.H.Tutelaers@urc.tue.nl, tex-fonts@math.utah.edu In-reply-to: <199702251608.QAA22487@lochnagarn.elsevier.co.uk> (message from Sebastian Rahtz on Tue, 25 Feb 1997 16:08:42 GMT) Subject: Re: Checksums (was re: 8r fonts) Reply-to: bkph@ai.mit.edu > Great idea! But I know what will happen. It will be just like > Tex 'n ANSI encoding => 8r. Because it `wasn't invented here' > it has to be changed - at least enough to make it useless for the oh, thats not fair, Berthold. 8r wasnt a deliberate contravention of texnansi. maybe we misunderstood texnansi (your name is on 8r, dont forget) but it was as cynical as you suggest. OK, I apologize for the tone of my messages. Perhaps I should have been more forceful then --- but in the sunny days in Santa Barbara I just gave up instead :=) What has happened is that 8r adopts many features of texnansi, but not quite enough to actually displace texnansi (in particular it dropped the useful repeated encoding to leave space for - what?) Also, in the end it turns out it probably didn't really help PC-TeX and TrueTeX etc users much (as far as I know) - which was one motiviation for basing it on Windows ANSI (which in turn is derived from ISO Latin 1). That was hard to predict. > Your milage may vary. But getting totally worthless checksum mismatch > error messages is not my idea of fun... yes, checksum error messages are one of the worst ways of filling the day Berthold. 26-Feb-1997 18:12:15-GMT,1399;000000000000 Return-Path: Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id LAA24325 for ; Wed, 26 Feb 1997 11:12:13 -0700 (MST) Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <08592-0@josef.ifi.unizh.ch>; Wed, 26 Feb 1997 19:12:31 +0100 Date: Wed, 26 Feb 1997 19:12:30 +0100 (MET) From: "Martin J. Duerst" Sender: mduerst@enoshima To: "Berthold K.P. Horn" cc: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199702251703.MAA06513@kauai.ai.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 25 Feb 1997, Berthold K.P. Horn wrote: > Let me stick my neck out here: I know this was not the intent > of UNICODE, and UNICODE has many features that make it non-ideal > for this, but UNICODE *is* a de facto glyph standard. > > (1) Which is why we have the `alphabetic presentation forms' > ff, ffi, ffl, fi, fl, slongt, st etc. in UNICODE. They are in the compatibility section. If you consider the Indic scripts and Arabic (except for the compatibility section), you would not say that Unicode is a glyph standard. Regards, Martin. 26-Feb-1997 18:24:02-GMT,2732;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA24695 for ; Wed, 26 Feb 1997 11:24:02 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id NAA15833; Wed, 26 Feb 1997 13:23:27 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id NAA07250; Wed, 26 Feb 1997 13:23:19 -0500 (EST) Date: Wed, 26 Feb 1997 13:23:19 -0500 (EST) Message-Id: <199702261823.NAA07250@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: mduerst@ifi.unizh.ch CC: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu In-reply-to: (mduerst@ifi.unizh.ch) Subject: Re: Unicode and math symbols Reply-to: bkph@ai.mit.edu On Tue, 25 Feb 1997, Berthold K.P. Horn wrote: > Let me stick my neck out here: I know this was not the intent > of UNICODE, and UNICODE has many features that make it non-ideal > for this, but UNICODE *is* a de facto glyph standard. > (1) Which is why we have the `alphabetic presentation forms' > ff, ffi, ffl, fi, fl, slongt, st etc. in UNICODE. They are in the compatibility section. Well, they were put in *somewhere* because they are needed, since (i) we do not have a usable and widely accepted glyph standard, and (ii) because most software wants to be able to have *some* way of telling what glyph in a font is to be used. We can all dream about a better world (GX?) but, do you really want to deal with each font as a separate entitity? Wasn't it bad enough to have ten or twelve different character encoding schemes used by Computer Modern fonts? If you consider the Indic scripts and Arabic (except for the compatibility section), you would not say that Unicode is a glyph standard. Oh yes, I agree. I know what the religiously pure answer is. And I know that this is much more involved for some scripts than others. But do I really need - in English - to make a distinction between the characters A-Z and the glyphs A-Z? Or, beyond that, most of the glyphs in the ISO Latin X tables (if we ignore the mistakes and bad choices made). But anyway, meantime we need to make life easier! And despite all the explanations and arguments I don't see a whole lot wrong with using UNICODE as essentially a glyph standard for Latin X, Cyrillic, Greek, and yes, most math symbols, relations, operators, delimiters etc. Except that unfortunately they don't cover enough of math to be really useful... Regards, Martin. 28-Feb-1997 18:00:47-GMT,3808;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id LAA27938 for ; Fri, 28 Feb 1997 11:00:38 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <05153-0@venus.open.ac.uk>; Fri, 28 Feb 1997 17:46:27 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id RAA21644; Fri, 28 Feb 1997 17:45:40 GMT Date: Fri, 28 Feb 1997 17:45:40 GMT Message-Id: <199702281745.RAA21644@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bkph@ai.mit.edu Cc: mduerst@ifi.unizh.ch, BNB@math.ams.org, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199702261823.NAA07250@kauai.ai.mit.edu> References: <199702261823.NAA07250@kauai.ai.mit.edu> Berthold wrote -- > > (1) Which is why we have the `alphabetic presentation forms' > > ff, ffi, ffl, fi, fl, slongt, st etc. in UNICODE. > > They are in the compatibility section. > > Well, they were put in *somewhere* because they are needed, No, they were put in for compatibility and there use is not advised. Also "etc" are not there: these are the only Latin "aesthetic ligatures" that are there, eg there is no ck ligature. > since (i) we do not have a usable and widely accepted glyph > standard, and (ii) because most software wants to be able to have > *some* way of telling what glyph in a font is to be used. These do seem to be the two problems driving this issue. But not just "some way": it seems that the only object some software can use is a fixed-length number; and *only one* correspondence from these numbers to ... what? ... to glyphs (in all fonts, in some fonts, or what??) or to characters (ie units of information) or to both (ie a one-one relationship between glyphs and characters?). > But do I really need - in English - to make a distinction > between the characters A-Z and the glyphs A-Z? Or, beyond that, > most of the glyphs in the ISO Latin X tables (if we ignore the > mistakes and bad choices made). I have little qualification to answer this but it may well be that you do not need to make a big thing of the difference in these cases. But the point of Unicode is to remove such cultural dominance of modern European languages on IT. > But anyway, meantime we need to make life easier! And despite all the > explanations and arguments I don't see a whole lot wrong with using > UNICODE as essentially a glyph standard for Latin X, Cyrillic, Greek, > and yes, most math symbols, relations, operators, delimiters etc. Let us suppose that some such encoding would be a practical encoding containing considerably more than 256 slots but using enormously less than 2^16 slots available. If, as I mentioned above, there must be only one encoding, then surely it will have to be whatever Adobe or Microsoft decides, and will therefore cover only some subset of the glyphs they are interested in: and, knowing them, it will be almost but not quite "the same as" Unicode. So even if a 16-bit encoding is set up with all the math symbols "we" want, it will not be used as the *only one*. > Except that unfortunately they don't cover enough of math to be > really useful... And never will, according to some definitions of useful; but it will also not cover my ck ligature, or all the lovely twirly things in Poetica and similar fonts. So set up a 16-bit glyph encoding if you wish, but do not try to change Unicode because you want it to parallel your glyph encoding. Leave Unicode itself to do what it is intended for. chris 28-Feb-1997 18:31:37-GMT,5985;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA28693 for ; Fri, 28 Feb 1997 11:31:33 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id NAA25781; Fri, 28 Feb 1997 13:31:05 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id NAA08338; Fri, 28 Feb 1997 13:31:03 -0500 (EST) Date: Fri, 28 Feb 1997 13:31:03 -0500 (EST) Message-Id: <199702281831.NAA08338@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: C.A.Rowley@open.ac.uk CC: mduerst@ifi.unizh.ch, BNB@math.ams.org, tex-font@math.utah.edu In-reply-to: <199702281745.RAA21644@fell.open.ac.uk> (message from Chris Rowley on Fri, 28 Feb 1997 17:45:40 GMT) Subject: Re: Unicode and math symbols Reply-to: bkph@ai.mit.edu Chris wrote: Berthold wrote -- > > (1) Which is why we have the `alphabetic presentation forms' > > ff, ffi, ffl, fi, fl, slongt, st etc. in UNICODE. > > They are in the compatibility section. > > Well, they were put in *somewhere* because they are needed, No, they were put in for compatibility and there use is not advised. But nobody is heeding that avise! Applications in Windows NT *are* using them. And I would not be suprised if they were put in after arm twisting from the `Seattle Satans' as Sebastain refers to them. And you can see why: (just about) the only way to get at glyphs in fonts in these systems is either (1) by UNICODE or (2) by numeric sequence number of arrangement of glyphs in the font, which of course is quite random, although fixed for a given version of a given font. In addition in some font technologies there need be tables with mnemonic names (such as AFII numbers :-). So what is an application developer to do? (The `just about' above refers to the exception that you can make a `symbol' font which is treated as an incomprehensible thing that the operating system does not mess with. You can put your glyphs in any order you like and access them by numeric code). Also "etc" are not there: these are the only Latin "aesthetic ligatures" that are there, eg there is no ck ligature. Yes, I know, and fj and a few others one might like see there. It took them a long time to even add ff, ffi, ffl to the basic fi and fl. > since (i) we do not have a usable and widely accepted glyph > standard, and (ii) because most software wants to be able to have > *some* way of telling what glyph in a font is to be used. These do seem to be the two problems driving this issue. But not just "some way": it seems that the only object some software can use is a fixed-length number; and *only one* correspondence from these numbers to ... what? ... to glyphs (in all fonts, in some fonts, or what??) or to characters (ie units of information) or to both (ie a one-one relationship between glyphs and characters?). Well, there are many borderline cases we can argue about. But let just take `greater'. I know what that means and you do. And we'll in most cases recognize which glyph if any in a font is supposed to represent it. It is very convenient that in most encodings it is at char code 62 in all fonts, bold, regular, oblique, blackletter, Script, what have you. The more of this uniformity we have the better. > But do I really need - in English - to make a distinction > between the characters A-Z and the glyphs A-Z? Or, beyond that, > most of the glyphs in the ISO Latin X tables (if we ignore the > mistakes and bad choices made). I have little qualification to answer this but it may well be that you do not need to make a big thing of the difference in these cases. But the point of Unicode is to remove such cultural dominance of modern European languages on IT. And it fails in that. It *does* succeed in assiging unique codes to characters from many languages. But it fails in dealing with the different writing systems which have all sorts of features not found in Western languages. Look for example at the rapidly growing `alphabetic presentation forms' put in to try and cope with a bit of this. > But anyway, meantime we need to make life easier! And despite all the > explanations and arguments I don't see a whole lot wrong with using > UNICODE as essentially a glyph standard for Latin X, Cyrillic, Greek, > and yes, most math symbols, relations, operators, delimiters etc. ... > Except that unfortunately they don't cover enough of math to be > really useful... And never will, according to some definitions of useful; but it will also not cover my ck ligature, or all the lovely twirly things in Poetica and similar fonts. So set up a 16-bit glyph encoding if you wish, but do not try to change Unicode because you want it to parallel your glyph encoding. Leave Unicode itself to do what it is intended for. That is not an option. On systems with system level font support (i.e. not Unix) you get a lot of power from what the system provides and at the same time inherit any limitations `they' put in. So in the case of Windows NT for example (and perhaps AT&T Plan 9) the OS supports UNICODE and applications can use it to display and print. BUT: what they consider not to be in UNICODE is not accessible. So for example when I convert Lucida Bright from Type 1 to TrueType format using the built in converter, I can get at all the glyphs except the ones not in their table, such as dotlessj. Ditto for ATM (now in beta test). So the issue of what *is* in UNICODE *is* important. Aside from that we don't want a hundred different versions of UNICODE++ (like the mess we have with \special). I have put dotlessj at FB0F, but who knows where you will put it? chris Berthold. 28-Feb-1997 19:18:38-GMT,1580;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id MAA29902 for ; Fri, 28 Feb 1997 12:18:22 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <08921-0@venus.open.ac.uk>; Fri, 28 Feb 1997 19:17:32 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id TAA21792; Fri, 28 Feb 1997 19:16:56 GMT Date: Fri, 28 Feb 1997 19:16:56 GMT Message-Id: <199702281916.TAA21792@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bkph@ai.mit.edu Cc: mduerst@ifi.unizh.ch, BNB@math.ams.org, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199702281831.NAA08338@kauai.ai.mit.edu> References: <199702281745.RAA21644@fell.open.ac.uk> <199702281831.NAA08338@kauai.ai.mit.edu> Berthold Just a few questions to you to clarify matters: Does this dependence of OSs on the Unicode standard mean that whenever Unicode changes, everyone needs a new version of the OS or just new font-files, or what? > BUT: what they consider not to be in UNICODE is not accessible. by "not in" do you mean that if a slot is empty in what that OS thinks is the Unicode encoding then I cannot access a glyph in that slot in any font? So how does one use Poetica on NT? Thanks And, if anyone knows, does plan 9 also have font-encodings hard-wired like this? chris 28-Feb-1997 19:59:31-GMT,3049;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id MAA01142 for ; Fri, 28 Feb 1997 12:59:20 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id OAA00962; Fri, 28 Feb 1997 14:58:48 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id OAA08375; Fri, 28 Feb 1997 14:58:34 -0500 (EST) Date: Fri, 28 Feb 1997 14:58:34 -0500 (EST) Message-Id: <199702281958.OAA08375@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: C.A.Rowley@open.ac.uk CC: mduerst@ifi.unizh.ch, BNB@math.ams.org, tex-font@math.utah.edu In-reply-to: <199702281916.TAA21792@fell.open.ac.uk> (message from Chris Rowley on Fri, 28 Feb 1997 19:16:56 GMT) Subject: Re: Unicode and math symbols Reply-to: bkph@ai.mit.edu Berthold Just a few questions to you to clarify matters: Does this dependence of OSs on the Unicode standard mean that whenever Unicode changes, everyone needs a new version of the OS or just new font-files, or what? The support for all this right now is still rather poor, actually. (1) For example, the Microsoft NT font installer has a fixed table of glyph name to UNICODE mappings (complete with typos like aroowleft, hungerumlaunt, traglf). If your Type 1 font has glyphs names that are not in that table those glyphs will not be converted, and hence are not usable. (2) The table makes no provision for alternate names. Thus you have to have Odblacute: Ohungarumlaut will not work. And it has to be Tcedilla: Tcommaaccent will not work. etc. (3) The coverage of this table is limited, mostly WGL4 (which covers about 662 glyphs, including all the Latin alphabets, Greek, Cyrillic) (And in the current implementation it actually covers less). (4) ATM for NT apparenlty has a similar table, with some differences in names and some differences in UNICODE codes from the MicroSoft version. one can only hope that they at least get together and `unify' these tables. > BUT: what they consider not to be in UNICODE is not accessible. by "not in" do you mean that if a slot is empty in what that OS thinks is the Unicode encoding then I cannot access a glyph in that slot in any font? So how does one use Poetica on NT? Oh, keep in mind that there are two flavours of fonts: UGL (text) fonts and `symbol' (or rather: non-text) fonts. non-text fonts can be layed o out anyway you want and you access them by numeric codes (although this is restricted to 0 - 255 as far as I can tell (you can use 16 bit numbers but the mapping is weird and wonderful and useless I think). This is how all CM, AMS, extra LaTeX + SliTeX fonts are treated now. They are *not* text fonts, because they all have their own bizarre encoding. Thanks And, if anyone knows, does plan 9 also have font-encodings hard-wired like this? chris 28-Feb-1997 20:12:57-GMT,1713;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id NAA01554 for ; Fri, 28 Feb 1997 13:12:54 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id PAA02032; Fri, 28 Feb 1997 15:12:34 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id PAA08397; Fri, 28 Feb 1997 15:12:31 -0500 (EST) Date: Fri, 28 Feb 1997 15:12:31 -0500 (EST) Message-Id: <199702282012.PAA08397@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: C.A.Rowley@open.ac.uk CC: mduerst@ifi.unizh.ch, BNB@math.ams.org, tex-font@math.utah.edu In-reply-to: <199702281916.TAA21792@fell.open.ac.uk> (message from Chris Rowley on Fri, 28 Feb 1997 19:16:56 GMT) Subject: Re: Unicode and math symbols Reply-to: bkph@ai.mit.edu Berthold Just a few questions to you to clarify matters: Does this dependence of OSs on the Unicode standard mean that whenever Unicode changes, everyone needs a new version of the OS or just new font-files, or what? I guess I forgot to answer this: Yes, it has already happened the T1 installer in NT maps fi and fl to F001 and F002 (UNICODE 1.1.x) while ATM NT maps them to FB01 and FB02 (UNICODE 2.0). This is why it is so important to get as many of these issue resolved *long* before anyone ever starts using this sort of stuff. Like if we decide in the next millenium that UNICODE may be useful for TeX, then it would be too late to agitate for inclusion of additional characters at *that* point. Berthold. 28-Feb-1997 20:49:01-GMT,1678;000000000000 Return-Path: Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id NAA02545 for ; Fri, 28 Feb 1997 13:49:00 -0700 (MST) Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <05354-0@josef.ifi.unizh.ch>; Fri, 28 Feb 1997 21:49:17 +0100 Date: Fri, 28 Feb 1997 21:49:16 +0100 (MET) From: "Martin J. Duerst" Sender: mduerst@enoshima To: "Berthold K.P. Horn" cc: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199702282012.PAA08397@kauai.ai.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 28 Feb 1997, Berthold K.P. Horn wrote: > This is why it is so important to get as many of these issue resolved > *long* before anyone ever starts using this sort of stuff. Like if > we decide in the next millenium that UNICODE may be useful for TeX, > then it would be too late to agitate for inclusion of additional > characters at *that* point. Inclusion of additional characters, in particular genuinely new (in the sense that they are not just the same as something already in) but well established math symbols, in not a problem at all (except for time, which is spent mainly on the ISO side). There many ongoing additions, in particular scripts not yet covered, historical scripts, and CJK ideographs. Of course, moving things around is a completely different issue, to be avoided at all cost. Regards, Martin. 28-Feb-1997 20:55:26-GMT,1777;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id NAA02694 for ; Fri, 28 Feb 1997 13:55:21 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id PAA04196; Fri, 28 Feb 1997 15:53:49 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id PAA08427; Fri, 28 Feb 1997 15:53:47 -0500 (EST) Date: Fri, 28 Feb 1997 15:53:47 -0500 (EST) Message-Id: <199702282053.PAA08427@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: mduerst@ifi.unizh.ch CC: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu In-reply-to: (mduerst@ifi.unizh.ch) Subject: Re: Unicode and math symbols Reply-to: bkph@ai.mit.edu From: "Martin J. Duerst" Inclusion of additional characters, in particular genuinely new (in the sense that they are not just the same as something already in) but well established math symbols, in not a problem at all (except for time, which is spent mainly on the ISO side). Well, not quite. If it is not in the standard, then frustrated implementors and frustrated users will put characters *somewhere* and end up with many competing incompatible layouts... (Much like we have a dozen different \specials just for including EPS images). There many ongoing additions, in particular scripts not yet covered, historical scripts, and CJK ideographs. Of course, moving things around is a completely different issue, to be avoided at all cost. Agreed. Regards, Martin. 28-Feb-1997 21:04:22-GMT,3092;000000000000 Return-Path: Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id OAA02917 for ; Fri, 28 Feb 1997 14:04:20 -0700 (MST) Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <05548-0@josef.ifi.unizh.ch>; Fri, 28 Feb 1997 22:04:03 +0100 Date: Fri, 28 Feb 1997 22:04:02 +0100 (MET) From: "Martin J. Duerst" Sender: mduerst@enoshima To: "Berthold K.P. Horn" cc: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199702281958.OAA08375@kauai.ai.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 28 Feb 1997, Berthold K.P. Horn wrote: > > Berthold > > Just a few questions to you to clarify matters: > > Does this dependence of OSs on the Unicode standard mean that whenever > Unicode changes, everyone needs a new version of the OS or just new > font-files, or what? > > The support for all this right now is still rather poor, actually. > > (1) For example, the Microsoft NT font installer has a fixed table > of glyph name to UNICODE mappings (complete with typos like > aroowleft, hungerumlaunt, traglf). Microsoft wrongly uses Unicode as a kind of glyph repertoire, and can get away with it as long as they don't deal with Indian scripts. The correct solution is to not have the system do the conversion between character codepoints and glyph indices, but to leave that to the font (which should know best). Quickdraw GX (from Apple) and TrueType open are approaches to this, although I would prefer it if the knowledge of the font about the mapping were available as methods (in the OO sense) and not just as tables. > (3) The coverage of this table is limited, mostly WGL4 (which covers > about 662 glyphs, including all the Latin alphabets, Greek, Cyrillic) > (And in the current implementation it actually covers less). Well, for the bulk of Unicode, CJK, names are a silly idea anyway. > > BUT: what they consider not to be in UNICODE is not accessible. > by "not in" do you mean that if a slot is empty in what that OS thinks > is the Unicode encoding then I cannot access a glyph in that slot in any > font? > > So how does one use Poetica on NT? The main problem with the approach I proposed above (that the font knows how to do the mapping) is that you have to think about ways to bring in the preferences of the application. Poetical is a particular example, but still lots of decisions could be made by the font itself depending on character combinations. > And, if anyone knows, does plan 9 also have font-encodings hard-wired > like this? Plan 9 is in a very early stage as with respect to character -> glyph mapping and other kinds of font support such as outline fonts. It's just not their area of interest/expertise, at least not currently. Regards, Martin. 28-Feb-1997 21:17:20-GMT,3146;000000000000 Return-Path: Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id OAA03293 for ; Fri, 28 Feb 1997 14:17:17 -0700 (MST) Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <05843-0@josef.ifi.unizh.ch>; Fri, 28 Feb 1997 22:17:34 +0100 Date: Fri, 28 Feb 1997 22:17:32 +0100 (MET) From: "Martin J. Duerst" Sender: mduerst@enoshima To: "Berthold K.P. Horn" cc: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199702281831.NAA08338@kauai.ai.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 28 Feb 1997, Berthold K.P. Horn wrote: > > Chris wrote: > > Berthold wrote -- > > > > (1) Which is why we have the `alphabetic presentation forms' > > > ff, ffi, ffl, fi, fl, slongt, st etc. in UNICODE. > > > > They are in the compatibility section. > > > > Well, they were put in *somewhere* because they are needed, > > No, they were put in for compatibility and there use is not advised. > > But nobody is heeding that avise! Applications in Windows NT *are* > using them. And I would not be suprised if they were put in after > arm twisting from the `Seattle Satans' as Sebastain refers to them. No, no. fi and fl are in Mac fonts, too. Some are definitely due to MS, but it's not fair to blame MS for all of them. > But the point of Unicode is to remove such cultural dominance of modern > European languages on IT. > > And it fails in that. It *does* succeed in assiging unique codes to > characters from many languages. But it fails in dealing with the > different writing systems which have all sorts of features not found > in Western languages. Look for example at the rapidly growing > `alphabetic presentation forms' put in to try and cope with a bit of this. I guess you mean extended Greek and Latin, with lots of diacritic combinations? The main reason they are in is that some ISO people thought that dealing with combining characters would be too difficult for some systems, and so they invented "Levels". Because the Greeks and the Vietnamese and a few others didn't want to end up in level 3, they lobbied to have their combinations in. This creates a vicious cycle: The more is in, the less it pays off to work on level 3, and the more pressure you have to put some precombined stuff in. In addition, there is the political prestige of having your language's precombinations in, following from the fact that all the rich and influential countries have theirs in, too. > Aside from that we don't want a hundred different versions of UNICODE++ > (like the mess we have with \special). I have put dotlessj at FB0F, > but who knows where you will put it? Guess you have never heard about the private zone? That's where such things go if you want to create the least amount of problems you can. Regards, Martin. 28-Feb-1997 21:27:19-GMT,3258;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id OAA03609 for ; Fri, 28 Feb 1997 14:27:15 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id QAA06094; Fri, 28 Feb 1997 16:26:48 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id QAA08485; Fri, 28 Feb 1997 16:26:46 -0500 (EST) Date: Fri, 28 Feb 1997 16:26:46 -0500 (EST) Message-Id: <199702282126.QAA08485@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: mduerst@ifi.unizh.ch CC: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu In-reply-to: (mduerst@ifi.unizh.ch) Subject: Re: Unicode and math symbols Reply-to: bkph@ai.mit.edu On Fri, 28 Feb 1997, Berthold K.P. Horn wrote: > But nobody is heeding that avise! Applications in Windows NT *are* > using them. And I would not be suprised if they were put in after > arm twisting from the `Seattle Satans' as Sebastain refers to them. No, no. fi and fl are in Mac fonts, too. Some are definitely due to MS, but it's not fair to blame MS for all of them. You get the polarity wrong: I think it is a *good* thing they are in there :) And yes, just about all 30,000 fonts in Type 1 format have fi and fl. Even the ones on Windows. Only you can't use them in Windows unless you have an application that can reencode them on the fly (like DVIWindo :), but they are there in the font. Even the TrueType fonts MicroSoft supplies with Windows have these glyphs. And you can easily get at them in NT, even NT 3.51. So its not a question of the fonts, but the platform. You can't get at ff, ffi, ffl on the Mac, even if the fonts have them (as Lucida Bright does). > And it fails in that. It *does* succeed in assiging unique codes to > characters from many languages. But it fails in dealing with the > different writing systems which have all sorts of features not found > in Western languages. Look for example at the rapidly growing > `alphabetic presentation forms' put in to try and cope with a bit of this. I guess you mean extended Greek and Latin, with lots of diacritic combinations? The main reason they are in is that some ISO people No, actually I meant the `alphabetic presentation forms' - which now have a few Latin ligatures some other stuff and pages upon pages of Arabic `alphabetic presentation forms'. > Aside from that we don't want a hundred different versions of UNICODE++ > (like the mess we have with \special). I have put dotlessj at FB0F, > but who knows where you will put it? Guess you have never heard about the private zone? That's where such things go if you want to create the least amount of problems you can. You miss my point. I don't care where you put them. The point is that if everyone decides for him or herself where to put them, we will have a mess. If the UNICODE consortium decides it may be a mess, but everyone will be dealing with the *same* mess. Regards, Martin. 28-Feb-1997 21:38:20-GMT,2657;000000000000 Return-Path: Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id OAA03897 for ; Fri, 28 Feb 1997 14:38:18 -0700 (MST) Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <06175-0@josef.ifi.unizh.ch>; Fri, 28 Feb 1997 22:38:36 +0100 Date: Fri, 28 Feb 1997 22:38:35 +0100 (MET) From: "Martin J. Duerst" Sender: mduerst@enoshima To: "Berthold K.P. Horn" cc: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199702282126.QAA08485@kauai.ai.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 28 Feb 1997, Berthold K.P. Horn wrote: > > On Fri, 28 Feb 1997, Berthold K.P. Horn wrote: > > > But nobody is heeding that avise! Applications in Windows NT *are* > > using them. And I would not be suprised if they were put in after > > arm twisting from the `Seattle Satans' as Sebastain refers to them. > > No, no. fi and fl are in Mac fonts, too. Some are definitely due > to MS, but it's not fair to blame MS for all of them. > > You get the polarity wrong: I think it is a *good* thing they are in there :) I got the polarity correct, because *I* don't think it's a good thing. > And yes, just about all 30,000 fonts in Type 1 format have fi and fl. Nothing bad about that. Any good font should have these ligatures, and a few more. But it shouldn't matter which number they have, you should be able to send "f","i" to the font and it should do the substitution on its own. > Even the ones on Windows. Only you can't use them in Windows unless > you have an application that can reencode them on the fly (like DVIWindo :), > but they are there in the font. Even the TrueType fonts MicroSoft supplies > with Windows have these glyphs. And you can easily get at them in NT, > even NT 3.51. But a user shouldn't type then in as ligatures. He/she won't in TeX. This is a TeX forum, and we shouldn't get too distracted by low quality stuff. > You miss my point. I don't care where you put them. The point is that if > everyone decides for him or herself where to put them, we will have a mess. > If the UNICODE consortium decides it may be a mess, but everyone > will be dealing with the *same* mess. Unicode decided to set apart an area to mess around with, but to have the rest clean. This doesn't give you a licence to mess around everywhere. Regards, Martin. 2-Mar-1997 22:03:44-GMT,1476;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id PAA01925 for ; Sun, 2 Mar 1997 15:03:43 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <12878-0@venus.open.ac.uk>; Sun, 2 Mar 1997 22:03:16 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id OAA23782; Sun, 2 Mar 1997 14:05:31 GMT Date: Sun, 2 Mar 1997 14:05:31 GMT Message-Id: <199703021405.OAA23782@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bkph@ai.mit.edu Cc: mduerst@ifi.unizh.ch, BNB@math.ams.org, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199702282126.QAA08485@kauai.ai.mit.edu> References: <199702282126.QAA08485@kauai.ai.mit.edu> Berthold wrote -- > If the UNICODE consortium decides it may be a mess, but everyone > will be dealing with the *same* mess. It may well be that for many purposes some standard, even a bad one, is better than no standard. But this one will be a mess that cannot (and is not intended to) support typography (on any medium);s o there does not seem, much point in the providers of such systems spending time on being involved in making this mess. chris 2-Mar-1997 22:03:45-GMT,1931;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id PAA01927 for ; Sun, 2 Mar 1997 15:03:44 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <12882-0@venus.open.ac.uk>; Sun, 2 Mar 1997 22:03:18 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id OAA23776; Sun, 2 Mar 1997 14:00:54 GMT Date: Sun, 2 Mar 1997 14:00:54 GMT Message-Id: <199703021400.OAA23776@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bkph@ai.mit.edu Cc: mduerst@ifi.unizh.ch, BNB@math.ams.org, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199702282012.PAA08397@kauai.ai.mit.edu> References: <199702281916.TAA21792@fell.open.ac.uk> <199702282012.PAA08397@kauai.ai.mit.edu> Berthold It seesm unlikely that Microsoft and whoever: a: will take any notice of Unicode when they do not wish to; b: intend (or wish) their OS support for fonts to be used for typographic purposes. So the automation of high-quality typography (on paper, screnn, ballons or etc>) in an OS-independent way should not use such OS support for 16-bit fonts. If it does it will always have to change as whoever decides. Note that this does not imply that Unicode is irrelevant; its use as the internal coding, as in Omega, seems sensible and fits in with it becoming a standard for information exchange. Neither does this mean that there are not other reasons for trying to change Unicode because it has ben usurped in this way; but that need not, and perhaps should not, be related to omega/TeX uses of 16-bit character encodings. And there are certainly reasons for trying to improve it as a character encoding. chris 2-Mar-1997 22:46:55-GMT,2989;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id PAA02887 for ; Sun, 2 Mar 1997 15:46:53 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id RAA12782; Sun, 2 Mar 1997 17:46:42 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id RAA09318; Sun, 2 Mar 1997 17:46:40 -0500 (EST) Date: Sun, 2 Mar 1997 17:46:40 -0500 (EST) Message-Id: <199703022246.RAA09318@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: mduerst@ifi.unizh.ch CC: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu In-reply-to: (mduerst@ifi.unizh.ch) Subject: Re: Unicode and math symbols Reply-to: bkph@ai.mit.edu > Does this dependence of OSs on the Unicode standard mean that whenever > Unicode changes, everyone needs a new version of the OS or just new > font-files, or what? > The support for all this right now is still rather poor, actually. > (1) For example, the Microsoft NT font installer has a fixed table > of glyph name to UNICODE mappings (complete with typos like > aroowleft, hungerumlaunt, traglf). Microsoft wrongly uses Unicode as a kind of glyph repertoire, and can get away with it as long as they don't deal with Indian scripts. Seems like they were forced into this by (1) inertia, (2) ignorance maybe, and the fact that (3) there is nothing better - all a few years ago when they started with this stuff. Today we are wiser, but still not wise enough apparently... The correct solution is to not have the system do the conversion between character codepoints and glyph indices, but to leave that to the font (which should know best). Quickdraw GX (from Apple) and TrueType open are approaches to this, although I would prefer it if the knowledge of the font about the mapping were available as methods (in the OO sense) and not just as tables. I don't agree with this. GX hides under hood much of what a typesetting application needs to know about (such as ligatures). The main idea behind GX is to add some apparent typesetting capabilities to dumb appications. Useless for TeX. > (3) The coverage of this table is limited, mostly WGL4 (which covers > about 662 glyphs, including all the Latin alphabets, Greek, Cyrillic) > (And in the current implementation it actually covers less). Well, for the bulk of Unicode, CJK, names are a silly idea anyway. Fine so they should accept unicode numbers written in hex as glyph names. This is what the officially released version of Lucida Sans Unicode in Type 1 format does. And which is why it does not work ironically either in autoconverted TrueType form or in Windows NT ATM! Regards, Berthold. 2-Mar-1997 22:51:52-GMT,2684;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id PAA02980 for ; Sun, 2 Mar 1997 15:51:51 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id RAA13012; Sun, 2 Mar 1997 17:51:40 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id RAA09322; Sun, 2 Mar 1997 17:51:39 -0500 (EST) Date: Sun, 2 Mar 1997 17:51:39 -0500 (EST) Message-Id: <199703022251.RAA09322@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: mduerst@ifi.unizh.ch CC: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu In-reply-to: (mduerst@ifi.unizh.ch) Subject: Re: Unicode and math symbols Reply-to: bkph@ai.mit.edu > And yes, just about all 30,000 fonts in Type 1 format have fi and fl. Nothing bad about that. Any good font should have these ligatures, and a few more. But it shouldn't matter which number they have, you should be able to send "f","i" to the font and it should do the substitution on its own. That I do not agree with. Yes, low end applications will work this way with GX and OpenType. But high end applications will need to work at this level themselves, *not* let the system machinery do it. And after the application decides to use a ligatures it must have a way of selecting it from the font. > with Windows have these glyphs. And you can easily get at them in NT, > even NT 3.51. But a user shouldn't type then in as ligatures. He/she won't in TeX. This is a TeX forum, and we shouldn't get too distracted by low quality stuff. Who said the user should type in ligatures? And yes, I mean TeX and such. If TeX decides after much cogitation that it wants to use ffi it has to have a way to select that from the font. > You miss my point. I don't care where you put them. The point is that if > everyone decides for him or herself where to put them, we will have a mess. > If the UNICODE consortium decides it may be a mess, but everyone > will be dealing with the *same* mess. Unicode decided to set apart an area to mess around with, but to have the rest clean. This doesn't give you a licence to mess around everywhere. You are still missing my point. The private use area or whatever area is worthless. Only if everyone puts there stuff in the same place is there any sense in UNICODE numbers. Otherwise we are back to the same old mess... Regards, Berthold. 3-Mar-1997 10:40:05-GMT,1763;000000000000 Return-Path: Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id DAA17830 for ; Mon, 3 Mar 1997 03:40:04 -0700 (MST) Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <07885-0@josef.ifi.unizh.ch>; Mon, 3 Mar 1997 11:39:48 +0100 Date: Mon, 3 Mar 1997 11:39:47 +0100 (MET) From: "Martin J. Duerst" Sender: mduerst@enoshima To: "Berthold K.P. Horn" cc: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199703022246.RAA09318@kauai.ai.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 2 Mar 1997, Berthold K.P. Horn wrote: > The correct solution is to not have the system do the conversion > between character codepoints and glyph indices, but to leave that > to the font (which should know best). Quickdraw GX (from Apple) and > TrueType open are approaches to this, although I would prefer > it if the knowledge of the font about the mapping were available > as methods (in the OO sense) and not just as tables. > > I don't agree with this. GX hides under hood much of what a > typesetting application needs to know about (such as ligatures). > The main idea behind GX is to add some apparent typesetting capabilities > to dumb appications. Useless for TeX. I just said that GX and TT Open are going in the right direction. But I agree that they don't go far enough. I already say what I think is needed, see my other mail for more details about this. Regards, Martin. 3-Mar-1997 10:46:08-GMT,2428;000000000000 Return-Path: Received: from josef.ifi.unizh.ch (josef.ifi.unizh.ch [130.60.48.10]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id DAA17930 for ; Mon, 3 Mar 1997 03:46:07 -0700 (MST) Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <08019-0@josef.ifi.unizh.ch>; Mon, 3 Mar 1997 11:45:53 +0100 Date: Mon, 3 Mar 1997 11:45:52 +0100 (MET) From: "Martin J. Duerst" Sender: mduerst@enoshima To: "Berthold K.P. Horn" cc: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu Subject: Re: Unicode and math symbols In-Reply-To: <199703022251.RAA09322@kauai.ai.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 2 Mar 1997, Berthold K.P. Horn wrote: > > > And yes, just about all 30,000 fonts in Type 1 format have fi and fl. > > Nothing bad about that. Any good font should have these ligatures, > and a few more. But it shouldn't matter which number they have, > you should be able to send "f","i" to the font and it should > do the substitution on its own. > > That I do not agree with. Yes, low end applications will work this way > with GX and OpenType. But high end applications will need to work at > this level themselves, *not* let the system machinery do it. And after > the application decides to use a ligatures it must have a way of > selecting it from the font. I agree that "take this character string and typeset it in a nice way" is not the only method a font should provide. But it is a very important one, especially for low end applications. > If TeX decides after much cogitation that it wants to use ffi it has to > have a way to select that from the font. For an application, there can be other ways to select ligatures. One is to insert ZWNJ (zero width non-joiner) or similar codepoints at positions where ligaturing has to be suppressed. The other would be to use a method of the font that allows the application to ask what ligatures are present. I.e. calling this method with "ffi" will return true for fonts that contain an "ffi" ligature and false for fonts that don't. After that, the application could decide on its own whether e.g. it wants to try to use an "ff" ligature or an "fi" ligature, or none at all,... Regards, Martin. 4-Mar-1997 13:36:58-GMT,2663;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA25972 for ; Tue, 4 Mar 1997 06:36:57 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id IAA01890; Tue, 4 Mar 1997 08:34:24 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA10101; Tue, 4 Mar 1997 08:34:23 -0500 (EST) Date: Tue, 4 Mar 1997 08:34:23 -0500 (EST) Message-Id: <199703041334.IAA10101@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: mduerst@ifi.unizh.ch CC: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu In-reply-to: (mduerst@ifi.unizh.ch) Subject: Re: Unicode and math symbols Reply-to: bkph@ai.mit.edu Date: Mon, 3 Mar 1997 11:39:47 +0100 (MET) From: "Martin J. Duerst" Sender: mduerst@enoshima cc: C.A.Rowley@open.ac.uk, BNB@math.ams.org, tex-font@math.utah.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 2 Mar 1997, Berthold K.P. Horn wrote: > The correct solution is to not have the system do the conversion > between character codepoints and glyph indices, but to leave that > to the font (which should know best). Quickdraw GX (from Apple) and > TrueType open are approaches to this, although I would prefer > it if the knowledge of the font about the mapping were available > as methods (in the OO sense) and not just as tables. > > I don't agree with this. GX hides under hood much of what a > typesetting application needs to know about (such as ligatures). > The main idea behind GX is to add some apparent typesetting capabilities > to dumb appications. Useless for TeX. I just said that GX and TT Open are going in the right direction. But I agree that they don't go far enough. I already say what I think is needed, see my other mail for more details about this. Yes, and I just said that they go in the *wrong* direction :=). They make it possible for brain-dead applications like Microsoft Word to appear to have some typographic savy. However, they actually stand in the way of something like TeX that needs to put togther and take apart things like ligatures itself to do its paragraph line-breaking/ hyphenation algorithm. It is hiding under the hood all the machinery that needs to be accessible to sophisticated typesetting engine. Regards, Martin. 4-Mar-1997 21:13:17-GMT,2316;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id OAA07337 for ; Tue, 4 Mar 1997 14:13:16 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id NAA11544 for ; Tue, 4 Mar 1997 13:13:10 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id NAA25689 for tex-fonts@math.utah.edu; Tue, 4 Mar 1997 13:13:08 -0800 (PST) Message-Id: <199703042113.NAA25689@alonzo.cs.sfu.ca> Subject: AFMs for BlueSky CM Type 1 PS fonts... To: tex-fonts@math.utah.edu Date: Tue, 4 Mar 1997 13:13:07 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sometimes I think this is the strangest mailing list. We've spent lots of time talking about Unicode and `dotless j's, but haven't mentioned one of the most interesting developments of late, namely BlueSky's donation of it's type 1 CM fonts to the public domain. Perhaps the assumption is that this has been adequately covered in comp.text.tex? (Reminds me of how the addition of partial font downloading to dvips passed by just as quietly.) As things stand, however, I see a problem with the current distribution of these fonts. We currently have one distribution for Macintosh users and one for ATM users, but no complete distribution. What I mean here is that we're missing the AFM files for these fonts; it's true that there are tools that could generate AFM files both from the Mac font bundles and from the PFM files, and even perhaps from the original TFM files, yet I would have thought there would be cannonical AFM files from the creation of the font that may very well be more complete than any of these. Does anyone here (Berthold, for example?) have these AFM files that they could make available? Currently, I feel that my best bet may be to keep the AFM files from the BaKoMa fonts and use those (?). Melissa. P.S. Yes, you can claim that I don't really *need* AFM files most of the time, since I'm typesetting with TeX, but then I never use /bin/gdb yet it's nice to know it's there, just in case. 5-Mar-1997 9:39:43-GMT,2069;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA24612 for ; Wed, 5 Mar 1997 02:39:42 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA22125 for ; Wed, 5 Mar 1997 09:37:43 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Wed, 5 Mar 1997 09:38:45 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA00530; Wed, 5 Mar 1997 09:38:40 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id JAA11243; Wed, 5 Mar 1997 09:38:35 GMT Date: Wed, 5 Mar 1997 09:38:35 GMT Message-Id: <199703050938.JAA11243@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: oneill@cs.sfu.ca Cc: tex-fonts@math.utah.edu Subject: Re: AFMs for BlueSky CM Type 1 PS fonts... In-Reply-To: <199703042113.NAA25689@alonzo.cs.sfu.ca> References: <199703042113.NAA25689@alonzo.cs.sfu.ca> Melissa O'Neill writes: > of time talking about Unicode and `dotless j's, but haven't mentioned > one of the most interesting developments of late, namely BlueSky's > donation of it's type 1 CM fonts to the public domain. Perhaps the i suppose because technically it isn't news at all. interesting politically, agreed. since we have had BaKoMa for a couple of years, what we have now is just a bit better quality, yes? > (Reminds me of how the addition of partial font downloading to dvips > passed by just as quietly.) it still has problems, i'd say :-} > and one for ATM users, but no complete distribution. What I mean here > is that we're missing the AFM files for these fonts; it's true that good gracious, is this true? i am amazed. i hadnt looked, i assumed they existed sebastian 5-Mar-1997 11:32:57-GMT,2350;000000000000 Return-Path: Received: from bluesky.com ([204.200.195.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id EAA26660 for ; Wed, 5 Mar 1997 04:32:56 -0700 (MST) Received: from barry.bluesky.com by bluesky.com (5.65/Inherent1.1Mailhost) id AA05169; Wed, 5 Mar 97 03:38:16 PST Message-Id: <331D59E3.2467@bluesky.com> Date: Wed, 05 Mar 1997 03:32:53 -0800 From: Barry Smith Reply-To: barry@bluesky.com Organization: Blue Sky Research X-Mailer: Mozilla 3.01 (Macintosh; I; 68K) Mime-Version: 1.0 To: tex-fonts@math.utah.edu Subject: Re: AFMs for Blue Sky CM/PS fonts... References: <199703042113.NAA25689@alonzo.cs.sfu.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Melissa O'Neill wrote: > > As things stand, however, I see a problem with the current distribution > of these fonts. We currently have one distribution for Macintosh users > and one for ATM users, but no complete distribution. What I mean here > is that we're missing the AFM files for these fonts; it's true that > there are tools that could generate AFM files both from the Mac font > bundles and from the PFM files, and even perhaps from the original TFM > files, yet I would have thought there would be canonical AFM files from > the creation of the font that may very well be more complete than any > of these. > > Does anyone here (Berthold, for example?) have these AFM files that they > could make available? We do have some around here (somewhere), but the Macintosh distribution is all we've put up so far, and I don't know of any Mac apps that use AFM files [except Textures ;]. (I don't understand Melissa's comments re separate distributions for ATM and Macintosh users. Do I really need to?) FWIW, our AFM files were created "after the fact", not in any way as part of the font production process; in fact they were created specifically because the NeXT font system required them for installation. > Currently, I feel that my best bet may be to keep > the AFM files from the BaKoMa fonts and use those (?). This sounds just excellent. I know of nothing that should be different in the AFM files for these fonts. (Except, perhaps, some of the comments identifying copyright, producer, version, etc.) Barry Smith, Blue Sky Research barry@bluesky.com 5-Mar-1997 12:49:36-GMT,3256;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA28163 for ; Wed, 5 Mar 1997 05:49:35 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id EAA20201 for ; Wed, 5 Mar 1997 04:49:33 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id EAA01822 for tex-fonts@math.utah.edu; Wed, 5 Mar 1997 04:49:31 -0800 (PST) Message-Id: <199703051249.EAA01822@alonzo.cs.sfu.ca> Subject: Re: AFMs for Blue Sky CM/PS fonts... To: tex-fonts@math.utah.edu Date: Wed, 5 Mar 1997 04:49:31 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Barry Smith writes: > We do have some around here (somewhere), but the Macintosh distribution > is all we've put up so far, and I don't know of any Mac apps that use AFM > files [except Textures ;]. (I don't understand Melissa's comments re > separate distributions for ATM and Macintosh users. Do I really need to?) Berthold K.P. Horn in his Y&Y role provided Robin Fairbairns with a PFB+PFM distribution to put up on CTAN. (An an aside, one or other of them also downcased the names, which I think was a mistake, since I believe it's best if the external file name matches the internal name of the font). > FWIW, our AFM files were created "after the fact", not in any way as > part of the font production process; in fact they were created specifically > because the NeXT font system required them for installation. Surprise surprise, I'm on a NeXT. In fact, I don't think I'm really need them (since I'm working with TeX/TeXview/dvips and not trying to use them in other applications), but I think both NeXT, OS/2 and some Unix users are used to seeing AFM files with their fonts. > This sounds just excellent. I know of nothing that should be different > in the AFM files for these fonts. (Except, perhaps, some of the comments > identifying copyright, producer, version, etc.) Well, in practice it looks like the only real difference between the BaKoMa fonts and the BlueSky ones is that the BlueSky ones are freer, since they're now in the public domain. I compared Metafont, BaKoMa and BlueSky fonts on my aged 300dpi printer and on-screen on my NeXT and couldn't find anything to recommend the BlueSky fonts over the BaKoMa ones quality wise. This may be a shame or a triumph (depending on your perspective), given the fact that hours of human effort went into hinting the BlueSky fonts and a machine came up with the hints for the BaKoMa ones. (*) Later today I might compare the fonts under Acrobat and on a modern 600dpi printer. (*) Actually, it's probably a shame either way since Basil K. Malyshev's software is now languishing on a disk somewhere, untouched, unused, while the EC fonts are out there aching to be converted to type1 format. Regards, Melissa. P.S. Hmm, it's 4:40am, so I guess I can't say this isn't something I'll lose any sleep over. (And I only got up to let out the cat, oh well...) 5-Mar-1997 12:51:48-GMT,3382;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA28216 for ; Wed, 5 Mar 1997 05:51:48 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id HAA26811; Wed, 5 Mar 1997 07:51:43 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id HAA10660; Wed, 5 Mar 1997 07:51:37 -0500 (EST) Date: Wed, 5 Mar 1997 07:51:37 -0500 (EST) Message-Id: <199703051251.HAA10660@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: oneill@cs.sfu.ca CC: tex-fonts@math.utah.edu In-reply-to: <199703042113.NAA25689@alonzo.cs.sfu.ca> (oneill@cs.sfu.ca) Subject: Re: AFMs for BlueSky CM Type 1 PS fonts... Reply-to: bkph@ai.mit.edu Melissa writes: Sometimes I think this is the strangest mailing list. We've spent lots of time talking about Unicode and `dotless j's, but haven't mentioned one of the most interesting developments of late, namely BlueSky's donation of it's type 1 CM fonts to the public domain. Some corrections: it was not quite a `donation', AMS, SIAM, Springer, BSR and Y&Y worked out some arrangement for this to happen. All parties should get credit. I assume that AMS is preparing some kind of announcement. And the fonts are *not* in the public domain, they have AMS copyright. The intents is to have them be used freely, but it is important to retain the copyright to prevent mischief and misuse. Perhaps the assumption is that this has been adequately covered in comp.text.tex? Certainly a lot of postings there with that subject line, but on other topics.. (Reminds me of how the addition of partial font downloading to dvips passed by just as quietly.) Well, it isn't news in the sense that it has been in DVIPSONE since 1990 and nobody seemed to make much of a fuss over that either :=) As things stand, however, I see a problem with the current distribution of these fonts. We currently have one distribution for Macintosh users and one for ATM users, but no complete distribution. What I mean here is that we're missing the AFM files for these fonts; it's true that there are tools that could generate AFM files both from the Mac font bundles and from the PFM files, and even perhaps from the original TFM files, yet I would have thought there would be cannonical AFM files from the creation of the font that may very well be more complete than any of these. Does anyone here (Berthold, for example?) have these AFM files that they could make available? Currently, I feel that my best bet may be to keep the AFM files from the BaKoMa fonts and use those (?). * The AFM files exist, of course. It is up to AMS to decide what to do * with them. As you point out, they are not very important for use with * TeX since (i) everyone already has TFM files and (ii) CM fonts have * fixed encoding so no need to make new TFMs. However, Display * PostScript users will want PFA and AFM files... Melissa. P.S. Yes, you can claim that I don't really *need* AFM files most of the time, since I'm typesetting with TeX, but then I never use /bin/gdb yet it's nice to know it's there, just in case. 5-Mar-1997 13:39:01-GMT,1432;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmzc.zdv.Uni-Mainz.DE [134.93.8.34]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA29167 for ; Wed, 5 Mar 1997 06:38:59 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IG5ARKKYGGO1AN5I@MZDMZA.ZDV.UNI-MAINZ.DE>; Wed, 05 Mar 1997 14:39:43 +0100 Date: Wed, 05 Mar 1997 14:39:43 +0100 Subject: Re: AFMs for Blue Sky CM/PS fonts... To: barry@bluesky.com, tex-fonts@math.utah.edu Message-id: <01IG5ARKL51UO1AN5I@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: MZDMZA::IN%"barry@bluesky.com" X-VMS-Cc: IN"tex-fonts@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT There are ,,official`` afm files for the cm fonts made by Pierre MacKay using gf2afm on CTAN://fonts/cm/afm. Pierre MacKay has invested some work to render all cm font dimensions in an afm file. --J"org Knappen. >From the README: These Computer Modern afm files are made up by way of a METAFONT compilation, and so represent Knuth's designs exactly. I have included everything but cmff10 cmfi10 cmfib10 and cminch. You have to draw the line somewhere. No information that can be preserved is discarded. I have invented names for fontdimens that afm does not know about. [...] 5-Mar-1997 14:08:17-GMT,1571;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA29755 for ; Wed, 5 Mar 1997 07:08:16 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA01527 for ; Wed, 5 Mar 1997 14:06:16 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Wed, 5 Mar 1997 14:07:59 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA14287; Wed, 5 Mar 1997 14:07:56 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id OAA08362; Wed, 5 Mar 1997 14:07:53 GMT Date: Wed, 5 Mar 1997 14:07:53 GMT Message-Id: <199703051407.OAA08362@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: barry@bluesky.com Cc: tex-fonts@math.utah.edu Subject: Re: AFMs for Blue Sky CM/PS fonts... In-Reply-To: <331D59E3.2467@bluesky.com> References: <199703042113.NAA25689@alonzo.cs.sfu.ca> <331D59E3.2467@bluesky.com> Its a shame the Blue Sky font set doesn't cover the same ground as the BaKoMa one. It means in practice that people have to have both together. The next edition TeX Live CD will have the fonts on, for what its worth, augmented by BaKoMa as needed (including AFMs from the latter) sebastian 5-Mar-1997 14:11:36-GMT,2222;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA29840 for ; Wed, 5 Mar 1997 07:11:35 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA01633 for ; Wed, 5 Mar 1997 14:09:33 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Wed, 5 Mar 1997 14:11:31 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA15281; Wed, 5 Mar 1997 14:11:29 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id OAA08751; Wed, 5 Mar 1997 14:11:25 GMT Date: Wed, 5 Mar 1997 14:11:25 GMT Message-Id: <199703051411.OAA08751@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: oneill@cs.sfu.ca Cc: tex-fonts@math.utah.edu Subject: Re: AFMs for Blue Sky CM/PS fonts... In-Reply-To: <199703051249.EAA01822@alonzo.cs.sfu.ca> References: <199703051249.EAA01822@alonzo.cs.sfu.ca> Melissa O'Neill writes: > PFB+PFM distribution to put up on CTAN. (An an aside, one or other of > them also downcased the names, which I think was a mistake, since I > believe it's best if the external file name matches the internal name > of the font). unless your OS is case insensitive, as all are except Unix (?). i cannot, for instance, preserve the Blue Sky / BaKoMa distinction by name case on a CD-ROM > Well, in practice it looks like the only real difference between the > BaKoMa fonts and the BlueSky ones is that the BlueSky ones are freer, and the Blue Sky free ones dont cover eg the AMS symbol fonts :-} > (*) Actually, it's probably a shame either way since Basil K. Malyshev's > software is now languishing on a disk somewhere, untouched, unused, > while the EC fonts are out there aching to be converted to type1 hear hear. though i don't quite have your faith that Basil didn't hand-tinker at times sebastian 5-Mar-1997 14:26:38-GMT,1960;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA00311 for ; Wed, 5 Mar 1997 07:26:36 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA02272 for ; Wed, 5 Mar 1997 14:24:37 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Wed, 5 Mar 1997 14:26:02 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA16217; Wed, 5 Mar 1997 14:25:57 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id OAA09831; Wed, 5 Mar 1997 14:25:52 GMT Date: Wed, 5 Mar 1997 14:25:52 GMT Message-Id: <199703051425.OAA09831@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: bkph@ai.mit.edu Cc: oneill@cs.sfu.ca, tex-fonts@math.utah.edu Subject: Re: AFMs for BlueSky CM Type 1 PS fonts... In-Reply-To: <199703051251.HAA10660@kauai.ai.mit.edu> References: <199703042113.NAA25689@alonzo.cs.sfu.ca> <199703051251.HAA10660@kauai.ai.mit.edu> Berthold K. P. Horn writes: > And the fonts are *not* in the public domain, they have AMS copyright. > The intents is to have them be used freely, but it is important to > retain the copyright to prevent mischief and misuse. Barry's readme says not be enforced. These fonts may be used in any fashion for any purpose, and may be redistributed by anyone who wishes. We ask only one restriction: if you make derivative versions of these fonts, or change them in any way, kindly _remove_ our copyright notices. implied that mischief and abuse is fine by him (if we change the name). is that not what _you_ mean? sebastian 5-Mar-1997 14:45:07-GMT,1774;000000000000 Return-Path: Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA00789; Wed, 5 Mar 1997 07:45:07 -0700 (MST) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.4/8.8.4) id HAA22659; Wed, 5 Mar 1997 07:45:05 -0700 (MST) Date: Wed, 5 Mar 1997 07:45:05 -0700 (MST) To: tex-fonts@math.utah.edu Cc: beebe@math.utah.edu X-US-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: missing AFMs for Blue Sky CM/PS fonts Message-ID: Please note that other (non-TeX) programs that use PostScript font DO need the .afm files; examples are my lptops (text -> PostScript) utility, Adobe's Transcript package, graphics software that supports PostScript fonts, and anything else that needs character metrics. The .pfa/.pfb files contain neither metrics, nor kerning information, and in any event, are much more complex to parse than .afm file ares I'm therefore pleased by Barry Smith's report that the BaKoMa .afm files can be used with the Blue Sky CM/PS fonts. ======================================================================== 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 URL: http://www.math.utah.edu/~beebe Salt Lake City, UT 84112, USA ======================================================================== 5-Mar-1997 15:42:37-GMT,1292;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA02353 for ; Wed, 5 Mar 1997 08:42:36 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id QAA28155 for ; Wed, 5 Mar 1997 16:42:21 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id QAA05029; Wed, 5 Mar 1997 16:49:54 +0100 (MET) Date: Wed, 5 Mar 1997 16:49:54 +0100 (MET) Message-Id: <199703051549.QAA05029@mozart.ujf-grenoble.fr> From: Thierry Bouche To: tex-fonts@math.utah.edu Subject: Blue Sky CM/PS fonts... Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII If I made virtual T1 fonts based on these CM type1 glyphs as much as possible and bakoma's dc 1.2 glyphs, would it be of any utility? This would NOT be metrically compatible with EC however. I would give them a name like fcmr8t10 (BTW is 8t the right encoding name for TRUE T1 encoding? the full T1 encoding is yet more expertized than 9e!) thierry 5-Mar-1997 15:49:48-GMT,1193;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA02565 for ; Wed, 5 Mar 1997 08:49:47 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id QAA28674 for ; Wed, 5 Mar 1997 16:49:31 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id QAA05397; Wed, 5 Mar 1997 16:57:03 +0100 (MET) Date: Wed, 5 Mar 1997 16:57:03 +0100 (MET) Message-Id: <199703051557.QAA05397@mozart.ujf-grenoble.fr> From: Thierry Bouche To: tex-fonts@math.utah.edu Subject: upright math greek letters Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII are there upright math greek letters available? (to match cm text) is there a list of available greek more generally? thanks Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 5-Mar-1997 16:18:35-GMT,1781;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA03462 for ; Wed, 5 Mar 1997 09:18:33 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id LAA07060; Wed, 5 Mar 1997 11:18:18 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id LAA10792; Wed, 5 Mar 1997 11:18:17 -0500 (EST) Date: Wed, 5 Mar 1997 11:18:17 -0500 (EST) Message-Id: <199703051618.LAA10792@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: KNAPPEN@vkpmzd.kph.uni-mainz.de CC: barry@bluesky.com, tex-fonts@math.utah.edu In-reply-to: <01IG5ARKL51UO1AN5I@MZDMZA.ZDV.UNI-MAINZ.DE> (KNAPPEN@VKPMZD.kph.Uni-Mainz.DE) Subject: Re: AFMs for Blue Sky CM/PS fonts... Reply-to: bkph@ai.mit.edu There are ,,official`` afm files for the cm fonts made by Pierre MacKay using gf2afm on CTAN://fonts/cm/afm. Pierre MacKay has invested some work to render all cm font dimensions in an afm file. --J"org Knappen. >From the README: These Computer Modern afm files are made up by way of a METAFONT compilation, and so represent Knuth's designs exactly. I have included everything but cmff10 cmfi10 cmfib10 and cminch. You have to draw the line somewhere. No information that can be preserved is discarded. I have invented names for fontdimens that afm does not know about. [...] These are *not* the official AFM files for the BSR CM fonts. For a start, they have rounded advance widths and no ligatures links. Please be patient. Let AMS decide when and how to deal with this. Berthold. 5-Mar-1997 16:20:37-GMT,1789;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA03476 for ; Wed, 5 Mar 1997 09:20:04 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id RAA01328; Wed, 5 Mar 1997 17:19:57 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id RAA06326; Wed, 5 Mar 1997 17:27:29 +0100 (MET) Date: Wed, 5 Mar 1997 17:27:29 +0100 (MET) Message-Id: <199703051627.RAA06326@mozart.ujf-grenoble.fr> From: Thierry Bouche To: KNAPPEN@vkpmzd.kph.uni-mainz.de Cc: tex-fonts@math.utah.edu Subject: Re: AFMs for Blue Sky CM/PS fonts... In-Reply-To: <01IG5ARKL51UO1AN5I@MZDMZA.ZDV.UNI-MAINZ.DE> References: <01IG5ARKL51UO1AN5I@MZDMZA.ZDV.UNI-MAINZ.DE> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: AFMs for Blue Sky CM/PS fonts... », KNAPPEN@VKPMZD.kph.Uni-Mainz.DE écrit : > There are ,,official`` afm files for the cm fonts made by Pierre MacKay > using gf2afm on CTAN://fonts/cm/afm. > > Pierre MacKay has invested some work to render all cm font dimensions in > an afm file. > > --J"org Knappen. I checked that using fontinst on these afm files in the following way \afmtomtx{cmr10}{cmr10} \mtxtopl{cmr10}{cmr10} yields .pl files that are (after pltotf/tftopl) exactly equal to the ones from metafont cms. sounds good. Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 5-Mar-1997 16:23:20-GMT,1478;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA03568 for ; Wed, 5 Mar 1997 09:23:18 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id LAA07357; Wed, 5 Mar 1997 11:23:06 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id LAA10800; Wed, 5 Mar 1997 11:23:00 -0500 (EST) Date: Wed, 5 Mar 1997 11:23:00 -0500 (EST) Message-Id: <199703051623.LAA10800@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: s.rahtz@elsevier.co.uk CC: barry@bluesky.com, tex-fonts@math.utah.edu In-reply-to: <199703051407.OAA08362@lochnagarn.elsevier.co.uk> (message from Sebastian Rahtz on Wed, 5 Mar 1997 14:07:53 GMT) Subject: Re: AFMs for Blue Sky CM/PS fonts... Reply-to: bkph@ai.mit.edu Its a shame the Blue Sky font set doesn't cover the same ground as the BaKoMa one. It means in practice that people have to have both together. What is the difference? The AMS fonts? Wait for the end of the year maybe? The next edition TeX Live CD will have the fonts on, I assume you asked the copyright holder :=) for what its worth, augmented by BaKoMa as needed (including AFMs from the latter). Please use the correct AFM files for the BSR fonts at least! sebastian 5-Mar-1997 16:25:03-GMT,2677;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA03626 for ; Wed, 5 Mar 1997 09:25:02 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id IAA25108; Wed, 5 Mar 1997 08:24:55 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id IAA01970; Wed, 5 Mar 1997 08:24:53 -0800 (PST) Message-Id: <199703051624.IAA01970@alonzo.cs.sfu.ca> Subject: Re: AFMs for BlueSky CM Type 1 PS fonts... To: bkph@ai.mit.edu Date: Wed, 5 Mar 1997 08:24:53 -0800 (PST) Cc: tex-fonts@math.utah.edu In-Reply-To: <199703051251.HAA10660@kauai.ai.mit.edu> from "Berthold K.P. Horn" at Mar 5, 97 07:51:37 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I wrote: >> [We] haven't mentioned one of the most interesting developments of >> late, namely BlueSky's donation of it's type 1 CM fonts to the public >> domain. ... and Berthold K.P. Horn replied: > Some corrections: it was not quite a `donation', AMS, SIAM, Springer, > BSR and Y&Y worked out some arrangement for this to happen. All > parties should get credit. I assume that AMS is preparing some kind > of announcement. > > And the fonts are *not* in the public domain, they have AMS copyright. > The intents is to have them be used freely, but it is important to > retain the copyright to prevent mischief and misuse. Well, there seem to be some wires crossed somewhere, since the README file on CTAN states quite clearly that they're now in the public domain. >From the README, written by Barry Smith of Blue Sky Research. | | Computer Modern PostScript fonts released to the public domain | | PORTLAND, OREGON --- We of Blue Sky Research are delighted to | announce the release, into the public domain, of a complete set of | the typefaces of Computer Modern in the form of 75 PostScript text | and symbol fonts. ... it goes on to say: | These fonts may be used in any fashion for any purpose, and may be | redistributed by anyone who wishes. We ask only one restriction: if | you make derivative versions of these fonts, or change them in any way, | kindly _remove_ our copyright notices. ... which to me, given the above, has the tone of a `respectful request' rather than anything with any legal power for enforcement behind it (i.e. if they are in the public domain, people don't have to respect the request to remove the copyright notices when changes are made). Regards, Melissa. 5-Mar-1997 16:28:30-GMT,2379;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA03708 for ; Wed, 5 Mar 1997 09:28:29 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id LAA07595; Wed, 5 Mar 1997 11:28:24 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id LAA10806; Wed, 5 Mar 1997 11:28:22 -0500 (EST) Date: Wed, 5 Mar 1997 11:28:22 -0500 (EST) Message-Id: <199703051628.LAA10806@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: barry@bluesky.com CC: tex-fonts@math.utah.edu In-reply-to: <331D59E3.2467@bluesky.com> (message from Barry Smith on Wed, 05 Mar 1997 03:32:53 -0800) Subject: Re: AFMs for Blue Sky CM/PS fonts... Reply-to: bkph@ai.mit.edu > Does anyone here (Berthold, for example?) have these AFM files that they > could make available? We do have some around here (somewhere), but the Macintosh distribution is all we've put up so far, and I don't know of any Mac apps that use AFM files [except Textures ;]. (I don't understand Melissa's comments re separate distributions for ATM and Macintosh users. Do I really need to?) FWIW, our AFM files were created "after the fact", not in any way as part of the font production process; in fact they were created specifically because the NeXT font system required them for installation. Hmm, not quite, FONTONE which was to tell for the final output depends critically on the AFM files :=). > Currently, I feel that my best bet may be to keep > the AFM files from the BaKoMa fonts and use those (?). This sounds just excellent. I know of nothing that should be different in the AFM files for these fonts. (Except, perhaps, some of the comments identifying copyright, producer, version, etc.) They are different. Please don't use them. They do not have all the fields needed by DPS e.g. Wait for AMS to decide what to do with the AFM files. As Barry says, they are *only* needed for Display PostScript. A related question is whether PFA files should be posted as well, since DPS needs those. Although it is easy to convert PFA to PFB and vice versa using some PD software. Berthold Horn. 5-Mar-1997 16:29:34-GMT,2734;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA03729 for ; Wed, 5 Mar 1997 09:29:31 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id QAA07231 for ; Wed, 5 Mar 1997 16:27:19 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Wed, 5 Mar 1997 16:28:47 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id QAA21473; Wed, 5 Mar 1997 16:28:44 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id QAA21978; Wed, 5 Mar 1997 16:28:38 GMT Date: Wed, 5 Mar 1997 16:28:38 GMT Message-Id: <199703051628.QAA21978@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: bkph@ai.mit.edu Cc: barry@bluesky.com, tex-fonts@math.utah.edu Subject: Re: AFMs for Blue Sky CM/PS fonts... In-Reply-To: <199703051623.LAA10800@kauai.ai.mit.edu> References: <199703051407.OAA08362@lochnagarn.elsevier.co.uk> <199703051623.LAA10800@kauai.ai.mit.edu> Berthold K. P. Horn writes: > > What is the difference? The AMS fonts? Wait for the end of the year maybe? I list the extra ones (in addition to AMS). dont ask me what or why the exist... > The next edition TeX Live CD will have the fonts on, > I assume you asked the copyright holder :=) i read Barry's Readme :-} > for what its worth, augmented by BaKoMa as needed (including AFMs > from the latter). > > Please use the correct AFM files for the BSR fonts at least! sure, if they get released. sebastian cmbsy6.pfb cmcbxti1.pfb cmcss12.pfb cmcti10.pfb cmcyr5.pfb cmbsy7.pfb cmccsc10.pfb cmcss17.pfb cmcti12.pfb cmcyr6.pfb cmbsy8.pfb cmccsc8.pfb cmcss8.pfb cmcti7.pfb cmcyr7.pfb cmbsy9.pfb cmccsc9.pfb cmcss9.pfb cmcti8.pfb cmcyr8.pfb cmcb10.pfb cmcitt10.pfb cmcssbx1.pfb cmcti9.pfb cmcyr9.pfb cmcbx10.pfb cmcsc8.pfb cmcssdc1.pfb cmctt10.pfb cmex7.pfb cmcbx12.pfb cmcsc9.pfb cmcssi10.pfb cmctt12.pfb cmex8.pfb cmcbx5.pfb cmcsl10.pfb cmcssi12.pfb cmctt8.pfb cmex9.pfb cmcbx6.pfb cmcsl12.pfb cmcssi17.pfb cmctt9.pfb cmmib6.pfb cmcbx7.pfb cmcsl8.pfb cmcssi8.pfb cmcu10.pfb cmmib7.pfb cmcbx8.pfb cmcsl9.pfb cmcssi9.pfb cmcyr10.pfb cmmib8.pfb cmcbx9.pfb cmcsltt1.pfb cmcssq8.pfb cmcyr12.pfb cmmib9.pfb cmcbxsl1.pfb cmcss10.pfb cmcssqi8.pfb cmcyr17.pfb 5-Mar-1997 16:29:57-GMT,1789;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA03746 for ; Wed, 5 Mar 1997 09:29:52 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id RAA01328; Wed, 5 Mar 1997 17:19:57 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id RAA06326; Wed, 5 Mar 1997 17:27:29 +0100 (MET) Date: Wed, 5 Mar 1997 17:27:29 +0100 (MET) Message-Id: <199703051627.RAA06326@mozart.ujf-grenoble.fr> From: Thierry Bouche To: KNAPPEN@vkpmzd.kph.uni-mainz.de Cc: tex-fonts@math.utah.edu Subject: Re: AFMs for Blue Sky CM/PS fonts... In-Reply-To: <01IG5ARKL51UO1AN5I@MZDMZA.ZDV.UNI-MAINZ.DE> References: <01IG5ARKL51UO1AN5I@MZDMZA.ZDV.UNI-MAINZ.DE> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: AFMs for Blue Sky CM/PS fonts... », KNAPPEN@VKPMZD.kph.Uni-Mainz.DE écrit : > There are ,,official`` afm files for the cm fonts made by Pierre MacKay > using gf2afm on CTAN://fonts/cm/afm. > > Pierre MacKay has invested some work to render all cm font dimensions in > an afm file. > > --J"org Knappen. I checked that using fontinst on these afm files in the following way \afmtomtx{cmr10}{cmr10} \mtxtopl{cmr10}{cmr10} yields .pl files that are (after pltotf/tftopl) exactly equal to the ones from metafont cms. sounds good. Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 5-Mar-1997 16:36:19-GMT,2109;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA03956 for ; Wed, 5 Mar 1997 09:36:18 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id LAA07993; Wed, 5 Mar 1997 11:36:13 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id LAA10810; Wed, 5 Mar 1997 11:36:12 -0500 (EST) Date: Wed, 5 Mar 1997 11:36:12 -0500 (EST) Message-Id: <199703051636.LAA10810@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: oneill@cs.sfu.ca CC: tex-fonts@math.utah.edu In-reply-to: <199703051249.EAA01822@alonzo.cs.sfu.ca> (oneill@cs.sfu.ca) Subject: Re: AFMs for Blue Sky CM/PS fonts... Reply-to: bkph@ai.mit.edu Well, in practice it looks like the only real difference between the BaKoMa fonts and the BlueSky ones is that the BlueSky ones are freer, since they're now in the public domain. I compared Metafont, BaKoMa You may find a difference in file size and rendering speed also. and BlueSky fonts on my aged 300dpi printer and on-screen on my NeXT and couldn't find anything to recommend the BlueSky fonts over the BaKoMa ones quality wise. This may be a shame or a triumph (depending on your perspective), given the fact that hours of human effort went into hinting the BlueSky fonts and a machine came up with the hints for the BaKoMa ones. (*) You are not going to see a huge difference at 300 dpi unless you know what to look for (like `dogleg' phenonmen on R and `epaulets' on `M'). The difference is more noticable on screen at 96dpi or 120 dpi in Windows, or 72 dpi on the Mac. NexT does not provide a good comparison test because it is not using a top quality rasterizer. And on printers it will depend on the quality of the rasterizer also (i.e. is it a true Adobe rasterizer). Later today I might compare the fonts under Acrobat and on a modern 600dpi printer. Berthold. 5-Mar-1997 16:51:44-GMT,2549;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA04369 for ; Wed, 5 Mar 1997 09:51:43 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id LAA08808; Wed, 5 Mar 1997 11:51:29 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id LAA10825; Wed, 5 Mar 1997 11:51:23 -0500 (EST) Date: Wed, 5 Mar 1997 11:51:23 -0500 (EST) Message-Id: <199703051651.LAA10825@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: s.rahtz@elsevier.co.uk CC: barry@bluesky.com, tex-fonts@math.utah.edu In-reply-to: <199703051628.QAA21978@lochnagarn.elsevier.co.uk> (message from Sebastian Rahtz on Wed, 5 Mar 1997 16:28:38 GMT) Subject: Re: AFMs for Blue Sky CM/PS fonts... Reply-to: bkph@ai.mit.edu Thanks. Some of those are bold math, which are not in CM, but in AMS font set (supposedly to be released end of the year). Also odd sizes of cmex are of course not in CM but in AMS font set, as are odd sizes of CMCSC From: Sebastian Rahtz I list the extra ones (in addition to AMS). dont ask me what or why the exist... Well, CMBSY*, CMMIB* are extra bold math sizes that are *not* in Knuth's 75 CM set, but are in the AMS font set: cmbsy6.pfb cmbsy7.pfb cmbsy8.pfb cmbsy9.pfb cmmib9.pfb cmmib8.pfb cmmib7.pfb cmmib6.pfb Ditto for odd sizes of CMEX* and CMCSC*: cmex7.pfb cmex8.pfb cmex9.pfb cmcsc8.pfb cmcsc9.pfb I believe the bulk of the fonts in your list (the CMC* fonts) are however extended with Cyrillic - which is another story cmcbxti1.pfb cmcss12.pfb cmcti10.pfb cmcyr5.pfb cmccsc10.pfb cmcss17.pfb cmcti12.pfb cmcyr6.pfb cmccsc8.pfb cmcss8.pfb cmcti7.pfb cmcyr7.pfb cmccsc9.pfb cmcss9.pfb cmcti8.pfb cmcyr8.pfb cmcb10.pfb cmcitt10.pfb cmcssbx1.pfb cmcti9.pfb cmcbx10.pfb cmcssdc1.pfb cmctt10.pfb cmcbx12.pfb cmcssi10.pfb cmctt12.pfb cmcyr9.pfb cmcbx5.pfb cmcsl10.pfb cmcssi12.pfb cmctt8.pfb cmcbx6.pfb cmcsl12.pfb cmcssi17.pfb cmctt9.pfb cmcbx7.pfb cmcsl8.pfb cmcssi8.pfb cmcu10.pfb cmcbx8.pfb cmcsl9.pfb cmcssi9.pfb cmcyr10.pfb cmcbx9.pfb cmcsltt1.pfb cmcssq8.pfb cmcyr12.pfb cmcbxsl1.pfb cmcss10.pfb cmcssqi8.pfb cmcyr17.pfb 5-Mar-1997 16:57:44-GMT,2231;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA04543 for ; Wed, 5 Mar 1997 09:57:43 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id LAA09024; Wed, 5 Mar 1997 11:57:33 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id LAA10832; Wed, 5 Mar 1997 11:57:27 -0500 (EST) Date: Wed, 5 Mar 1997 11:57:27 -0500 (EST) Message-Id: <199703051657.LAA10832@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: thierry.bouche@ujf-grenoble.fr CC: KNAPPEN@vkpmzd.kph.uni-mainz.de, tex-fonts@math.utah.edu In-reply-to: <199703051627.RAA06326@mozart.ujf-grenoble.fr> (message from Thierry Bouche on Wed, 5 Mar 1997 17:27:29 +0100 (MET)) Subject: Re: AFMs for Blue Sky CM/PS fonts... Reply-to: bkph@ai.mit.edu Date: Wed, 5 Mar 1997 17:27:29 +0100 (MET) From: Thierry Bouche Cc: tex-fonts@math.utah.edu References: <01IG5ARKL51UO1AN5I@MZDMZA.ZDV.UNI-MAINZ.DE> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: AFMs for Blue Sky CM/PS fonts... », KNAPPEN@VKPMZD.kph.Uni-Mainz.DE écrit : > There are ,,official`` afm files for the cm fonts made by Pierre MacKay > using gf2afm on CTAN://fonts/cm/afm. > > Pierre MacKay has invested some work to render all cm font dimensions in > an afm file. > > --J"org Knappen. I checked that using fontinst on these afm files in the following way \afmtomtx{cmr10}{cmr10} \mtxtopl{cmr10}{cmr10} yields .pl files that are (after pltotf/tftopl) exactly equal to the ones from metafont cms. sounds good. Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ It is hard to imagine how that could be unless your PL files are also corrupted, since these AFM files have the wrong advance widths. 5-Mar-1997 17:17:51-GMT,1556;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmzc.zdv.Uni-Mainz.DE [134.93.8.34]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA05188 for ; Wed, 5 Mar 1997 10:17:50 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IG5I8WB2OWF9DS5E@MZDMZA.ZDV.UNI-MAINZ.DE>; Wed, 05 Mar 1997 18:18:21 +0100 Date: Wed, 05 Mar 1997 18:18:21 +0100 Subject: Re: AFMs for Blue Sky CM/PS fonts... To: bkph@ai.mit.edu, tex-fonts@math.utah.edu Message-id: <01IG5I8WC59UF9DS5E@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: MZDMZA::IN%"bkph@ai.mit.edu" X-VMS-Cc: IN"tex-fonts@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Berthold, >It is hard to imagine how that could be unless your PL files are >also corrupted, since these AFM files have the wrong advance widths. What do you mean by saying `advance width'? A glyph has afaik two different `widths': a) The tfm width, which is measured in TeX scaled points (typically) and is resolution independent. b) The value chardx, which is the real advance taken by the renderer (printer or screen) and which is necessarily an integer number of pixels. The latter value is not relevant for TeX tfm files, but is recorded in the gf and pk files. If the you mean the latter value, it can be corrected in the afm files without changing the related tfm files. --J"org Knappen 5-Mar-1997 17:37:56-GMT,1713;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA05816 for ; Wed, 5 Mar 1997 10:37:53 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id SAA07985; Wed, 5 Mar 1997 18:37:46 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id SAA08780; Wed, 5 Mar 1997 18:45:19 +0100 (MET) Date: Wed, 5 Mar 1997 18:45:19 +0100 (MET) Message-Id: <199703051745.SAA08780@mozart.ujf-grenoble.fr> From: Thierry Bouche To: bkph@ai.mit.edu CC: tex-fonts@math.utah.edu Subject: Re: AFMs for Blue Sky CM/PS fonts... In-Reply-To: <199703051657.LAA10832@kauai.ai.mit.edu> References: <199703051627.RAA06326@mozart.ujf-grenoble.fr> <199703051657.LAA10832@kauai.ai.mit.edu> Reply-To: thierry.bouche@ujf-grenoble.fr Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII > > It is hard to imagine how that could be unless your PL files are > also corrupted, since these AFM files have the wrong advance widths. > ah yes, pardon me, it's the same `feature' of tftopl & kpathsea: they were the same beacuse although I launched tftopl from another directory, always the metafont ones were disassembled. moreover, one should add some support in fontinst to take advantage of the fontdimens declared in the afms, and use installrawfont rather than too low-level conversion commands. They are slightly different indeed... but the bakoma ones are nonstandard (including commas...) 5-Mar-1997 18:28:36-GMT,3197;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA07300 for ; Wed, 5 Mar 1997 11:28:35 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id KAA02446; Wed, 5 Mar 1997 10:28:33 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id KAA02161; Wed, 5 Mar 1997 10:28:31 -0800 (PST) Message-Id: <199703051828.KAA02161@alonzo.cs.sfu.ca> Subject: Re: AFMs for Blue Sky CM/PS fonts... To: bkph@ai.mit.edu Date: Wed, 5 Mar 1997 10:28:30 -0800 (PST) Cc: KNAPPEN@vkpmzd.kph.uni-mainz.de, barry@bluesky.com, tex-fonts@math.utah.edu In-Reply-To: <199703051618.LAA10792@kauai.ai.mit.edu> from "Berthold K.P. Horn" at Mar 5, 97 11:18:17 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Berthold Horn writes: > As Barry says, they are *only* needed for Display PostScript. > > A related question is whether PFA files should be posted as well, > since DPS needs those. Although it is easy to convert PFA to PFB > and vice versa using some PD software. This is misleading, since Display PostScript systems can do pretty much any rendering that regular PostScript system can do, and so in use with TeX these fonts do not need AFMs. Certainly on my NeXT I can use the BlueSky fonts with TeXview or with dvips and Preview without having the AFMs installed. Similarly, I'm happily using the PFB files in this setup. Only if I were setting the font up as a native font for NEXTSTEP applications (which, if I recall correctly, itself is problematic owing to the encoding of the font -- something to do with the space glyph) would I need to have the font in PFA format and need to have the AFM files. ... in another posting, Berthold Horn writes: > NeXT does not provide a good comparison test because it is not using a > top quality rasterizer. And on printers it will depend on the quality > of the rasterizer also (i.e. is it a true Adobe rasterizer). Huh? Have you ever actually seen these fonts on a NeXT? The NeXT has an Adobe rasterizer, which in general is very up to date with Adobe's latest PostScript version. In my opinion, it does a better job of rendering fonts than ATM running on the Mac in my office. This was also confirmed by someone from Adobe (who admittedly may have been a know-nothing sales dweeb), who, when questioned about this, told me that the Display PostScript architecture was better than ATM. (I'm talking here about rendering without anti-aliasing. On our Mac the anti-aliased fonts look blurry and grey and are next-to-useless for readability, even if they do look `cool' at a glance. In any case, various software on NeXT's DPS does anti-aliased fonts, including a version of TeXview, albeit one which I don't have. In any case, I'm not talking about anti-aliased rendering, perhaps this is indeed where the superiority that you believe ATM to have lies, and this is how we can have such differing views?) Regards, Melissa. 5-Mar-1997 19:10:06-GMT,2685;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id MAA08528 for ; Wed, 5 Mar 1997 12:10:04 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id OAA16433; Wed, 5 Mar 1997 14:09:58 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id OAA10888; Wed, 5 Mar 1997 14:09:54 -0500 (EST) Date: Wed, 5 Mar 1997 14:09:54 -0500 (EST) Message-Id: <199703051909.OAA10888@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: KNAPPEN@vkpmzd.kph.uni-mainz.de In-reply-to: <01IG5I8WC59UF9DS5E@MZDMZA.ZDV.UNI-MAINZ.DE> (KNAPPEN@VKPMZD.kph.Uni-Mainz.DE) Subject: Re: AFMs for Blue Sky CM/PS fonts... cc: tex-fonts@math.utah.edu Reply-to: bkph@ai.mit.edu >It is hard to imagine how that could be unless your PL files are >also corrupted, since these AFM files have the wrong advance widths. What do you mean by saying `advance width'? A glyph has afaik two different `widths': a) The tfm width, which is measured in TeX scaled points (typically) and is resolution independent. b) The value chardx, which is the real advance taken by the renderer (printer or screen) and which is necessarily an integer number of pixels. The latter value is not relevant for TeX tfm files, but is recorded in the gf and pk files. If the you mean the latter value, it can be corrected in the afm files without changing the related tfm files. I am not concerned about bitmaps (as you know :=), and beyond that there is only one `width.' This should be identical in the AFM file and the TFM file. And since the widths in CM fonts are not integer multiples of 1/1000th of an em, they must be non-integers in the AFM file. Any AFM file for CM fonts that has integer widths (except for a few special character at a few special sizes) is wrong (not by much, but by enough that it matters). Any program purporting to make TFM files from AFM files should then also get the wrong width in the TFM files if it working from these rounded widths. There is another issue, which is that the widths in the TFM files for CM themselves are not accurate, relative to Knuth's design. The bottom 2 or 3 bits are wrong, probably due to arithmetic round- off in METAFONT, but this error is very small compared to the above. One can tell easily, since for e.g. for some fonts most dimensions are supposed to be integer multiples of 1/36pt (or sometimes 0.1 * 1/36pt). Regards, Berthold. 5-Mar-1997 19:22:01-GMT,4835;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id MAA08905 for ; Wed, 5 Mar 1997 12:21:58 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id OAA17240; Wed, 5 Mar 1997 14:21:25 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id OAA10893; Wed, 5 Mar 1997 14:21:21 -0500 (EST) Date: Wed, 5 Mar 1997 14:21:21 -0500 (EST) Message-Id: <199703051921.OAA10893@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: oneill@cs.sfu.ca CC: KNAPPEN@vkpmzd.kph.uni-mainz.de, barry@bluesky.com, tex-fonts@math.utah.edu In-reply-to: <199703051828.KAA02161@alonzo.cs.sfu.ca> (oneill@cs.sfu.ca) Subject: Re: AFMs for Blue Sky CM/PS fonts... Reply-to: bkph@ai.mit.edu Berthold Horn writes: > A related question is whether PFA files should be posted as well, > since DPS needs those. Although it is easy to convert PFA to PFB > and vice versa using some PD software. This is misleading, since Display PostScript systems can do pretty much any rendering that regular PostScript system can do, and so in use with TeX these fonts do not need AFMs. Certainly on my NeXT I can use the BlueSky fonts with TeXview or with dvips and Preview without having the AFMs installed. Similarly, I'm happily using the PFB files in this setup. Like I said, if you want to use the fonts with Display PostScript you need to install them properly, and to install them properly you need PFA *and* AFM files :=) As opposed to some special purpose hack for TeX and DVIPS only, that is. Only if I were setting the font up as a native font for NEXTSTEP applications (which, if I recall correctly, itself is problematic owing That *is* what I mean. System level support for fonts. Available for *all* applications. No need for each application to invent its own. to the encoding of the font -- something to do with the space glyph) would I need to have the font in PFA format and need to have the AFM files. Well, yes, that devilish glitch at 32! Of course it is quite trivial to reencode the fonts in PFA and AFM form (unlike Macintosh font format or Windows PFB where it is a bit more work). These fonts all *do* have a `space' character, unlike the original CM fonts. All you need to do is move it to char code 32 in both PFA and AFM, and condemn that glitch to hyperspace (C -1 ;); ... in another posting, Berthold Horn writes: > NeXT does not provide a good comparison test because it is not using a > top quality rasterizer. And on printers it will depend on the quality > of the rasterizer also (i.e. is it a true Adobe rasterizer). Huh? Have you ever actually seen these fonts on a NeXT? The NeXT has an Adobe rasterizer, which in general is very up to date with Adobe's latest PostScript version. In my opinion, it does a better job of rendering That is the point, the PS rasterizer is *not* the same as the ATM rasterizer. No doubt it has improved since I last looked. But unless Adobe has recently ported the ATM rasterizer into their PS interpreters the two *are* different. fonts than ATM running on the Mac in my office. Well that is no surprise! Macs have only 72 dpi. This was also confirmed by someone from Adobe (who admittedly may have been a know-nothing sales dweeb), who, when questioned about this, told me that the Display PostScript architecture was better than ATM. As you say, a know-nothing sales dweeb. Ask on comp.fonts. (I'm talking here about rendering without anti-aliasing. On our Mac the anti-aliased fonts look blurry and grey and are next-to-useless for readability, even if they do look `cool' at a glance. In any case, various Contrary to Windows, where the `font smoothing' (it is not true anti-aliasing on *any* platforms - that would be too slow) is very helpful. It means I can put a full page up on my screen and still read it. Without it I don't have quite enough resolution. software on NeXT's DPS does anti-aliased fonts, including a version of TeXview, albeit one which I don't have. In any case, I'm not talking about anti-aliased rendering, perhaps this is indeed where the superiority that you believe ATM to have lies, and this is how we can have such differing views?) Well, a lot of it is a matter of taste. And a lot of it depends on what screen resolution you are working at, and how good your monitor is and what the phase of the moon is. But overall my experience is that ATM does substabtially better than even quality PS rasterizers like the one in Transverter Pro. Berthold. 5-Mar-1997 19:23:35-GMT,1898;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id MAA08966 for ; Wed, 5 Mar 1997 12:23:34 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id OAA17380; Wed, 5 Mar 1997 14:23:27 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id OAA10897; Wed, 5 Mar 1997 14:23:25 -0500 (EST) Date: Wed, 5 Mar 1997 14:23:25 -0500 (EST) Message-Id: <199703051923.OAA10897@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: thierry.bouche@ujf-grenoble.fr CC: tex-fonts@math.utah.edu In-reply-to: <199703051745.SAA08780@mozart.ujf-grenoble.fr> (message from Thierry Bouche on Wed, 5 Mar 1997 18:45:19 +0100 (MET)) Subject: Re: AFMs for Blue Sky CM/PS fonts... Reply-to: bkph@ai.mit.edu > It is hard to imagine how that could be unless your PL files are > also corrupted, since these AFM files have the wrong advance widths. ah yes, pardon me, it's the same `feature' of tftopl & kpathsea: they were the same beacuse although I launched tftopl from another directory, always the metafont ones were disassembled. moreover, one should add some support in fontinst to take advantage of the fontdimens declared in the afms, and use installrawfont rather than too low-level conversion commands. Not sure what you mean, but AFMtoTFM reads the extra Comments in the AFM file to constuct all the missing dimensions and other stuff like extensible characters found in math fonts. This is indeed a good thing because it means you can make TFM files even for math fonts >From AFM. They are slightly different indeed... but the bakoma ones are nonstandard (including commas...) Berthold. 6-Mar-1997 0:30:05-GMT,1745;000000000000 Return-Path: Received: from bluesky.com ([204.200.195.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id RAA17169 for ; Wed, 5 Mar 1997 17:30:03 -0700 (MST) Received: from barry.bluesky.com by bluesky.com (5.65/Inherent1.1Mailhost) id AA06548; Wed, 5 Mar 97 16:35:20 PST Message-Id: <331E1001.5E58@bluesky.com> Date: Wed, 05 Mar 1997 16:29:53 -0800 From: Barry Smith Reply-To: barry@bluesky.com Organization: Blue Sky Research X-Mailer: Mozilla 3.01 (Macintosh; I; 68K) Mime-Version: 1.0 To: tex-fonts@math.utah.edu Subject: Re: AFMs for Blue Sky CM/PS fonts... References: <199703042113.NAA25689@alonzo.cs.sfu.ca> <331D59E3.2467@bluesky.com> <199703051407.OAA08362@lochnagarn.elsevier.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sebastian Rahtz wrote: > > Its a shame the Blue Sky font set doesn't cover the same ground > as the BaKoMa one. It means in practice that people have to have both > together. just out of curiosity, what are the differences? (we're not going to make any more, but whatever we have will be released, eventually, and this includes a partial AMS set.) > The next edition TeX Live CD will have the fonts on, for what its > worth, augmented by BaKoMa as needed (including AFMs from the latter) thanks. imho, the "best effect" of the public availability of these fonts is to make DVI a responsible format for publications (and to allow PDF decent mathematics). technically, the hinting is -quite- noticeable with a rendering engine at screen resolutions, but irrelevant for print resolution. and, of course the BaKoMa fonts are not freely distributable; wonder if that will change? barry 6-Mar-1997 0:35:18-GMT,1945;000000000000 Return-Path: Received: from bluesky.com ([204.200.195.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id RAA17323 for ; Wed, 5 Mar 1997 17:35:14 -0700 (MST) Received: from barry.bluesky.com by bluesky.com (5.65/Inherent1.1Mailhost) id AA06555; Wed, 5 Mar 97 16:40:36 PST Message-Id: <331E113E.498A@bluesky.com> Date: Wed, 05 Mar 1997 16:35:10 -0800 From: Barry Smith Reply-To: barry@bluesky.com Organization: Blue Sky Research X-Mailer: Mozilla 3.01 (Macintosh; I; 68K) Mime-Version: 1.0 To: tex-fonts@math.utah.edu Subject: Re: AFMs for BlueSky CM Type 1 PS fonts... References: <199703042113.NAA25689@alonzo.cs.sfu.ca> <199703051251.HAA10660@kauai.ai.mit.edu> <199703051425.OAA09831@lochnagarn.elsevier.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sebastian Rahtz wrote: > > Berthold K. P. Horn writes: > > And the fonts are *not* in the public domain, they have AMS copyright. > > The intents is to have them be used freely, but it is important to > > retain the copyright to prevent mischief and misuse. > > Barry's readme says > > not be enforced. These fonts may be used in any fashion for any > purpose, and may be redistributed by anyone who wishes. We ask > only one restriction: if you make derivative versions of these > fonts, or change them in any way, kindly _remove_ our copyright > notices. > > implied that mischief and abuse is fine by him (if we change the > name). is that not what _you_ mean? I['d like to] think that we, Berthold, and the AMS are essentially in line; any -use- of the fonts is permitted, but the "official" copyright notice indicates the purity of lineage. (I think the actual official notice implies that one could, say, rename CMR10 as CMBX12, which certainly qualifies as mischief. ;) In practice it's difficult to imagine serious practical difficulties. barry 6-Mar-1997 1:04:53-GMT,1746;000000000000 Return-Path: Received: from bluesky.com ([204.200.195.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id SAA18171 for ; Wed, 5 Mar 1997 18:04:52 -0700 (MST) Received: from barry.bluesky.com by bluesky.com (5.65/Inherent1.1Mailhost) id AA06643; Wed, 5 Mar 97 17:10:13 PST Message-Id: <331E182E.4DDA@bluesky.com> Date: Wed, 05 Mar 1997 17:04:48 -0800 From: Barry Smith Reply-To: barry@bluesky.com Organization: Blue Sky Research X-Mailer: Mozilla 3.01 (Macintosh; I; 68K) Mime-Version: 1.0 To: tex-fonts@math.utah.edu Subject: Re: AFMs for BlueSky CM Type 1 PS fonts... References: <199703051624.IAA01970@alonzo.cs.sfu.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Melissa O'Neill wrote: > > Well, there seem to be some wires crossed somewhere, since the README > file on CTAN states quite clearly that they're now in the public domain. > > | These fonts may be used in any fashion for any purpose, and may be > | redistributed by anyone who wishes. We ask only one restriction: if > | you make derivative versions of these fonts, or change them in any way, > | kindly _remove_ our copyright notices. > > ... which to me, given the above, has the tone of a `respectful request' > rather than anything with any legal power for enforcement behind it (i.e. > if they are in the public domain, people don't have to respect the > request to remove the copyright notices when changes are made). no offense intended, but if you think I have any interest in make-work for lawyers, ... ;-) if there -is- a practical problem, it will be up to the AMS to resolve it. it would seem to require malice to create a problem, no? barry 6-Mar-1997 1:21:34-GMT,1732;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id SAA18590 for ; Wed, 5 Mar 1997 18:21:34 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id RAA27707 for ; Wed, 5 Mar 1997 17:21:26 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id RAA03112 for tex-fonts@math.utah.edu; Wed, 5 Mar 1997 17:21:24 -0800 (PST) Message-Id: <199703060121.RAA03112@alonzo.cs.sfu.ca> Subject: Re: AFMs for BlueSky CM Type 1 PS fonts... To: tex-fonts@math.utah.edu Date: Wed, 5 Mar 1997 17:21:23 -0800 (PST) In-Reply-To: <331E182E.4DDA@bluesky.com> from "Barry Smith" at Mar 5, 97 05:04:48 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Barry writes, regarding his README: > no offense intended, but if you think I have any interest in > make-work for lawyers, ... ;-) > > if there -is- a practical problem, it will be up to the AMS to > resolve it. it would seem to require malice to create a problem, no? It is exactly because I'd rather not see lawyers getting much work >From me I tend to be very careful how I phrase copyright notices and licenses. Also, I think that there's plenty of malice out there in the world, plenty of foolishness, and plenty of people out to make a buck they didn't earn. Any of these might create a problem, time will tell, of course -- most likely no one will care enough about the TeX community to make any trouble at all. Regards, Melissa. 6-Mar-1997 1:30:49-GMT,1540;000000000000 Return-Path: Received: from bluesky.com ([204.200.195.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id SAA18816 for ; Wed, 5 Mar 1997 18:30:46 -0700 (MST) Received: from barry.bluesky.com by bluesky.com (5.65/Inherent1.1Mailhost) id AA06711; Wed, 5 Mar 97 17:36:04 PST Message-Id: <331E1E3E.CB@bluesky.com> Date: Wed, 05 Mar 1997 17:30:41 -0800 From: Barry Smith Reply-To: barry@bluesky.com Organization: Blue Sky Research X-Mailer: Mozilla 3.01 (Macintosh; I; 68K) Mime-Version: 1.0 To: tex-fonts@math.utah.edu Subject: Re: AFMs for Blue Sky CM/PS fonts... References: <199703051249.EAA01822@alonzo.cs.sfu.ca> <199703051411.OAA08751@lochnagarn.elsevier.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sebastian Rahtz wrote: > > unless your OS is case insensitive, as all are except Unix (?). i > cannot, for instance, preserve the Blue Sky / BaKoMa distinction by > name case on a CD-ROM actually there's a dirty little secret here, in that the Macintosh OS requires the (internal) PostScript font names to be upper-case so that it can resolve the (external) filename containing the actual PostScript font. I don't know of any way to avoid this; perhaps it would be best to change the BaKoMa names to be consistent, where this is required and permissible. Another 'solution' (that may not be possible) is to modify the fonts so as to install themselves under both names in the font dictionary. Berthold? barry 6-Mar-1997 5:15:23-GMT,1067;000000000000 Return-Path: Received: from topo.math.u-psud.fr (lcs@topo.math.u-psud.fr [192.54.146.180]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id WAA23411 for ; Wed, 5 Mar 1997 22:15:22 -0700 (MST) Received: (from lcs@localhost) by topo.math.u-psud.fr (8.6.12/8.6.12) id GAA12066 for tex-fonts@math.utah.edu; Thu, 6 Mar 1997 06:15:19 +0100 Date: Thu, 6 Mar 1997 06:15:19 +0100 From: Laurent Siebenmann Message-Id: <199703060515.GAA12066@topo.math.u-psud.fr> To: tex-fonts@math.utah.edu Subject: BaKoMa licencing *** BaKoMa licencing *** Barry writes: > the BaKoMa fonts are not freely distributable According to the licencing notice on CTAN, specific permission from the author is required for commercial use (only). Clearly, this was intended to afford some protection to preexisting BSR and Y&Y commercial interests ;=) Equally clearly, Malyshev will now drop this restriction since those commercial interests have been abandoned ;=) That's my pious hope. Larry 6-Mar-1997 5:16:58-GMT,1873;000000000000 Return-Path: Received: from topo.math.u-psud.fr (lcs@topo.math.u-psud.fr [192.54.146.180]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id WAA23468 for ; Wed, 5 Mar 1997 22:16:57 -0700 (MST) Received: (from lcs@localhost) by topo.math.u-psud.fr (8.6.12/8.6.12) id GAA12070 for tex-fonts@math.utah.edu; Thu, 6 Mar 1997 06:16:55 +0100 Date: Thu, 6 Mar 1997 06:16:55 +0100 From: Laurent Siebenmann Message-Id: <199703060516.GAA12070@topo.math.u-psud.fr> To: tex-fonts@math.utah.edu Subject: anti-aliasing anti-aliasing (also called smoothing) Dear Melissa, You write: > In any case, I'm not talking > about anti-aliased rendering On the Mac and the Next machines, it seems to me that users prefer Adobe's ATM B/W rasterizer used *without* anti-aliasing. The first acceptable anti-aliasing on the Mac is in Adobe's Acrobat reader Version 3 of late 1997. I suspect Adobe's low-level intervention was required. As you indicated, if one looks at Textures' earlier attempt the letters are not black enough --- the image is "washed out". Reason? I observe that original ATM's hinting tended to make the B-to-W ratio well below the ideal value of the outlines through the range of sizes currently used on screens. That was a consequence of wanting smooth edges. Also, when Adobe's Acrobat is used without anti-aliasing the bitmaps are heavier and more rugged than for Textures. But Textures excels with simple B/W (ie. in the absence of anti-aliasing) --- and it excels in both speed and quality. (OzTeX and Direct TeX are catching up gradually.) If you are right that, at *equal resolution* (pixels per em), the Next type1 rasterizer gives better quality in B/W than the Mac with Textures Reader, then you do have something to boast about! Cheers Larry Siebenmann 6-Mar-1997 5:18:46-GMT,2011;000000000000 Return-Path: Received: from topo.math.u-psud.fr (lcs@topo.math.u-psud.fr [192.54.146.180]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id WAA23500 for ; Wed, 5 Mar 1997 22:18:45 -0700 (MST) Received: (from lcs@localhost) by topo.math.u-psud.fr (8.6.12/8.6.12) id GAA12074 for tex-fonts@math.utah.edu; Thu, 6 Mar 1997 06:18:42 +0100 Date: Thu, 6 Mar 1997 06:18:42 +0100 From: Laurent Siebenmann Message-Id: <199703060518.GAA12074@topo.math.u-psud.fr> To: tex-fonts@math.utah.edu Subject: BaKoMa extras A couple of years back I made the following post on another list. Has the situation changed? Larry Siebenmann %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% BaKoMa extras I have just made a quick check. The following 38 fonts in the BaKoMa series, appear to be absent >From the BSR series. Please correct me. The absence of "standard" fonts is a great hinderence in exploiting ".dvi" files posted by EMJs. Virtual font surrogates for many of these 38 have been available on the BSR server; however they are typographically inferior (and slow). Be aware that BSR goes beyond BaKoMa too for the while. the WNCY, and LaTeX series are not yet in BaKoMa. I suspect that Malyshev has made substantial progress in automating MF ==> PS type1 conversion. I would hope that these improvements will mean that METAFONT can finally play a serious role as a PS type1 type design tool. (This has not even been mooted on the MF list. Why?) Laurent S CM fonts cmcsc8 cmcsc9 cmbsy5 cmbsy6 cmbsy7 cmbsy8 cmbsy9 cmex7 cmex8 cmex9 AMS fonts euex7 euex8 euex9 eufb6 eufb8 eufb9 eufm6 eufm8 eufm9 eurb6 eurb8 eurb9 eurm6 eurm8 eurm9 eusb6 eusb8 eusb9 eusm6 eusm8 eusm9 msam6 msam8 msam9 msbm6 msbm8 msbm9 6-Mar-1997 5:19:42-GMT,1196;000000000000 Return-Path: Received: from topo.math.u-psud.fr (lcs@topo.math.u-psud.fr [192.54.146.180]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id WAA23519 for ; Wed, 5 Mar 1997 22:19:41 -0700 (MST) Received: (from lcs@localhost) by topo.math.u-psud.fr (8.6.12/8.6.12) id GAA12079 for tex-fonts@math.utah.edu; Thu, 6 Mar 1997 06:19:39 +0100 Date: Thu, 6 Mar 1997 06:19:39 +0100 From: Laurent Siebenmann Message-Id: <199703060519.GAA12079@topo.math.u-psud.fr> To: tex-fonts@math.utah.edu Subject: BaKoMa remains essential *** BaKoMa remains essential *** Ralph Youngen of the AMS recently stated on another list that > Creating additional point sizes is not in the immediate plans. I conclude that the many fonts provided exclusively by the BaKoMa series alone, will remain BaKoMa. They are fonts that I would use routinely in a math book to be published electronically in any of the formats DVI, PS or PDF. Another point, the heart of BaKoMa is automation of MF ==> type1 and its secrets have not yet been fully published. Can we hope? Larry Siebenmann 6-Mar-1997 9:52:56-GMT,2050;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA29787 for ; Thu, 6 Mar 1997 02:52:55 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA27549 for ; Thu, 6 Mar 1997 09:50:53 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Thu, 6 Mar 1997 09:52:44 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA27040; Thu, 6 Mar 1997 09:52:38 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id JAA09857; Thu, 6 Mar 1997 09:52:34 GMT Date: Thu, 6 Mar 1997 09:52:34 GMT Message-Id: <199703060952.JAA09857@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: bkph@ai.mit.edu Cc: barry@bluesky.com, tex-fonts@math.utah.edu Subject: Re: AFMs for Blue Sky CM/PS fonts... In-Reply-To: <199703051651.LAA10825@kauai.ai.mit.edu> References: <199703051628.QAA21978@lochnagarn.elsevier.co.uk> <199703051651.LAA10825@kauai.ai.mit.edu> Berthold K. P. Horn writes: > Thanks. Some of those are bold math, which are not in CM, but in AMS > font set (supposedly to be released end of the year). Also odd it *is* unfortunate the the new release isnt a replacement for BaKoMa. I fear it could harm the cause somewhat when people blithely plug in the new stuff, and expect what they did last year to keep working. more importantly, i really think you should consider making the font names lower case. isnt it best if font names match the TeX names, in the simplest case? please? > I believe the bulk of the fonts in your list (the CMC* fonts) are > however extended with Cyrillic - which is another story indeed. we can forget about those in practice s 6-Mar-1997 10:24:05-GMT,2150;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA00532 for ; Thu, 6 Mar 1997 03:24:04 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA28730 for ; Thu, 6 Mar 1997 10:22:04 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Thu, 6 Mar 1997 10:24:01 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA01616; Thu, 6 Mar 1997 10:23:58 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id KAA12301; Thu, 6 Mar 1997 10:23:53 GMT Date: Thu, 6 Mar 1997 10:23:53 GMT Message-Id: <199703061023.KAA12301@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: barry@bluesky.com Cc: tex-fonts@math.utah.edu Subject: Re: AFMs for Blue Sky CM/PS fonts... In-Reply-To: <331E1001.5E58@bluesky.com> References: <199703042113.NAA25689@alonzo.cs.sfu.ca> <331D59E3.2467@bluesky.com> <199703051407.OAA08362@lochnagarn.elsevier.co.uk> <331E1001.5E58@bluesky.com> Barry Smith writes: > just out of curiosity, what are the differences? the AMS stuff, basically > thanks. imho, the "best effect" of the public availability > of these fonts is to make DVI a responsible format for publications i think i take that with a pinch of salt... it'll take much more than that to make anyone use DVI! (IMHO) > technically, the hinting > is -quite- noticeable with a rendering engine at screen resolutions, > but irrelevant for print resolution. yes, i am sure your stuff is better, i am glad i can now use it > and, of course the BaKoMa fonts > are not freely distributable; wonder if that will change? i think thats always been a joke. Basil has been out of it for some time, and i dont believe he ever really thought through his conditions sebastian 6-Mar-1997 10:25:23-GMT,1677;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA00583 for ; Thu, 6 Mar 1997 03:25:21 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA28786 for ; Thu, 6 Mar 1997 10:23:21 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Thu, 6 Mar 1997 10:24:51 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA01702; Thu, 6 Mar 1997 10:24:49 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id KAA12309; Thu, 6 Mar 1997 10:24:45 GMT Date: Thu, 6 Mar 1997 10:24:45 GMT Message-Id: <199703061024.KAA12309@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: barry@bluesky.com Cc: tex-fonts@math.utah.edu Subject: Re: AFMs for BlueSky CM Type 1 PS fonts... In-Reply-To: <331E113E.498A@bluesky.com> References: <199703042113.NAA25689@alonzo.cs.sfu.ca> <199703051251.HAA10660@kauai.ai.mit.edu> <199703051425.OAA09831@lochnagarn.elsevier.co.uk> <331E113E.498A@bluesky.com> Barry Smith writes: > actual official notice implies that one could, say, rename CMR10 > as CMBX12, which certainly qualifies as mischief. ;) In practice > it's difficult to imagine serious practical difficulties. > so can i redistribute them with all the names changed to lowercase? sebastian 6-Mar-1997 10:26:53-GMT,1715;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA00618 for ; Thu, 6 Mar 1997 03:26:52 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA28866 for ; Thu, 6 Mar 1997 10:24:52 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Thu, 6 Mar 1997 10:26:23 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id KAA01934; Thu, 6 Mar 1997 10:26:17 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id KAA12341; Thu, 6 Mar 1997 10:26:13 GMT Date: Thu, 6 Mar 1997 10:26:13 GMT Message-Id: <199703061026.KAA12341@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: barry@bluesky.com Cc: tex-fonts@math.utah.edu Subject: Re: AFMs for Blue Sky CM/PS fonts... In-Reply-To: <331E1E3E.CB@bluesky.com> References: <199703051249.EAA01822@alonzo.cs.sfu.ca> <199703051411.OAA08751@lochnagarn.elsevier.co.uk> <331E1E3E.CB@bluesky.com> > actually there's a dirty little secret here, in that the Macintosh > OS requires the (internal) PostScript font names to be upper-case > so that it can resolve the (external) filename containing the actual > PostScript font. I don't know of any way to avoid this; perhaps oh so there *is* a technical reason, i had often wondered. thanks, thats makes the problem clearer sebastian 6-Mar-1997 15:00:38-GMT,2152;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA06223 for ; Thu, 6 Mar 1997 08:00:37 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id KAA24860; Thu, 6 Mar 1997 10:00:34 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA11334; Thu, 6 Mar 1997 10:00:32 -0500 (EST) Date: Thu, 6 Mar 1997 10:00:32 -0500 (EST) Message-Id: <199703061500.KAA11334@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: oneill@cs.sfu.ca CC: tex-fonts@math.utah.edu In-reply-to: <199703060121.RAA03112@alonzo.cs.sfu.ca> (oneill@cs.sfu.ca) Subject: Re: AFMs for BlueSky CM Type 1 PS fonts... Reply-to: bkph@ai.mit.edu Barry writes, regarding his README: > no offense intended, but if you think I have any interest in > make-work for lawyers, ... ;-) > > if there -is- a practical problem, it will be up to the AMS to > resolve it. it would seem to require malice to create a problem, no? It is exactly because I'd rather not see lawyers getting much work from me I tend to be very careful how I phrase copyright notices and licenses. Also, I think that there's plenty of malice out there in the world, plenty of foolishness, and plenty of people out to make a buck they didn't earn. Any of these might create a problem, time will tell, of course -- most likely no one will care enough about the TeX community to make any trouble at all. Regards, Melissa. Well, based on this kind of thinking, we *only* put in /Notice (Copyright (c) 1997 American Mathematical Society. All Rights Reserved) readonly def None of the extra verbage about modifying and renaming. I think we should let AMS decide what they will allow or not allow and not enshrine that data in the font itself. Much too dangerous. (The above is in the IBM PC version now and will shortly be in the Mac version). Regards, Berthold. 6-Mar-1997 15:03:57-GMT,2663;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA06311 for ; Thu, 6 Mar 1997 08:03:56 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id KAA24996; Thu, 6 Mar 1997 10:03:53 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA11337; Thu, 6 Mar 1997 10:03:52 -0500 (EST) Date: Thu, 6 Mar 1997 10:03:52 -0500 (EST) Message-Id: <199703061503.KAA11337@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: barry@bluesky.com CC: tex-fonts@math.utah.edu In-reply-to: <331E1E3E.CB@bluesky.com> (message from Barry Smith on Wed, 05 Mar 1997 17:30:41 -0800) Subject: Re: AFMs for Blue Sky CM/PS fonts... Reply-to: bkph@ai.mit.edu Date: Wed, 05 Mar 1997 17:30:41 -0800 From: Barry Smith Reply-To: barry@bluesky.com Organization: Blue Sky Research X-Mailer: Mozilla 3.01 (Macintosh; I; 68K) Mime-Version: 1.0 References: <199703051249.EAA01822@alonzo.cs.sfu.ca> <199703051411.OAA08751@lochnagarn.elsevier.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sebastian Rahtz wrote: > > unless your OS is case insensitive, as all are except Unix (?). i > cannot, for instance, preserve the Blue Sky / BaKoMa distinction by > name case on a CD-ROM actually there's a dirty little secret here, in that the Macintosh OS requires the (internal) PostScript font names to be upper-case so that it can resolve the (external) filename containing the actual PostScript font. I don't know of any way to avoid this; perhaps it would be best to change the BaKoMa names to be consistent, where this is required and permissible. Another 'solution' (that may not be possible) is to modify the fonts so as to install themselves under both names in the font dictionary. Berthold? The short answer is that it can't be done. The long one is that you can set up two PFM files for one PFB and then have two names appear in font menus. But this is *gauranteed* to break something in some version of ATM or some brain-dead application. There are already enough reasons for things to break :=) thank you. But the case of the *file* name is a separate issue from that of the PS FontName. Fortunately, I don't care about either one, sincem while Windows FaceNames *are* case sensitive, DVIWindo ignores the case just to deal with this kind of thing. Regards, Berthold. 6-Mar-1997 15:17:39-GMT,1793;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA06680 for ; Thu, 6 Mar 1997 08:17:38 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id KAA25607; Thu, 6 Mar 1997 10:17:22 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA11355; Thu, 6 Mar 1997 10:17:20 -0500 (EST) Date: Thu, 6 Mar 1997 10:17:20 -0500 (EST) Message-Id: <199703061517.KAA11355@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: s.rahtz@elsevier.co.uk CC: barry@bluesky.com, tex-fonts@math.utah.edu In-reply-to: <199703061024.KAA12309@lochnagarn.elsevier.co.uk> (message from Sebastian Rahtz on Thu, 6 Mar 1997 10:24:45 GMT) Subject: Re: AFMs for BlueSky CM Type 1 PS fonts... Reply-to: bkph@ai.mit.edu Date: Thu, 6 Mar 1997 10:24:45 GMT From: Sebastian Rahtz Cc: tex-fonts@math.utah.edu References: <199703042113.NAA25689@alonzo.cs.sfu.ca> <199703051251.HAA10660@kauai.ai.mit.edu> <199703051425.OAA09831@lochnagarn.elsevier.co.uk> <331E113E.498A@bluesky.com> Barry Smith writes: > actual official notice implies that one could, say, rename CMR10 > as CMBX12, which certainly qualifies as mischief. ;) In practice > it's difficult to imagine serious practical difficulties. > so can i redistribute them with all the names changed to lowercase? sebastian But you can change the file names without touching the PS FontNames? Or are you talking about the Mac version where the file name is the 5+3+3+... reduced version of the PS FontName? Berthold. 6-Mar-1997 15:56:06-GMT,1659;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA07622 for ; Thu, 6 Mar 1997 08:56:01 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id PAA10184 for ; Thu, 6 Mar 1997 15:54:00 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Thu, 6 Mar 1997 15:55:32 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id PAA16619; Thu, 6 Mar 1997 15:55:23 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id PAA15220; Thu, 6 Mar 1997 15:55:18 GMT Date: Thu, 6 Mar 1997 15:55:18 GMT Message-Id: <199703061555.PAA15220@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: bkph@ai.mit.edu Cc: barry@bluesky.com, tex-fonts@math.utah.edu Subject: Re: AFMs for BlueSky CM Type 1 PS fonts... In-Reply-To: <199703061517.KAA11355@kauai.ai.mit.edu> References: <199703061024.KAA12309@lochnagarn.elsevier.co.uk> <199703061517.KAA11355@kauai.ai.mit.edu> Berthold K. P. Horn writes: > But you can change the file names without touching the PS FontNames? > > Or are you talking about the Mac version where the file name is > the 5+3+3+... reduced version of the PS FontName? no, i meant changing the *internal* names, but Barry explained why i couldnt anyway... sebastian 6-Mar-1997 16:24:50-GMT,1432;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA08415 for ; Thu, 6 Mar 1997 09:24:47 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id KAA26006; Thu, 6 Mar 1997 10:24:10 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA11361; Thu, 6 Mar 1997 10:24:09 -0500 (EST) Date: Thu, 6 Mar 1997 10:24:09 -0500 (EST) Message-Id: <199703061524.KAA11361@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: lcs@topo.math.u-psud.fr CC: tex-fonts@math.utah.edu In-reply-to: <199703060518.GAA12074@topo.math.u-psud.fr> (message from Laurent Siebenmann on Thu, 6 Mar 1997 06:18:42 +0100) Subject: Re: BaKoMa extras Reply-to: bkph@ai.mit.edu You are incorrectly listing fonts whose names start with `CM' as `CM' fonts. All the ones you listed are in the `AMS' font set, not in Knuth's 75. The AMS font set includes extra sizes of `CM' bold math fonts, CMEX and CMSC. Of course you are welcome to bitch and moan about not having them. After all that is what we all like to do around here :=) And make some dramatic threats like not using them unless you get them. On the other hand you can wait to see whether AMS has plans for this. 7-Mar-1997 5:10:23-GMT,1327;000000000000 Return-Path: Received: from topo.math.u-psud.fr (lcs@topo.math.u-psud.fr [192.54.146.180]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id WAA16329 for ; Thu, 6 Mar 1997 22:10:22 -0700 (MST) Received: (from lcs@localhost) by topo.math.u-psud.fr (8.6.12/8.6.12) id GAA16660 for tex-fonts@math.utah.edu; Fri, 7 Mar 1997 06:10:19 +0100 Date: Fri, 7 Mar 1997 06:10:19 +0100 From: Laurent Siebenmann Message-Id: <199703070510.GAA16660@topo.math.u-psud.fr> To: tex-fonts@math.utah.edu Subject: a pinch of sugar Barry wrote: > thanks. imho, the "best effect" of the public availability > of these fonts is to make DVI a responsible format for publications Sebastien replies: > i think i take that with a pinch of salt... it'll take much more than > that to make anyone use DVI! (IMHO) Take it with a pinch of sugar. There IS much more. Barry Smith has just made Textures Reader freely available. Where browsing/reading of complex scientific typeography is concerned, I hold Textures to be the WORLD'S BEST READER --- on *any* platform. Rumors of the death of TeX's efficient DVI format are propoganda no more noble then the persistent PC originating rumors of the death of the rival Macintosh. Cheers, Larry Siebenmann 7-Mar-1997 5:36:58-GMT,3351;000000000000 Return-Path: Received: from topo.math.u-psud.fr (lcs@topo.math.u-psud.fr [192.54.146.180]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id WAA16924 for ; Thu, 6 Mar 1997 22:36:57 -0700 (MST) Received: (from lcs@localhost) by topo.math.u-psud.fr (8.6.12/8.6.12) id GAA16685; Fri, 7 Mar 1997 06:36:54 +0100 Date: Fri, 7 Mar 1997 06:36:54 +0100 From: Laurent Siebenmann Message-Id: <199703070536.GAA16685@topo.math.u-psud.fr> To: metafont@ens.fr, tex-fonts@math.utah.edu Subject: MF ==> (PS type1) *** Malyshev's MF ==> (PS type1) is important *** > In replying to me (indented), Berthold Horn wrote: > > I suspect that Malyshev has made substantial progress > in automating MF ==> PS type1 conversion. > > You are joking right? > Why would he put any effort into this, particularly now. > > I would hope > that these improvements will mean that METAFONT can > finally play a serious role as a PS type1 type design > tool. (This has not even been mooted on the MF list. > Why?) > > You are joking right? MF will never be a typographers design > tool. Only a few geniuses have ever more or less masters it > DEK is one, and maybe Yannis is another. Neena Bulawaya (sp?), Damian Cugley, Yannis Haralambous, Doug Henderson, Bogislav Jakowsky, Silvio Levy, Joerg Knappen, Pierre Mackay, Ralph Smith, Goergia Tobin, and other accomplished metafont programmer-artists are surely flattered to hear they have a rare genius (far from me to deny it!). However my own thought was that they would be happier still to have a smooth path on which to take their fonts to the widest possible public and so declare their genius where the all the world can take notice. >From my own scientist's point of view, I note that essentially all math fonts usable with TeX originate in Metafont and all too often remain there. For example I want the lamstex arrow fonts in type1 since they are the one arrow font set I know that is stylisticly compatible with with CM. Also, I want Ralph Smith's Formal Script as a Math Caligraphic, and as a luxury Yannis Haralambous' math extensions. That is three small math "meta-fonts" important to me but marooned in Metafont format. There are probably many more, especially when one widens the scope to logic, physics, chemistry, and beyond. If Malyshev's MF ==> (PS type1) conversion were fully published, such problems would be readily solved. Let me anticipate the familiar cry that we are all tired of sober-sided CM and its cousins and should be moving on to world class PostScript designs, beginning with budget-fitting Times & MathTime. Well, there is one detail you all aught to know: MathTime was originally done in MetaFont by Georgia Tobin of MetaFoundry fame. As absolute last resort in the small Type 1 world, one has Lucida Math by Biggelow & Holmes. But isn't there a Metafont ancestry there too? So I am saying Berthold has it quite wrong. Now that he no longer has substantial financial interest in type1 renditions of freely available Metafont series, he can afford to welcome the "coming-out" of Knuth's Metafont via Malyshev's MF ==> (PS type1). Cheers Larry S 7-Mar-1997 9:40:57-GMT,1938;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA22764 for ; Fri, 7 Mar 1997 02:40:56 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA01527 for ; Fri, 7 Mar 1997 09:38:50 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Fri, 7 Mar 1997 09:40:28 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA22421; Fri, 7 Mar 1997 09:40:24 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id JAA11422; Fri, 7 Mar 1997 09:40:19 GMT Date: Fri, 7 Mar 1997 09:40:19 GMT Message-Id: <199703070940.JAA11422@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: lcs@topo.math.u-psud.fr Cc: tex-fonts@math.utah.edu Subject: Re: a pinch of sugar In-Reply-To: <199703070510.GAA16660@topo.math.u-psud.fr> References: <199703070510.GAA16660@topo.math.u-psud.fr> Laurent Siebenmann writes: > Take it with a pinch of sugar. There IS much more. Barry > Smith has just made Textures Reader freely available. Where > browsing/reading of complex scientific typeography is > concerned, I hold Textures to be the WORLD'S BEST READER > --- on *any* platform. you want us to buy Macs just for that? > Rumors of the death of TeX's efficient DVI format are propoganda no > more noble then the persistent PC originating rumors of the death of > the rival Macintosh. its hard to find an industry analyst who holds out any hope for Apple. its hard to find any text-processing industry analyst who ever even mentions TeX or dvi :-} Sebastian 7-Mar-1997 9:44:35-GMT,2305;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA22835 for ; Fri, 7 Mar 1997 02:44:34 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA01654 for ; Fri, 7 Mar 1997 09:42:30 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Fri, 7 Mar 1997 09:44:08 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA22447; Fri, 7 Mar 1997 09:44:01 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id JAA11696; Fri, 7 Mar 1997 09:43:56 GMT Date: Fri, 7 Mar 1997 09:43:56 GMT Message-Id: <199703070943.JAA11696@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: lcs@topo.math.u-psud.fr Cc: metafont@ens.fr, tex-fonts@math.utah.edu Subject: Re: MF ==> (PS type1) In-Reply-To: <199703070536.GAA16685@topo.math.u-psud.fr> References: <199703070536.GAA16685@topo.math.u-psud.fr> Laurent Siebenmann writes: > Neena Bulawaya (sp?), Damian Cugley, Yannis Haralambous, Doug > Henderson, Bogislav Jakowsky, Silvio Levy, Joerg Knappen, Pierre > Mackay, Ralph Smith, Goergia Tobin, and other accomplished metafont > programmer-artists are surely flattered to hear they have a rare the fact that you can list the practitioners surely makes the point? > From my own scientist's point of view, I note that essentially all > math fonts usable with TeX originate in Metafont and all too can you point us at a math font which is *not* useable with TeX? > MathTime. Well, there is one detail you all aught to know: MathTime > was originally done in MetaFont by Georgia Tobin of MetaFoundry you are not implying that Spivak converted something by Tobin? if not, whats the relevance? > As absolute last resort in the small Type 1 world, one has Lucida > Math by Biggelow & Holmes. But isn't there a Metafont ancestry > there too? absolutely not! and why a last resort? why `small Type1 world'? sebastian 7-Mar-1997 12:13:37-GMT,2313;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA25755 for ; Fri, 7 Mar 1997 05:13:36 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA06665 for ; Fri, 7 Mar 1997 12:11:34 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Fri, 7 Mar 1997 12:13:35 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id MAA26231 for ; Fri, 7 Mar 1997 12:13:32 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id MAA24744; Fri, 7 Mar 1997 12:13:27 GMT Date: Fri, 7 Mar 1997 12:13:27 GMT Message-Id: <199703071213.MAA24744@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: tex-fonts@math.utah.edu Subject: pdftex mailing list As many people are already aware, there is now a version of TeX available which produces PDF format instead of dvi. This comes from a project at Masaryk University, Brno, Czech Republic, and is the work of Han The Thanh, under the supervision of Petr Sojka and Jiri Zlatuska. The sources of tex2pdf (pdftex) are on CTAN, in systems/tex2pdf, as a patch/addition to the Web2c 7.0 setup. It is still under development, and anyone preparing to use it should be prepared to compile it themselves at this stage (on more or less any Unix system). A compiled binary for Windows NT/95 should be available soon. PLEASE do not jump into this stuff without accepting it as beta status. I don't think Han The Thanh will thank me if announcements like this get him deluged with mail saying `where is the Mac version' or suchlike. In order to help promulgate information about this development, and exchange ideas, the TeX Users Group is hosting a mailing list. If you want to join, send a mail message to majordomo@mail.tug.org saying subscribe pdftex I am the moderator of this list, and will endeavour to provide all the help I can. Sebastian Rahtz Secretary, TUG 7-Mar-1997 12:54:04-GMT,5063;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA26505 for ; Fri, 7 Mar 1997 05:54:03 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id HAA11553; Fri, 7 Mar 1997 07:53:13 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id HAA11861; Fri, 7 Mar 1997 07:53:12 -0500 (EST) Date: Fri, 7 Mar 1997 07:53:12 -0500 (EST) Message-Id: <199703071253.HAA11861@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: lcs@topo.math.u-psud.fr CC: metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703070536.GAA16685@topo.math.u-psud.fr> (message from Laurent Siebenmann on Fri, 7 Mar 1997 06:36:54 +0100) Subject: Re: MF ==> (PS type1) Reply-to: bkph@ai.mit.edu Date: Fri, 7 Mar 1997 06:36:54 +0100 From: Laurent Siebenmann *** Malyshev's MF ==> (PS type1) is important *** > In replying to me (indented), Berthold Horn wrote: Yes, you enjoy these flame wars don't you :-)? > I suspect that Malyshev has made substantial progress > in automating MF ==> PS type1 conversion. > You are joking right? > Why would he put any effort into this, particularly now. > I would hope > that these improvements will mean that METAFONT can > finally play a serious role as a PS type1 type design > tool. (This has not even been mooted on the MF list. > Why?) > You are joking right? MF will never be a typographers design > tool. Only a few geniuses have ever more or less masters it > DEK is one, and maybe Yannis is another. I had no intent for this to go to a wider audience, but so be it. Neena Bulawaya (sp?), Damian Cugley, Yannis Haralambous, Doug Henderson, Bogislav Jakowsky, Silvio Levy, Joerg Knappen, Pierre Mackay, Ralph Smith, Goergia Tobin, and other accomplished metafont programmer-artists are surely flattered to hear they have a rare genius (far from me to deny it!). However my own thought was that they would be happier still to have a smooth path on which to take their fonts to the widest possible public and so declare their genius where the all the world can take notice. From my own scientist's point of view, I note that essentially all math fonts usable with TeX originate in Metafont and all too Sorry, that is just not so. There are three choices right now, and two of them originated in scalable outline format, not MF. often remain there. For example I want the lamstex arrow fonts in type1 since they are the one arrow font set I know that is stylisticly compatible with with CM. Also, I want Ralph Smith's Formal Script as a Math Caligraphic, and as a luxury Yannis Haralambous' math extensions. That is three small math "meta-fonts" important to me but marooned in Metafont format. There I like that word `marooned' - how appropriate! are probably many more, especially when one widens the scope to logic, physics, chemistry, and beyond. If Malyshev's MF ==> (PS type1) conversion were fully published, such problems would be readily solved. But why would he do that? Have you asked him? Do you realize there is an enormous amount of hand work involved beyond the automation? Let me anticipate the familiar cry that we are all tired of sober-sided CM and its cousins and should be moving on to world class PostScript designs, beginning with budget-fitting Times & MathTime. Well, there is one detail you all aught to know: MathTime was originally done in MetaFont by Georgia Tobin of MetaFoundry fame. You will have to ask Mike Spivak whether *any* of the original MF code survived. For one, he was I think, not at all pleased with the design and redid virtually all of it himself. And then someone (Yannis?) made the pre 1.0 version in Type 1 format. As absolute last resort in the small Type 1 world, one has Lucida Math by Biggelow & Holmes. But isn't there a Metafont ancestry there too? Absolutely not. Keep in mind that it was Bigelow and Holmes who rescued the AMS / Euler font project by advising Knuth to give up on METAFONT and do it as scalable outlines (Yes, they did use the MF program but they simply described Zapf's outlines by splines - this increased productivity one or two orders of magnitude and made the project possibly for David Siegel to complete at the Digital Typograpphy Group at Stanford). So I am saying Berthold has it quite wrong. Now that he no longer has substantial financial interest in type1 renditions of freely available Metafont series, he can afford to welcome the "coming-out" of Knuth's Metafont via Malyshev's MF ==> (PS type1). Good luck. How about Richard Kinch's METAFOG? That seems more real. Cheers Larry S 7-Mar-1997 12:56:08-GMT,1364;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA26590 for ; Fri, 7 Mar 1997 05:56:07 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id HAA11585; Fri, 7 Mar 1997 07:55:58 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id HAA11867; Fri, 7 Mar 1997 07:55:56 -0500 (EST) Date: Fri, 7 Mar 1997 07:55:56 -0500 (EST) Message-Id: <199703071255.HAA11867@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: lcs@topo.math.u-psud.fr CC: metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703070536.GAA16685@topo.math.u-psud.fr> (message from Laurent Siebenmann on Fri, 7 Mar 1997 06:36:54 +0100) Subject: Re: MF ==> (PS type1) Reply-to: bkph@ai.mit.edu Date: Fri, 7 Mar 1997 06:36:54 +0100 From: Laurent Siebenmann Oh yes, just noticed one interesting little thing in your message: As absolute last resort in the small Type 1 world, one has Lucida Math by Biggelow & Holmes. Samll Type 1 world? Let's see, there are over 30,000 fonts in Adobe Type 1 format. Real small :-) And several thousand in TrueType form. 7-Mar-1997 21:17:20-GMT,1529;000000000000 Return-Path: Received: from moria.imaginet.fr (moria.imaginet.fr [194.51.83.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id OAA09082 for ; Fri, 7 Mar 1997 14:17:19 -0700 (MST) Received: from imaginet.fr by moria.imaginet.fr via ESMTP (950215.SGI.8.6.10/911001.SGI) id WAA18706; Fri, 7 Mar 1997 22:17:07 +0100 Received: from [195.68.10.80] (isdn1.lille.imaginet.fr [195.68.10.80]) by imaginet.fr (8.7.5/8.7.31) with SMTP id WAA16760; Fri, 7 Mar 1997 22:17:04 +0100 (MET) Message-Id: <199703072117.WAA16760@imaginet.fr> Subject: Re: MF ==> (PS type1) Date: Ven, 7 Mar 97 22:22:06 -0000 x-sender: yannis@mail.imaginet.fr x-mailer: Claris Emailer 1.1 From: Yannis Haralambous To: , cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" >You will have to ask Mike Spivak whether *any* of the original MF code >survived. For one, he was I think, not at all pleased with the design >and redid virtually all of it himself. And then someone (Yannis?) >made the pre 1.0 version in Type 1 format. Yes, I did Type 1 versions of the lams fonts. But as last year all my cartridges were stolen, I don't have those fonts anymore. Mike is the only one to have them (I hope he kept them, I did a very precise work so that pieces of arrows fit to each other, he had a book to publish in very high resolution, that's why he needed PS fonts) Yannis 8-Mar-1997 22:08:51-GMT,1570;000000000000 Return-Path: Received: from ccserv.ucc.ie (ccserv.ucc.ie [143.239.1.12]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id PAA10104 for ; Sat, 8 Mar 1997 15:08:50 -0700 (MST) Received: from curia by CCSERV.UCC.IE (PMDF #3468 ) id <01IG9XHGNJY8000I41@CCSERV.UCC.IE>; Sat, 8 Mar 1997 22:10:40 GMT Received: from samhain.ucc.ie (samhain.ucc.ie [143.239.128.43]) by curia.ucc.ie (8.6.10/8.6.10) with SMTP id WAA10192; Sat, 8 Mar 1997 22:09:20 GMT Date: 08 Mar 1997 22:09:20 +0000 (GMT) From: Peter Flynn Subject: Re: MF ==> (PS type1) To: metafont@ens.fr Cc: tex-fonts@math.utah.edu Message-id: <199703082209.WAA10192@curia.ucc.ie> X-Envelope-to: tex-fonts@math.utah.edu MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7BIT X-Sender: pflynn@curia.ucc.ie (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 [math fonts] >Sorry, that is just not so. There are three choices right now, Four if you include Euler as a separate font (see current issue of GUTenberg). > MathTime. Well, there is one detail you all aught to know: MathTime > was originally done in MetaFont by Georgia Tobin of MetaFoundry fame. > >You will have to ask Mike Spivak whether *any* of the original MF code I asked Georgia once when I was enquiring about the old Times. It was all Metafont 1 and unusable now unless anyone can compile the metafont binary for version 1 (historical note: someone ought to preserve this intact if it still exists). ///Peter 9-Mar-1997 23:24:44-GMT,1120;000000000000 Return-Path: Received: from alisan.ibm.net (uri@slip166-72-232-144.ny.us.ibm.net [166.72.232.144]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id QAA09634 for ; Sun, 9 Mar 1997 16:24:41 -0700 (MST) Received: (from uri@localhost) by alisan.ibm.net (8.7.6/8.7.3) id SAA12065; Sun, 9 Mar 1997 18:25:02 -0500 Date: Sun, 9 Mar 1997 18:25:02 -0500 Message-Id: <199703092325.SAA12065@alisan.ibm.net> From: Uri Blumenthal To: tex-fonts@math.utah.edu Subject: A new mode (sort of :-) Reply-to: uri@ibm.net Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII This one is for Lexmark Optra R+ in 600 dpi mode (which is naturally different from "lexmarkr" in "modes.mf" that gives 1200 dpi). % Uri Blumenthal mode_def lexmarku = % IBM (Lexmark) Optra R (4049) in 600dpi mode mode_param (pixels_per_inch, 600); mode_param (blacker, .5); mode_param (fillin, 0); mode_param (o_correction, .75); mode_param (tracingtitles, 0); mode_common_setup_; enddef; OptrarU := lexmarku; 11-Mar-1997 0:46:56-GMT,3675;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id RAA12829 for ; Mon, 10 Mar 1997 17:46:56 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id QAA18992 for ; Mon, 10 Mar 1997 16:46:53 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id QAA05869 for tex-fonts@math.utah.edu; Mon, 10 Mar 1997 16:46:51 -0800 (PST) Message-Id: <199703110046.QAA05869@alonzo.cs.sfu.ca> Subject: BlueSky fonts and subfont To: tex-fonts@math.utah.edu Date: Mon, 10 Mar 1997 16:46:50 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Has anyone had success using the BlueSky fonts with Basil K. Malyshev's fload font loading program, especially the subfont program it uses to generate subset/partial fonts... When I use the BaKoMa fonts (also created by subfont's author), I get: unix% fload -P 35 parsecom-bakoma.ps > parsecom-fixed.ps Process PS file parsecom.ps.new. Write font using statistic to parsecom.ps.fstat Process font 'cmtex10' from file '/fonts/bakoma/./cmtex10.pfb' Process font 'cmtex9' from file '/fonts/bakoma/./cmtex9.pfb' Process font 'cmcsc10' from file '/fonts/bakoma/./cmcsc10.pfb' Process font 'cmmi10' from file '/fonts/bakoma/./cmmi10.pfb' Process font 'cmsy10' from file '/fonts/bakoma/./cmsy10.pfb' Process font 'cmbx10' from file '/fonts/bakoma/./cmbx10.pfb' Process font 'cmmi7' from file '/fonts/bakoma/./cmmi7.pfb' Process font 'cmr7' from file '/fonts/bakoma/./cmr7.pfb' Process font 'cmr9' from file '/fonts/bakoma/./cmr9.pfb' Process font 'cmbx9' from file '/fonts/bakoma/./cmbx9.pfb' Process font 'cmti10' from file '/fonts/bakoma/./cmti10.pfb' Process font 'cmr10' from file '/fonts/bakoma/./cmr10.pfb' Process font 'cmti9' from file '/fonts/bakoma/./cmti9.pfb' Process font 'cmr6' from file '/fonts/bakoma/./cmr6.pfb' Process font 'cmbx12' from file '/fonts/bakoma/./cmbx12.pfb' Totaly 16 files are processed. unix% ... however, with the BlueSky fonts, it breaks: unix% fload -P 35 parsecom.ps.bluesky > parsecom-fixed.ps Process PS file parsecom.ps.bluesky. Write font using statistic to parsecom.ps.fstat Process font 'CMBX10' from file '/fonts/bluesky/./CMBX10.pfb' Unexpected end of Subrs: ' 'While 39 Subrs yet not defined Unexpected end of CharStrings: ' 'While 0 CharStrings yet not defined Process font 'CMTI9' from file '/fonts/bluesky/./CMTI9.pfb' Process font 'CMSY10' from file '/fonts/bluesky/./CMSY10.pfb' unix% Since I have no idea what ``Subrs: '' are, or what ``CharStrings: '' are in this context, I have no idea what is wrong with subfont (or missing in the BlueSky fonts), or how to fix it. It would be really quite useful if I could get this working, since in the use I'm putting the fonts to, the exact advance widths of the BlueSky fonts will (I believe) result in better output than I would get with the BaKoMa fonts. If someone reading this list either knows of an alternate program for making font subsets or would have the time to investigate this problem, I'd appreciate it. Melissa. P.S. The task is converting some legacy PostScript files (without the original DVI files that created them) from using bitmaps to using PostScript fonts, so neither dvips 5.66a nor dvipsone's partial font loading are likely to help. 11-Mar-1997 5:59:07-GMT,2019;000000000000 Return-Path: Received: from topo.math.u-psud.fr (lcs@topo.math.u-psud.fr [192.54.146.180]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id WAA19234 for ; Mon, 10 Mar 1997 22:59:06 -0700 (MST) Received: (from lcs@localhost) by topo.math.u-psud.fr (8.6.12/8.6.12) id GAA27187; Tue, 11 Mar 1997 06:59:03 +0100 Date: Tue, 11 Mar 1997 06:59:03 +0100 From: Laurent Siebenmann Message-Id: <199703110559.GAA27187@topo.math.u-psud.fr> To: metafont@ens.fr, tex-fonts@math.utah.edu Subject: new CM instances *** Super-Saulter and Multimaster CM *** OK, so we have counted up to four font systems for TeX : CM, Euler, MathTime, Lucida Math , and all are available in type 1. But only one of them is meta, namely CM. Metal typesetting tradition, and my own experience indicate that meta-ness --- the evolution of character shape as point size changes (notably for indices) --- is *highly* desirable. So in some sense CM is the only *top quality* math system for TeX. How many of the thousands of type 1 prose fonts marry happily with one of the above 4. Not many I fear. I demand *at least* reasonable agreement between prose and math of (aspect ratio) and (weight), where (aspect ratio) := x-height/X-height (weight) := (black area) / (width * height) averaged CHALLENGE : Build a (metafont/Adobe) multi-parameter font system of (Saulter/multimaster) type in style CM that allows one to vary *at least* the following parameters (point size), (aspect ratio), (weight) within useful limits. The aim is to produce new instances of CM that match many of the existing type 1 prose fonts. This would surely be used for books exploiting refreshingly unfamiliar type 1 prose fonts, and it would therefore be a *saleable* product. Cheers, Larry Siebenmann 11-Mar-1997 5:59:30-GMT,1069;000000000000 Return-Path: Received: from topo.math.u-psud.fr (lcs@topo.math.u-psud.fr [192.54.146.180]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id WAA19251 for ; Mon, 10 Mar 1997 22:59:29 -0700 (MST) Received: (from lcs@localhost) by topo.math.u-psud.fr (8.6.12/8.6.12) id GAA27191; Tue, 11 Mar 1997 06:59:27 +0100 Date: Tue, 11 Mar 1997 06:59:27 +0100 From: Laurent Siebenmann Message-Id: <199703110559.GAA27191@topo.math.u-psud.fr> To: metafont@ens.fr, tex-fonts@math.utah.edu Subject: Re: MF ==> (PS type1) Re: MF ==> (PS type1) Peter Flynn writes: > ... someone ought to preserve this [Georgia Tobin's > metafont 1 Times] intact if it still exists... Was Georgia Tobin's metafont 1 Times public domain? Spivak's derived MathTime is not. Incidentally, if I am reading right, Yannis converted lams arrow fonts to type 1, and not the nascent MathTime. Can we conclude that the latter was converted to type 1 by Henderson at BSR? Larry S. 11-Mar-1997 7:18:28-GMT,2601;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id AAA21842 for ; Tue, 11 Mar 1997 00:18:27 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id XAA00436 for ; Mon, 10 Mar 1997 23:18:25 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id XAA06603 for tex-fonts@math.utah.edu; Mon, 10 Mar 1997 23:18:23 -0800 (PST) Message-Id: <199703110718.XAA06603@alonzo.cs.sfu.ca> Subject: Re: BlueSky fonts and subfont [the fix!] To: tex-fonts@math.utah.edu Date: Mon, 10 Mar 1997 23:18:23 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In an amazing feat of meddling with things I don't (fully) understand, I seem to have fixed the problems I was having with subfont. I fixed the ``Unexpected end of Subrs: '\n' While 39 Subrs yet not defined'' problem by modifying the BlueSky fonts, putting each font through the pipeline: t1disasm | grep -v '^[ \t]*$' | t1asm ... to remove some blank lines which I figured where spooking the simplistic parser used by subfont. That fixed the problems with the first two fonts, but subfont dumped core on CMSY10. Investigating with gdb, I found (eventually) that the problem lay in the fact that CMSY10 didn't have any `Subrs', and this was tickling a bug in subfont. Enclosed is a patch for that bug, for anyone else who cares about subfont. Hope this helps someone out there, Melissa. P.S. I was saying the other day that I never used gdb, but it was good to know it was there... and today, I did use it. Enc. --- subfont.c.orig Mon Mar 10 22:27:32 1997 +++ subfont.c Mon Mar 10 22:28:18 1997 @@ -1401,7 +1401,9 @@ { Subr[i] = Subr[3]; Subr[i].use = 0; } else { k = i; l++; } - MaxSubrs = k+1; /* Forget tail of unused subrs ... */ + if (k+1 < MaxSubrs) { + MaxSubrs = k+1; /* Forget tail of unused subrs ... */ + } if ( HiSubr != NULL ) { for ( i = 0 , k = 0 ; i < HiMaxSubrs ; i++ ) @@ -1409,7 +1411,9 @@ { HiSubr[i] = HiSubr[3]; HiSubr[i].use = 0; } else { k = i; l++; } - HiMaxSubrs = k+1; /* Forget tail of unused subrs ... */ + if (k+1 < MaxSubrs) { + HiMaxSubrs = k+1; /* Forget tail of unused subrs ... */ + } } l = MaxSubrs + (HiSubr == NULL ? 0 : HiMaxSubrs) - l; 11-Mar-1997 9:35:28-GMT,2241;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA24535 for ; Tue, 11 Mar 1997 02:35:27 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA14295 for ; Tue, 11 Mar 1997 09:33:23 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Tue, 11 Mar 1997 09:35:09 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA16972; Tue, 11 Mar 1997 09:34:55 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id JAA22662; Tue, 11 Mar 1997 09:34:45 GMT Date: Tue, 11 Mar 1997 09:34:45 GMT Message-Id: <199703110934.JAA22662@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: lcs@topo.math.u-psud.fr Cc: metafont@ens.fr, tex-fonts@math.utah.edu Subject: Re: new CM instances In-Reply-To: <199703110559.GAA27187@topo.math.u-psud.fr> References: <199703110559.GAA27187@topo.math.u-psud.fr> Laurent Siebenmann writes: > But only one of them is meta, namely CM. Metal typesetting tradition, > and my own experience indicate that meta-ness --- the evolution of > character shape as point size changes (notably for indices) --- is *highly* excuse me, but that isnt Meta-ness, in my book. Metaness is being able to generate a new font family by tweaking a top level driver file, isnt it? > So in some sense CM is the only *top quality* math system for TeX. in a useful sense? > The aim is to produce new instances of CM that match many of the > existing type 1 prose fonts. the problem only requires math symbols to be done, then, i assume? > This would surely be used for books exploiting refreshingly unfamiliar > type 1 prose fonts, and it would therefore be a *saleable* product. technically, yes. but as Berthold and Spivak know, making a living sell high-quality math fonts is a dangerous occupation! sebastian 11-Mar-1997 10:59:40-GMT,1202;000000000000 Return-Path: Received: from ccserv.ucc.ie (ccserv.ucc.ie [143.239.1.12]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id DAA26169 for ; Tue, 11 Mar 1997 03:59:37 -0700 (MST) Received: from curia by CCSERV.UCC.IE (PMDF #3468 ) id <01IGDGX7UOZK000Z3E@CCSERV.UCC.IE>; Tue, 11 Mar 1997 10:59:23 GMT Received: (from pflynn@localhost) by curia.ucc.ie (8.6.10/8.6.10) id KAA02228; Tue, 11 Mar 1997 10:58:14 GMT Date: 11 Mar 1997 10:58:14 +0000 (GMT) From: Peter Flynn Subject: Re: MF ==> (PS type1) To: metafont@ens.fr, tex-fonts@math.utah.edu Message-id: <199703111058.KAA02228@curia.ucc.ie> X-Envelope-to: tex-fonts@math.utah.edu Content-transfer-encoding: 7BIT > Peter Flynn writes: > > ... someone ought to preserve this [Georgia Tobin's > > metafont 1 Times] intact if it still exists... > > Was Georgia Tobin's metafont 1 Times public domain? Spivak's derived > MathTime is not. No, it was commercial (Metafoundry, Dublin OH. I think). I bought my copy from whoever was the nearest agent (UK I think) but it was a _long_ time ago. They were 300dpi bitmaps and pretty ragged (early versions?). ///Peter 11-Mar-1997 14:51:52-GMT,1980;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA01161 for ; Tue, 11 Mar 1997 07:51:49 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id JAA26843; Tue, 11 Mar 1997 09:51:18 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id JAA13323; Tue, 11 Mar 1997 09:51:16 -0500 (EST) Date: Tue, 11 Mar 1997 09:51:16 -0500 (EST) Message-Id: <199703111451.JAA13323@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: yannis@null.net CC: lcs@topo.math.u-psud.fr, metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703072117.WAA16760@imaginet.fr> (message from Yannis Haralambous on Ven, 7 Mar 97 22:22:06 -0000) Subject: Re: MF ==> (PS type1) Reply-to: bkph@ai.mit.edu Date: Ven, 7 Mar 97 22:22:06 -0000 x-sender: yannis@mail.imaginet.fr x-mailer: Claris Emailer 1.1 From: Yannis Haralambous cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" >You will have to ask Mike Spivak whether *any* of the original MF code >survived. For one, he was I think, not at all pleased with the design >and redid virtually all of it himself. And then someone (Yannis?) >made the pre 1.0 version in Type 1 format. Yes, I did Type 1 versions of the lams fonts. But as last year all my cartridges were stolen, I don't have those fonts anymore. Mike is the only one to have them (I hope he kept them, I did a very precise work so that pieces of arrows fit to each other, he had a book to publish in very high resolution, that's why he needed PS fonts) I knew that (about the lams fonts) :=). The question was about the MathTime 1.0 fonts... Regards, Berthold. 11-Mar-1997 14:55:37-GMT,1271;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA01256 for ; Tue, 11 Mar 1997 07:55:36 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id JAA26998; Tue, 11 Mar 1997 09:55:21 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id JAA13333; Tue, 11 Mar 1997 09:55:15 -0500 (EST) Date: Tue, 11 Mar 1997 09:55:15 -0500 (EST) Message-Id: <199703111455.JAA13333@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: pflynn@curia.ucc.ie CC: metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703082209.WAA10192@curia.ucc.ie> (message from Peter Flynn on 08 Mar 1997 22:09:20 +0000 (GMT)) Subject: Re: MF ==> (PS type1) Reply-to: bkph@ai.mit.edu [math fonts] >Sorry, that is just not so. There are three choices right now, Four if you include Euler as a separate font (see current issue of GUTenberg). Hmm, people keep on saying that, but there is no Euler math font set. Only EUEX. You have to use it with basic CM math fonts. ... ///Peter Berthold. 11-Mar-1997 15:00:18-GMT,13522;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA01355 for ; Tue, 11 Mar 1997 08:00:14 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id KAA27209; Tue, 11 Mar 1997 10:00:04 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA13345; Tue, 11 Mar 1997 10:00:01 -0500 (EST) Date: Tue, 11 Mar 1997 10:00:01 -0500 (EST) Message-Id: <199703111500.KAA13345@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: tex-fonts@math.utah.edu Subject: Re: UNICODE glyph standard Reply-to: bkph@ai.mit.edu re: UNICODE becoming a glyph standard It is happening as we speak :=) Check out the unicode FTP site (ftp.unicode.org), which contains the UNICODE 2.0 CD-ROM files. Buried deep down you will find: unix/mappings/vendors/apple/corpchr.txt (Here appended) This is the `corporate use subarea for Apple.' I understand other vendors (MicroSoft, Adobe, MonoType) are doing similar things. We can only hope they are coordinating to avoid stepping on each others toes. What all this does is flesh out UNICODE 2.0 so it can be somewhat useful for glyph encoding. This process is not unlike the development of Windows ANSI, which started with the not-so-great-at-all (*) ISO Latin 1, and added a bunch of typographically useful glyphs between 128 and 160 (quoteleft, quoteright, quotedblleft, quotedblright, quotesinglbase, quotedblbase, guilsinglleft, guilsinglright, endash, emdash, OE, oe, Scaron, scaron, Ydieresis, florin dagger, daggerdbl, bullet, ellipsis, perthousand, trademark, circumflex, tilde) to make a somewhat useful kludge. Regards, Berthold. (*) ISO Latin 1: Has grave, acute, dieresis, macron, cedilla, but not breve, dotaccent, and dotlessi. why? Has `grave accent' where ASCII has `quoteleft', ugh! Has `quotesingle' (`apostrophe') instead of `quoteright', Has `minus' where `hyphen' should be. Has none of the left and right single or double quotes. Does not have endash and emdash. Has several ambiguities (minus <=> hyphen, circumflex <=> asciicircum, tilde <=> asciitilde). Is an encoding that does not match ASCII in the low range. Some essentially useless characters like `Ydieresis' and `currency'. Macintosh Corporate use subarea: ########################################################################## # # Name: MacOS_CorpChars # Unicode versions: 1.1, 2.0 # Table version/date: # Current - 0.4, 15 Nov 1995 (from internal version <8>) # Add chars for Hebrew and Thai # Previous - 0.3, 15 Apr 1995 (from internal version <5>) # Author: Peter Edberg # # Copyright (c) 1995 Apple Computer, Inc. All Rights reserved. # # Apple, the Apple logo, and Macintosh are trademarks of Apple # Computer, Inc., registered in the United States and other countries. # Unicode is a trademark of Unicode Inc. For the sake of brevity, # throughout this document, "Macintosh" can be used to refer to # Macintosh computers and "Unicode" can be used to refer to the # Unicode standard. # # Apple makes no warranty or representation, either express or # implied, with respect to these tables, their quality, accuracy, or # fitness for a particular purpose. In no event will Apple be liable # for direct, indirect, special, incidental, or consequential damages # resulting from any defect or inaccuracy in this document or the # accompanying tables. # # These mapping tables and character lists are preliminary and # subject to change. Updated tables will be available from the # Unicode Inc. ftp site (unicode.org), the Apple Computer ftp site # (ftp.info.apple.com), the Apple Computer World-Wide Web pages # (http://www.info.apple.com), and possibly on diskette from APDA # (Apple's mail-order distribution service for developers). # # Format: # ------- # # Three tab-separated columns; # '#' begins a comment which continues to the end of the line. # Column #1 is the Unicode corporate character code point # (in hex as 0xNNNN) # Column #2 is a comment containing: # 1) an informal name describing the MacOS usage of the character # ("presentation" is abbreviated as "pres.") # 2) another '#' # 3) a list of the corresponding code points in MacOS encodings # (Japanese is abbreviated as just J) # # The entries are in Unicode order. #_______________________________________________________________________ */ # The following (22) are added for MacOS Thai encoding. # In this encoding, positional variants of upper vowels, tone marks, # and other marks are normally handled automatically by Worldscript I. # However, the Thai-DTP keyboard allows the codes for the positional # variants to be entered directly, so they must be treated as # characters. When the abstract character is treated as a positional # variant, it has the right (and high, if relevant) position. 0xF884 # form for THAI CHARACTER MAI HAN-AKAT, left position # Thai-x92 0xF885 # form for THAI CHARACTER SARA I, left position # Thai-x94 0xF886 # form for THAI CHARACTER SARA II, left position # Thai-x95 0xF887 # form for THAI CHARACTER SARA UE, left position # Thai-x96 0xF888 # form for THAI CHARACTER SARA UEE, left position # Thai-x97 0xF889 # form for THAI CHARACTER MAITAIKHU, left position # Thai-x93 0xF88A # form for THAI CHARACTER MAI EK, left position # Thai-x98 0xF88B # form for THAI CHARACTER MAI EK, low position # Thai-x88 0xF88C # form for THAI CHARACTER MAI EK, low left position # Thai-x83 0xF88D # form for THAI CHARACTER MAI THO, left position # Thai-x99 0xF88E # form for THAI CHARACTER MAI THO, low position # Thai-x89 0xF88F # form for THAI CHARACTER MAI THO, low left position # Thai-x84 0xF890 # form for THAI CHARACTER MAI TRI, left position # Thai-x9A 0xF891 # form for THAI CHARACTER MAI TRI, low position # Thai-x8A 0xF892 # form for THAI CHARACTER MAI TRI, low left position # Thai-x85 0xF893 # form for THAI CHARACTER MAI CHATTAWA, left position # Thai-x9B 0xF894 # form for THAI CHARACTER MAI CHATTAWA, low position # Thai-x8B 0xF895 # form for THAI CHARACTER MAI CHATTAWA, low left position # Thai-x86 0xF896 # form for THAI CHARACTER THANTHAKHAT, left position # Thai-x9C 0xF897 # form for THAI CHARACTER THANTHAKHAT, low position # Thai-x8C 0xF898 # form for THAI CHARACTER THANTHAKHAT, low left position # Thai-x87 0xF899 # form for THAI CHARACTER NIKHAHIT, left position # Thai-x8F # The following (6) are added for MacOS Hebrew encoding. Four of # these are for the obsolete "canoral" codes that were used before # System7.1/Worldscript to control positioning of nikud marks (points). # In the future these 4 code points may be redefined. 0xF89A # Hebrew ligature lamed holam # Hebrew-xC0 0xF89B # Hebrew canoral 1 # Hebrew-xC2 0xF89C # Hebrew canoral 2 # Hebrew-xC3 0xF89D # Hebrew canoral 3 # Hebrew-xC4 0xF89E # Hebrew canoral 4 # Hebrew-xC5 0xF89F # Hebrew point qamats qatan # Hebrew-xDE # The following (1) is added to handle mapping of the single undefined # code point in MacOS Greek and Turkish encodings, thus permitting full # round-trip fidelity. 0xF8A0 # undefined1 # Greek-0xFF, Turkish-0xF5 # The following (54) were added for MacOS Japanese encoding # part 1 - Apple corporate Unicode chars for MacOS Japanese extended # characters not in Unicode. 0xF8A1 # digit zero full stop # J-0x8591 0xF8A2 # roman numeral thirteen # J-0x85AB 0xF8A3 # roman numeral fourteen # J-0x85AC 0xF8A4 # roman numeral fifteen # J-0x85AD 0xF8A5 # small roman numeral thirteen # J-0x85BF 0xF8A6 # small roman numeral fourteen # J-0x85C0 0xF8A7 # small roman numeral fifteen # J-0x85C1 0xF8A8 # square m (meter?) # J-0x8645 0xF8A9 # square g (gram?) # J-0x864B 0xF8AA # square l (liter?) # J-0x8650 0xF8AB # square TB # J-0x865D 0xF8AC # FAX sign # J-0x869E 0xF8AD # downwards arrow leftwards of upwards arrow # J-0x86CE 0xF8AE # rightwards black arrow # J-0x86D3 0xF8AF # leftwards black arrow # J-0x86D4 0xF8B0 # upwards black arrow # J-0x86D5 0xF8B1 # downwards black arrow # J-0x86D6 0xF8B2 # square "limited company, ltd. [yuugen gaisha]" # J-0x87FB 0xF8B3 # square "foundation [zaidan houjin]" # J-0x87FC 0xF8B4 # inverted double prime quotation mark # J-0x8855 # part 2 - Apple corporate Unicode chars for MacOS Japanese vertical # forms not in Unicode. 0xF8B5 # pres. form for vertical IDEOGRAPHIC COMMA # J-0xEB41 0xF8B6 # pres. form for vertical IDEOGRAPHIC FULL STOP # J-0xEB42 0xF8B7 # pres. form for vertical OVERLINE # J-0xEB50 0xF8B8 # pres. form for vertical KATAKANA-HIRAGANA PROLONGED SOUND MARK # J-0xEB5B 0xF8B9 # pres. form for vertical HYPHEN # J-0xEB5D 0xF8BA # pres. form for vertical WAVE DASH # J-0xEB60 0xF8BB # pres. form for vertical DOUBLE VERTICAL LINE # J-0xEB61 0xF8BC # pres. form for vertical FULLWIDTH VERTICAL LINE # J-0xEB62 0xF8BD # pres. form for vertical MIDLINE HORIZONTAL ELLIPSIS # J-0xEB63 0xF8BE # pres. form for vertical FULLWIDTH LEFT SQUARE BRACKET # J-0xEB6D 0xF8BF # pres. form for vertical FULLWIDTH RIGHT SQUARE BRACKET # J-0xEB6E 0xF8C0 # pres. form for vertical FULLWIDTH EQUALS SIGN # J-0xEB81 0xF8C1 # pres. form for vertical HIRAGANA LETTER SMALL A # J-0xEC9F 0xF8C2 # pres. form for vertical HIRAGANA LETTER SMALL I # J-0xECA1 0xF8C3 # pres. form for vertical HIRAGANA LETTER SMALL U # J-0xECA3 0xF8C4 # pres. form for vertical HIRAGANA LETTER SMALL E # J-0xECA5 0xF8C5 # pres. form for vertical HIRAGANA LETTER SMALL O # J-0xECA7 0xF8C6 # pres. form for vertical HIRAGANA LETTER SMALL TU # J-0xECC1 0xF8C7 # pres. form for vertical HIRAGANA LETTER SMALL YA # J-0xECE1 0xF8C8 # pres. form for vertical HIRAGANA LETTER SMALL YU # J-0xECE3 0xF8C9 # pres. form for vertical HIRAGANA LETTER SMALL YO # J-0xECE5 0xF8CA # pres. form for vertical HIRAGANA LETTER SMALL WA # J-0xECEC 0xF8CB # pres. form for vertical KATAKANA LETTER SMALL A # J-0xED40 0xF8CC # pres. form for vertical KATAKANA LETTER SMALL I # J-0xED42 0xF8CD # pres. form for vertical KATAKANA LETTER SMALL U # J-0xED44 0xF8CE # pres. form for vertical KATAKANA LETTER SMALL E # J-0xED46 0xF8CF # pres. form for vertical KATAKANA LETTER SMALL O # J-0xED48 0xF8D0 # pres. form for vertical KATAKANA LETTER SMALL TU # J-0xED62 0xF8D1 # pres. form for vertical KATAKANA LETTER SMALL YA # J-0xED83 0xF8D2 # pres. form for vertical KATAKANA LETTER SMALL YU # J-0xED85 0xF8D3 # pres. form for vertical KATAKANA LETTER SMALL YO # J-0xED87 0xF8D4 # pres. form for vertical KATAKANA LETTER SMALL WA # J-0xED8E 0xF8D5 # pres. form for vertical KATAKANA LETTER SMALL KA # J-0xED95 0xF8D6 # pres. form for vertical KATAKANA LETTER SMALL KE # J-0xED96 # The following (14) were added for MacOS Dingbats encoding 0xF8D7 # medium left parenthesis ornament # Dingbats-0x80 0xF8D8 # medium right parenthesis ornament # Dingbats-0x81 0xF8D9 # medium flattened left parenthesis ornament # Dingbats-0x82 0xF8DA # medium flattened right parenthesis ornament # Dingbats-0x83 0xF8DB # medium left-pointing angle bracket ornament # Dingbats-0x84 0xF8DC # medium right-pointing angle bracket ornament # Dingbats-0x85 0xF8DD # heavy left-pointing angle quotation mark ornament # Dingbats-0x86 0xF8DE # heavy right-pointing angle quotation mark ornament # Dingbats-0x87 0xF8DF # heavy left-pointing angle bracket ornament # Dingbats-0x88 0xF8E0 # heavy right-pointing angle bracket ornament # Dingbats-0x89 0xF8E1 # light left tortoise shell bracket ornament # Dingbats-0x8A 0xF8E2 # light right tortoise shell bracket ornament # Dingbats-0x8B 0xF8E3 # medium left curly bracket ornament # Dingbats-0x8C 0xF8E4 # medium right curly bracket ornament # Dingbats-0x8D # The following (26) were added for MacOS Symbol encoding 0xF8E5 # radical extender # Symbol-0x60 0xF8E6 # vertical arrow extender # Symbol-0xBD 0xF8E7 # horizontal arrow extender # Symbol-0xBE 0xF8E8 # registered sign sans serif # Symbol-0xE2 0xF8E9 # copyright sign sans serif # Symbol-0xE3 0xF8EA # trade mark sign sans serif # Symbol-0xE4 0xF8EB # left parenthesis top # Symbol-0xE6 0xF8EC # left parenthesis extender # Symbol-0xE7 0xF8ED # left parenthesis bottom # Symbol-0xE8 0xF8EE # left square bracket top # Symbol-0xE9 0xF8EF # left square bracket extender # Symbol-0xEA 0xF8F0 # left square bracket bottom # Symbol-0xEB 0xF8F1 # left curly bracket top # Symbol-0xEC 0xF8F2 # left curly bracket center # Symbol-0xED 0xF8F3 # left curly bracket bottom # Symbol-0xEE 0xF8F4 # curly bracket extender # Symbol-0xEF 0xF8F5 # integral extender # Symbol-0xF4 0xF8F6 # right parenthesis top # Symbol-0xF6 0xF8F7 # right parenthesis extender # Symbol-0xF7 0xF8F8 # right parenthesis bottom # Symbol-0xF8 0xF8F9 # right square bracket top # Symbol-0xF9 0xF8FA # right square bracket extender # Symbol-0xFA 0xF8FB # right square bracket bottom # Symbol-0xFB 0xF8FC # right curly bracket top # Symbol-0xFC 0xF8FD # right curly bracket center # Symbol-0xFD 0xF8FE # right curly bracket bottom # Symbol-0xFE # The following (1) was added for MacOS Roman encoding 0xF8FF # Apple logo # Roman-0xF0, Symbol-0xF0, Croatian-0xD8 # NOTE: The graphic image associated with the Apple logo character is # not authorized for use without permission of Apple, and unauthorized # use might constitute trademark infringement. 11-Mar-1997 15:13:31-GMT,3767;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA01737 for ; Tue, 11 Mar 1997 08:13:30 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id KAA27797; Tue, 11 Mar 1997 10:13:26 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA13374; Tue, 11 Mar 1997 10:13:19 -0500 (EST) Date: Tue, 11 Mar 1997 10:13:19 -0500 (EST) Message-Id: <199703111513.KAA13374@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: oneill@cs.sfu.ca CC: tex-fonts@math.utah.edu In-reply-to: <199703110046.QAA05869@alonzo.cs.sfu.ca> (oneill@cs.sfu.ca) Subject: Re: BlueSky fonts and subfont Reply-to: bkph@ai.mit.edu Has anyone had success using the BlueSky fonts with Basil K. Malyshev's fload font loading program, especially the subfont program it uses to generate subset/partial fonts... When I use the BaKoMa fonts (also created by subfont's author), I get: unix% fload -P 35 parsecom-bakoma.ps > parsecom-fixed.ps Process PS file parsecom.ps.new. Write font using statistic to parsecom.ps.fstat Process font 'cmtex10' from file '/fonts/bakoma/./cmtex10.pfb' Process font 'cmtex9' from file '/fonts/bakoma/./cmtex9.pfb' ... however, with the BlueSky fonts, it breaks: unix% fload -P 35 parsecom.ps.bluesky > parsecom-fixed.ps Process PS file parsecom.ps.bluesky. Write font using statistic to parsecom.ps.fstat Process font 'CMBX10' from file '/fonts/bluesky/./CMBX10.pfb' Unexpected end of Subrs: ' 'While 39 Subrs yet not defined Unexpected end of CharStrings: ' 'While 0 CharStrings yet not defined Process font 'CMTI9' from file '/fonts/bluesky/./CMTI9.pfb' Process font 'CMSY10' from file '/fonts/bluesky/./CMSY10.pfb' unix% Since I have no idea what ``Subrs: '' are, or what ``CharStrings: '' are in this context, I have no idea what is wrong with subfont (or missing in the BlueSky fonts), or how to fix it. The program cannot handle arbitrary Type 1 fonts, only Bakoma. It gets stuck in the encrypted part which is not in exactly the same form as that in BaKoMa fonts. It would be really quite useful if I could get this working, since in the use I'm putting the fonts to, the exact advance widths of the BlueSky fonts will (I believe) result in better output than I would get with the BaKoMa fonts. But why do you want to do download or make subfonts? In the first place? Just use the new DVIPS to do it for you. And withpartial font down loading there is little use for permanent downloading to the printer. If someone reading this list either knows of an alternate program for making font subsets or would have the time to investigate this problem, I'd appreciate it. DOWNLOAD and/or SUBFONT from Y&Y can do this sort of thing. But again, I don't see the point. P.S. The task is converting some legacy PostScript files (without the original DVI files that created them) from using bitmaps to using PostScript fonts, so neither dvips 5.66a nor dvipsone's partial font loading are likely to help. Oh, I see. How about the following: rip out the bitmap fonts. Insert references to the outline fonts, but *do not include the fonts themselves* Then run through Distiller. Take the resulting PDF file read it into Acrobat Reader and print to file. if you have told Distiller where the fonts are and you have changes it settings to always subset you will have what you want. Berthold Horn 11-Mar-1997 15:16:07-GMT,1697;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id IAA01812 for ; Tue, 11 Mar 1997 08:16:05 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id KAA27910; Tue, 11 Mar 1997 10:15:44 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA13378; Tue, 11 Mar 1997 10:15:42 -0500 (EST) Date: Tue, 11 Mar 1997 10:15:42 -0500 (EST) Message-Id: <199703111515.KAA13378@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: lcs@topo.math.u-psud.fr CC: metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703110559.GAA27191@topo.math.u-psud.fr> (message from Laurent Siebenmann on Tue, 11 Mar 1997 06:59:27 +0100) Subject: Re: MF ==> (PS type1) Reply-to: bkph@ai.mit.edu Date: Tue, 11 Mar 1997 06:59:27 +0100 From: Laurent Siebenmann Re: MF ==> (PS type1) Peter Flynn writes: > ... someone ought to preserve this [Georgia Tobin's > metafont 1 Times] intact if it still exists... Was Georgia Tobin's metafont 1 Times public domain? Spivak's derived MathTime is not. Incidentally, if I am reading right, Yannis converted lams arrow fonts to type 1, and not the nascent MathTime. Can we conclude that the latter was converted to type 1 by Henderson at BSR? No. I believe Mike did it himself, using the original design only a starting point. There was no direct conversion of either MF code or high res bitmaps. Larry S. Berthold. 11-Mar-1997 16:03:06-GMT,1395;000000000000 Return-Path: Received: from mailhost.cs.auc.dk (root@mailhost.cs.auc.dk [130.225.194.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id JAA02971 for ; Tue, 11 Mar 1997 09:03:02 -0700 (MST) Received: from micro.cs.auc.dk (fj@micro.cs.auc.dk [130.225.194.68]) by mailhost.cs.auc.dk (8.8.5/8.8.5) with ESMTP id RAA28008; Tue, 11 Mar 1997 17:01:23 +0100 (MET) Received: (from fj@localhost) by micro.cs.auc.dk (8.8.5/8.8.5) id RAA11342; Tue, 11 Mar 1997 17:01:21 +0100 (MET) Date: Tue, 11 Mar 1997 17:01:21 +0100 (MET) Message-Id: <199703111601.RAA11342@micro.cs.auc.dk> From: Frank Jensen To: bkph@ai.mit.edu CC: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703111455.JAA13333@kauai.ai.mit.edu> (bkph@ai.mit.edu) Subject: Re: MF ==> (PS type1) bkph> [math fonts] bkph> >Sorry, that is just not so. There are three choices right now, bkph> bkph> Four if you include Euler as a separate font (see current issue of GUTenberg). bkph> bkph> Hmm, people keep on saying that, but there is no Euler math font set. bkph> Only EUEX. You have to use it with basic CM math fonts. This is in direct contradiction to the information given at the BSR and Y&Y web sites. So what is the truth? --- Frank Jensen, fj@cs.auc.dk Department of Computer Science Aalborg University DENMARK 11-Mar-1997 17:01:41-GMT,1961;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA04515 for ; Tue, 11 Mar 1997 10:01:39 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id MAA04628; Tue, 11 Mar 1997 12:01:01 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id MAA13462; Tue, 11 Mar 1997 12:00:58 -0500 (EST) Date: Tue, 11 Mar 1997 12:00:58 -0500 (EST) Message-Id: <199703111700.MAA13462@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: fj@cs.auc.dk CC: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703111601.RAA11342@micro.cs.auc.dk> (message from Frank Jensen on Tue, 11 Mar 1997 17:01:21 +0100 (MET)) Subject: Re: MF ==> (PS type1) Reply-to: bkph@ai.mit.edu Date: Tue, 11 Mar 1997 17:01:21 +0100 (MET) From: Frank Jensen CC: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu bkph> [math fonts] bkph> >Sorry, that is just not so. There are three choices right now, bkph> bkph> Four if you include Euler as a separate font (see current issue of GUTenberg). bkph> bkph> Hmm, people keep on saying that, but there is no Euler math font set. bkph> Only EUEX. You have to use it with basic CM math fonts. This is in direct contradiction to the information given at the BSR and Y&Y web sites. So what is the truth? Could you explain? I do not know what the contradiction is? Yes, the AMS font set exists in Type 1 format. Yes, it includes Euler fonts. But you use it *with* CM fonts for basic math, it just *extends* it. I must have somehow missed the point.... --- Frank Jensen, fj@cs.auc.dk Department of Computer Science Aalborg University DENMARK 11-Mar-1997 17:18:15-GMT,1695;000000000000 Return-Path: Received: from mailhost.cs.auc.dk (root@mailhost.cs.auc.dk [130.225.194.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA04993 for ; Tue, 11 Mar 1997 10:18:14 -0700 (MST) Received: from micro.cs.auc.dk (fj@micro.cs.auc.dk [130.225.194.68]) by mailhost.cs.auc.dk (8.8.5/8.8.5) with ESMTP id SAA29556; Tue, 11 Mar 1997 18:18:02 +0100 (MET) Received: (from fj@localhost) by micro.cs.auc.dk (8.8.5/8.8.5) id SAA11612; Tue, 11 Mar 1997 18:18:01 +0100 (MET) Date: Tue, 11 Mar 1997 18:18:01 +0100 (MET) Message-Id: <199703111718.SAA11612@micro.cs.auc.dk> From: Frank Jensen To: bkph@ai.mit.edu CC: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703111700.MAA13462@kauai.ai.mit.edu> (bkph@ai.mit.edu) Subject: Re: MF ==> (PS type1) bkph> This is in direct contradiction to the information given at the BSR bkph> and Y&Y web sites. So what is the truth? bkph> bkph> Could you explain? I do not know what the contradiction is? bkph> bkph> Yes, the AMS font set exists in Type 1 format. Yes, it includes Euler bkph> fonts. But you use it *with* CM fonts for basic math, it just bkph> *extends* it. I must have somehow missed the point.... The Euler family also contains EURM and EUSB fonts. The EURM fonts may replace CMMI and the EUSB fonts may replace the CMSY fonts (at least partially). This is what Knuth did for the Concrete Mathematics book. Look at the `gkpmac.tex' macro package (builds on the plain format). I did a similar package (`euler') for LaTeX. --- Frank Jensen, fj@cs.auc.dk Department of Computer Science Aalborg University DENMARK 11-Mar-1997 17:49:47-GMT,2356;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA05906 for ; Tue, 11 Mar 1997 10:49:45 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id MAA07617; Tue, 11 Mar 1997 12:49:17 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id MAA13502; Tue, 11 Mar 1997 12:49:15 -0500 (EST) Date: Tue, 11 Mar 1997 12:49:15 -0500 (EST) Message-Id: <199703111749.MAA13502@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: fj@cs.auc.dk CC: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703111718.SAA11612@micro.cs.auc.dk> (message from Frank Jensen on Tue, 11 Mar 1997 18:18:01 +0100 (MET)) Subject: Re: MF ==> (PS type1) Reply-to: bkph@ai.mit.edu Date: Tue, 11 Mar 1997 18:18:01 +0100 (MET) From: Frank Jensen CC: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu bkph> This is in direct contradiction to the information given at the BSR bkph> and Y&Y web sites. So what is the truth? bkph> Could you explain? I do not know what the contradiction is? bkph> Yes, the AMS font set exists in Type 1 format. Yes, it includes Euler bkph> fonts. But you use it *with* CM fonts for basic math, it just bkph> *extends* it. I must have somehow missed the point.... The Euler family also contains EURM and EUSB fonts. The EURM fonts may replace CMMI and the EUSB fonts may replace the CMSY fonts (at least partially). This is what Knuth did for the Concrete Mathematics book. Look at the `gkpmac.tex' macro package (builds on the plain format). I did a similar package (`euler') for LaTeX. EURM contains only alphabetic characters. Ditto for EUSB, which is a bold Script face. So basically what you are saying is that you can replace the letters in the CM math fonts with letters from other fonts. Of course one can do this with any text font. Why single out Euler? By the way, I still don't see the `contradiction' you alluded to :=). Frank Jensen, fj@cs.auc.dk Department of Computer Science Aalborg University DENMARK Berthold Horn. 11-Mar-1997 18:00:58-GMT,1497;000000000000 Return-Path: Received: from mailhost.cs.auc.dk (root@mailhost.cs.auc.dk [130.225.194.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA06242 for ; Tue, 11 Mar 1997 11:00:20 -0700 (MST) Received: from micro.cs.auc.dk (fj@micro.cs.auc.dk [130.225.194.68]) by mailhost.cs.auc.dk (8.8.5/8.8.5) with ESMTP id TAA00214; Tue, 11 Mar 1997 19:00:10 +0100 (MET) Received: (from fj@localhost) by micro.cs.auc.dk (8.8.5/8.8.5) id TAA11754; Tue, 11 Mar 1997 19:00:08 +0100 (MET) Date: Tue, 11 Mar 1997 19:00:08 +0100 (MET) Message-Id: <199703111800.TAA11754@micro.cs.auc.dk> From: Frank Jensen To: bkph@ai.mit.edu CC: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703111749.MAA13502@kauai.ai.mit.edu> (bkph@ai.mit.edu) Subject: Re: MF ==> (PS type1) bkph> EURM contains only alphabetic characters. bkph> Ditto for EUSB, which is a bold Script face. bkph> So basically what you are saying is that you can replace the letters bkph> in the CM math fonts with letters from other fonts. bkph> Of course one can do this with any text font. Why single out Euler? I don't know the Type1 version of the Euler fonts. But the MF version contains almost everything needed to make up a complete math setup -- including digits, punctuation characters, plus, minus, division sign, \sum, \prod, delimiters, ... This is not generally true about any other font family (that I know about at least). /Frank 11-Mar-1997 18:35:46-GMT,2843;000000000000 Return-Path: Received: from mailhost.cs.auc.dk (root@mailhost.cs.auc.dk [130.225.194.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA07290 for ; Tue, 11 Mar 1997 11:35:44 -0700 (MST) Received: from micro.cs.auc.dk (fj@micro.cs.auc.dk [130.225.194.68]) by mailhost.cs.auc.dk (8.8.5/8.8.5) with ESMTP id TAA00763; Tue, 11 Mar 1997 19:35:33 +0100 (MET) Received: (from fj@localhost) by micro.cs.auc.dk (8.8.5/8.8.5) id TAA11847; Tue, 11 Mar 1997 19:35:27 +0100 (MET) Date: Tue, 11 Mar 1997 19:35:27 +0100 (MET) Message-Id: <199703111835.TAA11847@micro.cs.auc.dk> From: Frank Jensen To: bkph@ai.mit.edu, pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703111800.TAA11754@micro.cs.auc.dk> (message from Frank Jensen on Tue, 11 Mar 1997 19:00:08 +0100 (MET)) Subject: Re: MF ==> (PS type1) fj> bkph> EURM contains only alphabetic characters. fj> bkph> Ditto for EUSB, which is a bold Script face. fj> bkph> So basically what you are saying is that you can replace the letters fj> bkph> in the CM math fonts with letters from other fonts. fj> bkph> Of course one can do this with any text font. Why single out Euler? fj> fj> I don't know the Type1 version of the Euler fonts. But the MF version fj> contains almost everything needed to make up a complete math setup -- fj> including digits, punctuation characters, plus, minus, division sign, fj> \sum, \prod, delimiters, ... I forgot the most important thing: greek letters, both lowercase and uppercase. EUSB is indeed a bold script font. What I meant to refer to was EUSM/EUSB (for the medium and bold script fonts). This font (the MF version of it at least) has a layout similar to CMSY, although some characters are missing (\cdot, \times, and such). It is slightly misleading to say that EURM contains only alphabetic characters, since it contains all latin and greek letters in both lowercase and uppercase versions. In addition, it contains arabic numerals, some punctuation characters, less than/greater than signs, the `slash' and the \partial signs, \imath, \jmath. The layout is similar to CMMI. Again, I can only talk about the MF version, since that is the only version I know. bkph> By the way, I still don't see the `contradiction' you alluded to :=). You said that only EUEX was available in Type1 format, but the BSR and Y&Y web sites say that also the other Euler fonts are available. I assumed that the Type1 versions of these fonts contained the same glyphs as the MF versions, so I concluded that enough glyphs were available to create the ``Euler look'' from the Concrete Mathematics book using Type1 fonts only. But if my assumptions about the Type1 versions of the Euler fonts are incorrect, then my conclusion is also wrong. /Frank 11-Mar-1997 18:41:34-GMT,3725;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id LAA07450 for ; Tue, 11 Mar 1997 11:41:33 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id KAA27472 for ; Tue, 11 Mar 1997 10:41:31 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id KAA13942 for tex-fonts@math.utah.edu; Tue, 11 Mar 1997 10:41:29 -0800 (PST) Message-Id: <199703111841.KAA13942@alonzo.cs.sfu.ca> Subject: Re: BlueSky fonts and subfont (and FixFont) To: tex-fonts@math.utah.edu Date: Tue, 11 Mar 1997 10:41:28 -0800 (PST) In-Reply-To: <199703111513.KAA13374@kauai.ai.mit.edu> from "Berthold K.P. Horn" at Mar 11, 97 10:13:19 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I wrote: >> Has anyone had success using the BlueSky fonts with Basil K. Malyshev's >> fload font loading program, especially the subfont program it uses >> to generate subset/partial fonts? [Right now it crashes with them.] ... and Berthold replied: > The program cannot handle arbitrary Type 1 fonts, only Bakoma. > It gets stuck in the encrypted part which is not in exactly the same > form as that in BaKoMa fonts. That turns out to be not quite true. It turns out that it is possible to massage (some) other fonts (including the BlueSky ones) into a form that subfont will parse. Certainly though, subfont's parser isn't robust. (Plus it had a bug in dealing with fonts that had no `Subrs'.) >> [Does anyone] reading this list [know] of an alternate program for >> making font subsets[?]. > > DOWNLOAD and/or SUBFONT from Y&Y can do this sort of thing. > But again, I don't see the point. DOWNLOAD and/or SUBFONT from Y&Y aren't free though, right? (This isn't something I'd really want to spend any money doing.) >> The task is converting some legacy PostScript files (without the >> original DVI files that created them) from using bitmaps to using >> PostScript fonts, so neither dvips 5.66a nor dvipsone's partial font >> loading are likely to help. I forgot to mention here that I'm using the marvelous `FixFont' utility for this task. > How about the following: rip out the bitmap fonts. Insert references > to the outline fonts, but *do not include the fonts themselves* Then > run through Distiller. Take the resulting PDF file read it into > Acrobat Reader and print to file. if you have told Distiller where > the fonts are and you have changes it settings to always subset you > will have what you want. Yes, this possibility occured to me (except that I'd have included the PostScript fonts (unsubsetted) in the file to distill, since distiller is of on another machine somewhere). But I guess I couldn't let go of the fact that it'd work for BaKoMa and not for BlueSky; I needed to try to fix it -- call me obsessive. (And, as we saw in a later e-mail, I succeeded.) One remaining issue is that even with the BlueSky fonts, replacing the PK fonts with type1 fonts doesn't result in the exact same output. Some positioning is subtly changed (in long runs of text) -- it's especially noticiable in things like tables of contents where the numbers on the righthand side turns out wobbly. Anyone know of why this might happen and better how it might be fixed? Regards, Melissa. P.S. Also, does anyone know whether `t1disasm | t1asm' performed on a font is in any way lossy? (I'd like to be sure that I've not damaged my BlueSky fonts in way by piping them through these tools). 11-Mar-1997 19:05:35-GMT,2759;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id MAA08147 for ; Tue, 11 Mar 1997 12:05:34 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id OAA11536; Tue, 11 Mar 1997 14:00:17 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id OAA13542; Tue, 11 Mar 1997 14:00:14 -0500 (EST) Date: Tue, 11 Mar 1997 14:00:14 -0500 (EST) Message-Id: <199703111900.OAA13542@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: fj@cs.auc.dk CC: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703111835.TAA11847@micro.cs.auc.dk> (message from Frank Jensen on Tue, 11 Mar 1997 19:35:27 +0100 (MET)) Subject: Re: MF ==> (PS type1) Reply-to: bkph@ai.mit.edu I forgot the most important thing: greek letters, both lowercase and uppercase. EUSB is indeed a bold script font. What I meant to refer to was EUSM/EUSB (for the medium and bold script fonts). This font (the MF version of it at least) has a layout similar to CMSY, although some characters are missing (\cdot, \times, and such). You can rest assured that the Type 1 versions have *exactly* the same glyphs as the original MF versions (except they also have a genuine `space' character). It is slightly misleading to say that EURM contains only alphabetic characters, since it contains all latin and greek letters in both lowercase and uppercase versions. In addition, it contains arabic numerals, some punctuation characters, less than/greater than signs, the `slash' and the \partial signs, \imath, \jmath. The layout is similar to CMMI. Well it has the alphabet in the same place :=) But it is missing most of the `math' glyphs. Again, I can only talk about the MF version, since that is the only version I know. See above. bkph> By the way, I still don't see the `contradiction' you alluded to :=). You said that only EUEX was available in Type1 format, but the BSR and Y&Y web sites say that also the other Euler fonts are available. You misunderstood. What I meant was that the only `math' font in the Euler font group is EUEX*. I assumed that the Type1 versions of these fonts contained the same glyphs as the MF versions, so I concluded that enough glyphs were available to create the ``Euler look'' from the Concrete Mathematics book using Type1 fonts only. Well, tell me whether it uses CM math fonts or not. Then we can settle the question of whether there is a `fourth choice' /Frank 11-Mar-1997 20:03:58-GMT,3006;000000000000 Return-Path: Received: from comp.uark.edu (luecking@comp.uark.edu [130.184.252.197]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id NAA09763 for ; Tue, 11 Mar 1997 13:03:55 -0700 (MST) Received: (from luecking@localhost) by comp.uark.edu (8.8.5/8.7.3) id OAA29569; Tue, 11 Mar 1997 14:03:23 -0600 (CST) Date: Tue, 11 Mar 1997 14:03:23 -0600 (CST) From: "Daniel H. Luecking" X-Sender: luecking@comp Reply-To: "Daniel H. Luecking" To: Metafont distribution list cc: tex-fonts@math.utah.edu Subject: Is EULER math?; was: Re: MF ==> (PS type1 In-Reply-To: <199703111835.TAA11847@micro.cs.auc.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Pardon me for jumping in here late. I have been following this exchange between B.K.P.Horn and F.Jensen and it seems as if there might be some misunderstandings going on. Maybe I can help. I actually prepared a math article using Concrete + Euler (+ CM). I followed closely (I hope exactly!) the arrangement of fonts laid out in gkpmac.tex, the macro package allegedly used for Concrete Mathematics. The font set CC and EU were intended to go together, with the Concrete fonts used for text, the Euler for math. Essentially: CCR replaces CMR (and similarly for other text fonts) EUR replaces CMMI (but it lacks a 17 glyphs, mostly arrows and accents) EUS replaces a small part of CMSY (37 glyphs: \cal A...Z, plus 11 more) EUEX replaces a small part of CMEX (50 glyphs including sums, (co)products, integrals, some arrows and all the various bits of braces) For a full featured math setup, the other extensible symbols (parentheses, brackets, etc.) are drawn from CMEX. And virtually all the specialized relations and binary operations are drawn from CMSY. I understood B.K.P. Horn to say that the Euler family was not mainly a math family except for EUEX. This is partly (maybe mostly) correct. I do not think he meant to say anything about their availability in Type 1 format. If the book Concrete Mathematics (as printed) followed the macros in gkpmac.tex, then it would certainly have needed CMEX at least (or a replacement) and might possibly have needed CMSY. Indeed, I have read comments from Knuth that EUEX was needed only for the few cases where the CM symbols did not blend well with the EU family. This suggests that they were used or at least intended to be used. To me, it makes equally good sense to regard EU as extending CM or to regard CM as extending EU, with respect to the math fonts. Dan Luecking -------->-------->-------->-------->-------->--------v Mathematical Sciences <---+ luecking@comp.uark.edu | Univ. of Arkansas <---| http://comp.uark.edu/~luecking/ | Fayetteville, AR 72101 <---+--<--------<--------<--------<--------< 11-Mar-1997 20:22:30-GMT,3747;000000000000 Return-Path: Received: from life.ai.mit.edu (ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id NAA10359 for ; Tue, 11 Mar 1997 13:22:28 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id PAA15644; Tue, 11 Mar 1997 15:22:24 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id PAA13575; Tue, 11 Mar 1997 15:22:22 -0500 (EST) Date: Tue, 11 Mar 1997 15:22:22 -0500 (EST) Message-Id: <199703112022.PAA13575@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: oneill@cs.sfu.ca CC: tex-fonts@math.utah.edu In-reply-to: <199703111841.KAA13942@alonzo.cs.sfu.ca> (oneill@cs.sfu.ca) Subject: Re: BlueSky fonts and subfont (and FixFont) Reply-to: bkph@ai.mit.edu I wrote: ... and Berthold replied: >> The task is converting some legacy PostScript files (without the >> original DVI files that created them) from using bitmaps to using >> PostScript fonts, so neither dvips 5.66a nor dvipsone's partial font >> loading are likely to help. I forgot to mention here that I'm using the marvelous `FixFont' utility for this task. Could you amplify on that? > How about the following: rip out the bitmap fonts. Insert references > to the outline fonts, but *do not include the fonts themselves* Then > run through Distiller. Take the resulting PDF file read it into > Acrobat Reader and print to file. if you have told Distiller where > the fonts are and you have changes it settings to always subset you > will have what you want. Yes, this possibility occured to me (except that I'd have included the PostScript fonts (unsubsetted) in the file to distill, since distiller is of on another machine somewhere). Important point, as you say to do it this way you want the fonts to be `unsubsetted' Otherwise Distiller thinks they are complete fonts. In your case they would naturally be unsubsetted, but I have seen people produce bad PDF by having partial fonts in the PS files (as opposed to none which is by far the best - or complete fonts). One remaining issue is that even with the BlueSky fonts, replacing the PK fonts with type1 fonts doesn't result in the exact same output. Some positioning is subtly changed (in long runs of text) -- it's especially noticiable in things like tables of contents where the numbers on the righthand side turns out wobbly. Anyone know of why this might happen and better how it might be fixed? This is because DVIPS output is not resolution-independent. It uses rounded off advance widths for the characters. Normally these `rounding effects' tend to cancel out since they tend to be random. But you can see them build up when the same letter is used repeatedly or in a fixed width font, where all the `rounding effects' have the same sign. The advance widths in the Type 1 fonts are exact (fractional) and hence do not match the PK fonts advance widths exactly. You don't see this problem when you produce output from DVIPS directly using Type 1 fonts, since it forces the same fixed resolution onto the Type 1 fonts by redefining their metrics. Regards, Melissa. P.S. Also, does anyone know whether `t1disasm | t1asm' performed on a font is in any way lossy? (I'd like to be sure that I've not damaged my BlueSky fonts in way by piping them through these tools). I believe they should be lossfree since they do not touch the hinting or the outlines or change the subroutine structure. You will lose any hidden comments buried in the encrypted part. Berthold Horn 11-Mar-1997 21:28:39-GMT,4491;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id OAA12229 for ; Tue, 11 Mar 1997 14:28:37 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id NAA04914 for ; Tue, 11 Mar 1997 13:28:35 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id NAA14155 for tex-fonts@math.utah.edu; Tue, 11 Mar 1997 13:28:33 -0800 (PST) Message-Id: <199703112128.NAA14155@alonzo.cs.sfu.ca> Subject: Re: BlueSky fonts and subfont (and FixFont, dvips & PDF) To: tex-fonts@math.utah.edu Date: Tue, 11 Mar 1997 13:28:33 -0800 (PST) In-Reply-To: <199703112022.PAA13575@kauai.ai.mit.edu> from "Berthold K.P. Horn" at Mar 11, 97 03:22:22 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I wrote: >> [...] I'm using the marvelous `FixFont' utility for [the task of >> converting some legacy PostScript files (without the original DVI >> files that created them) from using bitmaps to using BlueSky outline >> fonts]. ... and Berthold replied: > Could you amplify on that? Certainly, see http://www.emrg.com/texpdf.html for details, or just download it from http://www.emrg.com/FixFont.tar and read the README file. Basically, it uses a database which has 32-bit hash-codes for each glyph of each CM font at each resolution. It tries to match the glyphs in the PS file's bitmap fonts to these hashes, and when it thinks it has a match (you can vary how many matches it needs before it substitutes), it substitutes the font for the outline version. Obviously, the resolution needs to be in the database and the Metafont mode fairly similar. You can make your own database for local modes, but the provided database has worked remarkably well on the files I've tried. And all of the above is necessary because older dvips versions never cared to put in any comments as to just what PK fonts it was inserting. Berthold also writes: > Important point, as you say [when including the outline fonts in the > PostScript file for distiller] you want the fonts to be `unsubsetted' > Otherwise Distiller thinks they are complete fonts. In your case they > would naturally be unsubsetted, but I have seen people produce bad > PDF by having partial fonts in the PS files (as opposed to none which > is by far the best - or complete fonts). Can you explain why this is bad PDF? I fear that in the past I may have made just such files, since my dvips is configured to always subset fonts (and include fonts not in the `Standard 35') and I've given that output to distiller. (I have distiller configured to always subset fonts too, which seems to result in some (useful) font renaming in this case, the subset of `cmmi10', which dvips 5.60a called `cmmi10', got called `AGPGAL+cmmi10' in the PDF file). > You don't see this problem when you produce output from DVIPS directly > using Type 1 fonts, since it forces the same fixed resolution onto > the Type 1 fonts by redefining their metrics. Ah. This explains things then; FixFont just uses: /DvipsFontMatrix [ 4 0 0 -4 0 0 ] def % ... and later ... /Fa { /CMR10 findfont 10.000 scalefont DvipsFontMatrix makefont setfont } def ...whereas dvips, when asked to use BlueSky fonts directly dvips utters: /rf{findfont dup length 1 add dict begin{1 index /FID ne 2 index /UniqueID ne and{def}{pop pop}ifelse}forall[1 index 0 6 -1 roll exec 0 exch 5 -1 roll VResolution Resolution div mul neg 0 0]/Metrics exch def dict begin Encoding{exch dup type /integertype ne{pop pop 1 sub dup 0 le{pop}{[}ifelse}{FontMatrix 0 get div Metrics 0 get div def} ifelse}forall Metrics /Metrics currentdict end def[2 index currentdict end definefont 3 -1 roll makefont /setfont load]cvx def}def % ... and later ... /Fa 141[33 2[42 2[23 6[37 46 12[85 14[62 22[42 2[23 46[{}9 83.022003 /CMR10 rf I guess I could fix things for FixFont so it too munged the metrics of the font, but my PostScript hacking isn't too great. Anyone else want to try it? Myself, while I can readily understand FixFont's incantation, it would probably take me a whole evening with the Red Book beside me to figure out how to extract the relevant parts of what dvips is doing. Best Regards, Melissa. 12-Mar-1997 12:55:07-GMT,5041;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA03944 for ; Wed, 12 Mar 1997 05:55:05 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id HAA18688; Wed, 12 Mar 1997 07:55:01 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id HAA13867; Wed, 12 Mar 1997 07:54:59 -0500 (EST) Date: Wed, 12 Mar 1997 07:54:59 -0500 (EST) Message-Id: <199703121254.HAA13867@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: oneill@cs.sfu.ca CC: tex-fonts@math.utah.edu In-reply-to: <199703112128.NAA14155@alonzo.cs.sfu.ca> (oneill@cs.sfu.ca) Subject: Re: BlueSky fonts and subfont (and FixFont, dvips & PDF) Reply-to: bkph@ai.mit.edu Berthold also writes: > Important point, as you say [when including the outline fonts in the > PostScript file for distiller] you want the fonts to be `unsubsetted' > Otherwise Distiller thinks they are complete fonts. In your case they > would naturally be unsubsetted, but I have seen people produce bad > PDF by having partial fonts in the PS files (as opposed to none which > is by far the best - or complete fonts). Can you explain why this is bad PDF? I fear that in the past I may have made just such files, since my dvips is configured to always subset fonts (and include fonts not in the `Standard 35') and I've given that output to distiller. There are a few reasons. The first is that you now cannot tell for sure whether fonts are subsetted, since Distiller assumes what you gave it is the complete font and unless it finds more stuff to strip out it will mark it as such. So if you look in `Document Info > Fonts' it will not be listed as `embedded subset (Acrobat 3.0) or with the random prefix (Acrobat 2.1). More seriously, you can run into problems where ATM is used to render using one partial font and it thinks that is it and builds a cache on that information, only to then see a different partial set in another fonts. Glyphs that occur in the second job but not the first may disappear (it depends on the version of Acrobat - whether it has built in ATM or uses the one installed on your machine etc.). Also, I have seen Acrobat Readers encoding problems aroused by such files. (I have distiller configured to always subset fonts too, which seems to result in some (useful) font renaming in this case, You know that is not enough, right? You *also* have to set MaxSubsetPct to 99 or 100. The default value is way too low to be useful. In Acrobat 3.0 you can do this by fiddling with preferences or options. In Acrobat 2.1 it required adding a file to the startup directory. It will only subset if you use 10% or fewer (Acrobat 2.1) of the glyphs, whicih often means that most fonts are included in complete form. * This is important. Many people think they are sending out files with * partial fonts because they have checked the `subset fonts' check box. * This is *not* enough. You must also set MaxSubsetPct to a high value. * I think this is discussed in places like http://www.YandY.com/pdf_from.pdf the subset of `cmmi10', which dvips 5.60a called `cmmi10', got called `AGPGAL+cmmi10' in the PDF file). > You don't see this problem when you produce output from DVIPS directly > using Type 1 fonts, since it forces the same fixed resolution onto > the Type 1 fonts by redefining their metrics. Ah. This explains things then; FixFont just uses: /DvipsFontMatrix [ 4 0 0 -4 0 0 ] def % ... and later ... /Fa { /CMR10 findfont 10.000 scalefont DvipsFontMatrix makefont setfont } def ...whereas dvips, when asked to use BlueSky fonts directly dvips utters: /rf{findfont dup length 1 add dict begin{1 index /FID ne 2 index /UniqueID ne and{def}{pop pop}ifelse}forall[1 index 0 6 -1 roll exec 0 exch 5 -1 roll VResolution Resolution div mul neg 0 0]/Metrics exch def dict begin Encoding{exch dup type /integertype ne{pop pop 1 sub dup 0 le{pop}{[}ifelse}{FontMatrix 0 get div Metrics 0 get div def} ifelse}forall Metrics /Metrics currentdict end def[2 index currentdict end definefont 3 -1 roll makefont /setfont load]cvx def}def % ... and later ... /Fa 141[33 2[42 2[23 6[37 46 12[85 14[62 22[42 2[23 46[{}9 83.022003 /CMR10 rf I guess I could fix things for FixFont so it too munged the metrics of the font, but my PostScript hacking isn't too great. Anyone else want to try it? Myself, while I can readily understand FixFont's incantation, it would probably take me a whole evening with the Red Book beside me to figure out how to extract the relevant parts of what dvips is doing. Well, its a worthy project for someone stuck with a huge pile of legacy documents. For me, I rather produce clean PS and clean PDF from sratch :-) Berthold Horn. 12-Mar-1997 14:02:13-GMT,4840;000000000000 Return-Path: Received: from mailhost.cs.auc.dk (root@mailhost.cs.auc.dk [130.225.194.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA05309 for ; Wed, 12 Mar 1997 07:02:11 -0700 (MST) Received: from micro.cs.auc.dk (fj@micro.cs.auc.dk [130.225.194.68]) by mailhost.cs.auc.dk (8.8.5/8.8.5) with ESMTP id PAA19061; Wed, 12 Mar 1997 15:02:02 +0100 (MET) Received: (from fj@localhost) by micro.cs.auc.dk (8.8.5/8.8.5) id PAA14116; Wed, 12 Mar 1997 15:02:02 +0100 (MET) Date: Wed, 12 Mar 1997 15:02:02 +0100 (MET) Message-Id: <199703121402.PAA14116@micro.cs.auc.dk> From: Frank Jensen To: luecking@comp.uark.edu CC: metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: (luecking@comp.uark.edu) Subject: Re: Is EULER math?; was: Re: MF ==> (PS type1 dhl> I actually prepared a math article using Concrete + Euler (+ CM). I dhl> followed closely (I hope exactly!) the arrangement of fonts laid out in dhl> gkpmac.tex, the macro package allegedly used for Concrete Mathematics. I prepared (but I didn't write it) a whole book using Concrete + Euler. The book was prepared using LaTeX(2e). In the process, I created the LaTeX packages `beton' and `euler', and I examined closely the `gkpmac' macro package that indeed was used for preparing Concrete Mathematics. dhl> The font set CC and EU were intended to go together, with the Concrete dhl> fonts used for text, the Euler for math. Essentially: That's how Knuth originally intended them to be used. But I find that the Euler fonts are sufficiently distinctive (i.e., they do not look like any text font that I know of). So I have used the Euler fonts in combination with other text fonts with a weight similar to Concrete. In particular, I have used them with Bitstream Charter. dhl> CCR replaces CMR (and similarly for other text fonts) dhl> EUR replaces CMMI (but it lacks a 17 glyphs, mostly arrows and dhl> accents) Euler does not have variants of sigma and rho (so you must use the regular shapes). The (harpoon) arrows are in EUEX. If you need the triangles, the \star, the \vec accent, or hooks for the arrows, then you still need CMMI. I do not consider the special symbols \flat, \natural, \sharp, \smile, and \frown to be math symbols; I believe they were put there because Knuth did not want to leave any slots empty in the fonts. dhl> EUS replaces a small part of CMSY (37 glyphs: \cal A...Z, plus 11 more) The arrows and \infty are in EUEX. Also, don't forget the EUF fonts which has parentheses, square brackets, plus, minus, division, equals sign, and oldstyle numerals (in addition to the Fraktur letters). dhl> EUEX replaces a small part of CMEX (50 glyphs including sums, dhl> (co)products, integrals, some arrows and all the dhl> various bits of braces) dhl> dhl> For a full featured math setup, the other extensible symbols dhl> (parentheses, brackets, etc.) are drawn from CMEX. And virtually all the dhl> specialized relations and binary operations are drawn from CMSY. dhl> If the book Concrete Mathematics (as printed) followed the macros in dhl> gkpmac.tex, then it would certainly have needed CMEX at least (or dhl> a replacement) and might possibly have needed CMSY. Indeed, I have read dhl> comments from Knuth that EUEX was needed only for the few cases where dhl> the CM symbols did not blend well with the EU family. This suggests dhl> that they were used or at least intended to be used. Knuth's macros was dictated by the needs of the Concrete Mathematics book. He did not intend to create a complete replacement for the CM fonts, and why should he? Would it make sense for him to spend time designing a \cdot, \times, or a \subset sign for the Euler family? Especially if the new versions would be quite similar to the originals or if they were not needed at all for the Concrete Mathematics book (which is the case for many of the specialized operators and relations). The EUEX font was created when somebody mentioned that it looked strange with CM sum signs together with the other Euler symbols (the first few chapters of Concrete Mathematics has especially many sum signs). Later came the integral sign and the arrows. dhl> To me, it makes equally good sense to regard EU as extending CM dhl> or to regard CM as extending EU, with respect to the math fonts. Even though Euler must draw on CM for a number of specialized symbols (typically `simple' shapes such as \times), I would characterize it as being an alternative to the CM, not an extension. Would it have made sense to characterize MathTime (before MathTime Plus was created) as an extension to CM, since it had to draw on CM for bold latin and greek letters? I think not. /Frank 13-Mar-1997 9:43:52-GMT,3336;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA03450 for ; Thu, 13 Mar 1997 02:43:51 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id BAA27006 for ; Thu, 13 Mar 1997 01:43:49 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id BAA21333 for tex-fonts@math.utah.edu; Thu, 13 Mar 1997 01:43:47 -0800 (PST) Message-Id: <199703130943.BAA21333@alonzo.cs.sfu.ca> Subject: Re: BlueSky fonts and subfont (really FixFont and dvips) To: tex-fonts@math.utah.edu Date: Thu, 13 Mar 1997 01:43:47 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Across two messages, Berthold wrote: > [...] DVIPS output is not resolution-independent. It uses rounded > off advance widths for the characters. Normally these `rounding > effects' tend to cancel out since they tend to be random. But you > can see them build up when the same letter is used repeatedly or in > a fixed width font, where all the `rounding effects' have the same > sign. The advance widths in the Type 1 fonts are exact (fractional) > and hence do not match the PK fonts advance widths exactly. > > You don't see this problem when you produce output from DVIPS directly > using Type 1 fonts, since it forces the same fixed resolution onto > the Type 1 fonts by redefining their metrics. > > [Working out how fix FixFont so it too fiddled with the metrics > of the font] a worthy project for someone stuck with a huge pile of > legacy documents. For me, I rather produce clean PS and clean PDF from > scratch :-) Well, I did it, I wrote postscript code that tied into the CDevProc hook in the font to round the advance widths appropriately. I still didn't get good results though, and it turned out that the code for font selection inserted by the `FixFonts' program was just plain wrong. The details are short enough for me to enclose for anyone who cares. Melissa. Enc. First, we have the macro to alter the advance widths; it actually does nothing on older Level-1, but I can't say as I care about that. Thus: % NEWNAME OLDNAME hackfont - /hackfont {findfont dup length 1 add dict begin {1 index /FID ne 2 index /UniqueID ne and {def} {pop pop} ifelse} forall /CDevProc {pop 10 -1 roll matrix defaultmatrix dup dup 0 get exch 2 get add abs 72 mul exch currentmatrix dup 0 get exch 2 get add abs div dup 3 1 roll div Resolution mul round Resolution div mul 10 1 roll} def currentdict end definefont pop} def ... and then the macro to scale the font to the appropriate size: % FONT POINTSIZE dvipsmakefont SCALEDFONT /dvipsmakefont {[Resolution 72.27 div 2 index mul 0 0 Resolution -72.27 div 6 -1 roll mul 0 0] makefont} def Thus, whereas before, FixFont would have output: /Fa { /CMR10 findfont 10.0 scalefont DvipsFontMatrix makefont setfont } def ... we replace that with: /CMR10fixed /CMR10 hackfont /Fa { /CMR10fixed findfont 10.0 dvipsmakefont setfont } def And that, is all there is to it (I think). Whoop-de-do. 14-Mar-1997 6:52:27-GMT,3253;000000000000 Return-Path: Received: from topo.math.u-psud.fr (lcs@topo.math.u-psud.fr [192.54.146.180]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id XAA02486 for ; Thu, 13 Mar 1997 23:52:26 -0700 (MST) Received: (from lcs@localhost) by topo.math.u-psud.fr (8.6.12/8.6.12) id HAA10993; Fri, 14 Mar 1997 07:52:22 +0100 Date: Fri, 14 Mar 1997 07:52:22 +0100 From: Laurent Siebenmann Message-Id: <199703140652.HAA10993@topo.math.u-psud.fr> To: metafont@ens.fr, tex-fonts@math.utah.edu Subject: Malyshev's work *** Basil Malyshev's METAFONT ==> PS Type 1 conversion tools *** I wrote: > There > are probably many more, especially when one widens the scope to > logic, physics, chemistry, and beyond. If Malyshev's MF ==> (PS > type1) conversion were fully published, such problems would be > readily solved. Berthold Horn replied: > But why would he do that? Have you asked him? Do you > realize there is an enormous amount of hand work involved > beyond the automation? When Basil Malyshev's worked on METAFONT ==> PS Type 1 conversion there was a clear conflict of interest between him and those (Berthold for one) who had earlier created the CM/PS & AMS/PS as a commercial product. I am morally certain that this conflict made him rather hesitant in promoting and perfecting his work. Now that the CM/PS & AMS/PS work is freely availably, it would certainly be timely and appropriate that Malyshev's work become more available. Basil was laid up with a broken knee last summer so there was *no* news whatever of his work at the 1996 TUG meeting in Dubna not too far from Protvino. I understand that Basil did this conversion as part of his doctorate and it turned out to be by itself much more than a doctorate. Just how much *hand* work was required beyond what he managed to do with programs and scripts is deliciously open to conjecture. He did manage to do far more conversions than anyone has ever done and in a far shorter time --- while cultivating a reputation for indolence. Why would it be good to have fully published foundations for important operations like METAFONT ==> type 1? Obviously because technology like science is pyramidal. Even Berthold will have to concede that the availability of dvips code and documentation has had a very positive influence: I would hope that METAFOG (commercial, under devellopment, for PC?) would profit, much as Berthold's DVIPSONE has profited from dvips. Other platforms like unix & Mac need a jumpstart on this conversion problem. Last but not least, the *several* activists on this list who have toyed with this conversion problem would finally know pretty well the status of their own work and feel encouraged to publish/sell or go on to the next lap. Let us encourage Basil to fully publish his tools and also his type 1 fonts in the dramatically altered situation the free release of CM/PS & AMS/PS has created. I will of course be disapointed if he decides not to do so. But even the certain knowlege that he has definitively left the subject behind him would clear away barriers to progress. Cheers Larry Siebenmann 14-Mar-1997 10:02:15-GMT,3672;000000000000 Return-Path: Received: from utkux.utcc.utk.edu (UTKUX1.UTK.EDU [128.169.76.67]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id DAA07008 for ; Fri, 14 Mar 1997 03:02:14 -0700 (MST) Received: by utkux.utcc.utk.edu (5.x/2.8s-UTK.UTCC) id AA04654; Fri, 14 Mar 1997 05:02:14 -0500 Received: from nef.ens.fr by utkux.utcc.utk.edu (5.x/2.8s-UTK.UTCC) id AA11564; Wed, 12 Mar 1997 03:07:12 -0500 Received: from (listserv@localhost) by nef.ens.fr (8.8.5/jtpda-5.1) with TULP id TAA23475 ; Tue, 11 Mar 1997 19:36:48 +0100 (MET) Received: from mailhost.cs.auc.dk (mailhost.cs.auc.dk [130.225.194.2]) by nef.ens.fr (8.8.5/jtpda-5.1) with ESMTP id TAA23304 for ; Tue, 11 Mar 1997 19:35:41 +0100 (MET) Received: from micro.cs.auc.dk (fj@micro.cs.auc.dk [130.225.194.68]) by mailhost.cs.auc.dk (8.8.5/8.8.5) with ESMTP id TAA00763; Tue, 11 Mar 1997 19:35:33 +0100 (MET) Received: (from fj@localhost) by micro.cs.auc.dk (8.8.5/8.8.5) id TAA11847; Tue, 11 Mar 1997 19:35:27 +0100 (MET) Date: Tue, 11 Mar 1997 19:35:27 +0100 (MET) Message-Id: <199703111835.TAA11847@micro.cs.auc.dk> From: Frank Jensen To: bkph@ai.mit.edu, pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu In-Reply-To: <199703111800.TAA11754@micro.cs.auc.dk> (message from Frank Jensen on Tue, 11 Mar 1997 19:00:08 +0100 (MET)) Subject: Re: MF ==> (PS type1) Errors-To: listman2@ens.fr X-Sequence: 1099 fj> bkph> EURM contains only alphabetic characters. fj> bkph> Ditto for EUSB, which is a bold Script face. fj> bkph> So basically what you are saying is that you can replace the letters fj> bkph> in the CM math fonts with letters from other fonts. fj> bkph> Of course one can do this with any text font. Why single out Euler? fj> fj> I don't know the Type1 version of the Euler fonts. But the MF version fj> contains almost everything needed to make up a complete math setup -- fj> including digits, punctuation characters, plus, minus, division sign, fj> \sum, \prod, delimiters, ... I forgot the most important thing: greek letters, both lowercase and uppercase. EUSB is indeed a bold script font. What I meant to refer to was EUSM/EUSB (for the medium and bold script fonts). This font (the MF version of it at least) has a layout similar to CMSY, although some characters are missing (\cdot, \times, and such). It is slightly misleading to say that EURM contains only alphabetic characters, since it contains all latin and greek letters in both lowercase and uppercase versions. In addition, it contains arabic numerals, some punctuation characters, less than/greater than signs, the `slash' and the \partial signs, \imath, \jmath. The layout is similar to CMMI. Again, I can only talk about the MF version, since that is the only version I know. bkph> By the way, I still don't see the `contradiction' you alluded to :=). You said that only EUEX was available in Type1 format, but the BSR and Y&Y web sites say that also the other Euler fonts are available. I assumed that the Type1 versions of these fonts contained the same glyphs as the MF versions, so I concluded that enough glyphs were available to create the ``Euler look'' from the Concrete Mathematics book using Type1 fonts only. But if my assumptions about the Type1 versions of the Euler fonts are incorrect, then my conclusion is also wrong. /Frank ############################# Notice: This message was found in a dead-letter box and appears to be for you. If you have already gotten a copy of this message, we beg your tolerance. The Unix Systems Group 14-Mar-1997 10:15:07-GMT,2326;000000000000 Return-Path: Received: from utkux.utcc.utk.edu (UTKUX1.UTK.EDU [128.169.76.67]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id DAA07261 for ; Fri, 14 Mar 1997 03:15:06 -0700 (MST) Received: by utkux.utcc.utk.edu (5.x/2.8s-UTK.UTCC) id AA06721; Fri, 14 Mar 1997 05:14:56 -0500 Received: from nef.ens.fr by utkux.utcc.utk.edu (5.x/2.8s-UTK.UTCC) id AA12062; Wed, 12 Mar 1997 03:10:56 -0500 Received: from (listserv@localhost) by nef.ens.fr (8.8.5/jtpda-5.1) with TULP id TAA21825 ; Tue, 11 Mar 1997 19:01:19 +0100 (MET) Received: from mailhost.cs.auc.dk (mailhost.cs.auc.dk [130.225.194.2]) by nef.ens.fr (8.8.5/jtpda-5.1) with ESMTP id TAA21754 for ; Tue, 11 Mar 1997 19:00:15 +0100 (MET) Received: from micro.cs.auc.dk (fj@micro.cs.auc.dk [130.225.194.68]) by mailhost.cs.auc.dk (8.8.5/8.8.5) with ESMTP id TAA00214; Tue, 11 Mar 1997 19:00:10 +0100 (MET) Received: (from fj@localhost) by micro.cs.auc.dk (8.8.5/8.8.5) id TAA11754; Tue, 11 Mar 1997 19:00:08 +0100 (MET) Date: Tue, 11 Mar 1997 19:00:08 +0100 (MET) Message-Id: <199703111800.TAA11754@micro.cs.auc.dk> From: Frank Jensen To: bkph@ai.mit.edu Cc: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu In-Reply-To: <199703111749.MAA13502@kauai.ai.mit.edu> (bkph@ai.mit.edu) Subject: Re: MF ==> (PS type1) Errors-To: listman2@ens.fr X-Sequence: 1097 bkph> EURM contains only alphabetic characters. bkph> Ditto for EUSB, which is a bold Script face. bkph> So basically what you are saying is that you can replace the letters bkph> in the CM math fonts with letters from other fonts. bkph> Of course one can do this with any text font. Why single out Euler? I don't know the Type1 version of the Euler fonts. But the MF version contains almost everything needed to make up a complete math setup -- including digits, punctuation characters, plus, minus, division sign, \sum, \prod, delimiters, ... This is not generally true about any other font family (that I know about at least). /Frank ############################# Notice: This message was found in a dead-letter box and appears to be for you. If you have already gotten a copy of this message, we beg your tolerance. The Unix Systems Group 14-Mar-1997 13:29:11-GMT,1906;000000000000 Return-Path: Received: from heaton.cl.cam.ac.uk (exim@heaton.cl.cam.ac.uk [128.232.0.11]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id GAA10966 for ; Fri, 14 Mar 1997 06:29:04 -0700 (MST) Received: from cl.cam.ac.uk [128.232.1.34] (rf) by heaton.cl.cam.ac.uk with esmtp (Exim 1.59 #2) id 0w5WzU-00052t-00; Fri, 14 Mar 1997 13:25:48 +0000 To: Laurent Siebenmann cc: metafont@ens.fr, tex-fonts@math.utah.edu Subject: Re: Malyshev's work In-reply-to: Your message of "Fri, 14 Mar 1997 07:52:22 +0100." <199703140652.HAA10993@topo.math.u-psud.fr> Date: Fri, 14 Mar 1997 13:25:44 +0000 From: Robin Fairbairns Message-Id: > When Basil Malyshev's worked on METAFONT ==> PS Type 1 > conversion there was a clear conflict of interest between him and > those (Berthold for one) who had earlier created the CM/PS & > AMS/PS as a commercial product. I am morally certain that this > conflict made him rather hesitant in promoting and perfecting his > work. [...] Your morals are plainly different from mine. My understanding is that he found the work *very* time-consuming and exhausting, and wanted some monetary recompense (remember, he lives in Russia, and so probably hardly ever acquires any money via what you or I would consider `normal' channels). Hence his original restrictions on use by commercial organisations. ISTR that someone's given him some money somehow, and the restrictions have been lifted. He still does not release his conversion code, or give any details of the manual operations involved. Maybe he hopes to wow the world some time with a conversion of the EC fonts... (And to earn some _real_ money, perhaps.) I wouldn't expect anything much of him in the immediate future. Robin 14-Mar-1997 13:31:45-GMT,2524;000000000000 Return-Path: Received: from utkux.utcc.utk.edu (UTKUX1.UTK.EDU [128.169.76.67]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id GAA10998 for ; Fri, 14 Mar 1997 06:31:38 -0700 (MST) Received: by utkux.utcc.utk.edu (5.x/2.8s-UTK.UTCC) id AA28416; Fri, 14 Mar 1997 08:31:39 -0500 Received: from nef.ens.fr by utkux.utcc.utk.edu (5.x/2.8s-UTK.UTCC) id AA24743; Wed, 12 Mar 1997 04:03:42 -0500 Received: from (listserv@localhost) by nef.ens.fr (8.8.5/jtpda-5.1) with TULP id SAA19621 ; Tue, 11 Mar 1997 18:19:15 +0100 (MET) Received: from mailhost.cs.auc.dk (mailhost.cs.auc.dk [130.225.194.2]) by nef.ens.fr (8.8.5/jtpda-5.1) with ESMTP id SAA19520 for ; Tue, 11 Mar 1997 18:18:08 +0100 (MET) Received: from micro.cs.auc.dk (fj@micro.cs.auc.dk [130.225.194.68]) by mailhost.cs.auc.dk (8.8.5/8.8.5) with ESMTP id SAA29556; Tue, 11 Mar 1997 18:18:02 +0100 (MET) Received: (from fj@localhost) by micro.cs.auc.dk (8.8.5/8.8.5) id SAA11612; Tue, 11 Mar 1997 18:18:01 +0100 (MET) Date: Tue, 11 Mar 1997 18:18:01 +0100 (MET) Message-Id: <199703111718.SAA11612@micro.cs.auc.dk> From: Frank Jensen To: bkph@ai.mit.edu Cc: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu In-Reply-To: <199703111700.MAA13462@kauai.ai.mit.edu> (bkph@ai.mit.edu) Subject: Re: MF ==> (PS type1) Errors-To: listman2@ens.fr X-Sequence: 1094 bkph> This is in direct contradiction to the information given at the BSR bkph> and Y&Y web sites. So what is the truth? bkph> bkph> Could you explain? I do not know what the contradiction is? bkph> bkph> Yes, the AMS font set exists in Type 1 format. Yes, it includes Euler bkph> fonts. But you use it *with* CM fonts for basic math, it just bkph> *extends* it. I must have somehow missed the point.... The Euler family also contains EURM and EUSB fonts. The EURM fonts may replace CMMI and the EUSB fonts may replace the CMSY fonts (at least partially). This is what Knuth did for the Concrete Mathematics book. Look at the `gkpmac.tex' macro package (builds on the plain format). I did a similar package (`euler') for LaTeX. --- Frank Jensen, fj@cs.auc.dk Department of Computer Science Aalborg University DENMARK ############################# Notice: This message was found in a dead-letter box and appears to be for you. If you have already gotten a copy of this message, we beg your tolerance. The Unix Systems Group 14-Mar-1997 14:15:15-GMT,2792;000000000000 Return-Path: Received: from utkux.utcc.utk.edu (UTKUX1.UTK.EDU [128.169.76.67]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id HAA11903 for ; Fri, 14 Mar 1997 07:15:12 -0700 (MST) Received: by utkux.utcc.utk.edu (5.x/2.8s-UTK.UTCC) id AA13891; Fri, 14 Mar 1997 09:14:59 -0500 Received: from nef.ens.fr by utkux.utcc.utk.edu (5.x/2.8s-UTK.UTCC) id AB26022; Wed, 12 Mar 1997 04:10:07 -0500 Received: from (listserv@localhost) by nef.ens.fr (8.8.5/jtpda-5.1) with TULP id SAA18724 ; Tue, 11 Mar 1997 18:02:40 +0100 (MET) Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by nef.ens.fr (8.8.5/jtpda-5.1) with ESMTP id SAA18513 for ; Tue, 11 Mar 1997 18:01:21 +0100 (MET) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id MAA04628; Tue, 11 Mar 1997 12:01:01 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id MAA13462; Tue, 11 Mar 1997 12:00:58 -0500 (EST) Date: Tue, 11 Mar 1997 12:00:58 -0500 (EST) Message-Id: <199703111700.MAA13462@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: fj@cs.auc.dk Cc: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu In-Reply-To: <199703111601.RAA11342@micro.cs.auc.dk> (message from Frank Jensen on Tue, 11 Mar 1997 17:01:21 +0100 (MET)) Subject: Re: MF ==> (PS type1) Reply-To: bkph@ai.mit.edu Errors-To: listman2@ens.fr X-Sequence: 1093 Date: Tue, 11 Mar 1997 17:01:21 +0100 (MET) From: Frank Jensen CC: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu bkph> [math fonts] bkph> >Sorry, that is just not so. There are three choices right now, bkph> bkph> Four if you include Euler as a separate font (see current issue of GUTenberg). bkph> bkph> Hmm, people keep on saying that, but there is no Euler math font set. bkph> Only EUEX. You have to use it with basic CM math fonts. This is in direct contradiction to the information given at the BSR and Y&Y web sites. So what is the truth? Could you explain? I do not know what the contradiction is? Yes, the AMS font set exists in Type 1 format. Yes, it includes Euler fonts. But you use it *with* CM fonts for basic math, it just *extends* it. I must have somehow missed the point.... --- Frank Jensen, fj@cs.auc.dk Department of Computer Science Aalborg University DENMARK ############################# Notice: This message was found in a dead-letter box and appears to be for you. If you have already gotten a copy of this message, we beg your tolerance. The Unix Systems Group 14-Mar-1997 18:20:43-GMT,2053;000000000000 Return-Path: Received: from beach.frankfurt.netsurf.de (beach.frankfurt.netsurf.de [194.64.181.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id LAA18588 for ; Fri, 14 Mar 1997 11:20:42 -0700 (MST) Received: from puma.npc.de (deck-12.frankfurt.netsurf.de [194.64.181.44]) by beach.frankfurt.netsurf.de (8.6.12/8.6.12) with ESMTP id TAA02587; Fri, 14 Mar 1997 19:20:30 +0100 Received: (from schrod@localhost) by puma.npc.de (8.6.12/8.6.12) id TAA03919; Fri, 14 Mar 1997 19:00:03 +0100 Received: (from schrod@localhost) by puma.npc.de (8.6.12/8.6.12) id SAA03916; Fri, 14 Mar 1997 18:59:53 +0100 Date: Fri, 14 Mar 1997 18:59:53 +0100 Message-Id: <199703141759.SAA03916@puma.npc.de> From: Joachim Schrod To: Robin Fairbairns Cc: metafont@ens.fr, tex-fonts@math.utah.edu Subject: Re: Malyshev's work In-Reply-To: References: <199703140652.HAA10993@topo.math.u-psud.fr> Mime-Version: 1.0 (generated by tm-edit 7.95) Content-Type: text/plain; charset=US-ASCII >>>>> "RF" == Robin Fairbairns writes: RF> Hence his original restrictions on use by commercial RF> organisations. RF> ISTR that someone's given him some money somehow, and the restrictions RF> have been lifted. Have they? The README on CTAN doesn't tell so. BaKoMa Fonts ``cannot be sold or distributed with any commercial product or used in any commercial organization without additional agreement with author.'' IMO they even cannot be distributed on CDs without checks, as ``If you want to charge a small fee via distribution these fonts or any derivations from this fonts, you should contact the author.'' Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: jschrod@acm.org Net & Publication Consultance GmbH Tel.: +49-6074-861530 Roedermark, Germany Fax: +49-6074-861531 14-Mar-1997 20:50:45-GMT,5144;000000000000 Return-Path: Received: from math.ams.org (MATH.AMS.ORG [130.44.210.14]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id NAA22950 for ; Fri, 14 Mar 1997 13:50:37 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 14 Mar 1997 20:50:33 UT Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V5.1-8 #16534) id <01IGHKKF2FYO0017A7@AXP14.AMS.ORG> for tex-fonts@math.utah.edu; Fri, 14 Mar 1997 15:49:51 EST Date: Fri, 14 Mar 1997 15:49:50 -0500 (EST) From: Ralph Youngen Subject: Computer Modern PostScript Fonts To: info-tex@shsu.edu, tex-fonts@math.utah.edu, texhax@tex.ac.uk, metafont@ens.fr Cc: rey@ams.org Message-id: <858372590.561040.REY@MATH.AMS.ORG> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Mail-system-version: The American Mathematical Society is pleased to announce the public release of the Computer Modern PostScript Fonts in Adobe Type 1 format. The READ.ME file that accompanies this release appears below. We call your attention to the second full paragraph of the READ.ME file which discusses the AMS copyright associated with this release. We hope that this explanation will set aside any possible confusion regarding the intent of the AMS copyright with respect to these fonts. Ralph Youngen Director, Electronic Product Development American Mathematical Society -------------------- Computer Modern PostScript Fonts (Adobe Type 1 format) ----------------------------------------------------------------------------- The PostScript Type 1 implementation of the Computer Modern fonts produced by and previously distributed by Blue Sky Research and Y&Y, Inc. are now freely available for general use. This has been accomplished through the cooperation of a consortium of scientific publishers with Blue Sky Research and Y&Y. Members of this consortium include: Elsevier Science IBM Corporation Society for Industrial and Applied Mathematics (SIAM) Springer-Verlag American Mathematical Society (AMS) In order to assure the authenticity of these fonts, copyright will be held by the American Mathematical Society. This is not meant to restrict in any way the legitimate use of the fonts, such as (but not limited to) electronic distribution of documents containing these fonts, inclusion of these fonts into other public domain or commercial font collections or computer applications, use of the outline data to create derivative fonts and/or faces, etc. However, the AMS does require that the AMS copyright notice be removed from any derivative versions of the fonts which have been altered in any way. In addition, to ensure the fidelity of TeX documents using Computer Modern fonts, Professor Donald Knuth, creator of the Computer Modern faces, has requested that any alterations which yield different font metrics be given a different name. The AMS does not provide technical support or installation assistance beyond any installation instructions included in this file. Installation and use of these fonts may require some technical expertise. Review this READ.ME file in its entirety before undertaking an installation. ---------------------------------------------------------------------------- History The PostScript versions of the Computer Modern fonts were produced in 1988 by Blue Sky Research of Portland, Oregon, and Y&Y, Inc., of Concord, Massachusetts, who published the fonts in conjunction with their commercial implementations of the TeX program. Character outlines were derived from high-resolution METAFONT-generated character bitmaps by the ScanLab application from Projective Solutions (Ian Morrison and Henry Pinkham), applied and corrected by Douglas Henderson of Blue Sky Research. Character hints were created by software from Y&Y (Berthold and Blenda Horn), with extensive hand work by Blenda Horn. Font engineering, production, and packaging were by Douglas Henderson and Berthold Horn. The CMMI* fonts were revised in 1996 to conform to Knuth's changes to the greek delta and arrow characters. ---------------------------------------------------------------------------- Font Distributions The canonical version of the Computer Modern PostScript Fonts is located on the AMS FTP server, e-math.ams.org, at /pub/tex/cmfonts/ps. This area is also mirrored on the Comprehensive TeX Archive Network (CTAN) at fonts/cm/ps-type1/bluesky. The following three files are in this directory for you to download: cmps-macintosh.hqx for use on a Macintosh, contains fonts in standard Macintosh Type 1 format cmps-pc.zip for use on a Windows or DOS system, contains fonts in PFB format with PFM metrics files cmps-unix.tar.gz for use on a Unix system, contains fonts in PFB format with AFM metrics files Each distribution includes a READ.ME file which contains instructions for installing the fonts. Please review the READ.ME file in its entirety before undertaking to install the fonts on your system. 16-Mar-1997 8:54:38-GMT,3187;000000000000 Return-Path: Received: from utkux.utcc.utk.edu (UTKUX1.UTK.EDU [128.169.76.67]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id BAA07702 for ; Sun, 16 Mar 1997 01:54:37 -0700 (MST) Received: by utkux.utcc.utk.edu (5.x/2.8s-UTK.UTCC) id AB06297; Sun, 16 Mar 1997 03:54:39 -0500 Received: from nef.ens.fr by utkux.utcc.utk.edu (5.x/2.8s-UTK.UTCC) id AA25368; Wed, 12 Mar 1997 04:07:53 -0500 Received: from (listserv@localhost) by nef.ens.fr (8.8.5/jtpda-5.1) with TULP id SAA21326 ; Tue, 11 Mar 1997 18:50:47 +0100 (MET) Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by nef.ens.fr (8.8.5/jtpda-5.1) with ESMTP id SAA21274 for ; Tue, 11 Mar 1997 18:49:41 +0100 (MET) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.11) with ESMTP id MAA07617; Tue, 11 Mar 1997 12:49:17 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id MAA13502; Tue, 11 Mar 1997 12:49:15 -0500 (EST) Date: Tue, 11 Mar 1997 12:49:15 -0500 (EST) Message-Id: <199703111749.MAA13502@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: fj@cs.auc.dk Cc: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu In-Reply-To: <199703111718.SAA11612@micro.cs.auc.dk> (message from Frank Jensen on Tue, 11 Mar 1997 18:18:01 +0100 (MET)) Subject: Re: MF ==> (PS type1) Reply-To: bkph@ai.mit.edu Errors-To: listman2@ens.fr X-Sequence: 1096 Date: Tue, 11 Mar 1997 18:18:01 +0100 (MET) From: Frank Jensen CC: pflynn@curia.ucc.ie, metafont@ens.fr, tex-fonts@math.utah.edu bkph> This is in direct contradiction to the information given at the BSR bkph> and Y&Y web sites. So what is the truth? bkph> Could you explain? I do not know what the contradiction is? bkph> Yes, the AMS font set exists in Type 1 format. Yes, it includes Euler bkph> fonts. But you use it *with* CM fonts for basic math, it just bkph> *extends* it. I must have somehow missed the point.... The Euler family also contains EURM and EUSB fonts. The EURM fonts may replace CMMI and the EUSB fonts may replace the CMSY fonts (at least partially). This is what Knuth did for the Concrete Mathematics book. Look at the `gkpmac.tex' macro package (builds on the plain format). I did a similar package (`euler') for LaTeX. EURM contains only alphabetic characters. Ditto for EUSB, which is a bold Script face. So basically what you are saying is that you can replace the letters in the CM math fonts with letters from other fonts. Of course one can do this with any text font. Why single out Euler? By the way, I still don't see the `contradiction' you alluded to :=). Frank Jensen, fj@cs.auc.dk Department of Computer Science Aalborg University DENMARK Berthold Horn. ############################# Notice: This message was found in a dead-letter box and appears to be for you. If you have already gotten a copy of this message, we beg your tolerance. The Unix Systems Group 17-Mar-1997 16:05:24-GMT,1368;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id JAA14117 for ; Mon, 17 Mar 1997 09:05:17 -0700 (MST) Received: from fell.open.ac.uk by venus.open.ac.uk with SMTP Local (PP) id <17761-0@venus.open.ac.uk>; Mon, 17 Mar 1997 16:00:51 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id PAA03537; Mon, 17 Mar 1997 15:59:51 GMT Date: Mon, 17 Mar 1997 15:59:51 GMT Message-Id: <199703171559.PAA03537@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Sebastian Rahtz Cc: lcs@topo.math.u-psud.fr, metafont@ens.fr, tex-fonts@math.utah.edu Subject: Re: new CM instances In-Reply-To: <199703110934.JAA22662@lochnagarn.elsevier.co.uk> References: <199703110559.GAA27187@topo.math.u-psud.fr> <199703110934.JAA22662@lochnagarn.elsevier.co.uk> Sebastian wrote -- > > technically, yes. but as Berthold and Spivak know, making a living > sell high-quality math fonts is a dangerous occupation! > Whereas making a living not selling them but keeping them and using them to make money seems to be safe enough (at least for our friends at CUP Prining). chris 18-Mar-1997 13:29:08-GMT,2689;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA12236 for ; Tue, 18 Mar 1997 06:29:07 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.13) with ESMTP id IAA04234; Tue, 18 Mar 1997 08:26:25 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA16745; Tue, 18 Mar 1997 08:26:24 -0500 (EST) Date: Tue, 18 Mar 1997 08:26:24 -0500 (EST) Message-Id: <199703181326.IAA16745@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: lcs@topo.math.u-psud.fr CC: metafont@ens.fr, tex-fonts@math.utah.edu In-reply-to: <199703140652.HAA10993@topo.math.u-psud.fr> (message from Laurent Siebenmann on Fri, 14 Mar 1997 07:52:22 +0100) Subject: Re: Malyshev's work Reply-to: bkph@ai.mit.edu Laurent says: technology like science is pyramidal. Even Berthold will have to concede that the availability of dvips code and documentation has had a very positive influence: I would hope that METAFOG Yes, DVIPS is wonderful and has helped propel the TeX world into the PostScript era. Few remember that there was enormous resistance, mostly because PS was invented by Adobe and Adobe is a commercial organization. You don't believe me? I am sure you also won't believe me 5-10 years down the row when I tell you that once there was enormous resistance to Acrobat PDF in the TeX world :=) (commercial, under devellopment, for PC?) would profit, much as Berthold's DVIPSONE has profited from dvips. Other platforms like But to set the record straight: I have never read DVIPS code or bothered to learn about its command line switches. I must admit to fiddling with Nelson Beebe's DVIALW in the old days, trying to change it to make it do what I wanted - I can't deny learning something from that. (I am forced to use DVIPS here at MIT AI on Unix, but that is another story). On the other hand, it is gratifying in a way to see features of DVIPSONE such as `partial font downloading' make it into other DVI drivers :=) unix & Mac need a jumpstart on this conversion problem. Let us encourage Basil to fully publish his tools and also his type 1 fonts in the dramatically altered situation the free release of CM/PS & AMS/PS has created. I will of course be disapointed if he decides not to do so. But even the certain knowlege that he has definitively left the subject behind him would clear away barriers to progress. Cheers Larry Siebenmann Berthold Horn 18-Mar-1997 14:00:27-GMT,2325;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA12810 for ; Tue, 18 Mar 1997 07:00:26 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id NAA10109 for ; Tue, 18 Mar 1997 13:58:13 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Tue, 18 Mar 1997 14:01:03 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id OAA09861; Tue, 18 Mar 1997 14:00:59 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id OAA08954; Tue, 18 Mar 1997 14:00:51 GMT Date: Tue, 18 Mar 1997 14:00:51 GMT Message-Id: <199703181400.OAA08954@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: bkph@ai.mit.edu Cc: lcs@topo.math.u-psud.fr, metafont@ens.fr, tex-fonts@math.utah.edu Subject: Re: Malyshev's work In-Reply-To: <199703181326.IAA16745@kauai.ai.mit.edu> References: <199703140652.HAA10993@topo.math.u-psud.fr> <199703181326.IAA16745@kauai.ai.mit.edu> Berthold K. P. Horn writes: > Yes, DVIPS is wonderful and has helped propel the TeX world into the > PostScript era. Few remember that there was enormous resistance, > mostly because PS was invented by Adobe and Adobe is a commercial When was this resistance, Berthold? I started TeX in 1986; in 1987 I went to the TUG meeting in Seattle, and talked to many people about dvi to PS drivers; Stephan von B was just then finishing his effort, Textures of course had PS output, and I gave many people copies of a dvi2ps set up to under builtin PS fonts. I dont recall any suggestion of opposition to Adobe or to PS. > another story). On the other hand, it is gratifying in a way to see > features of DVIPSONE such as `partial font downloading' make it into > other DVI drivers :=) you are right. if i understand right. Rokicki's code comes from Sergey Lesenko, who started from Malyshev's fload, which came from seeing dvipsone. then then i may be rewriting history,.... sebastian 19-Mar-1997 10:43:54-GMT,2346;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id DAA10896 for ; Wed, 19 Mar 1997 03:43:53 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id CAA19186; Wed, 19 Mar 1997 02:43:51 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id CAA18226; Wed, 19 Mar 1997 02:43:50 -0800 (PST) Message-Id: <199703191043.CAA18226@alonzo.cs.sfu.ca> Subject: T1 encoding and font subsetting dont mix in dvips (?) To: rokicki@cs.stanford.edu, tex-fonts@math.utah.edu Date: Wed, 19 Mar 1997 02:43:49 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit It seems that I've stumbled on a bug with font subsetting in dvips... unix% cat < utopian.tex \documentclass{article} \usepackage{utopia} \usepackage[T1]{fontenc} \begin{document} \pagestyle{empty} na\"{\i}ve was I \end{document} END unix% latex utopian.tex This is TeX, Version 3.14159 (C version 6.1) (utopian.tex LaTeX2e <1996/12/01> (/usr/local/tex/texmf/tex/latex/base/article.cls Document Class: article 1996/10/31 v1.3u Standard LaTeX document class (/usr/local/tex/texmf/tex/latex/base/size10.clo)) (/usr/local/tex/texmf/tex/latex/psnfss/utopia.sty) (/usr/local/tex/texmf/tex/latex/base/fontenc.sty (/usr/local/tex/texmf/tex/latex/base/t1enc.def)) (utopian.aux) (/usr/local/tex/texmf/tex/latex/psnfss/T1put.fd) [1] (utopian.aux) ) Output written on utopian.dvi (1 page, 220 bytes). Transcript written on utopian.log. unix% dvips utopian.dvi This is dvips 5.70 Copyright 1997 Radical Eye Software (www.radicaleye.com) ' TeX output 1997.03.19:0211' -> utopian.ps <8r.enc>. Error: '/idieresis' not found in reencoding vector <8r.enc> for [1] unix% ... sigh ... If one removes the ``\usepackage[T1]{fontenc}'', the problem mysteriously goes away, as it does if one uses ``dvips -j0'' to disable font subsetting. I've tried vainly to track the problem down, but alas no luck, since `/idieresis' plainly is in 8r.enc. Any idea of a fix would be greatly appreciated, source patches especially. Melissa. 19-Mar-1997 13:26:11-GMT,1543;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA14081 for ; Wed, 19 Mar 1997 06:26:10 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id FAA00096 for ; Wed, 19 Mar 1997 05:26:09 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id FAA23642 for tex-fonts@math.utah.edu; Wed, 19 Mar 1997 05:26:07 -0800 (PST) Message-Id: <199703191326.FAA23642@alonzo.cs.sfu.ca> Subject: Re: T1 encoding and font subsetting dont mix in dvips (?) To: thierry.bouche@ujf-grenoble.fr Date: Wed, 19 Mar 1997 05:25:29 -0800 (PST) In-Reply-To: <199703191225.NAA04560@mozart.ujf-grenoble.fr> from "Thierry Bouche" at Mar 19, 97 01:25:31 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: oneill@cs.sfu.ca Thierry Bouche writes: > starnge I can't reproduce it, but I had an analogous problem with > lucida... > > dvips texput -odvipsk 5.66a Copyright 1986-97 Radical Eye Software (www.radicaleye.com) > ' TeX output 1997.03.19:1309' -> texput.ps > <8r.enc>. [1] My problems begain with ludida, but I reduced it down to a simpler example with a free font so that more people could try. Strange that you can't reproduce it, though... *sigh* Melissa. 19-Mar-1997 17:08:44-GMT,752;000000000000 Return-Path: Received: from Xenon.Stanford.EDU (Xenon.Stanford.EDU [171.64.64.24]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id KAA19413 for ; Wed, 19 Mar 1997 10:08:40 -0700 (MST) Received: (from rokicki@localhost) by Xenon.Stanford.EDU (8.8.4/8.8.4) id JAA16742; Wed, 19 Mar 1997 09:10:57 -0800 (PST) Date: Wed, 19 Mar 1997 09:10:57 -0800 (PST) From: "Tomas G. Rokicki" Message-Id: <199703191710.JAA16742@Xenon.Stanford.EDU> To: oneill@cs.sfu.ca, rokicki@CS.Stanford.EDU, tex-fonts@math.utah.edu Subject: Re: T1 encoding and font subsetting dont mix in dvips (?) Thanks for the mail! I'll get this fixed as soon as possible . . . -tom 20-Mar-1997 2:26:01-GMT,3554;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id TAA03356 for ; Wed, 19 Mar 1997 19:25:58 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id SAA08282; Wed, 19 Mar 1997 18:25:51 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id SAA24375; Wed, 19 Mar 1997 18:25:50 -0800 (PST) Message-Id: <199703200225.SAA24375@alonzo.cs.sfu.ca> Subject: Re: T1 encoding and font subsetting dont mix in dvips (fixed, kinda) To: rokicki@cs.stanford.edu (Tomas G. Rokicki) Date: Wed, 19 Mar 1997 18:25:49 -0800 (PST) Cc: tex-fonts@math.utah.edu In-Reply-To: <199703191710.JAA16742@Xenon.Stanford.EDU> from "Tomas G. Rokicki" at Mar 19, 97 09:10:57 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Further to my mailing, here's a fix for dvips... The problem I encountered was due to the fact that t1part.c seemed to think that if a glyph wasn't accessible in a font's default encoding, it couldn't be accessed no matter how much reencoding was done. This is blatantly wrong. Enclosed is a hack to the source that makes it do the right thing... it could probably be cleaned up a little. It seems though, that I've now found a different bug. It seems that even on my first example that supposidly worked, t1part somehow botches the job of subsetting Utopia. This is true of 5.60 and 5.70 and unrelated to my previous encoding bug and fix. Thankfully, really I was working in Lucida, so this isn't an immediate problem for me. In other news, I also consider the current handling of ``%%DocumentFonts:'' identically to ``%%DocumentNeededFonts:'' to be a bug. Thus, I have patch for finclude.c too. Best Regards, Melissa. Enc. --- t1part.c.orig Sun Mar 2 20:15:54 1997 +++ t1part.c Wed Mar 19 18:06:48 1997 @@ -562,7 +562,9 @@ while (ThisChar != NULL) { CHAR *tm = ThisChar; - fprintf(fout, "dup %d %s put\n",ThisChar->num,ThisChar->name); + if (ThisChar->num > 0) { + fprintf(fout, "dup %d %s put\n", ThisChar->num, ThisChar->name); + } ThisChar = ThisChar->NextChar; free(tm); } @@ -675,6 +677,18 @@ return 1; } } + if (ThisChar->NextChar == NULL) { + CHAR *NewChar = getmem(sizeof(CHAR)); + + NewChar->name = getmem(length + 1); + strcpy(NewChar->name, name); + NewChar->length = length; + NewChar->num = -1; + NewChar->NextChar = NULL; + NewChar->choose = 1; + ThisChar->NextChar = NewChar; + return 1; + } ThisChar = ThisChar->NextChar; } return -1; --- finclude.c.orig Wed Mar 19 01:22:20 1997 +++ finclude.c Wed Mar 19 01:23:43 1997 @@ -18,7 +18,9 @@ #define getname vms_getname #endif +#ifndef NeXT double atof(); +#endif /* * These are the external routines we call. */ @@ -356,17 +358,7 @@ char *p; char *psfile; { - if (strncmp(p, "%%DocumentFonts: ",17) == 0) { - p += 17 ; - while (*p && *p <= ' ') - p++ ; - if(!strncmp(p,"(atend)",7)) { - check_atend = 1; - } else { - scan_fontnames(p,psfile); - fc_state = 1; - } - } else if (strncmp(p, "%%DocumentNeededFonts: ",23)==0) { + if (strncmp(p, "%%DocumentNeededFonts: ",23)==0) { p += 23 ; while (*p && *p <= ' ') p++ ; 20-Mar-1997 4:43:32-GMT,1025;000000000000 Return-Path: Received: from Xenon.Stanford.EDU (Xenon.Stanford.EDU [171.64.64.24]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id VAA06170 for ; Wed, 19 Mar 1997 21:43:31 -0700 (MST) Received: (from rokicki@localhost) by Xenon.Stanford.EDU (8.8.4/8.8.4) id UAA11684; Wed, 19 Mar 1997 20:45:32 -0800 (PST) Date: Wed, 19 Mar 1997 20:45:32 -0800 (PST) From: "Tomas G. Rokicki" Message-Id: <199703200445.UAA11684@Xenon.Stanford.EDU> To: oneill@cs.sfu.ca, rokicki@CS.Stanford.EDU Cc: tex-fonts@math.utah.edu Subject: Re: T1 encoding and font subsetting dont mix in dvips (fixed, kinda) Dear Melissa, Wow, thanks for the patch! I'm going to download it and check it out; I had not yet gotten around to figuring out what was going on, but I knew it was something pretty awful. I congratulate you for finding and fixing this problem. I hope to soon understand your patch and release a new version for the world. -tom 20-Mar-1997 18:46:15-GMT,59332;000000000000 Return-Path: Received: from cs.umb.edu (root@cs.umb.edu [158.121.104.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id LAA24906 for ; Thu, 20 Mar 1997 11:46:11 -0700 (MST) Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA05815 (5.65c/IDA-1.4.4 for tex-fonts@math.utah.edu); Thu, 20 Mar 1997 13:46:22 -0500 From: "K. Berry" Received: (from kb@localhost) by terminus.cs.umb.edu (8.8.0/8.8.0) id NAA12857; Thu, 20 Mar 1997 13:44:28 -0500 (EST) Date: Thu, 20 Mar 1997 13:44:28 -0500 (EST) Message-Id: <199703201844.NAA12857@terminus.cs.umb.edu> To: oneill@cs.sfu.ca Cc: rokicki@cs.stanford.edu, tex-fonts@math.utah.edu Subject: Re: T1 encoding and font subsetting dont mix in dvips (fixed, kinda) Further to my mailing, here's a fix for dvips... The problem I That second hunk looks like something I fixed in dvipsk earlier and didn't make it into dvips 5.70 for whatever reason. I sent the patch to Tom earlier. Here's my current t1part.c, FWIW. Melissa's first fix certainly looks applicable, and I guess the finclude thing as well. Why is it good to get rid of support for %%DocumentFonts, BTW? /* * T1part.c version 1.59 beta Copyright (C)1994, 1996 * by Sergey Lesenko * lesenko@mx.ihep.su * * It is distributed with no warranty of any kind. * You may modify and use this program. It can be included * in any distribution, commercial or otherwise, so long as * copyright notice be preserved on all copies. */ #include "dvips.h" #include "t1part.h" int LoadVector() ; int Afm() ; #ifdef BORLANDC void huge *UniGetMem(size) ub4 size ; { void huge *tmp; if ((tmp =(void huge*) farmalloc(size)) == NULL) { fprintf(stderr,"Error allocating far memory\n"); exit(1); } return tmp; } #else #define UniGetMem getmem #endif #ifdef WIN32 /* CHAR is typedef'd by -- popineau@esemetz.ese-metz.fr. */ #define CHAR CHARACTER #endif typedef struct Char { unsigned char *name; int length; int num; int choose; struct Char *NextChar; } CHAR; typedef struct String { unsigned char *name; int num; struct String *NextStr; } STRING; static STRING *FirstStr; static STRING *RevStr; static CHAR *FirstChar; static CHAR *FirstCharA; CHAR *FirstCharB; static CHAR *FirstCharW; int CharCount; int GridCount; int ind_ref; typedef struct { int num[4]; int select; } def_ref; def_ref refer[10]; #ifndef min #define min(a, b) ((a) < (b) ? (a) : (b)) #endif #ifndef max #define max(a, b) ((a) > (b) ? (a) : (b)) #endif #define PFA 1 #define PFB 2 #define NOTHING 0 #define FLG_ASCII 1 #define FLG_BINARY 2 #define FLG_EOF 3 #define FLG_ZERO_LINE 4 #define FLG_OUT_STR (-1) #define CHAR_NOT_DEF (-1) #define SEAC_NOT_END (-2) #define FLG_LOAD_BASE (1) #define STANDARD_ENC (1) #define SPECIAL_ENC (2) #define AFM_ENC (4) #define FLG_REENCODE (4) #define BYTES_PER_LINE 32 #ifndef KPATHSEA_TYPES_H #define TRUE 1 #define FALSE 0 #endif /* not KPATHSEA_TYPES_H */ #define LENIV 0 #define SUBRS 1 #define CHARSTRINGS 2 #define ERR_FIRST_NUM (-1) #define ERR_SECOND_NUM (-2) #define ERR_FIRST_TOK (-3) #define ERR_SECOND_TOK (-4) #define ERR_STACK (-5) #define ERR_NUM_CHAR (-6) #define ERR_NAME_CHAR (-7) #define SUBR_STR 1 #define CHAR_STR -1 #define CHAR_SEAC -2 #define SKIP_ON_DUP 3 #define C1 52845 #define C2 22719 #define EDR 55665 #define EER 55665 #define CDR 4330 #define MAX_ESCAPE 33 #define HSTEM 1 #define VSTEM 3 #define VMOVETO 4 #define CHARS_RLINETO 5 #define HLINETO 6 #define VLINETO 7 #define RRCURVETO 8 #define CHARS_CLOSEPATH 9 #define CALLSUBR 10 #define RETURN 11 #define ESCAPE 12 #define HSBW 13 #define ENDCHAR 14 #define CHARS_RMOVETO 21 #define HMOVETO 22 #define VHCURVETO 30 #define HVCURVETO 31 #define DOTSECTION 0 #define VSTEM3 1 #define HSTEM3 2 #define SEAC 6 #define SBW 7 #define CHARS_DIV 12 #define CALLOTHERSUBR 16 #define POP 17 #define SETCURRENTPOINT 33 typetemp _HUGE *temp; typetemp _HUGE *begin_of_scan; typetemp _HUGE *end_of_scan; unsigned char *line; unsigned char *tmpline; unsigned char token[64]; unsigned char notdef[]="/.notdef"; unsigned char grid[256]; unsigned char tmpgrid[256]; unsigned char psfontfile[500]; /* really should dynamically allocate */ unsigned char psvectfile[500]; unsigned char basevect[]="ad.enc"; unsigned char version[] = "v1.59 beta (c)1994, 1996"; unsigned char tmp_token[64]; /* static int j = 0; */ static int stack[128]; ub1 buf[BUFSIZ]; int loadbase = 0; static int encode; static int reencode; int find_encod; int lastpart=0; int keep_flg=0; int keep_num=0; int number; int offset; long value; int lenIV = 4; static int grow=0; static int level; static int flg_seac=0; typedef struct { char *command; int code; } tablecommand; tablecommand TableCommand[] = { {"callsubr", CALLSUBR}, {"callothersubr", CALLOTHERSUBR}, {"pop", POP }, {"seac", SEAC}, {""} }; typedef struct { char *extension; int num; } typefonts; typefonts TypeFonts[] = { {".pfa", PFA}, {".pfb", PFB}, {".PFA", PFA}, {".PFB", PFB}, {""} }; char Dup[]="dup"; typedef struct { typetemp _HUGE *begin; int length; int type; int offset; int oldnum; int newnum; } def_key; def_key keyword[6]; int FirstKey, current; int subrs, char_str; typedef struct { char *name; int num; } type_key; type_key Key[] = { {"/LenIV", LENIV}, {"/Subrs", SUBRS}, {"/CharStrings", CHARSTRINGS}, {""} }; struct def_label { typetemp _HUGE *begin; unsigned char skip; int length; short select; int num; }; struct def_label label[NUM_LABEL]; int DefTypeFont (name) unsigned char *name ; { int i; for(i=0;*TypeFonts[i].extension;i++) { if(strstr(name,TypeFonts[i].extension)!=0) return(TypeFonts[i].num); } return -1; } int GetZeroLine (str) unsigned char *str ; { int token_type=0; if(*str!='0') { return (token_type=0); } while(*str=='0') { str++; } if(*str=='\n' || *str=='\r') token_type= -1; else token_type=0; return(token_type); } /* We get token type and its content for ASCII code */ int GetWord (mem) unsigned char *mem ; { int token_type=0; register unsigned char *tmp; tmp=mem; *tmp= *line; while((*line!='\0')&&(*line!='%')) { if(*line=='-') { *tmp++= *line++; } if(isdigit(*line)) { while(isdigit(*line)) { *tmp++= *line++; } *tmp = '\0'; return 5; } if(*line=='/') { *tmp++= *line++; token_type=1; } if(*line=='.') { *tmp++= *line++; if(token_type==1) { if(*line==' ') { *tmp = '\0'; return(token_type=token_type+2); } } } if(isalpha(*line)) { while(!isspace(*line)) *tmp++= *line++; *tmp = '\0'; return(token_type=token_type+2); } token_type=0; tmp=mem; line++; } return(token_type= -1); } /* We get token type and its content for BINARY code */ int GetToken() { register unsigned char *tmp; int token_type=0; tmp=token; *tmp= *temp; while(tempname = getmem(length+1); strcpy(ThisChar->name, CharName); ThisChar->length= length; ThisChar->num=num; ThisChar->NextChar = TmpChar; TmpChar = ThisChar; return TmpChar; } void AddStr(name, num) unsigned char *name ; int num ; { int length; STRING *ThisStr = getmem(sizeof(STRING)); length = strlen(name); ThisStr->name = getmem(length+1); strcpy(ThisStr->name, name); ThisStr->num=num; ThisStr->NextStr = FirstStr; FirstStr = ThisStr; } /* We prepare own encoding vector for output */ void RevChar(TmpChar) CHAR *TmpChar; { int i; CHAR *ThisChar = TmpChar; while (ThisChar != NULL) { for(i=keyword[char_str].offset-1; i < number; i++) { if(ThisChar->num == label[i].num) { if (label[i].select==FLG_BINARY) { CHAR *Rev_Char = getmem(sizeof(CHAR)); Rev_Char->name = ThisChar->name; Rev_Char->num = ThisChar->num; Rev_Char->NextChar = FirstCharW; FirstCharW = Rev_Char; break; } } } ThisChar = ThisChar->NextChar; } } /* And here we produce own resulting encoding vector for partial font */ void OutChar (TmpChar, fout) CHAR *TmpChar ; FILE *fout ; { CHAR *ThisChar = TmpChar; while (ThisChar != NULL) { CHAR *tm = ThisChar; fprintf(fout, "dup %d %s put\n",ThisChar->num,ThisChar->name); ThisChar = ThisChar->NextChar; free(tm); } FirstCharW = NULL; } /* We prepare strings list for output */ void Reverse(TmpStr) STRING *TmpStr; { int tmp; if(encode==AFM_ENC) tmp = -2; else tmp=0; while (TmpStr != NULL) { if(TmpStr->num < tmp) { STRING *ThisStr = getmem(sizeof(STRING)); ThisStr->name = TmpStr->name; ThisStr->NextStr = RevStr; RevStr = ThisStr; } TmpStr = TmpStr->NextStr; } } /* And here we post strings to out */ void OutStr (TmpStr, fout) STRING *TmpStr ; FILE *fout ; { STRING *ThisStr = TmpStr; if(encode==AFM_ENC) fprintf(fout, "readonly def\n"); while (ThisStr != NULL) { STRING *tm = ThisStr; fprintf(fout, "%s",ThisStr->name); ThisStr = ThisStr->NextStr; free(tm); } RevStr = NULL; } void PrintChar(TmpChar) CHAR *TmpChar; { CHAR *ThisChar = TmpChar; while (ThisChar != NULL) { if(ThisChar->choose==1) { fprintf(stderr, " Debug: Char %d '%s'\n", ThisChar->num,ThisChar->name); } ThisChar = ThisChar->NextChar; } } int ClearB() { CHAR *ThisChar = FirstCharB; while (ThisChar != NULL) { ThisChar->choose=0; ThisChar = ThisChar->NextChar; } return 1; } /* We mark chars in encoding vector thanks same names from reencoding vector */ int ChooseChar (name, TmpChar) unsigned char *name ; CHAR *TmpChar ; { int length; CHAR *ThisChar = TmpChar; length=strlen(name); while (ThisChar != NULL) { /* since ClearCW may free ThisChar, follow the pointer now. */ CHAR *NextChar = ThisChar->NextChar; if(ThisChar->length==length) { if (strcmp(name, ThisChar->name) == 0) { ThisChar->choose=1; return 1; } } ThisChar = NextChar; } return -1; } /* We find index in label array for char, wich is required for compose char, if it uses SEAC command */ int FindSeac (num) int num ; { int i; for(i=keyword[char_str].offset-1; i < number; i++) { if(label[i].num==num) { return i; } } return -1; } void ClearCW(); int FindCharW(name, length) unsigned char *name ; int length ; { CHAR *ThisChar = FirstCharW; int find = 0; int keep_char = 0; int tmp = 0; int tmp_num = 0; int ddd = 0; #ifdef DEBUG if(dd(D_VIEW_VECTOR)) { ddd = 1; } #endif while (ThisChar != NULL) { /* since ClearCW may free ThisChar, follow the pointer now. */ CHAR *NextChar = ThisChar->NextChar; if(ThisChar->length==length) { if (strcmp(name, ThisChar->name) == 0) { if(ThisChar->choose==1) { if(find !=2) { find = 2; tmp=FLG_BINARY; label[number].num=ThisChar->num; } } else { keep_char = 0; if(find != 2) { find = 1; tmp_num = ThisChar->num; } } if(keep_char == 0) { ClearCW(ThisChar); } if((find == 2)&&(ddd == 1)) keep_char = 1; } } ThisChar = NextChar; } if(find == 1) { tmp=NOTHING; label[number].num=tmp_num; } return tmp; } void ClearCW (ThisChar) CHAR *ThisChar; { if (ThisChar == FirstCharW) FirstCharW = ThisChar->NextChar; else { CHAR *tm = FirstCharW; while (tm != NULL) { if (ThisChar == tm->NextChar) { tm->NextChar = ThisChar->NextChar; break; } tm = tm->NextChar; } } free(ThisChar); } /* We build temporary 'work' encoding vector only for searching needed chars */ int WorkVect (TmpChar) CHAR *TmpChar ; { while (TmpChar != NULL) { { CHAR *ThisChar = getmem(sizeof(CHAR)); ThisChar->name = TmpChar->name; ThisChar->length = TmpChar->length; ThisChar->num = TmpChar->num; ThisChar->choose = TmpChar->choose; ThisChar->NextChar = FirstCharW; FirstCharW = ThisChar; } TmpChar = TmpChar->NextChar; } return 0; } void UnDefineCharsW() { CHAR *ThisChar = FirstCharW; while (ThisChar != NULL) { CHAR *tm = ThisChar; ThisChar = ThisChar->NextChar; free(tm); } FirstCharW = NULL; CharCount = 0; } CHAR * UnDefineChars(TmpChar) CHAR *TmpChar; { CHAR *ThisChar = TmpChar; while (ThisChar != NULL) { CHAR *tm = ThisChar; free(ThisChar->name); ThisChar = ThisChar->NextChar; free(tm); } TmpChar = NULL; CharCount = 0; return TmpChar; } void UnDefineStr() { STRING *ThisStr = FirstStr; while (ThisStr != NULL) { STRING *tm = ThisStr; free(ThisStr->name); ThisStr = ThisStr->NextStr; free(tm); } FirstStr = NULL; } /* */ /* We mark subroutines without charstring decrypting */ /* */ void ScanSubrs(i) int i ; { int err_num; int word_type = 0; int len_dup; int num_err=0; int test=0; len_dup = strlen(Dup); for( ; number < keyword[i].oldnum + keyword[i].offset;) { if((word_type=GetToken())>0) { if(word_type==2) { if(!strcmp(token,Dup)) { if(test==0) test=1; label[number].begin = temp-len_dup; err_num=GetNum(); if(err_num<0) ; else { if(err_num<4) { label[number].select=FLG_BINARY; keyword[i].newnum++; } } label[number].num=err_num; num_err=PassString(1); if(num_err<0) { ErrorOfScan(num_err); fprintf(stderr,"in %d Subr string", number - 1); exit(1); } if(test>1) PassToken(); number++; } else { if(test>=1) test++; } } } else { ErrorOfScan(0); fprintf(stderr, "Token 'def' not found in %d Subr string ", number - 1); exit(1); } } } void ViewReturnCall(num_err, top, pstack, j, depth) int num_err ; int top ; int *pstack ; int j ; int depth ; { int k,m; #ifdef DEBUG if((dd(D_CALL_SUBR))&&(num_err>0)) { if(grow==1) { grow=0; fprintf(stderr, "\n Top: "); } else fprintf(stderr, " Back: "); } #endif if(num_err<0) { if(grow==1) { grow=0; fprintf(stderr, "\n ERROR: "); ErrorOfScan(num_err); } else fprintf(stderr, " Back: "); } fprintf(stderr, " %d Subr \n", top); fprintf(stderr," %dth level> STACK: ", level); for(m=0; m < j; m++, pstack++) { if(depth>(j-(m+1))) { for(k=0; TableCommand[k].command; k++) { if(TableCommand[k].code==*pstack) { fprintf(stderr," %s", TableCommand[k].command); k=0; break; } } if(k!=0) fprintf(stderr," (%d)", *pstack); } else fprintf(stderr, " %d", *pstack); } fprintf(stderr, " \n"); } /* */ /* We decrypt charstring with recursive descent */ /* */ int DeCodeStr (num, numseac) int num ; int numseac ; { unsigned int loccr; unsigned char byte; static int j ; int i; unsigned char jj,k; int tmpnum; int depth = 0; int num_err = 0; int len_str; typetemp _HUGE *loc; typetemp _HUGE *end_str; int pstack[64]; int last_subr; if(num > CHAR_STR) { last_subr=keyword[subrs].offset+keyword[subrs].oldnum; for(tmpnum=keyword[subrs].offset; tmpnum keyword[subrs].newnum ) /* max num of subr */ keyword[subrs].newnum = num+1; } loc = label[tmpnum].begin + label[tmpnum].skip; len_str=label[tmpnum].length; } else { j=0; if(num == CHAR_SEAC) { if(label[numseac].select!=FLG_BINARY) { label[numseac].select=FLG_BINARY; keyword[char_str].newnum++; temp = label[numseac].begin; } else return 1; } len_str=GetNum(); if(len_str < 0) { return ERR_SECOND_NUM; } num_err = PassToken(); if(num_err < 0) { return ERR_FIRST_TOK; } loc=temp; } loc++; end_str=loc+len_str; loccr = CDR; for (i = 0; i < lenIV; i++,loc++) { byte = CDeCrypt(*loc, &loccr); } for (; loc < end_str;) { byte = CDeCrypt(*loc++, &loccr); if (byte == RETURN) { j=0; break; } else if (byte == ESCAPE) { byte = CDeCrypt(*loc++, &loccr); if (byte > MAX_ESCAPE) fprintf(stderr, "Error: not_defined_e%d in %s", byte, psfontfile); else { switch(byte) { case DOTSECTION : j=0; break; case VSTEM3 : j=0; break; case HSTEM3 : j=0; break; case SEAC : stack[j++]=byte; grow=1; level++; jj=j; for(k=0;k -3) label[number].select=SEAC_NOT_END; grow=0; level=0; j=0; break; } num_err=DeCodeStr(CHAR_SEAC, num_err); level--; #ifdef DEBUG if((num_err<0)||(dd(D_CALL_SUBR))) #else if(num_err<0) #endif ViewReturnCall (num_err, pstack[jj-3],pstack,jj,1); grow=1; level++; num_err=FindSeac(pstack[jj-2]); if(num_err<0) { flg_seac=1; CharCount++; keyword[char_str].newnum--; keyword[char_str].newnum--; if(flg_seac > -3) label[number].select=SEAC_NOT_END; grow=0; level=0; j=0; break; } num_err=DeCodeStr(CHAR_SEAC, num_err); level--; #ifdef DEBUG if((num_err<0)||(dd(D_CALL_SUBR))) #else if(num_err<0) #endif ViewReturnCall (num_err, pstack[jj-2],pstack,jj,1); if(num_err<0) return ERR_STACK; j=0; break; case SBW : j=0; break; case CHARS_DIV : j=0; break; case CALLOTHERSUBR : stack[j++]=byte; depth=depth+2; break; case POP : stack[j++]=byte; depth=depth+2; break; case SETCURRENTPOINT : j=0; break; } } continue; } else if (byte < 32) { switch(byte) { case HSTEM : j=0; break; case VSTEM : j=0; break; case VMOVETO : j=0; break; case CHARS_RLINETO : j=0; break; case HLINETO : j=0; break; case VLINETO : j=0; break; case RRCURVETO : j=0; break; case CHARS_CLOSEPATH : j=0; break; case CALLSUBR : stack[j++]=byte; depth=depth+2; level++; grow=1; jj=j; j=j-depth; for(k=0;k= 32) { if (byte <= 246) { value= byte - 139; stack[j++]=value; } else if ((byte >= 247) && (byte <= 250)) { value= (byte - 247) * 256 + CDeCrypt(*loc++, &loccr) + 108; stack[j++]=value; } else if ((byte >= 251) && (byte <= 254)) { value= -(byte - 251) * 256 - CDeCrypt(*loc++, &loccr) - 108; stack[j++]=value; } else if (byte == 255) { value = CDeCrypt(*loc++, &loccr); value <<= 8; value += CDeCrypt(*loc++, &loccr); value <<= 8; value += CDeCrypt(*loc++, &loccr); value <<= 8; value += CDeCrypt(*loc++, &loccr); stack[j++]=value; } } } if(num == CHAR_STR) { temp=loc; num_err = PassToken(); if(num_err<0) { return ERR_SECOND_TOK; } } return 1; } /* */ /* We mark only necessary charstring */ /* */ void ScanChars(i) int i; { int word_type=0; int found; int str_len; int max_num; int counter; int num_err = 0; typetemp _HUGE *tmptemp; CharCount++; counter=number; max_num = keyword[i].offset+keyword[i].oldnum; while( number < max_num ) { if((word_type=GetToken())>0) { if(word_type>=3) { strcpy(tmp_token, token); str_len = strlen(token); if(CharCount!=0) { num_err=FindCharW(token, str_len); if(num_err==FLG_BINARY) { CharCount--; found=num_err; keyword[i].newnum++; } else { #ifdef DEBUG if(dd(D_VIEW_VECTOR)&&(num_err==-1)) { fprintf(stderr, " Debug: Char '%s' not used in WorkVector\n", token); } #endif if(word_type>3) { if(strstr(token, notdef)!=NULL) { CharCount--; label[number].num = -2; found=FLG_BINARY; keyword[i].newnum++; } else found=NOTHING; } else found=NOTHING; } } else { found=NOTHING; } label[number].begin = temp-str_len; label[number].select = found; switch(found) { case FLG_BINARY: tmptemp=temp; for(subrs=FirstKey; subrs0) fprintf(stderr, " Debug for Char '%s'\n", tmp_token); } #endif break; case NOTHING: num_err=PassString(0); break; } if(num_err<0) { ErrorOfScan(num_err); fprintf(stderr,"in Char string of '%s'", tmp_token); exit(1); } number++; } } else { fprintf(stderr, "\n File <%s> ended before all chars have been found.", psfontfile); fprintf(stderr, "\n We scan %d Chars from %d", counter - (2 + keyword[subrs].oldnum), keyword[i].oldnum); if(tmp_token!=NULL) { fprintf(stderr, "\n Last seen token was '%s'\n", tmp_token); } exit(1); } } if(flg_seac!=0) { tmptemp=temp; flg_seac--; for(; counter0) { if(word_type==3) { for(i=First_Key; i<=lastkey; i++) { if(!strcmp(token, Key[i].name)) { tmp_num = GetNum(); if(tmp_num<0) { fprintf(stderr, "\n ERROR: Number not found for '%s' in <%s>", Key[i].name, psfontfile); exit(1); } keyword[current].oldnum = tmp_num; keyword[current].length=strlen(token); keyword[current].begin=temp - keyword[current].length; return i; } } } } else { fprintf(stderr, "\n ERROR: In <%s> keyword not found:", psfontfile); for(i=First_Key; i<=lastkey; i++) fprintf(stderr,"\n %dth > '%s' ",i,Key[i].name); exit(1); } } } /* To increase scan speed we use dynamic range of keywords */ int ScanBinary() { int i; int firstnum, lastnum; firstnum= LENIV; lastnum=SUBRS; number=0; label[number].begin = begin_of_scan; temp = label[number].begin; label[number].select = FLG_BINARY; offset= ++number; for (current=0, FirstKey=current ; ; current++) { i=FindKeyWord(firstnum,lastnum); switch(i) { case LENIV: FirstKey++; firstnum=SUBRS; lastnum=SUBRS; lenIV=keyword[current].oldnum; keyword[current].type=Key[0].num; break; case SUBRS: firstnum=SUBRS; lastnum= CHARSTRINGS; keyword[current].offset=number; keyword[current].newnum=0; keyword[current].type=Key[1].num; ScanSubrs(current); LastLook(); break; case CHARSTRINGS: char_str=current; keyword[current].offset=number; keyword[current].newnum=0; keyword[current].type=Key[2].num; ScanChars(current); LastLook(); #ifdef DEBUG if(dd(D_CALL_SUBR)) { for(i=0;i<=2;i++) { if(keyword[i].oldnum!=0) fprintf(stderr, " Result for <%s>: %s %d (instead %d) \n", psfontfile, Key[keyword[i].type].name,keyword[i].newnum, keyword[i].oldnum); } } #endif return 1; } } } unsigned char *itoasp (n, s, len) int n ; unsigned char *s ; int len ; { static int i, j; j++; if(n/10) itoasp(n/10,s,len); else i=0; s[i++]=abs(n)%10+'0'; j--; if(j==0) { for(; i> 8)); *lcdr = (cipher + *lcdr) * c1 + c2; return plain; } unsigned short int eer; /* We find end of own vector with non StandardEncoding, */ int EndOfEncoding (err_num) int err_num; { int j; int i = 0; int flg_get_word=0; static char *RefKey[] = { "readonly", "getinterval", "exch", "" }; for(;;) { if(flg_get_word==0) flg_get_word = 1; else { err_num=GetWord(token); } if(err_num <= 0) return -1; if(err_num==5) refer[ind_ref].num[i++]=atoi(token); else { for(j=0; *RefKey[j]; j++) { if(strcmp(token, RefKey[j]) ==0) break; } switch(j) { case 0: find_encod=1; keep_num = -2; if(ind_ref!=0) { CorrectGrid(); } return 1; case 1: break; case 2: if(i==1) { refer[ind_ref].num[1] = 1; refer[ind_ref].num[2] = refer[ind_ref].num[0]; GetWord(token); refer[ind_ref].num[0]= atoi(token); } i=0; refer[ind_ref].select=1; ind_ref++; break; default: break; } } } } /* We rebuild grid for case "dup dup 161 10 getinterval 0 exch putinterval dup dup 173 23 getinterval 10 exch putinterval dup dup 127 exch 196 get put readonly def" in non StandardEncoding */ void CorrectGrid() { int i, j, k, imax; for(j=0; j<=ind_ref; j++){ if(refer[j].select==1){ imax= refer[j].num[1] + refer[j].num[2]; for(k=0, i=refer[j].num[2]; i< imax; k++,i++){ if(grid[i]==1){ grid[i]=0; grid[k+refer[j].num[0]]=1; } } } } } /* We build vector for non StandardEncoding */ int CharEncoding() { int err_token=0; int num=0; err_token=GetWord(token); if(err_token==2) { if(strcmp(token, Dup) ==0) { err_token=GetWord(token); if(err_token<0) return ERR_NUM_CHAR; if(err_token!=2) /* define "dup word" */ { num=atoi(token); err_token=GetWord(token); if(err_token<0) { return ERR_NAME_CHAR; } FirstChar=AddChar(FirstChar,token, num); keep_num=num; keep_flg=1; return 1; } } if(keep_flg==1) { keep_num=FLG_OUT_STR; if(EndOfEncoding(err_token)<0) { return -1; } } } return 0; } void FindEncoding() { int num_err=0; int tmpnum; line=tmpline; if(encode==0) { while((num_err=GetWord(token))>=0) { if(num_err==3) { if (strcmp(token,"/Encoding") == 0) { tmpnum=GetWord(token); if(tmpnum==5) { encode=SPECIAL_ENC; } else { find_encod=1; encode=STANDARD_ENC; } return; } } } } else { num_err= CharEncoding(); if(num_err<0) { ErrorOfScan(num_err); fprintf(stderr, "\n ERROR in encoding vector in <%s>", psfontfile); exit(1); } } } /* Before parse in BINARY portion of font we should mark needed chars, reencode them if there is reencoding vector for this case and build work vector */ void CheckChoosing() { CHAR *TmpChar; int err_num, i; if(encode==STANDARD_ENC) { TmpChar = FirstCharB; } else { if(encode==SPECIAL_ENC) { TmpChar = FirstChar; } else { fprintf(stderr, "WARNING: '/Encoding' not found in <%s>\n", psfontfile); exit(1); } } if(reencode==FLG_REENCODE) err_num=LoadVector(reencode, TmpChar); else err_num=ChooseVect(TmpChar); if(err_num<0) { Afm(); encode=AFM_ENC; TmpChar = FirstCharA; for(i=0;i<=255;i++) grid[i]=tmpgrid[i]; if(reencode==FLG_REENCODE) err_num=LoadVector(reencode, TmpChar); else err_num=ChooseVect(TmpChar); if(err_num<0) { fprintf(stderr, "\n Warning: after loading AFM file \n"); fprintf(stderr, " only %d chars found instead %d for <%s>\n", CharCount, GridCount, psfontfile); } } WorkVect(TmpChar); #ifdef DEBUG if(dd(D_VIEW_VECTOR)) { fprintf(stderr, "\n"); if(encode==1) fprintf(stderr, " Encoding: standard \n"); else fprintf(stderr, " Encoding: not standard \n"); if(reencode==FLG_REENCODE) fprintf(stderr, " with reencode vector <%s>\n", psvectfile); PrintChar(FirstCharW); } #endif } void OutASCII(fout, buff, len) FILE *fout ; ub1 *buff ; ub4 len ; { ub4 i; for (i = 0; i < len; i++) { if ((*buff == 10)||(*buff == 13)) { buff++; *line++='\n'; *line='\0'; if((find_encod==0)&&(lastpart==0)) { FindEncoding(); } line=tmpline; if(keep_flg==0) fprintf(fout,"%s", line); else { if(keep_num<0) { AddStr(line,keep_num); if(keep_num==-2) keep_num = -3; } } } else { *line++ = *buff++; } } } /* It's eexec decription for PFB format */ void BinEDeCrypt(buff, len) ub1 *buff ; ub4 len ; { ub4 i; for (i = 0; i < len; i++, temp++, buff++) { *temp = (*buff ^ (edr >> 8)); edr = (*buff + edr) * c1 + c2; } } /* And it's eexec decription for PFA format */ void HexEDeCrypt(mem) unsigned char *mem ; { int ch1, ch2, cipher; for(;*mem!='\n' && *mem!='\r'; temp++) { ch1= *mem++; ch2= *mem++; if ('A' <= ch1 && ch1 <= 'F') ch1 -= 'A' - 10; else if ('a' <= ch1 && ch1 <= 'f') ch1 -= 'a' - 10; else ch1 -= '0'; ch1<<=4; if ('A' <= ch2 && ch2 <= 'F') ch2 -= 'A' - 10; else if ('a' <= ch2 && ch2 <= 'f') ch2 -= 'a' - 10; else ch2 -= '0'; cipher = ch1 + ch2; *temp = (cipher ^ (edr >> 8)); edr = (cipher + edr) * c1 + c2; } } int PartialPFA(fin, fout) FILE *fin ; FILE *fout ; { ub1 type; ub4 memory, addmemory, length, add_of_len; unsigned char *mem = tmpline; int check_vect=0; tmpline=buf; edr = EDR; type = FLG_ASCII; memory = BASE_MEM; addmemory= ADD_MEM; length=0; temp=UniGetMem(memory); begin_of_scan=temp; for(;;) { if(fgets(buf,BUFSIZ,fin)==NULL) break; switch (type) { case FLG_ASCII: if(strstr(buf,"currentfile eexec") != NULL) { type=FLG_BINARY; } if((find_encod==0)&&(lastpart==0)) { FindEncoding(); } if(keep_flg==0) fprintf(fout,"%s", buf); else { AddStr(buf,keep_num); } break; case FLG_BINARY: if(check_vect==0) { tmpline=mem; CheckChoosing(); check_vect=1; } if(GetZeroLine(buf)<0) { type = FLG_ZERO_LINE; end_of_scan=temp; ScanBinary(); SubstNum(); if(keep_flg==1) { keep_flg=0; lastpart=1; if(encode!=1) { UnDefineCharsW(); if(encode==4) RevChar(FirstCharA); else RevChar(FirstChar); OutChar(FirstCharW, fout); } Reverse(FirstStr); OutStr(RevStr, fout); } OutHEX(fout); UniFree(begin_of_scan); fprintf(fout, "%s", buf); break; } add_of_len=strlen(buf)/2; length=length + add_of_len; if(length>memory) { memory = memory + addmemory; /* Using "memory = length;" retains minimum */ /* of memory but it will be more slowly */ begin_of_scan = UniRealloc(begin_of_scan, memory); temp = begin_of_scan + length - add_of_len; } HexEDeCrypt(buf); break; case FLG_ZERO_LINE: fprintf(fout, "%s", buf); break; } } if(type == FLG_ZERO_LINE) return TRUE; else return FALSE; } int PartialPFB (fin, fout) FILE *fin ; FILE *fout ; { ub1 type; ub4 length, nread; int nbytes, rc; int check_vect = 0; line=tmpline; edr = EDR; for (;;) { if ((rc = fread((char *) buf, 1, 6, fin)) < 2) { return FALSE; } if (buf[0] != 128) return FALSE; type = buf[1]; if (type == FLG_EOF) { return TRUE; } if (rc != 6) return FALSE; length = little4(&buf[2]); if(type==FLG_BINARY) { temp=UniGetMem(length); begin_of_scan=temp; } for (nread = 0; nread < length; nread += rc) { nbytes = min(BUFSIZ, length - nread); if ((rc = fread((char *) buf, 1, nbytes, fin))==0) { return FALSE; } switch (type) { case FLG_ASCII: OutASCII(fout, buf, (ub4) rc); break; case FLG_BINARY: if(check_vect==0) { CheckChoosing(); check_vect=1; } BinEDeCrypt(buf, (ub4) rc); break; default: return FALSE; } } if(type == FLG_BINARY) { end_of_scan=temp; ScanBinary(); SubstNum(); if(keep_flg==1) { keep_flg=0; lastpart=1; if(encode!=1) { UnDefineCharsW(); if(encode==4) RevChar(FirstCharA); else RevChar(FirstChar); OutChar(FirstCharW, fout); } Reverse(FirstStr); OutStr(RevStr, fout); } OutHEX(fout); UniFree(begin_of_scan); } } } void OutHEX (fout) FILE *fout ; { int i=0; int num; static char *hexstr = "0123456789abcdef" ; int bin; line=tmpline; eer = EER; label[number].begin = end_of_scan; label[number].select = NOTHING; number++; for(num=0; num < number; num++) { switch(label[num].select) { case NOTHING: break; case FLG_BINARY: label[num].select=NOTHING; for(temp=label[num].begin; temp> 8)); /* Eexec encryption */ eer = ((bin + eer) * c1 + c2); *line++= hexstr[(bin&0xf0)>>4]; *line++= hexstr[bin&0xf]; if (!((i + 1) % BYTES_PER_LINE)) { *line++='\0'; line =tmpline; fprintf(fout, "%s\n",line); } } break; } } if (i % BYTES_PER_LINE) { *line++='\0'; line =tmpline; fprintf(fout, "%s\n",line); } } /* We parse AFM file only if we've received errors after parsing of own vector */ int Afm() { unsigned char afmfile[100]; FILE *fafm; int err_num=0; int i,j,k,num=0; unsigned char name[40]; static char *AfmKey[] = { "StartCharMetrics", "EndCharMetrics", "" }; static char *InfoKey[] = { "C", "N", "" }; for(i=0; psfontfile[i] ; i++) { if(psfontfile[i] == '.') break; else afmfile[i]=psfontfile[i]; } afmfile[i]='\0'; strcat(afmfile,".afm"); fprintf(stderr, "<%s>", afmfile); if ((fafm = psfopen(afmfile, "r")) == NULL) { NameOfProgram(); perror(afmfile); return -1; } for(j=0;;) { line = tmpline; if(fgets(line,BUFSIZ,fafm)==NULL) break; if(strstr(line, AfmKey[j])!=NULL) { if(j==0) { j++; continue; } else { fclose(fafm); return 1; } } if(j==1) { for(k=0; err_num>=0; ) { err_num=GetWord(token); if(err_num==2) { if(strcmp(token,InfoKey[k])==0) { if(k==0) { err_num=GetWord(token); num=atoi(token); k=1; continue; } else { err_num=GetWord(token); name[0]='/'; name[1]='\0'; strcat(name,token); if(num>=0) FirstCharA=AddChar(FirstCharA, name, num); break; } } } } } } return -2; } int FontPart(fout, fontfile, vectfile ) FILE *fout; unsigned char *fontfile; unsigned char *vectfile; { FILE *fin=0; int num; int rc; int i; ind_ref=0; reencode=0; encode=0; lastpart=0; keep_flg=0; flg_seac=0; strcpy(psfontfile,fontfile); find_encod=0; CharCount=0; if(loadbase != 1) { for(i=offset; i < NUM_LABEL; i++) label[i].num=CHAR_NOT_DEF; strcpy(psvectfile, basevect); #ifdef DEBUG if(dd(D_VIEW_VECTOR)) fprintf(stderr, " Base vector <%s>.", basevect); #endif if(LoadVector(1, FirstCharB)==1) { loadbase = FLG_LOAD_BASE; } else exit(1); } if(vectfile) { reencode=FLG_REENCODE; strcpy(psvectfile,vectfile); } for(num=0;num 0) CharCount++; else { fprintf(stderr, "Error: '%s' not found in reencoding vector <%s> for <%s>\n", token,psvectfile, psfontfile); } } index_grid++; } else { if(num==1) /* Build base vector */ { FirstCharB=AddChar(FirstCharB,token, CharCount); CharCount++; } } continue; } if(j== -1) break; if(j==2) { i=0; end_vect = 1; break; } } } if(j==2) { if((index_grid!=256)&&(CharCount!=256)) { fclose(fvect); fprintf(stderr,"Error during Load Vector in <%s> \n", psvectfile); fprintf(stderr, "Found %d chars instead 256\n", max(index_grid,CharCount)); return -3; } if(CharCount>0) { fclose(fvect); return 1; } else { fclose(fvect); fprintf(stderr, "\n Warning: Vector from <%s> for <%s> doesn't load\n", psvectfile, psfontfile); return -1; } } else { fprintf(stderr,"\n Error: ending token 'def' not found in <%s> \n", psvectfile); return -2; } } int ChooseVect (tmpChar) CHAR * tmpChar ; { CHAR *ThisChar = tmpChar; CharCount=0; while (ThisChar != NULL) { ThisChar->choose= grid[ThisChar->num]; if(grid[ThisChar->num]==1) { CharCount++; } ThisChar = ThisChar->NextChar; } if(CharCount Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id MAA26437 for ; Thu, 20 Mar 1997 12:40:56 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id LAA14332; Thu, 20 Mar 1997 11:40:49 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id LAA00521; Thu, 20 Mar 1997 11:40:47 -0800 (PST) Message-Id: <199703201940.LAA00521@alonzo.cs.sfu.ca> Subject: Re: T1 encoding and font subsetting dont mix in dvips (fixed, kinda) To: kb@cs.umb.edu (K. Berry) Date: Thu, 20 Mar 1997 11:40:47 -0800 (PST) Cc: rokicki@cs.stanford.edu, tex-fonts@math.utah.edu In-Reply-To: <199703201844.NAA12857@terminus.cs.umb.edu> from "K. Berry" at Mar 20, 97 01:44:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Karl writes > Here's my current t1part.c, FWIW. Thanks! And then asks: > Melissa's first fix certainly looks applicable, and I guess the finclude > thing as well. Why is it good to get rid of support for %%DocumentFonts, > BTW? Maybe my patch was too harsh a hack, but while it is right for DVIPS to scan EPS files to find what fonts they use so that those fonts can be included on the output file's ``%%DocumentFonts:'' line, in another regard dvips was treated ``%%DocumentFonts:'' as if it were ``%%DocumentNeededFonts:'', and adding the font to the list of fonts that should eventually be included by DVIPS. Quoting from page 662 of the `red book', Note that %%DocumentFonts: should be the union of %%DocumentNeededFonts: and %%DocumentSuppliedFonts: Thus, if you have an EPS file which uses, say, Utopia, and Utopia (or a subset) is included in the EPS file, we find that suddenly dvips is adding an extra copy of Utopia in the final output which wasn't needed. If dvips wants to include fonts that an EPS file needs but doesn't supply, it should either scan for ``%%DocumentNeededFonts:'' or ``%%IncludeFont:'' in the EPS file (and the similar generalized comments for resources). Hope this makes things clearer, Melissa. 20-Mar-1997 19:59:17-GMT,2470;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id MAA26919 for ; Thu, 20 Mar 1997 12:59:16 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id LAA15360; Thu, 20 Mar 1997 11:59:14 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id LAA00555; Thu, 20 Mar 1997 11:59:12 -0800 (PST) Message-Id: <199703201959.LAA00555@alonzo.cs.sfu.ca> Subject: Revised patch, for Karl's t1part.c To: kb@cs.umb.edu (K. Berry) Date: Thu, 20 Mar 1997 11:59:11 -0800 (PST) Cc: rokicki@cs.stanford.edu, tex-fonts@math.utah.edu In-Reply-To: <199703201844.NAA12857@terminus.cs.umb.edu> from "K. Berry" at Mar 20, 97 01:44:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In e-mail, you tell me: > That second hunk looks like something I fixed in dvipsk earlier and > didn't make it into dvips 5.70 for whatever reason. I sent the patch to > Tom earlier. I don't think the second hunk matches with whatever it was that you fixed. However, my patch does winds up misplaced, given your changes to ChooseChar, this time I've enclosed a patch for Karls's t1part.c with enough context that it hopefully can't misplace itself. Best Regards, Melissa. Enc. --- t1part.c.orig Thu Mar 20 11:44:20 1997 +++ t1part.c Thu Mar 20 11:52:28 1997 @@ -570,11 +570,13 @@ CHAR *ThisChar = TmpChar; while (ThisChar != NULL) { CHAR *tm = ThisChar; - fprintf(fout, "dup %d %s put\n",ThisChar->num,ThisChar->name); + if (ThisChar->num > 0) { + fprintf(fout, "dup %d %s put\n", ThisChar->num, ThisChar->name); + } ThisChar = ThisChar->NextChar; free(tm); } FirstCharW = NULL; @@ -686,10 +688,22 @@ { ThisChar->choose=1; return 1; } } + if (NextChar == NULL) { + CHAR *NewChar = getmem(sizeof(CHAR)); + + NewChar->name = getmem(length + 1); + strcpy(NewChar->name, name); + NewChar->length = length; + NewChar->num = -1; + NewChar->NextChar = NULL; + NewChar->choose = 1; + ThisChar->NextChar = NewChar; + return 1; + } ThisChar = NextChar; } return -1; } 21-Mar-1997 21:30:29-GMT,1957;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id OAA17121 for ; Fri, 21 Mar 1997 14:30:29 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id NAA18603 for ; Fri, 21 Mar 1997 13:30:26 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id NAA10387 for tex-fonts@math.utah.edu; Fri, 21 Mar 1997 13:30:24 -0800 (PST) Message-Id: <199703212130.NAA10387@alonzo.cs.sfu.ca> Subject: Nonsense map files in psfonts/urw on CTAN To: tex-fonts@math.utah.edu Date: Fri, 21 Mar 1997 13:30:24 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Has anyone actually looked at the map currently given for URW Antiqua and Nimbus on CTAN? To me, it looks like some software that was supposed to auto-generate them broke, for example for Nimbus we have two files in the dvips directory, unm.map and unms.map, the former being empty and the latter containing the line: unm*8r* NimbusRomanNo9L-Regular "TeXBase1Encoding ReEncodeFont" <8r.enc Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id OAA17578 for ; Fri, 21 Mar 1997 14:52:47 -0700 (MST) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id NAA20117 for ; Fri, 21 Mar 1997 13:52:45 -0800 (PST) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id NAA10409 for tex-fonts@math.utah.edu; Fri, 21 Mar 1997 13:52:43 -0800 (PST) Message-Id: <199703212152.NAA10409@alonzo.cs.sfu.ca> Subject: More map-file strangeness... To: tex-fonts@math.utah.edu Date: Fri, 21 Mar 1997 13:52:42 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I also notice that ptm.map contains entries for psyr, psyro and pzcmi8r which really have no business being there. Melissa. 24-Mar-1997 9:17:51-GMT,1514;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA02831 for ; Mon, 24 Mar 1997 02:17:50 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA14757 for ; Mon, 24 Mar 1997 09:15:31 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 24 Mar 1997 09:18:11 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA02625; Mon, 24 Mar 1997 09:18:05 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id JAA05399; Mon, 24 Mar 1997 09:18:05 GMT Date: Mon, 24 Mar 1997 09:18:05 GMT Message-Id: <199703240918.JAA05399@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: oneill@cs.sfu.ca Cc: tex-fonts@math.utah.edu Subject: Re: More map-file strangeness... In-Reply-To: <199703212152.NAA10409@alonzo.cs.sfu.ca> References: <199703212152.NAA10409@alonzo.cs.sfu.ca> Melissa O'Neill writes: > I also notice that ptm.map contains entries for psyr, psyro and pzcmi8r > which really have no business being there. > they are there for mathptm; i forget the precise reasoning, but i thought it did no harm sebastian 24-Mar-1997 9:17:00-GMT,1706;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id CAA02821 for ; Mon, 24 Mar 1997 02:16:59 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA14736 for ; Mon, 24 Mar 1997 09:14:40 GMT Received: from cadair.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 24 Mar 1997 09:17:20 +0000 Received: from lochnagarn.elsevier.co.uk (lochnagarn.elsevier.co.uk [193.131.216.1]) by cadair.elsevier.co.uk (8.8.3/8.8.3) with ESMTP id JAA02621; Mon, 24 Mar 1997 09:17:13 GMT Received: (from srahtz@localhost) by lochnagarn.elsevier.co.uk (8.8.3/8.8.3) id JAA05371; Mon, 24 Mar 1997 09:17:14 GMT Date: Mon, 24 Mar 1997 09:17:14 GMT Message-Id: <199703240917.JAA05371@lochnagarn.elsevier.co.uk> From: Sebastian Rahtz To: oneill@cs.sfu.ca Cc: tex-fonts@math.utah.edu Subject: Re: Nonsense map files in psfonts/urw on CTAN In-Reply-To: <199703212130.NAA10387@alonzo.cs.sfu.ca> References: <199703212130.NAA10387@alonzo.cs.sfu.ca> Melissa O'Neill writes: > Has anyone actually looked at the map currently given for URW Antiqua > and Nimbus on CTAN? yes, i generated it automatically, and no, i didnt look at it. will try and find time quickly to clean this up > all, and while I have 16 .tfm files, CTAN has none. Something definately > seems to have gotten broken somewhere. i'll probably just remove this set altogether, if thats ok by you. sebastian 25-Mar-1997 12:31:32-GMT,1077;000000000000 Return-Path: Received: from freelunch.freenet.kiev.ua (root@freelunch.freenet.kiev.ua [194.44.28.250]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA07622 for ; Tue, 25 Mar 1997 05:31:15 -0700 (MST) Received: from tbimc.UUCP (uutbimc@localhost) by freelunch.freenet.kiev.ua (8.8.5/8.8.5) with UUCP id OAA21740 for tex-fonts@math.utah.edu; Tue, 25 Mar 1997 14:24:50 +0200 (EET) X-Authentication-Warning: freelunch.freenet.kiev.ua: uutbimc set sender to tbimc!tbimc.freenet.kiev.ua!tiger using -f Received: by tbimc.freenet.kiev.ua (UUPC/@ v6.20, 03Nov96) id AA25988; Tue, 25 Mar 1997 13:11:22 +0200 (UKR) To: tex-fonts@math.utah.edu Cc: tiger@freelunch.freenet.kiev.ua Message-Id: Organization: TBiMC Scientific Publishers From: "Igor I. Klesov" Date: Tue, 25 Mar 97 13:11:22 +0200 X-Mailer: BML [MS/DOS Beauty Mail v1.36H] Lines: 1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii help 26-Mar-1997 13:49:28-GMT,3089;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id GAA09275 for ; Wed, 26 Mar 1997 06:49:23 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.13) with ESMTP id IAA25826; Wed, 26 Mar 1997 08:49:08 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA03933; Wed, 26 Mar 1997 08:49:07 -0500 (EST) Date: Wed, 26 Mar 1997 08:49:07 -0500 (EST) Message-Id: <199703261349.IAA03933@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: tex-fonts@math.utah.edu Subject: kern pairs in CM fonts TFM Reply-to: bkph@ai.mit.edu re: apparently conflicting kern pairs in CM TFM files. Can anyone tell me where the apparently contradictory kern pairs come from in CM TFM files? There are a few cases where there are two occurences of a particular kern pair with different kern amounts. Now presumably TeX stops looking after it finds the first one, so one of these values is always shadowed. But I am curious whether this is an `optimization' that METAFONT does, or whether it is something the font author has control over. Attached find examples. Regards, Berthold. >From CMR10: (LABEL C k) (LABEL C v) (KRN C a R -0.055555) (LABEL C w) (KRN C e R -0.027779) (KRN C a R -0.027779) (KRN C o R -0.027779) (KRN C c R -0.027779) (STOP) Which means that the kern programs for k and v drop through to the kern program for w. Hence there are two different kerns for the pairs `k a' and `v a,' of different size (-0.055555 and -0.027779). Presumably TeX will read the first one and ignore the second. The same thing happens in all CMR* and CMBX* fonts (and some others). But there are no other such duplicate kern pairs in CM TFM files AFAIK. (There are a few other places where kern programs `drop through,' but none where there are conflicting values for the kern amount). >From CMMI10: (LABEL C N) (LABEL C X) (KRN O 75 R -0.083334) (LABEL C C) (LABEL C T) (KRN O 75 R -0.027779) (KRN O 73 R -0.055555) (KRN O 72 R -0.055555) (LABEL O 2) (LABEL O 4) (LABEL O 6) (LABEL O 10) (LABEL O 12) (LABEL O 14) (LABEL O 20) (LABEL O 22) (LABEL O 32) (LABEL O 36) (LABEL O 42) (LABEL O 43) (LABEL O 45) (LABEL O 46) (LABEL O 47) (LABEL O 100) (LABEL C B) (LABEL C E) (LABEL C G) (LABEL C O) (LABEL C Q) (LABEL C R) (LABEL C l) (LABEL C p) (LABEL C q) (LABEL C t) (LABEL C w) (LABEL O 174) (KRN O 177 R 0.083336) (STOP) The tail end of this are just some bogus kern pairs used for accent positioning in math. The interesting part is the start, where the kern programs for N and X drop through to those for C and T. As a result there are two kern pairs for each of `N slash' and `X slash,' with different kern amounts. The same thing happens in all CMMI* and CMMIB* fonts. 26-Mar-1997 14:34:46-GMT,3127;000000000000 Return-Path: Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA10178 for ; Wed, 26 Mar 1997 07:34:45 -0700 (MST) Date: Wed, 26 Mar 1997 15:33:21 +0100 (MET) Message-Id: <199703261433.PAA02085@isle.informatik.uni-stuttgart.de> Received: by isle.informatik.uni-stuttgart.de; Wed, 26 Mar 1997 15:33:21 +0100 (MET) From: Bernd Raichle To: tex-fonts@math.utah.edu In-reply-to: <199703261349.IAA03933@kauai.ai.mit.edu> (bkph@ai.mit.edu) Subject: Re: kern pairs in CM fonts TFM On Wed, 26 Mar 1997 08:49:07 -0500 (EST), "Berthold K.P. Horn" wrote: : re: apparently conflicting kern pairs in CM TFM files. : : Can anyone tell me where the apparently contradictory kern pairs come from in : CM TFM files? They are declared in the Metfont source. For example CM's "roman.mf" contain the two lines ligtable "k": if serifs: "v": "a" kern -u#, fi\\"w": "e" kern k#, "a" kern k#, "o" kern k#, "c" kern k#; If "serifs" is defined, there will be two different kern pairs for "k"+"a", but they won't do any harm: TeX will take only the first matching kern or ligature command. : There are a few cases where there are two occurences of a : particular kern pair with different kern amounts. Now presumably TeX stops : looking after it finds the first one, so one of these values is always : shadowed. Correct. The kerning/ligature table is search for a matching pair using a simple linear search. : But I am curious whether this is an `optimization' that METAFONT : does, or whether it is something the font author has control over. [...] As shown above, it is under the control of the font author... and Metafont won't remove shadowed pairs. An addition: I have made prototypical reimplementation of TeX's ligature/kerning builder to allow kerning between two ligatures. (With TeX it is only possible to kern between a ligature/character and the following character. Even if the following character will form a ligature afterwards, TeX doesn't support ligature-ligature or character- ligature kerning because of the necessity to backstep.) This reimplementation is running. It separates the necessary ligature pass from the following kerning pass, nonetheless both passes can be implemented in a single pass(!). The new algorithm allows suppressing ligature building and for this case it's possible to do some kerning using the fact that the kerning/ligature table of a font can have both: a kern and a ligature step between two character/ligature pairs. Before someone will ask: The implementation was done in Common-Lisp, implements left/right boundary characters, has a compatibility switch to get TeX's original behaviour (for comparison: the re-implementation of the read-tfm-font function needs ~500 lines of code, the new dolig function needs ~180 lines), and it's planned to incorporate this algorithm rewitten in Web-Pascal in one of the next e-TeX versions. -bernd 26-Mar-1997 14:54:04-GMT,1411;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmzb.zdv.Uni-Mainz.DE [134.93.8.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA10539 for ; Wed, 26 Mar 1997 07:54:02 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IGYP8K1HEOFTE2VG@MZDMZA.ZDV.UNI-MAINZ.DE>; Wed, 26 Mar 1997 15:54:53 +0100 Date: Wed, 26 Mar 1997 15:54:53 +0100 Subject: Re: kern pairs in CM fonts TFM To: bkph@ai.mit.edu, tex-fonts@math.utah.edu Message-id: <01IGYP8K1O02FTE2VG@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: MZDMZA::IN%"bkph@ai.mit.edu" X-VMS-Cc: IN"tex-fonts@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT The author of a META-FONT actually has controll over this, alltho it looks rather like a misfeature of MF than anything else. However, since presumably the kerning ist judged a posteriori from the printouts, I don't think that it really introduces bugs. The relevant bit of METAFONT syntax is: (from roman.mf) ligtable "k": if serifs: "v": "a" kern -u#, fi\\"w": "e" kern k#, "a" kern k#, "o" kern k#, "c" kern k#; The MF syntax is very close to the PL (and TFM) syntax here. The statement looks very contrieved (note the if going in there...). --J"org Knappen. 31-Mar-1997 14:52:04-GMT,872;000000000000 Return-Path: Received: from PSFC.MIT.EDU (PSFC.MIT.EDU [18.77.0.113]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id HAA20421 for ; Mon, 31 Mar 1997 07:52:03 -0700 (MST) Date: Mon, 31 Mar 1997 9:52:02 -0500 From: Mark London To: TEX-FONTS@csc-sun.math.utah.edu Message-Id: <970331095202.2064fc6f@PSFC.MIT.EDU> Subject: psfonts question Hi- I'm new at this. I just obtained the psfonts from a CTAN server, and in the .map files I notice several different definitions for the same font, i.e.: ptmro8r Times-Roman " .167 SlantFont TeXBase1Encoding ReEncodeFont " <8r.enc ptmrr8re Times-Roman " 1.2 ExtendFont TeXBase1Encoding ReEncodeFont " <8r.enc ptmrr8rn Times-Roman " .82 ExtendFont TeXBase1Encoding ReEncodeFont " <8r.enc All 3 are Times-Roman. Can someone explain? Thanks. Mark 31-Mar-1997 22:34:44-GMT,1335;000000000000 Return-Path: Received: from cs.umb.edu (root@cs.umb.edu [158.121.104.2]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id PAA09802 for ; Mon, 31 Mar 1997 15:34:43 -0700 (MST) Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA02052 (5.65c/IDA-1.4.4 for TEX-FONTS@csc-sun.math.utah.edu); Mon, 31 Mar 1997 17:33:10 -0500 From: "K. Berry" Received: (from kb@localhost) by terminus.cs.umb.edu (8.8.0/8.8.0) id RAA15307; Mon, 31 Mar 1997 17:33:08 -0500 (EST) Date: Mon, 31 Mar 1997 17:33:08 -0500 (EST) Message-Id: <199703312233.RAA15307@terminus.cs.umb.edu> To: MRL@PSFC.MIT.EDU Cc: TEX-FONTS@csc-sun.math.utah.edu Subject: Re: psfonts question ptmro8r Times-Roman " .167 SlantFont TeXBase1Encoding ReEncodeFont " <8r.enc ptmrr8re Times-Roman " 1.2 ExtendFont TeXBase1Encoding ReEncodeFont " <8r.enc ptmrr8rn Times-Roman " .82 ExtendFont TeXBase1Encoding ReEncodeFont " <8r.enc All 3 are Times-Roman. Can someone explain? Thanks. All three are *based* on Times Roman. The first is oblique, the second is extended, the third is narrow. See the Dvipsk manual (I'm not sure if Tom has updated his version of the manual yet :-), the Fontname document, etc. (accessible from http://www.tug.org/web2c, among other places). 3-Apr-1997 12:13:20-GMT,2236;000000000000 Return-Path: Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmza.zdv.Uni-Mainz.DE [134.93.178.30]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA29483 for ; Thu, 3 Apr 1997 05:13:19 -0700 (MST) From: KNAPPEN@MZDMZA.ZDV.UNI-MAINZ.DE Received: from MZDMZA.ZDV.UNI-MAINZ.DE by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #10401) id <01IH9QXRCYU8G0UKSC@MZDMZA.ZDV.UNI-MAINZ.DE> for tex-fonts@math.utah.edu; Thu, 03 Apr 1997 14:14:04 +0100 Date: Thu, 03 Apr 1997 14:14:04 +0100 Subject: Text symbol encodings To: tex-fonts@csc-sun.math.utah.edu Message-id: <01IH9QXRD3JMG0UKSC@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: IN"tex-fonts@math.utah.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT During the 10th Unicode conference at MAinz, I had some discussion with Chris and Frank about the different encodings. Out of these discussions, it seems appropriate to agree on two new encodings: TS0 := TS1 \cap {Adobe Standard Encoding} TS0X:= TS1 \cap ({Adobe Standard encoding} \cup {Adobe Expert Encoding}) IMO, the code positions should be the same as in TS1, such that TS0 \subset TS0X \subset TS1. Yours, J"org Knappen. P.S. For recent information on the TS1 encoding (including information on some command names which I have changed after discussions with Chris) consult my wep page http://vzdmzi.zdv.uni-mainz.de/~knappen/jk007.html The main page is in german, but most leaf docoment are in english. P.S.P^{\dagger}: I want you to check the following two lists, if they are correct and complete. TS0: \$ \textasteriskcentered \textminus \textdagger \textdaggerdbl \textbardbl \textpermill \textbullet \textflorin \texttrademark \textcent \pounds \textcurrency \textyen \textbrokenbar \S \textcopyright \textordfeminine \textlogicalnot \textregistered \textdegree \textpm \textmu \P \textperiodcentered \textordmasculine \textmultiply \textdivide TS0X: all of TS0 plus \textfraction The 10 oldstyle digits, comma, and period \textdollaroldstyle \textcentoldstyle \textcolonmonetary \texttwosuperior \textthreesuperior \textonesuperior \textonequarter \textonehalf \textthreequarters *** The End *** 3-Apr-1997 12:46:02-GMT,2223;000000000000 Return-Path: Received: from ursa.cns.umist.ac.uk (ursa.cns.umist.ac.uk [130.88.210.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id FAA29970 for ; Thu, 3 Apr 1997 05:39:49 -0700 (MST) Received: from fs4.in.umist.ac.uk by ursa.cns.umist.ac.uk with SMTP (PP); Thu, 3 Apr 1997 12:19:50 +0100 Received: from UMIST-IN-FS4/SpoolDir by fs4.in.umist.ac.uk (Mercury 1.21); 3 Apr 97 11:20:04 GMT Received: from SpoolDir by UMIST-IN-FS4 (Mercury 1.21); 3 Apr 97 11:19:40 GMT From: Bernard Treves Brown Organization: DIAS, UMIST, UK. To: tex-fonts@csc-sun.math.utah.edu Date: Thu, 3 Apr 1997 11:19:30 GMT MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: kern pairs in CM fonts TFM Reply-to: B.J.Treves.Brown@umist.ac.uk Priority: normal In-reply-to: <199703261433.PAA02085@isle.informatik.uni-stuttgart.de> References: <199703261349.IAA03933@kauai.ai.mit.edu> (bkph@ai.mit.edu) X-mailer: Pegasus Mail for Windows (v2.52) Message-ID: <137E8215C@fs4.in.umist.ac.uk> Bernd Raichle said: > I have made prototypical reimplementation of TeX's ligature/kerning > builder to allow kerning between two ligatures. (With TeX it is > only possible to kern between a ligature/character and the following > character. Even if the following character will form a ligature > afterwards, TeX doesn't support ligature-ligature or character- > ligature kerning because of the necessity to backstep.) Many thanks for this. I have just run into trouble with endashes in Gill Sans. (r hyphen) is kerned, and looks neat. TeX therefore gives (r endash) has the same kern, which makes the endash nearly collide with the r, as endash is further from the baseline than hyphen... Is there any way around this except a future e-TeX? Thanks Bernard Dr. Bernard J. Treves Brown, Research Associate Department of Instrumentation and Analytical Science, UMIST, P.O. Box 88, Manchester. M60 1QD UK Email: B.J.Treves.Brown@umist.ac.uk Tel: 0161-200 4899 (Outside UK +44 161 200 4899) Fax: 0161-200 4911 (Outside UK +44 161 200 4911) 3-Apr-1997 13:34:38-GMT,1823;000000000000 Return-Path: Received: from moria.imaginet.fr (moria.imaginet.fr [194.51.83.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id GAA01062 for ; Thu, 3 Apr 1997 06:34:36 -0700 (MST) Received: from imaginet.fr by moria.imaginet.fr via ESMTP (950215.SGI.8.6.10/911001.SGI) id PAA05176; Thu, 3 Apr 1997 15:35:11 +0200 Received: from [195.68.10.81] (isdn2.lille.imaginet.fr [195.68.10.81]) by imaginet.fr (8.7.5/8.7.31) with SMTP id PAA03326; Thu, 3 Apr 1997 15:34:28 +0200 (METDST) Message-Id: <199704031334.PAA03326@imaginet.fr> Subject: Re: kern pairs in CM fonts TFM Date: Jeu, 3 Avr 97 15:34:28 -0000 x-sender: yannis@mail.imaginet.fr x-mailer: Claris Emailer 1.1 From: Yannis Haralambous To: , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" >Many thanks for this. I have just run into trouble with endashes in >Gill Sans. (r hyphen) is kerned, and looks neat. TeX therefore gives >(r endash) has the same kern, which makes the endash nearly collide >with the r, as endash is further from the baseline than hyphen... > >Is there any way around this except a future e-TeX? You can wait for a future e-TeX or take a today's omega: we are not at all using internal font ligatures (only kernings). This allows us to change the ligature scheme dynamically (Portuguese and Turkish use no ff, ffi, ... other languages do). And it solves your problem: omega will replace -- by the endash before it even arrives to the font (in fact at the Unicode level, since endash is indeed a Unicode character and not merely a glyph). Then you font can define kernings between r and - but not with endash and bingo. Could this be more natural than that?? Yannis 3-Apr-1997 14:08:29-GMT,1472;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA01760 for ; Thu, 3 Apr 1997 07:08:24 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id QAA06838; Thu, 3 Apr 1997 16:07:55 +0200 (MET DST) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id QAA20415; Thu, 3 Apr 1997 16:07:46 +0200 (MET DST) Date: Thu, 3 Apr 1997 16:07:46 +0200 (MET DST) Message-Id: <199704031407.QAA20415@mozart.ujf-grenoble.fr> From: Thierry Bouche To: Yannis Haralambous Cc: , Subject: Re: kern pairs in CM fonts TFM In-Reply-To: <199704031334.PAA03326@imaginet.fr> References: <199704031334.PAA03326@imaginet.fr> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII OK, let's try something more difficult: I want to print the string ffi but it should be printed as f next to fi (lig) but not as the ffi lig. Nonetheless, I want to have the right kern between f and fi (well fi is in unicode, but let's suppose it's not there) Possible? Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 3-Apr-1997 14:59:05-GMT,2514;000000000000 Return-Path: Received: from moria.imaginet.fr (moria.imaginet.fr [194.51.83.1]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with SMTP id HAA02905 for ; Thu, 3 Apr 1997 07:59:03 -0700 (MST) Received: from imaginet.fr by moria.imaginet.fr via ESMTP (950215.SGI.8.6.10/911001.SGI) id QAA07835; Thu, 3 Apr 1997 16:59:22 +0200 Received: from [194.206.126.133] (port5.nordnet.fr [194.206.126.133]) by imaginet.fr (8.7.5/8.7.31) with SMTP id QAA13285; Thu, 3 Apr 1997 16:57:44 +0200 (METDST) Message-Id: <199704031457.QAA13285@imaginet.fr> Subject: Re: kern pairs in CM fonts TFM Date: Jeu, 3 Avr 97 16:57:43 -0000 x-sender: yannis@mail.imaginet.fr x-mailer: Claris Emailer 1.1 From: Yannis Haralambous To: "Thierry Bouche" cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" >OK, let's try something more difficult: > >I want to print the string ffi but it should be printed as f next to >fi (lig) but not as the ffi lig. Nonetheless, I want to have the right >kern between f and fi (well fi is in unicode, but let's suppose it's >not there) I encounter only one problem: I can't see where the difficulty is... What you want is a font with fi ligature but without ffi, and with a kern between f and fi. Provided your font has a kern between f and fi in your otp you will put a f+i -> fi ligature, but not a f+fi->ffi one. I know what you are thinking, no need to ask it: yes, of course you can have a ff ligature: just put the rule f+fi->itself before f+f->ff. >but let's suppose it's >not there) The character set Omega works with is an superset of Unicode. It can contain anything you want. +--------------------------------------------------------------------+ | Yannis Haralambous, Ph.D. yannis@null.net | +--------------------------------------------------------------------+ | 187, rue Nationale fax: +33 (0)3.20.40.28.64 | | 59800 Lille, France | +--------------------------------------------------------------------+ ...pour distinguer l'exterieur d'un aquarium, mieux vaut n'etre pas poisson ...the ball I threw while playing in the park has never reached the ground 12-Apr-1997 13:26:14-GMT,604;000000000000 Return-Path: Received: from hog.uchicago.edu (hog.uchicago.edu [128.135.72.46]) by csc-sun.math.utah.edu (8.8.4/8.8.4) with ESMTP id HAA20903 for ; Sat, 12 Apr 1997 07:26:02 -0600 (MDT) Received: (from nathand@localhost) by hog.uchicago.edu (8.8.4/8.7.5) id IAA01936 for tex-fonts@math.utah.edu; Sat, 12 Apr 1997 08:25:49 -0500 (CDT) Date: Sat, 12 Apr 1997 08:25:49 -0500 (CDT) From: Nathan Dunfield Message-Id: <199704121325.IAA01936@hog.uchicago.edu> To: tex-fonts@csc-sun.math.utah.edu Subject: archive ls 16-Apr-1997 18:17:20-GMT,590;000000000000 Return-Path: Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id MAA19841 for ; Wed, 16 Apr 1997 12:17:17 -0600 (MDT) Subject: subscribe To: tex-fonts@csc-sun.math.utah.edu Date: Wed, 16 Apr 1997 19:01:01 +0100 (BST) From: Timothy Murphy X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: tim@maths.tcd.ie Message-ID: <9704161901.aa02286@salmon.maths.tcd.ie> help 17-Apr-1997 5:20:33-GMT,1049;000000000000 Return-Path: Received: from ring.kotel.co.kr (ring.kotel.co.kr [147.6.1.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id XAA05305 for ; Wed, 16 Apr 1997 23:20:16 -0600 (MDT) Received: from copoolso.kotel.co.kr (copoolso [147.6.19.15]) by ring.kotel.co.kr (8.6.12h2/8.6.9) with SMTP id OAA08864 for ; Thu, 17 Apr 1997 14:21:27 +0900 Received: by copoolso.kotel.co.kr (5.0/SMI-SVR4) id AA02125; Thu, 17 Apr 1997 14:15:46 --900 From: mchung@copoolso.kotel.co.kr (Chung) Message-Id: <9704170515.AA02125@copoolso.kotel.co.kr> Subject: Missing fonts To: tex-fonts@csc-sun.math.utah.edu Date: Thu, 17 Apr 1997 14:15:45 +0900 (ROK) X-Mailer: ELM [version 2.4 PL21-h3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I need the Ghostscript-generated bitmaps(PK files) for the standard 35 PS fonts at multiples of 600dpi. Could you let me know the location for them? Thank you in advance for your information. Min Gyo 17-Apr-1997 19:09:25-GMT,894;000000000000 Return-Path: Received: from cs.umb.edu (root@cs.umb.edu [158.121.104.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id NAA08551 for ; Thu, 17 Apr 1997 13:09:23 -0600 (MDT) Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA06613 (5.65c/IDA-1.4.4 for tex-fonts@csc-sun.math.utah.edu); Thu, 17 Apr 1997 15:07:52 -0400 From: "K. Berry" Received: (from kb@localhost) by terminus.cs.umb.edu (8.8.0/8.8.0) id PAA15332; Thu, 17 Apr 1997 15:07:39 -0400 (EDT) Date: Thu, 17 Apr 1997 15:07:39 -0400 (EDT) Message-Id: <199704171907.PAA15332@terminus.cs.umb.edu> To: mchung@copoolso.kotel.co.kr Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: Missing fonts PS fonts at multiples of 600dpi. Could you let me know the location for them? ftp://ftp.cs.umb.edu/pub/tex/lw35pk.zip (also CTAN, ftp.tug.org, etc.) 18-Apr-1997 7:26:20-GMT,1160;000000000000 Return-Path: Received: from mailhost.rz.ruhr-uni-bochum.de (sun529.rz.ruhr-uni-bochum.de [134.147.32.36]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id BAA15414 for ; Fri, 18 Apr 1997 01:26:19 -0600 (MDT) Received: (qmail 8298 invoked from network); 18 Apr 1997 07:26:17 -0000 Received: from hp138.rz.ruhr-uni-bochum.de (kriegjcb@134.147.222.5) by sun529.rz.ruhr-uni-bochum.de with SMTP; 18 Apr 1997 07:26:17 -0000 Received: (from kriegjcb@localhost) by hp138.rz.ruhr-uni-bochum.de (8.8.5/8.8.5) id JAA23377; Fri, 18 Apr 1997 09:26:13 +0200 (METDST) Sender: kriegjcb@rz.ruhr-uni-bochum.de From: "K. Berry" Date: Thu, 17 Apr 1997 15:07:39 -0400 (EDT) Message-Id: <199704171907.PAA15332@terminus.cs.umb.edu> To: mchung@copoolso.kotel.co.kr Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: Missing fonts Lines: 9 X-Mailer: Gnus v5.4.37/Emacs 19.34 PS fonts at multiples of 600dpi. Could you let me know the location for them? ftp://ftp.cs.umb.edu/pub/tex/lw35pk.zip (also CTAN, ftp.tug.org, etc.) --AAB22717.861317901/sun529.rz.ruhr-uni-bochum.de-- 18-Apr-1997 7:26:41-GMT,1160;000000000000 Return-Path: Received: from mailhost.rz.ruhr-uni-bochum.de (sun529.rz.ruhr-uni-bochum.de [134.147.32.36]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id BAA15419 for ; Fri, 18 Apr 1997 01:26:40 -0600 (MDT) Received: (qmail 8340 invoked from network); 18 Apr 1997 07:26:38 -0000 Received: from hp138.rz.ruhr-uni-bochum.de (kriegjcb@134.147.222.5) by sun529.rz.ruhr-uni-bochum.de with SMTP; 18 Apr 1997 07:26:38 -0000 Received: (from kriegjcb@localhost) by hp138.rz.ruhr-uni-bochum.de (8.8.5/8.8.5) id JAA23402; Fri, 18 Apr 1997 09:26:35 +0200 (METDST) Sender: kriegjcb@rz.ruhr-uni-bochum.de From: "K. Berry" Date: Thu, 17 Apr 1997 15:07:39 -0400 (EDT) Message-Id: <199704171907.PAA15332@terminus.cs.umb.edu> To: mchung@copoolso.kotel.co.kr Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: Missing fonts Lines: 9 X-Mailer: Gnus v5.4.37/Emacs 19.34 PS fonts at multiples of 600dpi. Could you let me know the location for them? ftp://ftp.cs.umb.edu/pub/tex/lw35pk.zip (also CTAN, ftp.tug.org, etc.) --BAB01238.861321378/sun529.rz.ruhr-uni-bochum.de-- 24-Apr-1997 0:01:27-GMT,3463;000000000000 Return-Path: Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id SAA29253; Wed, 23 Apr 1997 18:01:27 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id SAA17814; Wed, 23 Apr 1997 18:01:25 -0600 (MDT) Date: Wed, 23 Apr 1997 18:01:25 -0600 (MDT) To: tex-fonts@csc-sun.math.utah.edu, math-font-discuss@cogs.susx.ac.uk Cc: beebe@csc-sun.math.utah.edu X-US-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: New font developments: OpenType Font Specification Message-ID: People on this list may be interested in a new announcement about a major development in the font industry dated today, 23-Apr-1997, at this URL: http://www.adobe.com/aboutadobe/publicrelations/HTML/9704/970423.admictyp.html It begins: >> ... >> Adobe Systems and Microsoft Deliver OpenType Font Specification >> >> Universal Font Format Enhances User Experience and Integrates Print >> and Web Authoring Environments; Industry Endorses Open Standard and >> Font Embedding Solution >> >> SEYBOLD, New York (April 23 , 1997) (Nasdaq:ADBE, MSFT)--Adobe Systems >> Incorporated and Microsoft Corporation today announced the >> availability of an OpenType font specification for developers and >> ISVs. OpenType is a universal typography solution co-developed by the >> two companies that combines today's leading Type 1 and TrueType font >> technologies. OpenType is a next-generation type format that >> streamlines font management in a mixed computing-platform environment, >> provides richer formatting options, and includes an integrated >> Internet publishing environment for font embedding and management for >> Internet-based applications. Unlike proprietary font embedding >> technologies, OpenType is an open, freely-licensable solution for >> developers who want to build support into Web browsers and authoring >> tools. The OpenType specification is available on both the Adobe >> (http://www.adobe.com) and Microsoft (http://www.microsoft.com) Web >> pages. >> >> Industry leading font developers, including Agfa Typographic Systems >> and MonoType Typography Incorporated, have publicly endorsed OpenType >> and font embedding for high-quality typography across all publishing >> media and for protection of intellectual property rights. These >> companies, as well as Adobe and Microsoft, plan to deliver OpenType >> typefaces by early 1998. Additionally, Microsoft today unveiled its >> first OpenType typeface, a new expanded-character set version of >> Hermann Zapf Palatino(TM). Zapf has overseen the project with >> Linotype-Hell AG at every stage. The new font was shown today in the >> Type Gallery at the Seybold conference. >> ... ======================================================================== 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 URL: http://www.math.utah.edu/~beebe Salt Lake City, UT 84112, USA ======================================================================== 24-Apr-1997 12:05:50-GMT,2926;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id GAA13119; Thu, 24 Apr 1997 06:05:49 -0600 (MDT) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/8.8.5AI/life.ai.mit.edu:1.13) with ESMTP id IAA19051; Thu, 24 Apr 1997 08:05:45 -0400 (EDT) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA04312; Thu, 24 Apr 1997 08:05:43 -0400 (EDT) Date: Thu, 24 Apr 1997 08:05:43 -0400 (EDT) Message-Id: <199704241205.IAA04312@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: beebe@csc-sun.math.utah.edu CC: tex-fonts@csc-sun.math.utah.edu, math-font-discuss@cogs.susx.ac.uk, beebe@csc-sun.math.utah.edu In-reply-to: Subject: Re: New font developments: OpenType Font Specification Reply-to: bkph@ai.mit.edu Nelson Beebe wrote: People on this list may be interested in a new announcement about a major development in the font industry dated today, 23-Apr-1997, at this URL: http://www.adobe.com/aboutadobe/publicrelations/HTML/9704/970423.admictyp.html It begins: >> Adobe Systems and Microsoft Deliver OpenType Font Specification This has been in the works for quite some time (originally just as `spec arw' or vapourware to try and kill GX on the Mac) and in some sense puts to rest the corporate font wars (TT versus T1) between MS and Adobe (and leaves Apple out in the cold with GX?). It's main effect I think will be many more fonts with reasonable glyph complements (at least 400 to cover all Latin alphabets and probably 665 to cover WGL4). Where will TeX stand? It is ironic that TeX bitmap fonts finally arrived in the 8 bit world with EC fonts, just at a time when people are getting ready to take the next step... (The Lucida Latin font set already goes in the direction of supporting a more reasonable glyph complement, by the way, and under ATM for NT provides access to 403 glyphs in each of the twelve fonts). Another important side effect that I expect is that ATM may very well go away and just become part of the operating system - at least in Windows NT (which is the 32 bit platform of choice in the Windows world since its WIN32 API is more powerful than the one in Windows 95, and since UNICODE support in Windows 95 is just a wink and a nod). That will put an end to the nonsense about wanting everything in TrueType form - even when inferior - simply because you then don't have to install ATM. As for web authoring. I am not holding my breath. There is no valid security method in the current OpenType spec. Hence no protection for fonts, hence few vendors will participate - other than the parties pushing OpenType technology. I expect MS in particular to give away some fonts to promote this. Regards, Berthold. 24-Apr-1997 18:22:11-GMT,1529;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id MAA22438; Thu, 24 Apr 1997 12:22:10 -0600 (MDT) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id LAA02482; Thu, 24 Apr 1997 11:21:15 -0700 (PDT) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id LAA25926; Thu, 24 Apr 1997 11:21:13 -0700 (PDT) Message-Id: <199704241821.LAA25926@alonzo.cs.sfu.ca> Subject: Re: New font developments: OpenType Font Specification To: bkph@ai.mit.edu Date: Thu, 24 Apr 1997 11:21:12 -0700 (PDT) Cc: beebe@csc-sun.math.utah.edu, tex-fonts@csc-sun.math.utah.edu, math-font-discuss@cogs.susx.ac.uk In-Reply-To: <199704241205.IAA04312@kauai.ai.mit.edu> from "Berthold K.P. Horn" at Apr 24, 97 08:05:43 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Berthold K.P. Horn writes: > This has been in the works for quite some time (originally just as > `spec arw' or vapourware to try and kill GX on the Mac) and in some > sense puts to rest the corporate font wars (TT versus T1) between MS > and Adobe (and leaves Apple out in the cold with GX?). Apple has already abandoned GX. Rapsody's imaging model will be based on Display PostScript, with the PostScript Level 3 extensions, and possibly some extensions taken from the now orphaned GX code. Melissa. 25-Apr-1997 20:33:08-GMT,2435;000000000000 Return-Path: Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id OAA27079 for ; Fri, 25 Apr 1997 14:33:07 -0600 (MDT) Received: (from uucp@localhost) by out1.ibm.net (8.6.9/8.6.9) id UAA422923 for ; Fri, 25 Apr 1997 20:32:42 GMT Message-Id: <199704252032.UAA422923@out1.ibm.net> Received: from slip139-92-42-172.ut.nl.ibm.net(139.92.42.172) by out1.ibm.net via smap (V1.3mjr) id smal4UCAI; Fri Apr 25 20:31:53 1997 From: "Walter Schmidt" To: "tex-fonts" Date: Fri, 25 Apr 97 18:51:50 +0200 Reply-To: "Walter Schmidt" Priority: Normal X-Mailer: PMMail 1.91 for OS/2 Warp MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: New font developments: OpenType Font Specification On Thu, 24 Apr 1997 08:05:43 -0400 (EDT), Berthold K.P. Horn wrote: > Where will TeX stand? It is ironic that >TeX bitmap fonts finally arrived in the 8 bit world with EC fonts, >just at a time when people are getting ready to take the next step... With (La)TeX every T1 text font has its corresponding text companion font, so there is room for 512 glyphs. At the user level this is completely transparent: You do not need to know whether a certain symbol comes from the one or the other font. >Another important side effect that I expect is that ATM may very >well go away and just become part of the operating system - at >least in Windows NT The idea is not new: The operating system OS/2 has - since v1.3 - a perfectly integrated ATM. Most users do not even know that they have ATM; they simply use it! >As for web authoring... One can send PDF documents through WWW, and Adobe has just created a special technology (Amber) for optimizing this process. Why do we need another new "standard"? Just ask Bill Gate$! Greetings Walter -- Walter Schmidt Schornbaumstrasse 2, 91052 Erlangen, Germany -- Walter Schmidt Schornbaumstrasse 2, 91052 Erlangen, Germany -- Walter Schmidt Schornbaumstrasse 2, 91052 Erlangen, Germany -- Walter Schmidt Schornbaumstrasse 2, 91052 Erlangen, Germany -- Walter Schmidt Schornbaumstrasse 2, 91052 Erlangen, Germany 14-May-1997 7:44:44-GMT,1461;000000000000 Return-Path: Received: from ns.lhsgroup.com (ns.lhsgroup.com [208.140.112.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id BAA03767 for ; Wed, 14 May 1997 01:44:43 -0600 (MDT) Received: from atlanta.de.lhsgroup.com (bhertel@atlanta.121.140.208.IN-ADDR.ARPA [208.140.121.56]) by ns.lhsgroup.com (8.7.6/8.7.3) with ESMTP id DAA22937 for ; Wed, 14 May 1997 03:44:41 -0400 Received: (from bhertel@localhost) by atlanta.de.lhsgroup.com (8.7.5/8.7.4) id JAA12728; Wed, 14 May 1997 09:48:37 +0200 Date: Wed, 14 May 1997 09:48:37 +0200 Message-Id: <199705140748.JAA12728@atlanta.de.lhsgroup.com> From: Bernd Hertel To: tex-fonts@csc-sun.math.utah.edu Subject: Arial fonts Reply-to: bhertel@de.lhsgroup.com Hallo there, I'm looking for an Arial (or similar) font to use under LaTeX. The format can be mf or type 1. If somebody of you knows about a TTF to type 1 converter, this would do also because this Arial font comes as a TTF with Windows (Word). I can use type 1 fonts because of the extremly helpful fontinst and vfinst packages (many kotau's to the authors). Thanks for your help. Regards Bernd -- Bernd Hertel .............eMail bhertel@de.lhsgroup.com LHS Spezifications GmbH .............eMail bhertel@t-online.de (private) Otto-Hahn-Strasse 36 .............Tel. +49 6103 482 627 63303 Dreieich-Sprendlingen 14-May-1997 9:40:10-GMT,1107;000000000000 Return-Path: Received: from cs.umb.edu (root@cs.umb.edu [158.121.104.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id DAA06168 for ; Wed, 14 May 1997 03:40:09 -0600 (MDT) From: kb@cs.umb.edu Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA07928 (5.65c/IDA-1.4.4 for tex-fonts@math.utah.edu); Wed, 14 May 1997 05:38:52 -0400 Received: (from kb@localhost) by terminus.cs.umb.edu (8.8.0/8.8.0) id FAA24279; Wed, 14 May 1997 05:38:29 -0400 (EDT) Date: Wed, 14 May 1997 05:38:29 -0400 (EDT) Message-Id: <199705140938.FAA24279@terminus.cs.umb.edu> To: bhertel@de.lhsgroup.com Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: Arial fonts I'm looking for an Arial (or similar) font to use under LaTeX. The format can be mf or type 1. If somebody of you knows about a TTF to Arial is basically Helvetica, and Helvetica, along with the other standard 35 fonts, is freely available (GPL'd) in Type 1 form, thanks to URW: ftp://prep.ai.mit.edu/pub/gnu/ghostscript-fonts-std-3.33.tar.gz Also at ftp.cs.wisc.edu/pub/ghost. kb@cs.umb.edu 14-May-1997 11:37:10-GMT,2380;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id FAA08209 for ; Wed, 14 May 1997 05:37:09 -0600 (MDT) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.15) with ESMTP id HAA02475; Wed, 14 May 1997 07:37:04 -0400 (EDT) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id HAA06088; Wed, 14 May 1997 07:37:02 -0400 (EDT) Date: Wed, 14 May 1997 07:37:02 -0400 (EDT) Message-Id: <199705141137.HAA06088@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: bhertel@de.lhsgroup.com CC: tex-fonts@csc-sun.math.utah.edu In-reply-to: <199705140748.JAA12728@atlanta.de.lhsgroup.com> (message from Bernd Hertel on Wed, 14 May 1997 09:48:37 +0200) Subject: Re: Arial fonts Reply-to: bkph@ai.mit.edu From: Bernd Hertel I'm looking for an Arial (or similar) font to use under LaTeX. The format can be mf or type 1. If somebody of you knows about a TTF to type 1 converter, this would do also because this Arial font comes as a TTF with Windows (Word). I can use type 1 fonts because of the extremly helpful fontinst and vfinst packages (many kotau's to the authors). You don't say what TeX system you are using. Several allow you to use TrueType fonts directly. These have their own method for writing TFM files. If you must have Type 1, get Arial MT from Adobe (http://www.adobe.com) or MonoType. At one point Arial MT was bundled with ATM for Windows. I wouldn't recommend converting between font formats since the hinting will be lost, and `auto hinting' substituted. But if you must do this, use TypeDesigner which does a slightly better job than some of the others. MicroSoft's Arial is one of a very small number of TrueType fonts with outstanding hinting (done by Type Solutions in New Hampshire). You can tell how much work this was by converting to Type 1 form and back again: the file size shrinks by one half! Bernd Hertel .............eMail bhertel@de.lhsgroup.com LHS Spezifications GmbH .............eMail bhertel@t-online.de (private) Otto-Hahn-Strasse 36 .............Tel. +49 6103 482 627 63303 Dreieich-Sprendlingen Berthold. 14-May-1997 11:49:11-GMT,2565;000000000000 Return-Path: Received: from ns.lhsgroup.com (mail.lhsgroup.com [208.140.112.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id FAA08459 for ; Wed, 14 May 1997 05:49:10 -0600 (MDT) Received: from atlanta.de.lhsgroup.com (bhertel@atlanta.121.140.208.IN-ADDR.ARPA [208.140.121.56]) by ns.lhsgroup.com (8.7.6/8.7.3) with ESMTP id HAA24286; Wed, 14 May 1997 07:49:07 -0400 Received: (from bhertel@localhost) by atlanta.de.lhsgroup.com (8.7.5/8.7.4) id NAA14673; Wed, 14 May 1997 13:52:54 +0200 Date: Wed, 14 May 1997 13:52:54 +0200 Message-Id: <199705141152.NAA14673@atlanta.de.lhsgroup.com> From: Bernd Hertel To: bkph@ai.mit.edu CC: tex-fonts@csc-sun.math.utah.edu In-reply-to: <199705141137.HAA06088@kauai.ai.mit.edu> (bkph@ai.mit.edu) Subject: Re: Arial fonts Reply-to: bhertel@de.lhsgroup.com Hi, > > You don't say what TeX system you are using. Several allow you to use > TrueType fonts directly. These have their own method for writing TFM files. > I'm using tetex under linux. Unfortunatly it does not allow to use TTF directly since TTF is, as far as I know, MS specific. > If you must have Type 1, get Arial MT from Adobe (http://www.adobe.com) > or MonoType. At one point Arial MT was bundled with ATM for Windows. Yes, good hint, I will check that (especially whether I can effort the $'s) > > I wouldn't recommend converting between font formats since the hinting > will be lost, and `auto hinting' substituted. But if you must do this, > use TypeDesigner which does a slightly better job than some of the others. I guess TypeDesigner is running on Win95 or NT right? But that shouldn't be a problem because it's ok to convert fonts there, although I prefer to run TeX itself in my favorite environment. > > MicroSoft's Arial is one of a very small number of TrueType fonts > with outstanding hinting (done by Type Solutions in New Hampshire). > You can tell how much work this was by converting to Type 1 form and back > again: the file size shrinks by one half! Well, I'm rather clueless when it comes to typesetting and font details. This is the reason why I enjoy LaTeX so much. The guys that have implemented it are professionals, so fortunatly I don't need to be one too. Thanks for your help, Bernd -- Bernd Hertel .............eMail bhertel@de.lhsgroup.com LHS Spezifications GmbH .............eMail bhertel@t-online.de (private) Otto-Hahn-Strasse 36 .............Tel. +49 6103 482 627 63303 Dreieich-Sprendlingen 15-May-1997 7:36:04-GMT,1834;000000000000 Return-Path: Received: from out2.ibm.net (out2.ibm.net [165.87.201.252]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id BAA05031 for ; Thu, 15 May 1997 01:36:03 -0600 (MDT) Received: (from uucp@localhost) by out2.ibm.net (8.6.9/8.6.9) id HAA74480 for ; Thu, 15 May 1997 07:36:02 GMT Message-Id: <199705150736.HAA74480@out2.ibm.net> Received: from slip139-92-42-159.ut.nl.ibm.net(139.92.42.159) by out2.ibm.net via smap (V1.3mjr) id smaddkDFW; Thu May 15 07:35:59 1997 From: "Walter Schmidt" To: "tex-fonts" Date: Thu, 15 May 97 09:35:09 +0200 Reply-To: "Walter Schmidt" Priority: Normal X-Mailer: PMMail 1.91 for OS/2 Warp MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Arial fonts On Wed, 14 May 1997 09:48:37 +0200, Bernd Hertel wrote: >I'm looking for an Arial (or similar) font to use under LaTeX. The >format can be mf. Hi, what about the CM Bright font family (mf format)? You can find it in the CTAN directory fonts/cmbright. I do not dare to compare it to Arial (=Helvetica), but it provides a full set of mathematical fonts, incl. all the AMS fonts, too At the moment the text fonts are available only with traditional (OT1) encoding. In the next two weeks or so an update will be released, providing T1 (=EC) and TS1 (= text companion) fonts, plus more font shapes. You want to see how it looks in a real book? See the Proceedings of the Ninth European TeX Conference (1995). The fonts used were a beta version of CM Bright and have been improved further in the meantime. Greetings Walter -- Walter Schmidt Schornbaumstrasse 2, 91052 Erlangen, Germany 27-May-1997 21:10:50-GMT,1949;000000000000 Return-Path: Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id PAA00728 for ; Tue, 27 May 1997 15:10:48 -0600 (MDT) Received: (from uucp@localhost) by out1.ibm.net (8.6.9/8.6.9) id VAA238838 for ; Tue, 27 May 1997 21:10:47 GMT Message-Id: <199705272110.VAA238838@out1.ibm.net> Received: from slip139-92-42-182.ut.nl.ibm.net(139.92.42.182) by out1.ibm.net via smap (V1.3mjr) id smaZpsDe7; Tue May 27 21:10:19 1997 From: "Walter Schmidt" To: "tex-fonts" Date: Tue, 27 May 97 23:11:01 +0200 Reply-To: "Walter Schmidt" Priority: Normal X-Mailer: PMMail 1.91 for OS/2 Warp MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: CM Bright Fonts Hello, I would like to announce the availability of the COMPUTER MODERN BRIGHT FONTS, version 1.0c. `Computer Modern Bright' is a family of sans serif fonts for TeX and LaTeX, coming in METAFONT format. It comprises text fonts of various shapes as well as all the fonts necessary for mathematical typesetting, incl. the AMS symbols. Being `lighter' and less obtrusive than CMSS, CM Bright has been designed as a well legible standalone font, suitable for typesetting complete documents. With this new version the text fonts are now available with *traditional*, *EC* and *text companion* encoding. Together with CM Bright there comes a family of typewriter fonts, `CM Typwewriter Light', which look better in combination with CM Bright than the CMTT fonts would do. In addition to the fonts all the necessary LaTeX interface files are provided. The software resides in the CTAN directory fonts/cmbright. Greetings Walter -- Walter Schmidt Schornbaumstrasse 2, 91052 Erlangen, Germany 4-Jun-1997 8:52:02-GMT,1879;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id CAA12359 for ; Wed, 4 Jun 1997 02:51:58 -0600 (MDT) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id KAA06320 for ; Wed, 4 Jun 1997 10:51:38 +0200 (MET DST) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id KAA19266; Wed, 4 Jun 1997 10:32:46 +0200 (MET DST) Date: Wed, 4 Jun 1997 10:32:46 +0200 (MET DST) Message-Id: <199706040832.KAA19266@mozart.ujf-grenoble.fr> From: Thierry Bouche To: Fontinst Mailing list CC: tex-font@csc-sun.math.utah.edu Subject: hidden composites X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII hello, there exist some fonts (like Monotype baskerville or Lino didot) where the AFM declares true chars that are indeed composites built in the PFA by a seac construct. These may fool some partial font downloading software (downloading the PFA definition of egrave in mbvr8r willnot download the two outlines needed to print this char). An example being the current pdftex. As these PS fonts are usually used through fontinst's VFs, I think it would be more interesting to redeclare these chars as composites in the AFM, and do the composition inside the VF, which would solve this particular problem. Does anybody know how to add the composite section of the AFM when the only available info is the seac construct in the PFA? Any different reaction? Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 5-Jun-1997 0:02:58-GMT,2629;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id SAA03506 for ; Wed, 4 Jun 1997 18:02:57 -0600 (MDT) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id RAA05545; Wed, 4 Jun 1997 17:02:55 -0700 (PDT) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id RAA23955; Wed, 4 Jun 1997 17:02:53 -0700 (PDT) Message-Id: <199706050002.RAA23955@alonzo.cs.sfu.ca> Subject: Re: hidden composites To: Thierry.Bouche@ujf-grenoble.fr (Thierry Bouche) Date: Wed, 4 Jun 1997 17:02:53 -0700 (PDT) Cc: fontinst@cogs.susx.ac.uk, tex-font@csc-sun.math.utah.edu In-Reply-To: <199706040832.KAA19266@mozart.ujf-grenoble.fr> from "Thierry Bouche" at Jun 4, 97 10:32:46 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Thierry Bouche says: > there exist some fonts (like Monotype baskerville or Lino didot) where > the AFM declares true chars that are indeed composites built in the > PFA by a seac construct. These may fool some partial font downloading > software (downloading the PFA definition of egrave in mbvr8r willnot > download the two outlines needed to print this char). An example being > the current pdftex. I'd say the problem isn't the AFM, but the partial font downloader; it should be doing a better job. (It might not even be that hard to fix if you have the source.) Generally, I've found that AFMs have more metric information than one can extract (easily) from a PFA file, however. However, a quick look at the available information seems to indicate that it might be doable in this case. You'd need a tool like t1disasm to look at the relevent `seac' entries in the CharStrings dictionary, then if you see: / { hsbw seac } ND ...and, if you let: = StandardEncoding[] = StandardEncoding[] = + - = ... then you could try the following composite character entry in the AFM file: CC 2 ; PCC 0 0 ; PCC ; It shouldn't be too hard to write a perl script to do this all automatically. This formula was derived emperically, by comparing AFM files of fonts I had with their corresponding disassembled CharStrings; I make no claims about its general applicability. Anyway, I hope this helps, Melissa. 5-Jun-1997 13:27:46-GMT,2601;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id HAA19142 for ; Thu, 5 Jun 1997 07:27:43 -0600 (MDT) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id PAA10235; Thu, 5 Jun 1997 15:27:24 +0200 (MET DST) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id PAA19689; Thu, 5 Jun 1997 15:30:56 +0200 (MET DST) Date: Thu, 5 Jun 1997 15:30:56 +0200 (MET DST) Message-Id: <199706051330.PAA19689@mozart.ujf-grenoble.fr> From: Thierry Bouche To: "Melissa O'Neill" Cc: Thierry.Bouche@ujf-grenoble.fr (Thierry Bouche), fontinst@cogs.susx.ac.uk, tex-font@csc-sun.math.utah.edu Subject: Re: hidden composites In-Reply-To: <199706050002.RAA23955@alonzo.cs.sfu.ca> References: <199706040832.KAA19266@mozart.ujf-grenoble.fr> <199706050002.RAA23955@alonzo.cs.sfu.ca> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi again & thanks! Concernant « Re: hidden composites », Melissa O'Neill écrit : > Generally, I've found that AFMs have more metric information than one > can extract (easily) from a PFA file, however. However, a quick look of course > at the available information seems to indicate that it might be doable > in this case. > > You'd need a tool like t1disasm to look at the relevent `seac' entries > in the CharStrings dictionary, then if you see: > > / { > hsbw > seac > } ND > > ...and, if you let: > = StandardEncoding[] > = StandardEncoding[] > = + - > = > > ... then you could try the following composite character entry in the AFM > file: > > CC 2 ; PCC 0 0 ; PCC ; > nice explaination, I hadn't recognise these computations! > It shouldn't be too hard to write a perl script to do this all automatically. > or maybe it's doable in postscript? > This formula was derived emperically, by comparing AFM files of fonts > I had with their corresponding disassembled CharStrings; I make no claims > about its general applicability. > it seems to be true for adobe 35 standard already. Thanks again 5-Jun-1997 14:00:13-GMT,1921;000000000000 Return-Path: <100.143869@germany.net> Received: from frankfurt. (frankfurt.germany.net [151.189.0.20]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id IAA19847 for ; Thu, 5 Jun 1997 08:00:02 -0600 (MDT) Received: from pp48 by frankfurt. (SMI-8.6/SMI-SVR4) id PAA21367; Thu, 5 Jun 1997 15:59:21 +0200 Message-ID: <3396F182.2244@germany.net> Date: Thu, 05 Jun 1997 13:04:02 -0400 From: Hilmar Schlegel <100.143869@germany.net> Reply-To: Hilmar Schlegel Organization: http://home.pages.de/~typo-pages/ X-Mailer: Mozilla 2.02E (OS/2; I) MIME-Version: 1.0 To: fontinst@cogs.susx.ac.uk, tex-font@csc-sun.math.utah.edu Subject: Re: hidden composites References: <199706050002.RAA23955@alonzo.cs.sfu.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Melissa O'Neill wrote: > I'd say the problem isn't the AFM, but the partial font downloader; it > should be doing a better job. (It might not even be that hard to fix > if you have the source.) Good suggestion - the source is avail for your attempts in this direction ;-) > Generally, I've found that AFMs have more metric information than one > can extract (easily) from a PFA file, however. Even more specifically, the tools for generating the complete (and exact) AFM are available for years meanwhile. But of course please feel free to reinvent the wheel... > However, a quick look > at the available information seems to indicate that it might be doable > in this case. Oh well - it is true! > Anyway, I hope this helps, I fear not too much - as long as getafm or similar code is not adjusted nothing will change. Hilmar Schlegel -- --------------------------------------------------------------- mailto:hshlgaii@mailszrz.zrz.TU-Berlin.DE?Subject=Mail response http://home.pages.de/~typo-pages/ --------------------------------------------------------------- 5-Jun-1997 18:00:13-GMT,3371;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id MAA25738 for ; Thu, 5 Jun 1997 12:00:13 -0600 (MDT) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id LAA11274; Thu, 5 Jun 1997 11:00:11 -0700 (PDT) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id LAA00140; Thu, 5 Jun 1997 11:00:09 -0700 (PDT) Message-Id: <199706051800.LAA00140@alonzo.cs.sfu.ca> Subject: Re: hidden composites To: Thierry.Bouche@ujf-grenoble.fr (Thierry Bouche) Date: Thu, 5 Jun 1997 11:00:08 -0700 (PDT) Cc: fontinst@cogs.susx.ac.uk, tex-font@csc-sun.math.utah.edu In-Reply-To: <199706051330.PAA19689@mozart.ujf-grenoble.fr> from "Thierry Bouche" at Jun 5, 97 03:30:56 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Thierry Bouche writes: > Hi again & thanks! > > nice explaination, I hadn't recognise these computations! > > maybe it's doable in postscript? Two difficulties for doing the computations in PostScript are that read access to the CharStrings dictionary of a font is usually forbidden, and one would have to decode the bytecodes that make up the CharSrings entries. There may be ways around this, but it is likely more trouble than its worth if you have t1disasm and perl handy. Hilmar Schlegel writes: > Good suggestion - the source [for the partial font downloader in > pdftex] is avail for your attempts in this direction ;-) I've already fixed bugs in the dvips partial font downloader, as some here know, so it's not so outlandish for me to suggest that this bug might be fixable. Currently, I don't use pdftex nor the troublesome fonts in question, so I have no burning personal need to fix the bug. > Even more specifically, the tools for generating the complete (and > exact) AFM are available for years meanwhile. But of course please feel > free to reinvent the wheel... I'm not aware of any tools that generate the same `CC' entries and the same kern pairs provided by the font vendor (which is the only ``correct'' AFM for a font). It is my understanding that kern pairs are usually hand tuned by the font designer, so I do not see how what you say can be true. Nevertheless, if you feel I am reinventing the wheel, do please tell us all of the utilities that are available that Thierry should be using to solve his problem. I wrote: >> Anyway, I hope this helps, ... and Hilmar Schlegel replied: > I fear not too much - as long as getafm or similar code is not adjusted > nothing will change. Thierry seemed very pleased, and he was the person I was trying to help. Getafm has nothing to do with this, as far as I can see. Thierry had the vendor's AFM file, which is more complete than anything getafm might produce -- especially since getafm lists no kern pairs and no composite character entries. Melissa. P.S. Having corresponded with Hilmar Schlegel once before and been hurt by what I found an arrogant and condescending attitude, and disappointed at what I saw as lack comprehension and insight, I will likely not respond to anything else he might say on this matter. 13-Jun-1997 11:55:02-GMT,2644;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id FAA17136 for ; Fri, 13 Jun 1997 05:55:01 -0600 (MDT) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.15) with ESMTP id HAA16900; Fri, 13 Jun 1997 07:54:40 -0400 (EDT) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id HAA09379; Fri, 13 Jun 1997 07:54:38 -0400 (EDT) Date: Fri, 13 Jun 1997 07:54:38 -0400 (EDT) Message-Id: <199706131154.HAA09379@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: Thierry.Bouche@ujf-grenoble.fr CC: fontinst@cogs.susx.ac.uk, tex-font@csc-sun.math.utah.edu In-reply-to: <199706040832.KAA19266@mozart.ujf-grenoble.fr> (message from Thierry Bouche on Wed, 4 Jun 1997 10:32:46 +0200 (MET DST)) Subject: Re: hidden composites Reply-to: bkph@ai.mit.edu hello, there exist some fonts (like Monotype baskerville or Lino didot) where the AFM declares true chars that are indeed composites built in the PFA by a seac construct. These may fool some partial font downloading software (downloading the PFA definition of egrave in mbvr8r willnot download the two outlines needed to print this char). An example being the current pdftex. Oops! Are you sure? This works in *some* partial font downloading schemes :-) As these PS fonts are usually used through fontinst's VFs, I think it would be more interesting to redeclare these chars as composites in the AFM, and do the composition inside the VF, which would solve this particular problem. Does anybody know how to add the composite section of the AFM when the only available info is the seac construct in the PFA? You can use PFAtoAFM and extract the Composites section of the AFM file (PFAtoAFM is in the Y&Y `Font Manipulation Package'). If you want to do it by hand then watch out for an error in the original Type 1 book which says that the offsets are with respect to the character origins when in fact they are with respect to the left side-bearing point (the Adobe site has both the Type 1 book in PDF form and the addendum). Any different reaction? Of course, a much better solution is to fix the partial font downloading you are using. As far as I can tell it wouldn't slow it down much more, since it already does more than one pass in order to prune out Subrs that are not used. Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 13-Jun-1997 12:25:01-GMT,2874;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id GAA17724 for ; Fri, 13 Jun 1997 06:24:58 -0600 (MDT) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.15) with ESMTP id IAA17145; Fri, 13 Jun 1997 08:08:31 -0400 (EDT) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA09403; Fri, 13 Jun 1997 08:08:30 -0400 (EDT) Date: Fri, 13 Jun 1997 08:08:30 -0400 (EDT) Message-Id: <199706131208.IAA09403@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: oneill@cs.sfu.ca CC: Thierry.Bouche@ujf-grenoble.fr, fontinst@cogs.susx.ac.uk, tex-font@csc-sun.math.utah.edu In-reply-to: <199706051800.LAA00140@alonzo.cs.sfu.ca> (oneill@cs.sfu.ca) Subject: Re: hidden composites Reply-to: bkph@ai.mit.edu Thierry Bouche writes: > Hi again & thanks! > nice explaination, I hadn't recognise these computations! > maybe it's doable in postscript? Hilmar Schlegel writes: > Even more specifically, the tools for generating the complete (and > exact) AFM are available for years meanwhile. But of course please feel > free to reinvent the wheel... I'm not aware of any tools that generate the same `CC' entries and the same kern pairs provided by the font vendor (which is the only ``correct'' AFM for a font). It is my understanding that kern pairs are usually hand tuned by the font designer, so I do not see how what you say can be true. PFAtoAFM will reproduce virtually everything in an AFM file including character bounding boxes even for unencoded characters. This includes the Composite character section. The PFB (or PFA) file does not contain kern pairs or kern tracking information, so that part is not available by this method. PFMtoAFM on the other hand will extract the kern pairs (and other information). PFAtoAFM can take output from PFMtoAFM as auxiliary input to create essentially a complete AFM file. Of course, all quality fonts should come with proper AFM files in the first place - so there should be no need to ever to any of this :-) Nevertheless, if you feel I am reinventing the wheel, do please tell us all of the utilities that are available that Thierry should be using to solve his problem. `Font Manipulation Package' see http://www.YandY.com P.S. Having corresponded with Hilmar Schlegel once before and been hurt by what I found an arrogant and condescending attitude, and disappointed at what I saw as lack comprehension and insight, I will likely not respond to anything else he might say on this matter. DISCLAIMER: respondent has connections with Y&Y. 13-Jun-1997 19:15:29-GMT,3222;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id NAA27622 for ; Fri, 13 Jun 1997 13:15:28 -0600 (MDT) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id MAA05736; Fri, 13 Jun 1997 12:15:25 -0700 (PDT) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id MAA25595; Fri, 13 Jun 1997 12:15:24 -0700 (PDT) Message-Id: <199706131915.MAA25595@alonzo.cs.sfu.ca> Subject: Re: hidden composites To: bkph@ai.mit.edu Date: Fri, 13 Jun 1997 12:15:23 -0700 (PDT) Cc: Thierry.Bouche@ujf-grenoble.fr, fontinst@cogs.susx.ac.uk, tex-fonts@csc-sun.math.utah.edu In-Reply-To: <199706131208.IAA09403@kauai.ai.mit.edu> from "Berthold K.P. Horn" at Jun 13, 97 08:08:30 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I wrote (thinking about extracting information from PFA/PFB files): >> I'm not aware of any tools that generate the same `CC' entries and the >> same kern pairs provided by the font vendor (which is the only ``correct'' >> AFM for a font). ... and Berthold K.P. Horn to replied, saying: > PFAtoAFM will reproduce virtually everything in an AFM file including > character bounding boxes even for unencoded characters. This includes the > Composite character section. The PFB (or PFA) file does not contain > kern pairs or kern tracking information, so that part is not available > by this method. > > PFMtoAFM on the other hand will extract the kern pairs (and other > information). PFAtoAFM can take output from PFMtoAFM as auxiliary > input to create essentially a complete AFM file. It's excellent that PFAtoAFM is smart enough to work out the CC entries; after all, the necessary information is right there in the font. I guess I should probably have been a little more specific in my original posting, and since I should really have added that I was taking about freely available tools, not commercial software. I'm sure if you use FontLab, Fontographer, etc. or somesuch, you can do all sorts of font manipulations that I wasn't considering. I've always wanted to use Y&Y's tools for font manipulation, since they seem very capable, but been held back by both their price and the fact that they seem to run only under DOS, which makes them utterly useless to me. Also, since Berthold brings up PFMs, I've been told for a long time that PFMs have almost all the information you'll find in an AFM but some things are missing, but never known exactly what (if I had to guess I'd probably go for the composite character entries). I'd be really interested if someone who knows could enlighten me, just for curiosity's sake. (Similarly, I've never really understood why Adobe introduced PFMs and MMM files when they had AFMs and AMFMs, it just seems to add needless complexity and incompatibility to font issues.) > Of course, all quality fonts should come with proper AFM files in the > first place - so there should be no need to ever to any of this :-) Absolutely! Melissa. 13-Jun-1997 19:57:05-GMT,2450;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id NAA28662 for ; Fri, 13 Jun 1997 13:57:02 -0600 (MDT) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.15) with ESMTP id PAA06437; Fri, 13 Jun 1997 15:56:46 -0400 (EDT) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id PAA09767; Fri, 13 Jun 1997 15:56:45 -0400 (EDT) Date: Fri, 13 Jun 1997 15:56:45 -0400 (EDT) Message-Id: <199706131956.PAA09767@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: oneill@cs.sfu.ca CC: Thierry.Bouche@ujf-grenoble.fr, fontinst@cogs.susx.ac.uk, tex-fonts@csc-sun.math.utah.edu In-reply-to: <199706131915.MAA25595@alonzo.cs.sfu.ca> (oneill@cs.sfu.ca) Subject: Re: hidden composites Reply-to: bkph@ai.mit.edu I wrote (thinking about extracting information from PFA/PFB files): Also, since Berthold brings up PFMs, I've been told for a long time that PFMs have almost all the information you'll find in an AFM but some things are missing, but never known exactly what (if I had to guess I'd probably go for the composite character entries). I'd be really interested if someone who knows could enlighten me, just for curiosity's sake. PFM's are rather anaemic. They do not contain character bounding boxes. They contain no information on unencoded characters. They do not have the font encoding. Some of these flaws are shared with TFM files. (Similarly, I've never really understood why Adobe introduced PFMs and MMM files when they had AFMs and AMFMs, it just seems to add needless complexity and incompatibility to font issues.) For the same reason TeX uses TFM's rather than say PL's: speed and compactness. For many fonts the AFM file is almost as large as the actual font itself in PFB format and takes a long time to parse. I don't know what platform you are on, but if you are on a Mac then you have another weirdness, which is the `screen font' suitcase the only real use of which is the FOND resource that contains the font's metrics - quite like the PFM file. As for AMFM's, I have never seen one and am beginning to doubt whether they really exist. I always make AFM or TFM files for my Multiple Master instances directly from the installed font. Berthold 13-Jun-1997 20:41:31-GMT,3279;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id OAA29748 for ; Fri, 13 Jun 1997 14:41:28 -0600 (MDT) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id NAA10381; Fri, 13 Jun 1997 13:41:25 -0700 (PDT) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id NAA25752; Fri, 13 Jun 1997 13:41:23 -0700 (PDT) Message-Id: <199706132041.NAA25752@alonzo.cs.sfu.ca> Subject: Re: hidden composites To: bkph@ai.mit.edu Date: Fri, 13 Jun 1997 13:41:23 -0700 (PDT) Cc: oneill@cs.sfu.ca, Thierry.Bouche@ujf-grenoble.fr, fontinst@cogs.susx.ac.uk, tex-fonts@csc-sun.math.utah.edu In-Reply-To: <199706131956.PAA09767@kauai.ai.mit.edu> from "Berthold K.P. Horn" at Jun 13, 97 03:56:45 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I said: >> I've been told for a long time that PFMs have almost all the information >> you'll find in an AFM but some things are missing, but never known >> exactly what. ... and Berthold K.P. Horn replied, saying: > PFM's are rather anaemic. They do not contain character bounding > boxes. They contain no information on unencoded characters. They do > not have the font encoding. Eww... I also said: >> Similarly, I've never really understood why Adobe introduced PFMs >> and MMM files when they had AFMs and AMFMs, it just seems to add >> needless complexity and incompatibility to font issues. ... and Berthold replied: > For the same reason TeX uses TFM's rather than say PL's: speed and > compactness. For many fonts the AFM file is almost as large as the > actual font itself in PFB format and takes a long time to parse. > I don't know what platform you are on, but if you are on a Mac then you > have another weirdness, which is the `screen font' suitcase the only real > use of which is the FOND resource that contains the font's metrics - > quite like the PFM file. > > As for AMFM's, I have never seen one and am beginning to doubt whether > they really exist. I always make AFM or TFM files for my Multiple > Master instances directly from the installed font. Well, still I don't think it was such a good strategy. My AFMs seem to average about 25% of the size of my PFA files, which I'm fine with, compared to the other sources of bloat you find in computer systems -- especially since people doing serious work using fonts may find that their software needs the AFMs anyway, meaning they get the bloat of having AFMs and PFMs or AFMs and Font Suitcases. I use NEXTSTEP, which uses AFMs directly, although it caches the information from parsing the AFMs for better performance. Whether NEXTSTEP's successor, Rhapsody will do the same remains to be seen; maybe by that time OpenType will have fixed everything. I have AMFMs (and the sets of design AFMs needed) for Nueva and Tekton, my two Multiple Master fonts, so I can vouch for their reality. Getting AMFMs for Nueva required a contact in Adobe. It certainly looks like Adobe doesn't want to bother with them any more. Best Regards, Melissa. 14-Jun-1997 9:58:30-GMT,3643;000000000000 Return-Path: <100.143869@germany.net> Received: from elara.germany.net (elara.germany.net [151.189.0.18]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id DAA15288 for ; Sat, 14 Jun 1997 03:58:23 -0600 (MDT) Received: from pp52 (pp42.berlin2m.germany.net [192.168.24.42]) by elara.germany.net (8.7.6/8.7.3) with SMTP id LAA20598; Sat, 14 Jun 1997 11:57:12 +0200 Message-ID: <33A218E3.60F5@germany.net> Date: Sat, 14 Jun 1997 00:06:59 -0400 From: Hilmar Schlegel <100.143869@germany.net> Reply-To: Hilmar Schlegel Organization: http://home.pages.de/~typo-pages/ X-Mailer: Mozilla 2.02E (OS/2; I) MIME-Version: 1.0 To: bkph@ai.mit.edu CC: fontinst@cogs.susx.ac.uk, tex-font@csc-sun.math.utah.edu Subject: Re: hidden composites References: <199706131956.PAA09767@kauai.ai.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Berthold K.P. Horn wrote: > I wrote (thinking about extracting information from PFA/PFB files): .. > probably go for the composite character entries). I'd be really interested > if someone who knows could enlighten me, just for curiosity's sake. > > PFM's are rather anaemic. They do not contain character bounding boxes. > They contain no information on unencoded characters. They do not have Which means kerns for unencoded characters are definitively lost... (Examples are fi, fl on a PC) > (Similarly, I've never really understood why Adobe introduced PFMs and > MMM files when they had AFMs and AMFMs, it just seems to add needless > complexity and incompatibility to font issues.) > > For the same reason TeX uses TFM's rather than say PL's: speed and > compactness. For many fonts the AFM file is almost as large as the ... and for some half-hearted interface to make life easier for M$-Win: store win face names and little confused attribute bits ;-) The essential message would be here that PFM's do not contain the height of the individual characters in a font, which means that M$-win *cannot* access character heights and consequently uses the *font* bounding box as an ersatz. Given that is true *no* software getting metric information only from the M$-win "fontsystem" and not directly from the fonts (AFM or PFB) will be able to produce reasonable typography. (Most people will know the line-spacing problems in M$-word - when a font which has only a single "large" character comes into play). Simply a design fault ;-) Another version are OFM-files: That's what Os/2 uses to compile from AFM-files. I'd be curious if there is a specification available somewhere. Especially interesting would be the question of completeness also for this case. > As for AMFM's, I have never seen one and am beginning to doubt whether > they really exist. They exist! The news is that with the level 4 ATM-compatible mutiple masters you will need besides the AFMs also access to the PFB itself for blending (at least in the general case). That means that from this point the metric files no longer contain the *complete* metric information of a font. > I always make AFM or TFM files for my Multiple > Master instances directly from the installed font. Berthold, there is a little problem with that, however! This method doesn't work for the composites in multiple master fonts (in contrast to PFAtoAFM) - or do I miss here something? Hilmar Schlegel -- --------------------------------------------------------------- mailto:hshlgaii@mailszrz.zrz.TU-Berlin.DE?Subject=Mail response http://home.pages.de/~typo-pages/ --------------------------------------------------------------- 16-Jun-1997 9:55:41-GMT,1737;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id DAA08437 for ; Mon, 16 Jun 1997 03:55:26 -0600 (MDT) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id LAA17050; Mon, 16 Jun 1997 11:55:20 +0200 (MET DST) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id MAA18160; Mon, 16 Jun 1997 12:00:17 +0200 (MET DST) Date: Mon, 16 Jun 1997 12:00:17 +0200 (MET DST) Message-Id: <199706161000.MAA18160@mozart.ujf-grenoble.fr> From: Thierry Bouche To: "Melissa O'Neill" CC: tex-fonts@csc-sun.math.utah.edu Subject: Re: hidden composites In-Reply-To: <199706132041.NAA25752@alonzo.cs.sfu.ca> References: <199706131956.PAA09767@kauai.ai.mit.edu> <199706132041.NAA25752@alonzo.cs.sfu.ca> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: hidden composites », Melissa O'Neill écrit : > I have AMFMs (and the sets of design AFMs needed) for Nueva and Tekton, > my two Multiple Master fonts, so I can vouch for their reality. Getting > AMFMs for Nueva required a contact in Adobe. It certainly looks like > Adobe doesn't want to bother with them any more. > do you mean that they don't even consider people willing to use MM fonts without acces to some flavour of ATM? It's a shame! Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 16-Jun-1997 18:05:00-GMT,1868;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id MAA19233 for ; Mon, 16 Jun 1997 12:04:59 -0600 (MDT) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id LAA07137; Mon, 16 Jun 1997 11:04:46 -0700 (PDT) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id LAA14838; Mon, 16 Jun 1997 11:04:45 -0700 (PDT) Message-Id: <199706161804.LAA14838@alonzo.cs.sfu.ca> Subject: Re: hidden composites To: Thierry.Bouche@ujf-grenoble.fr (Thierry Bouche) Date: Mon, 16 Jun 1997 11:04:44 -0700 (PDT) Cc: tex-fonts@csc-sun.math.utah.edu In-Reply-To: <199706161000.MAA18160@mozart.ujf-grenoble.fr> from "Thierry Bouche" at Jun 16, 97 12:00:17 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I wrote: >> I have AMFMs (and the sets of design AFMs needed) for Nueva and Tekton, >> my two Multiple Master fonts, so I can vouch for their reality. Getting >> AMFMs for Nueva required a contact in Adobe. It certainly looks like >> Adobe doesn't want to bother with them any more. ... and Thierry Bouche replied: > do you mean that they don't even consider people willing to use MM > fonts without acces to some flavour of ATM? That's about the size of it. The platforms without ATM are a tiny percentage of Adobe's business, so it's little surprise if support is inaqequate for those platforms. Chris, from Adobe Technical Support told me: < You are correct; our ftp site does not include all AFM files. We are no < longer updating that list, as we get very few requests for AFM files. < Most applications no longer need them. *sigh* Melissa. 18-Jun-1997 14:03:11-GMT,3406;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id IAA19599 for ; Wed, 18 Jun 1997 08:03:10 -0600 (MDT) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.15) with ESMTP id JAA12658; Wed, 18 Jun 1997 09:57:19 -0400 (EDT) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id JAA11360; Wed, 18 Jun 1997 09:57:16 -0400 (EDT) Date: Wed, 18 Jun 1997 09:57:16 -0400 (EDT) Message-Id: <199706181357.JAA11360@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: hshlgaii@mailszrz.zrz.tu-berlin.de CC: fontinst@cogs.susx.ac.uk, tex-font@csc-sun.math.utah.edu In-reply-to: <33A218E3.60F5@germany.net> (message from Hilmar Schlegel on Sat, 14 Jun 1997 00:06:59 -0400) Subject: Re: hidden composites Reply-to: bkph@ai.mit.edu Reply-To: Hilmar Schlegel > I wrote (thinking about extracting information from PFA/PFB files): .. > probably go for the composite character entries). I'd be really interested > if someone who knows could enlighten me, just for curiosity's sake. > PFM's are rather anaemic. They do not contain character bounding boxes. > They contain no information on unencoded characters. They do not have Which means kerns for unencoded characters are definitively lost... (Examples are fi, fl on a PC) Yes. Which is one of the reasons having the actual AFM file is better. Not that any AFM files I have sen have any kern pairs with fi and fl... > (Similarly, I've never really understood why Adobe introduced PFMs and > MMM files when they had AFMs and AMFMs, it just seems to add needless > complexity and incompatibility to font issues.) > For the same reason TeX uses TFM's rather than say PL's: speed and > compactness. For many fonts the AFM file is almost as large as the and for some half-hearted interface to make life easier for M$-Win: store win face names and little confused attribute bits ;-) The essential message would be here that PFM's do not contain the height of the individual characters in a font, which means that M$-win *cannot* access character heights and consequently uses the *font* bounding box as an ersatz. Given that is true *no* software getting metric information only from the M$-win "fontsystem" and not directly from the fonts (AFM or PFB) will be able to produce reasonable typography. (Most people will know the line-spacing problems in M$-word - when a font which has only a single "large" character comes into play). Simply a design fault ;-) Yes, if you only use the information in the font metric file you will not have enough for TeX. Which is why you either need the AFM, or PFAtoAFM or DVIWindo to extract this information for you. The information *IS* available to a Windows program - even for unencoded characters. > I always make AFM or TFM files for my Multiple > Master instances directly from the installed font. Berthold, there is a little problem with that, however! This method doesn't work for the composites in multiple master fonts (in contrast to PFAtoAFM) - or do I miss here something? Not sure why you say that? Regards, Berthold. 18-Jun-1997 14:37:29-GMT,2271;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id IAA20394 for ; Wed, 18 Jun 1997 08:37:28 -0600 (MDT) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.15) with ESMTP id KAA14304; Wed, 18 Jun 1997 10:37:21 -0400 (EDT) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA11389; Wed, 18 Jun 1997 10:37:20 -0400 (EDT) Date: Wed, 18 Jun 1997 10:37:20 -0400 (EDT) Message-Id: <199706181437.KAA11389@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: oneill@cs.sfu.ca CC: Thierry.Bouche@ujf-grenoble.fr, tex-fonts@csc-sun.math.utah.edu In-reply-to: <199706161804.LAA14838@alonzo.cs.sfu.ca> (oneill@cs.sfu.ca) Subject: Re: hidden composites Reply-to: bkph@ai.mit.edu Hi: I wrote: >> I have AMFMs (and the sets of design AFMs needed) for Nueva and Tekton, >> my two Multiple Master fonts, so I can vouch for their reality. Getting >> AMFMs for Nueva required a contact in Adobe. It certainly looks like >> Adobe doesn't want to bother with them any more. ... and Thierry Bouche replied: > do you mean that they don't even consider people willing to use MM > fonts without acces to some flavour of ATM? That's about the size of it. The platforms without ATM are a tiny percentage of Adobe's business, so it's little surprise if support is inaqequate for those platforms. Chris, from Adobe Technical Support told me: < You are correct; our ftp site does not include all AFM files. We are no < longer updating that list, as we get very few requests for AFM files. < Most applications no longer need them. *sigh* Melissa. The AFM files for Adobe fonts are most conveniently found on the `Type on Call' (TOC 4.1) CD-ROM (which is also the most convenient way of buying there fonts - in fact its hard to get some packages on diskette now). You have to grovel around to find them though since they are `hidden' files and arganized in sub-directories based on the font package number or first letter (I forget which) regards, berthold. 18-Jun-1997 16:16:47-GMT,1543;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id KAA22811 for ; Wed, 18 Jun 1997 10:16:47 -0600 (MDT) Received: from alonzo.cs.sfu.ca (oneill@alonzo [199.60.3.17]) by cs.sfu.ca (8.8.5/8.8.5) with ESMTP id JAA05690; Wed, 18 Jun 1997 09:16:45 -0700 (PDT) From: "Melissa O'Neill" Received: (oneill@localhost) by alonzo.cs.sfu.ca (8.7.6/8.6.12) id JAA28444; Wed, 18 Jun 1997 09:16:44 -0700 (PDT) Message-Id: <199706181616.JAA28444@alonzo.cs.sfu.ca> Subject: Re: hidden composites To: bkph@ai.mit.edu Date: Wed, 18 Jun 1997 09:16:44 -0700 (PDT) Cc: tex-fonts@csc-sun.math.utah.edu In-Reply-To: <199706181437.KAA11389@kauai.ai.mit.edu> from "Berthold K.P. Horn" at Jun 18, 97 10:37:20 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Berthold writes: > The AFM files for Adobe fonts are most conveniently found on the > `Type on Call' (TOC 4.1) CD-ROM (which is also the most convenient > way of buying there fonts - in fact its hard to get some packages > on diskette now). You have to grovel around to find them though > since they are `hidden' files and arganized in sub-directories > based on the font package number or first letter (I forget which) Unless it happens to be a multiple-master font, where you get a big fat zero on the TOC CD. (Well, you do get an MMM file, but Adobe refuses to document those.) Melissa. 4-Jul-1997 7:51:52-GMT,769;000000000000 Return-Path: Received: from mail.u-net.net (mail.u-net.net [194.119.128.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id BAA20459 for ; Fri, 4 Jul 1997 01:51:50 -0600 (MDT) Received: from [194.119.133.151] ([194.119.133.151]) by mail.u-net.net with ESMTP id <30175-14244>; Fri, 4 Jul 1997 08:45:47 +0100 X-Sender: rebecca-astrid@mail.u-net.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 4 Jul 1997 05:37:12 +0100 To: tex-fonts@csc-sun.math.utah.edu From: Rebecca and Rowland Subject: How to join? Hello, Can you send me details of how to join the tex-fonts mailing list please? Rowland. 10-Jul-1997 14:22:26-GMT,3994;000000000000 Return-Path: Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id IAA15448; Thu, 10 Jul 1997 08:22:26 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id IAA29195; Thu, 10 Jul 1997 08:22:24 -0600 (MDT) Date: Thu, 10 Jul 1997 08:22:24 -0600 (MDT) To: tex-fonts@csc-sun.math.utah.edu Cc: beebe@csc-sun.math.utah.edu X-US-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: TrueType to BDF converter available Message-ID: Folks, this posting about a TrueType to BDF converter may be of some interest to you. I have found relatively little software available for dealing with TrueType fonts. Since this code is based on the FreeType TT renderer, perhaps one of you will be able to adapt it to produce TeX GF or PK fonts. --------------- Received: from mail-out1.apple.com (A17-254-0-52.apple.com [17.254.0.52]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id WAA05091 for ; Wed, 9 Jul 1997 22:54:25 -0600 (MDT) Received: from unicode.org (unicode2.apple.com [17.254.3.212]) by mail-out1.apple.com (8.8.5/8.8.5) with SMTP id VAA41010; Wed, 9 Jul 1997 21:51:28 -0700 Received: by unicode.org (NX5.67g/NX3.0S) id AA01523; Wed, 9 Jul 97 21:46:33 -0700 Message-Id: <9707100446.AA01523@unicode.org> Errors-To: uni-bounce@unicode.org X-Uml-Sequence: 3174 (1997-07-10 04:46:29 GMT) To: Multiple Recipients of Reply-To: Mark Leisher From: "Unicode Discussion" Date: Wed, 9 Jul 1997 21:46:27 -0700 (PDT) Subject: TrueType to BDF converter available For those of you doing font work (Unicode or otherwise) for Unix, I just put together a TT->BDF converter based on the FreeType TT renderer. The source code is now part of the FreeType distribution which is available from: ftp://ftp.physiol.med.tu-muenchen.de/pub/freetype/devel/freetype-current.tar.gz I have pre-built binaries available from: [Binaries: Linux, Solaris, SunOS] ftp://crl.nmsu.edu/CLR/multiling/General/ttf2bdf-1.0-ELF.tar.gz ftp://crl.nmsu.edu/CLR/multiling/General/ttf2bdf-1.0-SOLARIS.tar.gz ftp://crl.nmsu.edu/CLR/multiling/General/ttf2bdf-1.0-SUNOS.tar.gz The resulting BDF fonts still have a few minor problems (to be fixed in later ttf2bdf versions), but loading them into the XmBDFEditor and saving them will automatically fix those problems. The XmBDFEditor is available in source and binary form in the same directory as the ttf2bdf binaries. For those interested in this sort of thing, I would like to mention that the FreeType renderer will soon be available as an additional renderer for X11R6 and it's font server. I'll be announcing the release on comp.fonts and comp.windows.x near the end of this month after a testing period. ----------------------------------------------------------------------------- mleisher@crl.nmsu.edu Mark Leisher "A designer knows he has achieved perfection Computing Research Lab not when there is nothing left to add, but New Mexico State University when there is nothing left to take away." Box 30001, Dept. 3CRL -- Antoine de Saint-Exup éry Las Cruces, NM 88003 ======================================================================== 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 URL: http://www.math.utah.edu/~beebe Salt Lake City, UT 84112, USA ======================================================================== 10-Jul-1997 23:40:02-GMT,1345;000000000000 Return-Path: Received: from www.nsysu.edu.tw (www.nsysu.edu.tw [140.117.11.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id RAA28941; Thu, 10 Jul 1997 17:39:57 -0600 (MDT) Received: from localhost (werner@localhost) by www.nsysu.edu.tw (8.8.6/8.8.6) with SMTP id HAA19093; Fri, 11 Jul 1997 07:39:45 +0800 (CST) Date: Fri, 11 Jul 1997 07:39:45 +0800 (CST) From: Werner Lemberg Reply-To: Werner Lemberg To: "Nelson H. F. Beebe" cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: TrueType to BDF converter available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 10 Jul 1997, Nelson H. F. Beebe wrote: > Folks, this posting about a TrueType to BDF converter may > be of some interest to you. I have found relatively little > software available for dealing with TrueType fonts. Since > this code is based on the FreeType TT renderer, perhaps one > of you will be able to adapt it to produce TeX GF or PK fonts. Well, I'll do this in the near future. I have already written a ttf2pk converter for CJK fonts, and I plan to update it to FreeType soon. Werner 11-Jul-1997 10:17:30-GMT,1577;000000000000 Return-Path: Received: from hermes.hrz.uni-giessen.de (hermes.hrz.uni-giessen.de [134.176.2.15]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id EAA11884 for ; Fri, 11 Jul 1997 04:17:28 -0600 (MDT) Received: from d3.hrz.uni-giessen.de by hermes.hrz.uni-giessen.de; Fri, 11 Jul 1997 12:17:19 +0200 Received: from localhost by d3.hrz.uni-giessen.de (AIX 3.2/UCB 5.64/4.03 JLUG d3 U437398) id AA16999; Fri, 11 Jul 1997 12:17:18 +0200 Date: Fri, 11 Jul 1997 12:17:17 +0200 (CET) From: Jan P Glaescher X-Sender: g61011@d3.hrz.uni-giessen.de To: tex-fonts@csc-sun.math.utah.edu Subject: sites for downloading afm-files Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi psfonts experts, I noticed in the `README=B4 of `fontname=B4 that you are one of the maintainers of this naming scheme. Since there are fontname lists of the Digital Typeface Corporation and Bitstream included, I thought that you might know a web of ftp site where I can download the matching afm-files for my psfonts of these two companies, which I unfortunately only have in the *.pfb and *.pfm format. I would really appreciate _any_ hints on this question --- even the home site of the Digital Typeface Corporation would help since the common search engines were not able to find this site on the web. Thanks for any hints in advance, Jan=20 11-Jul-1997 13:50:51-GMT,2613;000000000000 Return-Path: Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id HAA15948; Fri, 11 Jul 1997 07:50:51 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id HAA05817; Fri, 11 Jul 1997 07:50:50 -0600 (MDT) Date: Fri, 11 Jul 1997 07:50:50 -0600 (MDT) To: Jan P Glaescher Cc: beebe@csc-sun.math.utah.edu, tex-fonts@csc-sun.math.utah.edu X-US-Mail: "Center for Scientific Computing, University of Utah, Salt Lake City, UT 84112, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: sites for downloading afm-files In-Reply-To: Your message of Fri, 11 Jul 1997 12:17:17 +0200 (CET) Message-ID: Jan P Glaescher writes today: >> I thought that you might know a web of ftp site where >> I can download the matching afm-files for my psfonts of these >> two companies, [Digital Typeface Corporation and Bitstream] >> which I unfortunately only have in the *.pfb and *.pfm format. I don't believe that we can do that legally. Unlike Adobe's AFM files, which just begin Comment Copyright (c) 1989 Adobe Systems Incorporated. All rights reserved. and which Adobe makes freely available on their Web server, and on the Type-on-Call CD-ROMs, Bitstream is more restrictive: Comment Copyright 1987-1992 as an unpublished work by Bitstream Inc., Cambridge, MA. Comment All rights reserved Comment Confidential and proprietary to Bitstream Inc. Comment Bitstream is a registered trademark of Bitstream Inc. ... Notice Copyright 1987-1992 as an unpublished work by Bitstream Inc. All rights reserved. Confidential. However, Bitstream fonts are priced exceedingly reasonably, and they offer 500+ fonts on a CD-ROM. Details, and addresses, can be found at http://www.math.utah.edu/~beebe/fonts/bitstream.html I have no information at present about fonts from Digital Typeface Corporation. ======================================================================== 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 URL: http://www.math.utah.edu/~beebe Salt Lake City, UT 84112, USA ======================================================================== 11-Jul-1997 15:20:19-GMT,1267;000000000000 Return-Path: Received: from cs.umb.edu (root@cs.umb.edu [158.121.104.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id JAA18093 for ; Fri, 11 Jul 1997 09:20:18 -0600 (MDT) Received: from u1.cs.umb.edu by cs.umb.edu with SMTP id AA19163 (5.65c/IDA-1.4.4 for tex-fonts@math.utah.edu); Fri, 11 Jul 1997 11:20:09 -0400 From: "K. Berry" Received: (from kb@localhost) by u1.cs.umb.edu (8.8.0/8.8.0) id LAA24185; Fri, 11 Jul 1997 11:20:12 -0400 (EDT) Date: Fri, 11 Jul 1997 11:20:12 -0400 (EDT) Message-Id: <199707111520.LAA24185@u1.cs.umb.edu> To: Jan.P.Glaescher@psychol.uni-giessen.de Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: sites for downloading afm-files fontname lists of the Digital Typeface Corporation and Bitstream included, I thought that you might know a web of ftp site where Sorry, I wrote all the information I had in those files. I can download the matching afm-files for my psfonts of these two companies, which I unfortunately only have in the *.pfb and *.pfm format. I think there are programs that are able to generate afm files from pfb and/or pfm, but unfortunately I don't have any specific pointers. Maybe someone else on this list can help more. 11-Jul-1997 20:43:41-GMT,1891;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id OAA26127 for ; Fri, 11 Jul 1997 14:43:40 -0600 (MDT) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.7.6/8.6.9) with ESMTP id WAA01602; Fri, 11 Jul 1997 22:43:36 +0200 (MET DST) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id WAA16767; Fri, 11 Jul 1997 22:51:54 +0200 (MET DST) Date: Fri, 11 Jul 1997 22:51:54 +0200 (MET DST) Message-Id: <199707112051.WAA16767@mozart.ujf-grenoble.fr> From: Thierry Bouche To: "K. Berry" Cc: Jan.P.Glaescher@psychol.uni-giessen.de, tex-fonts@csc-sun.math.utah.edu Subject: Re: sites for downloading afm-files In-Reply-To: <199707111520.LAA24185@u1.cs.umb.edu> References: <199707111520.LAA24185@u1.cs.umb.edu> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: sites for downloading afm-files », K. Berry écrit : > I think there are programs that are able to generate afm files from pfb > and/or pfm, but unfortunately I don't have any specific pointers. > Maybe someone else on this list can help more. > under dos &/or unix, you have getmetric that does a very good job (found on ctan in the archive t1tools (or t1utils?) someone told me too that there exist some tools from y&y that do this kind of things. The usual disclaimer is that when you buy your fonts, you should be able to ask for the afm (or it should be automatically supplied). best wishes Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 18-Jul-1997 21:34:00-GMT,3832;000000000000 Return-Path: Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id PAA24039 for ; Fri, 18 Jul 1997 15:34:00 -0600 (MDT) Received: (mackay@localhost) by june.cs.washington.edu (8.8.5+CS/7.2ju) id OAA02295; Fri, 18 Jul 1997 14:33:53 -0700 Date: Fri, 18 Jul 1997 14:33:53 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Message-Id: <199707182133.OAA02295@june.cs.washington.edu> To: info-tex@shsu.edu, tex-fonts@csc-sun.math.utah.edu, cthiele@ccs.carleton.ca, mackay@cs.washington.edu Subject: Ibycus4, an upgrade of the Ibygrk Greek package The Ibycus4 package (the name is a intended as a tribute to David Packard's Ibycus system, but this package has no connection with any work done by the Packard Humanities Institute) is available on osman.classics.washington.edu [128.95.170.63] in ~ftp/pub/tex, in 4 forms. 1. iby4str is a streamed SVR4 (Solaris) package, ready for installation 2, iby4str.gz is the same thing gzipped. There doesn't seem to be any way to zcat such a file and pipe it into pkgadd. gunzip has to be used as a separate operation/ 3. ibycus4.tar.gz is a SVR4 (Solaris) package in spool directory format if untarred into the directory /var/spool/pkg it is ready for pkgadd 4. ibycus4.zip is for non-Unix sites. It includes all the genuine files of Ibycus4 in an 8+3 TDS-conformant style, but not the symbolic links that make life pleasanter in the Unix world. Changes in setwidths have been made, so spacing will be a bit different (and better, I hope). Some small improvements in input coding are made (the 4 distinguishes the new input coding from the old 3 coding). For other details see the README file. Here is the relevant extract from the README file. Ibycus3 is what was previously known as ibygrk. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% NOTE: THE FOLLOWING CODINGS ARE NOT COMPATIBLE WITH IBYCUS3 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% I have tried to keep incompatible codings to the minimum but the ibycus3 versions of the following were extremely undesirable. These are all simplifications of ibycus3 coding. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The mark of elision is ' or {'} (the form in braces may be needed to prevent ' from being read as an accent). Single quotes may be provided by ` {`} and ' {'}, (isolate them in braces if necessary). Double quotes are `` {``} and '' {''} (isolate in braces if necessary). < and > are the angle brackets used for conjectural supplements. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The prefix in Karl Berry's font-naming scheme is "fib". The full naming scheme is provided in the README file. -- %=======================================================================% | N O T I C E | | Please note the changes in address and telephone number below. | | There is no Northwest Computing Support Center any longer. | | Until further notice, I shall be continuing to provide tape | | distributions and whatever other services I can. | | | %=======================================================================% Email concerned with UnixTeX distribution software may be sent To: mackay@cs.washington.edu Pierre A. MacKay Smail: Department of Classics Emeritus Druid for Denny Hall, Mail Stop DH-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-2268 (Message recorder) 22-Jul-1997 0:17:21-GMT,1582;000000000000 Return-Path: Received: from hubert.wustl.edu (ats@eliot226.wuh.wustl.edu [128.252.105.226]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id SAA02794 for ; Mon, 21 Jul 1997 18:17:20 -0600 (MDT) Received: (from ats@localhost) by hubert.wustl.edu (8.8.5/8.8.5) id TAA26730; Mon, 21 Jul 1997 19:17:19 -0500 To: tex-fonts@csc-sun.math.utah.edu Subject: Complete Spectrum font support? Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: Alan Shutko Date: 21 Jul 1997 19:17:19 -0500 Message-ID: Lines: 23 I just purchased the SpectrumMT fonts from Adobe and noticed that I have a more complete set than is available in ctan/fonts/psfonts. I have the complete set listed in monotype.map: msmr8r SpectrumMT MSpectrum msmr8x SpectrumMT-Expert msmrc8r SpectrumMT-SC msmri7d SpectrumMT-ItalicOsF msmri8r SpectrumMT-Italic MSpectrum-Italic msmri8x SpectrumMT-ItalicExpert msms7d SpectrumMT-SemiBoldOsF msms8r SpectrumMT-SemiBold MSpectrum-SemiBold msms8x SpectrumMT-SemiBoldExpert Tried to install them on teTeX with those names and found that th bundled fontinst didn't use them. Could someone tell me how to create TeX font files for these fonts (including the hacked fontinst in the ctan/fonts/psfonts/tools dir, if needed) and distribute them so that others need not face the same frustration? -- Alan Shutko - By consent of the corrupted All my friends and I are crazy. That's the only thing that keeps us sane. 22-Jul-1997 0:45:49-GMT,2620;000000000000 Return-Path: Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.1.4]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id SAA03549 for ; Mon, 21 Jul 1997 18:45:48 -0600 (MDT) Received: (mackay@localhost) by june.cs.washington.edu (8.8.5+CS/7.2ju) id RAA29304; Mon, 21 Jul 1997 17:45:42 -0700 Date: Mon, 21 Jul 1997 17:45:42 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Message-Id: <199707220045.RAA29304@june.cs.washington.edu> To: info-tex@shsu.edu, tex-fonts@csc-sun.math.utah.edu, cthiele@ccs.carleton.ca, mackay@cs.washington.edu In-reply-to: <199707182133.OAA02295@june.cs.washington.edu> (mackay@cs.washington.edu) Subject: levygrk--Silvio Levy's source as a SVR4 package. Because they may be need for font generation in Ibycus4, I have reshaped Silvio Levy's source files into a package. I have changed nothing in these files, which come from a 1994 archive on CTAN. Only the arrangement into a package is new. A couple of *.tex filenames had to be massaged into 8+3 limits for the Intel world. Symbolic links attach them to their original names. 1. levystr is a streamed SVR4 (Solaris) package, ready for installation 2, levystr.gz is the same thing gzipped. There doesn't seem to be any way to zcat such a file and pipe it into pkgadd. gunzip has to be used as a separate operation. 3. levygrk.tar.gz is a SVR4 (Solaris) package in spool directory format. If untarred into the directory /var/spool/pkg it is ready for pkgadd 4. levygrk.zip is for non-Unix sites. It includes all the genuine files of levygrk in an 8+3 TDS-conformant style, but not the symbolic links that make life pleasanter in the Unix world. -- %=======================================================================% | N O T I C E | | Please note the changes in address and telephone number below. | | There is no Northwest Computing Support Center any longer. | | Until further notice, I shall be continuing to provide tape | | distributions and whatever other services I can. | | | %=======================================================================% Email concerned with UnixTeX distribution software may be sent To: mackay@cs.washington.edu Pierre A. MacKay Smail: Department of Classics Emeritus Druid for Denny Hall, Mail Stop DH-10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-2268 (Message recorder) 25-Jul-1997 14:28:02-GMT,2712;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id IAA11301 for ; Fri, 25 Jul 1997 08:28:02 -0600 (MDT) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.15) with ESMTP id KAA25657; Fri, 25 Jul 1997 10:27:55 -0400 (EDT) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id KAA25125; Fri, 25 Jul 1997 10:27:54 -0400 (EDT) Date: Fri, 25 Jul 1997 10:27:54 -0400 (EDT) Message-Id: <199707251427.KAA25125@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: Jan.P.Glaescher@psychol.uni-giessen.de In-reply-to: (message from Jan P Glaescher on Fri, 11 Jul 1997 12:17:17 +0200 (CET)) cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: sites for downloading afm-files Reply-to: bkph@ai.mit.edu Date: Fri, 11 Jul 1997 12:17:17 +0200 (CET) From: Jan P Glaescher X-Sender: g61011@d3.hrz.uni-giessen.de Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by life.ai.mit.edu id GAA07430 Hi psfonts experts, I noticed in the `README´ of `fontname´ that you are one of the maintainers of this naming scheme. Since there are fontname lists of the Digital Typeface Corporation and Bitstream included, I thought that you might know a web of ftp site where I can download the matching afm-files for my psfonts of these two companies, which I unfortunately only have in the *.pfb and *.pfm format. I would really appreciate _any_ hints on this question --- even the home site of the Digital Typeface Corporation would help since the common search engines were not able to find this site on the web. Thanks for any hints in advance, Jan AFAIK, DTC is out of business. AFAI remember they made low grade rip-offs of mostly BitStream fonts, which themselves may be of dubious heritage, according to some ("We did contact the designers and offered to pay them royalties, but they wanted too much..."). Why to you need the AFMs? If you just need TFMs you may be able to generate these in your TeX system after installing the fonts using ATM. Perhaps you can use Y&Y's Font Manipulation Package. It includes PFAtoAFM and PFMtoAFM, which together construct as complete and accurate an AFM file as you can get if you don't have the original. Regards, Berthold. DISCLAIMER: I have connections with http://www.YandY.com 4-Aug-1997 8:16:17-GMT,1514;000000000000 Return-Path: Received: from ixgate02.dfnrelay.d400.de (ixgate02.dfnrelay.d400.de [193.174.248.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id CAA01229 for ; Mon, 4 Aug 1997 02:16:11 -0600 (MDT) X400-Received: by mta d400relay in /PRMD=dfnrelay/ADMD=d400/C=de/; Relayed; Mon, 4 Aug 1997 10:15:34 +0200 X400-Received: by /PRMD=UNI-SIEGEN/ADMD=D400/C=DE/; converted (ia5-text); Relayed; Mon, 4 Aug 1997 11:11:37 +0200 Date: Mon, 4 Aug 1997 11:11:37 +0200 X400-Originator: FLIESSBACH@PHYSIK.uni-siegen.d400.de X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=UNI-SIEGEN/ADMD=D400/C=DE/;2215111004081997/A38701/OSI4SI] X400-Content-Type: P2-1984 (2) Content-Identifier: 11B8228B0E00 From: Fliessbach (Tel +49 271 740 4156) Message-ID: <2215111004081997/A38701/OSI4SI/11B8228B0E00*@MHS> To: tex-fonts (Non Receipt Notification Requested) (IPM Return Requested) Subject: New ptm??.pk fonts Dear Sir: Your new ptm?8r.pk are quite useful for previewing my Latex-files (using times fonts). Thanks for making these fonts available to the public. In order to get ligatures etc. correct it seems, however, that I needed a file like '8renc.def' replacing t1enc.def. (Presently, I am using the font substitution ptm?8t -> ptm?8r). Can you help me? Many thanks in advance, yours sincerely, Torsten Fliessbach e-mail: fliessbach@physik.uni-siegen.de 4-Aug-1997 9:19:06-GMT,1637;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id DAA02536 for ; Mon, 4 Aug 1997 03:19:04 -0600 (MDT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id KAA27151 for ; Mon, 4 Aug 1997 10:14:37 +0100 (BST) Received: from screavie.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 4 Aug 1997 10:15:14 +0100 Received: from knott.elsevier.co.uk (knott.elsevier.co.uk [193.131.197.165]) by screavie.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id KAA05799; Mon, 4 Aug 1997 10:15:10 +0100 (BST) Received: (from srahtz@localhost) by knott.elsevier.co.uk (8.8.5/8.8.5) id KAA10858; Mon, 4 Aug 1997 10:20:13 +0100 (BST) Date: Mon, 4 Aug 1997 10:20:13 +0100 (BST) Message-Id: <199708040920.KAA10858@knott.elsevier.co.uk> From: Sebastian Rahtz To: FLIESSBACH@PHYSIK.uni-siegen.d400.de Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: New ptm??.pk fonts In-Reply-To: <2215111004081997/A38701/OSI4SI/11B8228B0E00*@MHS> References: <2215111004081997/A38701/OSI4SI/11B8228B0E00*@MHS> > In order to get ligatures etc. correct it seems, however, that I needed > a file like '8renc.def' replacing t1enc.def. (Presently, I am using the > font substitution ptm?8t -> ptm?8r). Can you help me? > no, you need ptm?8t *virtual fonts* to manage the process. Dont use 8r fonts directly, and dont make a substitution. Sebastian 4-Aug-1997 11:48:57-GMT,1148;000000000000 Return-Path: Received: from ixgate02.dfnrelay.d400.de (ixgate02.dfnrelay.d400.de [193.174.248.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id FAA05051 for ; Mon, 4 Aug 1997 05:48:55 -0600 (MDT) X400-Received: by mta d400relay in /PRMD=dfnrelay/ADMD=d400/C=de/; Relayed; Mon, 4 Aug 1997 13:48:49 +0200 X400-Received: by /PRMD=UNI-SIEGEN/ADMD=D400/C=DE/; converted (ia5-text); Relayed; Mon, 4 Aug 1997 14:44:52 +0200 Date: Mon, 4 Aug 1997 14:44:52 +0200 X400-Originator: FLIESSBACH@PHYSIK.uni-siegen.d400.de X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=UNI-SIEGEN/ADMD=D400/C=DE/;8714431304081997/A38935/OSI4SI] X400-Content-Type: P2-1984 (2) Content-Identifier: 11B8236B0D00 From: Fliessbach (Tel +49 271 740 4156) Message-ID: <8714431304081997/A38935/OSI4SI/11B8236B0D00*@MHS> To: TEX-FONTS (Non Receipt Notification Requested) (IPM Return Requested) Subject: New ptm??.pk fonts Dear Sebastian, thank you for your extremely prompt answer (use *.vf). It works. Torsten 7-Aug-1997 15:43:12-GMT,1696;000000000000 Return-Path: Received: from iwr1.iwr.uni-heidelberg.de (iwr1.iwr.uni-heidelberg.de [129.206.104.40]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA25188 for ; Thu, 7 Aug 1997 09:43:11 -0600 (MDT) Received: from giotto.iwr.uni-heidelberg.de (giotto.iwr.uni-heidelberg.de [129.206.107.82]) by iwr1.iwr.uni-heidelberg.de (8.8.5/8.8.5) with SMTP id RAA27475 for ; Thu, 7 Aug 1997 17:43:09 +0200 (MET DST) Received: by giotto.iwr.uni-heidelberg.de (931110.SGI/950628.SGImailhost) for tex-fonts@math.utah.edu id AA25226; Thu, 7 Aug 97 17:43:07 +0200 From: "Hermann Lauer" Message-Id: <9708071743.ZM25224@giotto.iwr.uni-heidelberg.de> Date: Thu, 7 Aug 1997 17:43:06 -0600 Received: by NeXT.Mailer (1.118.2.RR) X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: tex-fonts@csc-sun.math.utah.edu Subject: hlcdy.tfm (Lucida psfonts) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Hello TeX-Users, I recognized yesterday that the file: ftp://ftp.dante.de/tex-archive/fonts/psfonts/bh/lumath/tfm/hlcdy.tfm (CTAN-server) is not a tfm file, but a uuencoded file. I uudecoded it and can use it now as a tfm File, but I have no idea wether it's correct now or not. Or should I use other Files for the lucida Fonts ? Thanks for any help. Hermann P.S: Please reply via direct email, as I'm not on the list. -- Hermann Lauer Bildverarbeitungsgruppe des Interdiziplinaeren Zentrums fuer wissenschaftliches Rechnen, Universitaet Heidelberg INF 368; 69120 Heidelberg; Tel: (06221)548826 Fax: (06221)545224 Email: Hermann.Lauer@iwr.uni-heidelberg.de 8-Aug-1997 8:52:09-GMT,1768;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id CAA16912 for ; Fri, 8 Aug 1997 02:52:08 -0600 (MDT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id JAA27188 for ; Fri, 8 Aug 1997 09:47:39 +0100 (BST) Received: from screavie.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Fri, 8 Aug 1997 09:46:35 +0100 Received: from knott.elsevier.co.uk (knott.elsevier.co.uk [193.131.197.165]) by screavie.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id JAA11511; Fri, 8 Aug 1997 09:46:33 +0100 (BST) Received: (from srahtz@localhost) by knott.elsevier.co.uk (8.8.5/8.8.5) id JAA25649; Fri, 8 Aug 1997 09:53:02 +0100 (BST) Date: Fri, 8 Aug 1997 09:53:02 +0100 (BST) Message-Id: <199708080853.JAA25649@knott.elsevier.co.uk> From: Sebastian Rahtz To: Hermann.Lauer@IWR.Uni-Heidelberg.De Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: hlcdy.tfm (Lucida psfonts) In-Reply-To: <9708071743.ZM25224@giotto.iwr.uni-heidelberg.de> References: <9708071743.ZM25224@giotto.iwr.uni-heidelberg.de> Hermann Lauer writes: > ftp://ftp.dante.de/tex-archive/fonts/psfonts/bh/lumath/tfm/hlcdy.tfm > > (CTAN-server) is not a tfm file, but a uuencoded file. I uudecoded it and can > use it now as a tfm File, but I have no idea wether it's correct now or not. well dang so it is. my fault. i have kicked a CTAN re-install to update it > Or should I use other Files for the lucida Fonts ? no, that is the right metric file (after uudecoding and renaming) Sebastian 9-Aug-1997 1:30:21-GMT,1594;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id TAA07551 for ; Fri, 8 Aug 1997 19:30:20 -0600 (MDT) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.15) with ESMTP id VAA06028; Fri, 8 Aug 1997 21:30:17 -0400 (EDT) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id VAA00373; Fri, 8 Aug 1997 21:30:16 -0400 (EDT) Date: Fri, 8 Aug 1997 21:30:16 -0400 (EDT) Message-Id: <199708090130.VAA00373@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: Hermann.Lauer@IWR.Uni-Heidelberg.De CC: tex-fonts@csc-sun.math.utah.edu In-reply-to: <9708071743.ZM25224@giotto.iwr.uni-heidelberg.de> (Hermann.Lauer@IWR.Uni-Heidelberg.De) Subject: Re: hlcdy.tfm (Lucida psfonts) Reply-to: bkph@ai.mit.edu From: "Hermann Lauer" Hello TeX-Users, I recognized yesterday that the file: ftp://ftp.dante.de/tex-archive/fonts/psfonts/bh/lumath/tfm/hlcdy.tfm (CTAN-server) is not a tfm file, but a uuencoded file. I uudecoded it and can use it now as a tfm File, but I have no idea wether it's correct now or not. Or should I use other Files for the lucida Fonts ? Actually, the best way to use the Lucida fonts is with the metrics that come with the fonts. That way you avoid needing to download yet another branch of CTAN (unless you are talking about the old Adobe Lucida maybe?) Regards, Berthold. 25-Aug-1997 12:07:01-GMT,755;000000000000 Return-Path: Received: from bueno.newmex.com (bueno.newmex.com [206.183.203.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id GAA02415 for ; Mon, 25 Aug 1997 06:07:00 -0600 (MDT) Received: from [206.183.203.104] by bueno.newmex.com via ESMTP (940816.SGI.8.6.9/940406.SGI) id GAA16895; Mon, 25 Aug 1997 06:04:22 -0600 X-Sender: rollo@newmex.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Aug 1997 05:45:18 -0600 To: Font mailing list From: Roland Silver Subject: subscribe How can I subscribe to this mailing list? -- Rollo Silver 25-Aug-1997 17:36:00-GMT,2419;000000000000 Return-Path: Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id LAA09464; Mon, 25 Aug 1997 11:36:00 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id LAA08077; Mon, 25 Aug 1997 11:35:59 -0600 (MDT) Date: Mon, 25 Aug 1997 11:35:59 -0600 (MDT) To: tex-fonts@csc-sun.math.utah.edu Cc: beebe@csc-sun.math.utah.edu X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: New UNIX utilities for Adobe Multiple Master Fonts Message-ID: This just appeared on the Imprint mailing list: >> ... >> From: Imprint@macline.com (Imprint) >> Reply-To: Imprint@macline.com (Imprint) >> Date: Sun, 24 Aug 1997 19:52:47 -0500 >> Subject: IMPRINT Vol. 1, No. 8 >> ... >> UNIX utilities for Adobe Multiple Master Fonts. >> >> Preliminary versions of two free UNIX command-line tools, written by Eddie >> Kohler, are available for working with fonts in Adobe's Multiple Master >> format. >> mmafm creates a AFM file by interpolating at a given point in a Multiple >> Master Font's design space. mmpfb creates a PFB font by interpolating at a >> given point in a Multiple Master Font's design space. Both can handle >> fonts with intermediate masters, like Adobe Jenson. >> Both utilities require a C++ compiler -- g++-2.7.2 was used to develop the >> utilities -- but not the C++ libraries. >> Version 0.2 corrects a bug in previous versions. Source code for the >> utilities is located at >> http://www.pdos.lcs.mit.edu/~eddietwo/type/mmafm-0.2.tar.gz >> http://www.pdos.lcs.mit.edu/~eddietwo/type/mmpfb-0.2.tar.gz >> ... >> ... ======================================================================== Nelson H. F. Beebe Tel: +1 801 581 5254 Center for Scientific Computing FAX: +1 801 581 4148 University of Utah Internet e-mail: beebe@math.utah.edu Department of Mathematics, 105 JWB URL: http://www.math.utah.edu/~beebe 155 S 1400 E RM 233 Salt Lake City, UT 84112-0090, USA ======================================================================== 4-Sep-1997 6:27:25-GMT,1952;000000000000 Return-Path: Received: from david.kulak.ac.be (david.kulak.ac.be [193.190.176.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id AAA11067 for ; Thu, 4 Sep 1997 00:27:24 -0600 (MDT) Received: from david (localhost [127.0.0.1]) by david.kulak.ac.be (8.7.5/8.7.3) with SMTP id IAA23941 for ; Thu, 4 Sep 1997 08:28:14 +0200 (MET DST) Sender: Paul.Igodt@kulak.ac.be Message-ID: <340E54FE.58CD@kulak.ac.be> Date: Thu, 04 Sep 1997 08:28:14 +0200 From: Paul Igodt Organization: Katholieke Universiteit Leuven Campus Kortrijk X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5 sun4u) MIME-Version: 1.0 To: tex-fonts@csc-sun.math.utah.edu Subject: using psfonts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear PSfonts-specialists, I wanted to try out, for the first time ever, the use of psnfss and of (some of) the psfonts used on the CTAN sites. I ftp-ed the necessary stuff from CTAN and tried to install properly, at least, what I thought I would need. I wanted to try the adobe/univers fonts. I prepared this minimal .tex file: ---------------------------------- \documentclass[11pt]{article} \usepackage{univers} \begin{document} \textsf De tekst zelf \end{document} ---------------------------------- Composing went fine. When asking dvips to treat the .dvi file, I used the "dvips -Ppun ..." command, which produces " dvips: ! Couldn't find header file punr8a.pfb " I cannot locate anywhere on our system this .pfb file however... Can anyone make a diagnosis and help in taking off with psfonts? Gratefully. Paul -- Prof. Dr. Paul Igodt KU Leuven Campus Kortrijk Universitaire Campus B-8500 Kortrijk (Belgium) Tel.: (+32) (0)56 24 61 37 Fax.: (+32) (0)56 24 69 99 E-mail: Paul.Igodt@kulak.ac.be http://www.kulak.ac.be/facult/wet/wiskunde/igodt/www.html 4-Sep-1997 7:35:18-GMT,1808;000000000000 Return-Path: Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id BAA12304 for ; Thu, 4 Sep 1997 01:35:16 -0600 (MDT) Date: Thu, 4 Sep 1997 09:35:13 +0200 (MET DST) Message-Id: <199709040735.JAA14107@isidor.informatik.uni-stuttgart.de> Received: by isidor.informatik.uni-stuttgart.de; Thu, 4 Sep 1997 09:35:13 +0200 (MET DST) From: Bernd Raichle MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Igodt Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: using psfonts In-Reply-To: <340E54FE.58CD@kulak.ac.be> References: <340E54FE.58CD@kulak.ac.be> X-Mailer: VM 6.33 under Emacs 19.34.1 On Thu, 4 September 1997 08:28:14 +0200, Paul Igodt writes: [...] > I wanted to try the adobe/univers fonts. [...] > When asking dvips to treat the .dvi file, I used the > > "dvips -Ppun ..." > command, which produces > > " dvips: ! Couldn't find header file punr8a.pfb " > > I cannot locate anywhere on our system this .pfb file however... > > Can anyone make a diagnosis and help in taking off with psfonts? [...] You have to _buy_ the Univers PostScript font sources, they are not (and can not be) included legally. Btw. you have to pay money for almost all fonts, only a few are for free. Best wishes, -bernd ____________________________________________________________________ Bernd Raichle "Le langage est source DANTE e.V., Koordinator `german.sty' de malentendus" email: german@dante.de (A. de Saint-Exupery) 4-Sep-1997 8:18:40-GMT,1373;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id CAA13092 for ; Thu, 4 Sep 1997 02:18:39 -0600 (MDT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id JAA15028 for ; Thu, 4 Sep 1997 09:18:11 +0100 (BST) Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Thu, 4 Sep 1997 09:14:30 +0100 Date: Thu, 4 Sep 1997 09:11:38 +0100 Message-ID: <1545-Thu04Sep1997091138+0100-s.rahtz@elsevier.co.uk> From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul.Igodt@kulak.ac.be Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: using psfonts In-Reply-To: <340E54FE.58CD@kulak.ac.be> References: <340E54FE.58CD@kulak.ac.be> X-Mailer: VM 6.33 under Emacs 19.34.4 Exactly what I would expect. Univers is a commercial font which you have to buy, and install the .pfb files in a place where dvips can find them, named as per the Berry naming scheme you are nearly there; just either a) buy Univers, or b) rename/copy the font files you already own Sebastian 4-Sep-1997 11:56:18-GMT,1533;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id FAA16954 for ; Thu, 4 Sep 1997 05:56:17 -0600 (MDT) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.16) with ESMTP id HAA11281; Thu, 4 Sep 1997 07:56:11 -0400 (EDT) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id HAA10531; Thu, 4 Sep 1997 07:56:10 -0400 (EDT) Date: Thu, 4 Sep 1997 07:56:10 -0400 (EDT) Message-Id: <199709041156.HAA10531@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: Paul.Igodt@kulak.ac.be CC: tex-fonts@csc-sun.math.utah.edu In-reply-to: <340E54FE.58CD@kulak.ac.be> (message from Paul Igodt on Thu, 04 Sep 1997 08:28:14 +0200) Subject: Re: using psfonts Reply-to: bkph@ai.mit.edu > I wanted to try out, for the first time ever, the use of psnfss and of (some of) the psfonts used on the CTAN sites. > I ftp-ed the necessary stuff from CTAN and tried to install properly, at least, what I thought I would need. > I wanted to try the adobe/univers fonts. To use a font, you need the font :-) Generally on IBM PC you would want the *.PFB file for the font and *.PFM for Windows and an *.AFM files. These are available from the font vendor. In your case Adobe. http://www.adobe.com You are not the first to be misled by the TeX book calling a TFM metric file a `font.' Regards, Berthold. 7-Sep-1997 22:05:34-GMT,2086;000000000000 Return-Path: Received: from hubert.wuh.wustl.edu (ats@wydo122.wuh.wustl.edu [128.252.232.122]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id QAA17829 for ; Sun, 7 Sep 1997 16:05:33 -0600 (MDT) Received: (from ats@localhost) by hubert.wuh.wustl.edu (8.8.5/8.8.5) id RAA03987; Sun, 7 Sep 1997 17:05:30 -0500 To: tex-fonts@csc-sun.math.utah.edu Subject: Monotype Spectrum fonts From: Alan Shutko Date: 07 Sep 1997 17:05:27 -0500 Message-ID: Lines: 39 X-Mailer: Gnus v5.5/Emacs 20.0 I have the Monotype Spectrum Expert set fonts, and I'm trying to use the modified fontinst in the psfonts dir on CTAN to create the necessary TeX files to use them. Unfortunately, I must be naming the AFM files incorrectly, because things don't work after I copy everything in the right places. Here's the names I have for the AFM files, hoping that they match up with something: Directory /usr/lib/texmf/texmf/fonts/afm/monotype/spectrum/ msmr8a.afm msmrc8a.afm msmri8a.afm msms7d.afm msms8x.afm msmr8x.afm msmri7d.afm msmri8x.afm msms8a.afm The original names are: Directory /home/ats/psfonts/e*.afm ekexp___.afm ekio____.afm ekrg____.afm eksbo___.afm eksc____.afm eki_____.afm ekixp___.afm eksb____.afm eksbx___.afm I think that I've misnamed things, because I get these errors trying to use the font in LaTeX: (/usr/lib/texmf/texmf/tex/latex/spectrum/spectrum.sty) (resume-spectrum.aux) (/usr/lib/texmf/texmf/tex/latex/spectrum/OT1msm.fd)kpathsea: Running MakeTeXTFM msms7t.tfm MakeTeXTFM: Running mf \mode:=ljfour; mag:=1; scrollmode; input msms7t This is METAFONT, Version 2.718 (C version 6.1) kpathsea: Running MakeTeXMF msms7t.mf ! I can't find file `msms7t.mf'. Actually, looking at it... I didn't get any 7t files out of fontinst. Any ideas why? (Sorry for the very confused message... I am quite confused about the naming.) -- Alan Shutko - By consent of the corrupted If you can't be good, be careful. If you can't be careful, give me a call. 8-Sep-1997 9:13:16-GMT,1600;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id DAA29795 for ; Mon, 8 Sep 1997 03:13:15 -0600 (MDT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id KAA08777 for ; Mon, 8 Sep 1997 10:12:50 +0100 (BST) Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Mon, 8 Sep 1997 10:07:57 +0100 Date: Mon, 8 Sep 1997 10:09:38 +0100 Message-ID: <2848-Mon08Sep1997100938+0100-s.rahtz@elsevier.co.uk> From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ats@acm.org Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: Monotype Spectrum fonts In-Reply-To: References: X-Mailer: VM 6.33 under Emacs 19.34.4 Alan Shutko writes: > MakeTeXTFM: Running mf \mode:=ljfour; mag:=1; scrollmode; input msms7t > This is METAFONT, Version 2.718 (C version 6.1) > > kpathsea: Running MakeTeXMF msms7t.mf > ! I can't find file `msms7t.mf'. > > Actually, looking at it... I didn't get any 7t files out of fontinst. > Any ideas why? > 7t names are almost certainly for virtual fonts. fontinst should have written you msms7t.vpl for you to compile using vptovf. did you make .vf files and install them sebastian 8-Sep-1997 14:28:17-GMT,1286;000000000000 Return-Path: Received: from hubert.wuh.wustl.edu (ats@wydo122.wuh.wustl.edu [128.252.232.122]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id IAA05438 for ; Mon, 8 Sep 1997 08:28:16 -0600 (MDT) Received: (from ats@localhost) by hubert.wuh.wustl.edu (8.8.5/8.8.5) id JAA13240; Mon, 8 Sep 1997 09:28:10 -0500 To: s.rahtz@elsevier.co.uk (Sebastian Rahtz) Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: Monotype Spectrum fonts References: <2848-Mon08Sep1997100938+0100-s.rahtz@elsevier.co.uk> From: Alan Shutko Date: 08 Sep 1997 09:28:05 -0500 In-Reply-To: s.rahtz@elsevier.co.uk's message of Mon, 8 Sep 1997 10:09:38 +0100 Message-ID: Lines: 14 X-Mailer: Gnus v5.5/Emacs 20.0 >>>>> "S" == Sebastian Rahtz writes: S> 7t names are almost certainly for virtual fonts. fontinst should S> have written you msms7t.vpl for you to compile using vptovf. Doesn't look like it did. I'll have to go through and figure out why now. (I've had some troubles getting everything working, PATH and such, so it's probably something I left out.) -- Alan Shutko - By consent of the corrupted IBM: It's Bullshit Mommery 9-Sep-1997 8:07:03-GMT,865;000000000000 Return-Path: Received: from fast.fast.de (fast.fast.de [194.59.176.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id CAA28913 for ; Tue, 9 Sep 1997 02:07:01 -0600 (MDT) Received: from UNUK.fast.de (unuk.fast.de [194.59.176.109]) by fast.fast.de (8.8.4/8.7.3-FAST) with SMTP id KAA11765 for ; Tue, 9 Sep 1997 10:16:35 +0200 Message-Id: <3.0.1.32.19970909100508.00799290@fast.de> X-Sender: ssc@fast.de X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 09 Sep 1997 10:05:08 +0200 To: tex-fonts@csc-sun.math.utah.edu From: Steffen =?iso-8859-1?Q?Schw=E4rtzel?= Subject: Fonts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I am having problems to figure out the abbreviations for the type1 BaKoMa fonts. Could you please help me. Thanx in advance ssc 9-Sep-1997 18:06:22-GMT,2331;000000000000 Return-Path: Received: from tug.cs.umb.edu (root@tug.cs.umb.edu [158.121.106.10]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id MAA11779 for ; Tue, 9 Sep 1997 12:06:21 -0600 (MDT) Received: from refuge.Colorado.EDU (root@refuge.Colorado.EDU [128.138.240.12]) by tug.cs.umb.edu (8.8.0/8.8.0) with ESMTP id OAA15804 for ; Tue, 9 Sep 1997 14:16:42 -0400 Received: from refuge.Colorado.EDU (jds@localhost [127.0.0.1]) by refuge.Colorado.EDU (8.8.7/8.8.7/UnixOps/Hesiod/(SDM)) with ESMTP id MAA26041 for ; Tue, 9 Sep 1997 12:06:17 -0600 (MDT) Message-Id: <199709091806.MAA26041@refuge.Colorado.EDU> to: tex-fonts@tug.cs.umb.edu subject: font help Date: Tue, 09 Sep 1997 12:06:12 -0600 From: Justin D Slaughter Hello, I am having problems with fonts for LaTeX. I am trying to use the width class ultraexpanded with the small caps shape. I have found that the width ultraexpanded does not work for any shape. LaTeX does not like this and is substituting what I want for what I don't want. I have included a portion of my code and the error message. Justin ---------- This is a part of my code: ... \DeclareFixedFont{\jdsfont}{OT1}{cmr}{bux}{sc}{12} <--- this is line 11 ... \vspace{2mm} \hspace{-8mm} {\jdsfont{Examples}} \hrulefill \vspace{-2mm} ... \vspace{2mm} \hspace{-8mm} {\jdsfont{Questions}} \hrulefill \vspace{-2mm} ... -------- This is the error message I get: [jds]flatiron} latex resume This is TeX, Version 3.14159 (C version 6.1) (resume LaTeX2e <1996/12/01> patch level 1 Babel and hyphenation patterns for american, german, loaded. (/usr/local/TeX/texmf/tex/latex/base/article.cls Document Class: article 1996/10/31 v1.3u Standard LaTeX document class (/usr/local/TeX/texmf/tex/latex/base/size10.clo)) (/usr/local/TeX/texmf/tex/latex/base/newlfont.sty (/usr/local/TeX/texmf/tex/latex/base/latexsym.sty)) LaTeX Font Warning: Font shape `OT1/cmr/bux/sc' undefined (Font) using `OT1/cmr/m/n' instead on input line 11. (resume.aux) (/usr/local/TeX/texmf/tex/latex/base/omscmr.fd) [1] (resume.aux) LaTeX Font Warning: Some font shapes were not available, defaults substituted. ) Output written on resume.dvi (1 page, 4252 bytes). Transcript written on resume.log. 10-Sep-1997 8:41:33-GMT,1785;000000000000 Return-Path: Received: from tug.cs.umb.edu (root@tug.cs.umb.edu [158.121.106.10]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id CAA00592 for ; Wed, 10 Sep 1997 02:41:32 -0600 (MDT) Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by tug.cs.umb.edu (8.8.0/8.8.0) with ESMTP id EAA16335 for ; Wed, 10 Sep 1997 04:51:52 -0400 Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id JAA27110 for ; Wed, 10 Sep 1997 09:40:50 +0100 (BST) Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Wed, 10 Sep 1997 09:40:16 +0100 Date: Wed, 10 Sep 1997 09:31:10 +0100 Message-ID: <5884-Wed10Sep1997093110+0100-s.rahtz@elsevier.co.uk> From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: jds@Colorado.EDU Cc: tex-fonts@tug.cs.umb.edu Subject: Re: font help In-Reply-To: <199709091806.MAA26041@refuge.Colorado.EDU> References: <199709091806.MAA26041@refuge.Colorado.EDU> X-Mailer: VM 6.33 under Emacs 19.34.4 Justin D Slaughter writes: > I am having problems with fonts for LaTeX. I am trying to use the width > class ultraexpanded with the small caps shape. I have found that the width well, thats easy to answer. just because LaTeX knows about the idea of ultraexpanded small caps, it doesnt follow that your font family (Computer Modern) implements that combination. use a font family that *does* have the shape you want! [1] Sebastian [1] no, i dont know of one, unless you use a Multiple Master font 12-Sep-1997 16:54:06-GMT,2350;000000000000 Return-Path: Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id KAA09386 for ; Fri, 12 Sep 1997 10:54:05 -0600 (MDT) Received: from slip139-92-42-167.ut.nl.ibm.net (slip139-92-42-167.ut.nl.ibm.net [139.92.42.167]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id QAA54490; Fri, 12 Sep 1997 16:53:59 GMT Message-Id: <199709121653.QAA54490@out2.ibm.net> From: "Walter Schmidt" To: "tex-fonts" , "CTAN announcements" Date: Fri, 12 Sep 97 18:54:59 +0200 Reply-To: "Walter Schmidt" Priority: Normal X-Mailer: PMMail 1.92 (OS/2 Warp) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: LaTeX support for old german fonts A new and enhanced LaTeX support package for the old german fonts is now available in the CTAN directory macros/latex/contrib/supported/yfonts . The package yfonts.sty supports the old german fonts `Gotisch', `Fraktur', `Schwabacher' and `Initialen' designed by Yannis Haralambous. In contrast to oldgerm.sty the package provides a full *NFSS interface*, and it may be used in conjunction with *german.sty*. The package comes as a documented LaTeX source with an installation script and an example document. This software replaces my now obsolete package fraktur.sty, which has been removed. Major changes are: * support for the gothic font, too * various bug fixes * better documentation Greetings Walter Schmidt ********************************************************************* Walter Schmidt Schornbaumstrasse 2, 91052 Erlangen, Germany pgp key (1024 bits, keyID 69D36B8D): see pgp key fingerprint: 1C E5 A5 D8 B8 F7 E2 EF 36 55 69 EC D8 26 94 A9 ********************************************************************* ********************************************************************* Walter Schmidt Schornbaumstrasse 2, 91052 Erlangen, Germany pgp key (1024 bits, keyID 69D36B8D): see pgp key fingerprint: 1C E5 A5 D8 B8 F7 E2 EF 36 55 69 EC D8 26 94 A9 ********************************************************************* 25-Sep-1997 12:36:19-GMT,1846;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id GAA29196 for ; Thu, 25 Sep 1997 06:36:18 -0600 (MDT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id NAA29118 for ; Thu, 25 Sep 1997 13:35:28 +0100 (BST) Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Thu, 25 Sep 1997 13:35:37 +0100 Date: Thu, 25 Sep 1997 13:34:14 +0100 Message-ID: <9262-Thu25Sep1997133414+0100-s.rahtz@elsevier.co.uk> X-Mailer: emacs 19.34.4 (via feedmail 7 Q) From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) To: tex-fonts@csc-sun.math.utah.edu Subject: replacement CTAN fonts/psfonts/tools After a period of email battering, I have given in, and revamped (slightly) the tools I use to create PostScript font metrics for TeX. These are stored in fonts/psfonts/tools on CTAN. What I have done is: - generally clear up, and add some new targets to the Makefile - rewrite the remaining shell script in Perl - go over the Perl scripts, and make them work only with web2c 7.0 (ie they call kpsewhich) - test the whole thing under Windows NT, to get away from basic Unix dependency - put better messages into finst, my unofficial hack of fontinst - added my name and email address to finst files. The results are *UNCHANGED*, I sincerely hope. Prove me wrong, if you can. What I have _not_ done is: - alter the workings of finst in any way - added any new documentation - sorted out the remaining checksum issues which Piet T and I know so well I should add that I have no plans to write documentation. Sebastian 3-Oct-1997 13:18:12-GMT,1297;000000000000 Return-Path: Received: from tug.cs.umb.edu (root@tug.cs.umb.edu [158.121.106.10]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id HAA08336 for ; Fri, 3 Oct 1997 07:18:07 -0600 (MDT) Received: from notiid.mathstat.uottawa.ca (notiid.mathstat.uottawa.ca [137.122.49.36]) by tug.cs.umb.edu (8.8.0/8.8.0) with SMTP id JAA22320 for ; Fri, 3 Oct 1997 09:28:53 -0400 Received: from zenon.mathstat.uottawa.ca by notiid.mathstat.uottawa.ca (AIX 3.2/UCB 5.64/4.03) id AA22048; Fri, 3 Oct 1997 09:14:48 -0400 Received: by zenon.mathstat.uottawa.ca (SMI-8.6/SMI-SVR4) id JAA06158; Fri, 3 Oct 1997 09:22:14 -0400 Date: Fri, 3 Oct 1997 09:22:14 -0400 From: daniel@zenon.mathstat.uottawa.ca (Daniel Daigle) Message-Id: <199710031322.JAA06158@zenon.mathstat.uottawa.ca> To: tex-fonts@tug.cs.umb.edu Subject: metafont modes X-Sun-Charset: US-ASCII Hi, I would like to ask a question. My printer is a HP laserjet 6L, and there is no mode for it in the version of modes.mf which I have. Am I supposed to use "ljfive"? What is the best choice for me? How can I obtain the most recent version of modes.mf? Thank you very much. (Please phrase your answer so that a dummy can understand it.) Daniel Daigle 3-Oct-1997 13:53:07-GMT,5191;000000000000 Return-Path: Received: from tug.cs.umb.edu (root@tug.cs.umb.edu [158.121.106.10]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id HAA09147 for ; Fri, 3 Oct 1997 07:53:06 -0600 (MDT) Received: from csc-sun.math.utah.edu (root@csc-sun.math.utah.edu [128.110.198.2]) by tug.cs.umb.edu (8.8.0/8.8.0) with ESMTP id KAA22345 for ; Fri, 3 Oct 1997 10:03:52 -0400 Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id HAA09137; Fri, 3 Oct 1997 07:52:55 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id HAA12157; Fri, 3 Oct 1997 07:52:54 -0600 (MDT) Date: Fri, 3 Oct 1997 07:52:54 -0600 (MDT) To: daniel@zenon.mathstat.uottawa.ca (Daniel Daigle) Cc: beebe@csc-sun.math.utah.edu, tex-fonts@tug.cs.umb.edu X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: metafont modes In-Reply-To: Your message of Fri, 3 Oct 1997 09:22:14 -0400 Message-ID: >> My printer is a HP laserjet 6L, and there >> is no mode for it in the version of modes.mf which I have. >> Am I supposed to use "ljfive"? What is the best choice for me? >> How can I obtain the most recent version of modes.mf? The last release that I have installed here is modes.mf 3.2, dated Thu Nov 7 15:51:45 EST 1996 Karl Berry maintains that file, and announces new versions on this list, and possibly other lists. The CTAN archives (finger ctan@ftp.tex.ac.uk for a list) should have the new version within a few days of announcement. You can very likely use ljfive, ljfivemp, or ljfour with acceptable results. Remember that many laser printer vendors use the same engines (Canon and Ricoh are major manufacturers of such). We have 28 printers in my department, from several different manufacturers (Apple, Hewlett-Packard, Imagen, Lexmark, ...), and not once have I received a complaint about font quality arising from our use of ljfour as the standard mode on all of these models. Remember that users will often generate a PostScript file from a DVI file, then print it anywhere, or post it on the Web for printing at other sites. Thus, one cannot realistically expect the Metafont mode chosen to routinely match the printer finally used. The biggest difference in laser printer engines is white-writing versus black-writing (start with a black background and remove dots leaving letters shapes behind, or start with a white background and add dots to create letter shapes). Several Xerox and Ricoh engines are white-writing, and all Canon engines I know of are black-writing. Between these two classes, there can be significant differences in appearance: black-writing engine fonts on a white-writing engine usually look rather thin, and under magnification, the cause is evident. White-writing fonts on a black-writing engine will likely appear to dark. And don't forget individual printer density adjustments: earlier this week, I investigated a complaint about light output from one of our lab printers, and found that someone had reduced the toner intensity adjustment buried deep inside the printer. If you are really concerned about achieving the best appearance of your fonts, you might consider using outline fonts instead of bitmap fonts. There are two sets of Computer Modern fonts, the BaKoMa fonts, and the BlueSky/AMS fonts, both in the CTAN archives. The latter have had thousands of hours of work in hand tuning. However, I've used the BaKoMa fonts quite happily for some time (their release predated the other by a couple of years). By leaving the rasterization job until the file is inside the printer, you are more likely to get printer-tuned optimal appearance of fonts. The drawback is the larger size of such files (perhaps a factor of two, unless the driver supports font subsetting). There is a big payoff, however, if you want to convert them to PDF for viewing on the Web: the current versions (1, 2, 3) of Adobe Acrobat Reader do an abysmal job of displaying bitmap fonts, and a very good job of displaying outline fonts. Thus, I always recommend use of outline fonts for preparation of PDF files. Perhaps I can find some time to put up some examples of the two cases. ---------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 105 JWB beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ---------------------------------------------------------------------------- 6-Oct-1997 12:50:43-GMT,2637;000000000000 Return-Path: Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id GAA25704; Mon, 6 Oct 1997 06:50:42 -0600 (MDT) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id GAA01135; Mon, 6 Oct 1997 06:50:41 -0600 (MDT) Date: Mon, 6 Oct 1997 06:50:41 -0600 (MDT) To: pdf@lists.emrg.com, tex-fonts@csc-sun.math.utah.edu Cc: beebe@csc-sun.math.utah.edu X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Outline and bitmap fonts compared Message-ID: >From time to time on the PDF and tex-fonts lists, the question of display quality of fonts has come up, often with regard to the display of documents typeset by TeX. I have responded privately, and on the lists, to these questions when I had the time to do so. Over the last few days, I've put together a Web page that discusses the issues, and illustrates the problem with sample pages set with outline fonts, and with bitmap fonts. The problem lies primarily with Adobe Acrobat Reader, acroread, since other freely available software clearly demonstrates that bitmap fonts can be displayed satisfactorily. PERHAPS ENOUGH VOLUME OF COMPLAINTS TO ADOBE SYSTEMS WILL SURFACE THAT THEY WILL FINALLY FIX ACROBAT READER! Although TeX documents are often the origin of bitmap fonts, other document formatting systems also use them. For historical reasons documented in the Web page, Adobe has a responsibility to do better. Please visit http://www.math.utah.edu/~beebe/fonts/outline-vs-bitmap-fonts.html Comments are welcome, but please keep them off the lists unless they really are intended to be read by more than the author of that page. ---------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 105 JWB beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ---------------------------------------------------------------------------- 16-Oct-1997 20:42:41-GMT,2888;000000000000 Return-Path: Received: from pop.fallon.com (pop.fallon.com [204.73.73.4]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id OAA06185 for ; Thu, 16 Oct 1997 14:42:41 -0600 (MDT) Received: from [206.146.33.52] (fm33-52.fallon.com [206.146.33.52] (may be forged)) by pop.fallon.com (8.8.6/8.8.6) with SMTP id PAA17970 for ; Thu, 16 Oct 1997 15:44:01 -0500 Date: Thu, 16 Oct 1997 14:42:36 -0600 From: "Dorian J. Cougias" Message-ID: To: "Tex Fonts" Subject: Worldwide Satellite Communications X-Mailer: eMerge 1.1.1 I need your help. I'm conducting an online web-based survey that I'd like your involvement in. Its about what we in the computer field think about cell phones becoming satellite phones, and global connectivity. Its not long, and its aimed at folks who are interested in, or are supporting, people who travel and want to stay connected. Its about us who support travelers. The study is being conducted on line, and by participating, you'll also be able to directly see the results there as well. Feel free to continue to drop by and see how it is shaping up. Who's it for? We aren't being paid for this. We are doing it for research. We are going to share our information with Iridium and anyone else who is asking (you can have it too). Will we sell the data? No. We will give it away to anyone who wants to look at it on the Internet. All you have to do is hit print or save and you have the results. Why should you participate? Because if you are like me, an IS manager, you probably think that worldwide communications either stinks or is almost impossible. There is a new player coming into the market and after talking with them a while, I think we should send them a message about what we believe. If we don't we are at fault if they build something we don't like. If they build something we don't feel will work, well then that's silly on their part. Is it anonymous? Yep. We aren't even going to ask for your name. No cookie tracking, no nothing. No follow up spam trying to sell you something. It's not about that. Can you refer others? Yes, especially if you live overseas. I hate it when American companies try to foist their beliefs on everyone in the world. I'm looking to get at least a couple of hundred responses within the next couple of days. -- If you are wondering, I have your name from either a business card, or one of the bizillion lists I belong to. No, you won't get further mail about this, so don't worry about asking to be taken off of a list. Thanks. The URL for entering information is:http://survey.fallon.com The URL for looking at the results is:http://survey.fallon.com/results.html --- Thanks for the support, I really appreciate it. 20-Oct-1997 22:48:08-GMT,1580;000000000000 Return-Path: Received: from hubert.wuh.wustl.edu (ats@wydo122.wuh.wustl.edu [128.252.232.122]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id QAA18649 for ; Mon, 20 Oct 1997 16:48:04 -0600 (MDT) Received: (from ats@localhost) by hubert.wuh.wustl.edu (8.8.5/8.8.5) id RAA09288; Mon, 20 Oct 1997 17:47:54 -0500 To: tex-fonts@csc-sun.math.utah.edu Subject: Fontinst and expert fonts? X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA) Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.88 "Tsurugi") Content-Type: text/plain; charset=US-ASCII From: Alan Shutko Date: 20 Oct 1997 17:47:51 -0500 Message-ID: Lines: 25 X-Mailer: Gnus v5.5/Emacs 20.2 I was playing with the modified version of fontinst (in CTAN:fonts/psfonts/tools/finst) to install my Spectrum Expert set in the 8r encoding. It doesn't appear to be noticing my expert fonts, which I've named msmr8x.afm msmri8x.afm msms8x.afm (as per monotype.map) since I'm not getting the ff, ffi, ffl ligatures. I'm also getting errors like this in my run Raw font written on msms8r.pl. (msms8r.mtx) (../../finst/8r.mtx) (../../finst/8r.etx) (../../finst/8r.etx Warning: \ligature for unknown slot `ffi'. Warning: \ligature for unknown slot `ffl'. Warning: \ligature for unknown slot `ff'. ) (../../finst/8r.etx) Font written on msms8r.pl. Anyone have ideas what I'm doing wrong? (I probably missnamed the afm files again... 8^) -- Alan Shutko - By consent of the corrupted IBM: Into Building Money 23-Oct-1997 23:58:36-GMT,1915;000000000000 Return-Path: Received: from wrath (serv1.is2.u-net.net [194.119.130.23]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id RAA20901 for ; Thu, 23 Oct 1997 17:58:34 -0600 (MDT) Received: from [194.119.133.114] [194.119.133.114] by wrath with esmtp (Exim 1.62 #2) id 0xOWyy-0004OR-00; Fri, 24 Oct 1997 00:48:04 +0100 X-Sender: rebecca-astrid@mail.u-net.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Oct 1997 00:53:40 +0100 To: tex-fonts@csc-sun.math.utah.edu From: Rebecca and Rowland Subject: Re: Fontinst and expert fonts? >I was playing with the modified version of fontinst (in >CTAN:fonts/psfonts/tools/finst) to install my Spectrum Expert set in >the 8r encoding. It doesn't appear to be noticing my expert fonts, >which I've named > >msmr8x.afm msmri8x.afm msms8x.afm (as per monotype.map) > >since I'm not getting the ff, ffi, ffl ligatures. I'm also getting >errors like this in my run > >Raw font written on msms8r.pl. >(msms8r.mtx) (../../finst/8r.mtx) (../../finst/8r.etx) (../../finst/8r.etx >Warning: \ligature for unknown slot `ffi'. >Warning: \ligature for unknown slot `ffl'. >Warning: \ligature for unknown slot `ff'. >) (../../finst/8r.etx) >Font written on msms8r.pl. > >Anyone have ideas what I'm doing wrong? (I probably missnamed the afm >files again... 8^) >From the output above, I'd guess that it's noticing the expert founts, but doesn't know what to do with them. I don't know exactly how to solve the problem, but... You could try getting the latest version of fontinst 1.6 from CTAN which logs lots of accurate and useful information when you run it. And what fontinst file were you running fontinst on to try and install these founts? Rowland. 24-Oct-1997 17:19:08-GMT,2377;000000000000 Return-Path: Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id LAA14641 for ; Fri, 24 Oct 1997 11:19:07 -0600 (MDT) Received: from slip139-92-42-211.ut.nl.ibm.net (slip139-92-42-211.ut.nl.ibm.net [139.92.42.211]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id RAA159368 for ; Fri, 24 Oct 1997 17:18:55 GMT Message-Id: <199710241718.RAA159368@out2.ibm.net> From: "Walter Schmidt" To: "tex-fonts" Date: Fri, 24 Oct 97 18:34:12 +0200 Reply-To: "Walter Schmidt" Priority: Normal X-Mailer: PMMail 1.92 (OS/2 Warp) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: New font developments: OpenType Font Specification Hi, on the mailing list TYPO-L I've just found a message which might be interesting for us, too, since we've already discussed the subject `Open Type Fonts Specification': Daniel Will-Harris wrote: >Font foundries and designers have been vocal in their fear of font >embedding on the web, and now it seems their fears were >well-founded,at least in the case of Microsoft s new browser, Internet >Explorer 4. The browser s new OpenType font embedding feature has a >fatal security flaw that makes it easy for any user, even those >without technical knowledge, to capture embedded fonts from a web site >and install them into their system for use with all their software. No >one other than myself has yet uncovered the simple steps to do so and >I will not reveal the steps here, because I don t want people pirating >fonts. > >Microsoft knows about the problem and has stated it will do nothing to >correct it. > >You can read the details at http://news.i-us.com/wire/ Finally , let me mention another new www page http://www.typeright.org/feature4.html which deals with font piracy. Greetings Walter ********************************************************************* Walter Schmidt Schornbaumstrasse 2, 91052 Erlangen, Germany pgp key (1024 bits, keyID 69D36B8D): see pgp key fingerprint: 1C E5 A5 D8 B8 F7 E2 EF 36 55 69 EC D8 26 94 A9 ********************************************************************* 27-Oct-1997 11:19:03-GMT,1987;000000000000 Return-Path: Received: from thphy.uni-duesseldorf.de (xerxes.thphy.uni-duesseldorf.de [134.99.64.10]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id EAA01754 for ; Mon, 27 Oct 1997 04:19:02 -0700 (MST) Received: from macbeth.uni-duesseldorf.de (macbeth.thphy.uni-duesseldorf.de) by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA13191; Mon, 27 Oct 97 12:19:51 +0100 Received: by macbeth.uni-duesseldorf.de (SMI-8.6/SMI-SVR4) id MAA18870; Mon, 27 Oct 1997 12:18:14 +0100 Date: Mon, 27 Oct 1997 12:18:14 +0100 Message-Id: <199710271118.MAA18870@macbeth.uni-duesseldorf.de> To: alanje@cogs.susx.ac.uk, s.rahtz@elsevier.co.uk Cc: math-font-discuss@cogs.susx.ac.uk, tex-fonts@csc-sun.math.utah.edu Subject: fontinst/mathptm: bug in OMX.etx From: Ulrik Vieth Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit While experimenting with a mathptm-like implementation using the symbol fonts shipped with Mathematica 3.0, I've found a bug in the OMX encoding vector that produces the wrong kind of symbol for the \rmoustache delimiter. See the patch appended below for details. This bug affects all mathpm/palatcm/etc. implementations that built a virtual font replacement for cmex. It is also possible that the bug was inherited in the new experimental MX/MX1 encodings derived >From OMX. Cheers, Ulrik. P.S. Who is now the official maintainer of "fontinst" or "finst"? *** OMX.etx.orig Fri Sep 9 20:33:00 1994 --- OMX.etx Sat Oct 25 22:51:49 1997 *************** *** 427,433 **** \setslot{parenrightbt} \varchar \vartop{bracerighttp} ! \varbot{braceleftmid} \varrep{braceex} \endvarchar \endsetslot --- 427,433 ---- \setslot{parenrightbt} \varchar \vartop{bracerighttp} ! \varbot{braceleftbt} % bug fix - UV 1997/10/25 \varrep{braceex} \endvarchar \endsetslot 27-Oct-1997 12:15:55-GMT,2202;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id FAA02669 for ; Mon, 27 Oct 1997 05:15:54 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id MAA16963 for ; Mon, 27 Oct 1997 12:14:36 GMT Received: from screavie.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 27 Oct 1997 12:14:50 +0000 Received: from knott.elsevier.co.uk (knott.elsevier.co.uk [193.131.197.165]) by screavie.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id MAA14826; Mon, 27 Oct 1997 12:14:30 GMT From: Sebastian Rahtz Received: (from srahtz@localhost) by knott.elsevier.co.uk (8.8.5/8.8.5) id MAA02744; Mon, 27 Oct 1997 12:15:08 GMT Date: Mon, 27 Oct 1997 12:15:08 GMT Message-Id: <199710271215.MAA02744@knott.elsevier.co.uk> To: vieth@thphy.uni-duesseldorf.de Cc: alanje@cogs.susx.ac.uk, math-font-discuss@cogs.susx.ac.uk, tex-fonts@csc-sun.math.utah.edu Subject: Re: fontinst/mathptm: bug in OMX.etx MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In-Reply-To: <199710271118.MAA18870@macbeth.uni-duesseldorf.de> References: <199710271118.MAA18870@macbeth.uni-duesseldorf.de> X-Mailer: VM 6.33 under Emacs 19.34.6 --text follows this line-- whoops. i will update finst on CTAN. guess i should rebuild mathptm at some point too. as regards maintenance, i am pragmatically maintaining "finst" on my own, since Alan doesn't have time to do fontinst at present. i can and will make changes to finst, such as this fix and the logging enhancements i added recently, and i have to recommend that people use it in preference to the official package. as rowland-and-rebecca will point out, we are in the unsatisfactory position that the package used to generate a lot of metrics on CTAN (finst) has no documentation, and the documentation of `proper' fontinst is slightly out of date. Alan, the ball is in your court on this one..... Sebastian 27-Oct-1997 12:33:41-GMT,1643;000000000000 Return-Path: Received: from rsunx.crn.cogs.susx.ac.uk (root@rsunx-gw.susx.ac.uk [139.184.48.12]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id FAA02940; Mon, 27 Oct 1997 05:31:41 -0700 (MST) Received: from localhost (1042 bytes) by rsunx.crn.cogs.susx.ac.uk via sendmail with P:stdio/D:includelists/R:bind/T:smtp (sender: ) (ident using unix) id for ; Mon, 27 Oct 1997 12:25:50 +0000 (GMT) (Smail-3.2.0.97 1997-Aug-19 #9 built 1997-Oct-3) Message-Id: Date: Mon, 27 Oct 1997 12:25:50 +0000 (GMT) From: Alan Jeffrey To: Sebastian Rahtz Cc: vieth@thphy.uni-duesseldorf.de, alanje@cogs.susx.ac.uk, math-font-discuss@cogs.susx.ac.uk, tex-fonts@csc-sun.math.utah.edu Subject: Re: fontinst/mathptm: bug in OMX.etx In-Reply-To: <199710271215.MAA02744@knott.elsevier.co.uk> References: <199710271118.MAA18870@macbeth.uni-duesseldorf.de> <199710271215.MAA02744@knott.elsevier.co.uk> X-Mailer: VM 6.30 under 19.15 XEmacs Lucid Sebastian, Perhaps the best thing for me to do is take a back seat on fontinst and hand it over to someone else (er, eg you)? I'd originally thought it would only take me a couple of years being a lecturer to get some free time back, but I think that was wildly optimistic of me, and I should just hand the software over to someone who will actively maintain it. The current situation is certainly not good! Oh no, my little baby leaving the nest [spot the mixed metaphor...] Alan. 27-Oct-1997 15:03:14-GMT,2094;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id IAA05698 for ; Mon, 27 Oct 1997 08:03:13 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id PAA24461 for ; Mon, 27 Oct 1997 15:01:55 GMT Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Mon, 27 Oct 1997 14:15:15 +0000 Date: Mon, 27 Oct 1997 14:04:16 +0000 Message-ID: <588-Mon27Oct1997140416+0000-s.rahtz@elsevier.co.uk> From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: alanje@cogs.susx.ac.uk Cc: vieth@thphy.uni-duesseldorf.de, math-font-discuss@cogs.susx.ac.uk, tex-fonts@csc-sun.math.utah.edu Subject: Re: fontinst/mathptm: bug in OMX.etx In-Reply-To: References: <199710271118.MAA18870@macbeth.uni-duesseldorf.de> <199710271215.MAA02744@knott.elsevier.co.uk> X-Mailer: VM 6.33 under Emacs 19.34.6 Alan Jeffrey writes: > > and hand it over to someone else (er, eg you)? I'd originally thought > it would only take me a couple of years being a lecturer to get some > free time back, but I think that was wildly optimistic of me, and I looking forward to retirement? arent you due a sabbatical yet? havent got a tame PhD student yet?... > should just hand the software over to someone who will actively > maintain it. The current situation is certainly not good! i wish i could say "i claim this pore baby", but (to be honest) I would prefer it if someone else did. as this stands for me at present, i can't promise to do whats needed, ie update the fontinst documentation and merge finst back into fontinst. does anyone else want to have a crack at a new unified fontinst setup? sebastian 27-Oct-1997 17:52:52-GMT,1980;000000000000 Return-Path: Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id KAA10078 for ; Mon, 27 Oct 1997 10:52:51 -0700 (MST) Received: from streammachine.com (orchid.crisc.com [206.86.182.66]) by proxy4.ba.best.com (8.8.7/8.8.BEST) with SMTP id JAA22512 for ; Mon, 27 Oct 1997 09:50:55 -0800 (PST) Received: from micky.crisc ([206.86.182.71]) by streammachine.com (4.1/SMI-4.1) Received: by streammachine.com (4.1/SMI-4.1) id AA10514; Mon, 27 Oct 97 09:50:06 PST Received: by micky.crisc (SMI-8.6/SMI-SVR4) id JAA00202; Mon, 27 Oct 1997 09:50:00 -0800 From: kk@streammachine.com (Konstantino Konstantinides) Message-Id: <199710271750.JAA00202@micky.crisc> Subject: Old dvips fonts To: tex-fonts@csc-sun.math.utah.edu Date: Mon, 27 Oct 1997 09:49:59 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi there With old latex, I was using the old dvips fonts % The standard 35 fonts built in to almost all (but very old) PostScript % printers, plus a few variants afm2tfm can construct. rpagk AvantGarde-Book rpagko AvantGarde-BookOblique rpagd AvantGarde-Demi rpagdo AvantGarde-DemiOblique .... These fonts seem to be missing with the new latex2e distribution. However, I have no more access to my old latex209 and I need exactly the same fonts, because they were used to print a book so changes have to be made with the exact font. A couple of questions. Is it enough to have the old *tfm files so that I can reinstall unter latex2e? (I only need them in compatibility mode) How can I reinstall these old fonts? If this is impossible, how one can get the old latex209. It is considered obsolete and CTAN sites do not have it any more. Any other help/suggestions you can provide is welcome. K. Konstantinides kk@streammachine.com 28-Oct-1997 1:51:04-GMT,1719;000000000000 Return-Path: Received: from rsunx.crn.cogs.susx.ac.uk (root@rsunx-gw.susx.ac.uk [139.184.48.12]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id SAA21701; Mon, 27 Oct 1997 18:51:02 -0700 (MST) Received: from localhost (1118 bytes) by rsunx.crn.cogs.susx.ac.uk via sendmail with P:stdio/D:includelists/R:bind/T:smtp (sender: ) (ident using unix) id for ; Tue, 28 Oct 1997 01:45:59 +0000 (GMT) (Smail-3.2.0.97 1997-Aug-19 #9 built 1997-Oct-3) Message-Id: Date: Tue, 28 Oct 1997 01:45:59 +0000 (GMT) From: Alan Jeffrey To: s.rahtz@elsevier.co.uk (Sebastian Rahtz) Cc: alanje@cogs.susx.ac.uk, vieth@thphy.uni-duesseldorf.de, math-font-discuss@cogs.susx.ac.uk, tex-fonts@csc-sun.math.utah.edu Subject: Re: fontinst/mathptm: bug in OMX.etx In-Reply-To: <588-Mon27Oct1997140416+0000-s.rahtz@elsevier.co.uk> References: <199710271118.MAA18870@macbeth.uni-duesseldorf.de> <199710271215.MAA02744@knott.elsevier.co.uk> <588-Mon27Oct1997140416+0000-s.rahtz@elsevier.co.uk> X-Mailer: VM 6.30 under 19.15 XEmacs Lucid Sebastian Rahtz writes: > looking forward to retirement? arent you due a sabbatical yet? havent > got a tame PhD student yet?... Unforunately my PhD student insists on doing work for money (albeit not very much money) or for what passes for glory in a thesis... > i wish i could say "i claim this pore baby", but (to be honest) I > would prefer it if someone else did. as this stands for me at present, Any takers? Poor orphaned software... Alan. 28-Oct-1997 2:27:26-GMT,1704;000000000000 Return-Path: Received: from wrath (serv1.is2.u-net.net [194.119.130.23]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id TAA22537 for ; Mon, 27 Oct 1997 19:27:24 -0700 (MST) Received: from [194.119.133.155] [194.119.133.155] by wrath with esmtp (Exim 1.62 #2) id 0xQ1D5-0005F2-00; Tue, 28 Oct 1997 02:16:48 +0000 X-Sender: rebecca-astrid@mail.u-net.com Message-Id: In-Reply-To: <588-Mon27Oct1997140416+0000-s.rahtz@elsevier.co.uk> References: <199710271118.MAA18870@macbeth.uni-duesseldorf.de> <199710271215.MAA02744@knott.elsevier.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Oct 1997 23:59:10 +0000 To: tex-fonts@csc-sun.math.utah.edu From: Rebecca and Rowland Subject: Re: fontinst/mathptm: bug in OMX.etx Cc: alanje@cogs.susx.ac.uk, s.rahtz@elsevier.co.uk s.rahtz@elsevier.co.uk (Sebastian Rahtz) [snip] >i wish i could say "i claim this pore baby", but (to be honest) I >would prefer it if someone else did. as this stands for me at present, >i can't promise to do whats needed, ie update the fontinst >documentation and merge finst back into fontinst. does anyone else >want to have a crack at a new unified fontinst setup? I'll have a crack at documentation if someone will help me figure out exactly what the blasted thing does in detail. I reckon that the job is a bit big for any one person to be happy to take it on on their own, and *I'm* certainly not well-equipped enough in the brain department to do any coding. Rowland. 28-Oct-1997 10:07:06-GMT,2324;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id DAA01786 for ; Tue, 28 Oct 1997 03:07:05 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id KAA25526 for ; Tue, 28 Oct 1997 10:05:40 GMT Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Tue, 28 Oct 1997 10:05:46 +0000 Date: Tue, 28 Oct 1997 09:44:22 +0000 Message-ID: <1423-Tue28Oct1997094422+0000-s.rahtz@elsevier.co.uk> From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rebecca@astrid.u-net.com Cc: tex-fonts@csc-sun.math.utah.edu, alanje@cogs.susx.ac.uk Subject: Re: fontinst/mathptm: bug in OMX.etx In-Reply-To: References: <199710271118.MAA18870@macbeth.uni-duesseldorf.de> <199710271215.MAA02744@knott.elsevier.co.uk> <588-Mon27Oct1997140416+0000-s.rahtz@elsevier.co.uk> X-Mailer: VM 6.33 under Emacs 19.34.6 Rebecca and Rowland writes: > I'll have a crack at documentation if someone will help me figure out > exactly what the blasted thing does in detail. you dont catch me out that easily, rowland.... > I reckon that the job is a bit big for any one person to be happy to take > it on on their own, and *I'm* certainly not well-equipped enough in the > brain department to do any coding. coding is not really an issue at present; the job is one of organisation, to go through all the files in the main fontinst distribution and check they are consistent with the code implemented in the bits of finst that are changed. also, importantly, talking with Alan to get a firm list of known problems and issues. i am happy to keep the baby in my house at present, warm and well-fed (especially since i had the temerity to publish a description of it), but i am not sure i should be responsible for choosing what school to send it to, and for detailed instruction as to its morals. sebastian 28-Oct-1997 10:26:15-GMT,2064;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id DAA02139 for ; Tue, 28 Oct 1997 03:26:14 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id KAA26265 for ; Tue, 28 Oct 1997 10:24:58 GMT Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Tue, 28 Oct 1997 10:25:37 +0000 Date: Tue, 28 Oct 1997 10:11:04 +0000 Message-ID: <6505-Tue28Oct1997101104+0000-s.rahtz@elsevier.co.uk> From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kk@streammachine.com Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: Old dvips fonts In-Reply-To: <199710271750.JAA00202@micky.crisc> References: <199710271750.JAA00202@micky.crisc> X-Mailer: VM 6.33 under Emacs 19.34.6 Konstantino Konstantinides writes: > These fonts seem to be missing with the new latex2e distribution. they never were part of the LaTeX distribution > Is it enough to have the old *tfm files so that I can reinstall unter > latex2e? (I only need them in compatibility mode) > How can I reinstall these old fonts? you dont need to. the current PSNFSS setup has metrics which should be identical. the names of the fonts in the dvips .map file are irrelevant, what matters is the names used in the .tex and .dvi file. you probably use "ptmr0" or "ptmr". these are supported vi virtual fonts these days. if you use rptmr directly in your .tex file, god help you. you have some work ahead. but it is nothing to do with latex2e vs 209 (unless i misunderstand the question) > If this is impossible, how one can get the old latex209. It is considered > obsolete and CTAN sites do not have it any more. > of course they do, look back at the top level for obsolete sebastian 28-Oct-1997 12:19:03-GMT,1706;000000000000 Return-Path: Received: from rsunx.crn.cogs.susx.ac.uk (root@rsunx-gw.susx.ac.uk [139.184.48.12]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id FAA04033 for ; Tue, 28 Oct 1997 05:19:02 -0700 (MST) Received: from localhost (1096 bytes) by rsunx.crn.cogs.susx.ac.uk via sendmail with P:stdio/R:bind/T:smtp (sender: ) (ident using unix) id for ; Tue, 28 Oct 1997 12:15:00 +0000 (GMT) (Smail-3.2.0.97 1997-Aug-19 #9 built 1997-Oct-3) Message-Id: Date: Tue, 28 Oct 1997 12:15:00 +0000 (GMT) From: Alan Jeffrey To: s.rahtz@elsevier.co.uk (Sebastian Rahtz) Cc: rebecca@astrid.u-net.com, tex-fonts@csc-sun.math.utah.edu, alanje@cogs.susx.ac.uk Subject: Re: fontinst/mathptm: bug in OMX.etx In-Reply-To: <1423-Tue28Oct1997094422+0000-s.rahtz@elsevier.co.uk> References: <199710271118.MAA18870@macbeth.uni-duesseldorf.de> <199710271215.MAA02744@knott.elsevier.co.uk> <588-Mon27Oct1997140416+0000-s.rahtz@elsevier.co.uk> <1423-Tue28Oct1997094422+0000-s.rahtz@elsevier.co.uk> X-Mailer: VM 6.30 under 19.15 XEmacs Lucid Sebastian Rahtz writes: > coding is not really an issue at present; the job is one of > organisation, Indeed, it's a matter of taking the current setup and cleaning it up, rewriting documentation, etc. etc. all dull stuff I'm afraid. I can answer specific technical questions but I can't really help do the big reorganization (if I could then I'd just do it myself :-) Alan, 28-Oct-1997 12:48:39-GMT,1260;000000000000 Return-Path: Received: from vms.rhbnc.ac.uk (alpha1.rhbnc.ac.uk [134.219.201.113]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id FAA04530 for ; Tue, 28 Oct 1997 05:48:31 -0700 (MST) Date: Tue, 28 Oct 1997 12:30:04 GMT From: "Philip Taylor (RHBNC) " Reply-To: Qhaa006@vms.rhbnc.ac.uk To: 4TeX@nic.surfnet.nl, CSTeX@cs.felk.cvut.cz, CyrTeX-t2@vvv.vsu.ru, Ellhnika@urz.uni-heidelberg.de, Emtex-User@physik.tu-berlin.de, Gust-L@Man.Torun.Pl, Gut@Ens.Fr, Info-TeX@shsu.edu, Italic-L@irlearn.ucd.ie CC: QHAA006@vms.rhbnc.ac.uk X-Vmsmail-To: @TEX-LISTS X-Vmsmail-Cc: QHAA006 Message-Id: <971028123004.2b8df@vms.rhbnc.ac.uk> Subject: EuroTeX'98: last Call for Papers Final Call for Papers: the 1998 EuroTeX Conference at St Malo, France. Dear Colleague -- apologies if you receive multiple copies of this message, but time is short and we must circulate as many TeX lists as possible before the Call for Papers closes. Please see http://www.ens.fr/gut/manif/eurotex98/ for the official announcement of EuroTeX'98; the Call for Papers closes on Monday 3rd November 1997. Philip Taylor, for the EuroTeX'98 Programme Committee. 28-Oct-1997 14:05:40-GMT,1261;000000000000 Return-Path: Received: from math.ams.org (math.ams.org [130.44.210.14]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id HAA06026 for ; Tue, 28 Oct 1997 07:05:39 -0700 (MST) Received: from axp14.ams.org by math.ams.org via smtpd (for csc-sun.math.utah.edu [128.110.198.2]) with SMTP; 28 Oct 1997 14:05:38 UT Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V5.1-8 #1) id <01IPC248J04W000D9H@AXP14.AMS.ORG> for tex-fonts@math.utah.edu; Tue, 28 Oct 1997 09:05:24 EST Date: Tue, 28 Oct 1997 09:05:23 -0500 (EST) From: bbeeton Subject: Re: fontinst/mathptm: bug in OMX.etx In-reply-to: To: Alan Jeffrey Cc: s.rahtz@elsevier.co.uk, vieth@thphy.uni-duesseldorf.de, math-font-discuss@cogs.susx.ac.uk, tex-fonts@csc-sun.math.utah.edu Message-id: <878047523.911270.BNB@MATH.AMS.ORG> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Mail-system-version: regarding fontinst, if there are no other takers, alan -- would you like to put a request for adoption into the december issue of tugboat? we'd need copy by about november 20. -- bb 29-Oct-1997 7:37:17-GMT,2124;000000000000 Return-Path: Received: from wrath (serv1.is2.u-net.net [194.119.130.23]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id AAA28546 for ; Wed, 29 Oct 1997 00:37:15 -0700 (MST) Received: from [194.119.133.114] [194.119.133.114] by wrath with esmtp (Exim 1.62 #2) id 0xQSTO-0002uH-00; Wed, 29 Oct 1997 07:23:27 +0000 X-Sender: rebecca-astrid@mail.u-net.com Message-Id: In-Reply-To: <1423-Tue28Oct1997094422+0000-s.rahtz@elsevier.co.uk> References: <199710271118.MAA18870@macbeth.uni-duesseldorf.de> <199710271215.MAA02744@knott.elsevier.co.uk> <588-Mon27Oct1997140416+0000-s.rahtz@elsevier.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Oct 1997 07:32:16 +0000 To: s.rahtz@elsevier.co.uk (Sebastian Rahtz) From: Rebecca and Rowland Subject: Re: fontinst/mathptm: bug in OMX.etx Cc: tex-fonts@csc-sun.math.utah.edu, alanje@cogs.susx.ac.uk At 9:44 am +0000 28/10/97, Sebastian Rahtz wrote: >Rebecca and Rowland writes: > > I'll have a crack at documentation if someone will help me figure out > > exactly what the blasted thing does in detail. >you dont catch me out that easily, rowland.... I had to try :-) Alan Jeffrey wrote: >Sebastian Rahtz writes: > > coding is not really an issue at present; the job is one of > > organisation, > >Indeed, it's a matter of taking the current setup and cleaning it up, >rewriting documentation, etc. etc. all dull stuff I'm afraid. I can >answer specific technical questions but I can't really help do the big >reorganization (if I could then I'd just do it myself :-) Hmm - well, I can do things to the documentation if someone can answer my questions - and there seems to be a volunteer for that (but you might like to check with Sebastian before committing yourself on this one). Is there anyone who could do something to clean things up etc? Rowland. 29-Oct-1997 10:01:51-GMT,2151;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id DAA01112 for ; Wed, 29 Oct 1997 03:01:50 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id KAA06312 for ; Wed, 29 Oct 1997 10:00:34 GMT Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Wed, 29 Oct 1997 10:01:31 +0000 Date: Wed, 29 Oct 1997 09:48:10 +0000 Message-ID: <296-Wed29Oct1997094810+0000-s.rahtz@elsevier.co.uk> From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rebecca@astrid.u-net.com Cc: tex-fonts@csc-sun.math.utah.edu, alanje@cogs.susx.ac.uk Subject: Re: fontinst/mathptm: bug in OMX.etx In-Reply-To: References: <199710271118.MAA18870@macbeth.uni-duesseldorf.de> <199710271215.MAA02744@knott.elsevier.co.uk> <588-Mon27Oct1997140416+0000-s.rahtz@elsevier.co.uk> <1423-Tue28Oct1997094422+0000-s.rahtz@elsevier.co.uk> X-Mailer: VM 6.33 under Emacs 19.34.6 Rebecca and Rowland writes: > Hmm - well, I can do things to the documentation if someone can answer my > questions - and there seems to be a volunteer for that (but you might like > to check with Sebastian before committing yourself on this one). Is there this is code for `expect a constant barrage of email whinging', Alan > anyone who could do something to clean things up etc? > i am happy to do whatever is specified in terms of code, probably with advice from others i suggest that if R&R has the time, he should go ahead and try and produce a revised documentation set (asking questions on this list or the fontinst list if it still exists), and i will make changes to the code as required sebastian 29-Oct-1997 10:59:51-GMT,4645;000000000000 Return-Path: Received: from thphy.uni-duesseldorf.de (xerxes.thphy.uni-duesseldorf.de [134.99.64.10]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id DAA02145 for ; Wed, 29 Oct 1997 03:59:49 -0700 (MST) Received: from macbeth.uni-duesseldorf.de (macbeth.thphy.uni-duesseldorf.de) by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA21799; Wed, 29 Oct 97 12:00:35 +0100 Received: by macbeth.uni-duesseldorf.de (SMI-8.6/SMI-SVR4) id LAA20171; Wed, 29 Oct 1997 11:59:29 +0100 Date: Wed, 29 Oct 1997 11:59:29 +0100 Message-Id: <199710291059.LAA20171@macbeth.uni-duesseldorf.de> To: s.rahtz@elsevier.co.uk Cc: rebecca@astrid.u-net.com, tex-fonts@csc-sun.math.utah.edu, alanje@cogs.susx.ac.uk Cc: clasen@pong.mathematik.uni-freiburg.de In-Reply-To: <296-Wed29Oct1997094810+0000-s.rahtz@elsevier.co.uk> Subject: Re: fontinst/mathptm: bug in OMX.etx From: Ulrik Vieth Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sebastian Rahtz: > i suggest that if R&R has the time, he should go ahead and try and > produce a revised documentation set (asking questions on this list or > the fontinst list if it still exists), and i will make changes to the > code as required While we are at it, I'd like to point out that the recent work on math fonts also produced a few small extensions to fontinst (by Matthias Clasen) which facilitate writing .etx and .mtx files. It would be nice if those extensions, at least the essential ones, could find their way into the primary fontinst distrubtion as well. As for documentation, the code below allows to write something like \useexamplefont{} \setdefaultslotcomment{The symbol `\slotexample'.} \setslot{}\endsetslot \setslot{}\endsetslot \setslot{}[The letter `\slotexample'.]\endsetslot \setslot{}\endsetslot instead of the more tedious \usepackage{} \setslot{} \comment{The symbol `$\somesymbol$'.} \endsetslot \setslot{} \comment{The symbol `$\anothersymbol$'.} \endsetslot \setslot{} \comment{The letter `\letter'.} \endsetslot I hope the basic idea of this should be clear. Cheers, Ulrik, - - - - - - - - - - - - - - - - \RequirePackage{fontdoc} \ProvidesPackage{emfntdoc}[1997/04/03 small extensions to fontdoc] \newcommand{\useexamplefont}[1]{\def\fontname{#1}\font\@examplefont=#1} \newcommand{\setdefaultslotcomment}[1]{\def\default@slotcomment{#1}} \newcommand{\slotexample}{{\@examplefont\char\the\slot@number}} \newcommand{\setslot@comment}[1][\default@slotcomment]{\comment{#1}} \let\setslotorig=\setslot \let\endsetslotorig=\endsetslot \renewcommand{\setslot}[1]{\setslotorig{#1}\setslot@comment} \renewcommand{\endsetslot}{\endsetslotorig} \useexamplefont{cmr10} \setdefaultslotcomment{The symbol `\slotexample'.} - - - - - - - - - - - - - - - - \RequirePackage{fontinst} \ProvidesPackage{emfninst}[1997/04/03 small extensions to fontinst] \newcommand{\slotexample}{} \newcommand{\useexamplefont}[1]{} \newcommand{\setdefaultslotcomment}[1]{} \newcommand{\setslot@comment}[1][]{} \let\setslot@orig=\setslot \renewcommand{\setslot}[1]{\setslot@orig{#1}\setslot@comment} \newcommand{\missingglyph}[1]{ \setglyph{#1} \glyphrule{666}{666} \resetheight{0} % avoid problems with too many depths or heights \resetdepth{0} \glyphwarning{missing glyph} \endsetglyph } \newcommand{\controlglyph}[1]{ \setglyph{#1} \glyphrule{333}{333} \resetheight{0} % avoid problems with too many depths or heights \resetdepth{0} \glyphwarning{control glyph} \endsetglyph } \newcommand{\emptyglyph}[1]{\setglyph{#1}\endsetglyph} \newcommand{\replaceglyph}[2]{\setglyph{#1}\glyph{#2}{1000}\endsetglyph} % the proposed encodings \declareencoding{MATH CORE}{MC} \declareencoding{MATH EXTENSION 1}{MX1} \declareencoding{MATH EXTENSION 2}{MX2} \declareencoding{MATH SYMBOL PRIVILEDGE}{MSP} \declareencoding{MATH SYMBOL 1}{MS1} \declareencoding{MATH SYMBOL 2}{MS2} % additional encodings \declareencoding{LATEX SYMBOLS}{lasy} % for lasy fonts \declareencoding{TEX MATH ITALIC SUBSET}{eurm} % for Euler roman fonts \declareencoding{TEX TEXT SUBSET}{eufrak} % for Euler fraktur fonts \declareencoding{TEX MATH SYMBOLS SUBSET}{euscr} % for Euler script fonts \declareencoding{EULER SUBSTITUTIONS ONLY}{euex} % for Euler extension fonts - - - - - - - - - - - - - - - - 30-Oct-1997 7:14:03-GMT,1952;000000000000 Return-Path: Received: from wrath (serv1.is2.u-net.net [194.119.130.23]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id AAA27537 for ; Thu, 30 Oct 1997 00:14:02 -0700 (MST) Received: from [194.119.134.162] [194.119.134.162] by wrath with esmtp (Exim 1.62 #2) id 0xQodj-0001Le-00; Thu, 30 Oct 1997 07:03:35 +0000 X-Sender: rebecca-astrid@mail.u-net.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Oct 1997 07:13:50 +0000 To: tex-fonts@csc-sun.math.utah.edu, alanje@cogs.susx.ac.uk From: Rebecca and Rowland Subject: Re: fontinst/mathptm: bug in OMX.etx >Rebecca and Rowland writes: > > Hmm - well, I can do things to the documentation if someone can answer my > > questions - and there seems to be a volunteer for that (but you might like > > to check with Sebastian before committing yourself on this one). Is there > >this is code for `expect a constant barrage of email whinging', Alan :-)) > > anyone who could do something to clean things up etc? > > >i am happy to do whatever is specified in terms of code, probably with >advice from others Hehehehe >i suggest that if R&R has the time, he should go ahead and try and >produce a revised documentation set Ungh - I'll give it a go. I'm not really short of time at the moment; I am short of days on which I'm sane enough to do anything constructive. But the only way to see what happens is to give it a go. Is anyone interested in giving me feedback on what I write, and/or ideas on what needs to be in the documentation and/or changes needed to what's currently available? > (asking questions on this list or >the fontinst list if it still exists), If this list exists, could anyone provide details of where it is and how to subscribe? > and i will make changes to the >code as required Goody! Rowland. 30-Oct-1997 13:34:20-GMT,1457;000000000000 Return-Path: Received: from rsunx.crn.cogs.susx.ac.uk (root@rsunx-gw.susx.ac.uk [139.184.48.12]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id GAA03820 for ; Thu, 30 Oct 1997 06:34:19 -0700 (MST) Received: from localhost (852 bytes) by rsunx.crn.cogs.susx.ac.uk via sendmail with P:stdio/R:bind/T:smtp (sender: ) (ident using unix) id for ; Thu, 30 Oct 1997 13:33:59 +0000 (GMT) (Smail-3.2.0.97 1997-Aug-19 #9 built 1997-Oct-3) Message-Id: Date: Thu, 30 Oct 1997 13:33:59 +0000 (GMT) From: Alan Jeffrey To: Rebecca and Rowland Cc: tex-fonts@csc-sun.math.utah.edu, alanje@cogs.susx.ac.uk Subject: Re: fontinst/mathptm: bug in OMX.etx In-Reply-To: References: X-Mailer: VM 6.30 under 19.15 XEmacs Lucid Rebecca and Rowland writes: > >this is code for `expect a constant barrage of email whinging', Alan > > :-)) :-) By answer questions I meant specific quesions on technical points (and not very many of them...) I'm trying to practice the art of successful delegation here... To get on the fontinst mailing list (really this discussion should be there) you mail me. Since you've already done so, I'll add you. Alan. 12-Nov-1997 18:54:27-GMT,1783;000000000000 Return-Path: Received: from tug.cs.umb.edu (root@tug.cs.umb.edu [158.121.106.10]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id LAA26036 for ; Wed, 12 Nov 1997 11:54:25 -0700 (MST) From: hafner@almaden.ibm.com Received: from mailgw1.almaden.ibm.com (mailgw1.almaden.ibm.com [198.4.83.39]) by tug.cs.umb.edu (8.8.0/8.8.0) with SMTP id PAA20216 for ; Wed, 12 Nov 1997 15:06:14 -0500 Received: by mailgw1.almaden.ibm.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 8825654D.0067D97C ; Wed, 12 Nov 1997 10:54:18 -0800 X-Lotus-FromDomain: ALMADEN To: tex-fonts@tug.cs.umb.edu Message-ID: <8825654D.00671A35.00@mailgw1.almaden.ibm.com> Date: Wed, 12 Nov 1997 10:53:56 -0800 Subject: New mode_def (sort of) for modes.mf Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Greetings, There doesn't seem to be a mode_def in the current version of modes.mf (3.2) for the Lexmark 4039 printers (600dpi). There's also a version of this printer called the IBM 4039 (I think). We've found that the IBMFourZeroTwoNine mode (ibmfztn) works just fine with one caveat. It is recommended that the printer be configured with it's "Printer Darkness" set to "darker". So, I suggest 1) adding the lines IBMFourZeroThreeNine := ibmfztn LexmarkFourZeroThreeNine := ibmfztn to the file at around line 1278. 2) Adding some comment about "darker" to the same stanza Alternatives are to do extensive testing with blacker set higher but those of us with IBM 4029's and Lexmark 4039's don't really need two sets of 600dpi fonts (so we share them with the cavet above). Thanks, Jim Hafner hafner@almaden.ibm.com "And your wise men don't know how it feels/to be thick as a brick" Jethro Tull 20-Nov-1997 18:56:07-GMT,1494;000000000000 Return-Path: Received: from wrath (serv1.is2.u-net.net [194.119.130.23]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA20103 for ; Thu, 20 Nov 1997 11:56:05 -0700 (MST) Received: from [194.119.133.114] [194.119.133.114] by wrath with esmtp (Exim 1.62 #2) id 0xYbat-00075f-00; Thu, 20 Nov 1997 18:44:51 +0000 X-Sender: rebecca-astrid@mail.u-net.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Nov 1997 15:44:30 +0000 To: tex-fonts@csc-sun.math.utah.edu From: Rebecca and Rowland Subject: Fount encodings, dvi drivers, and stuff A question: If you use fontinst to install a new fount for use with LaTeX, and re-encode it to 8r encoding to begin with, what happens at the dvi driver end? As I understand it, when you install founts using fontinst 1.6 and \latinfamily, you get an 8r encoded .tfms to begin with, which are pointed at as the `final' founts by the .vf files etc. I think this means that the dvi driver has to map the glyph numbers requested in the dvi file to the appropriate slots in the `real' fount file. So that a request for glyph number 182 (para mark) by the dvi file (assuming 8r encoding) means that the dvi driver will actually present glyph number 166 (assuming Mac encoding) to the output device? Is that right? Rowland. (whose head is hurting writing this fontinst documentation) 21-Nov-1997 13:13:33-GMT,3683;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id GAA12839 for ; Fri, 21 Nov 1997 06:13:32 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with ESMTP id IAA28124; Fri, 21 Nov 1997 08:13:25 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA11030; Fri, 21 Nov 1997 08:13:23 -0500 (EST) Date: Fri, 21 Nov 1997 08:13:23 -0500 (EST) Message-Id: <199711211313.IAA11030@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: rebecca@astrid.u-net.com CC: tex-fonts@csc-sun.math.utah.edu In-reply-to: (message from Rebecca and Rowland on Thu, 20 Nov 1997 15:44:30 +0000) Subject: Re: Fount encodings, dvi drivers, and stuff Reply-to: bkph@ai.mit.edu Hi: If you use fontinst to install a new fount for use with LaTeX, and re-encode it to 8r encoding to begin with, what happens at the dvi driver end? With that scheme, the DVI driver reencodes the font to 8r rather than to the encoding used in TeX (T1, LY1, or whatever). As I understand it, when you install founts using fontinst 1.6 and \latinfamily, you get an 8r encoded .tfms to begin with, which are pointed at as the `final' founts by the .vf files etc. This is the `two TFMs plus one VF per font' scheme. The TFM file that TeX sees is set up according to the user chosen encoding (T1, LY1, or whatever). The other TFM file is set up for 8r. The VF file maps character codes in T1 to character codes in 8r. I think this means that the dvi driver has to map the glyph numbers requested in the dvi file to the appropriate slots in the `real' fount file. No, it normally doesn't remap the DVI character codes, but instead changes the encoding in the font. The font has an encoding vector, which lists for each character code what glyph to draw. (There *are* actually situtations where remapping at the DVI driver level is required to work around bugs in other software like Adobe Illustrator, Acrobat Reader etc. but DVIPS doesn't support this). So that a request for glyph number 182 (para mark) by the dvi file (assuming 8r encoding) means that the dvi driver will actually present glyph number 166 (assuming Mac encoding) to the output device? No. The DVI file uses character codes in T1 (or LY1). So your example is poorly chosen since T1 does not include paragraph (and about 38 other useful glyphs). Lets instead take `sterling' (\pound). This is character code 191 in T1, so 191 is the character code that will actually appear in the DVI file. Now in 8r, `sterling' is at 163. So the only purpose of the VF file is to remap character code 191 to 163 Note that since VF like TFM deals only with character codes it cannot really reencode a font (e.g. make unencoded characters accessible). It can only rearrange the character layout. Finally, the font has its own encoding, where `sterling' may be elsewhere (or not even accessible). It is the DVI drivers job to reencode the font so that character code 163 is linked to the program that draws the pound sign. This is quite easy to do in PostScript, and in the case of DVIPS is set up in psfonts.map. Pretty complicated, and while it has some advantages over the `one TFM file per font and no VF' scheme, it seems mostly to have disadvantages. Rowland. (whose head is hurting writing this fontinst documentation) Will it be called the `fountinst' documentation :-)? Regards, Berthold. 21-Nov-1997 18:33:26-GMT,1207;000000000000 Return-Path: Received: from wrath (serv1.is2.u-net.net [194.119.130.23]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id LAA20556 for ; Fri, 21 Nov 1997 11:33:25 -0700 (MST) Received: from [194.119.133.110] [194.119.133.88] by wrath with esmtp (Exim 1.62 #2) id 0xYxig-0005WI-00; Fri, 21 Nov 1997 18:22:23 +0000 X-Sender: rebecca-astrid@mail.u-net.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Nov 1997 15:30:25 +0000 To: tex-fonts@csc-sun.math.utah.edu From: Rebecca and Rowland Subject: Re: Fount encodings, dvi drivers, and stuff Thanks to everyone who replied to my query (I've only received the direct replies because the tex-fonts mailing list has my email address wrong :-( ) I think I understand what's going on now... And (for the curious), I'm documenting fontinst, which helps you install founts. (I've always spelt `fount' that way, and I'm damned if I'm changing just because every other English speaking person in the world has gone American; but `fontinst' is called `fontinst', and that's that). Rowland. 24-Nov-1997 22:55:23-GMT,4513;000000000000 Return-Path: Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id PAA07867; Mon, 24 Nov 1997 15:55:22 -0700 (MST) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id PAA26491; Mon, 24 Nov 1997 15:55:22 -0700 (MST) Date: Mon, 24 Nov 1997 15:55:22 -0700 (MST) To: tex-fonts@csc-sun.math.utah.edu Cc: beebe@csc-sun.math.utah.edu X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: [Mark Leisher : Unicode BDF fonts available] Message-ID: Folks, this interesting announcement about an extension of Computer Modern into the Unicode character set just came in on the unicode list; perhaps some of you may wish to investigate further: --------------- Received: from public.lists.apple.com (A17-254-0-151.apple.com [17.254.0.151]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id MAA03142 for ; Mon, 24 Nov 1997 12:49:24 -0700 (MST) Received: from unicode.org (A17-254-3-212.apple.com [17.254.3.212]) by public.lists.apple.com (8.8.5/8.8.5) with SMTP id LAA24840 ; Mon, 24 Nov 1997 11:47:04 -0800 Received: by unicode.org (NX5.67g/NX3.0S) id AA11717; Mon, 24 Nov 97 11:23:42 -0800 Message-Id: <9711241923.AA11717@unicode.org> Errors-To: uni-bounce@unicode.org X-Uml-Sequence: 4545 (1997-11-24 19:23:38 GMT) To: Multiple Recipients of Reply-To: unicode@unicode.org From: Mark Leisher Date: Mon, 24 Nov 1997 11:23:37 -0800 (PST) Subject: Unicode BDF fonts available MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Transfer-Encoding: 8bit Over the last year I have been working on a single typeface which can be used to render Unicode text. The typeface is intended for presenting truly multilingual text on Web pages, particularly for dense academic papers/texts that liberally mix languages. I have been distracted recently by "real" work and am unable to do much more work on the fonts. So I decided to put the fonts out so others can use them or work on them if they wish. The typeface is 12pt, 100dpi, proportional, and heavily influenced by Donald Knuth's Computer Modern. There are about 3100 glyphs at the moment in four fonts. Some of the glyphs are in the Private Use Area and may need to be moved if they conflict with other Unicode support systems. I am not an expert in many of these scripts, so please feel free to send me changes if you see something wrong. Also feel free to add glyphs to the fonts. I would appreciate a copy of any additions made. The fonts have not actually been tested in Web pages yet, so more work will probably be needed to adjust the glyph spacing. The fonts are available at: ftp://crl.nmsu.edu/CLR/multiling/unicode/fonts/cu12.tar.gz If you need a BDF font editor: [Sources] ftp://crl.nmsu.edu/CLR/multiling/General/xmbdfed.tar.gz [Binaries: Linux, Solaris, SunOS] ftp://crl.nmsu.edu/CLR/multiling/General/xmbdfed-2.7-ELF.tar.gz ftp://crl.nmsu.edu/CLR/multiling/General/xmbdfed-2.7-SOLARIS.tar.gz ftp://crl.nmsu.edu/CLR/multiling/General/xmbdfed-2.7-SUNOS.tar.gz ------------------------------------------------------------------------ mleisher@crl.nmsu.edu Mark Leisher "A designer knows he has achieved perfection Computing Research Lab not when there is nothing left to add, but New Mexico State University when there is nothing left to take away." Box 30001, Dept. 3CRL -- Antoine de Saint-Exupéry Las Cruces, NM 88003 ---------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 105 JWB beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ---------------------------------------------------------------------------- 25-Nov-1997 22:09:27-GMT,1945;000000000000 Return-Path: Received: from shodan.in-trier.de (root@shodan.in-trier.de [198.22.51.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id PAA07193 for ; Tue, 25 Nov 1997 15:09:24 -0700 (MST) Received: from hal9000 (arno@hal9000.in-trier.de [198.22.51.231]) by shodan.in-trier.de (8.8.5/8.8.5) with SMTP id AAA13662; Wed, 26 Nov 1997 00:22:28 +0100 Sender: arno@shodan.in-trier.de Message-ID: <347B5A49.4FDA1D0D@in-trier.de> Date: Wed, 26 Nov 1997 00:07:53 +0100 From: Arno Wagner Reply-To: Arno Wagner X-Mailer: Mozilla 3.0 (X11; I; Linux 2.0.25 i586) MIME-Version: 1.0 To: tex-fonts@csc-sun.math.utah.edu Subject: Mf mode for Epson Stylus color 600 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I made a mode for the Epson Stylus color 600 in 720 dpi. The added lines in 'modes.mf' are: % {\tt arno.wagner@acm.org}, Epson Stylus color 600, 25. November 1997. % In my opinion, the quality when printing 720 dpi is excellent. % If you want to print in 360dpi (much faster) use the 'epstylus' mode % instead. This printer seems to make smaller dots when printing in % 720 dpi and larger ones when printing in 360 dpi. I tried 720x1440 % resolution as well, but found it not worth the additional time. % Note that if you use Ghostscript, you need at least version 5.03 to % support 720 dpi on this printer. This mode may work with the % Epson Stylus color 800 as well. % I tested this mode with the test of Matt Swift, which can be found % above. mode_def epstcsixzerozero = %\[ Epson Stylus Color 600 (720 dpi) mode_param (pixels_per_inch, 720); mode_param (blacker, .25); mode_param (fillin, 0.5); %\[ no '\' in Matt Swift's test in 5pt when = 0 mode_param (o_correction, .8); mode_common_setup_; enddef; I would be happy to contribute this to all users of Metafont. Regards Arno Wagner 25-Nov-1997 22:22:41-GMT,2318;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id PAA07530 for ; Tue, 25 Nov 1997 15:22:40 -0700 (MST) Received: from alonzo.cs.sfu.ca (alonzo [199.60.3.17]) by cs.sfu.ca (8.8.8/8.8.8) with ESMTP id OAA13960 for ; Tue, 25 Nov 1997 14:22:39 -0800 (PST) From: "Melissa O'Neill" Received: (from oneill@localhost) by alonzo.cs.sfu.ca (8.8.8/8.8.5) id OAA05673 for tex-fonts@math.utah.edu; Tue, 25 Nov 1997 14:22:37 -0800 (PST) Message-Id: <199711252222.OAA05673@alonzo.cs.sfu.ca> Subject: Request for experience, MM fonts and LaTeX... (esp. Kepler) To: tex-fonts@csc-sun.math.utah.edu Date: Tue, 25 Nov 1997 14:22:36 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I've recently purchased Adobe's new MM font, Kepler, and am about to begin trying to get it to work elegantly with TeX. I know there is a TUGboat article on MM fonts and TeX that I can (and will) read, and generally I understand PostScript, fonts, TeX and the like, but, it only makes sense to ask all among the community of other tex-fonts people before embarking on this task. For example, recent MM fonts have may use specialized calculations for the NormalizeWeightVector and ConvertWeightVector, which existing tools may have problems with. Both of the MM blended-afm tools I have choked on Kepler, but I fixed that in one by making it go out and actually pass the font to a PostScript interpreter and get it to figure out the correct WeightVector. Similarly, I wonder if there is a name in the TeX font naming scheme for Kepler yet? I'd probably choose `pkp', if it's not already taken or another name isn't already assigned. Anyway, if you have have relevant experience you'd like to share, or if you'd like to suggest articles I might find on topics relevant to this endeavour, please let me know... Best Regards, Melissa. P.S. I'm using the standard LaTeX/DVIPS combination, but for previewing I use TeXview (under NEXTSTEP) which supports PostScript matters identically to dvips, so I don't have to worry about making PK fonts for a previewer, which is one challenge I get to avoid. 26-Nov-1997 10:00:25-GMT,2145;000000000000 Return-Path: Received: from atena.eurocontrol.fr (atena.uneec.eurocontrol.fr [147.196.69.10]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id DAA21576 for ; Wed, 26 Nov 1997 03:00:11 -0700 (MST) Received: by atena.eurocontrol.fr; (5.65v3.2/1.3/10May95) id AA12366; Wed, 26 Nov 1997 10:59:01 +0100 Received: from wotan.eurocontrol.fr by eurocontrol.fr with ESMTP (1.37.109.16/16.2) id AA147048143; Wed, 26 Nov 1997 10:55:43 +0100 Received: (from lab@localhost) by wotan.eurocontrol.fr (8.7.1/8.7.1) id KAA03361; Wed, 26 Nov 1997 10:57:11 +0100 (MET) Message-Id: <19971126105710.40956@eurocontrol.fr> Date: Wed, 26 Nov 1997 10:57:11 +0100 From: Christophe Labouisse To: "Melissa O'Neill" Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: Request for experience, MM fonts and LaTeX... (esp. Kepler) References: <199711252222.OAA05673@alonzo.cs.sfu.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.84e In-Reply-To: <199711252222.OAA05673@alonzo.cs.sfu.ca>; from Melissa O'Neill on Tue, Nov 25, 1997 at 02:22:36PM -0800 There was an article (in french sorry) by Thierry Bouche in Les Cahiers de GUTenberg describing how to install MM fonts for TeX (the example was MinionMM). To create instance of the font the authour used ATM on Windows then ghostscript to get the afm and finally merges the metrics from ghostscript with the kerning pairs from the .PFM file. It's quite cumbersome but I think that it should work with Kepler. > P.S. I'm using the standard LaTeX/DVIPS combination, but for previewing > I use TeXview (under NEXTSTEP) which supports PostScript matters > identically to dvips, so I don't have to worry about making PK fonts > for a previewer, which is one challenge I get to avoid. gsftopk handle gracefully MM fonts. -- Christophe Labouisse Eurocontrol Experimental Centre e-mail: lab@eurocontrol.fr BP 15 Phone: +33 - 01 69 88 73 55 91222 Brétigny-Sur-Orge Fax: +33 - 01 69 88 73 33 FRANCE 26-Nov-1997 10:09:37-GMT,2736;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id DAA21764 for ; Wed, 26 Nov 1997 03:08:52 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.8.5/8.8.5) with ESMTP id LAA07884; Wed, 26 Nov 1997 11:08:46 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id LAA21776; Wed, 26 Nov 1997 11:19:06 +0100 (MET) Date: Wed, 26 Nov 1997 11:19:06 +0100 (MET) Message-Id: <199711261019.LAA21776@mozart.ujf-grenoble.fr> From: Thierry Bouche To: "Melissa O'Neill" Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: Request for experience, MM fonts and LaTeX... (esp. Kepler) In-Reply-To: <199711252222.OAA05673@alonzo.cs.sfu.ca> References: <199711252222.OAA05673@alonzo.cs.sfu.ca> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Request for experience, MM fonts and LaTeX... (esp. Kepler) », Melissa O'Neill écrit : hello, i've put my personnal experience (with Minion) in a GUTenberg paper [french!] (ftp://fourier.ujf-grenoble.fr/pub/contrib-tex/gut/minion-pk.ps.gz) There does exist now an ideal software that didn't exist at that time, it's mmafm & mmpfb, two utilities by Eddie Kohler that respectively generate an AFM from AMFMs+master AFMs and a `snapshot' making the corresponding monomaster PFB. Both were designed to work with intermediate masters and are reported to work with them. Look at http://www.pdos.lcs.mit.edu/~eddietwo/type/ « « Similarly, I wonder if there is a name in the TeX font naming scheme for « Kepler yet? I'd probably choose `pkp', if it's not already taken or another « name isn't already assigned. if you look at my above mentionned paper, you'll see i have a berry naming scheme of my own for MM fonts, that does not match others (like in the LGC for instance)... « Anyway, if you have have relevant experience you'd like to share, or if « you'd like to suggest articles I might find on topics relevant to this « endeavour, please let me know... « this _should_ not be an endeavour! « making PK fonts « for a previewer, which is one challenge I get to avoid. not really a challenge when you have gs+gsftopk, simply something that should be avoided in the long term... BTW did people try out the patched xdvi that uses the type 1 X rasterizer? Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 26-Nov-1997 13:02:40-GMT,2638;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id GAA24702 for ; Wed, 26 Nov 1997 06:02:40 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with ESMTP id IAA01958; Wed, 26 Nov 1997 08:02:38 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA13491; Wed, 26 Nov 1997 08:02:36 -0500 (EST) Date: Wed, 26 Nov 1997 08:02:36 -0500 (EST) Message-Id: <199711261302.IAA13491@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: oneill@cs.sfu.ca CC: tex-fonts@csc-sun.math.utah.edu In-reply-to: <199711252222.OAA05673@alonzo.cs.sfu.ca> (oneill@cs.sfu.ca) Subject: Re: Request for experience, MM fonts and LaTeX... (esp. Kepler) Reply-to: bkph@ai.mit.edu Hi: I've recently purchased Adobe's new MM font, Kepler, and am about to begin trying to get it to work elegantly with TeX. I know there is a TUGboat article on MM fonts and TeX that I can (and will) read, and generally I understand PostScript, fonts, TeX and the like, but, it only makes sense to ask all among the community of other tex-fonts people before embarking on this task. For example, recent MM fonts have may use specialized calculations for the NormalizeWeightVector and ConvertWeightVector, which existing tools may have problems with. Both of the MM blended-afm tools I have choked on Kepler, but I fixed that in one by making it go out and actually pass the font to a PostScript interpreter and get it to figure out the correct WeightVector. It is annoying that there are no human readable metric files supplied with MM fonts. Otherwise it would be easier to do this part. But it isn't actually needed by all systems that can handle MM. With Y&Y TeX System :-) e.g. you just install the font using Adobe Type Manager (ATM), create the instances you want with ATM, then select the encoding you want to use from the previewer menu, and finally select `Fonts > WriteTFM...' and off you go. One minor problem is that under Windows NT, ATM no longer uses those cute stub PSS files that it used to. But it is pretty easy to get along without them. Similarly, I wonder if there is a name in the TeX font naming scheme for Kepler yet? I'd probably choose `pkp', if it's not already taken or another name isn't already assigned. I just use the actual font file names :-) Berthold. DISCLAIMER: respondent has connections with http://www.YandY.com 26-Nov-1997 17:11:07-GMT,1296;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id KAA00416; Wed, 26 Nov 1997 10:11:06 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with ESMTP id MAA13443; Wed, 26 Nov 1997 12:10:57 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id MAA13733; Wed, 26 Nov 1997 12:10:55 -0500 (EST) Date: Wed, 26 Nov 1997 12:10:55 -0500 (EST) Message-Id: <199711261710.MAA13733@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: beebe@csc-sun.math.utah.edu CC: tex-fonts@csc-sun.math.utah.edu, beebe@csc-sun.math.utah.edu In-reply-to: Subject: Re: [Mark Leisher : Unicode BDF fonts available] Reply-to: bkph@ai.mit.edu "Nelson H. F. Beebe" write: Folks, this interesting announcement about an extension of Computer Modern into the Unicode character set just came in on the unicode list; perhaps some of you may wish to investigate further: > If you need a BDF font editor: Too bad its in some obscure 100dpi bitmapped format :-) Berthold. 26-Nov-1997 18:04:15-GMT,1838;000000000000 Return-Path: Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id LAA01721; Wed, 26 Nov 1997 11:04:14 -0700 (MST) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id LAA09218; Wed, 26 Nov 1997 11:04:13 -0700 (MST) Date: Wed, 26 Nov 1997 11:04:13 -0700 (MST) To: bkph@ai.mit.edu Cc: beebe@csc-sun.math.utah.edu, tex-fonts@csc-sun.math.utah.edu X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Re: [Mark Leisher : Unicode BDF fonts available] In-Reply-To: Your message of Wed, 26 Nov 1997 12:10:55 -0500 (EST) Message-ID: >> Too bad its in some obscure 100dpi bitmapped format :-) I think the posting said BDF, which is the standard distribution format for X Window System fonts. Take a look at http://www.math.utah.edu/~beebe/fonts/X-Window-System-fonts.html ---------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 105 JWB beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ---------------------------------------------------------------------------- 26-Nov-1997 18:46:52-GMT,1704;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id LAA02831; Wed, 26 Nov 1997 11:46:51 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with ESMTP id NAA18443; Wed, 26 Nov 1997 13:46:49 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id NAA13771; Wed, 26 Nov 1997 13:46:46 -0500 (EST) Date: Wed, 26 Nov 1997 13:46:46 -0500 (EST) Message-Id: <199711261846.NAA13771@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: beebe@csc-sun.math.utah.edu CC: tex-fonts@csc-sun.math.utah.edu In-reply-to: Subject: Re: [Mark Leisher : Unicode BDF fonts available] Reply-to: bkph@ai.mit.edu Nelson H. F. Beebe wrote: >> Too bad its in some obscure 100dpi bitmapped format :-) I think the posting said BDF, which is the standard distribution format for X Window System fonts. Take a look at Oh, I know :-), I was trying to be sarcastic (note the emoticon in my earlier message). But anyway, isn't it about time that X Windows provide better font support? Isn't it about time that Unix provide system-level scalable outline font support? So we can avoid all the incompatibilities, and complex installation instructions that differ for each application? I know Sun ditched the very nice F3 format, and then got taken by Adobe on the T1 rasterizer they bought, and seem to totally at sea when it comes to fonts these days, but surely somebody can move forward... 27-Nov-1997 2:08:19-GMT,3064;000000000000 Return-Path: Received: from plot79.math.utah.edu (beebe@plot79.math.utah.edu [128.110.198.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id TAA12541; Wed, 26 Nov 1997 19:08:19 -0700 (MST) From: "Nelson H. F. Beebe" Received: (from beebe@localhost) by plot79.math.utah.edu (8.8.5/8.8.5) id TAA12089; Wed, 26 Nov 1997 19:08:18 -0700 (MST) Date: Wed, 26 Nov 1997 19:08:18 -0700 (MST) To: tex-fonts@csc-sun.math.utah.edu, math-font-discuss@cogs.susx.ac.uk Cc: beebe@csc-sun.math.utah.edu X-US-Mail: "Center for Scientific Computing, University of Utah, 155 S 1400 E RM 233, Salt Lake City, UT 84112-0090, USA" X-Telephone: +1 801 581 5254 X-FAX: +1 801 581 4148 X-URL: http://www.math.utah.edu/~beebe Subject: Web documentation on fonts Message-ID: I've spent a good bit of today reorganizing my Web pages on fonts. My intent with these pages is to create a resource that both local and remote users can read to learn more about fonts, and font software. There is now a new top-level entry to this documentation at http://www.math.utah.edu/~beebe/index.html#fonts or more directly, with less serendipity, at http://www.math.utah.edu/~beebe/fonts/index.html Several of the Web pages contain references to software; in every case where a UNIX manual page was available, I've provided links to an automatically-translated HTML file, using the latest release of my man2html utility, available at ftp://ftp.math.utah.edu/pub/sgml/index.html#m The extensive GNU font utilities and fontname documentation is also provided in HTML form, thanks to texi2html, and a half-dozen minor hand edits. All HTML files have been prettyprinted (except the GNU font utilities pages), and all pass the rigorous grammatical check of html-ncheck. These files have updated today, or automatically translated from existing documentation: X-Window-System-fonts.html info/fontname.html info/fontu.html info/fontu_toc.html manpages/t1ascii.html manpages/t1asm.html manpages/t1binary.html manpages/t1disasm.html manpages/unpost.html mathematica.html outline-vs-bitmap-fonts.html unicode.html These files are completely new today: computer-modern.html index.html metafont.html postscript-type-1-fonts.html I will be pleased to receive comments, bug reports, and complaints about errors of omission. ---------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - Center for Scientific Computing FAX: +1 801 581 4148 - - University of Utah Internet e-mail: beebe@math.utah.edu - - Department of Mathematics, 105 JWB beebe@acm.org - - 155 S 1400 E RM 233 beebe@ieee.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe - ---------------------------------------------------------------------------- 27-Nov-1997 9:41:16-GMT,1699;000000000000 Return-Path: Received: from nansen.nrsc.no (nansen.nrsc.no [129.177.42.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id CAA20786 for ; Thu, 27 Nov 1997 02:41:14 -0700 (MST) Received: from fram.nrsc.no by nansen.nrsc.no with SMTP id AA10524 (5.67b8/IDA-1.4.4 for ); Thu, 27 Nov 1997 10:40:16 +0100 Received: by fram.nrsc.no (5.67b8/Uninett-C-1.4) id AA20393; Thu, 27 Nov 1997 10:40:18 +0100 Message-Id: <199711270940.AA20393@fram.nrsc.no> Subject: new Metafont mode (bug fix for some fonts) To: tex-fonts@csc-sun.math.utah.edu Date: Thu, 27 Nov 1997 10:40:16 +0100 (MET) From: "Alastair D. Jenkins" X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Charset: LATIN1 X-Char-Esc: 29 Hello, Here is a "square" Metafont mode for the Canon Bubblejet 200. I needed it because I got errors with MusiXTeX when using the "proper" non-1.0 aspect ratio. As it's a quick fix I just use the "default" parameter values for blacker, fillin and o_correction. mode_def bjtzzs = %\[ Canon BubbleJet 200 (720x360 dpi) at 720x720 dpi mode_param (pixels_per_inch, 720); mode_param (blacker, 0.0); mode_param (fillin, 0); mode_param (o_correction, 1.0); mode_common_setup_; enddef; CanonBJTwoZeroZeroSquare := bjtzzs; Regards, Alastair J. -- Alastair D. Jenkins Do/renberg, Ho/go/y, Postboks 72, N-5350 Brattholmen, Norway Phone: +47-56 32 03 77 (listed under Sotra, not Bergen) At work: phone +47-55 29 72 88 fax +47-55 20 00 50 email: Alastair.Jenkins@nrsc.no URL: http://www.nrsc.no:8001/~jenkins/ 27-Nov-1997 23:03:59-GMT,3016;000000000000 Return-Path: Received: from wrath (serv1.is2.u-net.net [194.119.130.23]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id QAA04105 for ; Thu, 27 Nov 1997 16:03:56 -0700 (MST) Received: from [194.119.133.86] [194.119.133.86] by wrath with esmtp (Exim 1.62 #2) id 0xbCnT-0000pW-00; Thu, 27 Nov 1997 22:52:35 +0000 X-Sender: rebecca-astrid@mail.u-net.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Nov 1997 16:22:29 +0000 To: tex-fonts@csc-sun.math.utah.edu From: Rebecca and Rowland Subject: What's the relationship between vfs and tfms? Thanks to the helpful replies I got to my last query on this list, I find myself confused by something else. It's this tfm and vf business. I gather that TeX uses .tfm files as its source for fount metric information while typesetting, and that .vf files are used by the .dvi driver to work out which glyphs in the `real' fount should be used. (this all makes my head hurt because the `real' fount is usually an 8r encoded not at all real fount really that needs to be re-encoded by the dvi driver, but I can handle that if I don't think about it at the same time as thinking about .vfs and TeX and things) Now then, I've got a fount called fkar8a that I've installed. It's been re-encoded by fontinst to 8r encoding, so I've got fkar8r.tfm. This 8r encoded fount was used by fontinst (when it was a .pl and .mtx file) to create fkar8t.vpl. So far, so good. Now then, if I run pltotf on fkar8r.pl, I get fkar8r.tfm. This doesn't make my brain overheat. If I run vptovf on fkar8t.vpl, I get fkar8t.vf and fkar8t.tfm: This is VPtoVF, version 1.4 Input file: fkar8t.vpl Output TFM file: fkar8t.tfm Output VF file: fkar8t.vf Obviously, TeX uses fkar8t.tfm for typesetting. But how does anything know to use the .vf file? And what use exactly is the .vf file put to? I could guess that either there's a flag in the .tfm file that tells the dvi driver to look for a .vf file, or that the dvi driver looks for a `real' fount called fkar8t (either fkar8t.pk, fkar8t.mf, or an entry in a mapping table such as OzTeX's config file or DVIPS's psfonts.map), and failing to find one, looks for a .vf file corresponding to it. As for exactly what's done with the .vf file, I'm not quite sure. Could someone cast some light? And... (this is where my brain *does* overheat, melt down, and explode), when I run vftovp on fkar8t.vf, this happens: Input file: fkar8t.vf Reading TFM file: :TeX-fonts:New tfms:fkar8t.tfm Reading TFM file: :TeX-fonts:New tfms:fkar8r.tfm Check sum in VF file being replaced by TFM check sum Output file: fkar8t.vpl Why are two .tfms being read? Can anyone explain what's happening here? Thanks in advance, Rowland. P.S. At this rate, I suspect finishing any fontinst documentation will take a little longer than I was expecting, but I seem to be making some progress. 28-Nov-1997 9:36:37-GMT,3778;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id CAA14585 for ; Fri, 28 Nov 1997 02:36:30 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.8.5/8.8.5) with ESMTP id KAA04943; Fri, 28 Nov 1997 10:36:21 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id KAA26114; Fri, 28 Nov 1997 10:46:52 +0100 (MET) Date: Fri, 28 Nov 1997 10:46:52 +0100 (MET) Message-Id: <199711280946.KAA26114@mozart.ujf-grenoble.fr> From: Thierry Bouche To: Rebecca and Rowland Cc: tex-fonts@csc-sun.math.utah.edu Subject: Re: What's the relationship between vfs and tfms? In-Reply-To: References: X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII as berthold said, it's the 3 TFMs & 2 VFs for 3 founts scheme. 1 base TFM : the 8r which gives access to all glyphs in the type 1 fount, although to be effectively accessible, the type 1 fount will need to be reencoded by the driver before being downloaded. This is already a full functionnal TFM that allows typesetting in its own (ligatures & kerning are present). 1 pair VF+TFM for each one of T1 (8t or 9e) and OT1 (7t or 9t) TeX encoding, these being only virtual fonts refering to the base one. In 2 words, both TFM + VF are needed for them because TeX is happy (fooled ?) with one TFM, whatever it is related to (real or virtual or reencoded font), when you typset in free-KA using T1 encoding, tex will only need the metric information provided by fkar8t.tfm. The conversion virtual -> real is provided by the VF that is essentially a collection of fragments of DVI code drawing each individual (virtual) charachter with DVI opcodes (allowing rules, special, placement of charachters from some real font, offsets, etc.). Thus it is natural that the VF refers to the base TFM, and that the base TFM be used in order to read the metrics from the real font used. Typically, when asked to deliver some glyphs from a given fount fkar8t, a driver will _first_ look for the file fkar8t.vf and desassemble it back to real founts before proceeding, if it doesn't find any virutal definiton of that fount, it will assume that was a real one, and proceed. It is only a step further that different type formats are considered, when it comes to actually print the glyphs (in our case, it will only attempt to print glyphs from fkar8r). Depending on the driver's very nature, it will assume that some format is the default, & look in a parameter file to see if the peculiar font needs some special treatment (such as reencoding, downloading outlines rather than computing PKs, converting truetype to type 3, then batch-running fontographer to convert it to type1, and using a type1 rasterizer in the end, or running metapost on MF source to generate outlines that will be automagically auti-hinted in fontlab--the usual stuff in one word). You should also investigate the expert situation where you have a 4 TFMs + 2 VFS scheme for 2 founts, each virtual fount pointing to 2 base founts (8r and 8x) and the faked small cap situation where small accents are built from scaled down versions of cap accents in the 8r fount so that one VF calls twice the base TFM at 2 different sizes, which ends up in one download of one reencoded fount. Hope i helped. Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 28-Nov-1997 15:35:56-GMT,957;000000000000 Return-Path: Received: from diablo.fem.unicamp.br (root@diablo.fem.unicamp.br [143.106.9.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id IAA20389 for ; Fri, 28 Nov 1997 08:35:52 -0700 (MST) Received: from viper.fem.unicamp.br (viper [143.106.9.15]) by diablo.fem.unicamp.br (8.8.6/8.8.5) with ESMTP id MAA31386 for ; Fri, 28 Nov 1997 12:36:52 -0200 Received: (from camino@localhost) by viper.fem.unicamp.br (8.8.6/8.8.6) id NAA16168 for tex-fonts@math.utah.edu; Fri, 28 Nov 1997 13:34:53 -0200 (EDT) From: Juan F C dos Santos Message-Id: <199711281534.NAA16168@viper.fem.unicamp.br> Subject: Subscribe/unsubscribe To: tex-fonts@csc-sun.math.utah.edu Date: Fri, 28 Nov 1997 13:34:52 -0300 (GMT-3:00) X-Mailer: ELM [version 2.4 PL0] Content-Type: text Please, How can I subscribe (unsubscribe) to this mailing list? Thanks in advances, Juan 29-Nov-1997 3:33:12-GMT,3368;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id UAA02645 for ; Fri, 28 Nov 1997 20:33:11 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with ESMTP id WAA17358; Fri, 28 Nov 1997 22:33:05 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id WAA14585; Fri, 28 Nov 1997 22:33:03 -0500 (EST) Date: Fri, 28 Nov 1997 22:33:03 -0500 (EST) Message-Id: <199711290333.WAA14585@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: rebecca@astrid.u-net.com CC: tex-fonts@csc-sun.math.utah.edu In-reply-to: (message from Rebecca and Rowland on Thu, 27 Nov 1997 16:22:29 +0000) Subject: Re: What's the relationship between vfs and tfms? Reply-to: bkph@ai.mit.edu Hi: Thanks to the helpful replies I got to my last query on this list, I find myself confused by something else. Ghee, and everyone always tells me that this `two TFM plus one VF per font' scheme is so trivial that I am a fool to complain about its complexity :-) It's this tfm and vf business. I gather that TeX uses .tfm files as its source for fount metric information while typesetting, and that .vf files are used by the .dvi driver to work out which glyphs in the `real' fount should be used. (this all makes my head hurt because the `real' fount is usually an 8r encoded not at all real fount really that needs to be re-encoded by the dvi driver, but I can handle that if I don't think about it at the same time as thinking about .vfs and TeX and things) Here is the simple version of the story: In this scheme, TeX sees only one TFM file, which is for a virtual font. It puts the name of that file in the DVI file. DVIPS sees that name, discovers there isn't a real font with that name, and looks for a VF file with that name. That VF file gives the name of the `real' font and says how to rearrange the characters in the `real' font. It then looks for that real font. If it is a `PS' font it will be listed in psfonts.map. Typically the entry in psfonts.map will also specify how the `raw' font is to be reencoded to be this `real' font. I put `real' in quotation marks because it is the reencoded font, not the `raw' unadulterated font. Why the need for reencoding? Because the virtual font mechanism can only shuffle around numbers, that is, map character code numbers to other numbers. It cannot make unencoded characters accessible (Typically `raw' `PS' fonts are set up for Adobe StandardEncoding which leaves over 60 of the `standard' 228 glyphs in text fonts unencoded). Now if you have to reencode the font already why do you also need the shuffling of character codes by the VF? Hey, don't ask me :-) Why are two .tfms being read? Can anyone explain what's happening here? Another thing you ask about is why DVIPS reads both TFMs. Well, a more interesting question is why it reads the TFM at all, since the font has all the needed metrics in it. This has to do with DVIPS wanting to produce resolution-dependent output. It replaces the fonts metrics with rounded versions derived from the TFM file. Regards, Berthold 29-Nov-1997 4:34:40-GMT,2931;000000000000 Return-Path: Received: from wrath (serv1.is2.u-net.net [194.119.130.23]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id VAA03631 for ; Fri, 28 Nov 1997 21:34:39 -0700 (MST) Received: from [194.119.134.152] [194.119.134.152] by wrath with esmtp (Exim 1.62 #2) id 0xbeQt-0006sw-00; Sat, 29 Nov 1997 04:23:07 +0000 X-Sender: rebecca-astrid@mail.u-net.com Message-Id: In-Reply-To: <199711280946.KAA26114@mozart.ujf-grenoble.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Nov 1997 21:00:02 +0000 To: Thierry Bouche From: Rebecca and Rowland Subject: Re: What's the relationship between vfs and tfms? Cc: tex-fonts@csc-sun.math.utah.edu >as berthold said, it's the 3 TFMs & 2 VFs for 3 founts scheme. So it is - and thanks for this detailed explanation. >1 base TFM : the 8r which gives access to all glyphs in the type 1 >fount, although to be effectively accessible, the type 1 fount will >need to be reencoded by the driver before being downloaded. >This is already a full functionnal TFM that allows typesetting in its >own (ligatures & kerning are present). I see. >1 pair VF+TFM for each one of T1 (8t or 9e) and OT1 (7t or 9t) TeX >encoding, 9e and 9t? I've not heard of these encodings. Could someone give me a pointer to some information on them? I can't see anything obvious at CTAN. > these being only virtual fonts refering to the base one. >In 2 words, both TFM + VF are needed for them because TeX is happy >(fooled ?) with one TFM, whatever it is related to (real or virtual >or reencoded font), when you typset in free-KA using T1 encoding, free-KA? I *think* you mean `typeset using the fount family fka'? Is that right? > tex >will only need the metric information provided by fkar8t.tfm. The >conversion virtual -> real is provided by the VF that is essentially a >collection of fragments of DVI code drawing each individual (virtual) >charachter with DVI opcodes (allowing rules, special, placement of >charachters from some real font, offsets, etc.). Thus it is natural >that the VF refers to the base TFM, and that the base TFM be used in >order to read the metrics from the real font used. Righto - this makes sense. >Typically, when asked to deliver some glyphs from a given fount fkar8t, >a driver will _first_ look for the file fkar8t.vf and desassemble it [snip] >will be automagically auti-hinted in fontlab--the usual stuff in one >word). Okay - got this too. [snip] >Hope i helped. You certainly have - thank you very much. Maybe I'm being stupid, but I still don't see why vftovp reads two tfms and a vf when re-creating a vpl. What is it that lives in a vpl file? Thanks again, Rowland. 29-Nov-1997 17:57:29-GMT,4747;000000000000 Return-Path: Received: from wrath (serv1.is2.u-net.net [194.119.130.23]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id KAA16112 for ; Sat, 29 Nov 1997 10:57:27 -0700 (MST) Received: from [194.119.134.182] [194.119.134.182] by wrath with esmtp (Exim 1.62 #2) id 0xbqxN-00012z-00; Sat, 29 Nov 1997 17:45:30 +0000 X-Sender: rebecca-astrid@mail.u-net.com Message-Id: In-Reply-To: <199711290333.WAA14585@kauai.ai.mit.edu> References: (message from Rebecca and Rowland on Thu, 27 Nov 1997 16:22:29 +0000) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 29 Nov 1997 17:24:39 +0000 To: bkph@ai.mit.edu From: Rebecca and Rowland Subject: Re: What's the relationship between vfs and tfms? Cc: tex-fonts@csc-sun.math.utah.edu (I was going to reply only to Berthold, but I changed my mind) >Ghee, and everyone always tells me that this `two TFM plus one VF per font' >scheme is so trivial that I am a fool to complain about its complexity :-) :-) Actuallly, I understand *roughly* what's going on; it's just the details that I haven't yet got the hang of. I think part of the problem is that everyone wants to make it seem `oh so simple', so all the explanations skip the important details. [snip] >Here is the simple version of the story: In this scheme, TeX sees only >one TFM file, which is for a virtual font. It puts the name of that >file in the DVI file. DVIPS sees that name, discovers there isn't a >real font with that name, and looks for a VF file with that name. The famous Sebastian Rahtz tells me that the dvi driver first looks for a vf file with that name, and if it doesn't find one, then assumes its a real fount. Clearly, one of you has it wrong. Is it you, or is it him? >That VF file gives the name of the `real' font and says how to >rearrange the characters in the `real' font. It then looks for that >real font. If it is a `PS' font it will be listed in psfonts.map. This makes the not necessarily valid assumption that you're using DVIPS. >Typically the entry in psfonts.map will also specify how the `raw' >font is to be reencoded to be this `real' font. > >I put `real' in quotation marks because it is the reencoded font, not >the `raw' unadulterated font. Why the need for reencoding? >Because the virtual font mechanism can only shuffle around numbers, >that is, map character code numbers to other numbers. It cannot >make unencoded characters accessible (Typically `raw' `PS' fonts >are set up for Adobe StandardEncoding which leaves over 60 of >the `standard' 228 glyphs in text fonts unencoded). Now if you >have to reencode the font already why do you also need the shuffling >of character codes by the VF? Hey, don't ask me :-) A puzzle, isn't it? I think it's because TeX uses T1 and OT1 encoding and that's that (aside from when it doesn't, but you know what I mean). Forward and backward compatibility are Good Things, so you don't want to fiddle about with encodings too much (ever wondered why most people use OT1 by default?) Anyway, the actual encoding the real live Type 1 printer fount file uses can be pretty much anything, and this varies according to computer. It doesn't make any sense at all to have *this* part of the encoding dealt with by TeX itself, because the encoding used by the Type 1 fount is likely to change with time and computer system - after all, most of us use either Adobe Standard or Mac encoded encoded founts at the moment, but Unicode encoding will become quite common some time soon. The sensible thing to do is to have the dvi driver handle this part of the interface, because the dvi driver set-up is *supposed* to be system-dependent. This way, you can have a system independent TeX set-up, which means you get better compatibility across time and space (if you'll pardon the pretension) Does this reasoning make any sense, and does it have any relationship to reality? > Why are two .tfms being read? Can anyone explain what's happening here? > >Another thing you ask about is why DVIPS reads both TFMs. Not DVIPS; vftovpl. > Well, >a more interesting question is why it reads the TFM at all, since the >font has all the needed metrics in it. When you say `the font', what do you mean? (Thinks: the vf file `is' the fount; each tfm file `is' the fount; the Type 1 printer fount file `is' the fount.) > This has to do with DVIPS >wanting to produce resolution-dependent output. It replaces the >fonts metrics with rounded versions derived from the TFM file. I see (I think). I take it that DVIPS does the rounding? Thanks again, Rowland. 29-Nov-1997 19:05:20-GMT,5203;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id MAA17282 for ; Sat, 29 Nov 1997 12:05:19 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with ESMTP id OAA29904; Sat, 29 Nov 1997 14:05:15 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id OAA14874; Sat, 29 Nov 1997 14:05:14 -0500 (EST) Date: Sat, 29 Nov 1997 14:05:14 -0500 (EST) Message-Id: <199711291905.OAA14874@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: rebecca@astrid.u-net.com CC: tex-fonts@csc-sun.math.utah.edu In-reply-to: (message from Rebecca and Rowland on Sat, 29 Nov 1997 17:24:39 +0000) Subject: Re: What's the relationship between vfs and tfms? Reply-to: bkph@ai.mit.edu Hi: The famous Sebastian Rahtz tells me that the dvi driver first looks for a vf file with that name, and if it doesn't find one, then assumes its a real fount. Clearly, one of you has it wrong. Is it you, or is it him? The famous Sebastian Rahtz is right, no doubt. Since I never use DVIPS I don't know much about such details. >That VF file gives the name of the `real' font and says how to >rearrange the characters in the `real' font. It then looks for that >real font. If it is a `PS' font it will be listed in psfonts.map. This makes the not necessarily valid assumption that you're using DVIPS. Oh? That *is* what we are talking about isn't it? Do you know another implementation that works this way? >Because the virtual font mechanism can only shuffle around numbers, >that is, map character code numbers to other numbers. It cannot >make unencoded characters accessible (Typically `raw' `PS' fonts >are set up for Adobe StandardEncoding which leaves over 60 of >the `standard' 228 glyphs in text fonts unencoded). Now if you >have to reencode the font already why do you also need the shuffling >of character codes by the VF? Hey, don't ask me :-) A puzzle, isn't it? I think it's because TeX uses T1 and OT1 encoding and that's that (aside from when it doesn't, but you know what I mean). Forward and backward compatibility are Good Things, so you don't want to fiddle about with encodings too much (ever wondered why most people use OT1 by default?) Well, yes, but if you are going to have different names for the same font encoded different ways (by `decorating' the base name) then there is no need to share the same `real' font. And hence no need for the VF approach. That is, the psfonts.map has two entries to force reencoding of the `raw' font to anything you want, no need to add additional reshuffling using VF. Anyway, the actual encoding the real live Type 1 printer fount file uses can be pretty much anything, and this varies according to computer. It Well, for text fonts, the actual font file *always* says Adobe Standard Encoding. And yes, you never want to use that. So you *do* have to reencode the font anyway. Which was my point. If you have to reencode it anyway, why bother with an additional shuffling of character codes? doesn't make any sense at all to have *this* part of the encoding dealt with by TeX itself, because the encoding used by the Type 1 fount is likely to change with time and computer system - after all, most of us use either Adobe Standard or Mac encoded encoded founts at the moment, or Windows ANSI encoding :-) but Unicode encoding will become quite common some time soon. Well it is there right now in Windows NT with both TrueType and Type 1 fonts (using ATM 4.0 for NT). I can see all the popluated parts of Lucida Latin fonts in `Character Map' e.g. Unfortunately there is very little software that can take advantage of it yet. The sensible thing to do is to have the dvi driver handle this part of the interface, because the dvi driver set-up is *supposed* to be system-dependent. Agreed. But that still doesn't address the question of why yet another layer of remapping is needed (VF). >Well, >a more interesting question is why it reads the TFM at all, since the >font has all the needed metrics in it. When you say `the font', what do you mean? (Thinks: the vf file `is' the fount; each tfm file `is' the fount; the Type 1 printer fount file `is' the fount.) To me its real simple: the fo(u)nt is the thing that actually contains the character programs. Hence a TFM file is not a font (despite nomenclature used in the TeX book, neither is a VF file. But you are right this is one of the most confusion parts to most TeX users. >This has to do with DVIPS >wanting to produce resolution-dependent output. It replaces the >fonts metrics with rounded versions derived from the TFM file. I see (I think). I take it that DVIPS does the rounding? Yes, in order to achieve (claimed) better spacing at a particular resolution, at the cost of worse spacing at all other resolutions... Regards, Berthold. 29-Nov-1997 19:28:48-GMT,1113;000000000000 Return-Path: Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id MAA17748 for ; Sat, 29 Nov 1997 12:28:45 -0700 (MST) Received: from slip139-92-41-87.ut.nl.ibm.net (slip139-92-41-87.ut.nl.ibm.net [139.92.41.87]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id TAA53922 for ; Sat, 29 Nov 1997 19:28:41 GMT Message-Id: <199711291928.TAA53922@out2.ibm.net> From: "Walter Schmidt" To: "tex-fonts" Date: Sat, 29 Nov 97 16:08:38 +0100 Reply-To: "Walter Schmidt" Priority: Normal X-Mailer: PMMail 1.92 (OS/2 Warp) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: What's the relationship between vfs and tfms? On Fri, 28 Nov 1997 22:33:03 -0500 (EST), Berthold K.P. Horn wrote: >Here is the simple version of the story: ... Thank you very much! Your explanation should be posted to all TeX-related FAQs and mailing lists around the world ;-) Greetings Walter 29-Nov-1997 19:33:43-GMT,2622;000000000000 Return-Path: Received: from nx1.HRZ.Uni-Dortmund.DE (nx1.HRZ.Uni-Dortmund.DE [129.217.131.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id MAA17844 for ; Sat, 29 Nov 1997 12:33:42 -0700 (MST) Received: from StudServer.Uni-Dortmund.DE (actually sx2.HRZ.Uni-Dortmund.DE) by nx1.hrz.uni-dortmund.de with SMTP (PP); Sat, 29 Nov 1997 20:33:37 +0100 Received: from localhost by StudServer.Uni-Dortmund.DE (SMI-8.6/HRZ-V1.6-SunOS-09/10/97-11:04:10) id UAA15080; Sat, 29 Nov 1997 20:33:36 +0100 Date: Sat, 29 Nov 1997 20:33:36 +0100 (MET) From: Werner Lemberg To: "Berthold K.P. Horn" cc: rebecca@astrid.u-net.com, tex-fonts@csc-sun.math.utah.edu Subject: Re: What's the relationship between vfs and tfms? In-Reply-To: <199711291905.OAA14874@kauai.ai.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 29 Nov 1997, Berthold K.P. Horn wrote: > >That VF file gives the name of the `real' font and says how to > >rearrange the characters in the `real' font. It then looks for that > >real font. If it is a `PS' font it will be listed in psfonts.map. > > This makes the not necessarily valid assumption that you're using DVIPS. > > Oh? That *is* what we are talking about isn't it? Do you know another > implementation that works this way? I think that all PS TeX tools will check psfonts.map; so do pstopk and gsftopk which are e.g. called by xdvi to do the job. > Anyway, the actual encoding the real live Type 1 printer fount file uses > can be pretty much anything, and this varies according to computer. It > > Well, for text fonts, the actual font file *always* says Adobe Standard > Encoding. And yes, you never want to use that. So you *do* have to > reencode the font anyway. Which was my point. If you have to reencode > it anyway, why bother with an additional shuffling of character codes? At least Type 1 fonts have only one encoding. CID PS fonts and TTF fonts can have any number of encodings... > but Unicode encoding will become quite common some time soon. > > Well it is there right now in Windows NT with both TrueType and Type 1 fonts > (using ATM 4.0 for NT). I can see all the popluated parts of Lucida Latin > fonts in `Character Map' e.g. Unfortunately there is very little software that > can take advantage of it yet. Unicode is quite useless for TeX. Omega is a different story. Werner 29-Nov-1997 19:35:41-GMT,1478;000000000000 Return-Path: Received: from hubert.wuh.wustl.edu (ats@wydo122.wuh.wustl.edu [128.252.232.122]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id MAA17872 for ; Sat, 29 Nov 1997 12:35:40 -0700 (MST) Received: (from ats@localhost) by hubert.wuh.wustl.edu (8.8.5/8.8.5) id NAA22726; Sat, 29 Nov 1997 13:35:25 -0600 To: bkph@ai.mit.edu Cc: rebecca@astrid.u-net.com, tex-fonts@csc-sun.math.utah.edu Subject: Re: What's the relationship between vfs and tfms? References: <199711291905.OAA14874@kauai.ai.mit.edu> From: Alan Shutko Date: 29 Nov 1997 13:35:25 -0600 In-Reply-To: "Berthold K.P. Horn"'s message of Sat, 29 Nov 1997 14:05:14 -0500 (EST) Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 20.2 X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA) MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - =?ISO-8859-4?Q?"D=F2?= =?ISO-8859-4?Q?h=F2ji"?=) Content-Type: text/plain; charset=US-ASCII >>>>> "B" == Berthold K P Horn writes: B> Agreed. But that still doesn't address the question of why yet B> another layer of remapping is needed (VF). Well, it allows you to do stuff like mathptm, which I did last night for the Spectrum font. I've also heard that it allows you to do proper kerning for ligatures in the expert set? -- Alan Shutko - By consent of the corrupted It takes a smart husband to have the last word and not use it. 30-Nov-1997 7:45:40-GMT,1751;000000000000 Return-Path: Received: from wrath (serv1.is2.u-net.net [194.119.130.23]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id AAA00328 for ; Sun, 30 Nov 1997 00:45:38 -0700 (MST) Received: from [194.119.134.171] [194.119.134.171] by wrath with esmtp (Exim 1.62 #2) id 0xc3tE-0002gP-00; Sun, 30 Nov 1997 07:34:05 +0000 X-Sender: rebecca-astrid@mail.u-net.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 29 Nov 1997 22:44:59 +0000 To: TeX founts mailing list From: Rebecca and Rowland Subject: A question about encodings and afm files I've been trying to work out how TeX decides which number to put in a dvi file when it comes across a character to output. And I've not got all that far. Is it the case that TeX's default behaviour is to output the same number to the dvi file as it met in the input file? Please say `yes' - I think I can understand what's going on if that's the case. And the afm question is this: Does anyone know if there's some sort of key to the afm files at CTAN in the fonts/postscript/adobe/afmfiles/ directories, or have you got to download all the files and examine the contents of them to find the afm files you're after? (btw, I've left some ravings at ftp://ftp.u-net.com/local/fontinst-doc.tex that will eventually turn into the new fontinst documentation. It's not really properly started yet, let alone finished, and it certainly doesn't have anything like a discernable structure; but if anyone reads it and sees something that's actually wrong, I'd appreciate being put on the right track.) Ta, Rowland. 30-Nov-1997 8:24:02-GMT,1688;000000000000 Return-Path: Received: from nx1.HRZ.Uni-Dortmund.DE (nx1.HRZ.Uni-Dortmund.DE [129.217.131.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id BAA00959 for ; Sun, 30 Nov 1997 01:24:01 -0700 (MST) Received: from StudServer.Uni-Dortmund.DE (actually sx2.HRZ.Uni-Dortmund.DE) by nx1.hrz.uni-dortmund.de with SMTP (PP); Sun, 30 Nov 1997 09:23:55 +0100 Received: from localhost by StudServer.Uni-Dortmund.DE (SMI-8.6/HRZ-V1.6-SunOS-09/10/97-11:04:10) id JAA19382; Sun, 30 Nov 1997 09:23:56 +0100 Date: Sun, 30 Nov 1997 09:23:56 +0100 (MET) From: Werner Lemberg To: Rebecca and Rowland cc: TeX founts mailing list Subject: Re: A question about encodings and afm files In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 29 Nov 1997, Rebecca and Rowland wrote: > I've been trying to work out how TeX decides which number to put in a dvi > file when it comes across a character to output. > > And I've not got all that far. Is it the case that TeX's default behaviour > is to output the same number to the dvi file as it met in the input file? If you mean that (after macro expansion) a character 'x' will be shipped out as 'x', then the answer is yes, provided the character exists in the .tfm file. And this not the default behaviour, but the only possibility, since TeX only sees the .tfm file of the character's font. Werner 30-Nov-1997 20:44:17-GMT,2377;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id NAA12640 for ; Sun, 30 Nov 1997 13:44:16 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with ESMTP id PAA24825; Sun, 30 Nov 1997 15:44:10 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id PAA15285; Sun, 30 Nov 1997 15:44:09 -0500 (EST) Date: Sun, 30 Nov 1997 15:44:09 -0500 (EST) Message-Id: <199711302044.PAA15285@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: sx0005@sx2.hrz.uni-dortmund.de CC: rebecca@astrid.u-net.com, tex-fonts@csc-sun.math.utah.edu In-reply-to: (message from Werner Lemberg on Sat, 29 Nov 1997 20:33:36 +0100 (MET)) Subject: Re: What's the relationship between vfs and tfms? Reply-to: bkph@ai.mit.edu From: Werner Lemberg > Oh? That *is* what we are talking about isn't it? Do you know another > implementation that works this way? I think that all PS TeX tools will check psfonts.map; so do pstopk and gsftopk which are e.g. called by xdvi to do the job. I thought he was talking about TeX Systems. Also, I note that OzTeX uses a table in a different format, as does GhostView and Textures. > Well, for text fonts, the actual font file *always* says Adobe Standard > Encoding. And yes, you never want to use that. So you *do* have to > reencode the font anyway. Which was my point. If you have to reencode > it anyway, why bother with an additional shuffling of character codes? At least Type 1 fonts have only one encoding. CID PS fonts and TTF fonts can have any number of encodings... Not sure what this means. (1) You can reencode a T1 font to anything you want. It is actually hard to reencode a TT font. (2) If you consider different platforms then indeed the T1 font has several different encodings (Windows ANSI, Mac standard roman, ISO Latin 1), as does a TT font (except that many TT fonts do not have the required tables - e.g. Apple's TT fonts lack the Windows tables). Unicode is quite useless for TeX. Omega is a different story. Yup. Berthold. 30-Nov-1997 20:48:59-GMT,1943;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id NAA12738 for ; Sun, 30 Nov 1997 13:48:58 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with ESMTP id PAA24907; Sun, 30 Nov 1997 15:48:43 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id PAA15289; Sun, 30 Nov 1997 15:48:42 -0500 (EST) Date: Sun, 30 Nov 1997 15:48:42 -0500 (EST) Message-Id: <199711302048.PAA15289@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: ats@acm.org CC: rebecca@astrid.u-net.com, tex-fonts@csc-sun.math.utah.edu In-reply-to: (message from Alan Shutko on 29 Nov 1997 13:35:25 -0600) Subject: Re: What's the relationship between vfs and tfms? Reply-to: bkph@ai.mit.edu B> Agreed. But that still doesn't address the question of why yet B> another layer of remapping is needed (VF). Well, it allows you to do stuff like mathptm, which I did last night for the Spectrum font. I've also heard that it allows you to do proper kerning for ligatures in the expert set? Yes, VF lets you do some neat tricks like combining characters from different fonts into one `font' and tweaking side-bearings and advance widths, etc. Which is very good if you don't have tools to work with the actual fonts, or don't want to touch the actual fonts. But this isn't what we seem to be talking about here, which is straight-forward use of text fonts in LaTeX 2e. My point is that in order to get the rarely used fancy features we seem to force complexity in the trivial case. I have nothing against doing the fancy stuff, just don't like the idea of doing it at the expense of making ordinary things complex for the average users. Berthold. 30-Nov-1997 21:02:02-GMT,1652;000000000000 Return-Path: Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id OAA12970 for ; Sun, 30 Nov 1997 14:02:01 -0700 (MST) Received: from fell.open.ac.uk by venus with SMTP Internet (MMTA v2.2) with ESMTP; Sun, 30 Nov 1997 21:01:53 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.8.5/8.6.12) id UAA03328; Sun, 30 Nov 1997 20:59:17 GMT Date: Sun, 30 Nov 1997 20:59:17 GMT Message-Id: <199711302059.UAA03328@fell.open.ac.uk> From: Chris Rowley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Werner Lemberg Cc: Rebecca and Rowland , TeX founts mailing list Subject: Re: A question about encodings and afm files In-Reply-To: References: Werner wrote -- > If you mean that (after macro expansion) a character 'x' will be shipped > out as 'x', then the answer is yes, provided the character exists in the > .tfm file. And this not the default behaviour, but the only possibility, > since TeX only sees the .tfm file of the character's font. As Werner suggests, there may be a few other things that happen to a character on its way through TeX, especially if it is within math-mode. But at the output-to-dvi stage no further transformations happen. chris 30-Nov-1997 23:44:15-GMT,7068;000000000000 Return-Path: Received: from wrath (serv1.is2.u-net.net [194.119.130.23]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with SMTP id QAA15861 for ; Sun, 30 Nov 1997 16:44:11 -0700 (MST) Received: from [194.119.134.88] [194.119.134.88] by wrath with esmtp (Exim 1.62 #2) id 0xcIq0-0005H5-00; Sun, 30 Nov 1997 23:31:44 +0000 X-Sender: rebecca-astrid@mail.u-net.com Message-Id: In-Reply-To: <199711291905.OAA14874@kauai.ai.mit.edu> References: (message from Rebecca and Rowland on Sat, 29 Nov 1997 17:24:39 +0000) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 30 Nov 1997 23:15:45 +0000 To: bkph@ai.mit.edu From: Rebecca and Rowland Subject: Re: What's the relationship between vfs and tfms? Cc: tex-fonts@csc-sun.math.utah.edu >Hi: > > The famous Sebastian Rahtz tells me that the dvi driver first looks for a > vf file with that name, and if it doesn't find one, then assumes its a real > fount. Clearly, one of you has it wrong. Is it you, or is it him? > >The famous Sebastian Rahtz is right, no doubt. \begin{feeblejoke} I'd doubt it; anyone with judgement poor enough to engage me in an email conversation is clearly not to be trusted. (Thinks: Hmm... I seem to have insulted more than Sebastian here. I always said I was stupid.) \end{feeblejoke} > Since I never use >DVIPS I don't know much about such details. > > >That VF file gives the name of the `real' font and says how to > >rearrange the characters in the `real' font. It then looks for that > >real font. If it is a `PS' font it will be listed in psfonts.map. > > This makes the not necessarily valid assumption that you're using DVIPS. > >Oh? That *is* what we are talking about isn't it? I thought I asked a general question about how dvi drivers deal with virtual founts. > Do you know another >implementation that works this way? I don't know anything; that's why I asked. [snip] >Well, yes, but if you are going to have different names for the same font >encoded different ways (by `decorating' the base name) then there is no >need to share the same `real' font. And hence no need for the VF approach. It's not essential, but it does strike me as being more easily portable. >That is, the psfonts.map has two entries to force reencoding of the `raw' >font to anything you want, no need to add additional reshuffling using VF. But that does mean you need different encoding vectors for each occurrance of a different encoding *and* each different dvi driver. The nice thing about the vf approach is that you need one 8r encoding vector for each dvi driver (rather than OT1, T1, and any others that are in use); and the OT1->8r and T1->8r mapping is handled by a single encoding vector (for each encoding) that works for all TeX installations. If everyone used dvips and the same PostScript founts, then this non-vf approach wouldn't have any drawbacks. But what of those of us who use TrueType founts on Macintoshes, without using dvips? > Anyway, the actual encoding the real live Type 1 printer fount file uses > can be pretty much anything, and this varies according to computer. It > >Well, for text fonts, the actual font file *always* says Adobe Standard >Encoding. Surely not? I was under the impression that the printer fount files on my computer say they use Macintosh text encoding. They certainly behave as if this were the case. > And yes, you never want to use that. So you *do* have to >reencode the font anyway. Until 8r encoding was invented, PS founts were installed `raw', so this re-encoding step wasn't needed. As Alan Jeffrey puts it in fontinst.tex: >Finally, you should tell your {\tt dvi}-to-PostScript driver about the >fonts. This will depend on your driver, for example with {\tt dvips} >you should add the following lines to your {\tt psfonts.map} file: >\begin{verbatim} > ptmr0 Times-Roman > ptmri0 Times-Italic > ptmb0 Times-Bold > ptmbi0 Times-BoldItalic >\end{verbatim} In other words, Adobe standard encoding has been used, and re-encoding in the dvi driver isn't essential. > Which was my point. If you have to reencode >it anyway, why bother with an additional shuffling of character codes? Can you think of a way in which TeX documents could be made properly portable, and dvi drivers could be made easy to set up, given that we'd need dozens of different output encodings for each different dvi driver? [snip] > The sensible thing to do > is to have the dvi driver handle this part of the interface, because the > dvi driver set-up is *supposed* to be system-dependent. > >Agreed. But that still doesn't address the question of why yet another layer >of remapping is needed (VF). Can anyone who helped make this particular design decision explain it? As I see it (in my ignorance), the vf re-mapping is used because it's portable and works on all TeX systems. The extra re-mapping to 8r strikes me as more of a necessary evil, and is only put up with because you only need one single re-encoding vector file for each dvi driver, so it doesn't add too much to the mess of system-dependent files we've got anyway. > >Well, > >a more interesting question is why it reads the TFM at all, since the > >font has all the needed metrics in it. > > When you say `the font', what do you mean? (Thinks: the vf file `is' the > fount; each tfm file `is' the fount; the Type 1 printer fount file `is' the > fount.) > >To me its real simple: the fo(u)nt I suspect it would me more elegant if you used one spelling or the other; given that you're in the USA, I won't hold it against you if you use the deviant spelling. ;-) > is the thing that actually contains >the character programs. Hence a TFM file is not a font (despite nomenclature >used in the TeX book, neither is a VF file. What about pk files? By your definition, these aren't founts, which puts TeX users in the interesting postion of being able to produce printed output with no founts at all (by using tfm, vf, and pk files only). I think you could argue that vf files aren't founts, because nothing is deluded into thinking they are. > But you are right this >is one of the most confusion parts to most TeX users. Keep your fingers crossed - in a few months, you should be able to point people at a new bit of documentation at CTAN that'll explain this (assuming I don't get struck my a meteorite and you don't mind me stealing [1] your words) > >This has to do with DVIPS > >wanting to produce resolution-dependent output. It replaces the > >fonts metrics with rounded versions derived from the TFM file. > > I see (I think). I take it that DVIPS does the rounding? > >Yes, in order to achieve (claimed) better spacing at a particular resolution, >at the cost of worse spacing at all other resolutions... I see - thanks. Rowland. [1] Lesser artists borrow; greater artists steal. 1-Dec-1997 8:37:41-GMT,1851;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id BAA25325 for ; Mon, 1 Dec 1997 01:37:39 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id IAA23563 for ; Mon, 1 Dec 1997 08:35:48 GMT Received: from screavie.elsevier.co.uk by snowdon.elsevier.co.uk with SMTP (PP); Mon, 1 Dec 1997 08:29:22 +0000 Received: from lurgmhor.elsevier.co.uk (lurgmhor.elsevier.co.uk [193.131.192.141]) by screavie.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id IAA22821; Mon, 1 Dec 1997 08:29:08 GMT Received: (from srahtz@localhost) by lurgmhor.elsevier.co.uk (8.8.5/8.8.5) id IAA04969; Mon, 1 Dec 1997 08:36:33 GMT Date: Mon, 1 Dec 1997 08:36:33 GMT Message-Id: <199712010836.IAA04969@lurgmhor.elsevier.co.uk> From: Sebastian Rahtz To: rebecca@astrid.u-net.com Cc: Thierry.Bouche@ujf-grenoble.fr, tex-fonts@csc-sun.math.utah.edu Subject: Re: What's the relationship between vfs and tfms? In-Reply-To: References: <199711280946.KAA26114@mozart.ujf-grenoble.fr> > 9e and 9t? I've not heard of these encodings. Could someone give me a > pointer to some information on them? I can't see anything obvious at CTAN. the `fontname' documentation is required preparation for this exam... > Maybe I'm being stupid, but I still don't see why vftovp reads two tfms and > a vf when re-creating a vpl. What is it that lives in a vpl file? i suggest you get one and read it. it does make things clearer, honest. sebastian 1-Dec-1997 10:02:15-GMT,1626;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id DAA26877 for ; Mon, 1 Dec 1997 03:02:14 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id KAA26617 for ; Mon, 1 Dec 1997 10:00:25 GMT Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Mon, 1 Dec 1997 09:53:52 +0000 Date: Mon, 1 Dec 1997 09:21:16 +0000 Message-ID: <6692-Mon01Dec1997092116+0000-s.rahtz@elsevier.co.uk> From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rebecca@astrid.u-net.com Cc: bkph@ai.mit.edu, tex-fonts@csc-sun.math.utah.edu Subject: Re: What's the relationship between vfs and tfms? In-Reply-To: References: <199711290333.WAA14585@kauai.ai.mit.edu> X-Mailer: VM 6.33 under Emacs 19.34.6 > The famous Sebastian Rahtz tells me that the dvi driver first looks for a > vf file with that name, and if it doesn't find one, then assumes its a real > fount. I am wrong, you know. cringe. dvips looks at psfonts.map first. personally, i think it should do what i said it did. its inconsistent, it that it searches for cmr10.vf if you use PK fonts, but not if you use TYpe1 fonts sebastian 1-Dec-1997 10:07:58-GMT,3485;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id DAA27005 for ; Mon, 1 Dec 1997 03:07:47 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.8.5/8.8.5) with ESMTP id LAA28797; Mon, 1 Dec 1997 11:07:16 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id LAA29024; Mon, 1 Dec 1997 11:18:22 +0100 (MET) Date: Mon, 1 Dec 1997 11:18:22 +0100 (MET) Message-Id: <199712011018.LAA29024@mozart.ujf-grenoble.fr> From: Thierry Bouche To: bkph@ai.mit.edu Cc: rebecca@astrid.u-net.com, tex-fonts@csc-sun.math.utah.edu Subject: Re: What's the relationship between vfs and tfms? In-Reply-To: <199711291905.OAA14874@kauai.ai.mit.edu> References: <199711291905.OAA14874@kauai.ai.mit.edu> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: What's the relationship between vfs and tfms? », Berthold K.P. Horn écrit : « Agreed. But that still doesn't address the question of why yet another layer « of remapping is needed (VF). historically, afm2tfm was not able to produce ligfull & kernfull TFMs for reencoded fontes, VFS were mandatory. There has been an interim state of the art, where 8r fontes were made by a patched afm2tfm, could someone tell if afm2tfm is still able to do ligfull 8r TFMs or not? Now the remaining reason is obviously fontinst's ability of faking missing charachters. this heavily requires VF machinery, hence a base TFM from which building fakable chars. The point of 8r here is simply to have all charachters accessible (encoded) and to minimize problems for systems that do not support reencoding or `deviant' encodings (windows & textures were cited, if i recall?). OK this is useless in OT1, but as we already have a base font needed for T1, why multiply base (PS) (re)encodings? I know that Berthold prefers the `buy Y&Y font manipulation tools software' scheme which in my opinion is not a bad idea if you have some money to spare, and like manipulating fontes. What is the real discussion underlying this? it's not tex related indeed. It is true that what a program like fontinst can do on metrics, a program like y&y's can do on PFBs (using SEAC?). Let's talk of some T1 charachter missing in the `standard glyph set' like Abreve in Palatino-Roman. And imagine you're talking a language that requires that one. If you use some external program to draw figures, and you (of course) want the words in the figure to be set in the same fonte as the ones in your text, (and of course the names in your diagrams require the letter Abreve...) you need that this letter be _real_ so you have to modify your fonte. By chance, this is not needed with TeX thanks to VFs! Remember that Palatino is resident, and of course not editable: if you do the faking with VFs you can share your PS files with anybody, and they will print on any PS device: no need to even buy palatino's PFB to alter it! for writing on figures, you still have the psfrag or 0-surface picture approach... Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 1-Dec-1997 11:28:59-GMT,2455;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id EAA28420 for ; Mon, 1 Dec 1997 04:28:58 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id LAA00431 for ; Mon, 1 Dec 1997 11:27:08 GMT Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Mon, 1 Dec 1997 11:20:24 +0000 Date: Mon, 1 Dec 1997 10:24:54 +0000 Message-ID: <9174-Mon01Dec1997102454+0000-s.rahtz@elsevier.co.uk> From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bkph@ai.mit.edu Cc: ats@acm.org, rebecca@astrid.u-net.com, tex-fonts@csc-sun.math.utah.edu Subject: Re: What's the relationship between vfs and tfms? In-Reply-To: <199711302048.PAA15289@kauai.ai.mit.edu> References: <199711302048.PAA15289@kauai.ai.mit.edu> X-Mailer: VM 6.33 under Emacs 19.34.6 Berthold K. P. Horn writes: > isn't what we seem to be talking about here, which is straight-forward > use of text fonts in LaTeX 2e. My point is that in order to get the > rarely used fancy features we seem to force complexity in the trivial > case. I have nothing against doing the fancy stuff, just don't like > the idea of doing it at the expense of making ordinary things complex > for the average users. > A `simple' case is the use of expert fonts, when you want some characters >From font A to appear in your apparent font, which is mainly drawn >From font B. Virtual fonts are good for this, all agreed? So we need to have virtual fonts around. The current `norm' in public domain TeXs (the xxx8r --> xxx7t/8t system) is there for compatibility with the CM/EC font family, no more no less. We dont have the luxury of being able to start with new encodings. Those who dont care about compatibility can just use 8r fonts on their own, with faster processing and less complexity/functionality . So I would argue that the fonts `we' provide cater for a wide variety of uses, and the system should stay the same. New users coming in with new fonts can just make 8r fonts if they want, using afm2tfm or Y&Y tools, and hey presto. Sebastian 1-Dec-1997 13:16:07-GMT,7782;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id GAA00200 for ; Mon, 1 Dec 1997 06:16:07 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with ESMTP id IAA15227; Mon, 1 Dec 1997 08:16:04 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA15520; Mon, 1 Dec 1997 08:16:01 -0500 (EST) Date: Mon, 1 Dec 1997 08:16:01 -0500 (EST) Message-Id: <199712011316.IAA15520@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: rebecca@astrid.u-net.com CC: tex-fonts@csc-sun.math.utah.edu In-reply-to: (message from Rebecca and Rowland on Sun, 30 Nov 1997 23:15:45 +0000) Subject: Re: What's the relationship between vfs and tfms? Reply-to: bkph@ai.mit.edu Hi: >That is, the psfonts.map has two entries to force reencoding of the `raw' >font to anything you want, no need to add additional reshuffling using VF. But that does mean you need different encoding vectors for each occurrance of a different encoding *and* each different dvi driver. The nice thing about the vf approach is that you need one 8r encoding vector for each dvi Not sure I see the difference. The DVI processor has to reencode the font in any case. Whether it reencodes to 8r or the encoding the user actually wants (LY1 say) doesn't make much difference (other than not needing VF in the latter case). Also, the encoding vector is a *constant* --- it does not depend on the platform. Keep in mind it completely *replaces* whatever encoding the font is set up for. You are perhaps thinking of `remapping' done by VF, which *does* have to take into account the target encoding. Maybe it helps to see what an encoding vector looks like conceptually: 32 space 33 exclam 34 quotedbl 35 numbersign 36 dollar 37 percent 38 ampersand .... It is *NOT* a mapping from one set of numbers in the range (0-255)to another ser of numbers in the range of (0-255). (Which is all VF can do). driver (rather than OT1, T1, and any others that are in use); and the OT1->8r and T1->8r mapping is handled by a single encoding vector (for each encoding) that works for all TeX installations. If everyone used dvips and the same PostScript founts, then this non-vf approach wouldn't have any drawbacks. But what of those of us who use TrueType founts on Macintoshes, without using dvips? Then you are in trouble in any case, since there is no way to reencode a TrueType font on the Mac (other than changing the actual font file). You are stuck with what is in Mac standard roman encoding. This means you won't have access to 21 of the `standard' 228 glyphs (like eth, thorn). (Unlike Windows NT where some software can reencode the TrueType vectors just like Type 1 and make even f-ligatures accessible in TT fonts). > Anyway, the actual encoding the real live Type 1 printer fount file uses > can be pretty much anything, and this varies according to computer. It >Well, for text fonts, the actual font file *always* says Adobe Standard >Encoding. Surely not? I was under the impression that the printer fount files on my computer say they use Macintosh text encoding. They certainly behave as if this were the case. The actual Type 1 font file *always* says /Encoding StandardEncoding def in the case of a text font. In fact some system software and printer drivers depend on this. The operating system reencodes the font to a platform specific encoding (remember we are now talking about systems with system level support for scalable fonts :-). Until 8r encoding was invented, PS founts were installed `raw', so this re-encoding step wasn't needed. As Alan Jeffrey puts it in fontinst.tex: >Finally, you should tell your {\tt dvi}-to-PostScript driver about the >fonts. This will depend on your driver, for example with {\tt dvips} >you should add the following lines to your {\tt psfonts.map} file: >\begin{verbatim} > ptmr0 Times-Roman > ptmri0 Times-Italic > ptmb0 Times-Bold > ptmbi0 Times-BoldItalic >\end{verbatim} In other words, Adobe standard encoding has been used, and re-encoding in the dvi driver isn't essential. Sigh. Which means you do not have 58 accented characters and about 30 other special characters! No hyphenation in `foreign' languages in TeX. Not sure what you are getting at here. Surely nobody used it that way (In prehistoric times, DVIPS had its own hard-wired unadvertized internal encoding which it applied to text fonts - so at that point in history you wouldn't mention an encoding vector in psfonts.map). > Which was my point. If you have to reencode >it anyway, why bother with an additional shuffling of character codes? Can you think of a way in which TeX documents could be made properly portable, and dvi drivers could be made easy to set up, given that we'd need dozens of different output encodings for each different dvi driver? See above. The encoding vector is not *different* for different drivers, since it does *not* depend on the underlying encoding of the text font (or whatever the operating system reencodes the text font to). The encoding vector *replaces* whatever was there. The original encoding might as well be a null vector for all it matters. For example, many people happily use LY1 (TeX 'n ANSI encoding) - even on Unix. All you need do is \usepackage[LY1]{fontenc} and no need for `text companion' fonts. These people all use the *same* encoding vector. (Modulo different drivers requiring it in slightly different formats: DVIPS wants an actual PostScript array, OzTeX wants a `charnumber glyphname' format). > The sensible thing to do > is to have the dvi driver handle this part of the interface, because the > dvi driver set-up is *supposed* to be system-dependent. > >Agreed. But that still doesn't address the question of why yet another layer >of remapping is needed (VF). Can anyone who helped make this particular design decision explain it? As I see it (in my ignorance), the vf re-mapping is used because it's portable and works on all TeX systems. Yes, all systems that use DVIPS :-) And even there it is not needed for this purpose. The extra re-mapping to 8r strikes me as more of a necessary evil, and is only put up with because you only need one single re-encoding vector file for each dvi driver, so it doesn't add too much to the mess of system-dependent files we've got anyway. No. As explained above, the encoding vector is always the same. It simply says what glyph you are going to get for each numeric character code. (The physical expression of the encoding vector may differ because different drivers may like to see it in different forms - but the mapping from number to glyph is constant). > is the thing that actually contains >the character programs. Hence a TFM file is not a font (despite nomenclature >used in the TeX book, neither is a VF file. What about pk files? By your definition, these aren't founts, which puts TeX users in the interesting postion of being able to produce printed output with no founts at all (by using tfm, vf, and pk files only). I OK, PK files contain the character shapes, so they are fonts. (Since I never use PK fonts, I simply forgot to specifically mention them). Similarly BDF files, FON files, F3 files Speedo files etc. etc. are fonts. But AFM files, TFM files, PFM files, etc. are not. Regards, Berthold. 1-Dec-1997 13:32:33-GMT,5115;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id GAA00552 for ; Mon, 1 Dec 1997 06:32:32 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with ESMTP id IAA15829; Mon, 1 Dec 1997 08:32:21 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id IAA15540; Mon, 1 Dec 1997 08:32:19 -0500 (EST) Date: Mon, 1 Dec 1997 08:32:19 -0500 (EST) Message-Id: <199712011332.IAA15540@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: Thierry.Bouche@ujf-grenoble.fr CC: rebecca@astrid.u-net.com, tex-fonts@csc-sun.math.utah.edu In-reply-to: <199712011018.LAA29024@mozart.ujf-grenoble.fr> (message from Thierry Bouche on Mon, 1 Dec 1997 11:18:22 +0100 (MET)) Subject: Re: What's the relationship between vfs and tfms? Reply-to: bkph@ai.mit.edu Hi: Concernant « Re: What's the relationship between vfs and tfms? », Berthold K.P. Horn écrit : « Agreed. But that still doesn't address the question of why yet another layer « of remapping is needed (VF). historically, afm2tfm was not able to produce ligfull & kernfull TFMs for reencoded fontes, VFS were mandatory. There has been an interim state of the art, where 8r fontes were made by a patched afm2tfm, could someone tell if afm2tfm is still able to do ligfull 8r TFMs or not? I believe you may have this back to front. AFM2TFM *was* able to produce proper TFM files complete with ligatures and kerning long ago. Unless I am mistaken, this capability was purposefully removed. Some of it was later reintroduced - as you say. Now the remaining reason is obviously fontinst's ability of faking missing charachters. this heavily requires VF machinery, hence a base TFM from which building fakable chars. The point of 8r here is simply to have all charachters accessible (encoded) and to minimize problems for systems that do not support reencoding or `deviant' encodings (windows & textures were cited, if i recall?). Actually, not all Windows systems need VF or support it. Also, while Textures now supports VF, it is not used or needed (except for cute examples and for MTMI in MathTime). So the widespread misuse of VF for simple text fonts should not be blamed on Mac or IBM PC compatibles :-) There was some confusion on this point at the TUG meeting in Santa Barbara - and I am responsible for being too tired to try and fight the rising tide there :-) Other people being much more persuasive... I know that Berthold prefers the `buy Y&Y font manipulation tools software' scheme which in my opinion is not a bad idea if you have some money to spare, and like manipulating fontes. Well, as you know, you *don't* need any of that for simple use of text fonts. And I know that *you* specifically do complex things that cannot be handled without VF or the FMP. What is the real discussion underlying this? it's not tex related indeed. It is true that what a program like fontinst can do on metrics, a program like y&y's can do on PFBs (using SEAC?). Let's talk I don't think that is what I was getting at. You don't need any of the tools in the FMP. Many people happily use Type 1 fonts on a variety of platforms without VF and lead happy lives (being able to hyphenate in `foreign' languages and all that). For this no complex tools are required. No changes to the font files. of some T1 charachter missing in the `standard glyph set' like Abreve in Palatino-Roman. And imagine you're talking a language that requires that one. Precisely, for *your* complex requirements you must have either VF or the FMP. If you use some external program to draw figures, and you (of course) want the words in the figure to be set in the same fonte as the ones in your text, (and of course the names in your diagrams require the letter Abreve...) you need that this letter be _real_ so you have to modify your fonte. By chance, this is not needed with TeX thanks to VFs! Remember that Palatino is resident, and of course not editable: if you do the faking with VFs you can share your PS files with anybody, and they will print on any PS device: no need to even buy palatino's PFB to alter it! for writing on figures, you still have the psfrag or 0-surface picture approach... I was not taking about something so complex. I acknowledged that for complex work VF has power that you can use. My point is that it is a mistake to force use of this complex and unneccessary machinery on a simple problem. Since you have to reencode the font in any case in the DVI processor, you can determine its layout fully. Why add another layer of rearranging of the character layout? Why kill a flea with a steam-press :-)? Regards, Berthold. P.S. I am sorry this has taken us so far away from the documentation for fontinst, but maybe it will clarify some font related issues as a side effect. 1-Dec-1997 13:34:31-GMT,1621;000000000000 Return-Path: Received: from hp9000.hrz.uni-oldenburg.de (hp9000.hrz.uni-oldenburg.de [134.106.40.3]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id GAA00597 for ; Mon, 1 Dec 1997 06:34:29 -0700 (MST) Received: from mathematik.uni-oldenburg.de (mathematik.uni-oldenburg.de [134.106.104.2]) by hp9000.hrz.uni-oldenburg.de (8.8.8/8.8.8/21.11.97) with ESMTP id OAA16059 for ; Mon, 1 Dec 1997 14:34:22 +0100 (MET) Received: from FB6/MAILQUEUE by mathematik.uni-oldenburg.de (Mercury 1.21); 1 Dec 97 14:34:22 MEZ-1MESZ Received: from MAILQUEUE by FB6 (Mercury 1.21); 1 Dec 97 14:34:01 MEZ-1MESZ From: "Peter Harmand" To: tex-fonts@csc-sun.math.utah.edu Date: Mon, 1 Dec 1997 14:33:54 MET-1 Subject: lw35nfss Priority: normal X-mailer: Pegasus Mail v3.22 Message-ID: <3169CB7351@mathematik.uni-oldenburg.de> The faked slanted versions of the 8r-encoded metrics in lw35nfss.zip don't have ligatures and kernings. Since new Type1-in-TeX users may want to start with the standard 35, since the README in the psfonts directory claims "All fonts have ligatures and kerning (no ``raw'' fonts); therefore, even the *8r base fonts can be used for real typesetting" (however, nobody is doing this), and since we still have to wait a few month until we can point people at a new bit of documentation at CTAN, I think this should be corrected. The metrics in the adobe directory seem to be ok. (I only checked Times and Palatino -- sorry, I build my own metrics.) Peter 1-Dec-1997 14:17:01-GMT,1827;000000000000 Return-Path: Received: from pillar.elsevier.co.uk (root@pillar.elsevier.co.uk [193.131.222.35]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id HAA01448 for ; Mon, 1 Dec 1997 07:17:00 -0700 (MST) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by pillar.elsevier.co.uk (8.8.5/8.8.5) with ESMTP id OAA09441 for ; Mon, 1 Dec 1997 14:15:07 GMT Received: from SRAHTZ (actually host srahtz.elsevier.co.uk) by snowdon.elsevier.co.uk with SMTP (PP); Mon, 1 Dec 1997 14:17:13 +0000 Date: Mon, 1 Dec 1997 14:08:20 +0000 Message-ID: <4573-Mon01Dec1997140820+0000-s.rahtz@elsevier.co.uk> From: s.rahtz@elsevier.co.uk (Sebastian Rahtz) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: bkph@ai.mit.edu Cc: Thierry.Bouche@ujf-grenoble.fr, rebecca@astrid.u-net.com, tex-fonts@csc-sun.math.utah.edu Subject: Re: What's the relationship between vfs and tfms? In-Reply-To: <199712011332.IAA15540@kauai.ai.mit.edu> References: <199712011018.LAA29024@mozart.ujf-grenoble.fr> <199712011332.IAA15540@kauai.ai.mit.edu> X-Mailer: VM 6.33 under Emacs 19.34.6 > Why kill a flea with a steam-press :-)? for myself, because i don't want to understand a flea killer as well as a steam-press. i want the steam press effect sometimes so yes, i use it to squash fleas. why not? i don't care much about speed (things are fine as they are), and i care more about my mental state that the use of excess computer energy. the flaw in my argument is that for strange historical reasons, my personal choices effect thousands of people --- i have an influence in the PSNFSS/dvips/LaTeX encoding world. Serves people right for following a false prophet. Sebastian 1-Dec-1997 15:11:14-GMT,2114;000000000000 Return-Path: Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id IAA02597 for ; Mon, 1 Dec 1997 08:10:56 -0700 (MST) Received: from mozart.ujf-grenoble.fr (mozart.ujf-grenoble.fr [193.54.241.5]) by ujf.ujf-grenoble.fr (8.8.5/8.8.5) with ESMTP id QAA29671; Mon, 1 Dec 1997 16:08:14 +0100 (MET) Received: (from bouche@localhost) by mozart.ujf-grenoble.fr (8.7.6/8.6.9) id QAA08804; Mon, 1 Dec 1997 16:17:48 +0100 (MET) Date: Mon, 1 Dec 1997 16:17:48 +0100 (MET) Message-Id: <199712011517.QAA08804@mozart.ujf-grenoble.fr> From: Thierry Bouche To: bkph@ai.mit.edu Cc: Thierry.Bouche@ujf-grenoble.fr, rebecca@astrid.u-net.com, tex-fonts@csc-sun.math.utah.edu Subject: Re: What's the relationship between vfs and tfms? In-Reply-To: <199712011332.IAA15540@kauai.ai.mit.edu> References: <199712011018.LAA29024@mozart.ujf-grenoble.fr> <199712011332.IAA15540@kauai.ai.mit.edu> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Concernant « Re: What's the relationship between vfs and tfms? », Berthold K.P. Horn écrit : « I was not taking about something so complex. we were talking of the current fontinst, it _does_ fake T1 glyphs that miss in t1 fonts. If we have this possibility, i don't see why we should avoid it: then we'd need a CTAN area for `national' users, one for `not too foreign' ones--happy with adobe glyphs--, and another one for `exotic users' whose language _requires_ faked glyphs (not mentionning the remaining ones that are simply `unfakable' and bound to print pages of black boxes...). « P.S. I am sorry this has taken us so far away from the documentation « for fontinst, but maybe it will clarify some font related issues « as a side effect. maybe _i_ should be sorry ;-) Thierry Bouche. ----- thierry.bouche@ujf-grenoble.fr http://www-fourier.ujf-grenoble.fr/~bouche/ 1-Dec-1997 16:35:12-GMT,3042;000000000000 Return-Path: Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id JAA04568 for ; Mon, 1 Dec 1997 09:35:11 -0700 (MST) Received: from kauai.ai.mit.edu (kauai.ai.mit.edu [128.52.54.48]) by life.ai.mit.edu (8.8.5/AI1.15/ai.master.life:1.18) with ESMTP id LAA23469; Mon, 1 Dec 1997 11:34:48 -0500 (EST) Received: (from bkph@localhost) by kauai.ai.mit.edu (8.8.5/8.8.5AI/ai.client:1.5) id LAA15613; Mon, 1 Dec 1997 11:34:47 -0500 (EST) Date: Mon, 1 Dec 1997 11:34:47 -0500 (EST) Message-Id: <199712011634.LAA15613@kauai.ai.mit.edu> From: "Berthold K.P. Horn" To: Thierry.Bouche@ujf-grenoble.fr CC: Thierry.Bouche@ujf-grenoble.fr, rebecca@astrid.u-net.com, tex-fonts@csc-sun.math.utah.edu In-reply-to: <199712011517.QAA08804@mozart.ujf-grenoble.fr> (message from Thierry Bouche on Mon, 1 Dec 1997 16:17:48 +0100 (MET)) Subject: Re: What's the relationship between vfs and tfms? Reply-to: bkph@ai.mit.edu Concernant « Re: What's the relationship between vfs and tfms? », Berthold K.P. Horn écrit : « I was not taking about something so complex. we were talking of the current fontinst, it _does_ fake T1 glyphs that miss in t1 fonts. If we have this possibility, i don't see why we should avoid it: then we'd need a CTAN area for `national' users, one for `not too foreign' ones--happy with adobe glyphs--, and another one Oh, oh :-) you just pushed another one of my buttons. T1 gives up about 30 useful glyphs to add some more Eastern European Latin glyphs. This adds to the complexity since now you need `text companion' fonts to hold these displaced glyphs (i.e. 4 TFMs + 2 VF per font instead of a single TFM!). What is worse, since T1 doesn't cover *all* of the ISO Latin characters, it isn't as much use as one might hope. For example, one would have thought that the people in Poland in particularly would be happy that the glyphs they use are included in T1. Instead they seem to prefer their own encoding that also includes the glyphs used by their neighbors (such extra characters decorated with ogonek used in Lathvia). Ironic. for `exotic users' whose language _requires_ faked glyphs (not mentionning the remaining ones that are simply `unfakable' and bound to print pages of black boxes...). If we go too far away from the basic ISO Latin glyphs (minus Greek and Cyrillic, Hebrew, and Arabic) then we are talking special fonts in any case and T1 is not applicable. In any case, its typographically cleaner to use fonts that already have all the glyphs you need. For example, Lucida Latin fonts have everything to cover ISO Latin (and in NT you can actually access them all at the same time - but not in TeX of course). « P.S. I am sorry this has taken us so far away from the documentation « for fontinst, but maybe it will clarify some font related issues « as a side effect. maybe _i_ should be sorry ;-) :-) Regards, Berthold. 1-Dec-1997 19:14:16-GMT,2827;000000000000 Return-Path: Received: from relay-smtp.imaginet.net (alcor.imaginet.fr [194.51.83.171]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id MAA08814 for ; Mon, 1 Dec 1997 12:14:15 -0700 (MST) Received: from imaginet.fr (zoltar.imaginet.fr [194.51.83.150]) by relay-smtp.imaginet.net (8.8.8/8.8.8) with ESMTP id UAA04125; Mon, 1 Dec 1997 20:11:24 +0100 (MET) Received: from [195.68.10.81] (isdn2.lille.imaginet.fr [195.68.10.81]) by imaginet.fr (8.7.5/8.7.31) with SMTP id UAA17519; Mon, 1 Dec 1997 20:14:41 +0100 (MET) Message-Id: <199712011914.UAA17519@imaginet.fr> Subject: Re: What's the relationship between vfs and tfms? Date: Mon, 1 Dec 97 20:15:05 +0200 x-sender: yannis@mail.imaginet.fr x-mailer: Claris Emailer 2.0, March 15, 1997 From: Yannis Haralambous To: cc: , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" >What is worse, since T1 doesn't cover *all* of the ISO Latin >characters, it isn't as much use as one might hope. For example, one >would have thought that the people in Poland in particularly would be >happy that the glyphs they use are included in T1. Instead they seem >to prefer their own encoding that also includes the glyphs used by >their neighbors (such extra characters decorated with ogonek used in >Lathvia). Ironic. Use Omega: not only you can have all of those but even typographic subtleties (umlaut accent higher or lower depending if you want to write French or German, etc. see our forthcoming paper for EuroTeX98). We have a Perl script that allows to create arbitrary 16-bit virtual fonts based on 8-bit fonts. >If we go too far away from the basic ISO Latin glyphs (minus Greek and >Cyrillic, Hebrew, and Arabic) then we are talking special fonts in any All that we have as well. +--------------------------------------------------------------------+ | Yannis Haralambous, Ph.D. yannis@pobox.com | | http://pobox.com/~yannis | +--------------------------------------------------------------------+ | 187, rue Nationale fax: +33 (0)3.20.40.28.64 | | 59800 Lille, France | +--------------------------------------------------------------------+ | Visit the Omega home page!! http://www.ens.fr/omega | +--------------------------------------------------------------------+ ...pour distinguer l'exterieur d'un aquarium, mieux vaut n'etre pas poisson ...the ball I threw while playing in the park has never reached the ground 1-Dec-1997 20:40:25-GMT,5882;000000000000 Return-Path: Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by csc-sun.math.utah.edu (8.8.5/8.8.5) with ESMTP id NAA11179 for ; Mon, 1 Dec 1997 13:40:24 -0700 (MST) Received: from alonzo.cs.sfu.ca (alonzo [199.60.3.17]) by cs.sfu.ca (8.8.8/8.8.8) with ESMTP id MAA26497 for ; Mon, 1 Dec 1997 12:40:23 -0800 (PST) From: "Melissa O'Neill" Received: (from oneill@localhost) by alonzo.cs.sfu.ca (8.8.8/8.8.5) id MAA16898 for tex-fonts@math.utah.edu; Mon, 1 Dec 1997 12:40:20 -0800 (PST) Message-Id: <199712012040.MAA16898@alonzo.cs.sfu.ca> Subject: `.vf's, `.enc's, `.tfms', MMs, and problems with fontinst... To: tex-fonts@csc-sun.math.utah.edu Date: Mon, 1 Dec 1997 12:40:19 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I have enjoyed hearing the discussion of the pros and cos using VFs purely for reencoding versus simply reencoding the font directly; certainly I know more about how things work than I did. Ultimately, I think Sebastian is right -- I use perl when I could use the simpler tools of grep, sed, or awk, despite its being a sledgehammer to crack a nut, both because it means I only have to deal with one tool, and because I know Perl `usually gets things right'. Similarly, one *can* use the `simpler' tool of afm2tfm (or Y&Y's proprietary tools) to make LY1, 8r, or even T1/TS1 fonts that don't use VFs. You can even do this with fontinst -- just throw away your VF file and replace lines like: phvr8r Helvetica " TeXBase1Encoding ReEncodeFont " <8r.enc ... with lines like: phvr8t Helvetica " CorkEncoding ReEncodeFont"