From NTS-L@DHDURZ1.Berkeley.EDU Wed Aug 5 00:13:27 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06937; Wed, 5 Aug 92 00:13:25 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 5 Aug 1992 00:13 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6320; Tue, 04 Aug 92 23:12:08 PDT Date: Wed, 5 Aug 92 01:54:47 -0400 From: laurent@MATH.TORONTO.EDU Subject: WHAT SUPPORT FOR NTS? Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU WHAT SUPPORT FOR NTS? Rainer does keep coming back to the BIG I$$UE! > Coming back to the position paper by Richard Palais, I'd > like to comment what he said in his postscript about what > made the creation of TeX possible: that Don Knuth is a full > tenured professor at Stanford who not only had NSF grant > support for his project, but also he is a unique individual > who is able to accomplish such a task alone. > I do indeed believe that these is one of the critical issues > of the whole NTS project: Lots of resources are needed to > allow completion of the project. In my opinion it will not > be possible to accomplish this solely in the spare time of > some volunteers. I can only hope that there will be > sufficient support for it. Such is the complexity of TeX that it is not clear that it can be made to progress a great deal further in a cost-effective way. That is one of the many reasons I hesitate to back the idea of straight-away seeking major financing for NTS. Dick Palais's confidence gathering approach making first small steps seems just the right thing. On the other hand I have a feeling that the honours showered on Knuth since the completion of Computers and Typesetting can be taken as a sign that the world of science wholly approves of Knuth having done practical programming rather than (say) quietly going on to write volumes 4--7 of the Art of Computer Programming. For those of us who feel TeX-Metafont is the great music, it is satisfying to hear the mighty applause. Further, TeX is likely to be one of the major computer languages of science for the forseeable future, and perhaps the most widely used of all. Surely then proposals to undertake work along this line will get a fair hearing in the scientific world along side of more theoretical projects. In Knuth's programming, the solidity, performance, and documentation give an inspiring example and a tough standard. His style and standards fit perfectly into the traditional university model of science. Yes, that is little science, not the big science spawned by the Los Almos project and its many sequels. For me, that means that most actors are autonomous and individually responsible scientists whose research is in or related to the NTS project --- rather than (say) administrators or project employees with collective responsibility. I occasionally get the feeling that some NTS enthousiasts would like to see a NTS project make it BIG. I presently hope that little science would prove a welcoming and adequate context for NTS --- but explicit debate is just beginning. Laurent Siebenmann Mathematique, Bat. 425, Univ de Paris-Sud, 91405-Orsay, France From NTS-L@DHDURZ1.Berkeley.EDU Wed Aug 5 00:15:24 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06952; Wed, 5 Aug 92 00:15:22 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 5 Aug 1992 00:15 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6369; Tue, 04 Aug 92 23:14:35 PDT Date: Wed, 5 Aug 92 02:13:14 EDT From: "Mark A. Friedman" Subject: Out of Town Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU I will be out of town today through Thursday (8/6) hopefully dominating noontime basketball at the UW SERF and getting in a few racquetball victories as well. ( :^)) I will be reading my mail while in Wisconsin periodically. -- Mark Professor Mark A. Friedman mark.friedman@mail.trincoll.edu Engineering and Computer Science (or friedman@starbase.trincoll.edu) Trinity College Phone: (203) 297-2519 Hartford, Connecticut 06106 Fax: (203) 297-2569 From NTS-L@DHDURZ1.Berkeley.EDU Wed Aug 5 00:15:55 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06956; Wed, 5 Aug 92 00:15:53 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 5 Aug 1992 00:15 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6383; Tue, 04 Aug 92 23:15:03 PDT Date: Tue, 4 Aug 92 23:12:57 -0700 From: Paul Barton-Davis Subject: There's no-one here right now ... Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU I'm on vacation until August 21st. In an emergency, you might reach me at 011-44-225-338076, which is my parent's number in Bath, UK. Otherwise, enjoy the weather. From NTS-L@DHDURZ1.Berkeley.EDU Wed Aug 5 08:58:17 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA12980; Wed, 5 Aug 92 08:58:15 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 5 Aug 1992 08:58 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 7827; Wed, 05 Aug 92 07:57:13 PDT Date: Wed, 5 Aug 92 10:27:17 EDT From: Michael Barr Subject: From Laurent Siebenmann Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <259F70AEAA033E69@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: nts-l@vm.urz.uni-heidelberg.de Larry Siebenmann has asked me to forward this to NTS-L because his, ``current communications are currently verrry shaky''. Sorry if it gets posted twice. Michael Barr WHAT SUPPORT FOR NTS? Rainer does keep coming back to the BIG I$$UE! > Coming back to the position paper by Richard Palais, I'd > like to comment what he said in his postscript about what > made the creation of TeX possible: that Don Knuth is a full > tenured professor at Stanford who not only had NSF grant > support for his project, but also he is a unique individual > who is able to accomplish such a task alone. > I do indeed believe that these is one of the critical issues > of the whole NTS project: Lots of resources are needed to > allow completion of the project. In my opinion it will not > be possible to accomplish this solely in the spare time of > some volunteers. I can only hope that there will be > sufficient support for it. Such is the complexity of TeX that it is not clear that it can be made to progress a great deal further in a cost-effective way. That is one of the many reasons I hesitate to back the idea of straight-away seeking major financing for NTS. Dick Palais's confidence gathering approach making first small steps seems just the right thing. On the other hand I have a feeling that the honours showered on Knuth since the completion of Computers and Typesetting can be taken as a sign that the world of science wholly approves of Knuth having done practical programming rather than (say) quietly going on to write volumes 4--7 of the Art of Computer Programming. For those of us who feel TeX-Metafont is the great music, it is satisfying to hear the mighty applause. Further, TeX is likely to be one of the major computer languages of science for the forseeable future, and perhaps the most widely used of all. Surely then proposals to undertake work along this line will get a fair hearing in the scientific world along side of more theoretical projects. In Knuth's programming, the solidity, performance, and documentation give an inspiring example and a tough standard. His style and standards fit perfectly into the traditional university model of science. Yes, that is little science, not the big science spawned by the Los Almos project and its many sequels. For me, that means that most actors are autonomous and individually responsible scientists whose research is in or related to the NTS project --- rather than (say) administrators or project employees with collective responsibility. I occasionally get the feeling that some NTS enthousiasts would like to see a NTS project make it BIG. I presently hope that little science would prove a welcoming and adequate context for NTS --- but explicit debate is just beginning. Laurent Siebenmann Mathematique, Bat. 425, Univ de Paris-Sud, 91405-Orsay, France From NTS-L@DHDURZ1.Berkeley.EDU Thu Oct 8 11:51:47 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA19824; Thu, 8 Oct 92 11:51:45 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 8 Oct 1992 11:41 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 2535; Thu, 08 Oct 92 10:36:18 PDT Date: Thu, 8 Oct 92 18:26:38 BST From: CHAA006@VAX.RHBNC.AC.UK Subject: Transcending filename restrictions Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: RHBNC Philip Taylor Message-Id: <871F8CBC6C017B53@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "nts-l" >>> This issue has been discussed before. I believe it is even mentioned in >>> Karl Berry's article on font naming conventions. A reasonable, architecture >>> independant solution is to use a "name look-aside buffer". Allow TeX and >>> DVI drivers to look in some external file to associate font names with >>> file names. Then I could have: An alternative, also mooted on LaTeX-L, would be to implement a virtual file system, allowing arbitrarily complex filenames to be used on all systems. Real-time packers/unpackers such as STACKER [1] have shewn that the idea is viable even on simple operating system such as MS/DOS. Philip Taylor, RHBNC. [1] STACKER: A proprietary real-time file compression/decompression utility for MS/DOS. Believed to now be bundled with DR/DOS. From NTS-L@DHDURZ1.Berkeley.EDU Thu Oct 8 12:14:39 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20195; Thu, 8 Oct 92 12:14:37 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 8 Oct 1992 12:11 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1090; Thu, 08 Oct 92 10:17:24 PDT Date: Thu, 8 Oct 92 12:45:44 EDT From: Michael Barr Subject: font names Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <8B33D0958C013F22@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: nts-l@vm.hd-net.uni-heidelberg.de There was a recent posting on one of the TeX networks by Bertholdi Horn suggesting that future versions of TeX omit MS-DOS support. The reason for this absurd suggestion (which would lose probably 80% of all users) was the restrictions caused by short font names that, effectively, limited them to 6 chars, plus two for the design size. It also limited the latter to 99 point. As a result, I made a suggestion that I sent to the latex net. This was inappropriate in that it would require a minor change to TeX and output drivers and thus was tenable only if TeX was being changed anyway. In naming fonts, we waste 3 chars of the 8.3 format imposed by MS-DOS to specify what amounts to 2 bits of information. After all, a font name can have only one of 4 extensions: gf, pk, pxl or tfm. If I have left out a couple they can readily be accomodated. My original proposal was to rename all the fonts so that the extension was dds where dd was the design size and s was a single character to designate the actual type, say g, p, x and m, respectively for the four above. So cmr.10m would be the new name for cmr10.tfm and so on. Then Frank Mittelbach observed that if we used hex designators, we could extend the 99pt limit to 255 point. Then cmr10.tfm would become cmr.0am. A bit less than user-friendly, admittedly, but the typical user very rarely has to deal with it. A lot less disruptive than dropping MS-DOS support. Later, when NT has replaced MS-DOS, we can rethink this. In the meantime, I would like to make this a formal suggestion if and when there is an NTS. Although 8 characters is not going to be sufficient either, it is a lot better than 6. Michael Barr From NTS-L@DHDURZ1.Berkeley.EDU Thu Oct 8 12:19:46 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20229; Thu, 8 Oct 92 12:19:44 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 8 Oct 1992 12:17 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 2148; Thu, 08 Oct 92 10:31:15 PDT Date: Thu, 8 Oct 92 13:12:09 -0400 From: Norman Walsh Subject: font names Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: walsh@cs.umass.edu Message-Id: <8C11EE00FC01574D@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "NTS-L Distribution list" Michael Barr writes: > There was a recent posting on one of the TeX networks by Bertholdi Horn > suggesting that future versions of TeX omit MS-DOS support. The > reason for this absurd suggestion (which would lose probably 80% of all > users) was the restrictions caused by short font names that, > effectively, limited them to 6 chars, plus two for the design size. It > also limited the latter to 99 point. As a result, I made a suggestion > that I sent to the latex net. This was inappropriate in that it would > require a minor change to TeX and output drivers and thus was tenable > only if TeX was being changed anyway. This issue has been discussed before. I believe it is even mentioned in Karl Berry's article on font naming conventions. A reasonable, architecture independant solution is to use a "name look-aside buffer". Allow TeX and DVI drivers to look in some external file to associate font names with file names. Then I could have: % font definition file cmr10 cmr10 computer-modern-roman-10 cmr10 adobe-something-else xyzzy % % blah, blah, blah % And I could say % tex file \font\rm=cmr10 \font\alsorm=computer-modern-roman-10 \font\somethingelse=adobe-something-else at 34pt % % blah, blah, blah % In fact, I believe that DEK even granted permission to incorporate this into TeX as a "system dependent" extension or some such. Regards, norm --- Norman Walsh | University of Massachusetts, Amherst, MA 01003 | CMPSCI Dept., LGRC A210 | Standard disclaimer applies "A little sunlight is the best disinfectant." -- Justice Louis Brandeis From NTS-L@DHDURZ1.Berkeley.EDU Thu Oct 8 12:22:25 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA20243; Thu, 8 Oct 92 12:22:23 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 8 Oct 1992 12:19 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5324; Thu, 08 Oct 92 11:16:40 PDT Date: Fri, 9 Oct 92 03:34:17 EST From: Anthony Shipman Subject: Re: font names In-Reply-To: <199210081714.AA01430@yarra.pyramid.com.au>; from "Norman Walsh" atOct 8, 92 1:12 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <8C51A5A63C014457@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "TeX NTS - new ideas" > > This issue has been discussed before. I believe it is even mentioned in > Karl Berry's article on font naming conventions. A reasonable, architecture > independant solution is to use a "name look-aside buffer". Allow TeX and > DVI drivers to look in some external file to associate font names with > file names. Then I could have: > > % font definition file > cmr10 cmr10 > computer-modern-roman-10 cmr10 > adobe-something-else xyzzy > % > % blah, blah, blah > % > ..................... > In fact, I believe that DEK even granted permission to incorporate this > into TeX as a "system dependent" extension or some such. > Just as an aside, I mentioned this before in comp.text.tex in a different context. Let the file names be full OS-dependent paths to eliminate the horrible OS-dependent sub-directory searching that goes in (Unix)TeX and the dvi drivers. Let a simpler OS-dependent utility do the searching beforehand and set up the file. -- Anthony Shipman "You've got to be taught before it's too late, CP Software Export Pty Ltd, Before you are six or seven or eight, 19 Cato St., East Hawthorn, To hate all the people your relatives hate, Melbourne, Australia, 3121 You've got to be carefully taught." R&H E-mail: als@bohra.cpg.oz.au From NTS-L@DHDURZ1.Berkeley.EDU Thu Oct 8 16:45:26 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27675; Thu, 8 Oct 92 16:45:22 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Thu, 8 Oct 1992 16:44 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 0477; Thu, 08 Oct 92 15:42:34 PDT Date: Thu, 8 Oct 92 23:32:44 +0100 From: yannis Subject: Re: font names Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU | | In naming fonts, we waste 3 chars of the 8.3 format imposed by MS-DOS to | specify what amounts to 2 bits of information. After all, a font name | can have only one of 4 extensions: gf, pk, pxl or tfm. If I have left WRONG: you have also mf, log, pl, vpl, vf, dvi (output of GFtoDVI), ps (output of MacMF and MetaPost) and I'm not trying to contradict you: it happens that I have everyday files cmr10.mf, cmr10.log, cmr10.pl, NewTimesRoman.vpl, NewTimesRoman.vf cmr10.dvi and cmr10.ps in front of me. Maybe some of them are not actually ``fonts'' (like cmr10.dvi), but they still have the *same names* as fonts. Yannis From NTS-L@DHDURZ1.BITNET Fri Oct 16 03:27:44 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06387; Fri, 16 Oct 92 03:27:43 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 16 Oct 1992 03:27 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 8776; Fri, 16 Oct 92 02:26:43 PDT Date: Wed, 14 Oct 92 12:42:45 -0400 From: Karl Berry Subject: font names In-Reply-To: Norman Walsh's message of Thu, 8 Oct 92 13:12:09 -0400 <199210081713.AA04364@cs.umb.edu> Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: karl@cs.umb.edu Message-Id: <8B63D0119400274D@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU [from Norman Walsh] In fact, I believe that DEK even granted permission to incorporate this [a fontname mapping file] into TeX as a "system dependent" extension or some such. I asked Knuth as a courtesy. It is a system dependency (as is anything having to do with filenames), and thus is within the realm of allowable changes. [from Philip Taylor] An alternative, also mooted on LaTeX-L, would be to implement a virtual file system, allowing arbitrarily complex filenames to be used on all You mean implement a virtual file system within TeX? This sounds like a big job. A simple lookup file does almost the same thing, doesn't it? [from Anthony Shipman] Let the file names be full OS-dependent paths I don't understand. Are you really proposing putting filenames for fonts and input files like /foo/bar/baz into documents? That would make them completely nonportable, it seems to me. eliminate the horrible OS-dependent sub-directory searching that goes in (Unix)TeX I don't think value judgements like ``horrible'' can serve a useful purpose on lists like this. (In my own defense, as the person who perpetrated subdir searching, if you don't like subdirectory searching, you don't have to use it.) From NTS-L@DHDURZ1.BITNET Fri Oct 16 04:55:16 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA08923; Fri, 16 Oct 92 04:55:13 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 16 Oct 1992 04:55 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 9812; Fri, 16 Oct 92 03:54:13 PDT Date: Fri, 16 Oct 92 19:39:23 EST From: Anthony Shipman Subject: Re: font names In-Reply-To: <199210160928.AA07436@yarra.pyramid.com.au>; from "Karl Berry" at Oct 14, 92 12:42 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <979CEC5094002716@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "TeX NTS - new ideas" > [from Anthony Shipman] > Let the file names be full OS-dependent paths > > I don't understand. Are you really proposing putting filenames for > fonts and input files like /foo/bar/baz into documents? That would make > them completely nonportable, it seems to me. Not in documents of course. Someone was proposing a map file that mapped from font names in documents to external names. I suggested that the OS names be full path names for maximum flexibility, being more general and faster than subdirectory searching. > > eliminate the horrible OS-dependent sub-directory searching that > goes in (Unix)TeX > > I don't think value judgements like ``horrible'' can serve a useful > purpose on lists like this. (In my own defense, as the person who > perpetrated subdir searching, if you don't like subdirectory searching, > you don't have to use it.) > The idea's fine. But supporting very OS-dependent stuff like directory searching in both TeX and multiple driver programs is ``horrible'' plus there is the run-time overhead of directory searching. My suggestion is to do the searching off-line in the process of building the map file of above. Then the searching code is extracted out into a single place, the map utility. -- Anthony Shipman "You've got to be taught before it's too late, CP Software Export Pty Ltd, Before you are six or seven or eight, 19 Cato St., East Hawthorn, To hate all the people your relatives hate, Melbourne, Australia, 3121 You've got to be carefully taught." R&H E-mail: als@bohra.cpg.oz.au From NTS-L@DHDURZ1.BITNET Fri Oct 16 04:55:28 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA08927; Fri, 16 Oct 92 04:55:27 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 16 Oct 1992 04:55 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 9822; Fri, 16 Oct 92 03:54:27 PDT Date: Fri, 16 Oct 92 11:50:57 BST From: CHAA006@VAX.RHBNC.AC.UK Subject: Re: font names Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: RHBNC Philip Taylor Message-Id: <97A56A8A24002619@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU >>> [from Philip Taylor] >>> An alternative, also mooted on LaTeX-L, would be to implement a virtual >>> file system, allowing arbitrarily complex filenames to be used on all >>> You mean implement a virtual file system within TeX? This sounds like a >>> big job. A simple lookup file does almost the same thing, doesn't it? No, not within TeX, without TeX. If it were implemented within TeX, then a human would have to know the mapping between 8+3 & ; if implemented as an O/S-specific virtual file system, then only the author of the VFS would either care about, or need to know, the mapping (and even he or she need not: it could be entirely dynamic). Of course, if the VFS is 1:1 and the mapping ill-defined, the na{\"\i}ve user might accidentally (or even deliberately) delete a TeX file (e.g. Delete 14AF20DE.0FC); better would be a many:one mapping, such that _all_ files in the VFS were mapped to (i.e. contained in) one native-mode file. This is the technique which STACKER uses. ** Phil. From NTS-L@DHDURZ1.BITNET Mon Oct 19 13:07:16 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA16537; Mon, 19 Oct 92 13:07:12 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 19 Oct 1992 13:03 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1190; Mon, 19 Oct 92 11:37:34 PDT Date: Mon, 19 Oct 92 18:14:01 BST From: Timothy Murphy Subject: Re: font names Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <375DA0CF4400CF7F@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU > [from Anthony Shipman] > > eliminate the horrible OS-dependent sub-directory searching that > goes in (Unix)TeX > > I don't think value judgements like ``horrible'' can serve a useful > purpose on lists like this. (In my own defense, as the person who > perpetrated subdir searching, if you don't like subdirectory searching, > you don't have to use it.) I for one think subdirectory searching is very useful. The number of style files has become so large that some organisation is essential. I'm not sure that Karl has implemented this in the optimal way at the moment -- or maybe he hasn't explained clearly enough how one ought to organise one's TEXINPUTS tree. Timothy Murphy e-mail: tim@maths.tcd.ie tel: +353-1-2842366 (home/office) +353-1-7021507 (university) fax: +353-1-2842295 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From NTS-L@DHDURZ1.BITNET Mon Oct 19 21:32:04 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA25023; Mon, 19 Oct 92 21:32:02 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 19 Oct 1992 21:31 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1555; Mon, 19 Oct 92 20:31:54 PDT Date: Tue, 20 Oct 92 13:18:10 EST From: Anthony Shipman Subject: Re: font names In-Reply-To: <199210191749.AA05647@yarra.pyramid.com.au>; from "Timothy Murphy"at Oct 19, 92 6:14 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <7E5CF1AB4400D443@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "TeX NTS - new ideas" Well I'm putting my money where my mouth is. I've started work on what I call "texfs", a TeX font and file server. The need: We have a number of work stations that I would like to run TeX on but of course I only want one copy of the fonts and style files etc. The usual solution to this is NFS. But with texfs I can go a step further. texfs is inspired by the X11R5 font server. This supplies bitmap fonts to X servers on the LAN. The bitmaps can be generated on the fly from eg Adobe Type 1 fonts. This is what I would like to expand texfs into. (I decided it was easier to implement my own rather than try to modify the X11R5 fs protocol to suit TeX.) The stages I envisage are: 1a Get a basic texfs going that supplies existing font and other files from a server. 1b Use the MakeTeXPK mechanism of xdvi to generate TeX fonts on the fly. 2 Generate pk files from Type 1 fonts, possibly using the free font renderer supplied by Adobe to the X11R5 font server. Another possibility is one of the Adobe->MF converters. 3 Try for TrueType fonts. (Disclaimer: None of this solves the problem of math fonts of course. TeX math fonts may always be restricted to a few special ones like the Lucida New Math). All font directory layout policy can be centralised in texfs. What I have in mind is if a directory in a font path has a file named "texfonts.dir" then it is looked up for mapping the file name to a different path which may be relative to the current path or absolute. Status: Stage 1a is working in prototype with TeX on HPUX. It is built using the SUN RPC system (the same used by NFS). At the moment texfs is single threaded. I have modified the web2c common/extra.c and a few Makefiles to hook into the texfs client library when it opens files. For simplicity, when a file is opened it is copied whole from the server into /tmp on the local system and then TeX reads it from there. The format files are normally not served over the network! Comments? Brickbats? Am I reinventing the wheel? Suggestions for extra features? -- Anthony Shipman "You've got to be taught before it's too late, CP Software Export Pty Ltd, Before you are six or seven or eight, 19 Cato St., East Hawthorn, To hate all the people your relatives hate, Melbourne, Australia, 3121 You've got to be carefully taught." R&H E-mail: als@bohra.cpg.oz.au From NTS-L@DHDURZ1.BITNET Tue Oct 20 02:40:41 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29368; Tue, 20 Oct 92 02:40:40 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 20 Oct 1992 02:40 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 6427; Tue, 20 Oct 92 01:40:32 PDT Date: Tue, 20 Oct 92 09:36:50 CET From: Nicolas Jungers Subject: Font Names & texfs Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L@VM.URZ.UNI-HEIDELBERG.DE Anthony Shipman wrote about a TeX font and file server. Some comments: 1) as I understand texfs is not a TeX file! 2) what about copyright? 3) what will be the encoding vector of the bitmap generated 4) what about names? the actual problem for me is to distinguish between "Futura" from Adobe, "Futura" from Bitstream, "Futura" from The Font Company, "Futura" from Agfa, ... All those "Futura" have very similar names (Futura-something) and different shapes and metrics. In fact some font collection re-use font from other collection, the best example is the Linotype collection vs the Adobe collection. Because of TeX TFM confusing content, the encoding vector must be part of the name, and because MS-Dos user, the name must fit in 11 characters. There is one obvious solution to this problem. Just because Adobe is facing the realy same problem they have introduce the "unique ID" identification for fonts. Their is one 32 bits space for numbering each type of font (actually type 1, type 3 and the new type 0). But: 1) this unique ID is not mandatory (but almost for commercial products), 2) what kind of user will be happy to deal with the font: "0E142C41.1FM", 3) the font identification will take 9 characters (less with a more compact expression of a 32 bits number), 4) you must also add the coding scheme, for exemple a K for Cork, ... Nicolas Jungers From NTS-L@DHDURZ1.BITNET Tue Oct 20 03:56:49 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00418; Tue, 20 Oct 92 03:56:47 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 20 Oct 1992 03:56 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 7898; Tue, 20 Oct 92 02:56:39 PDT Date: Tue, 20 Oct 92 19:03:32 EST From: Anthony Shipman Subject: Re: Font Names & texfs In-Reply-To: <199210200841.AA23694@yarra.pyramid.com.au>; from "Nicolas Jungers"at Oct 20, 92 9:36 am Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "TeX NTS - new ideas" > > > > Anthony Shipman wrote about a TeX font and file server. > > Some comments: > 1) as I understand texfs is not a TeX file! No. It's a C program. Strongly UNIX oriented at the moment. > 2) what about copyright? It will be freely available a la the rest of TeX plus/minus whatever copyrights apply to the X11R5 stuff I use. > 3) what will be the encoding vector of the bitmap generated This is an issue. texfs should probably recode into cmr format. It should be reconfigurable. > 4) what about names? > the actual problem for me is to distinguish between "Futura" from > Adobe, "Futura" from Bitstream, "Futura" from The Font Company, > "Futura" from Agfa, ... > All those "Futura" have very similar names (Futura-something) and > different shapes and metrics. In fact some font collection re-use > font from other collection, the best example is the Linotype > collection vs the Adobe collection. > Because of TeX TFM confusing content, the encoding vector must be > part of the name, and because MS-Dos user, the name must fit in > 11 characters. Is this 11 character limit just in the DOS file system? What is the maximum length of a font name in TeX itself? If only DOS is the problem then it can be taken care of in a mapping file. The map key is the font name used in the document which conforms to TeX rules. The map result is a DOS file name. e.g. for \font\fut=adobefutura12 the map file might contain adobefutura12 c:\texfonts\adobe\futura12 where the DOS directory contains the .tfm and .pf? files. Extra attention is needed for virtual fonts and recoding. This can be implemented in emtex et al now. -- Anthony Shipman "You've got to be taught before it's too late, CP Software Export Pty Ltd, Before you are six or seven or eight, 19 Cato St., East Hawthorn, To hate all the people your relatives hate, Melbourne, Australia, 3121 You've got to be carefully taught." R&H E-mail: als@bohra.cpg.oz.au From NTS-L@DHDURZ1.BITNET Tue Oct 20 04:37:51 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01151; Tue, 20 Oct 92 04:37:49 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 20 Oct 1992 04:37 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 8788; Tue, 20 Oct 92 03:37:33 PDT Date: Tue, 20 Oct 92 19:03:32 EST From: Anthony Shipman Subject: Re: Font Names & texfs In-Reply-To: <199210200841.AA23694@yarra.pyramid.com.au>; from "Nicolas Jungers"at Oct 20, 92 9:36 am Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "TeX NTS - new ideas" > > > > Anthony Shipman wrote about a TeX font and file server. > > Some comments: > 1) as I understand texfs is not a TeX file! No. It's a C program. Strongly UNIX oriented at the moment. > 2) what about copyright? It will be freely available a la the rest of TeX plus/minus whatever copyrights apply to the X11R5 stuff I use. > 3) what will be the encoding vector of the bitmap generated This is an issue. texfs should probably recode into cmr format. It should be reconfigurable. > 4) what about names? > the actual problem for me is to distinguish between "Futura" from > Adobe, "Futura" from Bitstream, "Futura" from The Font Company, > "Futura" from Agfa, ... > All those "Futura" have very similar names (Futura-something) and > different shapes and metrics. In fact some font collection re-use > font from other collection, the best example is the Linotype > collection vs the Adobe collection. > Because of TeX TFM confusing content, the encoding vector must be > part of the name, and because MS-Dos user, the name must fit in > 11 characters. Is this 11 character limit just in the DOS file system? What is the maximum length of a font name in TeX itself? If only DOS is the problem then it can be taken care of in a mapping file. The map key is the font name used in the document which conforms to TeX rules. The map result is a DOS file name. e.g. for \font\fut=adobefutura12 the map file might contain adobefutura12 c:\texfonts\adobe\futura12 where the DOS directory contains the .tfm and .pf? files. Extra attention is needed for virtual fonts and recoding. This can be implemented in emtex et al now. -- Anthony Shipman "You've got to be taught before it's too late, CP Software Export Pty Ltd, Before you are six or seven or eight, 19 Cato St., East Hawthorn, To hate all the people your relatives hate, Melbourne, Australia, 3121 You've got to be carefully taught." R&H E-mail: als@bohra.cpg.oz.au From NTS-L@DHDURZ1.BITNET Tue Oct 20 08:23:25 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06072; Tue, 20 Oct 92 08:23:22 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 20 Oct 1992 08:23 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 7470; Tue, 20 Oct 92 07:22:17 PDT Date: Tue, 20 Oct 92 15:11:58 BST From: Timothy Murphy Subject: Re: Font Names & texfs In-Reply-To: Anthony Shipman's message of Tue, 20 Oct 92 19:03:32 EST Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU Wouldn't it be simpler for the program just to look up a TFM file in a "map file" if it isn't found in TEXINPUTS? (This could easily be implemented in web2c, without any changes to tex.ch .) Timothy Murphy e-mail: tim@maths.tcd.ie tel: +353-1-2842366 (home/office) +353-1-7021507 (university) fax: +353-1-2842295 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From NTS-L@DHDURZ1.BITNET Tue Oct 20 08:33:04 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06118; Tue, 20 Oct 92 08:33:02 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 20 Oct 1992 08:32 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 8097; Tue, 20 Oct 92 07:32:08 PDT Date: Tue, 20 Oct 92 15:27:17 BST From: Timothy Murphy Subject: Re: font names In-Reply-To: Anthony Shipman's message of Tue, 20 Oct 92 13:18:10 EST Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU > Well I'm putting my money where my mouth is. I've started work on what I call > "texfs", a TeX font and file server. ... > Comments? Brickbats? Am I reinventing the wheel? Suggestions for extra > features? Sorry, I was reading through my mail backwards, and came across your later posting first. I didn't realise you were talking about PK files, in other words TeX drivers rather than TeX itself. (Since you referred to the TeX program I assumed you were thinking of TFM files.) But much the same point holds. I don't see why I should have to list all my fonts in some file, just because you are very rich and have lots of workstations (and apparently don't want to run NFS). Why not just bring your yoke into effect if a font-file is _not_ found? In any case, it seems to me you would have to persuade Tomas Rokicki that what you are suggesting would be a Good Thing for dvips. Timothy Murphy e-mail: tim@maths.tcd.ie tel: +353-1-2842366 (home/office) +353-1-7021507 (university) fax: +353-1-2842295 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From NTS-L@DHDURZ1.BITNET Tue Oct 20 08:44:39 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA06351; Tue, 20 Oct 92 08:44:36 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 20 Oct 1992 08:44 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 8892; Tue, 20 Oct 92 07:44:08 PDT Date: Tue, 20 Oct 92 15:41:00 BST From: CHAA006@VAX.RHBNC.AC.UK Subject: Re: Font Names & texfs Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: RHBNC Philip Taylor Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU Timothy Murphy wrote: >>> (This could easily be implemented in web2c, >>> without any changes to tex.ch .) I have made this point before, and am reluctant to labour it, but it seems still not to be widely understood (or perhaps, more realistically, not to be widely accepted): Not all the world uses, or wishes to use, Web2C or any of its derivatives (C-Web, etc). The definitive source language for the TeX system is WEB, pure and simple (i.e. Pascal-based). No modification to the TeX system will be portable if it can only be implemented through C; as the Pascal-to-C route is well-defined (as in Web2C), surely such proposals should be defined in terms of their implementability in .Web, not in system-dependent modules such as Web2C? Philip Taylor, RHBNC. From NTS-L@DHDURZ1.BITNET Tue Oct 20 09:19:45 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA07603; Tue, 20 Oct 92 09:19:44 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 20 Oct 1992 09:19 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 1096; Tue, 20 Oct 92 08:19:07 PDT Date: Tue, 20 Oct 92 14:54:12 GMT From: spqr@MINSTER.YORK.AC.UK Subject: Re: Font Names & texfs Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU > Not all the world uses, or wishes to use, Web2C or any of its > derivatives (C-Web, etc). The definitive source language for the I seem to be getting strange messages from NTS these days. I thought it was about the philosophy behind a projected design of a New Typesetting System, but my mail seems to be about font files in TeX 3.x, and Pascal WEB, and things like that. does anyone else get these anomalous mails? > TeX system is WEB, pure and simple (i.e. Pascal-based). No WEB is a philosophy, not a Pascal notation. Web to C is just one variant of the weaving process. a fine state we'd be in if we all had to rely on Pascal compilers - how many people reading this still *have* a Pascal compiler on their computer? or know of a public domain one they could acquire? does anyone think Knuth uses Pascal any more? or we more realistically in fact know that *he* uses C-Web and edits it with gnu emacs? by all means lets treat DOS as a lowest common denominator (sigh). but no need to sink as low as Pascal. > in Web2C), surely such proposals should be defined in terms of > their implementability in .Web, not in system-dependent > modules such as Web2C? WEB is not set in concrete. describe what's needed in WEB and let the Weavers and Changefilewriters work out how to implement it on system X. as for the whole font mapping/naming/serving business, surely this is not really important to NTS? to TeX today, maybe, but the research into god-knows-what-sort-of-virtual-file-systems seems to be chugging along somewhere, so how about just using the general tools? like, as Timothy said, NFS.... sebastian From NTS-L@DHDURZ1.BITNET Tue Oct 20 09:40:54 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AB08293; Tue, 20 Oct 92 09:40:52 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Tue, 20 Oct 1992 09:40 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 2064; Tue, 20 Oct 92 08:39:46 PDT Date: Tue, 20 Oct 92 16:31:11 BST From: CHAA006@VAX.RHBNC.AC.UK Subject: Re: Font Names & texfs Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: RHBNC Philip Taylor Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU >>> WEB is not set in concrete. describe what's needed in WEB and let the >>> Weavers and Changefilewriters work out how to implement it on system X. [I agree that this is an inappropriate forum, so wil keep my reply brief] That was my point exactly: describe what's needed in WEB, and _don't_ assume Web2C. I don't think we really differ on this one; just a different perspective. ** Phil. From NTS-L@DHDURZ1.BITNET Wed Oct 21 07:04:43 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28333; Wed, 21 Oct 92 07:04:41 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 21 Oct 1992 07:04 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5762; Wed, 21 Oct 92 06:04:12 PDT Date: Wed, 21 Oct 92 14:42:13 EST From: Anthony Shipman Subject: Re: font names In-Reply-To: <199210201434.AA20032@yarra.pyramid.com.au>; from "Timothy Murphy"at Oct 20, 92 3:27 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <97801973E4013715@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "TeX NTS - new ideas" > > But much the same point holds. > I don't see why I should have to list all my fonts in some file, > just because you are very rich and have lots of workstations > (and apparently don't want to run NFS). > Why not just bring your yoke into effect > if a font-file is _not_ found? That's what I had in mind. The map file is used if it is found in a directory from the path, for appropriate paths. One wouldn't expect users to create a map file when the path contains "." for example. I haven't implemented this map stuff yet so I can't claim experience on the best way to use it. Some possible policies are if map file exists in the directory map through the file else check for the font in the directory or if font file exists in the directory use it else if map file exists in the directory map through the file and you could mix in subdirectory searching as well although that's getting a bit heavy. pick a policy... -- Anthony Shipman "You've got to be taught before it's too late, CP Software Export Pty Ltd, Before you are six or seven or eight, 19 Cato St., East Hawthorn, To hate all the people your relatives hate, Melbourne, Australia, 3121 You've got to be carefully taught." R&H E-mail: als@bohra.cpg.oz.au From NTS-L@DHDURZ1.BITNET Wed Oct 21 07:05:02 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA28343; Wed, 21 Oct 92 07:05:00 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Wed, 21 Oct 1992 07:04 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5777; Wed, 21 Oct 92 06:04:15 PDT Date: Wed, 21 Oct 92 14:50:58 EST From: Anthony Shipman Subject: Re: Font Names & texfs In-Reply-To: <199210201519.AA23136@yarra.pyramid.com.au>; from"spqr@MINSTER.YORK.AC.UK" at Oct 20, 92 2:54 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <978866B264014916@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "TeX NTS - new ideas" > > as for the whole font mapping/naming/serving business, surely this is > not really important to NTS? to TeX today, maybe, but the research > into god-knows-what-sort-of-virtual-file-systems seems to be chugging > along somewhere, so how about just using the general tools? like, as > Timothy said, NFS.... People's philisophy on NTS differs. I would hope that future technology builds on present-day experience. I don't pretend that anything I am doing should make it into NTS, but... The font management in TeX is way behind the state of the art. What I really want out of my texfs is a nice way to use all those TrueType and Adobe fonts that are floating around without having lots of bitmap files. Windows generates bitmaps on the fly from TrueType fonts. I want something like that. Perhaps something can be learned for the future from my experiences with texfs. Take it or leave it. I'm concentrating on solving my immediate problems. -- Anthony Shipman "You've got to be taught before it's too late, CP Software Export Pty Ltd, Before you are six or seven or eight, 19 Cato St., East Hawthorn, To hate all the people your relatives hate, Melbourne, Australia, 3121 You've got to be carefully taught." R&H E-mail: als@bohra.cpg.oz.au From NTS-L@DHDURZ1.BITNET Fri Oct 23 03:07:20 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26878; Fri, 23 Oct 92 03:07:19 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 23 Oct 1992 03:07 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5742; Fri, 23 Oct 92 02:07:01 PDT Date: Wed, 21 Oct 92 12:17:18 MEZ From: Joachim Schrod Subject: Re: Font Names & texfs In-Reply-To: <199210210519.AA26195@rs3.hrz.th-darmstadt.de>; from "Anthony Shipman" at Oct 21, 92 2:50 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <08B05E98B401804D@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: NTS-L@vm.hd-net.uni-heidelberg.de You wrote: > > > as for the whole font mapping/naming/serving business, surely this is > > not really important to NTS? to TeX today, maybe, but the research > > into god-knows-what-sort-of-virtual-file-systems seems to be chugging > > along somewhere, so how about just using the general tools? like, as > > Timothy said, NFS.... > > People's philisophy on NTS differs. I would hope that future > technology builds on present-day experience. I don't pretend that > anything I am doing should make it into NTS, but... > > The font management in TeX is way behind the state of the art. What I > really want out of my texfs is a nice way to use all those TrueType and > Adobe fonts that are floating around without having lots of bitmap > files. Windows generates bitmaps on the fly from TrueType fonts. I > want something like that. TeX does not have to do ANYTHING with bitmaps. This was already said, but obviously you did not listen. You do NOT talk about TeX -- you talk about drivers. This means especially that you name `texfs' is plain wrong. It's not a font server for TeX, it's a font server for systems which use bitmapped fonts in PK format. (Eg, DVI drivers for groff, GNU's troff version.) But: If you want to imply that NTS shall be a glyph based system, which knows already about the forms of letters, not only about their dimensions; if that is the reason you think that NTS-L is the appropriate forum for discussing font servers, than you should state this. (Needless to say, I'm opposed to an idea which would bring the state of the art back behind TeX.) Otherwise comp.text.tex/info-tex might be the more appropriate forum for this idea. (I don't want to imply that I think it's a bad idea. IMHO here's simply not the place to discuss it.) -- Joachim =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Joachim Schrod Email: schrod@iti.informatik.th-darmstadt.de Computer Science Department Technical University of Darmstadt, Germany From NTS-L@DHDURZ1.BITNET Fri Oct 23 03:16:45 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26903; Fri, 23 Oct 92 03:16:44 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 23 Oct 1992 03:16 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5832; Fri, 23 Oct 92 02:16:33 PDT Date: Wed, 21 Oct 92 21:24:34 BST From: Timothy Murphy Subject: Re: Font Names & texfs In-Reply-To: CHAA006@VAX.RHBNC.AC.UK's message of Tue, 20 Oct 92 15:41:00 BST Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <0A031C956401AB5F@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU Philip Taylor writes: > Not all the world uses, or wishes to use, Web2C or any of its derivatives > (C-Web, etc). The definitive source language for the TeX system is WEB, pure > and simple (i.e. Pascal-based). No modification to the TeX system will be > portable if it can only be implemented through C; as the Pascal-to-C route is > well-defined (as in Web2C), surely such proposals should be defined in terms o f > their implementability in .Web, not in system-dependent modules such as > Web2C? Sorry Philip, I'd forgotten your sensitivities! BEGIN Some of my best friends use Pascal. END But surely the font-searching stuff can't really belong in the web file. It's intrinsically system dependent, as far as I can see. Anyway, the suggestion made related to PK files, so actually seems to have nothing to do with tex.web anyway. In fact it's always seemed to me that C++ was the obvious language for playing with fonts, with a font object having "methods" to open and read it. There are several places in TeX which would benefit from C++, IMHO. And if the C++ were to come from web, presumably web would have to encompass objects. Timothy Murphy e-mail: tim@maths.tcd.ie tel: +353-1-2842366 (home/office) +353-1-7021507 (university) fax: +353-1-2842295 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From NTS-L@DHDURZ1.BITNET Fri Oct 23 04:56:43 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA29339; Fri, 23 Oct 92 04:56:40 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 23 Oct 1992 04:56 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 7239; Fri, 23 Oct 92 03:56:29 PDT Date: Fri, 23 Oct 92 19:18:51 EST From: Anthony Shipman Subject: Re: Font Names & texfs In-Reply-To: <199210230907.AA14309@yarra.pyramid.com.au>; from "Joachim Schrod"at Oct 21, 92 12:17 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <17F86D1B9401AF13@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "TeX NTS - new ideas" > > TeX does not have to do ANYTHING with bitmaps. This was already said, > but obviously you did not listen. > > You do NOT talk about TeX -- you talk about drivers. This means > especially that you name `texfs' is plain wrong. It's not a font > server for TeX, it's a font server for systems which use bitmapped > fonts in PK format. (Eg, DVI drivers for groff, GNU's troff version.) > I've talked about a lot of things, perhaps too much, following on from somebody else's discussion on font naming. I described texfs as both a font and file server. A bitmap and a tfm file must correspond. Generating a font on the fly at some variable point size means also generating the tfm file. As an add-on at no extra cost it also serves style files etc. so that they can be all in one place. > Otherwise comp.text.tex/info-tex might be the more appropriate > forum for this idea. (I don't want to imply that I think it's a bad > idea. IMHO here's simply not the place to discuss it.) Let's drop it then. -- Anthony Shipman "You've got to be taught before it's too late, CP Software Export Pty Ltd, Before you are six or seven or eight, 19 Cato St., East Hawthorn, To hate all the people your relatives hate, Melbourne, Australia, 3121 You've got to be carefully taught." R&H E-mail: als@bohra.cpg.oz.au From NTS-L@DHDURZ1.BITNET Fri Oct 23 11:01:42 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA08242; Fri, 23 Oct 92 11:01:39 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 23 Oct 1992 10:24 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5459; Fri, 23 Oct 92 07:23:54 PDT Date: Fri, 23 Oct 92 15:08:40 BST From: Timothy Murphy Subject: Re: Font Names & texfs In-Reply-To: Anthony Shipman's message of Fri, 23 Oct 92 19:18:51 EST Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <45BDE49604017369@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU > I described texfs as both a font and file server. A bitmap and a tfm > file must correspond. Generating a font on the fly at some variable > point size means also generating the tfm file. As an add-on at no > extra cost it also serves style files etc. so that they can be all in > one place. But one is much less likely to want to generate tfm files on the fly. Remember that the same tfm file corresponds to all magsizes of the font. Of course if you were talking about creating fonts on the fly which had say continuously varying tfm files there would be more to your argument. But are you? > Let's drop it then. You shouldn't be so easily browbeaten! My feeling was that you had not expressed very clearly how your "font manager" was going to fit in with a TeX system consisting of tex and driver(s). Timothy Murphy e-mail: tim@maths.tcd.ie tel: +353-1-2842366 (home/office) +353-1-7021507 (university) fax: +353-1-2842295 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland From NTS-L@DHDURZ1.BITNET Fri Oct 23 12:10:48 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA10758; Fri, 23 Oct 92 12:10:47 MDT Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Fri, 23 Oct 1992 12:00 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 5280; Fri, 23 Oct 92 09:45:49 PDT Date: Sat, 24 Oct 92 01:38:35 EST From: Anthony Shipman Subject: Re: Font Names & texfs In-Reply-To: <199210231426.AA25248@yarra.pyramid.com.au>; from "Timothy Murphy"at Oct 23, 92 3:08 pm Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <53441FEA54003A31@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU X-To: "TeX NTS - new ideas" > > But one is much less likely to want to generate tfm files on the fly. > Remember that the same tfm file corresponds to all magsizes of the font. > Of course if you were talking about creating fonts on the fly > which had say continuously varying tfm files > there would be more to your argument. > But are you? I am. The X11R5 font server model allows for this. To be general shouldn't I assume that the metrics may change with different sizes? TeX's dichotomy betweem different design sizes and different scales seems to confuse things here. I am assuming for generality that different sizes in non-TeX fonts correspond to different design sizes in TeX fonts and therefore the metrics may vary. (Although Postscript fonts are a counter example here with constant .afm files and scaling in the printer). In any case I take the point that these are practical, implementation issues and don't belong here. -- Anthony Shipman "You've got to be taught before it's too late, CP Software Export Pty Ltd, Before you are six or seven or eight, 19 Cato St., East Hawthorn, To hate all the people your relatives hate, Melbourne, Australia, 3121 You've got to be carefully taught." R&H E-mail: als@bohra.cpg.oz.au From NTS-L@DHDURZ1.BITNET Mon Oct 26 01:36:49 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu ([128.110.48.3]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26651; Mon, 26 Oct 92 01:35:16 MST Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 26 Oct 1992 01:32 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 3605; Mon, 26 Oct 92 00:32:34 PST Date: Mon, 26 Oct 92 09:11:00 GMT From: malcolm Subject: kerning and correction Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <570A168542021D73@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU NTS: two minor thoughts on a requirement of a new typesetting system kerning: it has been suggested from time to time in the typographic literature that two at a time kerning is not always appropriate, and that perhaps three (or more) at a time might be more appropriate (in the quest for fine typesetting). it is probably true that when compositors have the ability to adjust manually the inter-letter spacing, they will do it with regard to the cluster of characters, and not to individual pairs. should this be taken into consideration in a new system, committed to quality? David Kindersley suggested a technique which depends on the `optical' centres of characters, and claimed a much improved spacing. the details of his technique are a little awkward to unravel, but they seem to be linked to the fourth or fifth moment of the letter `mass', as some sort of weighting factor. he actually did the work with some sort of optical computer. since Kindersley is essentially a stone mason and calligrapher rather than a type creator, he may be tackling a slightly different problem (but Eric Gill was also a stone mason and engraver, rather than a typographer, and yet created some fine faces). the digital nature of Metafont might lend itself to calculation of the moments of the characters and lead naturally into an examination of this approach. the italic (sic) correction: surely any new system must avoid this. if the system looked ahead to the next but one character, it could automatically perform any necessary adjustment: in other words, an oblique character followed by a space, which itself was followed by a non-oblique character would have an adjustment. the model is probably more general. it might be possible that the space between a non-oblique and an oblique should be tightened slightly. and should (heaven forbid) backwards slanting typefaces enjoy (!) a vogue, some sort of correction or adjustment would also be necessary (therefore betwixt oblique and oblique). or between varying amounts of obliquity. malcolm clark (malcolmc@uk.ac.wmin -- ignore what it says elsewhere i am not a number, i am a free man) From NTS-L@DHDURZ1.BITNET Mon Oct 26 04:13:15 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu ([128.110.48.3]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26996; Mon, 26 Oct 92 04:11:43 MST Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 26 Oct 1992 04:09 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 4579; Mon, 26 Oct 92 03:09:52 PST Date: Mon, 26 Oct 92 06:01:07 -0500 From: Karl Berry Subject: Re: kerning and correction Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <6CF535F822017946@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU I've tried to implement Kindersley's optical spacing algorithm. I've read everything published about it (I think). What's published is not enough to do a good job. I think there are more secrets to be delved into. URW has some program or another which claims to do automatic spacing, but of course they are not publishing anything about how it does it. (Oh, I guess I lie ... I haven't read the British patent application Kindersley applied for, since I can't get it. ) From NTS-L@DHDURZ1.BITNET Mon Oct 26 04:13:57 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu ([128.110.48.3]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA26998; Mon, 26 Oct 92 04:12:26 MST Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 26 Oct 1992 04:10 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 4600; Mon, 26 Oct 92 03:10:35 PST Date: Mon, 26 Oct 92 06:02:00 -0500 From: Karl Berry Subject: Re: kerning and correction Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: NTS-L Distribution list Message-Id: <6D0F0E2E2201F64B@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU The shapes + the side bearings + (if you want to generalize ) space above and below the shape (for vertical typesetting). I don't think much is lost by assuming rectangles. From NTS-L@DHDURZ1.BITNET Mon Oct 26 04:23:06 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu ([128.110.48.3]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27033; Mon, 26 Oct 92 04:21:35 MST Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 26 Oct 1992 04:19 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 4639; Mon, 26 Oct 92 03:19:49 PST Date: Mon, 26 Oct 92 11:20:09 BST From: CHAA006@VAX.RHBNC.AC.UK Subject: Re: kerning and correction Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: RHBNC Philip Taylor Message-Id: <6E58B75692021F5B@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU [Re: Malcolm Clark, Les Carr, Tim Bradshaw] >>> You need rather a lot of parameters to represent a letter form. >>> `Fudge factors' are a way of reducing the dimension of the space you >>> need to work in by abstracting the parameters important to >>> typesetting. There undoubtedly are more parameters one should be >>> using but treating the letter forms themselves doesn't look like a >>> solution to me. Indeed. In going from a rectangular box to a general outline, you are essentially going from 2-space to $n$-space, where $n$ is potentially large. The next step after an erect bounding box is presumably a parallellogram, then a convex polygon, then a concavo-convex polygon. I wonder whether it makes sense to go direct from the simplest representation to the most complex, or whether we might usefully explore the intermediate representations first? Philip Taylor, RHBNC From NTS-L@DHDURZ1.BITNET Mon Oct 26 06:37:07 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu ([128.110.48.3]) by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA27051; Mon, 26 Oct 92 04:32:49 MST Received: from cmsa.Berkeley.EDU (MAILER@UCBCMSA) by CC.UTAH.EDU with PMDF#10043; Mon, 26 Oct 1992 04:31 MST Received: by UCBCMSA (Mailer R2.08 R208004) id 4850; Mon, 26 Oct 92 03:30:57 PST Date: Mon, 26 Oct 92 11:20:09 BST From: CHAA006@VAX.RHBNC.AC.UK Subject: Re: kerning and correction Sender: NTS-L Distribution list To: "Nelson H.F. Beebe" Reply-To: RHBNC Philip Taylor Message-Id: <6FE8E8FBF2022A6B@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU [Re: Malcolm Clark, Les Carr, Tim Bradshaw] >>> You need rather a lot of parameters to represent a letter form. >>> `Fudge factors' are a way of reducing the dimension of the space you >>> need to work in by abstracting the parameters important to >>> typesetting. There undoubtedly are more parameters one should be >>> using but treating the letter forms themselves doesn't look like a >>> solution to me. Indeed. In going from a rectangular box to a general outline, you are essentially going from 2-space to $n$-space, where $n$ is potentially large. The next step after an erect bounding box is presumably a parallellogram, then a convex polygon, then a concavo-convex polygon. I wonder whether it makes sense to go direct from the simplest representation to the most complex, or whether we might usefully explore the intermediate representations first? Philip Taylor, RHBNC From LISTSERV@DHDURZ1.BITNET Mon Oct 26 07:58:17 1992 Flags: 000000000001 Return-Path: Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA00495; Mon, 26 Oct 92 07:58:14 MST Received: from DHDURZ1 (MAILER@DHDURZ1) by CC.UTAH.EDU with PMDF#10043; Mon, 26 Oct 1992 07:57 MST Received: by DHDURZ1 (Mailer R2.08 R208004) id 9007; Mon, 26 Oct 92 15:41:47 CET Date: Mon, 26 Oct 92 15:41:45 CET From: ListEARN List Processor (1.3) Subject: Your removal from the NTS-L list To: "Nelson H.F. Beebe" Cc: Rainer Schoepf , Joachim Lammarsch Message-Id: <8CB7A9B0D2021656@CC.UTAH.EDU> X-Envelope-To: beebe@MATH.UTAH.EDU Dear subscriber, As of Monday, October the 26th of 1992, you have been removed from the NTS-L distribution list (NTS-L Distribution list) by Rainer Schoepf . Virtually, The LISTEARN management From @AWIUNI11.EDVZ.UNIVIE.AC.AT:A8131DAL@AWIUNI11.EDVZ.UNIVIE.AC.AT Thu Mar 18 02:48:10 1993 Flags: 000000000001 Return-Path: <@AWIUNI11.EDVZ.UNIVIE.AC.AT:A8131DAL@AWIUNI11.EDVZ.UNIVIE.AC.AT> Received: from cc.utah.edu by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA01887; Thu, 18 Mar 93 02:48:04 MST Message-Id: <9303180948.AA01887@math.utah.edu> Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT (MAILER@AWIUNI11) by CC.UTAH.EDU with PMDF#10043; Thu, 18 Mar 1993 02:47 MST Received: from AWIUNI11.EDVZ.UNIVIE.AC.AT (NJE origin A8131DAL@AWIUNI11) by AWIUNI11.EDVZ.UNIVIE.AC.AT (LMail V1.1d/1.7f) with BSMTP id 5632; Thu, 18 Mar 1993 10:45:51 +0100 Resent-Date: Thu, 18 Mar 93 10:43:24 MEZ Date: Thu, 18 Mar 93 10:37:21 MEZ Resent-From: Peter Schmitt From: Peter Schmitt Subject: Re: The NTS project: a new start. In-Reply-To: Message of Wed, 17 Mar 93 12:47:55 GMT from Resent-To: "Nelson H.F. Beebe" To: Philip Taylor , NTS-L Distribution list Resent-Message-Id: X-Envelope-To: beebe@MATH.UTAH.EDU I have forwarded your message to GUTENBERG on a TeX system call to the NTS (New Typesetting System) List where just now Philip Taylor has suggested such a call for an extended TeX. I hope you do not mind! Peter (As for the Komoedie bib's: I hope I shall be able to forward them next week.) Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at schmitt@awirap.bitnet ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria ----------------------------Original message---------------------------- On Wed, 17 Mar 93 12:47:55 GMT you said: >TeX has already been started in the guise of a discussion on the NFSS. As >my thoughts were very much to the effect that an immediate goal of the NTS >project should be the development of a totally compatible ``extended-TeX'' (or >e-TeX, for short) with proper support for a \system primitive, I sent the >following to those who were already involved in the discussion about >implementing system calls via \read and \write. Obviously I will be making a >fuller and more developed proposal to members of this list, but I thought that >it was worthwhile circulating the proposal even at this early stage. I would >welcome any comments or feedback. > Philip Taylor, RHBNC >From a recent contribution by Nelson Beebe to quite another list I learned that this has been already discussed, and think that the arguments cited *against* such a \system call are very convincing. I append this message below. ======================================================================== 54 >Date: Wed, 24 Feb 1993 14:05:57 CST >Sender: Project Gutenberg Email List >From: "Nelson H. F. Beebe" >Subject: Short remark on "common ground" document software ----------------------------Original message---------------------------- >> ... >> The receiver of the document created with Common Ground >> doesn't even need to have the program to view it. That's >> because the owner... can elect to install a "mini-viewer." >> This process attaches a tiny amount of additional computer code >> to the document that allows anyone to see and print it. >> ... I see two very big problems with this: (1) computer code means architecture and OS dependence, and (2) viruses. In the TeX community, we have discussed, and rejected, the possibility of a \system call in an extended TeX because it makes it possible to invoke arbitrary commands (that install worms, or trash the file system, or compromise security) just by the apparently innocuous action of typesetting a document. At present, a user can be confident that typing a command "tex foo.tex" or "latex foo.tex" can do nothing to files outside the current directory, and will like only create a limited number of new files, foo.dvi, foo.toc, foo.lof, foo.lot, foo.ind, ... with typesetter output, table of contents, list of figures, list of tables, index, ... Were a \system command available, a clever macro programmer could use TeX's powerful macro language to conceal the equivalent of \system{/bin/rm -rf /} to wipe out an entire UNIX file system if it were executed by a suitable privileged user, YET IN THE FILE, NO SUCH COMMAND WOULD BE VISIBLE. ======================================================================== Nelson H. F. Beebe Tel: +1 801 581 5254 Center for Scientific Computing FAX: +1 801 581 4148 Department of Mathematics, 105 JWB Internet: beebe@math.utah.edu University of Utah Salt Lake City, UT 84112, USA ======================================================================== Peter Schmitt a8131dal@awiuni11.edvz.univie.ac.at schmitt@awirap.bitnet ----------------------------------------------------------------------------- Institute of Mathematics Strudlhofgasse 4 University of Vienna A-1090 Wien Austria