20-Jan-1995 10:25:24-GMT,2878;000000000001 Return-Path: Received: from vs3002.ams.org by math.utah.edu (4.1/SMI-4.1-utah-csc-server) id AA22216; Fri, 20 Jan 95 03:25:18 MST Received: from clio.rz.uni-duesseldorf.de by MATH.AMS.ORG (PMDF #7286 ) id <01HM23FYERKWFYCP8X@MATH.AMS.ORG>; Fri, 20 Jan 1995 05:19:41 EST Received: from localhost by clio.rz.uni-duesseldorf.de (8.6.4.2/11.0) id LAA09759; Fri, 20 Jan 1995 11:17:20 +0100 Date: 20 Jan 1995 10:17:19 +0000 (WET) From: vieth@clio.rz.uni-duesseldorf.de (Ulrik Vieth) Subject: Guru question concerning web2c change files To: tex-implementors@MATH.AMS.ORG Reply-To: vieth@clio.rz.uni-duesseldorf.de (Ulrik Vieth) Message-Id: <199501201017.LAA09759@clio.rz.uni-duesseldorf.de> Organization: Heinrich-Heine-Universitaet Duesseldorf Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: ELM [version 2.4 PL21] Content-Length: 1953 Hi, I'm currently trying to adapt MetaPost so that it can be compiled with web2c-6.1/kpathsea-2.6 using the improved path searching facilities. (Unfortunately, John Hobby's MetaPost distribution now available from CTAN:graphics/metapost/metapost.tar.gz seems to be based on an older version of web2c which doesn't work too well with the latest version of the directory structure.) While examining the WEB change file for MetaPost (mp.ch), I noticed something strange which I didn't quite understand. Therefore, I would like to seek some clarification from the gurus here: As you'll know, there are a number of constants in the first section of {tex,mf,mp}.web that are changed in almost every implementation. Some of these constants are defined as PASCAL constants while some others are defined as WEB macros. Now, I was surprised to find that in the change files {tex,mf,mp}.ch the WEB macro definition of mem_top is simply replaced by a PASCAL constant definition in the preceeding module. Could anyone clarify why this is, and whether this is correct to do so? I seem to remember reading something about some side-effects of improperly changing some of these constants and forgetting to regenerate the {fmt,base,mem} files afterwards, but I cannot remember the details anymore. Thanks in advance for any clarifications, Ulrik Vieth. P.S. Concerning MetaPost: I plan to make my changes available when I am done, so that they can be integrated into the standard web2c eventually. I also plan to contact John Hobby concerning some minor errors in mp.web that cause a parse with weave and some minor errors in mp.ch that mess up the module numbering. Why am I doing this? Well, simply because I really want to try out MetaPost now that is has been put in the public domain and I want to to get it to work together with the rest of my TeX system that uses the new directory structure. Someone has do it, so why not give it a try. 14-Feb-1995 21:38:33-GMT,1921;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id OAA25984 for ; Tue, 14 Feb 1995 14:38:30 -0700 Received: from MATH.AMS.ORG by MATH.AMS.ORG (PMDF #7286 ) id <01HN1HLNN81C91VZIX@MATH.AMS.ORG>; Tue, 14 Feb 1995 15:53:55 EST Date: 14 Feb 1995 15:53:45 -0500 (EST) From: bbeeton Subject: Re: Proposed Re-Encoding Standard In-reply-to: <199502142017.PAA13842@ios.com> To: kinch@ios.com Cc: tex-implementors@VAX02.AMS.ORG, rhunter@tcisoft.com, malyshev@dxcern.cern.ch Message-id: <792795225.799919.BNB@MATH.AMS.ORG> Content-transfer-encoding: 7BIT Mail-System-Version: i'd like to make several small comments about richard kinch's invitation for a proposed re-encoding standard. 1. it sounds like a good idea, and i wish the effort success. 2. the tex-implementors list is not a listserv list; it is maintained by me, by hand (we don't have any listserv software or prospects for same at ams). i would also like to note that, except for roger hunter and basil malyshev, all explicit addressees on this message are already on the the tex-implementors list, though not necessarily with the same addresses. if roger and basil will confirm their addresses, i'll be pleased to add them to the list. 3. regarding "long" font names such lcircle10, there is an existing convention to take the first n + last n characters of the name, dropping out the middle, to minimize ambiguity. on a 6-character machine (e.g. sail -- the ur-home of tex), this would yield lcie10 (obscure, perhaps, but probably not a duplicate of anything else); an 8-character machine would get lcirle10. i think i have a statement about this in my archives, and can look it up if there is interest. -- bb 14-Feb-1995 22:59:15-GMT,5483;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id PAA27034 for ; Tue, 14 Feb 1995 15:59:10 -0700 Received: from june.cs.washington.edu by MATH.AMS.ORG (PMDF #7286 ) id <01HN1QQDUK9C91W00H@MATH.AMS.ORG>; Tue, 14 Feb 1995 17:43:54 EST Received: (mackay@localhost) by june.cs.washington.edu (8.6.9/7.2ju) id OAA09624; Tue, 14 Feb 1995 14:43:31 -0800 Date: 14 Feb 1995 14:43:31 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Subject: Re: Proposed Re-Encoding Standard In-reply-to: bbeeton's message of 14 Feb 1995 15:53:45 -0500 (EST) <792795225.799919.BNB@MATH.AMS.ORG> To: BNB@VAX02.AMS.ORG, kinch@ios.com Cc: kinch@ios.com, tex-implementors@VAX02.AMS.ORG, rhunter@tcisoft.com, malyshev@dxcern.cern.ch Message-id: <199502142243.OAA09624@june.cs.washington.edu> Content-transfer-encoding: 7BIT A combined reaction to both Richard Kinch's proposal and Barbara's response. Yes, it is probably a good idea. In fact, such a coding has been bandied about in another forum over the past 8 months. The general conclusion has been that since Type1 encoding vectors are quite adaptable, and TrueType encoding arrays seem to be strait-jacketed in wierd ways, the only thing is to cobble up a Type1 imitation of whatever TrueType demands. In principle, this is an appalling notion, but it may be inevitable. Why, when Adobe led the way to the use of intelligible character names in the encoding vector, are we going back to baffling and error-prone arrays of Hex code? It is bad enough that the lesson which should have been learned from Knuth's font encoding and from Type1 font encoding---that an output-only array of glyphs should not be subject to the constraints of an information-interchange encoding---has to be disregarded, but to make the effort of conforming to a limited and possibly defective coding as incomprehensible as possible seems simply perverse. I may be ultimately persuaded into the adoption of an encoding array such as Bertold Horn suggested in that other forum (which may be the same as this one) for the "what-we-used-to-call-raw-font" encoding of an array of glyphs. At least I would think about if it were ever stable enough to take the place of Adobe Standard Encoding which is stable, well documented and easily readable. But I suspect that very few people with the resources of PostScript available will be content to be handcuffed to TrueType coding when there are perfectly good mechanisms for translation. I suppose you don't absolutely HAVE to know what 0xaf really looks like if you are willing to accept it on blind faith, but you still can't make up a readable encoding vector if you have no access to the character names. Wouldn't it be possible at least to use enum to assign names? I realize that Adobe's clean use of A for A would not work, but something like UC_A might, and it would at least be readable. As for the automatic shortening of names, it can only be done if the original namer is thinking carefully about the effect. If I only had my old TOPS-20 tapes still available I could still dig out the procedure that shrank cmdunh10 to cmdh10 and cmssi10 to cmsi10. (I think cmmi* was reduced to cmi*, but I can't think why.) This was unnecessary on TOPS-20, but was kept for compatibility. Knuth named his fonts rather carefully to make that possible. and to provide for shortened names that made reasonable sense. He also made the sensible assumption that the longer and more informative name would ultimately prevail, even though it was his own environment that required the restriction to 6 characters. There is a lesson there. lcircle10, (originally circle10) was not named with that specific concern in mind. CIRCLEW10 even without the L, would never have worked in an 8-character straitjacket anyway. Since lcircle10 was not specifically designed as a shrinkable name, and since there are very few instances where the problem arises, I would suggest a more intuitive shortening lcircle10 -> lcirc10 lcirclew10 -> lcircw10 These two have the advantage of appearing already in Karl Berry's texfonts.map If in future it is necessary to produce short names automatically by dropping the center out of 9, 10 and 11 character names, the people who name such fonts will do well to consider how best to avoid ambiguity in the shortened name As for making cmr10 equivalent to Cmr10, cmR10 and CMR10, Karl Berry's texfonts.map can manage that too, and does so in the most satisfactory way, by reference to an external, editable 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. | | I will continue unofficially to provide tape distributions and | | any 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) 15-Feb-1995 6:22:19-GMT,1965;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id XAA00742 for ; Tue, 14 Feb 1995 23:22:11 -0700 Received: from netcomsv.netcom.com (uucp7.netcom.com) by MATH.AMS.ORG (PMDF #7286 ) id <01HN25RYOWE891W2D1@MATH.AMS.ORG>; Wed, 15 Feb 1995 00:55:03 EST Received: from clement.UUCP by netcomsv.netcom.com with UUCP (8.6.9/SMI-4.1) id VAA19013; Tue, 14 Feb 1995 21:40:18 -0800 Received: by quixote.com (UUPC/extended 1.12b); Tue, 14 Feb 1995 13:18:35 PST Date: 14 Feb 1995 21:18:34 -0800 From: Don Hosek Subject: Re: Proposed Re-Encoding Standard In-reply-to: from "Richard J. Kinch" at Feb 14 95 3:17 pm To: ios.com!kinch@netcom.com (Richard J. Kinch) Cc: tex-implementors@MATH.AMS.ORG, rhunter@tcisoft.com, malyshev@dxcern.cern.ch Message-id: <2f411e2b.clement@quixote.com> Content-transfer-encoding: 7BIT X-Mailer: ELM [version 2.3 PL11] for OS/2 A thought which Berthold will doubtless find reprehensible but such is life: Rather than worry about a standard code mapping to be handled by all software, why not specify an encoding vector which handles all characters required and a standard skeleton VF for mapping that to the character codes TeX needs. The encoding could then be appled as a standard to all native PS fonts as well, although there is the difficulty of really bad support for character code mapping under Windows and OS/2 (yet another reason I'm saving up for a Mac). -dh -- Don Hosek "What frightens me is when people substitute fear for reason." Quixote Digital Typography -The Day the Earth Stood Still Publishers of _Serif: The Magazine of Type and Typography_ 909-621-1291 Current reading: _Hosea_ (Andersen, FAX: 909-625-1342 Freedman, eds.), _Antologia de dhosek@quixote.com Cuentos Mexicanos II_ (Millau, ed.) 15-Feb-1995 6:22:21-GMT,3475;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id XAA00748 for ; Tue, 14 Feb 1995 23:22:18 -0700 Received: from netcomsv.netcom.com (uucp7.netcom.com) by MATH.AMS.ORG (PMDF #7286 ) id <01HN25V8MOLC91W4QL@MATH.AMS.ORG>; Wed, 15 Feb 1995 00:57:53 EST Received: from clement.UUCP by netcomsv.netcom.com with UUCP (8.6.9/SMI-4.1) id VAA19008; Tue, 14 Feb 1995 21:40:13 -0800 Received: by quixote.com (UUPC/extended 1.12b); Tue, 14 Feb 1995 13:13:21 PST Date: 14 Feb 1995 21:13:20 -0800 From: Don Hosek Subject: Re: Proposed Re-Encoding Standard In-reply-to: from "bbeeton" at Feb 14 95 3:53 pm To: MATH.AMS.ORG!BNB@netcom.com (bbeeton) Cc: tex-implementors@MATH.AMS.ORG, rhunter@tcisoft.com, malyshev@dxcern.cern.ch, kinch@ios.com Message-id: <2f411cf2.clement@quixote.com> Content-transfer-encoding: 7BIT X-Mailer: ELM [version 2.3 PL11] for OS/2 > 3. regarding "long" font names such lcircle10, there is an > existing convention to take the first n + last n characters > of the name, dropping out the middle, to minimize ambiguity. > on a 6-character machine (e.g. sail -- the ur-home of tex), > this would yield lcie10 (obscure, perhaps, but probably not > a duplicate of anything else); an 8-character machine would > get lcirle10. i think i have a statement about this in my > archives, and can look it up if there is interest. Convention implies that something is conventional, e.g., generally used. the drop-the-middle "convention" is not. In fact, as far as I know only the Sail system implemented this. I know of no TeX system which used first 4 plus last 4 under 8+3 naming. Instead, the better implementations all drop everything after 8 (and after 3 as appropriate) and the not-so-good implementations simply fail to find any file which is requested with a long name. While VM TeX was maintained out of WSU, it used the first 8 convention as well. Perhaps the Germans have changed this, but I don't think so. While the 4/4 mapping to 8 character filenames is attractive, it's also impractical for real world use. Even if we do change all the TeX software to use 4/4 instead of first 8, it won't change the fact that all the automated and semi-automated means for bringing files onto these systems will simply truncate at 8 characters. Back in 88 when I was first discussing this with Tom Reid for implementation under CMS and MVS, we decided not to worry about it for just this reason. After all, when we brought the file over from score.stanford.edu (back when there was such a machine) lcircle10.mf became lcircle1.mf. If we made the change manually to lcirle10.mf and somebody got the file from us and tried to install it under, say, Unix, they'd find that their requests for lcircle10 were left unanswered and since normally they were seeing file names truncated, they would not necessarily make the connection between lcirle10 and lcircle10. -dh -- Don Hosek "What frightens me is when people substitute fear for reason." Quixote Digital Typography -The Day the Earth Stood Still Publishers of _Serif: The Magazine of Type and Typography_ 909-621-1291 Current reading: _Hosea_ (Andersen, FAX: 909-625-1342 Freedman, eds.), _Antologia de dhosek@quixote.com Cuentos Mexicanos II_ (Millau, ed.) 15-Feb-1995 10:03:10-GMT,1488;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id DAA02313 for ; Wed, 15 Feb 1995 03:03:06 -0700 Received: from swan.cl.cam.ac.uk by MATH.AMS.ORG (PMDF #7286 ) id <01HN2DEAL2R491W9GV@MATH.AMS.ORG>; Wed, 15 Feb 1995 04:33:06 EST Received: from ouse.cl.cam.ac.uk (user spqr100 (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Wed, 15 Feb 1995 09:29:56 +0000 Date: 15 Feb 1995 09:29:52 +0000 From: Sebastian Rahtz Subject: Re: Proposed Re-Encoding Standard In-reply-to: Your message of "14 Feb 1995 21:18:34 PST." <2f411e2b.clement@quixote.com> To: Don Hosek Cc: ios.com!kinch@netcom.com (Richard J. Kinch), tex-implementors@MATH.AMS.ORG, rhunter@tcisoft.com, malyshev@dxcern.cern.ch Message-id: <"swan.cl.cam.:098190:950215093055"@cl.cam.ac.uk> Content-transfer-encoding: 7BIT > Rather than worry about a standard code mapping to be handled by all > software, why not specify an encoding vector which handles all > characters required and a standard skeleton VF for mapping that to the > character codes TeX needs. > there are just two flaws in this a) "all the characters requiored" is a giant set , certainly greater than 256. b) "codes TeX needs" are what? it depends on the macro package. certainly dont lets keep up the pretence that what Knuth did in plain, and Lamport copied in latex, is suitable or sufficient. sebastian 15-Feb-1995 13:52:58-GMT,2776;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id GAA03254 for ; Wed, 15 Feb 1995 06:52:51 -0700 Received: from netcomsv.netcom.com (uucp7.netcom.com) by MATH.AMS.ORG (PMDF #7286 ) id <01HN2M2U1L8091W4ON@MATH.AMS.ORG>; Wed, 15 Feb 1995 08:41:15 EST Received: from clement.UUCP by netcomsv.netcom.com with UUCP (8.6.9/SMI-4.1) id FAA01580; Wed, 15 Feb 1995 05:25:05 -0800 Received: by quixote.com (UUPC/extended 1.12b); Wed, 15 Feb 1995 04:40:31 PST Date: 15 Feb 1995 12:40:30 -0800 From: Don Hosek Subject: Re: Proposed Re-Encoding Standard In-reply-to: from "Sebastian Rahtz" at Feb 15 95 9:29 am To: cl.cam.ac.uk!Sebastian.Rahtz@netcom.com (Sebastian Rahtz) Cc: kinch@ios.com, tex-implementors@MATH.AMS.ORG, rhunter@tcisoft.com, malyshev@dxcern.cern.ch Message-id: <2f41f63f.clement@quixote.com> Content-transfer-encoding: 7BIT X-Mailer: ELM [version 2.3 PL11] for OS/2 > > Rather than worry about a standard code mapping to be handled by all > > software, why not specify an encoding vector which handles all > > characters required and a standard skeleton VF for mapping that to the > > character codes TeX needs. > there are just two flaws in this > a) "all the characters requiored" is a giant set , certainly greater > than 256. > b) "codes TeX needs" are what? it depends on the macro > package. certainly dont lets keep up the pretence that what Knuth did > in plain, and Lamport copied in latex, is suitable or sufficient. So it's a suite of encoding vectors. Big deal. If I understand the TT limitations, you'll need two TT fonts to provide the equivalent functionality of the EC encoding anyway (not that EC is anything other than a naive attempt at a solution in the first place). A well-planned system would allow a master set of TT/T1/PK/who-cares fonts and a set of VFs which would emulate cmr or dcr or whatever cm variant is desired. It IS a big problem to solve, but it's better to solve it right from the first than to end up with something as pointless as the EC encoding. Let's please set our sights a bit higher than Computer Modern and realize that not all typefaces have 5 ligatures and no real typefaces have that pointless extra 0 to change percent to permill. -dh -- Don Hosek "What frightens me is when people substitute fear for reason." Quixote Digital Typography -The Day the Earth Stood Still Publishers of _Serif: The Magazine of Type and Typography_ 909-621-1291 Current reading: _Hosea_ (Andersen, FAX: 909-625-1342 Freedman, eds.), _Antologia de dhosek@quixote.com Cuentos Mexicanos II_ (Millau, ed.) 15-Feb-1995 18:08:12-GMT,4089;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id LAA06069 for ; Wed, 15 Feb 1995 11:08:08 -0700 Received: from life.ai.mit.edu by MATH.AMS.ORG (PMDF #7286 ) id <01HN2U836P6891W1H9@MATH.AMS.ORG>; Wed, 15 Feb 1995 12:34:24 EST Received: from kauai (kauai.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) for tex-implementors@vax02.ams.org id AA25874; Wed, 15 Feb 95 12:34:09 EST Received: by kauai (4.1/AI-4.10) id AA09810; Wed, 15 Feb 95 12:34:08 EST Date: 15 Feb 1995 12:34:08 -0500 (EST) From: bkph@ai.mit.edu (Berthold K.P. Horn) Subject: [MAILER-DAEMON@ai.mit.edu: Returned mail: Host unknown] To: tex-implementors@VAX02.AMS.ORG Message-id: <9502151734.AA09810@kauai> Content-transfer-encoding: 7BIT ----- Unsent message follows ----- Return-Path: Received: from kauai (kauai.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) for kinch@netcom.com id AA23111; Wed, 15 Feb 95 11:51:46 EST From: bkph@ai.mit.edu (Berthold K.P. Horn) Received: by kauai (4.1/AI-4.10) id AA09792; Wed, 15 Feb 95 11:51:44 EST Date: Wed, 15 Feb 95 11:51:44 EST Message-Id: <9502151651.AA09792@kauai> To: tex-implementors@ams.org, bkph@ai.mit.edu, malyshev@dxcern.cern.ch, pti@crl.com, rhunter@tcisoft.com, barry@bluesky.com, kinch@ios.com, kinch@netcom.com In-Reply-To: "Richard J. Kinch"'s message of Tue, 14 Feb 1995 15:17:17 -0500 (EST) <199502142017.PAA13842@ios.com> Subject: Proposed Re-Encoding Standard I welcome any attempt to get some standardization in areas where TeX related issues seriously need standardization, such as: (1) Font Naming issues (2) Font Encoding issues (3) \special syntax for figure inclusions (4) Color, Hypertext, device independent graphics, ... Past attempts have produced partial results that were not always widely adopted. And some of the attempts just ran out of steam. Others were too tied to a particular piece of software and hence not adopted. I would recommend one thing though. We are discussion several quite separate issues, so it may be helpful to send separate messages on separate topics in order to make it easier to sort through all this.. In that spirit I will here address only one: shortening of names. (1) I am violently opposed to any revisionism regarding existing names. It took many years before we recovered form the circle10 => lcircle10 (or lcircle1 ?) etc fiasco. Lets not change these names again, please! There is no purpose served and many users get confused. And someone has to waste bandwidth and energy explaining it. (Similarly AM* => CM* was a pain, but justified, and MSXM*, MSYM* => MSAM*, MSBM* was a pain, but unavoidable because the metrics differed). (2) I don't see what the problem is actually. Part of it seems to be the notion that a font has *a* name. There are always several names. For example, (i) the files associated with a font have a name, (ii) the font may have a PostScript FontName if it is a T1 font, and (iii) an operating system may show a name in a Font Menu. File name, PS FontName and Font Menu names are not usually the same. Even if the PS FontName is 32 characters long, we need not worry because that is not the name we refer to it in TeX. Same for the Font Menu name, which on some operating systems can reach 32 characters (3) When you make a font, you can pick what the files will be called. Simply make sure the name is 8 characters or less. Then there is no need to play games with name contraction. And existing software will work without modification. (4) If we *did* have to contract names, then I propose that instead of some 4+4 rule, we use the 5+3+3+... rule of the Macintosh. It is well established and easy to implement. It is used to derive font file names based on the PS FontName (which may be very long). (In case its not obvious, this is a kind of joke :=) Its in my opinion however an option no less desirable than 4+4 name shortening. Regards, Berthold. 15-Feb-1995 18:13:06-GMT,6529;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id LAA06139 for ; Wed, 15 Feb 1995 11:12:50 -0700 Received: from life.ai.mit.edu by MATH.AMS.ORG (PMDF #7286 ) id <01HN2U7AACFK91W4MZ@MATH.AMS.ORG>; Wed, 15 Feb 1995 12:33:45 EST Received: from kauai (kauai.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) for tex-implementors@vax02.ams.org id AA25843; Wed, 15 Feb 95 12:33:32 EST Received: by kauai (4.1/AI-4.10) id AA09807; Wed, 15 Feb 95 12:33:30 EST Date: 15 Feb 1995 12:33:30 -0500 (EST) From: bkph@ai.mit.edu (Berthold K.P. Horn) Subject: [MAILER-DAEMON@ai.mit.edu: Returned mail: Host unknown] To: tex-implementors@VAX02.AMS.ORG Message-id: <9502151733.AA09807@kauai> Content-transfer-encoding: 7BIT Return-Path: Date: Wed, 15 Feb 95 12:28:53 EST From: MAILER-DAEMON@ai.mit.edu (Mail Delivery Subsystem) Subject: Returned mail: Host unknown To: ----- Unsent message follows ----- Return-Path: Received: from kauai (kauai.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) for kinch@netcom.com id AA25565; Wed, 15 Feb 95 12:28:53 EST From: bkph@ai.mit.edu (Berthold K.P. Horn) Received: by kauai (4.1/AI-4.10) id AA09799; Wed, 15 Feb 95 12:28:47 EST Date: Wed, 15 Feb 95 12:28:47 EST Message-Id: <9502151728.AA09799@kauai> To: tex-implementors@ams.org, bkph@ai.mit.edu, malyshev@dxcern.cern.ch, pti@crl.com, rhunter@tcisoft.com, barry@bluesky.com, kinch@ios.com, kinch@netcom.com Subject: font encoding On the issue of font encoding, I would like to make a few points: (1) Plain vanilla text fonts in Adobe Type 1 format have a `standard' complement of 228 glyphs. It would be a pity not to include all of these at least in any encoding. And definitely include the `standard' 58 accented / composite glyphs. In addition, we would probably want to include a few that occur in some, but not all, fonts yet are much loved, such as ff, ffi, ffl. (2) It is possible to lay out an encoding in such a way that much of it matches what plain TeX and LaTeX expect. Although it is hard to do this without departing too far from more sane layouts like ASCII, ANSI, ISO Latin 1 etc. (3) CM fonts use several (at least 4) different encodings for text fonts. This was forced in part by limitations of 7 bit code. Lets *NOT* do that! It is a nightmare to try and deal with different encodings for different text fonts (DVIPSONE implements this --- and it is not *a good thing* - sorry I ever put that in) (4) I don't actually care a whole lot about what encoding is used, since the Y&Y TeX System supports completely arbitrary font layout (*not* limited by platform specific encodings such as Mac roman encoding or Windows ANSI). However, many users ask what we *recommend*, and then it is nice to have something to pull out of a hat. For this purpose I have made up `texnansi.vec' which (i) includes the `standard' 228 glyphs, (ii) includes ff, ffi, ffl, dotlessj (iii) Matches the `TeX typewriter' layout to a large extend, (iv) matches Windows ANSI in the upper regions (and hence matches a large part of ISO Latin 1). Naturally it is somewhat ad hoc, and it of course leaves out many of the hundreds of composite characters used in other parts of the world, but it does include all 58 `standard' accented/compoiste glyphs (unlike Mac or Windows ANSI which miss some) all the Icelandic glyphs, Polish Lslash etc etc. (5) By the way, this has nothing to do with virtual fonts --- unless you are forced to use AFM2TFM, which has been purposefully crippled not to make TFM files complete with ligatures and kerning *unless* you use VF. In this context, VF itself can only *permute* encoding, since it, like the rest of TeX deals only in character code *numbers*, nit *glyph names*. It cannot make unencoded glyphs accessible, which is what real reencoding is about. (6) I have an idea it will be impossible to get a generally agreed upon scheme. So the way to cope is probably to have some TeX macro header file that one loads up that is tuned to a particular encoding. Much like now we load up different macros to interface graphics with particular drivers. What I have in mind is something like the present \input stanacce (for Adobe StandardEncoding), \input ansiacce (for Windows ANSI), \input macacce (for Mac standard roman) etc. When you get a document from someone on another platform, you change the \input statement appropriate for the set up on your machine ************************************************************************ An aside: at the risk of starting a flame war, I'd like to make a couple of observations here: One is that Cork encoding lacks about 38 glyphs that are in most text fonts, including dagger, daggerdbl, section, and paragraph which are needed for footnotes in LaTeX (and which are not in all math symbol fonts). At the same time Cork includes a large number of composites for Eastern Europe that are not found in most fonts. Yes, I know you can construct them using VF or using the Font Manipulation Package, but why should *everyone* give up a lot of slots for something they do not use at all, and so loose access to a lot of things they could use instead? Another is that LaTeX 2e's main claim to fame is better handling of non-CM fonts. I know that people have worked *very* hard on this and have definitely been quite clever in how it was done. But just talking from a practical day-to-day kind of point of view: it has been a tech support nightmare. The TeX system vendors had to do a *lot* of educating, and deal with a lot of confusion and complaints. And the huge number of little auxiliary files is a handicap. I find a lot of people run the basic code, then trow away most of the resulting files and use other means to deal with encoding issues for example. In part this is the result of a somewhat dogmatic approach in LaTeX 2e: though shalt use Cork encoding and though shalt use Karl Berry names. I understand the desire to standardize, but in a lot of cases it can actually get too much in the way of getting things done. Some claim there is no bias or dogma, but then how come encodings other than OT1 and T1 are grouped under U which it says is short for `rubbish'? All the encodings I ever use fall in that category! Regards, Berthold. 15-Feb-1995 18:57:44-GMT,3393;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id LAA06787 for ; Wed, 15 Feb 1995 11:57:37 -0700 Received: from life.ai.mit.edu by MATH.AMS.ORG (PMDF #7286 ) id <01HN2WSZYP7K91W3W4@MATH.AMS.ORG>; Wed, 15 Feb 1995 13:48:43 EST Received: from kauai (kauai.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) for tex-implementors@vax02.ams.org id AA01226; Wed, 15 Feb 95 13:48:13 EST Received: by kauai (4.1/AI-4.10) id AA09830; Wed, 15 Feb 95 13:48:12 EST Date: 15 Feb 1995 13:48:12 -0500 (EST) From: bkph@ai.mit.edu (Berthold K.P. Horn) Subject: font encoding In-reply-to: Berthold K.P. Horn's message of Wed, 15 Feb 95 12:28:47 EST <9502151728.AA09799@kauai> To: tex-implementors@VAX02.AMS.ORG, bkph@ai.mit.edu, malyshev@dxcern.cern.ch, pti@crl.com, rhunter@tcisoft.com, barry@bluesky.com, kinch@netcom.com Message-id: <9502151848.AA09830@kauai> Content-transfer-encoding: 7BIT > From Don Hosek: > The encoding could then be applied as a standard to all PS fonts > as well, although there is the difficulty of really bad support > for character code mapping under Windows and OS/2 (yet another > reason I'm saving up for a Mac) ********************************************************************** * * * Buy a Pentium instead! You have the polarity wrong! * * * ********************************************************************** Yes, indeed, both Mac and IBM PC / Windows are set up to reencode plain text fonts to platform specific encoding vectors (Mac standard roman and Windows ANSI respectively) as default. And these lack some important glyphs (Windows ANSI is missing 15, while the Mac lacks 21 of the `standard' 228 found in most text fonts). However, you don't have to live with that. For example, in the old version 1.1 of the Y&Y TeX System you can run a batch file called `encode.bat' that reencodes the fonts you want to any encoding you specify! * And this works both for on screen display *and* printing. * And it works for both PS *and* non PS printer. The encoding you choose is *not* restricted to just permuting the platform specific encoding vector. It can make unencoded glyphs accessible. Which is the whole idea of true reencoding... It is even easier in Y&Y TeX System 1.2, where reencoding is `on the fly' you don't need to run a batch file first. Just specify an environment variable that tells it what encoding vector to use (the vector itself is written out in a plain ASCII file). You can't do that on the Mac, since you are restricted by the `screen fonts' You can reencode fonts arbitrarily if they go to a PS printer, of course, but on screen display and non-PS printers won't work because there are no bitmaps in the screen font for glyphs that are not in Mac standard encoding. What is easy to do both on the Mac and in Windows is to permute the platform specific encoding, but that is pretty limited in utility... Sorry to sound like an ad, but signs of unwarranted apparent platform bias always gets me into this mode :=). Regards, Berthold. P.S. Check out `What's New' on Y&Y's web pages for more info http://www.yandy.com DISCLAIMER: Respondent has connections with Y&Y :=) Just in case... 15-Feb-1995 20:26:43-GMT,5853;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id NAA08288 for ; Wed, 15 Feb 1995 13:26:33 -0700 Received: from june.cs.washington.edu by MATH.AMS.ORG (PMDF #7286 ) id <01HN2YEF9NB491W3GW@MATH.AMS.ORG>; Wed, 15 Feb 1995 14:34:02 EST Received: (mackay@localhost) by june.cs.washington.edu (8.6.9/7.2ju) id LAA05657; Wed, 15 Feb 1995 11:33:48 -0800 Date: 15 Feb 1995 11:33:48 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Subject: Coding questions In-reply-to: Berthold K.P. Horn's message of 15 Feb 1995 12:33:30 -0500 (EST) <9502151733.AA09807@kauai> To: bkph@ai.mit.edu Cc: tex-implementors@VAX02.AMS.ORG Message-id: <199502151933.LAA05657@june.cs.washington.edu> Content-transfer-encoding: 7BIT I tend to agree with most of what Bertold says until I get to this point > (5) By the way, this has nothing to do with virtual fonts --- unless you are > forced to use AFM2TFM, which has been purposefully crippled not to make > TFM files complete with ligatures and kerning *unless* you use VF. > In this context, VF itself can only *permute* encoding, since it, like > the rest of TeX deals only in character code *numbers*, nit *glyph names*. > It cannot make unencoded glyphs accessible, which is what real > reencoding is about. This is simply bizarre. Afm2tfm makes 2 tfms if you tell it to, and and you can impose whatever coding you want on either of them. It is a bit unfortunate that TFM format did not anticipate the character name strings that Adobe enshrines, but it didn't. It is a serviceable format even so, but it would have been a shade more serviceable with the human-readable names. You can set up a tfm to point you directly at all the characters in (e.g.) Adobe Expert encoding if you want to and that gives you all sorts of accent composites. Or rather it does if the expert font has been put together responsibly. There are many foundries which use the basic set of Adobe Standard Encoding names for everything no matter what the actual glyph content of the font is. In those cases, one might just as well use numerical indices. Because TFM does not use names, it cannot be used as a vehicle to go rooting around in the unencoded section of a Type1 font. The encoding has to be supplied first. This has nothing to do with the way AFM2TFM was designed, it is simply impossible to use a fixed numerically indexed array to find glyphs which are not in fixed positions in that array. AFM2TFM provides a pretty good way around that limitation. "Raw" tfms are occasionally a redundancy, but they can also work very satisfactorily. For example: the original Knuth tfms can be used "raw" in association with a "cooked" set which supplies accented composites in any desired encoding, in very much the same way as the unencoded composites are provided in 90% or more of Type1 text fonts. It might have been better to set up most of the composites in Cork encoded fonts this way, and thus aviod the proliferation of dialect forms of the Computer Modern character repertory. And what produces the "cooked" TFM with all its composites? AFM2TFM. (Or fontinst, if you prefer that.) That said I can get back to general agreement with Bertold's last point. Universal encoding schemes to cover everything are not going to work, and certainly not in a 256 cell array with some of the cells made useless by Windows caltrops and land mines. Even Unicode doesn't manage it, but at least it holds some spaces open for private encoding. And would anyone care to take a bet on when wide-character text-processing will become generally available? There is certainly no harm in agreeing on a not-quite-256 character basic encoding for TeX-based applications on defective platforms. It clearly won't be either Knuth encoding or [D,E]C.encoding, because of the arbitrary holes that have to be left in it. That being the case, I would still rather use something as close as possible to Adobe Standard Encoding, but apparently Windows applications are so inflexible that it can't be done. Whatever encoding is adopted will have to be dumbed down to the lowest level of functionality. My impression is that Bertold has studied this problem more thoroughly than anyone else, and his solution deserves very careful scrutiny. For my own part, if I ever become convinced that such a dumbed down coding convention has any hope of being stable, I may be willing to use it in place of ASEX, but I will still go on using AFM2TFM to impose that encoding on my type1 fonts and to provide a more rational "cooked" encoding for my input. And PLEASE, if this encoding is to be imposed on Type1 text fonts let us be sure that none of the simplex characters in Adobe Standard Encoding, (encoded or unencoded) is left out. For most fonts the accented composites matter a lot less, though if you want them, there is no harm in having them. %=======================================================================% | 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. | | I will continue unofficially to provide tape distributions and | | any 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) 15-Feb-1995 20:29:01-GMT,5002;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id NAA08316 for ; Wed, 15 Feb 1995 13:28:55 -0700 Received: from life.ai.mit.edu by MATH.AMS.ORG (PMDF #7286 ) id <01HN2XUU2WA891WA4S@MATH.AMS.ORG>; Wed, 15 Feb 1995 14:19:08 EST Received: from kauai (kauai.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) for tex-implementors@vax02.ams.org id AA03510; Wed, 15 Feb 95 14:18:44 EST Received: by kauai (4.1/AI-4.10) id AA09843; Wed, 15 Feb 95 14:18:43 EST Date: 15 Feb 1995 14:18:43 -0500 (EST) From: bkph@ai.mit.edu (Berthold K.P. Horn) Subject: font encoding In-reply-to: Berthold K.P. Horn's message of Wed, 15 Feb 95 12:28:47 EST <9502151728.AA09799@kauai> To: tex-implementors@VAX02.AMS.ORG, bkph@ai.mit.edu, malyshev@dxcern.cern.ch, pti@crl.com, rhunter@tcisoft.com, barry@bluesky.com, kinch@netcom.com Message-id: <9502151918.AA09843@kauai> Content-transfer-encoding: 7BIT > From Richard Kinch : > ============================================================================ > 1. Re-encoding table proper. > ============================================================================ > As regards TTF, here is what we have been calling the ``ad hoc'' re-encoding > in TrueTeX: > The following table gives the mapping of DVI character codes (that is, the TeX > font encoding) to TrueType font codes: > {\tt\begin{tabular}{|r|r|r|r|r|r|r|r|r|} > \multicolumn{9}{c}{\bf \TeX\ DVI to \TeX\ TrueType Font Re-Encoding Map} \\ > \hline > {\it 0x00\/} & 0xa1 & 0xa2 & 0xa3 & 0xa4 & 0xa5 & 0xa6 & 0xa7 & 0xa8 \\ > {\it 0x08\/} & 0xa9 & 0xaa & 0xad & 0xae & 0xaf & 0xb0 & 0xb1 & 0xb2 \\ > {\it 0x10\/} & 0xb3 & 0xb4 & 0xb5 & 0xb6 & 0xb7 & 0xb8 & 0xb9 & 0xba \\ > {\it 0x18\/} & 0xbb & 0xbc & 0xbd & 0xbe & 0xbf & 0xc0 & 0xc1 & 0xc2 \\ > {\it 0x20\/} & 0xc3 & 0x21 & 0x22 & 0x23 & 0x24 & 0x25 & 0x26 & 0x27 \\ > {\it 0x28\/} & 0x28 & 0x29 & 0x2a & 0x2b & 0x2c & 0x2d & 0x2e & 0x2f \\ > {\it 0x30\/} & 0x30 & 0x31 & 0x32 & 0x33 & 0x34 & 0x35 & 0x36 & 0x37 \\ > {\it 0x38\/} & 0x38 & 0x39 & 0x3a & 0x3b & 0x3c & 0x3d & 0x3e & 0x3f \\ > {\it 0x40\/} & 0x40 & 0x41 & 0x42 & 0x43 & 0x44 & 0x45 & 0x46 & 0x47 \\ > {\it 0x48\/} & 0x48 & 0x49 & 0x4a & 0x4b & 0x4c & 0x4d & 0x4e & 0x4f \\ > {\it 0x50\/} & 0x50 & 0x51 & 0x52 & 0x53 & 0x54 & 0x55 & 0x56 & 0x57 \\ > {\it 0x58\/} & 0x58 & 0x59 & 0x5a & 0x5b & 0x5c & 0x5d & 0x5e & 0x5f \\ > {\it 0x60\/} & 0x60 & 0x61 & 0x62 & 0x63 & 0x64 & 0x65 & 0x66 & 0x67 \\ > {\it 0x68\/} & 0x68 & 0x69 & 0x6a & 0x6b & 0x6c & 0x6d & 0x6e & 0x6f \\ > {\it 0x70\/} & 0x70 & 0x71 & 0x72 & 0x73 & 0x74 & 0x75 & 0x76 & 0x77 \\ > {\it 0x78\/} & 0x78 & 0x79 & 0x7a & 0x7b & 0x7c & 0x7d & 0x7e & 0xc4 \\ > {\it 0x80\/} & 0x0 & 0x0 & 0x0 & 0x0 & 0x0 & 0x0 & 0x0 & 0x0 \\ > $\ldots$ \\ > {\it 0xF8\/} & 0x0 & 0x0 & 0x0 & 0x0 & 0x0 & 0x0 & 0x0 & 0x0 \\ > \hline > \end{tabular}} > In other words, a Windows program maps the code 0x18 in a DVI file to > TrueType glyph code 0xbb when calling, say, the Windows API TextOut(). OK, the above is not an encoding - at least not the way I would define an encoding. To me an encoding is a mapping from numeric character code to glyph. The above is a remapping, a mapping from numbers to numbers (which is what TeX and the VF world deals with). One big difference is that a remapping (or permutation if you like) cannot make unencoded glyphs accessible, while an encoding can. Secondly, what I see above is really just the remapping used to avoid the handicap that TrueType on Mac and Windows cannot handle control character range (0 - 31) (Curiously they did no make this mistake in Windows NT). This remapping was also in use earlier to avoid bugs in other software. The char code range from 0 - 9 is remapped to 161 - 170, and 10 - 32 is remapped to 173 - 195, and 127 is remapped to 196. This was first used in Adobe's Lucida Math fonts, and was invented I believe by Barry Smith of Blue Sky Research back in the dark ages (1987 or 1988). It is commonly referred to as `Lucida Math' remapping I believe. The CM fonts in Type 1 format, as well as math fonts from Y&Y have an encoding vector that essentially uses the above `Lucida Math remapping' scheme to *duplicate* the control character range higher up for software too dumb to handle control characters directly. But the glyphs are *also* accessible in their original `control character' positions. Using the `upper range' instead of the control characters sometimes comes in handy when dealing with buggy software such as some versions of Adobe Illustrator and some versions of Adobe Acrobat Reader. But other than that, there is no reason to do this for Type 1 fonts. > The same encoding can be applied to the default encoding of a Type 1 font. This I think is definitely a bad idea. Why cripple perfectly good fonts by forcing them to use only the usable glyphs in `TeX text' (OT1) encoding (probably less than 92 out of the full 228 `standard' glyphs)? Regards, Berthold. 16-Feb-1995 7:08:20-GMT,2722;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id AAA14544 for ; Thu, 16 Feb 1995 00:08:16 -0700 Received: from netcomsv.netcom.com (uucp4.netcom.com) by MATH.AMS.ORG (PMDF #7286 ) id <01HN3MCQD11C91W71B@MATH.AMS.ORG>; Thu, 16 Feb 1995 02:00:12 EST Received: from clement.UUCP by netcomsv.netcom.com with UUCP (8.6.9/SMI-4.1) id WAA07998; Wed, 15 Feb 1995 22:36:15 -0800 Received: by quixote.com (UUPC/extended 1.12b); Wed, 15 Feb 1995 22:28:28 PST Date: Thu, 16 Feb 95 6:28:26 +1600 From: Don Hosek Subject: font encoding To: tex-implementors@MATH.AMS.ORG Message-id: <2f42f08d.clement@quixote.com> Content-transfer-encoding: 7BIT X-Mailer: ELM [version 2.3 PL11] for OS/2 {I've wearied of adding the extra names to the list... this is only going to tex-implementors now)/ > > The encoding could then be applied as a standard to all PS fonts > > as well, although there is the difficulty of really bad support > > for character code mapping under Windows and OS/2 (yet another > > reason I'm saving up for a Mac) > It is even easier in Y&Y TeX System 1.2, where reencoding is `on the fly' > you don't need to run a batch file first. Just specify an environment > variable that tells it what encoding vector to use (the vector itself is > written out in a plain ASCII file). But does this reencoding happen in such a way as to make the inaccessible characters available through ATM? If so, you've done something quite nice. The version of Y&Y TeX that I looked at came with instructions that didn't quite work (perhaps my fault... this was two weeks and 120 miles away from where I sit now so I can't check to see what was happening) and required effectively installing a separate copy of the font to access the fi and fl glyphs. IBM has verified that these glyphs are inaccessible with the OS/2 ATM. My strong suspicion is that the same is true of Windows ATM. The characters which I want are all readily available under the Mac. Ergo, the Mac is a better platform for my needs. Plus, GX promises (assuming that apps ever support it) much better glyph access than is currently available for Intel, even in the Real Soon Now world of Microsoft vaporware. -dh -- Don Hosek "What frightens me is when people substitute fear for reason." Quixote Digital Typography -The Day the Earth Stood Still Publishers of _Serif: The Magazine of Type and Typography_ 909-621-1291 Current reading: _Hosea_ (Andersen, FAX: 909-625-1342 Freedman, eds.), _Antologia de dhosek@quixote.com Cuentos Mexicanos II_ (Millau, ed.) 16-Feb-1995 11:30:53-GMT,4395;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id EAA15666 for ; Thu, 16 Feb 1995 04:30:49 -0700 Received: from dub-img-2.compuserve.com by MATH.AMS.ORG (PMDF #7286 ) id <01HN3VCY8VS091WBSC@MATH.AMS.ORG>; Thu, 16 Feb 1995 06:18:09 EST Received: by dub-img-2.compuserve.com (8.6.9/5.941228sam) id GAA24220; Thu, 16 Feb 1995 06:17:13 -0500 Date: 16 Feb 1995 06:15:55 -0500 (EST) From: Louis Vosloo <71172.524@compuserve.com> Subject: font encoding To: Don Hosek Cc: TeX Implementors Message-id: <950216111554_71172.524_GHL46-1@CompuServe.COM> Content-transfer-encoding: 7BIT Hi: > > > The encoding could then be applied as a standard to all PS fonts > > > as well, although there is the difficulty of really bad support > > > for character code mapping under Windows and OS/2 (yet another > > > reason I'm saving up for a Mac) > > It is even easier in Y&Y TeX System 1.2, where reencoding is `on the fly' > > you don't need to run a batch file first. Just specify an environment > > variable that tells it what encoding vector to use (the vector itself is > > written out in a plain ASCII file). > But does this reencoding happen in such a way as to make the > inaccessible characters available through ATM? > If so, you've done something quite nice. Thank you! Glad somebody appreciates it...and they said it couldn't be done! > The version of Y&Y TeX that I looked at came with instructions that > didn't quite work (perhaps my fault... this was two weeks and 120 miles > away from where I sit now so I can't check to see what was happening) It works. Lots of people use it every day. Also, the installation procedures for fonts that Y&Y offers for use with TeX take advantage of this. It's just somewhat awkard since you need to run the `encode.bat' batch file (or the `install.bat' for fonts before loading the fonts with ATM). > and required effectively installing a separate copy of the font to access the fi and fl glyphs. Well, no, it modifies the PFB file and made new TFM and PFM files. I single copy is enough. However, if you *also* wanted to use the fonts with Windows ANSI encoding (or whatever), then you did need to install a second copy. (This is in old versions, of course --- now a single copy will work for everything). > IBM has verified that these glyphs are inaccessible with the OS/2 ATM. > My strong suspicion is that the same is true of Windows ATM. Yes indeed, there is no `on the fly' reencoding in Windows (or OS/2) --- if you don't know what you are doing :=). > The characters which I want are all readily available under the Mac. > Ergo, the Mac is a better platform for my needs. Well: clearly not. Since you can access any glyph you like in DVIWindo. When it comes to the Mac, I guess you never need for example: % Lslash, lslash, Yacute, yacute, Scaron, scaron, Zcaron, zcaron, % Eth, eth, Thorn, thorn, minus, multiply, brokenbar % onequarter, onehalf, threequarters, onesuperior, twosuperior, threesuperior which are not accessible on the Mac. Perhaps more important: ff ffi ffl dotlessj etc. for fonts that have them, like Lucida Bright, Lucida Sans etc. > Plus, GX promises (assuming that apps ever support it) much better glyph access > than is currently available for Intel, even in the Real Soon Now world of Microsoft vaporware. GX does things for applications that TeX already does for you (like ligatures), so it has, I feel, little to contribute to the TeX world. Its main potential advantage is to improve the capabilities of applications that are inferior to TeX in typesetting capabilities. And right now it doesn't work right. Most people uninstall it soon after installing it. Also, unless it is adopted on other platforms its impact will be limited. Portability... Regards, Berthold. P.S. The reason I have not paid much attention to the discussion of a `base encoding' is because that is something only important for a VF based approach. I believe the right way to do this is instead to provide full `on the fly' reencoding, *not* a fixed base encoding followed by a permutation of the character codes from 0 - 255. The latter really does introduce serious limitations and is doomed to failure since people will never agree to a single fixed based encoding. 16-Feb-1995 13:49:04-GMT,1214;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id GAA16214 for ; Thu, 16 Feb 1995 06:48:55 -0700 Received: from vms.rhbnc.ac.uk (alpha1.rhbnc.ac.uk) by MATH.AMS.ORG (PMDF #7286 ) id <01HN3ZSKZ8TS91WG5I@MATH.AMS.ORG>; Thu, 16 Feb 1995 08:25:28 EST Date: 16 Feb 1995 13:23:13 +0000 (GMT) From: Philip Taylor (RHBNC) Subject: RE: Coding questions To: mackay@cs.washington.edu Cc: tex-implementors@MATH.AMS.ORG, bkph@ai.mit.edu, CHAA006@alpha1.rhbnc.ac.uk Reply-to: P.Taylor@alpha1.rhbnc.ac.uk Message-id: <950216132313.2020171e@vms.rhbnc.ac.uk> Content-transfer-encoding: 7BIT >> This is simply bizarre. Afm2tfm makes 2 tfms if you tell it to, and >> and you can impose whatever coding you want on either of them. I would by _very_ grateful if you could explain how to cause it to generate TFMs with ligatures in; I have read the documentation from cover to cover, asked experts, and still had no success; at the moment I cobble the ligatures in via a PL file, as in: afm2tfm %1 -T cm.enc %2 tftopl %2 copy %2.pl+ligtable.pl tmp.pl copy tmp.pl %2.pl del tmp.pl pltotf %2 Philip Taylor, RHBNC 16-Feb-1995 13:52:20-GMT,6717;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id GAA16240 for ; Thu, 16 Feb 1995 06:52:16 -0700 Received: from arl-img-3.compuserve.com by MATH.AMS.ORG (PMDF #7286 ) id <01HN3YPI462O91W85H@MATH.AMS.ORG>; Thu, 16 Feb 1995 07:53:44 EST Received: by arl-img-3.compuserve.com (8.6.9/5.941228sam) id HAA05702; Thu, 16 Feb 1995 07:48:32 -0500 Date: 16 Feb 1995 07:47:32 -0500 (EST) From: Louis Vosloo <71172.524@compuserve.com> Subject: Coding questions To: "INTERNET:mackay@cs.washington.edu" Cc: TeX Implementors Message-id: <950216124732_71172.524_GHL28-1@CompuServe.COM> Content-transfer-encoding: 7BIT Hi: > From Pierre Mackay: > It is a bit unfortunate that TFM format did not anticipate the character > name strings that Adobe enshrines, but it didn't. It is a > serviceable format even so, but it would have been a shade more > serviceable with the human-readable names. At the time, file size and reading speed was no doubt a big concern. So we have this very compact human-unreadable file format that deals with glyphs *only* as numbers. Unfortunately VF perpetrates this by dealing with glyphs *also* only as numbers. Hence it is limited to remapping (permuting the numbers from 0 - 255). One needs more. Which is why - whether one uses VF or not - one needs actual reencoding. A common confusion results from an identification of the idea of VF and the idea of font encoding. These are quite separate things - and each has its uses. You can reencode without using VF and you can use VF without reencoding. > You can set up a tfm to point you directly at all the characters in > (e.g.) Adobe Expert encoding if you want to and that gives you all sorts of accent > composites. Or rather it does if the expert font has been put > together responsibly. There are many foundries which use > the basic set of Adobe Standard Encoding names for everything > no matter what the actual glyph content of the font is. > In those cases, one might just as well use numerical indices. This is a problem of crude font creation tools like Fontographer. No responsible foundry would use inappropriate glyphs names. (And its *not* ASE they use, but an application specific encoding that has `glyph names' for all 255 character codes which as you point our are simply aliases for the numbers from 0 - 255 --- a disgusting subversion of Adobe's wonderful encoding vector idea). > Because TFM does not use names, it cannot be used as a > vehicle to go rooting around in the unencoded section of a Type1 font. > The encoding has to be supplied first. Right, so the encoding is frozen into the TFM file. And unfortunately the TFM format makes no provision for even *recording* what encoding it is for. Worse yet, TFM files get frozen into TeX format files, leading to all sorts of nightmares where changes in metrics appear not to have any effect. Fortunately these days the speed advantages of format files is not much of an issue any more... > ... I frankly admit that I actuallly didn't understand much of what you said. I think it is because we have different world views. And each assumes that things are done in a certain way. > That said I can get back to general agreement with Bertold's last > point. Universal encoding schemes to cover everything are not > going to work, and certainly not in a 256 cell array with some > of the cells made useless by Windows caltrops and land mines. These are only land-mines if you don't use `on the fly' reencoding. And, by the way, the Macintosh OS has completely analogous `land-mines'. Both platforms as default reencode plain vanialla text fonts to a platform-specific encoding. And on both platforms some applications have trouble with the control character range (0 - 31 and 127) and some applications assume 32 is a space, and 9 is tab, 10 is return and 13 is linefeed etc. > Even Unicode doesn't manage it, but at least it holds some > spaces open for private encoding. And would anyone care to take a bet on > when wide-character text-processing will become generally available? Well it has for several years in AT&T Plan 9 and more recently in Windows NT. Just keep in mind that UNICODE does not do quite what you want, since it is a *character* encoding (input side) not a *glyph* encoding (output side). So for example ligatures and alternate forms have no place in UNICODE, and using the `private' area is a nightmare that leads us back full circle to the encoding mess we have to deal with now. > There is certainly no harm in agreeing on a not-quite-256 character > basic encoding for TeX-based applications on defective platforms. It > clearly won't be either Knuth encoding or [D,E]C.encoding, because of > the arbitrary holes that have to be left in it. That being the case, > I would still rather use something as close as possible to Adobe > Standard Encoding, ASE is a singularly bad choice in my opinion. It only has about 150 of the `standard' 228 glyphs and does not match any other encoding such as Mac standard roman, Windows ANSI, ISO Latin 1. etc. > but apparently Windows applications are so inflexible that it can't be done. Well, that is just not true. As mentioned before, the Y&Y TeX system has made it possible to use arbitrary encoding for years in Windows. And now it is even simpler than it was before. Secondly, why single out Windows? Mac has the same platform-specific encoding problems. And Unix only gets left out of the discussion because it has no real support for scalable fonts (Until recently with Display PostScript in Solaris 2.3). > And PLEASE, if this encoding is to be imposed on Type1 text fonts > let us be sure that none of the simplex characters in Adobe > Standard Encoding, (encoded or unencoded) is left out. I *completely* agree with that. And go further: let us make sure none of the 228 `standard' glyphs get left out (and add ff ffi ffl and dotlessj while you are at it). > For most fonts the accented composites matter a lot less, > though if you want them, there is no harm in having them. They should be in the encoding because (i) it makes life easier in dealing with hyphenation in TeX to have pre-built composites, and (ii) in some fonts the composite characters are not simply superpositions of a base and an accent (for example, in Lucida Sans Console, the accents for the upper case letters are shallower than the accents on the lower case letters) (iii) some composites having overlapping parts which can lead to rendering problems if not done right (Aring, Ccedilla, ccedilla etc). Regards, Berthold. 16-Feb-1995 15:22:21-GMT,2712;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id IAA16925 for ; Thu, 16 Feb 1995 08:22:19 -0700 Received: from swan.cl.cam.ac.uk by MATH.AMS.ORG (PMDF #7286 ) id <01HN427LCRUO91W8B7@MATH.AMS.ORG>; Thu, 16 Feb 1995 09:35:48 EST Received: from ouse.cl.cam.ac.uk (user spqr100 (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Thu, 16 Feb 1995 14:15:00 +0000 Date: 16 Feb 1995 14:14:53 +0000 From: Sebastian Rahtz Subject: Re: font encoding In-reply-to: Your message of "16 Feb 1995 06:15:55 EST." <950216111554_71172.524_GHL46-1@CompuServe.COM> To: Louis Vosloo <71172.524@compuserve.com> Cc: Don Hosek , TeX Implementors Message-id: <"swan.cl.cam.:267580:950216141513"@cl.cam.ac.uk> Content-transfer-encoding: 7BIT oh dear. i can feel another 6 months argument with Berthold coming on, which is a shame 'cos i agre with him 99% of the way. but lets get it straight. IF we accept that T1 encoiding (or small variants thereof) have any future, THEN we need more than the range of glyphs that eg Adobe provide. such as tcedilla. ALSO IF we accept that we wamt capsandsmallcaps faked fonts THEN reencoding ad nauseam wont help. So we have two solutions: a) mangle the fonts with Berthol'd's tools. fine, but that means you have to give the fonts to recipeints even if they already bought them. its a nightmare of maintenance. you have to run DOS to use Berthold's tools. they dont (for me) work 100% right (I never did get my caps and smallcaps right). its not the same font when you are done. b) use virtual fonts. portable, non-intrusive. easy to tailor. other virtues. so i find VF technology a *necessary* tool in my armoury for doing conventional typesetting. once we have it, why not use it for more? but as we all already know, *whatever happens*, one has to reencode the basic fonts regardless. i am pissed off with endless whinging about T1 encoding. firstly, any replacement has to be as rich, or we in Europe will not be interested. secondly, i close my ears to all well-meaning "if only" statements until/unless theire authors put work where their mouth is, and produce a complete new encoding which is better, docuemnted and justified and accepted by more than a jury of 1. i know nothing about True Type, and want to know less. my only experience is that when i installed Scientific Word with TrueTeX, it buggered up my Acrobat Reader until i zapped all those damned .fot files. but unless/until someone shows me a TT font doing a complete test of a T1 document, i think it should go to the devil. sebastian 16-Feb-1995 17:37:21-GMT,2887;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id KAA18697 for ; Thu, 16 Feb 1995 10:37:18 -0700 Received: from life.ai.mit.edu by MATH.AMS.ORG (PMDF #7286 ) id <01HN469Y96UO91WBEJ@MATH.AMS.ORG>; Thu, 16 Feb 1995 11:30:40 EST Received: from kauai (kauai.ai.mit.edu) by life.ai.mit.edu (4.1/AI-4.10) for tex-implementors@vax02.ams.org id AA10764; Thu, 16 Feb 95 11:29:50 EST Received: by kauai (4.1/AI-4.10) id AA10173; Thu, 16 Feb 95 11:29:48 EST Date: 16 Feb 1995 11:29:48 -0500 (EST) From: bkph@ai.mit.edu (Berthold K.P. Horn) Subject: font name case To: tex-implementors@MATH.AMS.ORG Message-id: <9502161629.AA10173@kauai> Content-transfer-encoding: 7BIT > ============================================================================= > 3. List of font names. > ============================================================================= > I believe we can stick with the METAFONT names and still stay within the > 8-character limit, except with longer names like "lcircle10", which may > simply be truncated and remain unambiguous. Yes. This is sort of automatic in DOS/Windows, if one has a supposed 8+3 name with more than 8 chars before the dot it just gets truncated. Unfortunately this does not work automagically that way in Windows NT, since it will look for the file with the longer name and not find it if the font files were installed earlier in DOS with the truncated name. A nuisance on a dual boot configuration... > I further propose that the names (such as the Windows "face name") be lower > case in the fonts themselves, but that software recognize names with > case-insensitivity, to the extent possible. For example, a font should carry > a face name "cmr10" and not "Cmr10", but programs should recognize either. The BSR CM fonts in Type 1 format use PostScript FontNames that are all upper case because of a need to keep names generated by the 5+3+3+... contraction rule unique on the Macintosh and (such names are broken up into fields before contraction based on hyphens and transitions from lower case to upper case). (So don't blame this one on DOS file name case insensitivity! :=). It was convenient to also make the font *menu names* (`QuickDraw' name on the mac and `Windows Face' name in Windows) also upper case. (Although there is no requirement that the menu names match the PS FontNames and indeed with long font names they do not). Now that scalable CM fonts have appeared with lower case menu names, we'll have to modify applications to ignore case. Which is OK I guess, although it would have been nicer to retain case sensivity... Fortunately this doesn't affect TeX itself at all since it only deals with the TFM metric files. Just previewers and printer drivers and other things that have to actually deal with the font itself. Berthold. 17-Feb-1995 6:30:59-GMT,1250;000000000001 Received: from ios.com (kinch@ios.com [198.4.75.44]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with ESMTP id XAA26033 for ; Thu, 16 Feb 1995 23:30:57 -0700 Received: (from kinch@localhost) by ios.com (8.6.9/8.6.9) id BAA29201 for beebe@math.utah.edu; Fri, 17 Feb 1995 01:30:50 -0500 From: "Richard J. Kinch" Message-Id: <199502170630.BAA29201@ios.com> Subject: Re: Proposed Re-Encoding Standard To: beebe@math.utah.edu (Nelson H. F. Beebe) Date: Fri, 17 Feb 1995 01:30:49 -0500 (EST) In-Reply-To: from "Nelson H. F. Beebe" at Feb 14, 95 02:21:14 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 458 > Thanks for your posting on a proposed re-encoding standard to deal with > the limitations of TrueType fonts. Thanks, and you're correct about DC needing to get standardized. I was supposed to add that to my posting, but I forgot it at the last minute. I expect a "rationing" of the 224 slots of TrueType/Windows to the DC extensions, plus virtual fonts, will be needed. I'm hoping that interested parties can get together to do it compatibly. Richard 17-Feb-1995 20:43:44-GMT,2211;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id NAA03120 for ; Fri, 17 Feb 1995 13:43:37 -0700 Received: from june.cs.washington.edu by MATH.AMS.ORG (PMDF #7286 ) id <01HN5SWJFWXC91WNQG@MATH.AMS.ORG>; Fri, 17 Feb 1995 15:29:28 EST Received: (mackay@localhost) by june.cs.washington.edu (8.6.9/7.2ju) id MAA29410; Fri, 17 Feb 1995 12:28:37 -0800 Date: 17 Feb 1995 12:28:37 -0800 From: mackay@cs.washington.edu (Pierre MacKay) Subject: Re: Coding questions In-reply-to: Philip Taylor (RHBNC)'s message of Thu, 16 Feb 1995 13:23:13 GMT <950216132313.2020171e@vms.rhbnc.ac.uk> To: P.Taylor@alpha1.rhbnc.ac.uk Cc: tex-implementors@VAX02.AMS.ORG, bkph@ai.mit.edu, CHAA006@alpha1.rhbnc.ac.uk Message-id: <199502172028.MAA29410@june.cs.washington.edu> Content-transfer-encoding: 7BIT Sorry, I was conflating two steps. with the -v flag afm2tfm makes a vpl file chock full of ligatures---for Romanized Ottoman I put in about 50, and then vptovf makes the cooked tfm. If you specify the same encoding for -p and -t and use it in the psfonts.map " MYEncoding ReEncodeFont " you can use the ligatured tfm and forget about the vf file. I used to do that, when I ran a machine whose performance with vf files was too slow to be endured. %=======================================================================% | 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. | | I will continue unofficially to provide tape distributions and | | any 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) 17-Feb-1995 22:14:12-GMT,5443;000000000001 Received: from vax02.ams.org (VAX02.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.9/8.6.9) with SMTP id PAA04096 for ; Fri, 17 Feb 1995 15:14:04 -0700 Received: from terminus.cs.umb.edu by MATH.AMS.ORG (PMDF #7286 ) id <01HN5S0VRCU891WEGC@MATH.AMS.ORG>; Fri, 17 Feb 1995 15:04:01 EST Received: by terminus.cs.umb.edu id AA06031 (5.65c/IDA-1.4.4 for tex-implementors@MATH.AMS.ORG); Fri, 17 Feb 1995 15:02:51 -0500 Date: 17 Feb 1995 15:02:51 -0500 From: "K. Berry" Subject: Coding questions To: tex-implementors@VAX02.AMS.ORG, s.rahtz@elsevier.co.uk, alanje@cogs.susx.ac.uk Message-id: <199502172002.AA06031@terminus.cs.umb.edu> Content-transfer-encoding: 7BIT I am all for a common encoding table. A while back a few folks worked on a base encoding that could be used for both latex and the current dvips fonts. The details about how we made the character code assignments are in the comments at the top of this file. I don't know what the hex codes in the original message from Richard K. refer to, so I can't tell what incompatibilities there are. We haven't started generating fonts yet, so there's certainly no problem with changing this. % @psencodingfile{ % author = "P. MacKay, Alan Jeffrey, S. Rahtz, K. Berry, B. Horn", % version = "0.3", % date = "10 February 1995", % filename = "8r.enc", % [blah blah blah ...] % } % % Idea is to have all the characters normally included in Type 1 fonts % available for typesetting. This is effectively the characters in Adobe % Standard Encoding + ISO Latin 1 + extra characters from Lucida. % % Character code assignments were made as follows: % % (1) the Windows ANSI characters are in their Windows ANSI positions, % because Windows users cannot easily reencode the fonts, and it makes % no difference on other systems. The only Windows ANSI characters not % available are those that make no sense for typesetting -- rubout % (127 decimal), nobreakspace (160), softhyphen (173). % % (2) The caron and dotlessi characters are in the positions used by % Y&Y for their modified ATM encoding. % % (3) Remaining characters are assigned arbitrarily to the first few % positions. % % (4) (Y&Y) Lucida Bright includes some extra text characters; in the % hopes that other PostScript fonts, perhaps created for public % consumption, will include them, they are included starting at 0x10. % % (5) Remaining positions left undefined are for use in (hopefully) % upward-compatible revisions, if someday more characters are generally % available in the Type 1 fonts. % % LIGKERN info is omitted, since this encoding is intended for use at the % driver end. Including ligatures and kerns would make the TFM files % much larger, to no particular purpose. If someone actually wants to % typeset in this encoding, they can pick a different name, and regenerate % the fonts. /TeXBase1Encoding [ % 0x00 (encoded characters from Adobe Standard not in Windows 3.1) /breve /dotaccent /fi /fl /fraction /hungarumlaut /Lslash /lslash /ogonek /ring /tilde /minus % These are the only two remaining unencoded characters, so may as % well include them. /Zcaron /zcaron /.notdef /.notdef % 0x10 (TeX characters from, e.g., Lucida Bright) /dotlessj /ff /ffi /ffl /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef % 0x20 (ASCII begins) /space /exclam /quotedbl /numbersign /dollar /percent /ampersand /quotesingle /parenleft /parenright /asterisk /plus /comma /hyphen /period /slash % 0x30 /zero /one /two /three /four /five /six /seven /eight /nine /colon /semicolon /less /equal /greater /question % 0x40 /at /A /B /C /D /E /F /G /H /I /J /K /L /M /N /O % 0x50 /P /Q /R /S /T /U /V /W /X /Y /Z /bracketleft /backslash /bracketright /asciicircum /underscore % 0x60 /grave /a /b /c /d /e /f /g /h /i /j /k /l /m /n /o % 0x70 /p /q /r /s /t /u /v /w /x /y /z /braceleft /bar /braceright /asciitilde /.notdef % rubout; ASCII ends % 0x80 /.notdef /.notdef /quotesinglbase /florin /quotedblbase /ellipsis /dagger /daggerdbl /circumflex /perthousand /Scaron /guilsinglleft /OE /caron % Y&Y /.notdef /.notdef % 0x90 /.notdef /quoteleft /quoteright /quotedblleft /quotedblright /bullet /endash /emdash /tildeaccent /trademark /scaron /guilsinglright /oe /dotlessi % Y&Y /.notdef /Ydieresis % 0xA0 /.notdef % nobreakspace /exclamdown /cent /sterling /currency /yen /brokenbar /section /dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen % Y&Y (also at 45); Windows' softhyphen /registered /macron % 0xD0 /degree /plusminus /twosuperior /threesuperior /acute /mu /paragraph /periodcentered /cedilla /onesuperior /ordmasculine /guillemotright /onequarter /onehalf /threequarters /questiondown % 0xC0 /Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring /AE /Ccedilla /Egrave /Eacute /Ecircumflex /Edieresis /Igrave /Iacute /Icircumflex /Idieresis % 0xD0 /Eth /Ntilde /Ograve /Oacute /Ocircumflex /Otilde /Odieresis /multiply /Oslash /Ugrave /Uacute /Ucircumflex /Udieresis /Yacute /Thorn /germandbls % 0xE0 /agrave /aacute /acircumflex /atilde /adieresis /aring /ae /ccedilla /egrave /eacute /ecircumflex /edieresis /igrave /iacute /icircumflex /idieresis % 0xF0 /eth /ntilde /ograve /oacute /ocircumflex /otilde /odieresis /divide /oslash /ugrave /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis ] def 7-Mar-1995 2:35:57-GMT,1242;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.10/8.6.10) with SMTP id TAA11416 for ; Mon, 6 Mar 1995 19:35:54 -0700 Received: from ios.com by MATH.AMS.ORG (PMDF #7286 ) id <01HNTV7K1HYO96VY7C@MATH.AMS.ORG>; Mon, 6 Mar 1995 20:54:30 EST Received: (from kinch@localhost) by ios.com (8.6.9/8.6.9) id UAA26202 for tex-implementors@math.ams.org; Mon, 6 Mar 1995 20:53:56 -0500 Date: 06 Mar 1995 20:53:55 -0500 (EST) From: "Richard J. Kinch" Subject: Bug in "thorn" glyph of DC fonts To: tex-implementors@MATH.AMS.ORG Message-id: <199503070153.UAA26202@ios.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: ELM [version 2.4 PL23] Content-Length: 459 I believe there may be a bug in the "thorn" glyph in the DC fonts on CTAN (file dxrlwest.mf). The serifs at the bottom of the stem do not match up with the stem itself. Kinch Computer Company Publishers of TrueTeX (R) brand of software Richard J. Kinch kinch@netcom.com 611 Mitchell Street Tel (607) 273-0222 Ithaca NY 14850 USA FAX (607) 273-0484 Info at FTP://ftp.netcom.com/pub/Tr/TrueTeX/truetex.txt 11-Mar-1995 21:17:30-GMT,7232;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.10/8.6.10) with SMTP id OAA00227 for ; Sat, 11 Mar 1995 14:17:20 -0700 Received: from MATH.AMS.ORG by MATH.AMS.ORG (PMDF #7286 ) id <01HO0JY5MCV495N2CH@MATH.AMS.ORG>; Sat, 11 Mar 1995 15:51:19 EST Date: 11 Mar 1995 15:51:14 -0500 (EST) From: bbeeton Subject: Announcing the 1995 update to TeX, Metafont, and friends To: tex-implementors@MATH.AMS.ORG Message-id: <794955074.769385.BNB@MATH.AMS.ORG> Content-transfer-encoding: 7BIT Mail-System-Version: Date: 11 Mar 95 Message No: 043 To: TeX implementors and distributors From: Barbara Beeton Subject: Announcing the 1995 update to TeX, Metafont, and friends A few days ago, I received the attached announcement from Don Knuth. As you read therein, he has updated several programs and related files, resulting in these new versions: TeX 3.14159 METAFONT 2.718 Computer Modern fonts (sources only) DVItype 3.5 PLtoTF 3.5 VPtoVF 1.4 plain.tex 3.14159 The new sources are in an alpha directory at labrea (see below); none of the "usual" /tex directories have been updated, so there will be no automatic updating of CTAN. I will ask Don about this, whether he would like the new material to undergo an initial shakedown after which the /tex areas at labrea will be upgraded, or if CTAN should be updated separately. The details of the bug reports and Don's responses have been delivered to me as a formidable stack of paper with his handwritten comments. As is my custom, I will transcribe the comments into an electronic file, send the originals to those who submitted the reports, and post the electronic version in this forum. That may well take a couple of weeks. (I will be out of town at a standards meeting March 21-26, and must prepare for it, as well as covering my usual AMS responsibilities, so the time available for this is limited.) I will do it as quickly as possible. ######################################################################## Date: 08 Mar 1995 18:22:30 -0800 --------- ANNOUNCING THE 1995 UPDATE TO TeX, METAFONT, and FRIENDS -------- I've just gone through all accumulated correspondence and made appropriate changes to the master TeX sources on my home computer. (I plan to do this again in February of 1998, 2002, 2007, etc.!) My files are grouped in two main subdirectories, "dist" and "local"; the former consists of the master WEB, TeX, METAFONT, Computer Modern, TeXware, and MFware sources, while the latter consists of my own change files and supplementary macros and fonts that other people might like to look at. These files fit into similarly named parts of the big TeX archive tree; they should replace their former counterparts. I don't know how to do this myself, not even at labrea, so I am hoping that all current maintainers of TeXnicalities will be alerted to the existence of this new material. I've checked everything pretty carefully, so I don't think there's any need to wait until independent vetting has been done. TeX Version 3.14159 has four bug fixes, two of which are significant: 1) fontmemsize can vary between formats dumped by INITEX and loaded by VIRTEX --- this problem had already been fixed by all the major implementations 2) math kerns disappear again at line breaks, as they should --- this problem arose by mistake in version 3.1415. 3) overflow won't occur when converting huge stretch/shrink amounts from real to integer --- again, implementors had fixed this 4) you can have more than 32K font parameters without crashing TeX (nobody ever wanted so many, but a crash is a crash) METAFONT Version 2.718 has only one bug fix, but it corrects a problem in the linear-equation-solving engine that lost significant figures and caused spurious overflows; the bug had been present since version 0.1. I've written a letter to Barbara Beeton about this, and she can send you a copy if you need more information. The bug had only microscopic effect on Computer Modern fonts. Ten changes were made to the Computer Modern fonts, affecting nine of the master source files, but the changes are rather minor and nearly invisible to the eye. (Again they help reduce the chance of overflow.) I have been unhappy to see so many people still using the pre-1992 CM fonts, because I made MAJOR important improvements in that year, and I hate to run across the obsolete symbols in preprints that people send me! Anybody who hasn't installed CM fonts since 1991 should surely change now; and please help stamp out all copies of the old fonts that you see installed anywhere. (The lowercase delta is the main giveaway --- the new shape is vastly better than the old. Also arrows are now darker, and several calligraphic caps are improved, etc etc; the TFM files did not change, but the images got lots better.) On the other hand, if you do have the 1993-or-later version of the fonts, there's no need to replace old bitmaps. Just replace the old source files, and regenerate fonts from them at your leisure. There are new versions of DVItype (3.5), PLtoTF (3.5), and VPtoVF (1.4). DVItype now checks the DVI file more carefully in material that is skipped over (e.g., between pages). Plain TeX format, version 3.14159, has eight changes, but only the change to \bmod has a substantial probability of affecting existing .tex files. Accents \b and \d have gotten better in four ways. Barbara Beeton will be distributing reward checks to 20 people who were first to report significant errors in Volumes A--E. The big "sweepstakes" winners this year were Chris Thompson (Cambridge) and Bogus{\l}aw Jackowski (Gdansk), who received the maximum $327.68 reward for pointing out longstanding bugs in TeX and METAFONT, respectively. All sources are frozen and no future changes will be made unless a new, serious and easily fixable error is reported. The threshold for calling something a feature rather than a bug is rising exponentially and may be almost infinitely high when I do this exercise again in 1998! However, I do still promise to maintain these programs as long as I am able. Where can you find the new sources? At labrea.stanford.edu, in file ~ftp/alpha/tex95.tar.gz (slightly less than 3MB). Thanks to all of you for continued high quality support. -- Don Knuth 3/8/95 ######################################################################## %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Character code reference %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Upper case letters: ABCDEFGHIJKLMNOPQRSTUVWXYZ % Lower case letters: abcdefghijklmnopqrstuvwxyz % Digits: 0123456789 % Square, curly, angle braces, parentheses: [] {} <> () % Backslash, slash, vertical bar: \ / | % Punctuation: . ? ! , : ; % Underscore, hyphen, equals sign: _ - = % Quotes--right left double: ' ` " %"at", "number" "dollar", "percent", "and": @ # $ % & % "hat", "star", "plus", "tilde": ^ * + ~ % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% [ end of message 043 ] 16-Mar-1995 18:38:41-GMT,2211;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.10/8.6.10) with SMTP id LAA28552 for ; Thu, 16 Mar 1995 11:38:36 -0700 Received: from MATH.AMS.ORG by MATH.AMS.ORG (PMDF #7286 ) id <01HO7D42D3BK985DND@MATH.AMS.ORG>; Thu, 16 Mar 1995 12:57:37 EST Date: 16 Mar 1995 12:57:31 -0500 (EST) From: bbeeton Subject: ["K. Berry" : t-i archive] To: tex-implementors@MATH.AMS.ORG Message-id: <795376651.277195.BNB@MATH.AMS.ORG> Content-transfer-encoding: 7BIT Mail-System-Version: i'm pleased to announce the existence of an archive of the tex-implementors traffic, for the private use of those who are on the tex-implementors list. this archive, courtesy of karl berry, is located at ftp.cs.umb.edu:private/tex/implementors . the following message will appear on your screen (unless you've turned off verbosity) when you connect there by ftp: -------------------- This archive of traffic on the tex-implementors@math.ams.org mailing list is maintained for the benefit of the list members. The file `current' is the current month's messages (if any). Although anyone is welcome to browse and read the material here, please do not redistribute any of it without permission of relevant author(s). If you think you should be on the list, ask barbara beeton, bnb@math.ams.org. -------------------- after reading the responses to my question whether the ad hoc traffic should be public or private, i have decided that it should remain private. although many, if not most, respondents were in favor of making it public, those who requested that it remain private presented their briefs with great eloquence, and i have been convinced. i trust that this will not inconvenience anyone, and in fact, just having the information available in a place where list members can get at it is a great improvement over the previous situation. the "official" messages will be posted at ctan; there are copies of many of them there now, but not all in one place. i will soon be asking robin fairbairns for help in getting this straightened out. thanks, karl! -- bb 16-Mar-1995 20:02:20-GMT,2098;000000000001 Received: from cs.umb.edu (cs.umb.edu [158.121.104.2]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id NAA29327 for ; Thu, 16 Mar 1995 13:02:18 -0700 Received: from Xenon.Stanford.EDU by cs.umb.edu with SMTP id AA21664 (5.65c/IDA-1.4.4 for ); Thu, 16 Mar 1995 14:57:19 -0500 Received: by Xenon.Stanford.EDU (5.61+IDA/25-Xenon-eef) id AA05814; Thu, 16 Mar 95 11:57:17 -0800 Date: Thu, 16 Mar 95 11:57:17 -0800 From: "Tomas G. Rokicki" Message-Id: <9503161957.AA05814@Xenon.Stanford.EDU> To: web2c-wizards@cs.umb.edu Subject: LaTeX2e path problems There has been no real discussion on how the required LaTeX2e path nonsense might be eliminated. Perhaps this is because there is no real problem here (although I believe there is); perhaps this is because no solutions are obvious. Here is a list of proposals to be torn apart. 1. LaTeX2e be changed to have files with names that are not in conflict with LaTeX or other packages. 2. Web2c/TeX be changed to look for files in a format-file or executable-name dependent manner. 2a. The directory in which the format file is found will be always scanned first for input files. 2b. The subdirectory of the `standard' /usr/lib/tex/inputs or whatever, with the same name as the format file, will be scanned first. 3. TeX/etc. be changed to deal with subdirectory components in path names. That is, the file latex2e/latex.tex will be converted to the system-dependent syntax (on VMS, [....latex2e]latex.tex, for instance). This, in my opinion, is the *correct* solution. All macro packages should then refer to their files with the appropriate subdir path. Any others? Ideally, the correct solution should: a) Eliminate any need for subdirectory searching b) Be backwards compatible (new exe, old files; new files, old exe; etc.) c) Work well with the file organization issues/new directory format d) Solve the LaTeX2e/LaTeX209 input files problem e) Work with the %& specification. -tom 21-Mar-1995 3:16:37-GMT,1583;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id UAA02227 for ; Mon, 20 Mar 1995 20:16:34 -0700 Received: from MATH.AMS.ORG by MATH.AMS.ORG (PMDF #7286 ) id <01HODH22EFB495NMYI@MATH.AMS.ORG>; Mon, 20 Mar 1995 21:54:54 EST Date: 20 Mar 1995 21:54:49 -0500 (EST) From: bbeeton Subject: update on tex 3.14159 from don knuth To: tex-implementors@MATH.AMS.ORG Message-id: <795754489.708106.BNB@MATH.AMS.ORG> Content-transfer-encoding: 7BIT Mail-System-Version: i just received a message from from don knuth. another bug has been found and corrected in the alpha version of tex 3.14149. please check for a new file on thursday, and please don't circulate the new version until he gives the go-ahead. thanks. -- bb --------------- Date: 20 Mar 1995 15:48:29 -0800 Subject: note from Don Knuth Two quick things: (1) [...] (2) I ... decided that I should definitely put those extra patches into initex and inimf (even though they fix a nonproblem, in the sense that the bad reference counts occur only when a malicious user is mounting an attack). ... I won't change the version numbers 3.14159 and 2.718; I hope nobody will be circulating those versions as they existed last week, but I really don't think it will be a problem if anybody does. So, please tell people to look for a new file on ~ftp/alpha at labrea! With luck, it will be there tomorrow, otherwise Thursday. After that, 1998 here we come! 5-Jun-1995 16:59:15-GMT,1442;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id KAA26622 for ; Mon, 5 Jun 1995 10:59:00 -0600 Received: from vms.rhbnc.ac.uk (alpha1.rhbnc.ac.uk) by MATH.AMS.ORG (PMDF #7286 ) id <01HRCI1PB8M89I63VB@MATH.AMS.ORG>; Mon, 5 Jun 1995 12:27:48 EST Date: 05 Jun 1995 17:16:49 +0100 (BST) From: Philip Taylor (RHBNC) Subject: RE: update on tex 3.14159 from don knuth To: BNB@MATH.AMS.ORG Cc: tex-implementors@MATH.AMS.ORG, CHAA006@alpha1.rhbnc.ac.uk Reply-to: P.Taylor@alpha1.rhbnc.ac.uk Message-id: <950605171649.222028e5@vms.rhbnc.ac.uk> Content-transfer-encoding: 7BIT Dear Barbara -- >> Date: 20 Mar 1995 21:54:49 -0500 (EST) >> From: bbeeton >> Subject: update on tex 3.14159 from don knuth >> To: tex-implementors@MATH.AMS.ORG >> Message-id: <795754489.708106.BNB@MATH.AMS.ORG> >> Content-transfer-encoding: 7BIT >> Mail-System-Version: >> i just received a message from from don knuth. >> another bug has been found and corrected in the alpha version >> of tex 3.14149. please check for a new file on thursday, and >> please don't circulate the new version until he gives the go-ahead. >> thanks. -- bb Has Don yet given the go-ahead? I am keen to offer e-TeX to TeX-Implementors, but our change files are all predicated on 3.14159. ** Phil. 12-Jun-1995 15:25:31-GMT,1534;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id JAA00512 for ; Mon, 12 Jun 1995 09:25:28 -0600 Received: from MATH.AMS.ORG by MATH.AMS.ORG (PMDF #7286 ) id <01HRM4ESS35C8WW6TE@MATH.AMS.ORG>; Mon, 12 Jun 1995 11:15:40 EST Date: 12 Jun 1995 11:15:35 -0400 (EDT) From: bbeeton Subject: RE: update on tex 3.14159 from don knuth In-reply-to: <950605171649.222028e5@vms.rhbnc.ac.uk> To: P.Taylor@alpha1.rhbnc.ac.uk Cc: tex-implementors@MATH.AMS.ORG Message-id: <802970135.422765.BNB@MATH.AMS.ORG> Content-transfer-encoding: 7BIT Mail-System-Version: phil, et al, in the absence of any more bug reports on the alpha version of tex 3.14159 and friends, in spite of the fact that i have heard nothing more from don knuth, i am satisfied that we have his implicit go-ahead to distribute this new version. i have asked for help from robin fairbairns in getting this posted to ctan, and he announced a week or more ago that he had made that update. there is one remaining problem -- getting the up-to-date files into the /tex area at labrea. i will work on that. there is no one in charge there, and making arrangements from the other side of the continent isn't exactly straightforward. until this has been straightened out, please regard the ctan files (unpacked) as the authoritative ones, unless you are going to work directly from the labrea /alpha (packed) file. -- bb 12-Jun-1995 16:56:13-GMT,2110;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id KAA01982 for ; Mon, 12 Jun 1995 10:56:07 -0600 Received: from swan.cl.cam.ac.uk by MATH.AMS.ORG (PMDF #7286 ) id <01HRM9CD7EW08Y5PYI@MATH.AMS.ORG>; Mon, 12 Jun 1995 12:12:05 EST Received: from dorceus.cl.cam.ac.uk (user rf (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Mon, 12 Jun 1995 16:57:48 +0100 Date: 12 Jun 1995 16:57:35 +0100 From: Robin Fairbairns Subject: Re: update on tex 3.14159 from don knuth In-reply-to: Your message of "12 Jun 1995 11:15:35 EDT." <802970135.422765.BNB@MATH.AMS.ORG> To: bbeeton Cc: P.Taylor@alpha1.rhbnc.ac.uk, tex-implementors@MATH.AMS.ORG Message-id: <"swan.cl.cam.:109140:950612155752"@cl.cam.ac.uk> Content-transfer-encoding: 7BIT Barbara writes: > there is one remaining problem -- getting the up-to-date files > into the /tex area at labrea. i will work on that. there is > no one in charge there, and making arrangements from the other > side of the continent isn't exactly straightforward. until > this has been straightened out, please regard the ctan files > (unpacked) as the authoritative ones, unless you are going to > work directly from the labrea /alpha (packed) file. This is a slightly sore point. I have installed everything necessary here, and when I last looked it had made it to dante. However, despite both my and Rainer Schoepf's best efforts, we don't seem to be able to sort out SHSU, which persists in mirroring 3.1415 from labrea's tex directory. When George Greenwade disappeared below the parapet, none of us knew terribly much about the layout of SHSU, and though we've worked rather hard at finding out, it's terribly difficult from this side of the atlantic. So -- Those who would normally acquire copies from SHSU should continue to go to labrea's alpha directory. The stuff does exist here (ftp.tex.ac.uk) and in Heidelberg (ftp.dante.de), so Europeans needn't suffer the appalling transfer rates that typically dog us over here. R 13-Jun-1995 10:12:22-GMT,1637;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id EAA10876 for ; Tue, 13 Jun 1995 04:12:13 -0600 Received: from balu.zdv.Uni-Mainz.DE by MATH.AMS.ORG (PMDF #7286 ) id <01HRN8OUFLS08Y5VL4@MATH.AMS.ORG>; Tue, 13 Jun 1995 04:58:42 EST Received: (from schoepf@localhost) by balu.zdv.Uni-Mainz.DE (8.6.12/8.6.12) id KAA02587; Tue, 13 Jun 1995 10:58:05 +0200 Date: 13 Jun 1995 10:58:05 +0200 From: Rainer Schoepf Subject: Re: update on tex 3.14159 from don knuth In-reply-to: <"swan.cl.cam.:109140:950612155752"@cl.cam.ac.uk> To: Robin Fairbairns Cc: bbeeton , P.Taylor@alpha1.rhbnc.ac.uk, tex-implementors@MATH.AMS.ORG Message-id: <199506130858.KAA02587@balu.zdv.Uni-Mainz.DE> Organization: Johannes Gutenberg-Universitaet Mainz Content-transfer-encoding: 7BIT References: <802970135.422765.BNB@MATH.AMS.ORG> <"swan.cl.cam.:109140:950612155752"@cl.cam.ac.uk> Robin Fairbairns writes: > This is a slightly sore point. I have installed everything necessary > here, and when I last looked it had made it to dante. However, > despite both my and Rainer Schoepf's best efforts, we don't seem to be > able to sort out SHSU, which persists in mirroring 3.1415 from > labrea's tex directory. I'm not sure that this is the problem. It could well be that the connection times out before it comes to mirroring the TeX sources. I'm currently running a mirror a SHSU against ftp.tex.ac.uk interactively. It's currently pulling over lots of stuff from the biblio subtree. Rainer 13-Jun-1995 20:01:53-GMT,5305;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id OAA16556 for ; Tue, 13 Jun 1995 14:01:47 -0600 Received: from jasper.ora.com by MATH.AMS.ORG (PMDF #7286 ) id <01HRNUHIKUJ48Y5SEM@MATH.AMS.ORG>; Tue, 13 Jun 1995 15:22:41 EST Received: (from norm@localhost) by jasper.ora.com (8.6.11/8.6.11) id PAA16088; Tue, 13 Jun 1995 15:22:01 -0400 Date: 13 Jun 1995 15:22:01 -0400 From: Norman Walsh Subject: Announcing: TWG-TDS Draft Standard 0.98 To: texhax@tex.ac.uk, info-tex@shsu.edu, tex-archive@Math.Utah.edu, tex-implementors@MATH.AMS.ORG Cc: twg-tds@shsu.edu Reply-to: twg-tds@shsu.edu Message-id: <199506131922.PAA16088@jasper.ora.com> Content-transfer-encoding: 7BIT The TUG Technical Working Group on a TeX Directory Structure is pleased to announce that a draft of the proposed TeX Directory Structure standard is available for public review. You can get it by FTP from: :/tex-archive/tds/draft-standard/ (The `/tex-archive' may vary; see the end of this message for a list of possible hosts.) The draft standard is available in LaTeX, PostScript, TeXinfo, HTML, and SGML formats. Comments and suggestions are welcome. Please communicate them by email to twg-tds@shsu.edu or by paper mail to Norman Walsh O'Reilly & Associates, Inc. 90 Sherman Street Cambridge, MA 02140 USA The primary purpose of this document is to describe a standard TeX Directory Structure (TDS) for macros, fonts, and other such implementation-independent TeX files. As a matter of practicality, it also suggests ways to incorporate the rest of the TeX files into a single structure. In the not-so-long run a consistent directory structure will make it much easier to install and maintain TeX. We hope that administrators and developers of both free and commercial implementations of TeX will adopt this standard. It has been designed to work on all modern systems. In particular, this Technical Working Group (TWG) believes it is usable under Unix, MS-DOS, OS/2, MacOS, and VMS. We hope to publish another draft, or make the final release (depending on the volume of comments and concerns) shortly after TUG 95. -- the TUG TWG on a TeX Directory Structure ------------------------------------------------------------------------ prompt$ finger ctan@ftp.shsu.edu [pip.shsu.edu] [...] In order to reduce network load, it is recommended that you use the Comprehensive TeX Archive Network (CTAN) host which is located in the closest network proximity to your site. Alternatively, you may wish to obtain a copy of the CTAN via CD-ROM (see help/CTAN.cdrom for details). Known partial mirrors of the CTAN reside on (alphabetically): ftp.adfa.oz.au (Australia) /pub/tex/ctan ftp.fcu.edu.tw (Taiwan) /pub2/tex ftp.germany.eu.net (Deutschland) /pub/packages/TeX ftp.cs.ruu.nl (The Netherlands) /pub/tex-archive ftp.uu.net (Virginia, USA) /pub/text-processing/TeX nic.switch.ch (Switzerland) /mirror/tex Known mirrors of the CTAN reside on (alphabetically): dongpo.math.ncu.edu.tw (Taiwan) /tex-archive gw.pacbell.com (California, USA) /mirror/ftp.shsu.edu/tex-archive ftp.center.osaka-u.ac.jp (Japan) /CTAN ftp.ccu.edu.tw (Taiwan) /pub/tex ftp.cs.rmit.edu.au (Australia) /tex-archive ftp.duke.edu (North Carolina, USA) /tex-archive ftp.gwdg.de (Deutschland) /pub/dante ftp.jussieu.fr (France) /pub4/TeX/CTAN ftp.loria.fr (France) /pub/unix/tex/ctan ftp.mpi-sb.mpg.de (Deutschland) /pub4/tex/mirror/ftp.dante.de ftp.muni.cz (The Czech Republic) /pub/tex/CTAN ftp.riken.go.jp (Japan) /pub/tex-archive ftp.uni-bielefeld.de (Deutschland) /pub/tex ftp.uni-stuttgart.de (Deutschland) /tex-archive (/pub/tex) ftp.usafa.af.mil (Colorado, USA) /mirrors/packages/TeX ftp.u-aizu.ac.jp (Japan) /pub/CTAN ftpserver.nus.sg (Singapore) /pub/zi/TeX kadri.ut.ee (Estonia) /pub/tex src.doc.ic.ac.uk (England) /packages/tex/uk-tex sunsite.unc.edu (North Carolina, USA) /pub/packages/TeX wuarchive.wustl.edu (Missouri, USA) /packages/TeX Please send updates to this list to . The participating hosts in the Comprehensive TeX Archive Network are: ftp.dante.de (Deutschland) -- anonymous ftp /tex-archive (/pub/tex /pub/archive) -- gopher on node sun.dante.de -- e-mail via ftpmail@dante.de -- Administrator: ftp.shsu.edu (Texas, USA) -- anonymous ftp and gopher /tex-archive (/pub/tex /pub/archive) -- NFS mountable from ftp.SHSU.edu:/pub/ftp/tex-archive -- e-mail via ftpmail@ftp.SHSU.edu -- World Wide Web access on www.SHSU.edu -- Administrator: ftp.tex.ac.uk (England) -- anonymous ftp /tex-archive (/pub/tex /pub/archive) -- gopher on node gopher.tex.ac.uk -- NFS mountable from nfs.tex.ac.uk:/public/ctan/tex-archive -- World Wide Web access on www.tex.ac.uk -- Administrator: 14-Jun-1995 8:21:52-GMT,1500;000000000001 Received: from thoth.mch.sni.de (thoth.mch.sni.de [192.35.17.2]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id CAA22081 for ; Wed, 14 Jun 1995 02:19:02 -0600 Received: from pgtd0143.mch.sni.de by thoth.mch.sni.de with SMTP id AA09904 (5.67a/IDA-1.5 for ); Wed, 14 Jun 1995 10:18:29 +0200 Received: (from herter@localhost) by pgtd0143.mch.sni.de (8.6.9/8.6.9) id KAA11088 for tex-archive@math.utah.edu; Wed, 14 Jun 1995 10:20:55 +0200 Date: Wed, 14 Jun 1995 10:20:55 +0200 From: Thomas Herter Message-Id: <199506140820.KAA11088@pgtd0143.mch.sni.de> To: info-tex@SHSU.edu, tex-archive@math.utah.edu, tex-implementors@math.ams.org, texhax@tex.ac.uk Cc: twg-tds@SHSU.edu Subject: Re: Announcing: TWG-TDS Draft Standard 0.98 Content-Type: text Content-Length: 640 w> The TUG Technical Working Group on a TeX Directory Structure is w> pleased to announce that a draft of the proposed TeX Directory w> Structure standard is available for public review. You can get it by w> FTP from: w> w> :/tex-archive/tds/draft-standard/ Hallo Norman, please note, that the file tdsguide.cls is missing in the tds/draft-standard/latex subdirectory. Moreover, I can not find this file in the whole tds tree. I think, I would be correct to provide this class file with the LaTeX source. Thomas. -- Thomas Herter email: thomas.herter@mch.sni.de +89 636-49973 100275.541@compuserve.com 14-Jun-1995 12:17:44-GMT,2031;000000000001 Received: from jasper.ora.com (jasper.ora.com [198.112.208.14]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with ESMTP id GAA23360 for ; Wed, 14 Jun 1995 06:13:55 -0600 Received: (from norm@localhost) by jasper.ora.com (8.6.11/8.6.11) id IAA07412; Wed, 14 Jun 1995 08:11:31 -0400 Date: Wed, 14 Jun 1995 08:11:31 -0400 From: Norman Walsh Message-Id: <199506141211.IAA07412@jasper.ora.com> To: texhax@tex.ac.uk, info-tex@SHSU.edu, tex-archive@math.utah.edu, tex-implementors@math.ams.org CC: twg-tds@SHSU.edu In-reply-to: vojta@math.berkeley.edu's message of Tue, 13 Jun 1995 17:23:12 -0700 Subject: TWG-TDS: some minor nits Reply-to: norm@ora.com > From: vojta@math.berkeley.edu (Paul Vojta) > Date: Tue, 13 Jun 1995 17:23:12 -0700 > > I have a few comments about the TDS copy I got from SHSU today. > > 1. In tds.dvi, the table of contents is a blank page. Fixed. > 2. I tried to re-LaTeX tds.dvi, but couldn't because I could not find the > file tdsguide.cls, either on CTAN or in a limited search on jasper. Fixed. I added these files. (Joachim, if you have a more recent version please let me know.) > 3. Bottom of page 3: "{\tt command} Commands are typeset in italics." > Shouldn't either \tt be changed to \it or italics be changed to typewriter > type? Yes. That will be corrected in the next draft. Thanks, Paul. These fixes are available immediately from ftp://jasper.ora.com/pub/twg-tds They will be available from CTAN within a day or so. Cheers, norm --- Norman Walsh | "The First Amendment is often inconvenient. But Production Tools Specialist | that is besides the point. Inconvenience does O'Reilly & Associates, Inc. | not absolve the government of its obligation to 90 Sherman Street | tolerate speech." -- Justice Anthony Kennedy, in Cambridge, MA 02140 | 91-155 (617) 354-5800/661-1116 FAX | 17-Jun-1995 9:30:16-GMT,7945;000000000001 Received: from omnigate.clarkson.edu (omnigate.clarkson.edu [128.153.4.2]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id DAA04553 for ; Sat, 17 Jun 1995 03:30:14 -0600 From: postmaster@omnigate.clarkson.edu Received: from omnigate.clarkson.edu by omnigate.clarkson.edu id <17158-1@omnigate.clarkson.edu>; Sat, 17 Jun 1995 05:31:39 -0400 To: beebe@math.utah.edu Subject: Delivery Report (failure) for mrd@usl.com Message-Type: Delivery Report Date: Sat, 17 Jun 1995 05:31:39 -0400 Message-ID: <"omnigate.c.153:17.05.95.09.31.33"@clarkson.edu> Content-Identifier: Announcing: T... ------------------------------ Start of body part 1 This report relates to your message: Subject: Announcing: TWG-TDS Draft Standard 0.98, Message-ID: <199506131922.PAA16088@jasper.ora.com>, To: texhax@tex.ac.uk, info-tex@SHSU.edu, tex-archive@math.utah.edu, tex-implementors@math.ams.org of Tue, 13 Jun 1995 16:18:37 -0400 Your message was not delivered to mrd@usl.com for the following reason: Message timed out ***** The following information is directed towards the local administrator ***** and is not intended for the end user * * DR generated by: mta omnigate.clarkson.edu * in /ADMD= /C=US/ at Sat, 17 Jun 1995 05:31:33 -0400 * * Converted to RFC 822 at omnigate.clarkson.edu * at Sat, 17 Jun 1995 05:31:39 -0400 * * Delivery Report Contents: * * Subject-Submission-Identifier: [/ADMD= /C=US/;<199506131922.PAA16088@jasper.or] * Content-Identifier: Announcing: T... * Subject-Intermediate-Trace-Information: /ADMD= /C=US/arrival Tue, 13 Jun 1995 16:18:37 -0400 action Relayed * Subject-Intermediate-Trace-Information: /ADMD= /C=US/arrival Tue, 13 Jun 1995 15:22:01 -0400 action Relayed * Content-Correlator: Subject: Announcing: TWG-TDS Draft Standard 0.98, * Message-ID: <199506131922.PAA16088@jasper.ora.com>, * To: texhax@tex.ac.uk, info-tex@SHSU.edu, tex-archive@math.utah.edu, tex-implementors@math.ams.org* Recipient-Info: mrd@usl.com, /RFC-822=mrd(a)usl.com/ADMD= /C=US/; * FAILURE reason Unable-To-Transfer (1); * diagnostic Maximum-Time-Expired (5); * last trace (ia5 text (2)) Tue, 13 Jun 1995 15:22:01 -0400; * converted eits ia5 text (2); ****** End of administration information ------------------------------ Start of forwarded message 1 Received: from sun.soe.clarkson.edu by omnigate.clarkson.edu with SMTP (PP) id <13970-0@omnigate.clarkson.edu>; Tue, 13 Jun 1995 16:18:39 -0400 Received: from csc-sun.math.utah.edu by sun.soe.clarkson.edu.soe (4.1/SMI-4.1) id AA14798; Tue, 13 Jun 95 16:16:55 EDT Received: from jasper.ora.com (jasper.ora.com [198.112.208.14]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with ESMTP id NAA16108 for ; Tue, 13 Jun 1995 13:24:49 -0600 Received: (from norm@localhost) by jasper.ora.com (8.6.11/8.6.11) id PAA16088; Tue, 13 Jun 1995 15:22:01 -0400 Date: Tue, 13 Jun 1995 15:22:01 -0400 From: Norman Walsh Message-Id: <199506131922.PAA16088@jasper.ora.com> To: texhax@tex.ac.uk, info-tex@SHSU.edu, tex-archive@math.utah.edu, tex-implementors@math.ams.org Cc: twg-tds@SHSU.edu Subject: Announcing: TWG-TDS Draft Standard 0.98 Reply-To: twg-tds@SHSU.edu The TUG Technical Working Group on a TeX Directory Structure is pleased to announce that a draft of the proposed TeX Directory Structure standard is available for public review. You can get it by FTP from: :/tex-archive/tds/draft-standard/ (The `/tex-archive' may vary; see the end of this message for a list of possible hosts.) The draft standard is available in LaTeX, PostScript, TeXinfo, HTML, and SGML formats. Comments and suggestions are welcome. Please communicate them by email to twg-tds@shsu.edu or by paper mail to Norman Walsh O'Reilly & Associates, Inc. 90 Sherman Street Cambridge, MA 02140 USA The primary purpose of this document is to describe a standard TeX Directory Structure (TDS) for macros, fonts, and other such implementation-independent TeX files. As a matter of practicality, it also suggests ways to incorporate the rest of the TeX files into a single structure. In the not-so-long run a consistent directory structure will make it much easier to install and maintain TeX. We hope that administrators and developers of both free and commercial implementations of TeX will adopt this standard. It has been designed to work on all modern systems. In particular, this Technical Working Group (TWG) believes it is usable under Unix, MS-DOS, OS/2, MacOS, and VMS. We hope to publish another draft, or make the final release (depending on the volume of comments and concerns) shortly after TUG 95. - -- the TUG TWG on a TeX Directory Structure - ------------------------------------------------------------------------ prompt$ finger ctan@ftp.shsu.edu [pip.shsu.edu] [...] In order to reduce network load, it is recommended that you use the Comprehensive TeX Archive Network (CTAN) host which is located in the closest network proximity to your site. Alternatively, you may wish to obtain a copy of the CTAN via CD-ROM (see help/CTAN.cdrom for details). Known partial mirrors of the CTAN reside on (alphabetically): ftp.adfa.oz.au (Australia) /pub/tex/ctan ftp.fcu.edu.tw (Taiwan) /pub2/tex ftp.germany.eu.net (Deutschland) /pub/packages/TeX ftp.cs.ruu.nl (The Netherlands) /pub/tex-archive ftp.uu.net (Virginia, USA) /pub/text-processing/TeX nic.switch.ch (Switzerland) /mirror/tex Known mirrors of the CTAN reside on (alphabetically): dongpo.math.ncu.edu.tw (Taiwan) /tex-archive gw.pacbell.com (California, USA) /mirror/ftp.shsu.edu/tex-archive ftp.center.osaka-u.ac.jp (Japan) /CTAN ftp.ccu.edu.tw (Taiwan) /pub/tex ftp.cs.rmit.edu.au (Australia) /tex-archive ftp.duke.edu (North Carolina, USA) /tex-archive ftp.gwdg.de (Deutschland) /pub/dante ftp.jussieu.fr (France) /pub4/TeX/CTAN ftp.loria.fr (France) /pub/unix/tex/ctan ftp.mpi-sb.mpg.de (Deutschland) /pub4/tex/mirror/ftp.dante.de ftp.muni.cz (The Czech Republic) /pub/tex/CTAN ftp.riken.go.jp (Japan) /pub/tex-archive ftp.uni-bielefeld.de (Deutschland) /pub/tex ftp.uni-stuttgart.de (Deutschland) /tex-archive (/pub/tex) ftp.usafa.af.mil (Colorado, USA) /mirrors/packages/TeX ftp.u-aizu.ac.jp (Japan) /pub/CTAN ftpserver.nus.sg (Singapore) /pub/zi/TeX kadri.ut.ee (Estonia) /pub/tex src.doc.ic.ac.uk (England) /packages/tex/uk-tex sunsite.unc.edu (North Carolina, USA) /pub/packages/TeX wuarchive.wustl.edu (Missouri, USA) /packages/TeX Please send updates to this list to . The participating hosts in the Comprehensive TeX Archive Network are: ftp.dante.de (Deutschland) -- anonymous ftp /tex-archive (/pub/tex /pub/archive) -- gopher on node sun.dante.de -- e-mail via ftpmail@dante.de -- Administrator: ftp.shsu.edu (Texas, USA) -- anonymous ftp and gopher /tex-archive (/pub/tex /pub/archive) -- NFS mountable from ftp.SHSU.edu:/pub/ftp/tex-archive -- e-mail via ftpmail@ftp.SHSU.edu -- World Wide Web access on www.SHSU.edu -- Administrator: ftp.tex.ac.uk (England) -- anonymous ftp /tex-archive (/pub/tex /pub/archive) -- gopher on node gopher.tex.ac.uk -- NFS mountable from nfs.tex.ac.uk:/public/ctan/tex-archive -- World Wide Web access on www.tex.ac.uk -- Administrator: ------------------------------ End of forwarded message 1 21-Jun-1995 8:45:12-GMT,1398;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id CAA05288 for ; Wed, 21 Jun 1995 02:44:56 -0600 Received: from thphy.uni-duesseldorf.de (xerxes.thphy.uni-duesseldorf.de) by MATH.AMS.ORG (PMDF #7286 ) id <01HRYDXV0Q3K8Y6UP3@MATH.AMS.ORG>; Wed, 21 Jun 1995 04:28:15 EST Received: from macbeth.thphy.uni-duesseldorf.de.thphy.uni-duesseldorf.de by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA02481; Wed, 21 Jun 95 10:30:04 +0200 Received: by macbeth.thphy.uni-duesseldorf.de.thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA17250; Wed, 21 Jun 95 10:27:39 +0200 Date: 21 Jun 1995 10:30:04 +0200 From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth) Subject: Ooops! I'm sorry!!! (was Re: test (no. 1) ... To: tex-implementors@MATH.AMS.ORG Message-id: <9506210830.AA02481@thphy.uni-duesseldorf.de> Content-transfer-encoding: 7BIT I want to apologize for my maximum stupidity in simply using the RMAIL reply function in response to Barbara's request for confirmation without clearing the CC-List (This should teach me somenthing!). It was too late to cancel the mail when I realized what I had done. Sorry for wasting bandwith and your time! -- Ulrik Vieth P.S. The mailer at tug@tug.org returned an error protocol in return to my accidental posting complaing about the form of my form address being not in UUCP-style. 21-Jun-1995 8:45:45-GMT,2073;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id CAA05294 for ; Wed, 21 Jun 1995 02:45:42 -0600 Received: from thphy.uni-duesseldorf.de (xerxes.thphy.uni-duesseldorf.de) by MATH.AMS.ORG (PMDF #7286 ) id <01HRYCKOZQO08Y72KF@MATH.AMS.ORG>; Wed, 21 Jun 1995 03:48:37 EST Received: from macbeth.thphy.uni-duesseldorf.de.thphy.uni-duesseldorf.de by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA02388; Wed, 21 Jun 95 09:50:26 +0200 Received: by macbeth.thphy.uni-duesseldorf.de.thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA17203; Wed, 21 Jun 95 09:47:58 +0200 Date: 21 Jun 1995 09:50:26 +0200 From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth) Subject: Re: test (no. 1) of new tex-implementors mailing procedure In-reply-to: <803669432.682696.BNB@MATH.AMS.ORG> (message from bbeeton on 20 Jun 1995 13:30:32 -0400 (EDT)) To: BNB@MATH.AMS.ORG Cc: tex-implementors@MATH.AMS.ORG, crh@MATH.AMS.ORG Message-id: <9506210750.AA02388@thphy.uni-duesseldorf.de> Content-transfer-encoding: 7BIT > please acknowledge receipt of this message as soon as possible, > and include a copy of the headers if you can. Message received. Headers follow below: -- Ulrik Vieth Mail-from: From BNB@MATH.AMS.ORG Tue Jun 20 23:13:38 1995 Return-Path: Received: from math.ams.org by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA02278; Tue, 20 Jun 95 23:13:24 +0200 Received: from axp14.ams.org by MATH.AMS.ORG (PMDF #7286 ) id <01HRXIM5N0CW8Y6OQF@MATH.AMS.ORG>; Tue, 20 Jun 1995 13:30:45 EST Received: from AXP14.AMS.ORG by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HRXIM1BVPS0009KI@AXP14.AMS.ORG>; Tue, 20 Jun 1995 13:30:32 -0500 (EST) Date: 20 Jun 1995 13:30:32 -0400 (EDT) From: bbeeton Subject: test (no. 1) of new tex-implementors mailing procedure To: tex-implementors@MATH.AMS.ORG Cc: crh@MATH.AMS.ORG Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Mail-System-Version: 21-Jun-1995 9:06:24-GMT,2078;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id DAA05367 for ; Wed, 21 Jun 1995 03:06:20 -0600 Received: from x4u2.desy.de by MATH.AMS.ORG (PMDF #7286 ) id <01HRYE3Z94GG8Y6Y9B@MATH.AMS.ORG>; Wed, 21 Jun 1995 04:32:23 EST Received: (from pks@localhost) by x4u2.desy.de (8.6.10/8.6.9) id IAA01065; Wed, 21 Jun 1995 08:32:05 GMT Date: 21 Jun 1995 10:32:05 +0200 (MST) From: Peter-Klaus Schilling Subject: Re: test (no. 1) of new tex-implementors mailing procedure In-reply-to: <803669432.682696.BNB@MATH.AMS.ORG> To: bbeeton Cc: tex-implementors@MATH.AMS.ORG, crh@MATH.AMS.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT > On Tue, 20 Jun 1995, bbeeton wrote: > Date: Tue, 20 Jun 1995 13:30:32 -0400 (EDT) > From: bbeeton > To: tex-implementors@MATH.AMS.ORG > Cc: crh@MATH.AMS.ORG > Subject: test (no. 1) of new tex-implementors mailing procedure > Resent-Date: Tue, 20 Jun 1995 17:53:56 GMT > Resent-From: NJSERV@DSYIBM.DESY.DE > Resent-To: pks@x4u2.desy.de > gentlemen, > we're moving to a new computer and a new mailer here at ams, and > one thing that has never been tested is its handling of mailing > lists. this is its first test. > > this test is being sent from the mm mailer to the alias > tex-implementors, which is a small subset of the production list. > > please acknowledge receipt of this message as soon as possible, > and include a copy of the headers if you can. > > there will be at least one more test, sending a message under > direct control of pmdf. > > thanks very much for your help. > -- bb > -------------------------------------------------- e-mail: schilling@desy.de address: Peter K. Schilling DESY Dpt. ZDV-ASG Notkestr. 85 - D-22603 Hamburg - Germany phone: +49 40 89983638 fax: +49 40 89943638 -------------------------------------------------- 22-Jun-1995 0:05:24-GMT,1849;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id SAA13754 for ; Wed, 21 Jun 1995 18:05:22 -0600 Received: from june.cs.washington.edu by MATH.AMS.ORG (PMDF #7286 ) id <01HRZAINZ1XC8Y6MPD@MATH.AMS.ORG>; Wed, 21 Jun 1995 20:00:30 EST Received: (mackay@localhost) by june.cs.washington.edu (8.6.12/7.2ju) id RAA13434; Wed, 21 Jun 1995 17:00:17 -0700 Date: 21 Jun 1995 17:00:17 -0700 From: mackay@cs.washington.edu (Pierre MacKay) Subject: Re: test (no. 1) of new tex-implementors mailing procedure In-reply-to: bbeeton's message of 20 Jun 1995 13:30:32 -0400 (EDT) <803669432.682696.BNB@MATH.AMS.ORG> To: BNB@MATH.AMS.ORG Cc: tex-implementors@MATH.AMS.ORG, crh@MATH.AMS.ORG Message-id: <199506220000.RAA13434@june.cs.washington.edu> Content-transfer-encoding: 7BIT Date: 20 Jun 1995 13:30:32 -0400 (EDT) From: bbeeton Subject: test (no. 1) of new tex-implementors mailing procedure To: tex-implementors@MATH.AMS.ORG Cc: crh@MATH.AMS.ORG MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Mail-System-Version: gentlemen, we're moving to a new computer and a new mailer here at ams, and one thing that has never been tested is its handling of mailing lists. this is its first test. this test is being sent from the mm mailer to the alias tex-implementors, which is a small subset of the production list. please acknowledge receipt of this message as soon as possible, and include a copy of the headers if you can. there will be at least one more test, sending a message under direct control of pmdf. thanks very much for your help. -- bb Here's the full message as received 28-Jul-1995 16:38:14-GMT,2090;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id KAA12740 for ; Fri, 28 Jul 1995 10:38:03 -0600 Received: from vms.rhbnc.ac.uk (alpha1.rhbnc.ac.uk) by MATH.AMS.ORG (PMDF #7286 ) id <01HTEH97KJ9CA5UBT5@MATH.AMS.ORG>; Fri, 28 Jul 1995 11:24:03 EST Date: 28 Jul 1995 16:10:51 +0100 (BST) From: Philip Taylor (RHBNC) Subject: e-TeX V1.0 beta To: tex-implementors@MATH.AMS.ORG Cc: CHAA006@alpha1.rhbnc.ac.uk Reply-to: P.Taylor@alpha1.rhbnc.ac.uk Message-id: <950728161051.20c27e7f@vms.rhbnc.ac.uk> Content-transfer-encoding: 7BIT Dear Colleagues -- much against my better judgement, I have allowed myself to be persuaded to announce the availability of e-TeX V1.0 beta to TeX-Implementors just one hour before I leave the country. We, the e-TeX/NTS team, would be _very_ grateful if you would try to port this software to the system(s) which you support. Rather than summarise the details of e-TeX here, I have set up a Web page with pointers to the sources and documentation; there is one demonstration implementation available (AXP/VMS), based directly on Christian Spieler's change-file for VMS TeX 3.14159; however, I very much hope that Christian will be one of those who undertakes the port, since the version I have produced lacks many of the subtleties that one would hope for in a production version. The Web page may be found at ftp://vms.rhbnc.ac.uk/e-tex/e-tex.html Please regard this announcement as reasonably confidential for the time being; the software is still formally in beta test, and will remain so until you the implementors have given us your blessing and confirmed that e-TeX is indeed 100% TeX-compatible. There are also some improvements which we would like to make to the associated macro libraries before going fully public. The e-TeX/NTS team look forward to hearing of your experiences in porting the software; we are accessible through a mailbox pointed to from the Web page. Yours very sincerely, Philip Taylor, for the e-TeX/NTS team. 31-Jul-1995 10:59:51-GMT,9723;000000000000 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id EAA07816 for ; Mon, 31 Jul 1995 04:59:42 -0600 Received: from thphy.uni-duesseldorf.de (xerxes.thphy.uni-duesseldorf.de) by MATH.AMS.ORG (PMDF #7286 ) id <01HTIAP9FMGGA5UHRN@MATH.AMS.ORG>; Mon, 31 Jul 1995 05:01:12 EST Received: from caligula.uni-duesseldorf.de (caligula.thphy.uni-duesseldorf.de) by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA18710; Mon, 31 Jul 95 11:02:07 +0200 Received: by caligula.uni-duesseldorf.de (5.x/SMI-SVR4) id AA03075; Mon, 31 Jul 1995 10:58:34 +0200 Date: 31 Jul 1995 10:58:34 +0200 From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth) Subject: Re: e-TeX V1.0 beta In-reply-to: <950728161051.20c27e7f@vms.rhbnc.ac.uk> (CHAA006@vms.rhbnc.ac.uk) To: tex-implementors@MATH.AMS.ORG Message-id: <9507310858.AA03075@caligula.uni-duesseldorf.de> Content-transfer-encoding: 7BIT Phil Taylor wrote: > Dear Colleagues -- much against my better judgement, I have allowed myself > to be persuaded to announce the availability of e-TeX V1.0 beta to > TeX-Implementors just one hour before I leave the country. Hi Phil et al., much against my better judgement, I was tempted to spend last Friday night trying to compile e-TeX with Web2C. Maybe it should have said: Warning, compiling e-TeX can be hazardous to your other interests! Anyway, here are my experiences. (Karl, are you listening?) 1. Merging the files: As I didn't have tie or patchweb on my machine and because I missed to download some of the auxiliary files required by texmerge, I had to think of another method of merging the files. I found that I could use the wmerge utility from cweb/examples to create the (hypothetical?) e-tex.web as follows: wmerge tex.web e-tex.ch > e-tex.web I then copied the web2c tex.ch to tex.ech and tried to tangle e-tex.web with tex.ech. 2. Tangling: It turned out that in order to get tangle to succeed, I had to modify only two modules involving wterm(banner) and wlog(banner), where banner had to be replaced by eTeX_banner. These are the modules where Web2c inserts a wterm(version_string) after wterm(banner). With these changes tangle e-tex.web tex.ech succeeded, but I later found that I had to increase pool_size to 125000 (with string_vacancies = 100000). It might be a good idea to put that change into the standard tex.ch to avoid future trouble. Apart from that, no further changes were necessary (a) because I didn't care to introduce a distinction between .fmt and .efmt file extensions and (b) because a mechanism for changing the default pool file name is already built into web2c. 3. Compiling: After tangling e-tex.web with tex.ech, I copied the resulting e-tex.p to tex.p in order to proceed with the standard Makefile for web2c/tex. (Note: It is important that ctex.ch exists and is older than tex.p, so that make will not attempt to re-tangle tex.web with ctex.ch to recreate tex.p.) I than changed to the top-level web2c directory and ran 'make -k TeX'. The web2c conversion went smoothly, but then I encoutered a few minor problems when compiling the resulting tex[1-10].c files. In tex2.c, in the new function pseudo_input, the compiler didn't like the `goto lab9999', because the corresponding label ended up in a different split file (initex.c). This `goto final_end' seems to come from the module , which is not normally used in web2c-tex, because input_ln is replaced by an external C function that does its own error handling. As a quick and dirty fix, I replaced the `goto lab9999' by `uexit(1)' in the C file tex2.c, but one should try to find a better solution. (Maybe insert an empty init..tini pair to fool the web2c converter?) Another problem occured while linking the initex and virtex binaries. This was caused by the increase in size which led to 10 split files instead of 9. I had to fix the Makefile to ensure that tex10.o got compiled and linked with the other files. (I once ran into a similar problem, when I adapted the web2c/mf Makefile for MetaPost.) To fix the name of the default pool file, web2c already provided a mechanism originally developed for MLTeX. I just had to add the compiler option -D'TEXPOOLNAME="e-tex.pool"' in the Makefile rules for initex.o and itex.o (the default rule no longer suffices!). With these changes to the web2c/tex Makefile, I eventually succeeded to compile initex and virtex. I finally renamed them back to e-initex and e-virtex, since all this renaming was just done to be able to use the standard Makefile and convert script. 4. Testing: Now, it was time for the big test: -------- % e-initex "*e-plain \dump" This is e-TeX, Version 3.14159-1.0beta (C version 6.1) (INITEX) entering extended mode (e-plain.tex (/usr/local/tex/texmf/tex/plain/base/plain.tex Preloading the plain format: codes, registers, parameters, fonts, more fonts, macros, math definitions, output routines, hyphenation (/usr/local/tex/texmf/tex/hyphen/english/hyphen.tex))) Beginning to dump on file e-plain.fmt (format=e-plain 95.7.29) 2040 strings of total length 28650 5553 memory locations dumped; current usage is 110&5431 964 multiletter control sequences ... 14787 words of font info for 50 preloaded fonts 14 hyphenation exceptions Hyphenation trie of length 6075 has 181 ops out of 751 181 for language 0 No pages of output. Transcript written on e-plain.log. -------- % e-initex "plain \dump" This is e-TeX, Version 3.14159-1.0beta (C version 6.1) (INITEX) entering compatibility mode (/usr/local/tex/texmf/tex/plain/base/plain.tex Preloading the plain format: codes, registers, parameters, fonts, more fonts, macros, math definitions, output routines, hyphenation (/usr/local/tex/texmf/tex/hyphen/english/hyphen.tex)) Beginning to dump on file plain.fmt (format=plain 95.7.29) 2031 strings of total length 28567 4989 memory locations dumped; current usage is 110&4876 923 multiletter control sequences ... 14787 words of font info for 50 preloaded fonts 14 hyphenation exceptions Hyphenation trie of length 6075 has 181 ops out of 751 181 for language 0 No pages of output. Transcript written on plain.log. -------- So this went all right. Now, I wanted to try an application that made use of the exteded features (e.g. TeX--XeT) and I promptly ran into a problem: -------- % weave tex.web e-tex.ch % mv tex.tex e-tex.tex % e-virtex "&e-plain" e-tex This is e-TeX, Version 3.14159-1.0beta (C version 6.1) entering extended mode (e-tex.tex (/usr/local/tex/texmf/tex/plain/web/webmac.tex) *1 ! Improper \beginR. \TeXXeT ->\TeX -{\revrm \beginR \TeX -\endR } the \TeXXeT \ feature is optional \C ...\XX \hfil \penalty -1\hfilneg \quad $\{\,$#1 $\,\}$\XX l.215 ...e}=0$\C{the \TeXXeT\ feature is optional} \Y\par ? h Sorry, this optional e-TeX feature has been disabled. ? ! Improper \endR. \TeXXeT ->\TeX -{\revrm \beginR \TeX -\endR } the \TeXXeT \ feature is optional \C ...\XX \hfil \penalty -1\hfilneg \quad $\{\,$#1 $\,\}$\XX l.215 ...e}=0$\C{the \TeXXeT\ feature is optional} \Y\par ? h Sorry, this optional e-TeX feature has been disabled. ? -------- At this point I stopped since it was already 3:30 a.m., but it appears that you'll have to fix e-tex.ch to enable the required TeX--XeT to be able weave it. (No, I don't expect anyone to reward me \pounds 2.56 for finding this bug.) Apart from that, things went remarkably well. Some minor changes to the Makefile and the change file (see the diff appended below) are most of what's required. The only real problem that needs to be resolved is the non-local goto across split files. So much for my preliminary results about compiling e-TeX for Web2C. Perhaps, I'll better leave it to Karl now to produce the `official' web2c e-TeX version (presumably for C version 7.0). Cheers, Ulrik Vieth. % diff -u tex.ch tex.ech --- tex.ch Tue Apr 18 15:25:13 1995 +++ tex.ech Sat Jul 29 02:44:35 1995 @@ -198,7 +198,7 @@ @!string_vacancies=100000; {the minimum number of characters that should be available for the user's control sequences and font names, after \TeX's own error messages are stored} -@!pool_size=124000; {maximum number of characters in strings, including all +@!pool_size=125000; {maximum number of characters in strings, including all error messages and help texts, and the names of all fonts and control sequences; must exceed |string_vacancies| by the total length of \TeX's own strings, which is currently about 23000} @@ -608,12 +608,12 @@ % [5.61] Eliminate the misleading message ``(no format preloaded)''. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% @x -wterm(banner); +wterm(eTeX_banner); if format_ident=0 then wterm_ln(' (no format preloaded)') else begin slow_print(format_ident); print_ln; end; @y -wterm (banner); +wterm (eTeX_banner); wterm (version_string); if format_ident>0 then slow_print(format_ident); print_ln; @@ -1093,12 +1093,12 @@ @z @x -begin wlog(banner); +begin wlog(eTeX_banner); slow_print(format_ident); print(" "); print_int(day); print_char(" "); months:='JANFEBMARAPRMAYJUNJULAUGSEPOCTNOVDEC'; @y -begin wlog (banner); +begin wlog (eTeX_banner); wlog (version_string); slow_print(format_ident); print(" "); print_int(day); print_char(" "); -------- 25-Aug-1995 11:34:06-GMT,1379;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id FAA01780 for ; Fri, 25 Aug 1995 05:33:54 -0600 Received: from linaxp.ikp.physik.th-darmstadt.de (130.83.133.11) by MATH.AMS.ORG (PMDF #7286 ) id <01HUHBXNPVS0AH3GCB@MATH.AMS.ORG>; Fri, 25 Aug 1995 06:53:11 EST Received: by linac.ikp.physik.th-darmstadt.de (MX V4.1 AXP) id 5; Fri, 25 Aug 1995 12:52:47 CET +0100 Date: 25 Aug 1995 12:52:30 +0100 (CET) From: "Christian Spieler, Institut fuer Kernphysik, Schlossgartenstr. 9, D-64289 Darmstadt" Subject: e-TeX port for VMS (DECUS TeX) is available To: tex-implementors@MATH.AMS.ORG Cc: P.Taylor@alpha1.rhbnc.ac.uk, SPIELER@linac.ikp.physik.th-darmstadt.de Message-id: <00995672.1AA65820.5@linac.ikp.physik.th-darmstadt.de> Content-transfer-encoding: 7BIT Hello, After being triggered by Phil Taylor, I have invested some work into the VMS DECUS TeX port to make it compatible with the e-TeX change file. At the time of this writing, a full featured betatest source distribution is finished. I will send it to Phil Taylor as soon as he is back. Then, it should appear quite soon on the e-TeX ftp server. (Please Phil, send me a message when you are prepared to receive a 520 block Zip archive of e-TeX-Beta for VMS.) Best regards, Christian Spieler 29-Aug-1995 16:40:46-GMT,2191;000000000001 Received: from math.ams.org (MATH.AMS.ORG [130.44.1.5]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with SMTP id KAA06788 for ; Tue, 29 Aug 1995 10:40:43 -0600 Received: from Campino.Informatik.RWTH-Aachen.DE by MATH.AMS.ORG (PMDF #7286 ) id <01HUN79AHSE8AH41OS@MATH.AMS.ORG>; Tue, 29 Aug 1995 11:43:28 EST Received: from genesis.informatik.rwth-aachen.de (genesis.Informatik.RWTH-Aachen.DE [137.226.112.10]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-3/8.6.12) with SMTP id RAA13591; Tue, 29 Aug 1995 17:22:20 +0200 Received: from GENESIS/MAILQUEUE by genesis.informatik.rwth-aachen.de (Mercury 1.1); Tue, 29 Aug 95 17:26:00 GMT+1 Date: 29 Aug 1995 17:25:35 +0100 From: Andreas Scherer Subject: Codepage setting in web2c? To: tex-k@cs.umb.edu Cc: tex-implementors@MATH.AMS.ORG Reply-to: scherer@genesis.informatik.rwth-aachen.de Message-id: <215D5A02539@genesis.informatik.rwth-aachen.de> Content-transfer-encoding: 7BIT X-mailer: Pegasus Mail v2.3 (R2). Dear fellow TeXnicians. Last week I was faced with the urgent request for extending the Amiga implementation of the web2c system with a feature to allow the user to apply different `codepage' settings for 8-bit character encodings. At the time of writing, version 6.1 of the web2c system uses the standard 7-bit ASCII setting of the `xord' and `xchr' tables as of `tex.web'. I know of at least two implementations of such a feature, both coming in binary form only, so I'll have to write the necessary code myself. But before I'm going to do this for the second distribution of the `AmiWeb2C' system, I'd very much appreciate your input regarding ideas about the general layout of the `code page file', i.e., the text file where the user specifies the relation between the input/output/printing encodings of the 256 possible character numbers, the use of command line options and/or environment variables to adapt for different such files. My fondest hope is that somebody already has written code to this end and is willing to kindly share it in a broader range. I'm looking forward to your support. Andreas Scherer AaXen University of TeXnology, Germany 10-Sep-1995 19:23:50-GMT,2072;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with ESMTP id NAA22655 for ; Sun, 10 Sep 1995 13:23:47 -0600 From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HV45L2D8NK0004ZB@AXP14.AMS.ORG>; Sun, 10 Sep 1995 14:59:02 -0500 (EST) Received: from MZDMZA.ZDV.UNI-MAINZ.DE (dzdmza.zdv.Uni-Mainz.DE) by MATH.AMS.ORG (PMDF #7286 ) id <01HV45KX8VLCAPTJGF@MATH.AMS.ORG>; Sun, 10 Sep 1995 14:58:55 EST Received: from decnet-daemon (KNAPPEN@VKPMZD) by MZDMZA.ZDV.UNI-MAINZ.DE (PMDF V5.0-4 #4432) id <01HV4HSBZC5S91VUW5@MZDMZA.ZDV.UNI-MAINZ.DE> for tex-implementors@MATH.AMS.ORG; Sun, 10 Sep 1995 20:58:45 +0100 Date: Sun, 10 Sep 1995 20:58:45 +0100 Subject: Non-standard hyphenchar looks ugly on screen To: tex-implementors@MATH.AMS.ORG Message-id: <01HV4HSC17OI91VUW5@MZDMZA.ZDV.UNI-MAINZ.DE> X-VMS-To: MZDMZA::IN%"tex-implementors@MATH.AMS.ORG" X-VMS-Cc: KNAPPEN MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT As you may know, the Cork font encoding provides an additional hyphenchar different from hyphen (positioned on ASCII hyphen/minus). The additional hyphenchar is located on position 127 (octal 177, ^^?). However, if this hyphenchar is activated, the over/underfull box messages look very ugly, nothing reminds the reader of the messages that there were actually hyphenation point intended: Overfull \hbox (8.32245pt too wide) in paragraph at lines 365--367 []\T1/cmr/m/n/10.95 In L[]T[]X2.09 ge^^?schrie^^?be^^?ne Do^^?ku^^?men^^?te las ^^?sen sich mei^^?stens leicht nach [] I wonder, whether it is possible, that a TeX implementation outputs a hyphen at the breaking points, regardless of the hyphenchar of the actual font. If I have not overlooked something, this feature is not tested by the TRIP test and therefore possible with TeX. Yours, J"org Knappen. P.S. Today, I uploaded the dc-fonts version 1.2 to the british CTAN, they'll be available in a few days. 11-Sep-1995 8:26:34-GMT,3564;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.6.11/8.6.11) with ESMTP id CAA26792 for ; Mon, 11 Sep 1995 02:26:30 -0600 Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HV4W2N5HKW0009NH@AXP14.AMS.ORG>; Mon, 11 Sep 1995 03:36:53 -0500 (EST) Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.ORG (PMDF #7286 ) id <01HV4W2C0M68APTOIK@MATH.AMS.ORG>; Mon, 11 Sep 1995 03:36:45 EST Received: from azu.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with ESMTP; Mon, 11 Sep 1995 09:36:11 +0200 Received: by azu.informatik.uni-stuttgart.de; Mon, 11 Sep 1995 09:36:12 +0200 Date: Mon, 11 Sep 1995 09:36:12 +0200 From: Bernd Raichle Subject: Non-standard hyphenchar looks ugly on screen In-reply-to: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE's message of Sun, 10 Sep 1995 20:58:45 +0100 <01HV4HSC17OI91VUW5@MZDMZA.ZDV.UNI-MAINZ.DE> To: tex-implementors@MATH.AMS.ORG Cc: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Message-id: <199509110736.JAA29938@azu.informatik.uni-stuttgart.de> Content-transfer-encoding: 7BIT On Sun, 10 Sep 1995 20:58:45 +0100, KNAPPEN@VKPMZD.kph.Uni-Mainz.DE said: [...] JK> I wonder, whether it is possible, that a TeX implementation outputs a JK> hyphen at the breaking points, regardless of the hyphenchar of the actual JK> font. If I have not overlooked something, this feature is not tested by JK> the TRIP test and therefore possible with TeX. 0.) Even if a feature is _not_ tested by the TRIP test, a change of TeX's behaviour can be an incompatible TeX extension. 1.) Is Joerg's suggested change is contradicting with the intended behaviour of |short_display|? TeX.web, "[12] Displaying boxes": The first of these, called |short_display|, is used in ``overfull box'' messages to give the top-level description of a list. The other one, called |show_node_list|, prints a detailed description of exactly what is in the data structure. and The philosophy of |short_display| is to ignore the fine points about exactly what is inside boxes, except that ligatures and discretionary breaks are expanded. IMO Joerg's change (print \hyphenchar\font always as `- ignoring the actual value) is within the "philosophy" of |short_display| to give a quick overview what's inside a node list. |show_node_list| is used for e.g. \showbox to show "a detailed description of exactly what is in the" node list. Therefore a change of the behaviour of this procedure contradicts with its intended behaviour ("exactly what is in..."). 2.) |short_display| and |show_node_list| are the "two procedures that display a [node] list in symbolic form." If we change |short_display| and leave |show_node_list| unchanged, will it be ok that the output of these two procedures w.r.t. simple character nodes (= \hyphenchar\font) are different? If the explicit hyphen is unequal to \hyphenchar\font it is possible to hyphenate words with an explicit hyphen. Is it intended that in a long word with an explicit hyphen both hyphen chars can not be distinguised? In the moment it is my opinion to _not_ change TeX.web. ...or to make a test version of TeX including this change to get a feeling for the advantages and disadvantages of this change. Yours, Bernd Raichle PS: e-TeX extension proposal: new register \diagnostichyphenchar; initialised with -1; if in the range [0..255] this character is displayed for a hyphen char in a node list within diagnostic output (e.g. overfull box messages). 27-Nov-1995 12:06:34-GMT,4139;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id FAA09508 for ; Mon, 27 Nov 1995 05:06:16 -0700 (MST) Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HY4K6XX0HC000GX9@AXP14.AMS.ORG>; Mon, 27 Nov 1995 05:22:19 -0500 (EST) Received: from thphy.uni-duesseldorf.de (134.99.64.123) by MATH.AMS.ORG (PMDF #7286 ) id <01HY4K29JMZ4B2C4K8@MATH.AMS.ORG>; Mon, 27 Nov 1995 05:22:01 EST Received: from macbeth.uni-duesseldorf.de (macbeth.thphy.uni-duesseldorf.de) by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA00423; Mon, 27 Nov 95 11:18:12 +0100 Received: by macbeth.uni-duesseldorf.de (5.x/SMI-SVR4) id AA00336; Mon, 27 Nov 1995 11:15:29 +0100 Date: Mon, 27 Nov 1995 11:15:29 +0100 From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth) Subject: bug with 8-bit input in Metafont/MetaPost To: tex-implementors@MATH.AMS.ORG Cc: hobby@research.att.com Message-id: <9511271015.AA00336@macbeth.uni-duesseldorf.de> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 8BIT Following a discussion about problems with 8-bit input in MetaPost btex...etex constructs on the Metafont mailing list, I did some experimenting and found something strange. Try the following file: % File: test.mf, process with either Metafont or MetaPost % string s; s:="éo"; message("length of " & ditto & s & ditto & " = " & decimal length(s)); s:="oé"; message("length of " & ditto & s & ditto & " = " & decimal length(s)); s:="é"; message("length of " & ditto & s & ditto & " = " & decimal length(s)); s:="éé"; message("length of " & ditto & s & ditto & " = " & decimal length(s)); s:="o"; message("length of " & ditto & s & ditto & " = " & decimal length(s)); end. which produces: $ mf test.mf This is METAFONT, Version 2.718 (C version 6.1) (test.mf length of "^^e9o" = 2 length of "o^^e9" = 2 length of "^^e9" = 4 <--- ??? length of "^^e9^^e9" = 2 length of "o" = 1 ) Transcript written on test.log. $ mp test.mf This is MetaPost, Version 0.63 (C version 6.1) (test.mf length of "^^e9o" = 2 length of "o^^e9" = 2 length of "^^e9" = 4 <--- ??? length of "^^e9^^e9" = 2 length of "o" = 1 ) Transcript written on test.log. I think it is obvious that there is something wrong here. A single-character string containing a non-ASCII character is treated as a string of 4 characters in the ^^ notation, whereas a string containing non-printable characters mixed with printable characters or simply two or more non-printable characters gives the expected result. I have verified that this behaviour is not specific to Web2C. I get similar results for emTeX's mf386, except that it prints ^^? instead of ^^e9 (and pretends that it has length 3) as it doesn't seem to allow 8-bit characters in the xord/xchr tables. I've also verified that this behaviour is independent of whether the char_class of characters 127..255 is set to invalid_class, space_class, or letter_class. In order to avoid error messages for non-ASCII characters in MetaPost btex...etex constructs, which are skipped over anyway, it appears to be necessary to change the char_class of 127..255 to something non-invalid. So is this the first bug for Knuth in 1998? Anyone has a fix? BTW, it appears that the trap test doesn't catch this. - Ulrik Vieth. P.S. I've looked through the 1989 changes in tex82.bug and mf84.bug and I've noticed that Metafont doesn't seem to have anything like a hex_to_cur_chr routine. So could it be that this has been wrong ever since? Anyone still has a Metafont 1.x around for testing? P.P.S. Some more silly variants of the above. $ mf vieth@zarquon:~ $ mf This is METAFONT, Version 2.718 (C version 6.1) **\relax *string s; s=" "; % <-- a character *message(s & " " & decimal length(s)); ^^I 3 *string s; s=" "; % <-- two s *message(s & " " & decimal length(s)); ^^I^^I 2 *string s; s=" " & " "; % <-- two single s *message(s & " " & decimal length(s)); ^^I^^I 6 *string s; s= char(9) & char(9); *message(s & " " & decimal length(s)); ^^I^^I 2 *end. Transcript written on mfput.log. 27-Nov-1995 13:28:16-GMT,3285;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id GAA09737 for ; Mon, 27 Nov 1995 06:28:02 -0700 (MST) Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HY4OOCSI6O000BLN@AXP14.AMS.ORG>; Mon, 27 Nov 1995 07:30:53 -0500 (EST) Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.ORG (PMDF #7286 ) id <01HY4ONUWMS0B2CNOH@MATH.AMS.ORG>; Mon, 27 Nov 1995 07:30:38 EST Received: from isle.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with ESMTP; Mon, 27 Nov 1995 13:29:40 +0100 Received: by isle.informatik.uni-stuttgart.de; Mon, 27 Nov 1995 13:29:40 +0100 Date: Mon, 27 Nov 1995 13:29:40 +0100 From: Bernd Raichle Subject: Re: bug with 8-bit input in Metafont/MetaPost In-reply-to: <9511271015.AA00336@macbeth.uni-duesseldorf.de> (vieth@thphy.uni-duesseldorf.de) To: tex-implementors@MATH.AMS.ORG Cc: hobby@research.att.com Message-id: <199511271229.NAA05170@isle.informatik.uni-stuttgart.de> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 8BIT [My response to Vieth's posting on the metafont list:] Ulrik Vieth wrote: [...] > While I was tracing this down, I discovered something strange. > Try running the test file attached below through MetaPost and > ponder over the mysteries of Metafont and MetaPost. Obviously, > there's something wrong with the handling of 8-bit characters > (actually any non-printable character) in strings as well. > > % File: test.mf, process with either Metafont or MetaPost > % > string s; [...] > s:="é"; > message("length of " & ditto & s & ditto & " = " & decimal length(s)); [...] > s:="o"; > message("length of " & ditto & s & ditto & " = " & decimal length(s)); > end. > > This produces: > > $ mf test.mf > This is METAFONT, Version 2.718 (C version 6.1) > (test.mf [...] > length of "^^e9" = 4 <--- ??? [...] > length of "o" = 1 ) > Transcript written on test.log. [...] Congratulations, this is a bug in Metafont (and IMHO an old one, too, because it can also happen with other unprintable characters with codes <= 127). In mf.web Knuth uses the web macro |length| in "decimal" which takes the difference between the string start positions in the string pool to get the length of the string. What Knuth has missed was that the first 256 strings are _not_ given in their internal representation (i.e. a single character) but in the "external" x _or_ ^^xy character representation with a string length of 1, 3, or 4. An addition: message if "ä" < "a": "less" else: "not less" fi; end. (the first string is an a-umlaut = ^^e4) showing an analogeous bug in MF's internal function |str_vs_str| to compare strings... and probably you can find the bug in other places using the internal macro |length|, too. -bernd member of the NTS/e-TeX group PS: Btw, there is no such bug in TeX.web, otherwise it has been found days before :-( ____________________________________________________________________ Bernd Raichle "Le langage est source DANTE e.V., Koordinator `german.sty' de malentendus" email: german@dante.de (A. de Saint-Exupery) 27-Nov-1995 16:01:43-GMT,1504;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id JAA10934 for ; Mon, 27 Nov 1995 09:01:06 -0700 (MST) From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HY4R0NMZFK000H24@AXP14.AMS.ORG>; Mon, 27 Nov 1995 08:38:04 -0500 (EST) Received: from vzdmza.zdv.uni-mainz.de by MATH.AMS.ORG (PMDF #7286 ) id <01HY4QZP975SB2CV4X@MATH.AMS.ORG>; Mon, 27 Nov 1995 08:37:56 EST Received: from DECNET-DAEMON (KNAPPEN@VKPMZD) by VzdmzA.ZDV.Uni-Mainz.DE (PMDF V4.2-11 #4432) id <01HY538II2J40000EA@VzdmzA.ZDV.Uni-Mainz.DE>; Mon, 27 Nov 1995 14:31:50 +0100 Date: Mon, 27 Nov 1995 14:31:49 +0100 Subject: Re: bug with 8-bit input in Metafont/MetaPost To: vieth@thphy.uni-duesseldorf.de, tex-implementors@MATH.AMS.ORG, hobby@research.att.com Message-id: <01HY538IKQZM0000EA@VzdmzA.ZDV.Uni-Mainz.DE> X-VMS-To: VZDMZA::IN%"vieth@thphy.uni-duesseldorf.de" X-VMS-Cc: GATEWAY"tex-implementors@MATH.AMS.ORG", GATEWAY"hobby@research.att.com",KNAPPEN MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Indeed I have access to METAFONT 1.0; and here is what it says: b$ mf This is METAFONT, Vax/VMS Version 1.0 (no base preloaded) **\relax *string s; s=" "; % *message(s & " " & decimal length(s)); ^^I 3 *end. Transcript written on $DISK2:[KNAPPEN]MFPUT.LIS;2. b$ Thus, the bug was lurking since version 1.0. --J"org Knappen 28-Nov-1995 13:11:20-GMT,2080;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id GAA24228 for ; Tue, 28 Nov 1995 06:11:18 -0700 (MST) Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HY609GSL1C000BLV@AXP14.AMS.ORG>; Tue, 28 Nov 1995 06:13:17 -0500 (EST) Received: from IRLEARN.UCD.IE by MATH.AMS.ORG (PMDF #7286 ) id <01HY609BH3M8B2CZ0W@MATH.AMS.ORG>; Tue, 28 Nov 1995 06:13:09 EST Received: from IRLEARN.UCD.IE by IRLEARN.UCD.IE (IBM VM SMTP V2R2) with BSMTP id 7722; Tue, 28 Nov 95 09:47:45 GMT Received: from IRLEARN.UCD.IE (NJE origin WSULIVAN@IRLEARN) by IRLEARN.UCD.IE (LMail V1.2a/1.8a) with BSMTP id 0794; Tue, 28 Nov 1995 08:51:46 +0000 Date: Tue, 28 Nov 1995 08:28:24 +0000 (GMT) From: "Wayne G. Sullivan" Subject: string length in METAFONT To: tex-implementors@MATH.AMS.ORG Message-id: <01HY609C32IAB2CZ0W@MATH.AMS.ORG> Content-transfer-encoding: 7BIT Whether you think the value length() gives for a string in METAFONT is a "bug" or a "feature" depends on your point of view. The function length() does not give the number of characters input, but rather the number of characters in the internal representation of the string, which may differ both from the number of input characters and the number of output characters when the string is printed. Those who use characters beyond the standard ASCII values should set up their METAFONT so that it prints these as individual characters -- then the string length returns the expected value. For general distribution, it is a bad idea to use non-ASCII characters in METAFONT source, unless the character mapping is clearly indicated, because other systems may use the numerical values for a different characters. If you think it is worth the effort to modify the program so that if a single character string is input, it will be appended to the string pool, rather than assigned the existing value of the string which represents this character, then you can modify the change file to achieve this. Wayne Sullivan 28-Nov-1995 16:25:10-GMT,5207;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id JAA25577 for ; Tue, 28 Nov 1995 09:25:06 -0700 (MST) Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HY68OBDRIO0001U1@AXP14.AMS.ORG>; Tue, 28 Nov 1995 10:14:19 -0500 (EST) Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.ORG (PMDF #7286 ) id <01HY68JG8JQ8B2D5VE@MATH.AMS.ORG>; Tue, 28 Nov 1995 10:14:11 EST Received: from isle.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with ESMTP; Tue, 28 Nov 1995 16:08:15 +0100 Received: by isle.informatik.uni-stuttgart.de; Tue, 28 Nov 1995 16:08:15 +0100 Date: Tue, 28 Nov 1995 16:08:15 +0100 From: Bernd Raichle Subject: Re: string length in METAFONT In-reply-to: <01HY609C32IAB2CZ0W@MATH.AMS.ORG> (WSULIVAN@IRLEARN.UCD.IE) To: tex-implementors@MATH.AMS.ORG Message-id: <199511281508.QAA06543@isle.informatik.uni-stuttgart.de> Content-transfer-encoding: 7BIT "Wayne G. Sullivan" wrote: > Whether you think the value length() gives for a string in METAFONT is > a "bug" or a "feature" depends on your point of view. The function > length() does not give the number of characters input, but rather the > number of characters in the internal representation of the string, which > may differ both from the number of input characters and the number of > output characters when the string is printed. Those who use characters ^^^^^^^^^ > beyond the standard ASCII values should set up their METAFONT so that ^^^^^^ ^^^^^^^^^^ > it prints these as individual characters -- then the string length > returns the expected value. [...] Nope, wrong setup (your model of the world is too simple :-). Your proposal will introduce a dependency between the result of the processing of a MF/MP input file and the local MF/MP setup ==> IMO a bug! Starting with some clarifications: TeX and Metafont/Metapost are dealing with three representations of a single character: 1) an "external" code used by the host/OS, type |text_char| in TeX/MF normally a single integer value between 0 and 255 in an OS specific code, e.g. ISO Latin-1, EBCDIC, etc. 2) a TeX/MF internal code used within TeX/MF, type |ASCII_code| in TeX/MF an single eight-bit number (a subrange of integer) between 0 and 255 in ASCII resp. an extension of ASCII ("T1") and as a very, very special kind 3) an interim representation used _only_ for the output of unprintable characters to external files or log output (this representation uses the first 256 strings in the string pool with character codes given in the TeX/MF internal code) After TeX/MF has read in characters from the input (and TeX collates ^^xy to a single character), these characters use the internal representation of type |ASCII_code| and all strings consisting only of one character have to have length 1. If I process these strings within TeX/MF, it will be a bug if the length will change (cf. \string^^J bug in TeX 3.14). At the time the string is written to the "external world" the ^^xy notation (representation 3) is used to create a printable output form of a single character in the external representation. > For general distribution, it is a bad idea > to use non-ASCII characters in METAFONT source, unless the character > mapping is clearly indicated, because other systems may use the numerical > values for a different characters. The same applies to TeX input files. Nonetheless this is __not__ the problem reported in Vieth's bug report! Please have a look into the TeX Implementors archive and look at the discussion starting with your bug report in December 1990 (tex82.bug, change 393 & 396; mf84.bug, change 558). The reported TeX bug has similarities with the one reported by Vieth... with the same confusions during the discussion of it in this list :-) > If you think it is worth the effort > to modify the program so that if a single character string is input, it > will be appended to the string pool, rather than assigned the existing > value of the string which represents this character, then you can modify > the change file to achieve this. Nope, it is IMO a bug in MF (& MP) needing some changes in mf.web. Otherwise it is possible that two MF binaries with two different definitions which characters are printable or not can produce different results for the same input file -- even if they are used on the same host! My bug fix proposal: IMO the first 256 strings should be _single_ character strings of length(1), i.e. don't use the ^^xy notation in the string pool. The transcription to ^^X resp. ^^xy for unprintable characters should be done in |print_char| immediately before the character is printed to a file or the terminal. With this change, |slow_print| can be removed and replaced by |print| ...and the bug fixes in TeX/MF mentioned above (resulting in a cheque for me :-) would have been non-existent, if DEK has done it this way from the beginning. -bernd raichle 30-Nov-1995 19:32:31-GMT,1651;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id MAA06753 for ; Thu, 30 Nov 1995 12:32:23 -0700 (MST) Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HY98236DJK00043F@AXP14.AMS.ORG>; Thu, 30 Nov 1995 13:28:46 -0500 (EST) Received: from nic.iii.net by MATH.AMS.ORG (PMDF #7286 ) id <01HY981VDJJ4B2DIF1@MATH.AMS.ORG>; Thu, 30 Nov 1995 13:28:38 EST Received: from yandy.com (yandy.com [199.232.44.51]) by nic.iii.net (8.6.8/8.6.6) with SMTP id NAA24029 for ; Thu, 30 Nov 1995 13:28:17 -0500 Date: Thu, 30 Nov 1995 14:39:13 -0500 From: tech-help@YandY.com (Y&Y Inc) Subject: 3.14159 X-Sender: y-and-y@nic.iii.net (Unverified) To: tex-implementors@MATH.AMS.ORG Message-id: <199511301828.NAA24029@nic.iii.net> MIME-version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7BIT Hi: I dropped off the list for a while and am now wondering whether 3.14159 is official and if so, where I may find the files. Thanks. Berthold. ********************************************************* Bitmap-Free TeX for Windows ------------------------------------------------------------ Y&Y Inc Tuttle's Livery, 45 Walden Street Concord, MA 01742 USA Phone: 508/371-3286 Fax: 508/371-2004 Email: Sales: sales-help@YandY.com Technical Support: tech-help@YandY.com Other Inquiries: main-office@YandY.com WWW: http://www.YandY.com ********************************************************* 1-Dec-1995 13:23:11-GMT,1451;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id GAA16362 for ; Fri, 1 Dec 1995 06:23:09 -0700 (MST) Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HYA7Q5XITS00068P@AXP14.AMS.ORG>; Fri, 01 Dec 1995 06:30:43 -0500 (EST) Received: from swan.cl.cam.ac.uk by MATH.AMS.ORG (PMDF #7286 ) id <01HYA7PTFV68B2DGSY@MATH.AMS.ORG>; Fri, 1 Dec 1995 06:30:37 EST Received: from dorceus.cl.cam.ac.uk (user rf (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Fri, 1 Dec 1995 09:19:09 +0000 Date: Fri, 01 Dec 1995 09:18:58 +0000 From: Robin Fairbairns Subject: Re: 3.14159 In-reply-to: Your message of "Thu, 30 Nov 1995 14:39:13 EST." <199511301828.NAA24029@nic.iii.net> To: tech-help@YandY.com (Y&Y Inc) Cc: tex-implementors@MATH.AMS.ORG Message-id: <"swan.cl.cam.:233410:951201091913"@cl.cam.ac.uk> Content-transfer-encoding: 7BIT > Hi: I dropped off the list for a while and am now wondering whether 3.14159 > is official and if so, where I may find the files. Thanks. Berthold. On CTAN at present: bash$ more -n 10 /public/tex-archive/systems/knuth/tex/tex.web % This program is copyright (C) 1982 by D. E. Knuth; all rights are reserved. % Copying of this file is authorized only if (1) you are D. E. Knuth, or if [...] @d banner=='This is TeX, Version 3.14159' {printed when \TeX\ starts} R 4-Dec-1995 15:18:34-GMT,1957;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id IAA01231 for ; Mon, 4 Dec 1995 08:18:21 -0700 (MST) Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HYEJ2R2PWG000APD@AXP14.AMS.ORG>; Mon, 04 Dec 1995 08:38:36 -0500 (EST) Received: from IRLEARN.UCD.IE by MATH.AMS.ORG (PMDF #7286 ) id <01HYEJ26RRPCB2DQE7@MATH.AMS.ORG>; Mon, 4 Dec 1995 08:38:31 EST Received: from IRLEARN.UCD.IE by IRLEARN.UCD.IE (IBM VM SMTP V2R2) with BSMTP id 1581; Mon, 04 Dec 95 13:17:36 GMT Received: from IRLEARN.UCD.IE (NJE origin WSULIVAN@IRLEARN) by IRLEARN.UCD.IE (LMail V1.2a/1.8a) with BSMTP id 1794; Mon, 4 Dec 1995 12:57:41 +0000 Date: Mon, 04 Dec 1995 12:50:10 +0000 (GMT) From: "Wayne G. Sullivan" Subject: Unprintable characters in METAFONT To: tex-implementors@MATH.AMS.ORG Message-id: <01HYEJ2EKA3AB2DQE7@MATH.AMS.ORG> Content-transfer-encoding: 7BIT Upon further consideration of METAFONT's string handling problem, as noted by Vieth, I believe the behavior should be considered a "bug" and not just a "feature". The problem is that if 'X' is an unprintable character, METAFONT assigns a string of the form "^^x" to "X". If, however, one uses 'char' or substring, a single character substring for 'X' is generated, e.g., substring (0,1) of "XX". To give a valid context in which the above treatment of strings yields anomalous behaviour takes a bit of effort, because the METAFONT book specifies that MF programs should consist only of lines using visible ASCII characters and spaces. However, file names may include unprintable characters, so consider the following: def nameinput (text s) = scantokens ("input " & s) ; enddef ; If 'X.mf' is the MF file for the unprintable character 'X', then nameinput("X") does not cause 'X.mf' to be input, but nameinput(substring(0,1) of "XX") does. Wayne Sullivan 5-Dec-1995 10:50:10-GMT,4779;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id DAA12086 for ; Tue, 5 Dec 1995 03:49:59 -0700 (MST) Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HYFNEVLVXS0002FE@AXP14.AMS.ORG>; Tue, 05 Dec 1995 03:53:43 -0500 (EST) Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.ORG (PMDF #7286 ) id <01HYFN19E8R4B2DSAR@MATH.AMS.ORG>; Tue, 5 Dec 1995 03:53:23 EST Received: from isle.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with ESMTP; Tue, 5 Dec 1995 09:39:58 +0100 Received: by isle.informatik.uni-stuttgart.de; Tue, 5 Dec 1995 09:39:54 +0100 Date: Tue, 05 Dec 1995 09:39:54 +0100 From: Bernd Raichle Subject: bug with 8-bit input in Metafont/MetaPost - FYI To: tex-implementors@MATH.AMS.ORG Message-id: <199512050839.JAA14316@isle.informatik.uni-stuttgart.de> MIME-version: 1.0 Content-type: TEXT/PLAIN Content-transfer-encoding: 8BIT In collaboration with Ulrik Vieth and John Hobby, we have created necessary changes to clean up the string pool/output code (|print_char|, |print|, |slow_print|) in MF/MP.web to remove the implementation dependent behaviour of the current MF/MP version when dealing with unprintables characters. These changes can be applied to TeX.web, too. Ulrik will post a summary in a few days... (Ulrik?) While trying to understand DEK's design of the current output routines in TeX and MF using my archives, I have a few questions which, I hope, can be answered by someone on this list: 1.) MF.Web, section @: The condition |length(cur_exp)<>1| for the case |char_op:| (i.e. MF's "char" primitive) shows that DEK had encountered some "funny" behaviour with single character strings of length <> 1. This was the fix for it: if the corresponding string cur_exp < 256 has length <> 1, create a new string of length 1. (IM_H_O this was a quick&dirty fix) Did someone know when DEK has introduced this test for "char"? Does it exists from the beginning of the "char" primitive? ==> Has someone older versions of "mf.web"? What do you think of an archive containing older TeX and MF sources? 2.) mf84.bug I can only find the following entries in mf84.bug (ignoring really old entries) mentioning problems with unprintable characters: 402. char 127 to be a string of length 1; slow_print added (therefore). Change 402 (MF version 0.4->0.5) makes me think that older versions of MF assumes that a one character string containing the unprintable character 127 ("^^?") had length 1. When and _why_ has DEK changed this? Any reason why he only mentioned a change for 127 but not for one of the other characters < 32? And this entry. It is an addition to my response to Wayne Sullivan's posting on Tuesday, 28 Nov 1995, why I think that the reported behaviour is a bug in MF.web: 558. Allow unprintable file names, as in TeX change 396 (19 Sep 91) (Much of this is redundant except for people who make nonportable versions that allow other 8-bit codes to be in variable names---and for those people only if they allow input of more codes than they can print! Still, it seems best to make the programs for TeX and MF as alike as possible.) In "errata.five" we can find the following change in MFbook: \bugonpage C282, the three lines following the chart (9/30/89) \MF\ can also be configured to accept any or all of the character codes 128--255. However, \MF\ programs that make use of anything in addition to the 95 standard ASCII characters cannot be expected to run on other systems, so the use of extended character sets is discouraged. IMO the comment in change 558 (and the additional lines in the MFbook) gives DEK's sanction to all changes allowing characters with codes >=128 in an MF input file. If these characters are allowed, strings using them should have an appropriate length, __independent__ of the declared set of printable characters. Example: You can have two implementations which allow the input of all 8-bit characters. The first one declare all but the 95 standard ASCII characters as unprintable, in the second one national characters >=128 are declared printable. Now compare the result of length(char 228) and length("ä") (<= there is an a-umlaut character having code 228 in ISO Latin-1). You will assume that they will return 1 on both implementations, won't you? -bernd _____________________________________________________________________ Bernd Raichle Stettener Str. 73 | "Le langage est source 73732 Esslingen, FRG | de malentendus" Email: raichle@Informatik.Uni-Stuttgart.de | (A. de Saint-Exupery) 5-Dec-1995 11:14:24-GMT,2620;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id EAA12178 for ; Tue, 5 Dec 1995 04:14:23 -0700 (MST) Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HYFNV3F0F400021L@AXP14.AMS.ORG>; Tue, 05 Dec 1995 04:06:47 -0500 (EST) Received: from ifi.informatik.uni-stuttgart.de by MATH.AMS.ORG (PMDF #7286 ) id <01HYFNNKQUQ8B2DZTP@MATH.AMS.ORG>; Tue, 5 Dec 1995 04:06:38 EST Received: from isle.informatik.uni-stuttgart.de by ifi.informatik.uni-stuttgart.de with ESMTP; Tue, 5 Dec 1995 10:00:06 +0100 Received: by isle.informatik.uni-stuttgart.de; Tue, 5 Dec 1995 10:00:06 +0100 Date: Tue, 05 Dec 1995 10:00:06 +0100 From: Bernd Raichle Subject: Re: Unprintable characters in METAFONT In-reply-to: <01HYEJ2EKA3AB2DQE7@MATH.AMS.ORG> (WSULIVAN@IRLEARN.UCD.IE) To: tex-implementors@MATH.AMS.ORG Message-id: <199512050900.KAA14335@isle.informatik.uni-stuttgart.de> Content-transfer-encoding: 7BIT "Wayne G. Sullivan" , Mon 04 Dec 1995 12:50:10 +0000 (GMT) wrote: [...] > To give a valid context in which the above treatment of strings > yields anomalous behaviour takes a bit of effort, because > the METAFONT book specifies that MF programs should consist > only of lines using visible ASCII characters and spaces. ^^^^^^^^^^^^^ [...] Really? MF programs have to be coded in ASCII? This means that I can not use MF on a host using EBCDIC? :-) The MFbook page 282 tells me that \MF\ can also be configured to accept any or all of the character codes 128--255. However, \MF\ programs that make use of anything in addition to the 95 standard ASCII characters cannot be expected to run on other systems, so the use of extended character sets is discouraged. This means that I can use characters not restricted to visible ASCII but if I use them I can not assume that the MF input file will run on another system. The same restriction applies to TeX 3.x, nonetheless a lot of people are using TeX input files with more than the 95 visible ASCII characters. (Btw. my old TeX version 2.x was already capable to input umlaut characters with code > 127. These characters were mapped to character codes < 32 using xchr/xord, they were declared printable, and in a TeX input file the \catcode of these characters < 32 were declared \active and defined to expand to \"a, etc. Before 1989/TeX 3 I had already encountered problems when I tried to give these files to a person using a different TeX implementation.) -bernd 6-Dec-1995 10:52:10-GMT,9457;000000000001 Received: from cs.umb.edu (daemon@cs.umb.edu [158.121.104.2]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with SMTP id DAA02665 for ; Wed, 6 Dec 1995 03:51:59 -0700 (MST) Received: by cs.umb.edu id AA19774 (5.65c/IDA-1.4.4 for tex-pretest-outgoing); Wed, 6 Dec 1995 05:35:12 -0500 Date: Wed, 6 Dec 1995 10:54:57 +0100 Message-Id: <199512060954.KAA15601@isle.informatik.uni-stuttgart.de> From: Bernd Raichle To: tex-pretest@cs.umb.edu Subject: [Raichle@informatik.uni-stuttgart.de: MLTeX -- bug found and fixed!] Sender: owner-tex-pretest@cs.umb.edu Precedence: bulk X-Mailing-List: tex-pretest@cs.umb.edu I have sent the appended mail to gut@ens.fr to inform MLTeX user about a bug in the latest version of MLTeX. This version is also included in Karl's last web2c test release. The new version I'm mentioning in the mail is still in testing and has atleast one bug which I want to fix if possible. I've got an idea how to fix it without introducing new bugs, but I want to test this idea of a bug fix this evening before I will release the new MLTeX version. Best wishes, Bernd PS: The mail contains some lines to test one of the remaining bugs, and at the end there is a test file which will tell you about more bugs in older versions (if you are using MLTeX). ------- Start of forwarded message ------- Received-Date: Wed, 6 Dec 1995 09:24:17 +0100 Date: Wed, 6 Dec 1995 09:22:37 +0100 From: Bernd Raichle To: gut@ens.fr Cc: kb@cs.umb.edu, mattes@azu, mike@inrs-telecom.uquebec.ca Subject: MLTeX -- bug found and fixed! Errors-To: listman1@ens.fr Reply-To: GUT Distribution List X-Sequence: 4604 Last night I have found the cause of the "Bad metric (TFM) file" bug in the current version of MLTeX: TeX saves the first and the last value of a font |f| in two arrays called |font_bc[f]| and |font_ec[f]|. This is done __at the end__ of the procedure |read_font_info|---after the complete tfm file was read and all checks are done. Before the assignments the values in the two array entries are undefined, and normally initialized with 0. Now, MLTeX's additional substitution routines uses the value of these two array entries to decide if a requested glyph exists in the current font |f|, and if not to substitute it using a previously defined \charsubdef. This routine is also used during the tfm checking stage, e.g. there is a check if all ligature character in the ligature/kerning program will exist. Because the two array entries have undefined resp. zeroed values, MLTeX will think that __all__ characters have to get substituted using a \charsubdef during all checks. To encounter the error you have to simply define a \charsubdef for an existing character using a non-existing base character. With the following lines you will get the error while loading "cmr10.tfm"! You have to test it with an IniTeX version of MLTeX to make sure that "cmr10.tfm" was not loaded before. \catcode`\{=1 \catcode`\}=2 \expandafter\ifx\csname active\endcsname\relax \else \message{IniTeX only!!}\endinput\fi \charsubdef `A=`a 128 \font\test=cmr10\relax \end During the analysis of this bug I have found more bugs caused by MLTeX's substitution routine which I try to fix in my version of MLTeX, which I will release soon... There will be atleast one bug remaining which IMHO has to be removed because it can cause accesses to array entries beyond valid boundaries (i.e. you can get access violations). Sadly there is no simple, real fix for it :-( MLTeX test ---------- To allow people to test their MLTeX versions, I have created "MLTeXtst.tex", a test file for MLTeX which will try to find all known bugs in your MLTeX version. You simply have to say "initex mltextst" (depending on your implementation you have to say "tex -i mltextst" or "tex -ini mltextst" instead) and read the log output messages. For very old versions of MLTeX it will stop with the message ..... This is a very old version of MLTeX, ..... please update to the newest MLTeX version! (If you use the MLTeX patches with a TeX version <= 3.14, you will this old version.) For the official version in the moment, it will tell you: ..... If there will be an error "Bad metric (TFM) file", ..... please update to the newest MLTeX version! ! Font \test=cmti10 not loadable: Bad metric (TFM) file. \relax l.78 \font\test=cmti10\relax and if you will be using my version (after the release in a few days, I want do some additional tests to make sure that there's no unknown bugs hidden in the depth of MLTeX/TeX): Congratulations, you have a MLTeX version with almost all known bugs fixed. !! Be aware that MLTeX has atleast one known bug :-( !! If you get the message Congratulations, you have a MLTeX version with all known bugs fixed. please get in contact with me! It will save me a lot of times re-implementing MLTeX in such a way to handle \charsubdef changes without problems. :-) -bernd %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% CUT HERE % This is MLTEXTST.TEX (Version 1.0) in text format, as of Dec 05, 1995. % Test file for to check MLTeX implementations. % % Copyright (C) 1995 by B.Raichle; all rights are reserved. % % Usage: % % Run iniTeX on this file. Do not try to use plain-TeX or LaTeX. % Needs the font metric files: cmr10.tfm, cmti10.tfm % % \catcode`\{=1 \catcode`\}=2 \catcode`\#=6 % check for plain-TeX: % we have to ensure that _no_ fonts are preloaded \expandafter\ifx\csname active\endcsname\relax \else \message{Please (Ini)TeX this file, no plain-TeX, no LaTeX!} \expandafter\endinput\expandafter\end\fi % check for MLTeX \expandafter\ifx\csname charsubdef\endcsname\relax \message{This test file can only be used with MLTeX!} \expandafter\endinput\fi % \tracingonline=1 \tracingoutput=1 \showboxbreadth=255 \tracinglostchars=100 \tracingcharsubdef=1 \hsize=5in % % % 1. Check for bug accessing the wrong character metrics: % (in versions before Feb 1992) % \font\tenrm=cmr10\relax % % The group is only necessary, if you want to use this % test in your own macros. \charsubdefmax is saved % explicitly for very old versions of MLTeX which have % an additional bug when assigning this special integer. \begingroup \count255=\charsubdefmax \charsubdefmax=256 % enable all substitutions % very old versions of MLTeX will \charsubdef`\i=1 `\M % substitute "i" by "M" \setbox0=\hbox{\tenrm i}% <-- here \dimen0=\wd0 % get width of box (either "i" or "M") % get width of "i" \charsubdefmax=-1 % disable all substitutions \setbox0=\hbox{\tenrm i}% \dimen2=\wd0 % get width of box % restore former value of \charsubdefmax \charsubdefmax=\count255 \expandafter\endgroup \ifdim\dimen0=\dimen2\relax \immediate\write16{} \immediate\write16{..... Ok, it is not one of the oldest versions.} \immediate\write16{} \else \immediate\write16{} \immediate\write16{..... This is a very old version of MLTeX,} \immediate\write16{..... please update to the newest MLTeX version!} \expandafter\endinput\expandafter\end \fi % % % 2. Check for font loading bug: % (in versions before Dec 1995) % % - Define a \charsubdef of an existing character with % a non-existing base character % \charsubdef `A=`a 128 \message{now: \string\charsubdefmax=\number\charsubdefmax} % % - now load font (do not preload this font!!!!!!) % \immediate\write16{} \immediate\write16{..... If there will be an error "Bad metric (TFM) file",} \immediate\write16{..... please update to the newest MLTeX version!} \immediate\write16{} \font\test=cmti10\relax \immediate\write16{..... Good, no "Bad metric (TFM) file" bug,} \immediate\write16{..... seems to be a newer version.} % % % 3. Check for invalid |font_info| access: % (not fixed yet :-() % \immediate\write16{} \font\tenrm=cmr10\relax % \setbox0=\hbox{\tenrm \char`a}\dimen1=\wd0 \setbox0=\hbox{\tenrm \char`M}\dimen3=\wd0 % \charsubdef 128=`a `a \setbox0=\hbox{\tenrm \char128} \dimen0=\wd0 % get width of `a % % Now the \charsubdef is changed using % an existing base character: \charsubdef 128=`a `M \setbox0=\hbox{\unhbox0} \dimen2=\wd0 % get width of `a or `M % % And then we remove it. Then MLTeX will try to access % the 128th entry in the |char_base| array, which is % the first entry in the width index array. \charsubdefmax=-1 \setbox0=\hbox{\unhbox0}% \dimen4=\ht0 % \def\x#1\fi\fi{\fi\fi#1} \ifdim\dimen0=\dimen2\relax \ifdim\dimen0=\dimen4\relax \immediate\write16{} \immediate\write16{Congratulations, you have a MLTeX version % with all known bugs fixed.} \immediate\write16{} \x{\endinput\csname end\endcsname}% \fi\fi % \immediate\write16{} \immediate\write16{Congratulations, you have a MLTeX version % with almost all known bugs fixed.} \immediate\write16{% !! Be aware that MLTeX has atleast one known bug :-( !!} \immediate\write16{} \end % %%% END OF FILE %%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% CUT HERE _______________________________________________________________________ Bernd Raichle Email: raichle@Informatik.Uni-Stuttgart.de Institut fuer Informatik Abteilung Intelligente Systeme | "Le langage est source Universitaet Stuttgart, Breitwiesenstr. 20-22 | de malentendus" 70565 Stuttgart-Vaihingen, FRG | (A. de Saint-Exupery) ------- End of forwarded message ------- 20-Dec-1995 18:09:32-GMT,77627;000000000001 Received: from axp14.ams.org (AXP14.AMS.ORG [130.44.1.14]) by csc-sun.math.utah.edu (8.7.1/8.7.1) with ESMTP id LAA24923 for ; Wed, 20 Dec 1995 11:04:27 -0700 (MST) Received: from math.ams.org by AXP14.AMS.ORG (PMDF V4.3-10 #7286) id <01HZ0TYALXHC000GHJ@AXP14.AMS.ORG>; Wed, 20 Dec 1995 07:47:51 -0500 (EST) Received: from thphy.uni-duesseldorf.de (xerxes.thphy.uni-duesseldorf.de) by MATH.AMS.ORG (PMDF #7286 ) id <01HZ0TU5OMXSB3LC91@MATH.AMS.ORG>; Wed, 20 Dec 1995 07:47:28 EST Received: from macbeth.uni-duesseldorf.de (macbeth.thphy.uni-duesseldorf.de) by thphy.uni-duesseldorf.de (4.1/SMI-4.1) id AA04315; Wed, 20 Dec 95 13:44:15 +0100 Received: by macbeth.uni-duesseldorf.de (5.x/SMI-SVR4) id AA14785; Wed, 20 Dec 1995 13:43:52 +0100 Date: Wed, 20 Dec 1995 13:43:52 +0100 From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth) Subject: (long) Summary: METAFONT/MetaPost string length bug To: tex-implementors@MATH.AMS.ORG Cc: bnb@MATH.AMS.ORG, hobby@research.att.com Message-id: <9512201243.AA14785@macbeth.uni-duesseldorf.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit Hi Barbara, Hi TeX-implementors! enclosed you'll find a summary of the discussion following my recent bug report regarding the string length of single-character unprintable strings in METAFONT and MetaPost. After some initial discussion on this mailing list about whether the observed phenomenon is considered a bug or a feature, most of the subsequent discussion about bug fix proposals went on in private mail exchanges between Bernd Raichle, Wayne Sullivan, John Hobby, Karl Berry, and myself. Therefore, I think it's time to report our findings back to tex-implementors. In short, two different bug fixes to this problem have been developed independently by Bernd Raichle and Wayne Sullivan. As an intermediate solution, Karl Berry will implement one of them via the change file in the next release of web2c (web2c-7.0) currently under development. John Hobby will consider both bug fix proposals for a permanent solution via the WEB file when he'll get around to work on the next version of MetaPost eventually, and I think it's quite possible that DEK will follow him in 1998 in order to keep METAFONT and MetaPost in sync. (But who knows?) In order to make this summary easier to read (I hope!), I have sorted the following messages by thread rather than strict chronological order. I have edited out irrelevant material such as issues specific to web2c or MetaPost only, and I've omitted some discussion about proposals for an e-METAFONT/MetaPost since we all know that DEK doesn't want to be bothered with that anyway. (John Hobby might consider some of them.) Finally, I have taken the liberty to correct some spelling mistakes (at least mine) and some EBCDIC-to-ASCII character translation problems in some messages. In the following, my editorial comments are marked in double brackets [[ like this ]], usually used to indicate the subject of the omitted material. I hope this kind of summary is suitable for forwarding to DEK eventually, even though it is somewhat lengthy. The actual bug fix proposals can be found near the end; some intermediate versions have been omitted to avoid excessive length. Still, it's 76K, I'm very sorry! Finally, let me wish you all a merry Christmas and a happy new year, and don't forget the upcoming METAFONT history event (2 weeks from now): % Version 0 was completed on July 28, 1984. % Version 1 was completed on January 4, 1986; it corresponds to "Volume D". - Ulrik Vieth, 1995/12/20. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> String length bug in METAFONT with unprintable characters: 1.) Bug report and discussion whether or not it's a bug 2.) Comments from John Hobby 3.) Bug fix proposal from Bernd Raichle 4.) Bug fix proposal from Wayne Sullivan 5.) Summary of both proposals - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> 1.) Bug report and discussion whether or not it's a bug: From: vieth@thphy.uni-duesseldorf.de (Ulrik Vieth) Date: Mon, 27 Nov 1995 11:15:29 +0100 To: tex-implementors@MATH.AMS.ORG CC: hobby@research.att.com Following a discussion about problems with 8-bit input in MetaPost btex...etex constructs on the Metafont mailing list, I did some experimenting and found something strange. Try the following file: % File: test.mf, process with either Metafont or MetaPost % string s; s:="éo"; message("length of " & ditto & s & ditto & " = " & decimal length(s)); s:="oé"; message("length of " & ditto & s & ditto & " = " & decimal length(s)); s:="é"; message("length of " & ditto & s & ditto & " = " & decimal length(s)); s:="éé"; message("length of " & ditto & s & ditto & " = " & decimal length(s)); s:="o"; message("length of " & ditto & s & ditto & " = " & decimal length(s)); end. which produces: $ mf test.mf This is METAFONT, Version 2.718 (C version 6.1) (test.mf length of "^^e9o" = 2 length of "o^^e9" = 2 length of "^^e9" = 4 <--- ??? length of "^^e9^^e9" = 2 length of "o" = 1 ) Transcript written on test.log. $ mp test.mf This is MetaPost, Version 0.63 (C version 6.1) (test.mf length of "^^e9o" = 2 length of "o^^e9" = 2 length of "^^e9" = 4 <--- ??? length of "^^e9^^e9" = 2 length of "o" = 1 ) Transcript written on test.log. I think it is obvious that there is something wrong here. A single-character string containing a non-ASCII character is treated as a string of 4 characters in the ^^ notation, whereas a string containing non-printable characters mixed with printable characters or simply two or more non-printable characters gives the expected result. I have verified that this behaviour is not specific to Web2C. I get similar results for emTeX's mf386, except that it prints ^^? instead of ^^e9 (and pretends that it has length 3) as it doesn't seem to allow 8-bit characters in the xord/xchr tables. I've also verified that this behaviour is independent of whether the char_class of characters 127..255 is set to invalid_class, space_class, or letter_class. (In order to avoid error messages for non-ASCII characters in MetaPost btex...etex constructs, which are skipped over anyway, it appears to be necessary to change the char_class of 127..255 to something non-invalid.) [[ A better solution to this, not requiring changes to the char_class arrays has been found meanwhile, see below -- UV ]] So is this the first bug for Knuth in 1998? Anyone has a fix? BTW, it appears that the trap test doesn't catch this. - Ulrik Vieth. P.S. I've looked through the 1989 changes in tex82.bug and mf84.bug and I've noticed that Metafont doesn't seem to have anything like a |hex_to_cur_chr| routine. So could it be that this has been wrong ever since? Anyone still has a Metafont 1.x around for testing? P.P.S. Some more silly variants of the above: $ mf vieth@zarquon:~ $ mf This is METAFONT, Version 2.718 (C version 6.1) **\relax *string s; s=" "; % <-- a character *message(s & " " & decimal length(s)); ^^I 3 *string s; s=" "; % <-- two s *message(s & " " & decimal length(s)); ^^I^^I 2 *string s; s=" " & " "; % <-- two single s *message(s & " " & decimal length(s)); ^^I^^I 6 *string s; s= char(9) & char(9); *message(s & " " & decimal length(s)); ^^I^^I 2 *end. Transcript written on mfput.log. ==== From: Bernd Raichle Date: Mon, 27 Nov 1995 13:29:40 +0100 To: tex-implementors@MATH.AMS.ORG CC: hobby@research.att.com [My response to Vieth's posting on the metafont list:] Ulrik Vieth wrote: [...] > While I was tracing this down, I discovered something strange. > Try running the test file attached below through MetaPost and > ponder over the mysteries of Metafont and MetaPost. Obviously, > there's something wrong with the handling of 8-bit characters > (actually any non-printable character) in strings as well. > > % File: test.mf, process with either Metafont or MetaPost > % > string s; [...] > s:="é"; > message("length of " & ditto & s & ditto & " = " & decimal length(s)); [...] > s:="o"; > message("length of " & ditto & s & ditto & " = " & decimal length(s)); > end. > > This produces: > > $ mf test.mf > This is METAFONT, Version 2.718 (C version 6.1) > (test.mf [...] > length of "^^e9" = 4 <--- ??? [...] > length of "o" = 1 ) > Transcript written on test.log. [...] Congratulations, this is a bug in Metafont (and IMHO an old one, too, because it can also happen with other unprintable characters with codes <= 127). In mf.web Knuth uses the web macro |length| in "decimal" which takes the difference between the string start positions in the string pool to get the length of the string. What Knuth has missed was that the first 256 strings are _not_ given in their internal representation (i.e. a single character) but in the "external" x _or_ ^^xy character representation with a string length of 1, 3, or 4. An addition: message if "ä" < "a": "less" else: "not less" fi; end. (the first string is an a-umlaut = ^^e4) showing an analogous bug in MF's internal function |str_vs_str| to compare strings... and probably you can find the bug in other places using the internal macro |length|, too. -bernd member of the NTS/e-TeX group PS: Btw, there is no such bug in TeX.web, otherwise it has been found days before :-( [[ ^^^^ you mean years! -- UV ]] ==== From: KNAPPEN@VKPMZD.kph.Uni-Mainz.DE Date: Mon, 27 Nov 1995 14:31:49 +0100 To: vieth@thphy.uni-duesseldorf.de, tex-implementors@MATH.AMS.ORG, hobby@research.att.com Indeed I have access to METAFONT 1.0; and here is what it says: b$ mf This is METAFONT, Vax/VMS Version 1.0 (no base preloaded) **\relax *string s; s=" "; % *message(s & " " & decimal length(s)); ^^I 3 *end. Transcript written on $DISK2:[KNAPPEN]MFPUT.LIS;2. b$ Thus, the bug was lurking since version 1.0. --J"org Knappen ==== From: "Wayne G. Sullivan" Date: Tue, 28 Nov 1995 08:28:24 +0000 (GMT) To: tex-implementors@MATH.AMS.ORG Whether you think the value length() gives for a string in METAFONT is a "bug" or a "feature" depends on your point of view. The function length() does not give the number of characters input, but rather the number of characters in the internal representation of the string, which may differ both from the number of input characters and the number of output characters when the string is printed. Those who use characters beyond the standard ASCII values should set up their METAFONT so that it prints these as individual characters -- then the string length returns the expected value. For general distribution, it is a bad idea to use non-ASCII characters in METAFONT source, unless the character mapping is clearly indicated, because other systems may use the numerical values for a different characters. If you think it is worth the effort to modify the program so that if a single character string is input, it will be appended to the string pool, rather than assigned the existing value of the string which represents this character, then you can modify the change file to achieve this. Wayne Sullivan ==== From: Bernd Raichle Date: Tue, 28 Nov 1995 16:08:15 +0100 To: tex-implementors@MATH.AMS.ORG "Wayne G. Sullivan" wrote: > Whether you think the value length() gives for a string in METAFONT is > a "bug" or a "feature" depends on your point of view. The function > length() does not give the number of characters input, but rather the > number of characters in the internal representation of the string, which > may differ both from the number of input characters and the number of > output characters when the string is printed. Those who use characters ^^^^^^^^^ > beyond the standard ASCII values should set up their METAFONT so that ^^^^^^ ^^^^^^^^^^ > it prints these as individual characters -- then the string length > returns the expected value. [...] Nope, wrong setup (your model of the world is too simple :-). Your proposal will introduce a dependency between the result of the processing of a MF/MP input file and the local MF/MP setup ==> IMO a bug! Starting with some clarifications: TeX and Metafont/Metapost are dealing with three representations of a single character: 1) an "external" code used by the host/OS, type |text_char| in TeX/MF normally a single integer value between 0 and 255 in an OS specific code, e.g. ISO Latin-1, EBCDIC, etc. 2) a TeX/MF internal code used within TeX/MF, type |ASCII_code| in TeX/MF an single eight-bit number (a subrange of integer) between 0 and 255 in ASCII resp. an extension of ASCII ("T1") and as a very, very special kind 3) an interim representation used _only_ for the output of unprintable characters to external files or log output (this representation uses the first 256 strings in the string pool with character codes given in the TeX/MF internal code) After TeX/MF has read in characters from the input (and TeX collates ^^xy to a single character), these characters use the internal representation of type |ASCII_code| and all strings consisting only of one character have to have length 1. If I process these strings within TeX/MF, it will be a bug if the length will change (cf. \string^^J bug in TeX 3.14). At the time the string is written to the "external world" the ^^xy notation (representation 3) is used to create a printable output form of a single character in the external representation. > For general distribution, it is a bad idea > to use non-ASCII characters in METAFONT source, unless the character > mapping is clearly indicated, because other systems may use the numerical > values for a different characters. The same applies to TeX input files. Nonetheless this is __not__ the problem reported in Vieth's bug report! Please have a look into the TeX Implementors archive and look at the discussion starting with your bug report in December 1990 (tex82.bug, change 393 & 396; mf84.bug, change 558). The reported TeX bug has similarities with the one reported by Vieth... with the same confusions during the discussion of it in this list :-) > If you think it is worth the effort > to modify the program so that if a single character string is input, it > will be appended to the string pool, rather than assigned the existing > value of the string which represents this character, then you can modify > the change file to achieve this. Nope, it is IMO a bug in MF (& MP) needing some changes in mf.web. Otherwise it is possible that two MF binaries with two different definitions which characters are printable or not can produce different results for the same input file -- even if they are used on the same host! My bug fix proposal: IMO the first 256 strings should be _single_ character strings of length(1), i.e. don't use the ^^xy notation in the string pool. The transcription to ^^X resp. ^^xy for unprintable characters should be done in |print_char| immediately before the character is printed to a file or the terminal. With this change, |slow_print| can be removed and replaced by |print| ...and the bug fixes in TeX/MF mentioned above (resulting in a cheque for me :-) would have been non-existent, if DEK had done it this way from the beginning. -bernd raichle ==== From: "Wayne G. Sullivan" Date: Mon, 04 Dec 1995 12:50:10 +0000 (GMT) To: tex-implementors@MATH.AMS.ORG Upon further consideration of METAFONT's string handling problem, as noted by Vieth, I believe the behavior should be considered a "bug" and not just a "feature". The problem is that if 'X' is an unprintable character, METAFONT assigns a string of the form "^^x" to "X". If, however, one uses 'char' or substring, a single character substring for 'X' is generated, e.g., substring (0,1) of "XX". To give a valid context in which the above treatment of strings yields anomalous behaviour takes a bit of effort, because the METAFONT book specifies that MF programs should consist only of lines using visible ASCII characters and spaces. However, file names may include unprintable characters, so consider the following: def nameinput (text s) = scantokens ("input " & s) ; enddef ; If 'X.mf' is the MF file for the unprintable character 'X', then nameinput("X") does not cause 'X.mf' to be input, but nameinput(substring(0,1) of "XX") does. Wayne Sullivan ==== From: Bernd Raichle Date: Tue, 05 Dec 1995 10:00:06 +0100 To: tex-implementors@MATH.AMS.ORG "Wayne G. Sullivan" , Mon 04 Dec 1995 12:50:10 +0000 (GMT) wrote: [...] > To give a valid context in which the above treatment of strings > yields anomalous behaviour takes a bit of effort, because > the METAFONT book specifies that MF programs should consist > only of lines using visible ASCII characters and spaces. ^^^^^^^^^^^^^ [...] Really? MF programs have to be coded in ASCII? This means that I can not use MF on a host using EBCDIC? :-) The MFbook page 282 tells me that \MF\ can also be configured to accept any or all of the character codes 128--255. However, \MF\ programs that make use of anything in addition to the 95 standard ASCII characters cannot be expected to run on other systems, so the use of extended character sets is discouraged. This means that I can use characters not restricted to visible ASCII but if I use them I can not assume that the MF input file will run on another system. The same restriction applies to TeX 3.x, nonetheless a lot of people are using TeX input files with more than the 95 visible ASCII characters. (Btw. my old TeX version 2.x was already capable to input umlaut characters with code > 127. These characters were mapped to character codes < 32 using xchr/xord, they were declared printable, and in a TeX input file the \catcode of these characters < 32 were declared \active and defined to expand to \"a, etc. Before 1989/TeX 3 I had already encountered problems when I tried to give these files to a person using a different TeX implementation.) -bernd - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> 2.) Comments from John Hobby: From: hobby@research.att.com Date: Mon, 27 Nov 95 15:58 EST To: vieth@thphy.uni-duesseldorf.de, Raichle@informatik.uni-stuttgart.de, kb@cs.umb.edu This bug is probably much more significant in MetaPost than it is METAFONT. I think the simplest solution is as follows: 1. Make sure all printable characters have a char_class other than invalid_class. Most of the special characters should probably be assigned to space_class as suggested by Ulrik Vieth. 2. The first 256 strings should only use the "^^" construction for characters that are not printable. Hence I would use instead of ^^I. I don't think I need to change the version number in my master distribution since the 8-bit stuff could be considered "system dependent". - John Hobby ==== From: hobby@research.att.com Date: Mon, 27 Nov 95 16:27 EST To: vieth@thphy.uni-duesseldorf.de, Raichle@informatik.uni-stuttgart.de, kb@cs.umb.edu That last suggestion may be a little heavy-handed. It may be better to modify the code so that string numbers less than 256 are used more sparingly. s:=char 233; message("length of " & ditto & s & ditto & " = " & decimal length(s)); does generate length of "^^e9" = 1 (as it should). Using the actual 233 byte in " quotes generates string number 233 while the char construction generates a higher-numbered string containing a single 233 byte. I will try to look into this and figure out how to change the code but it will take a week or two for me to get around to it. - John Hobby ==== From: Bernd Raichle Date: Tue, 28 Nov 1995 10:14:14 +0100 To: hobby@research.att.com CC: vieth@thphy.uni-duesseldorf.de, kb@cs.umb.edu > That last suggestion may be a little heavy-handed. It may be > better to modify the code so that string numbers less than 256 > are used more sparingly. > > s:=char 233; > message("length of " & ditto & s & ditto & " = " & decimal length(s)); > > does generate > > length of "^^e9" = 1 > > (as it should). Using the actual 233 byte in " quotes generates string > number 233 while the char construction generates a higher-numbered string > containing a single 233 byte. This is another "bug"!! (or an incomplete bug fix :-) IMO it is totally unnecessary to create new strings for a new single character string. In m[fp].web the lines if length(cur_exp)<>1 then begin str_room(1); append_char(cur_exp); cur_exp:=make_string; end; in @ for |char_op| are unnecessary, because the code before it else begin cur_exp:=round_unscaled(cur_exp) mod 256; cur_type:=string_type; if cur_exp<0 then cur_exp:=cur_exp+256; ensures that |cur_exp| is between 0 and 255 (incl.). For the real fix remove them and use the first 256 string numbers. For a real fix, it will be necessary to distinguish between a string number <= 255 representing a single character string and other string numbers. An idea for a quick solution which seems to need not a lot of changes is: after creating the first 256 strings create 256 additional single character strings and use these strings instead of the former 256. This doesn't work because tangle creates the pool file and string numbers in this region. You have to use 256 string numbers starting with the next free string number _after_ the pool file was read in. IMHO a better idea (for mf, mp, and tex) is to use __single__ character strings without ^^xy as the first 256 strings and to create the ^^xy notation during the text output, i.e. in the |print_char| routine. I have already done this for TeX, and it can be used for MF/MP because of the similarity in code. With this setup the changes are restricted to a minimum... and it will also remove the necessity of |slow_print| because all output to the external world is done "slowly" :-) > I will try to look into this and figure out how to change the code but > it will take a week or two for me to get around to it. Just have to look in my archive to find this old change. (I have done it to test codepage changes "on the fly" after the pseudo print bug for printable/unprintable characters were fixed in TeX 3.141). -bernd PS: Karl, this can also be integrated in new web2c simplifying the code in the TeX change file which moves the strings if a different "codepage" definition with changes in the set of printable characters is read. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> 3.) Bug fix proposal from Bernd Raichle: From: Bernd Raichle Date: Wed, 29 Nov 1995 09:21:48 +0100 To: hobby@research.att.com, vieth@thphy.uni-duesseldorf.de, kb@cs.umb.edu John wrote: > I will try to look into this and figure out how to change the code but > it will take a week or two for me to get around to it. Yesterday evening I have re-implemented my changes for the Amiga PasTeX TeX implementation and created a WEB change file for TeX. I hadn't the time to test it in detail, but it compiles without errors, passes the trip test, and some quick&dirty tests. The change file is made for TeX.web (I hadn't the time to create one for MF/MP _and_ test it!), nonetheless the adaptions needed for MF or MP are straightforward because there are only minor differences between tex.web and mf.web (i.e. no \newlinechar, but a string reference counter in MF/MP). I have included comments in the change file to show these adaption in principle. After applying these change file the first 256 strings of the string pool are single character strings of length 1, and the conversion to ^^xy is done in the print routines immediately before a character is written to the external world. Therefore the restriction that a change of the predicate @ needs some changes in the string pool is removed, allowing "codepage" switches "on the fly". I.e., it is now possible to change xchr/xord/ which-characters-are-printable during one TeX run (if this makes any sense, e.g. your operating systems allow different character coding schemes) without any additional changes in the string pool handling. Only xchr/xord and the predicate @ has to be changed accordingly. Ok, can one of you have a look at it and test it with MF/MP? I don't have enough time (and knowledge!) about MF/MP. Thanks, Bernd PS: Disadvantage of this change: The new print routine are not as fast as the old ones, because the conversion char=>^^xy isn't precomputed any more. If this will be a problem, I propose to introduce a second "string pool" array only containing the 256 strings which are the representation of a single character if printed to the output, i.e. separate the different use of these two kind of strings ("normal" strings vs. single character representations on output). PPS: Karl, these changes will simplify the web2c-6.94-pretest TeX change file removing the need to recreate the first 256 strings if the user specifies a codepage definition! % Changefile for TeX Version 3.14159 (and 3.141, 3.1415) % Replaces string pool representation and output routines % for single character strings. % % (C) 1993,1995 by Bernd Raichle % Email: raichle@Informatik.Uni-Stuttgart.de % % Changelog: % 10/93 Version 1.0 % Changes in C source for PasTeX/brTeX % 11/95 Version 1.1 % Reimplementation as WEB change file % % For METAFONT (Version 2.718) these changes have to be adapted % to mf.web. I have included the adaption in principle in comments. [[ merged in a small correction send by Bernd shortly afterwards -- UV ]] @x [4.48] l.1252 -- do not create "^^xy" in string pool @ @d app_lc_hex(#)==l:=#; if l<10 then append_char(l+"0")@+else append_char(l-10+"a") @y @ The first 256 strings will consist of a single character only. @z @x [4.48] l.1257 begin if (@) then begin append_char("^"); append_char("^"); if k<@'100 then append_char(k+@'100) else if k<@'200 then append_char(k-@'100) else begin app_lc_hex(k div 16); app_lc_hex(k mod 16); end; end else append_char(k); g:=make_string; @y begin append_char(k); g:=make_string; @z % === Change for MF === ... g:=make_string; str_ref[g]:=max_str_ref; %@y begin append_char(k); g:=make_string; str_ref[g]:=max_str_ref; %@z @x [4.49] l.1272 -- change documentation (probably needed in more places) would like string @'32 to be the single character @'32 instead of the @y would like string @'32 to be printed as the single character @'32 instead of the @z @x [5.58] l.1460 -- replace |print_char| by |print_visible_char| @ The |print_char| procedure sends one character to the desired destination, using the |xchr| array to map it into an external character compatible with |input_ln|. All printing comes through |print_ln| or |print_char|. @= procedure print_char(@!s:ASCII_code); {prints a single character} label exit; begin if @ then if selector= procedure print_visible_char(@!s:ASCII_code); {prints a single character} label exit; @z % == Change for MF == % delete in @x..@y part: begin if @ then if selector= procedure print_char(@!s:ASCII_code); {prints a single character} label exit; var k:ASCII_code; @!l:0..255; begin if @ then if selector then begin if selector>pseudo then begin print_visible_char(s); return; end; print_visible_char("^"); print_visible_char("^"); if s<64 then print_visible_char(s+64) else if s<128 then print_visible_char(s-64) else begin print_lc_hex(s div 16); print_lc_hex(s mod 16); end; end else print_visible_char(s); exit:end; @z % == Change for MF == % 1. replace in @x..@y and @y...@z part: exit:end; % by: end; % % 2. replace in @y..@z part: begin if @ then if selector then % by: begin k:=s; if @ then % @x [5.59/60] l.1501 -- simplify |print| and remove |slow_print| assumes that it is always safe to print a visible ASCII character.) @^system dependencies@> @y assumes that it is always safe to print a visible ASCII character.) @^system dependencies@> Old versions of \TeX\ needed a procedure called |slow_print| whose function is now subsumed by |print|. We retain the old name here as a possible aid to future software arch\ae ologists. @d slow_print == print @z @x [5.59/60] l.1508 -- simplify processing of |new_line_char| @!nl:integer; {new-line character to restore} @y @z @x [5.59/60] l.1513 -- simplify processing of |new_line_char| else begin if selector>pseudo then begin print_char(s); return; {internal strings are not expanded} end; if (@) then if selectorpseudo) then print_char(s) %@y if (s<256) then print_char(s) else if (selector>pseudo) then print_char(s) %@z @x [5.60/-] l.1534 -- remove |slow_print| @ Control sequence names, file names, and strings constructed with \.{\\string} might contain |ASCII_code| values that can't be printed using |print_char|. Therefore we use |slow_print| for them: @= procedure slow_print(@!s:integer); {prints string |s|} var j:pool_pointer; {current character code position} begin if (s>=str_ptr) or (s<256) then print(s) else begin j:=str_start[s]; while jFrom vieth Mon Dec 4 10:41:16 +0100 1995 To: Raichle@informatik.uni-stuttgart.de CC: hobby@research.att.com, kb@cs.umb.edu Bernd wrote: > Ok, can one of you have a look at it and test it with MF/MP? I don't > have enough time (and knowledge!) about MF/MP. OK, this weekend I found time to adapt your change file for MF/MP. After compiling, I've verified that they both pass their respective trap tests (which involved spending quite some time figuring out how the differences in the string usage statistics can be accounted for). I've did some ad hoc test to test that the previously buggy behaviour concerning the length of strings was corrected now, i.e. strings like "ä" (printed as "^^e4") now have the length one as expected. I've verified that the behaviour of unprintable characters in strings hasn't changed in contexts like |message|, |special|, and for MetaPost also |write| files, i.e. 8-bit chars are printed in the ^^ notaton in |message| and |write|, but are passed through unchanged in |special| (even though the PostScript interpreter might not like them). Of course, I've also tested that "ini{mf,mp} plain" works as usual. Finally, I've tested some real-world applications: I've run cmr10.mf through Metafont and compared the result with my existing fonts using tftopl and pktype. I've also tested examples.mp from metapost/doc. All in all, I'm pretty confident that the bug fix is OK now. Some notes: * in |print_char| I've added an extra shortcut to |print_visible_char| for an important case that's present only in the MetaPost version: ! begin ! if selector=ps_file_only then {assume it's safe} ! begin print_visible_char(s); return; ! end; ! k:=s; if @ then (You'll also need the lines |label exit;| and |exit:end;| since WEB's |return| is defined as |goto exit|.) I have no idea whether this really has much of an effect on speed, but since the PostScript output routines check their arguments themselves before calling one of the |print| routines, it would be unnecessary to check again here in any case. (Actually, routines like |ps_string_out| have to perform quite a different conversion from "ä" to "\344", so it wouldn't make sense if they were converted to "^^e4" notation.) * for the |print| routine, Bernd suggested the following: % == Change for MF == % remove last change above and add this one instead: %@x if (s<256)and(selector>pseudo) then print_char(s) %@y if (s<256) then print_char(s) else if (selector>pseudo) then print_char(s) %@z However, this is a bug, because it has the effect that |print_char| can be called if (selector>psedo) even if (s>=256). In my tests, this had the effect of breaking "inimf plain" somewhere in the middle and producing some funny characters in file names in the trap test such as trap.72270 instead of trap.72270gf. I've fixed that as follows: ! @x ! if (s<256)and(selector>pseudo) then print_char(s) ! @y ! if (s<256) then print_char(s) ! @z This allows the shortcut to |print_char| for (s<256) in all cases, independently of whether (selector>psedo), since the first 256 strings are now always single-character strings that are converted when necessary by the |print| routine. Some odd obsevations: [[ discrepancies between MetaPost's |print| and |slow_print| ]] [[ observation that MetaPost doesn't have shortcut in |print_char| |if (s<256)and(selector>pseudo) then ...| as in MF -- why not? ]] [[ potentially dangerous use of in MetaPost's |ps_string_out| when character set is extended ]] [[ differences in trap test string usage statistics in web2c version due to some editing mistake in Karl's change file ]] Concerning the trip test results: * For MF, I get a difference in the string usage amounting to 450 more pool characters left untouched (compared to Karl's results). This number can be fully accounted for by Bernd's new allocation scheme for the first 256 strings, since 450 = 3 * 128 + 2 * 33. * For MP, I first get the same difference of 450 characters at the beginning of mtrap.log, but later (following l.953) I also get some differences in the number of strings used since the line string EOF; EOF = char0; doesn't produce a new string of length one; instead it re-uses an existing string which was previously represented as "^^@". Due to the savings of 450 pool characters, the code that's supposed to trigger the string pool compactation routine produces different results. It fails to free as much space as it did before, but at least the offset remains a constant. Maybe, I should try another trap test with pool_size reduced by 450 for comparison. Similar differences also occur in the subsequent steps of the trap test. In mptrapin.log, I get a difference of 450 + 27 bytes and one string less compared to Karl's result (see note above) for the total string usage after dumping the trap.mem file. Finally, in mptrap.fot and mptrap.log, I get a savings of 450 + 3 pool characters and 3 strings less, which is probably due to the same reason as above for mtrap.log. However, in this case I haven't tried to find out which 3 single character strings cause the difference. trap.mp is simply too weird for that. [[ char_class of unprintable characters affects trap test results ]] OK, that's it, I think. I'll send the actual change file patches in a separate message. If you think everything is OK now, I'll send a summary of the whole story to Barbara in a few days for forwarding to Knuth by 1998. Cheers, Ulrik. Before I finish off, let me summarize a list of e-MF/MP requests I've thought of recently: [[ omitted for a good reason ]] ==== >From vieth Mon Dec 4 10:51:16 +0100 1995 To: Raichle@informatik.uni-stuttgart.de CC: hobby@research.att.com, kb@cs.umb.edu Here are my patches for mp.ch and mf.ch. They are based on Karl's original texk-6.94 change files, so they also contain some other stuff that's not directly relevant to the string pool changes. [[ omitted, see final version at the end of summary -- UV ]] ==== From: Bernd Raichle Date: Mon, 4 Dec 1995 12:27:21 +0100 To: vieth@thphy.uni-duesseldorf.de CC: hobby@research.att.com, kb@cs.umb.edu Ulrik, great work! Thanks for testing the changes and creating appropriate changes for mf/mp.web. I will have a look into your changes and your comments the next days, ok? Note: For the final change of mf/mp.web it is possible to remove the conditional |if length(cur_exp)<>1 ...| in the code for case "char_op:" in @. With the new string pool changes |length(cur_exp)<>1| is false for all |cur_exp| with |0<=cur_exp<256|. This code shows that DEK was aware of the fact that a single character string can be of length<>1. Does someone know where I can get an older MF version (before version 2.0) to have a look at the code dealing with the length of single character strings? When and why did DEK add the condition |if length(cur_exp)<>1 ...| for "char_op:"? I can only find these two entries in mf84.bug (ignoring really old entries) mentioning problems with unprintable characters: 402. char 127 to be a string of length 1; slow_print added (therefore). 558. Allow unprintable file names, as in TeX change 396 (19 Sep 91) (Much of this is redundant except for people who make nonportable versions that allow other 8-bit codes to be in variable names---and for those people only if they allow input of more codes than they can print! Still, it seems best to make the programs for TeX and MF as alike as possible.) Change 402 (MF 0.4->0.5) makes me think that older versions of MF assumes that a one character string containing the unprintable character 127 ("^^?") has length 1. When and _why_ has DEK changed this? The comment in change 558 (and three lines in the MFbook) sanctions the use of characters with codes >=128 in the mf input. -bernd PS: Perhaps I should mail these questions to the "TeX Implementors" list? ==== >From vieth Mon Dec 4 13:43:25 +0100 1995 To: Raichle@informatik.uni-stuttgart.de CC: hobby@research.att.com, kb@cs.umb.edu Bernd wrote: > This code shows that DEK was aware of the fact that a single character > string can be of length<>1. Does someone know where I can get an > older MF version (before version 2.0) to have a look at the code > dealing with the length of single character strings? I did a quick archie search for mf.web, but I found nothing older than what corresponds to TeX 3.0. I have also preserved an old TeX3.0.tar.Z (apparently from a tape distrubtion), that I found lying around in an archive directory here. However, that's also MF 2.0, so it won't help. Maybe you could try asking Joerg, since he had a running MF 1.0 and he tends to keep lots of old stuff. Maybe he's got the source as well. And if that also fails, you might still try asking Barbara, whose archives must be truly amazing. > PS: Perhaps I should mail these questions to the "TeX Implementors" > list? Maybe we should start a move to gather historic stuff somewhere on CTAN before it is too late? People always tend to throw away old stuff as soon as new versions appear, and by the time one needs an old version for comparison it might be too late. Fortunately, at least the history of TeX is documented slightly better than MF. Cheers, Ulrik. ==== From: Bernd Raichle Date: Tue, 05 Dec 1995 09:39:54 +0100 To: tex-implementors@MATH.AMS.ORG In collaboration with Ulrik Vieth and John Hobby, we have created necessary changes to clean up the string pool/output code (|print_char|, |print|, |slow_print|) in MF/MP.web to remove the implementation dependent behaviour of the current MF/MP version when dealing with unprintables characters. These changes can be applied to TeX.web, too. Ulrik will post a summary in a few days... (Ulrik?) While trying to understand DEK's design of the current output routines in TeX and MF using my archives, I have a few questions which, I hope, can be answered by someone on this list: 1.) MF.Web, section @: The condition |length(cur_exp)<>1| for the case |char_op:| (i.e. MF's "char" primitive) shows that DEK had encountered some "funny" behaviour with single character strings of length <> 1. This was the fix for it: if the corresponding string cur_exp < 256 has length <> 1, create a new string of length 1. (IM_H_O this was a quick&dirty fix) Did someone know when DEK has introduced this test for "char"? Does it exists from the beginning of the "char" primitive? ==> Has someone older versions of "mf.web"? What do you think of an archive containing older TeX and MF sources? 2.) mf84.bug I can only find the following entries in mf84.bug (ignoring really old entries) mentioning problems with unprintable characters: 402. char 127 to be a string of length 1; slow_print added (therefore). Change 402 (MF version 0.4->0.5) makes me think that older versions of MF assumes that a one character string containing the unprintable character 127 ("^^?") had length 1. When and _why_ has DEK changed this? Any reason why he only mentioned a change for 127 but not for one of the other characters < 32? And this entry. It is an addition to my response to Wayne Sullivan's posting on Tuesday, 28 Nov 1995, why I think that the reported behaviour is a bug in MF.web: 558. Allow unprintable file names, as in TeX change 396 (19 Sep 91) (Much of this is redundant except for people who make nonportable versions that allow other 8-bit codes to be in variable names---and for those people only if they allow input of more codes than they can print! Still, it seems best to make the programs for TeX and MF as alike as possible.) In "errata.five" we can find the following change in MFbook: \bugonpage C282, the three lines following the chart (9/30/89) \MF\ can also be configured to accept any or all of the character codes 128--255. However, \MF\ programs that make use of anything in addition to the 95 standard ASCII characters cannot be expected to run on other systems, so the use of extended character sets is discouraged. IMO the comment in change 558 (and the additional lines in the MFbook) gives DEK's sanction to all changes allowing characters with codes >=128 in an MF input file. If these characters are allowed, strings using them should have an appropriate length, __independent__ of the declared set of printable characters. Example: You can have two implementations which allow the input of all 8-bit characters. The first one declare all but the 95 standard ASCII characters as unprintable, in the second one national characters >=128 are declared printable. Now compare the result of length(char 228) and length("ä") (<= there is an a-umlaut character having code 228 in ISO Latin-1). You will assume that they will return 1 on both implementations, won't you? -bernd ==== From: hobby@research.att.com Date: Mon, 4 Dec 95 11:41 EST To: vieth@thphy.uni-duesseldorf.de CC: Raichle@informatik.uni-stuttgart.de, kb@cs.umb.edu I greatly appreciate your work on the 8-bit character problem, but I would like to point out one serious problem with the changes you just sent. (I'll send more comments later--I want to get this to you right away.) [[ explanation of discrepancies between |print| and |slow_print| in MetaPost: just an old typo that was fixed in version 0.631 ]] ==== From: hobby@research.att.com Date: Mon, 4 Dec 95 11:42 EST To: vieth@thphy.uni-duesseldorf.de CC: Raichle@informatik.uni-stuttgart.de, kb@cs.umb.edu Here are the remaining comments on your message about changes to allow 8-bit input: I think some of the changes really belong in the web file instead of the ch file. I guess I won't put them there now, but I would like to do that next time I do a new version. [...] [[ use of in PostScript ]] [[ char_class of unprintable characters ]] [[ comments on e-MetaPost suggestions, newlinechar? ]] ==== Date: Tue, 5 Dec 1995 20:12:02 -0500 From: "K. Berry" To: hobby@research.att.com CC: vieth@thphy.uni-duesseldorf.de, Raichle@informatik.uni-stuttgart.de [[ char_class of unprintable characters ]] ==== From: Bernd Raichle Date: Thu, 7 Dec 1995 15:30:49 +0100 To: vieth@xerxes.thphy.uni-duesseldorf.de CC: hobby@research.att.com Ulrik's notes to my suggestions how to adapt the proposed TeX changes to MF/MP seems to be ok. I had no time to test it for myself, but have looked into the code to decide if they will do the things we want them to do. Here are some additional notes I have made. [[ minor documentation fixes ]] [[ char_classes, suggestion of codepage support? ]] [[ use of in PostScript ]] -bernd ==== >From vieth Thu Dec 7 15:56:08 +0100 1995 To: Raichle@informatik.uni-stuttgart.de CC: hobby@research.att.com Bernd wrote: > Why not add "codepage" support to MP as it is done for TeX in which > the user can set the class of characters >= 128? During the Trip/Trap > test a special codepage can be loaded. Might be a good idea, but maybe the changes of the char_class arrays could be avoided at all, if |get_next| could be changed so that the error message for invalid characters isn't triggered when |scanner_status=tex_flushing|. (After all, the troublesome point is that MP complains about invalid characters appearing in text between btex ... etex that's ignored anyway, since it has already been interpreted and processed by the preprocessor, and it's just scanning ahead to find the matching `etex'.) However, since |get_next| is inner loop, one should be very careful about changes there. [[ use of in PostScript ]] Cheers, Ulrik. ==== >From vieth Fri Dec 8 11:24:25 +0100 1995 To: hobby@research.att.com CC: kb@cs.umb.edu [[ Better solution to handle invalid characters in btex..etex without requiring changes to MetaPost's char_class arrays: ]] ---- @x [29.629] Allow invalid 8 bit codes when |tex_flushing| invalid_class: @; @y invalid_class: if scanner_status=tex_flushing then goto switch else @; @z ---- P.S. Just to make it clear again: This problem of invalid codes is completely unrelated to the string length bug. I just discovered that bug while I was experimenting with 8-bit codes precisely to find out why MetaPost complained in btex...etex, but not in strings used in combination with the `infont' operator. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> 4.) Bug fix proposal from Wayne Sullivan: From: "Wayne G. Sullivan" Date: Thu, 07 Dec 95 11:39:18 +0000 (GMT) To: Ulrik Vieth [[ character translation problems corrected -- UV ]] The following additional change to texk-6.95/web2c/mf.ch will resolve MF's problem with single unprintable character strings, without causing any other modification of the behavior of the program: (simple diff:) 917,922d916 < @x 14021 m.671 < if loc=k+1 then cur_mod:=buffer[k] < @y 14021 < if (loc=k+1) and (length(buffer[k])=1) then cur_mod:=buffer[k] < @z < ==== >From vieth Thu Dec 7 13:16:14 +0100 1995 To: WSULIVAN@IRLEARN.UCD.IE Wayne Sullivan: > The following additional change to texk-6.95/web2c/mf.ch will resolve > MF's problem with single unprintable character strings, without causing > any other modification of the behavior of the program: (simple diff:) --- 917,922d916 < @x 14021 m.671 < if loc=k+1 then cur_mod:=buffer[k] < @y 14021 < if (loc=k+1) and (length(buffer[k])=1) then cur_mod:=buffer[k] < @z < --- Thanks, I'll try that (or at least have a closer look at it to see how it fits in and what it does). BTW, what kind of encoding did you use in your mail? I guess that `buffer Ohungarumlaut k thorn' is supposed to mean `buffer[k]'. Right? Ulrik. === From: "Wayne G. Sullivan" Date: Thu, 07 Dec 95 15:59:37 +0000 (GMT) To: Ulrik Vieth [[ character translation problems corrected -- UV ]] The machine which will mail this uses EBCDIC encoding. Your reply to my note came back with 917,922d916 < @x 14021 m.671 < if loc=k+1 then cur_mod:=buffer[k] < @y 14021 < if (loc=k+1) and (length(buffer[k])=1) then cur_mod:=buffer[k] < @z which bracket "k" by "U" and "tilde". This illustrates the problem of national and super-national (IBM) character sets. Before I had ftp access, it was worse because even uuencoded files required were decipherable only with special care. If the above change does not resolve you string problems, please let me know. I believe only module 671 causes problems. Of course it would be better if there were an accepted international character mapping, so that all would be able to see accented characters as the author intends them, but if the code works, even if it looks strange, that is the most important thing. There have been some operating systems of late which look beautiful; sadly, their performance does not match their looks. Wayne Sullivan ==== From: Bernd Raichle Date: Thu, 7 Dec 1995 14:39:09 +0100 To: WSULIVAN@IRLEARN.UCD.IE CC: vieth@thphy.uni-duesseldorf.de You wrote: > The "bug" is due to the way current versions of MF treat single character > strings which are input using double-quote notation. It has nothing to do > with string length. The bug is due to the way current versions of MF (and TeX) treat strings in the string pool. 1) The first 256 strings are not treated as "normal" strings for internal use, but as a character transcription table for text output. This means that IMHO they should not be used for any other purpose like string concatenation, length(), etc. (And if they are used you should do it with a lot of care otherwise the result will be unpredictable! Cf. |print| and the introduction of |slow_print|, the newer changes 393,396,403 in TeX and 558 in MF and a lot of older changes before TeX 3.0/MF 2.0.) 2) All other strings |s>255| are "normal" strings in the sense that all string operations can be done and the result will be predictable and independent of the current implementation. If DEK would have made the decision that he splits the string pool in two independent parts for the two different uses of the strings in the string pool, IMO he would have avoided a lot of bugs introduced by code like |slow_print|, optimizations in |print_char|, |print|, etc. For a proper design I would implement two "string" pools, the first one is a an array with 256 "strings" representing the external transcriptions of the 256 characters, the second one is a string pool containing strings which can be manipulated without care (the first 256 strings of this string pool will be single character strings of length 1). > The following change will eliminate it completely > without having to make any other changes in MF: > @x > if loc=k+1 then cur_mod:=buffer[k] > else begin str_room(loc-k); > @y > begin str_room(loc-k); > @z This seems to be another fix for Vieth's bug which is simpler than the one I have proposed. Btw. it can be optimized :-) to if loc=k+1 and length(buffer[k])=1 then cur_mod:=buffer[k] else begin str_room(loc-k); (untested!) One thing is remarkable about you fix: you try to avoid the first 256 "strings" and make a new string for a single character. 1. Question: Why not use one the first 256 strings? Why do we have to distinguish between strings in the string pool? 2. Question: Are you really sure that there is no other bug hidden in the routines dealing with strings, string pool, etc.? > Though the other string handling procedures in TeX/MF may not be the most > elegant, they have been remarkedly relieble -- can you guarantee that ^^^^^^^^^^^^^^^^^^^ oh! |slow_print|?! > your proposed changes will not introduce other problems? IMHO yes, because of two reasons: 1. I only change the first 256 strings into single character strings. If this invalidates any other piece of code in TeX/MF, it will be another bug because it is allowed to declare almost all characters printable. 2. All printing comes through |print_ln| or |print_char|. (quoted from TeX.web/MF.web!) The new routines are simpler than the older ones, additionally I can assume that all strings in the string pool can be used as strings (without any differentiation between "X" and "^^X", or taking care of the \newlinechar). Take a look at the old routines, then at the new ones... and then tell me which are easier to understand. > TeX and METAFONT are entirely different programs, though Knuth used a > number of common procedures. Both use the same basic string handling routines and string/character output routines... with the same bugs! > TeX is a language processor, so should be > able to use local alphabets. MF is a drawing program -- it could use any > character set, but it is convenient to stick with the original for > portability. Regarding TeX and national character sets: some versions of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > TeX provide utilities to convert to ^^XX notation for transfer between > systems. I would not have written one if I did not think it useful. ...this is the reason why bugs in the string pool are found in TeX and not in MF. If MF would have the ability to write additional text files, I'm sure that some of the bugs would have been found in MF first. (Vieth has found the bug in MF because he has played around with Metapost's btex...etex feature and its problems with national characters.) -bernd ==== >From vieth Thu Dec 7 15:38:00 +0100 1995 To: Raichle@informatik.uni-stuttgart.de CC: WSULIVAN@IRLEARN.UCD.IE Bernd wrote: > This seems to be another fix for Vieth's bug which is simpler than the > one I have proposed. Btw. it can be optimized :-) to > > if loc=k+1 and length(buffer[k])=1 then cur_mod:=buffer[k] > else begin str_room(loc-k); > > (untested!) This is more or less exactly what Wayne Sullivan suggested to me (except that you have to add parentheses to get it right): ! if (loc=k+1) and (length(buffer[k])=1) then cur_mod:=buffer[k] ! else begin str_room(loc-k); > > TeX is a language processor, so should be > > able to use local alphabets. MF is a drawing program -- it could use any > > character set, but it is convenient to stick with the original for > > portability. Regarding TeX and national character sets: some versions of > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > TeX provide utilities to convert to ^^XX notation for transfer between > > systems. I would not have written one if I did not think it useful. > ...this is the reason why bugs in the string pool are found in TeX and > not in MF. If MF would have the ability to write additional text > files, I'm sure that some of the bugs would have been found in MF > first. (Vieth has found the bug in MF because he has played around > with Metapost's btex...etex feature and its problems with national > characters.) ... precisely because MetaPost is a drawing program like MF with additional typesetting features not quite like TeX, but requiring access to arbitrary 8-bit character sets. [[ BTW, MetaPost does have a `write' file operator! ]] Actually, there are two different appraoches: 1.) at a very basic level, directly producing PostScript `fshow' commands without further reencoding: draw ("string" infont "fontname" scaled ... shifted ..., coordinate_pair); 2.) using a preprocessor that invokes TeX for typesetting and dvitomp to tranlate the typeset output into a low-level MetaPost code like above: (makempx shell script: mpto -tex -> tex -> dvitomp -> mpx file -> MP) btex etex In case 1. it's important to be able to use any 8-bit code within strings and to get the correct length when doing fancy things such as typesetting on a curve. [[ ... and splicing strings with `substring' or putting single-character strings together, etc. ]] In case 2. it's sufficient to be able to pass through any 8-bit code without interpreting it. This is why the changes of char_class tables to something non-invalid are necessary in order to avoid error messages. [[ this is no longer needed due to better solution, see above -- UV ]] (MP switches to the .mpx file when it reads `btex', invoking makempx when necessary, and switches back to the .mp file after `mpxbreak'. Then it has to scan forward, ignoring all text up to the next `etex', and it's during this when characters with char_class=invalid_class trigger error messages, even though the text is ignored, since it has been interpreted and processed already by the preprocessor.) Hope this helps to clarify things. Cheers, Ulrik. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> 5.) Summary of both proposals: >From vieth Mon Dec 11 11:40:04 +0100 1995 To: kb@cs.umb.edu CC: raichle@informatik.uni-stuttgart.de, hobby@reseach.att.com After preparing some general clean-up patches for {mf,mp}.ch as posted to tex-pretest, I've now updated the actual bug fixes for {mf,mp}.ch based on the texk-6.95 version. I've actually tried and tested two different bug fix approaches: 1.) a somewhat involved fix proposed by Bernd Raichle as already discussed last week. This involves changing the string pool so that the first 256 strings are stored as single characters. The |print_char| routine is then renamed to |print_visible_char| and a new |print_char| routine is added that does the translation to "^^xy" notation upon output. (For MP, I've added a special shortcut if |selector=ps_file_only|.) With these changes it's possible to simplify |print| and combine it with |slow_print|. It's also possible to remove a redundant length check in the code for |char_op| since strings created by `char xyz' can reuse one of the first 256 strings which always have length one now. 2.) a simpler quick & dirty fix proposed by Wayne Sullivan that just adds an extra length check to so that a new string is created for an unprintable single character rather than reusing one of the first 256 strings that are stored in "^^xy" notation. This fix is similar to the present code for |char_op|, which is presumably also a quick & dirty fix introduced by Knuth in an early version of MF. Change 1 is potentially more useful if anyone wants to add codepage switching to MF/MP, since it avoids the need to readjust the bottom of the string_pool since the first 256 characters always occupy the same amount of space, i.e. 256 byte rather than 95 + 33*3 + 128*4. However, change 1 will also lead to differences in the trap test statistics as mentioned last week. There will be a savings of 450 pool characters (+/- 1 for the length of the date string) and also some differences in the total number of strings due to the fact that strings s<256 will be reused for single character strings created with char xyz. Change 2 doesn't seem to affect the trap test results since the trap test apparently doesn't test the case of unprintable single character strings entered as "^^e4". If it would, you'd probably get a little increase in the string usage due to extra strings of length one. To minimize the differences in the MP trap test statistics, it's best to set pool_size.mp=31991 in web2c/triptrap/texmf.cnf. For change 2 this should be reduced by another 450, i.e. use 31541 in order to get a similar behaviour for the test of string pool compaction in mtrap.mp. In the changes below, I've changed inf_pool_size in mp.ch accordingly to make this possible since any value of pool_size below 32000 is presently ignored. As far as I've tested, both changes are OK. Now it's a question of taste, conceptual clarity, etc. which change you prefer. Cheers, Ulrik. Appended below are two sets of changes: 1.) Following Bernd's proposal: diff -c mf.ch mf.ch1 diff -c mp.ch mp.ch1 2.) Following Wayne's proposal: diff -c mf.ch mf.ch2 diff -c mp.ch mp.ch2 Don't apply both of these sets of changes at the same time! ================ diff -c mf.ch mf.ch1 *** mf.ch Sun Dec 10 21:15:39 1995 --- mf.ch1 Sun Dec 10 22:20:44 1995 *************** *** 448,453 **** --- 448,481 ---- end; @z + @x [4.48] l.1219 -- do not create "^^xy" in string pool + @ @d app_lc_hex(#)==l:=#; + if l<10 then append_char(l+"0")@+else append_char(l-10+"a") + @y + @ The first 256 strings will consist of a single character only. + @z + @x + begin if (@) then + begin append_char("^"); append_char("^"); + if k<@'100 then append_char(k+@'100) + else if k<@'200 then append_char(k-@'100) + else begin app_lc_hex(k div 16); app_lc_hex(k mod 16); + end; + end + else append_char(k); + g:=make_string; str_ref[g]:=max_str_ref; + @y + begin append_char(k); + g:=make_string; str_ref[g]:=max_str_ref; + @z + + @x [4.49] l.1239 -- change documentation (probably needed in more places) + would like string @'32 to be the single character @'32 instead of the + @y + would like string @'32 to be printed as the single character @'32 instead + of the + @z + % [4.51] Open the pool file using a path, and can't do string % assignments directly. (`strcpy' and `strlen' work here because % `pool_name' is a constant string, and thus ends in a null and doesn't *************** *** 499,504 **** --- 527,623 ---- @!trick_buf:array[0..ssup_error_line] of ASCII_code; {circular buffer for @z + @x [5.58] l.1420 -- rename |print_char| to |print_visible_char| + @ The |print_char| procedure sends one character to the desired destination, + using the |xchr| array to map it into an external character compatible with + |input_ln|. All printing comes through |print_ln| or |print_char|. + + @= + procedure print_char(@!s:ASCII_code); {prints a single character} + @y + @ The |print_visible_char| procedure sends one character to the desired + destination, using the |xchr| array to map it into an external character + compatible with |input_ln|. (It assumes that it is always called with + a visible ASCII character.) + + @= + procedure print_visible_char(@!s:ASCII_code); {prints a single character} + @z + + @x [5.58/59] l.1447 -- insert new |print_char| procedure + incr(tally); + end; + @y + incr(tally); + end; + + @ The |print_char| procedure sends one character to the desired destination. + File names and string expressions might contain |ASCII_code| values that + can't be printed using |print_visible_char|. These characters will be + printed in three- or four-symbol form like `\.{\^\^A}' or `\.{\^\^e4}'. + All printing comes through |print_ln| or |print_char|. + + @d print_lc_hex(#)==l:=#; + if l<10 then print_visible_char(l+"0")@+else print_visible_char(l-10+"a") + + @= + procedure print_char(@!s:ASCII_code); {prints a single character} + label exit; + var k:ASCII_code; + @!l:0..255; {small indices or counters} + begin + k:=s; if @ then + begin if selector>pseudo then + begin print_visible_char(s); return; + end; + print_visible_char("^"); print_visible_char("^"); + if s<64 then print_visible_char(s+64) + else if s<128 then print_visible_char(s-64) + else begin print_lc_hex(s div 16); print_lc_hex(s mod 16); + end; + end + else print_visible_char(s); + exit:end; + @z + + @x [5.59/60] l.1455 -- simplify |print| and remove |slow_print| + assumes that it is always safe to print a visible ASCII character.) + @^system dependencies@> + @y + assumes that it is always safe to print a visible ASCII character.) + @^system dependencies@> + + Old versions of \MF\ needed a procedure called |slow_print| whose function + is now subsumed by |print|. We retain the old name here as a possible aid + to future software arch\ae ologists. + + @d slow_print == print + @z + @x + if (s<256)and(selector>pseudo) then print_char(s) + @y + if (s<256) then print_char(s) + @z + + @x [5.60] l.1471 -- remove |slow_print| + @ Sometimes it's necessary to print a string whose characters + may not be visible ASCII codes. In that case |slow_print| is used. + + @= + procedure slow_print(@!s:integer); {prints string |s|} + var @!j:pool_pointer; {current character code position} + begin if (s<0)or(s>=str_ptr) then s:="???"; {this can't happen} + @.???@> + if (s<256)and(selector>pseudo) then print_char(s) + else begin j:=str_start[s]; + while j1 then + begin str_room(1); append_char(cur_exp); cur_exp:=make_string; + end; + end; + @y + else begin cur_exp:=round_unscaled(cur_exp) mod 256; cur_type:=string_type; + if cur_exp<0 then cur_exp:=cur_exp+256; + end; @z @x [42.965] A C casting problem. diff -c mp.ch mp.ch1 *** mp.ch Sun Dec 10 22:17:32 1995 --- mp.ch1 Sun Dec 10 22:21:09 1995 *************** *** 510,515 **** --- 510,543 ---- @!str_ref:^str_ref_type; {web2c only does |^identifier|} @z + @x [4.63] l.1400 -- do not create "^^xy" in string pool + @ @d app_lc_hex(#)==l:=#; + if l<10 then append_char(l+"0")@+else append_char(l-10+"a") + @y + @ The first 256 strings will consist of a single character only. + @z + @x + begin if (@) then + begin append_char("^"); append_char("^"); + if k<@'100 then append_char(k+@'100) + else if k<@'200 then append_char(k-@'100) + else begin app_lc_hex(k div 16); app_lc_hex(k mod 16); + end; + end + else append_char(k); + g:=make_string; str_ref[g]:=max_str_ref; + @y + begin append_char(k); + g:=make_string; str_ref[g]:=max_str_ref; + @z + + @x [4.64] l.1420 -- change documentation (probably needed in more places) + would like string @'32 to be the single character @'32 instead of the + @y + would like string @'32 to be printed as the single character @'32 instead + of the + @z + % [4.66] Open the pool file using a path, and can't do string % assignments directly. (`strcpy' and `strlen' work here because % `pool_name' is a constant string, and thus ends in a null and doesn't *************** *** 561,566 **** --- 589,693 ---- @!trick_buf:array[0..ssup_error_line] of ASCII_code; {circular buffer for @z + @x [5.73] l.1623 -- rename |print_char| to |print_visible_char| + @ The |print_char| procedure sends one character to the desired destination, + using the |xchr| array to map it into an external character compatible with + |input_ln|. All printing comes through |print_ln| or |print_char|, hence these + routines are the ones that limit lines to at most |max_print_line| characters. + @y + @ The |print_visible_char| procedure sends one character to the desired + destination, using the |xchr| array to map it into an external character + compatible with |input_ln|. (It assumes that it is always called with + a visible ASCII character.) All printing comes through |print_ln| or + |print_char|, which ultimately calls |print_visible_char|, hence these + routines are the ones that limit lines to at most |max_print_line| characters. + @z + @x + @= + procedure@?unit_str_room; forward;@t\2@>@/ + procedure print_char(@!s:ASCII_code); {prints a single character} + @y + @= + procedure@?unit_str_room; forward;@t\2@>@/ + procedure print_visible_char(@!s:ASCII_code); {prints a single character} + @z + + @x [5.73] l.1667 -- insert new |print_char| procedure + done:incr(tally); + end; + @y + done:incr(tally); + end; + + @ The |print_char| procedure sends one character to the desired destination. + File names and string expressions might contain |ASCII_code| values that + can't be printed using |print_visible_char|. These characters will be + printed in three- or four-symbol form like `\.{\^\^A}' or `\.{\^\^e4}'. + (This procedure assumes that it is safe to bypass all checks for unprintable + characters when |selector=ps_file_only| since the \ps\ printing routines + check their arguments themselves before calling |print_char| or |print|.) + + @d print_lc_hex(#)==l:=#; + if l<10 then print_visible_char(l+"0")@+else print_visible_char(l-10+"a") + + @= + procedure print_char(@!s:ASCII_code); {prints a single character} + label exit; + var k:ASCII_code; + @!l:0..255; {small indices or counters} + begin + if selector=ps_file_only then {assume it's safe} + begin print_visible_char(s); return; + end; + k:=s; if @ then + begin if selector>pseudo then + begin print_visible_char(s); return; + end; + print_visible_char("^"); print_visible_char("^"); + if s<64 then print_visible_char(s+64) + else if s<128 then print_visible_char(s-64) + else begin print_lc_hex(s div 16); print_lc_hex(s mod 16); + end; + end + else print_visible_char(s); + exit:end; + @z + + @x [5.74/75] l.1674 -- simplify |print| and remove |slow_print| + |print_char("c")| is quicker, so \MP\ goes directly to the |print_char| + routine when it knows that this is safe. (The present implementation + assumes that it is always safe to print a visible ASCII character.) + @^system dependencies@> + @y + |print_char("c")| is quicker, so \MP\ could go directly to the |print_char| + routine when it knows that this is safe. (The present implementation + assumes that it is always safe to print a visible ASCII character.) + @^system dependencies@> + + Old versions of \MP\ needed a procedure called |slow_print| whose function + is now subsumed by |print|. We retain the old name here as a possible aid + to future software arch\ae ologists. + + @d slow_print == print + @z + + @x [5.75] l.1689 -- remove |slow_print| + @ Sometimes it's necessary to print a string whose characters + may not be visible ASCII codes. In that case |slow_print| is used. + + @= + procedure slow_print(@!s:integer); {prints string |s|} + var @!j:pool_pointer; {current character code position} + begin if (s<0)or(s>max_str_ptr) then s:="???"; {this can't happen} + @.???@> + j:=str_start[s]; + while j1 then + begin str_room(1); append_char(cur_exp); cur_exp:=make_string; + end; + end; + @y + else begin cur_exp:=round_unscaled(cur_exp) mod 256; cur_type:=string_type; + if cur_exp<0 then cur_exp:=cur_exp+256; + end; @z @x [42.1151] Fix `threshold' conflict with local variable name. ================ ================ diff -c mf.ch mf.ch2 *** mf.ch Sun Dec 10 21:15:39 1995 --- mf.ch2 Sun Dec 10 22:20:49 1995 *************** *** 919,924 **** --- 919,936 ---- {Same thing} @z + % [33.671] l.14020 -- string length bug fix proposed by Wayne Sullivan: + % avoid using the first 256 strings (stored as "^^xy" in the string pool) + % for single character strings containing an unprintable character, + % create a new string of length one instead as done for `char xyz'. + @x + if loc=k+1 then cur_mod:=buffer[k] + else begin str_room(loc-k); + @y + if (loc=k+1) and (length(buffer[k])=1) then cur_mod:=buffer[k] + else begin str_room(loc-k); + @z + @x [38.768] Area and extension rules. @ The file names we shall deal with for illustrative purposes have the following structure: If the name contains `\.>' or `\.:', the file area diff -c mp.ch mp.ch2 *** mp.ch Sun Dec 10 22:17:32 1995 --- mp.ch2 Mon Dec 11 00:32:47 1995 *************** *** 894,899 **** --- 894,911 ---- @y invalid_class: if scanner_status=tex_flushing then goto switch else @; + @z + + % [29.631] l.12198 -- string length bug fix proposed by Wayne Sullivan: + % avoid using the first 256 strings (stored as "^^xy" in the string pool) + % for single character strings containing an unprintable character, + % create a new string of length one instead as done for `char xyz'. + @x + if loc=k+1 then cur_mod:=buffer[k] + else begin str_room(loc-k); + @y + if (loc=k+1) and (length(buffer[k])=1) then cur_mod:=buffer[k] + else begin str_room(loc-k); @z @x [35.745] area and extension rules. ================ ==== From: hobby@research.att.com Date: Mon, 11 Dec 95 08:39 EST To: vieth@thphy.uni-duesseldorf.de CC: kb@cs.umb.edu, raichle@informatik.uni-stuttgart.de Since I am still too busy to do much on MetaPost any time soon, I can only weigh in with my opinion. Whichever fix you choose probably belongs in the .web file rather than the .ch file. Of course, that would require new version numbers, etc. for both mf and mp. Since it appears that we want to avoid that, I would suggest change 2, the simpler option. When I eventually do get around to updating mp, I will probably go back and look at both options and change the .web in whichever manner seems best. This will be much less painless if the amount of affected code in the .ch file is small. - John Hobby ==== From: "K. Berry" Date: Mon, 11 Dec 1995 11:41:25 -0500 To: vieth@thphy.uni-duesseldorf.de CC: raichle@informatik.uni-stuttgart.de, hobby@research.att.com 1.) a somewhat involved fix proposed by Bernd Raichle as already discussed last week. This involves changing the string pool so that the first 256 strings are stored as single characters. This seems like the cleanest thing to do. The differences in the mptrap test don't bother me, especially since I expect people will diff against the log I will provide, and thus they won't show up. I'll probably end up applying Bernd's final patch to do the same thing to tex.ch as well. OK? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ==== END OF SUMMARY ====