UKTeX V90 #13 Friday 27 April 1990 ligatures in PostScript fonts Re: Atari driver Re: New E-cm virtual fonts for TeX 3.0 sideways printing in LaTeX LaTeX on A4 Paper. RE: Washington tape DVI is a trademark of Intel Corporation Chemical Formulae and Structures. TeX memory capacity; new errata; MF 2.0 changes; WEAVE 3.1 e-cm fonts; a DVIcopy processor Editor Peter Abbott Latest TeXhax in the Archive is #41 Latest TeXmag in the Archive is V3N4 (in 2 parts) ------------------------- Via: UK.AC.ASTON.MAIL; Mon, 23 Apr 90 13:47 BST Via: UK.AC.SOUTHAMPTON.MATHEMATICS; Mon, 23 Apr 90 13:31 BST Received: from manutius.ecs.soton.ac.uk by hilliard.ecs.soton.ac.uk; Sat, 21 Apr 90 14:56:23 BST From: Sebastian Rahtz Date: Sat, 21 Apr 90 14:54:37 gmt Message-Id: <15700.9004211454@manutius.ecs.soton.ac.uk> Subject: ligatures in PostScript fonts > Here at Oxford we're having problems with using PostScript fonts with > LaTeX/TeX -- we cannot obtain the fi and fl ligatures. (Also, the open > and closing angle brackets are present in Helvetica but not in Courier: > I have to admit I haven't done full font proofs to see if anything else You can one of three things: - redefine macros in TeX so requests for characters point at the right font position in an Adobe fonts - perform magic in your PostScript header file to define the encoding vector of the PS fonts - use virtual fonts to perform the mapping for you Full-worked examples of the first two approaches can be found by examining the various dvi to PostScript conversion systems. Tedious, I admit! If PSPRINT understood virtual fonts, it would be easier for you. I tend to think that the best long-term solution is to abandon Knuth's font layout, along with CMR, and rewrite the macros to reflect Adobe's layout... Sebastian Rahtz ------------------------ Via: UK.AC.ASTON.MAIL; Mon, 23 Apr 90 14:06 BST Via: UK.AC.SOUTHAMPTON.MATHEMATICS; Mon, 23 Apr 90 13:41 BST Received: from manutius.ecs.soton.ac.uk by hilliard.ecs.soton.ac.uk; Sat, 21 Apr 90 15:01:21 BST From: Sebastian Rahtz Date: Sat, 21 Apr 90 14:59:34 gmt Message-Id: <15705.9004211459@manutius.ecs.soton.ac.uk> In-Reply-To: <2440081B_00106D88.009357F1A83A6300$1_1@UK.AC.RHBNC.VAX> Subject: Re: Atari driver > From: Douglas Ross > Subject: TEX Laser printer driver for an Atari > > I have a version of TEX for my Atari 1040ST and I am trying to find a > driver for a laser-jet printer. I notice that in the archived directory > there is a file called LASERJET.DIR. I am a bit confused. Are these If you have a moderate understanding of C, and a C compiler, you should be able to compile either Beebe's driver for a LaserJet or Neumann's dvi2lj (in .drivers.neumann at Aston). Otherwise I suggest you consider buying a driver. There are various adverts in TUGBOAT. > Also if I manage to get hold of a Laser printer driver could you tell > me what the command line would be. For my Epson driver it is this is totally unknowable. There are literally dozens and dozens of dvi driver programs, and the syntax of the command line is up to the author. Sebastian Rahtz ------------------------ Via: UK.AC.ASTON.MAIL; Mon, 23 Apr 90 14:07 BST Via: UK.AC.NSFNET-RELAY; Mon, 23 Apr 90 13:43 BST Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK Via Ethernet with SMTP id ab10286; 20 Apr 90 20:13 GMT Received: from math.ams.com by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa01611; 20 Apr 90 21:11 BST Received: from NSFnet-Relay.AC.UK by MATH.AMS.COM via SMTP with TCP; Fri, 20 Apr 90 13:01:30-EDT Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa24087; 20 Apr 90 17:36 BST Date: Fri, 20 Apr 90 17:39:06 BST From: Chris Thompson Subject: Re: New E-cm virtual fonts for TeX 3.0 Message-ID: Sender: CET1%uk.ac.cambridge.phoenix%uk.ac.nsfnet-relay@com.ams.math This message is a response to Wayne Sullivan's posting on the subject. In general, much of what he says seems to me to be useful and correct, but there are some points to pick up. I will take them more or less in the order that they arise in Wayne's document. Generating VF files. Wayne suggests generating VF files from the DVI generated by TeX, possibly through the agency of DVItype. An alternative would be to use the output from \showbox. In any case, if the data is being massaged into the form of a VPL file, it will be important to get the scaling right; possibly by a judicious choice of DESIGNUNITS. (The DVI generated by TeX will not be suitable for literal inclusion in the VF file except in very carefully controlled conditions.) If VF files are being generated from VPL files, note that VPtoVF does very little cross-checking. Use VFtoVP on the result to check that the VF file contents agree with the TFM files for the secondary fonts. It may be advantageous to go round the VPL -> VF -> VPL loop more than once. DVIvfDVI (curiously constructed name, that!). I agree with Wayne that a translator like this would be very useful, and a desirable addition to the TeX distribution. It is important to note (as Wayne doesn't mention, and I also failed to point out in my posting in TeXhax 1990/015) that the DVI-like parts of the VF file have to be scaled before inclusion in the output DVI file. (The only case when more-or-less literal copying would be correct is when the scaled size of the virtual font is 2^20sp=16pt.) Scaling needs to be applied to explicit movements in the character definitions, and to the `s' values of the secondary fonts. We don't have a canonical definition of how rounding should be applied in this scaling process, which has some effects on the points mentioned below. "Inconsistent font specification". Wayne claims that there is an inconsistency between VFtoVP and VPtoVF, in that the default font (at the start of each subroutine) is the first defined in the preamble in VFtoVP, but font 0 in VPtoVF. However, VPtoVF remaps the MAPFONT font numbers in the VPL file to 0, 1, 2, ... in order of occurrence (which is the order they occurred in the VF file, if the VPL file was generated by VFtoVP), so that after this transformation, font 0 always *is* the first defined font. Floating point. As a general point, I agree that the uses of floating point arithmetic in TeX (accent positioning, glue settings) cause trouble, and I consider it a great pity that Don Knuth allowed them in, rather than taking the line that the DVI files generated by TeX should be machine-independent. See, for instance, the remarks near the bottom of tex82.bug where the consequences are used as an excuse (sorry, reason) for the non-existence of general list-decomposing primitives in TeX. I also wish that Don hadn't chickened out on the question of division of signed integers in METAFONT (see section 95), for similar reasons... but enough moaning! As a matter of interest, does anyone know which form of floating point arithmetic is used to construct the canonical TRIP results? Implicit push/pop. Wayne attributes the part of the specification that has each subroutine logically enclosed in a push-pop pair to a desire to save a few bytes in the VF file. I don't see it this way at all: it must be a requirement that one can interpret the DVI file knowing only the TFM information - - specifically, the character width information --- for each font. Hence the fact that one must return to the initial position, or the initial position plus the character width, is an absolute necessity. It is no doubt true that many subroutines, especially those consisting of a single SETCHAR, will leave the DVI cursor at the same place as will be achieved after the pop-and-move-right operation. There is no reason why the DVI-to-DVI converter shouldn't recognise such cases, and simplify the resulting output DVI file. To do so it must read the TFM files of the secondary fonts, which it might not otherwise have to do. (A DVI-to-device driver would have all the requisite TFM width information anyway, of course.) What Wayne seems to be asking for is an option in the VF file to specify to the converter that this coincidence will occur, to save it having to read the secondary TFM files and make the check. This hint would obviously have to be validated (by VFtoVP, as things are organised at the moment, as this is the only program that checks the VF file against the secondary TFM files) to avoid accidents. As the hint is not useful to true device drivers, I am very doubtful that it would be worth complicating the specification in this way. Pixel rounding. Wayne mentions the problem with following DVItype rules for pixel rounding after generating the DVI for a character in a virtual font, as I did in the TeXhax 1990/015 posting. One point to bear in mind here is that VF files have no `recommended pixel width' value (they can't, of course, as they refer to all possible resolutions), so the best one can do is to generate it as the rounded value of the scaled TFM width, as one did for PXL files. Wayne's suggestion that the DVI-to-DVI converter could generate a `setrule' with zero height instead of a `right' order in order to achieve the desired effect is interesting. (It would generate a few more DVI bytes, of course.) Note, however, that rule dimensions are supposed to be rounded *up* when being converted to pixels. Also it might be interesting to discover whether such a DVI file is handled correctly by all DVI drivers: TeX itself never generates rules with zero or negative dimensions in its DVI file, omitting them entirely instead. I have often toyed with the idea of writing a DVI-obfuscating program that would convert a DVI file to one functionally equivalent, but using all sorts of DVI features that TeX doesn't --- weird font numbers, unnecessary leading zeroes/signbits, nop's sprinkled here and there, and so forth --- for the purpose of stressing DVI-interpreting programs! Chris Thompson JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk ------------------------ Via: UK.AC.ASTON.MAIL; Mon, 23 Apr 90 14:23 BST Via: UK.AC.SOUTHAMPTON.MATHEMATICS; Mon, 23 Apr 90 14:13 BST Received: from escher.ecs.soton.ac.uk by hilliard.ecs.soton.ac.uk; Sun, 22 Apr 9 0 18:28:19 BST From: Sebastian Rahtz Date: Sun, 22 Apr 90 18:26:36 gmt Message-Id: <17062.9004221826@escher.ecs.soton.ac.uk> Subject: sideways printing in LaTeX Yet another contribution to the ways of printing material sideways or at funny angles in LaTeX, if you use a PostScript printer. I append my style option `rotate', which others may care to have a go with. It *should* work with Rokicki's dvips, Clark's dvitops and assorted versions of dvi[23]ps (if they have been doctored to allow PostScript to be passed straight through). I have been hacking at these macros for years; and they still fail me on occasion. If anyone can come up with changes to make them fool-proof, tell me now! The principal problems are: - the dvitops macros do not permit nested rotations; you cannot have sideways captions in a sideways table - under some circumstances, using dvips or dvi2ps, the LaserWriter says `invalidfont; OffendingCommand: show' which is incredibly unhelpful. - in dvips and dvitops, if you make a font change in some rotated text, you are stuck with it for much longer than you expected Sebastian Rahtz % rotate.sty % \typeout{** Rotation macros. version 2. Sebastian Rahtz Apr 22 1990 **} *************************************************************************** Editor - % Cut by Editor - It is in the Archive *************************************************************************** ------------------------ Via: UK.AC.ASTON.VAXA; Mon, 23 Apr 90 15:15 BST Date: Mon, 23 APR 90 15:16:07 BST From: ARCHIVEGROUP@UK.AC.ASTON.VAXA Subject: LaTeX on A4 Paper. Reply-To: Martin Tomes , Aston TeX Archivists Originally-sent:Mon, 23 Apr 90 10:52:37 BST Originally-To: uktex@uk.ac.aston Original-Ident: <1707.9004230952@jackdaw.eurotherm.co.uk> Originally-from:Martin Tomes How do I get LaTeX to print on A4 paper? I have tried: \textheight=8.65in and although this appears to work with straight text it goes crazy when I use psfig to include PostScript diagrams which get pushed to the end of the document. I would also like to reduce the left margin and increase the line length despite this being against the rules of good presentation given in Lamports book. I am using TeX 2.99 and LaTeX 2.09. Martin Tomes Janet: mt00@uk.co.eurotherm | Eurotherm Limited, Faraday Close, Internet: mt00@eurotherm.co.uk | Durrington, Worthing, W.Sussex, England. UUCP: {ukc,uunet}!etherm!mt00 | Phone: +44 903 68500 Fax: +44 903 65982 Via: UK.AC.ASTON.VAXA; Mon, 23 Apr 90 16:00 BST Date: Mon, 23 APR 90 16:02:42 BST From: ARCHIVEGROUP@UK.AC.ASTON.VAXA Subject: RE: LaTeX on A4 Paper. Originally-sent:Mon, 23 APR 90 15:53:53 BST Original-Ident: <00000959_00072FD8.00935A3A5DD660C0$12_2@UK.AC.CRANFIELD.RMCS> Originally-from:Brian {Hamilton Kelly} Martin, >How do I get LaTeX to print on A4 paper? I have tried: What you really want is some style files designed for A4 paper; however, in the absence of these, a compromise is to use the style *option* A4, which is available from [tex-archive.latex.contrib]a4.sty at Aston. Alternatively, you might like to try A4Wide, which uses more of the width of the paper; this is in the same directory. To use these, include `a4' amongst the style options which start your document (if you have any); for example: \documentstyle[a4]{report} (or article, or whatever). Brian {Hamilton Kelly} (p.p. Aston Archivists) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + JANET: tex@uk.ac.cranfield.rmcs + + BITNET: tex%uk.ac.cranfield.rmcs@ac.uk + + INTERNET: tex%uk.ac.cranfield.rmcs@nsfnet-relay.ac.uk + + UUCP: ...!mcvax!rmcs.cranfield.ac.uk!tex + + OR ...!ukc!rmcs.cranfield.ac.uk!tex + + Smail: School of Electrical Engineering & Science, Royal Military + + College of Science, Shrivenham, SWINDON SN6 8LA, U.K. + + Phone: Swindon (0793) 785252 (UK), +44-793-785252 (International) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------ Via: UK.AC.ASTON.MAIL; Mon, 23 Apr 90 15:51 BST Via: UK.AC.EARN-RELAY; Mon, 23 Apr 90 15:36 BST Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 1712; Mon, 23 Apr 90 15:07:31 BS Received: from FRINED51(BROUARD) by UKACRL (Mailer X1.25) id 0078; Mon, 23 Apr 90 15:07:31 BS Date: 23 APR 90 15:54:54.00-GMT From: BROUARD@EARN.FRINED51 Subject: RE: Washington tape TEX 2.993 is not TEX 3.0 and the differencse are quite big. It would have been better to wait up to TEX 3 for distribution Nicolas Brouard *************************************************************************** Editor - This is just the normal update tape from Washington *************************************************************************** ------------------------ Via: UK.AC.ASTON.VAXA; Mon, 23 Apr 90 21:01 BST Date: Mon, 23 APR 90 21:04:00 BST From: ARCHIVEGROUP@UK.AC.ASTON.VAXA Subject: DVI is a trademark of Intel Corporation Reply-To: CCZDGR@UK.AC.NOTTINGHAM.CCC.VAX, Aston TeX Archivists Originally-sent:Mon, 23 APR 90 20:54:12 GMT Originally-To: infotex@UK.AC.ASTON Original-Ident: <20200438_0011A988.00935A6451FE0DA0$12_1@UK.AC.NOTTINGHAM.CCC.VA X> Originally-from:CCZDGR@UK.AC.NOTTINGHAM.CCC.VAX Knuth had to be careful about using TeX rather than TEX, so as not to infringe Honeywell's use of TEX for something else. I remember a similar thing when UMRCC (as it then was) had to re-name Stanford's MINOS as SMINOS, so as not to infringe the NCB's use of MINOS for something else. I now see that Intel have got DVI as a registered trademark. Are there any lawyers reading who know whether Intel's ownership of "DVI" could ever impinge on our use of "a DVI file"? For reference, I saw Intel's DVI used in a notice advertising a workshop to be run by Knowledge Research Towermead Business Centre High Street Old Fletton Peterborough PE2 9DY Tel: +44 733 60535 Fax: +44 733 45522 Their trademark-ed "DVI Technology" is something to do with compression techniques for CD-ROMs. David Rhead Via: UK.AC.ASTON.VAXA; Tue, 24 Apr 90 8:24 BST Date: Tue, 24 APR 90 08:27:13 BST From: ARCHIVEGROUP@UK.AC.ASTON.VAXA Subject: RE: DVI is a trademark of Intel Corporation Originally-sent:Tue, 24 Apr 90 8:19 GMT Originally-To: CCZDGR@UK.AC.NOTTINGHAM.CCC.VAX, Originally-from:MALCOLM david this did come up at the board meeting at TUG last year (digital video information?). the discussion centred around copyrighting some other acronyms: pk, pxl (!!) web (not an acronym), etc. it's a difficult one..... malcolm Via: UK.AC.ASTON.VAXA; Tue, 24 Apr 90 19:11 BST Date: Tue, 24 APR 90 19:14:11 BST From: ARCHIVEGROUP@UK.AC.ASTON.VAXA Subject: Re: [Registered] Trade{mark,name}s Originally-sent:Tue, 24 Apr 90 19:05:21 BST Original-Ident: <7711.9004241805@convex.oxford.ac.uk> Originally-from:Charles Curran Though David Rhead's awareness message on DVI being a *registered* trademark of Intel doesn't pertain particularily to the workings of a/the TeX archive, this Topic, or should I say Apple, is still worth a few nibles. o One would hope, as Malcolm seems to suggest, that the various TUG committees would be `sorting this out'. o Since DVI (in the TeX domain) presumably predates the use of these letters when referring to digital video, one could pull the rug from under Intel. I believe this reallocation of trademarks has happened recently. o Where is DVIetc a *registered* trademark? (Unix (it's okay Phil, it's nothing +ve) is not a trademark of AT&T/Bell Labs in France: Unixsys got there 1st :-). And besides, those of you interested in typography will recall a book from 1938, the title of which escapes me just now, which shows an ad. of a bookcase named "unix".) o Is TeX registered in the UK yet? regards, Charles. Via: UK.AC.ASTON.VAXA; Wed, 25 Apr 90 8:23 BST Date: Wed, 25 APR 90 08:25:37 BST From: ARCHIVEGROUP@UK.AC.ASTON.VAXA Subject: Re: [Registered] Trade{mark,name}s Originally-sent:Wed, 25 Apr 90 8:18 GMT Originally-from:MALCOLM trademarks 'n' stuff 1. while tug is aware of the situation (to some extent), the feeling was that registration of the various `names' would be an expensive business. TUG already trades in deficit, and seems destined to do so for the next few years. neither could it afford to challenge the existing registration of dvi, nor really could it afford all the many names we've come up with. this is where the public domain, as usual, gets screwed. 2. i doubt if TeX is a registered trademark in the states, despite AMS' claim. 3. can a group have a trade mark? if we do not `trade' how can we (or TUG etc) have a trade mark? 4 i suspect us law permits the first registerer (or?) of a mark to claim it, despite prior usage. trade names, or trading names is another matter. i note one company in scandinavia was prevented from using the name TeXas (it's a pun TeX A/S, where A/S is equivalent to Ltd or plc or something) because of Texas instrumnets (or was it Texas homecare or Texas Big 'Un?). malcolm ------------------------ Via: UK.AC.ASTON.MAIL; Tue, 24 Apr 90 11:10 BST Via: UK.AC.HULL.CC.SEQUENT; Tue, 24 Apr 90 10:53 BST Via: uk.ac.hull; Tue, 24 Apr 90 10:57:42 -0100 Date: Tue,24 Apr 90 10:58:10 BST From: R.A.Reese@uk.ac.hull Subject: Chemical Formulae and Structures. Comments: For TeX bulletin please. Message-Id: <24 Apr 90 10:58:10 A103F0@UK.AC.HULL> In-Reply-To: Your message There is a chemist here who has recently started using TeX. We would appreciate advice from someone who knows the conventions for typesetting chemical formulae and how to achieve them in TeX. It is easy enough to write, \documentstyle{article}\nofiles \begin{document} \section*{Input} \begin{verbatim} Water is {\bf H}$_2${\bf O} Most carbon is $^{14}${\bf C} Oxygen wanders about as $^{16}${\bf O}$_2$ \end{verbatim} \section*{\dots makes output} Water is {\bf H}$_2${\bf O} Most carbon is $^{14}${\bf C} Oxygen wanders about as $^{16}${\bf O}$_2$ \end{document} but for extensive use it is tedious to have to drop into maths mode for every sub/superscript and non-maths for every atomic reference. Has anyone written code to define a "chemical" mode? We also have a copy of a paper by Haas and O'Kane "Typesetting Chemical Structure Formulas with TeX/LaTeX" (Computational Chemistry Vol 11 pp251-271 1987). Have the macros printed there been made available in an archive, or further developed? Or are there better alternatives? Allan Reese R.A.Reese@hull.ac.uk Post: Computer Centre JANET: R.A.Reese@uk.ac.hull | University of Hull Internet: R.A.Reese%hull.ac.uk@cunyvm.cuny.edu | Hull HU6 7RX EARN/BITNET: R.A.Reese%hull.ac.uk@UKACRL | UK |Phone +44 482 465296 |FAX +44 482 466205 Editor: The Professional Statistician (Newsletter of the Institute of Statisticians, membership open to qualified, practising statisticans, also affiliate and institutional grades) ------------------------ Via: UK.AC.ASTON.MAIL; Thu, 26 Apr 90 0:45 BST Via: UK.AC.NSFNET-RELAY; Thu, 26 Apr 90 0:38 BST Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK Via Ethernet with SMTP id ab14329; 25 Apr 90 23:16 GMT Received: from [130.44.1.4] by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa03473; 26 Apr 90 0:32 BST Received: from june.cs.washington.edu by VAX01.AMS.COM via SMTP with TCP; Wed, 25 Apr 90 19:33:53-EDT Received: by june.cs.washington.edu (5.61/7.0jh) id AA02369; Wed, 25 Apr 90 16:31:22 -0700 Date: Wed, 25 Apr 90 16:31:22 -0700 From: Pierre MacKay Return-Path: Message-Id: <9004252331.AA02369@june.cs.washington.edu> In-Reply-To: bbeeton's message of Sun 1 Apr 90 16:21:31-EST <639004891.0.BNB@MATH.AMS.COM> Subject: TeX memory capacity; new errata; MF 2.0 changes; WEAVE 3.1 Sender: mackay%edu.washington.cs.june%edu.washington.cs.june@com.ams.vax01 Here are the relevant values for the TeX change file that is the default in the UnixTeX distribution. There have been no complaints for quite a while since these values were chosen. Your point about the hyphenation sizes is important, however, and we will have to increase those. We did double the space for hyphenation exceptions, but that may not be enough. Ain't virtual memory wonderful? Especially if you are not stingy with the swap partition on the disk. @!mem_max=262140; {greatest index in \TeX's internal |mem| array; must be strictly less than |max_halfword|; must be equal to |mem_top| in \.{INITEX}, otherwise |>=mem_top|} @!buf_size=3000; {maximum number of characters simultaneously present in current lines of open files and in control sequences between \.{\\csname} and \.{\\endcsname}; must not exceed |max_halfword|} @!stack_size=300; {maximum number of simultaneous input sources} @!font_max=255; {maximum internal font number; must not exceed |max_quarterword| and must be at most |font_base+256|} @!font_mem_size=72000; {number of words of |font_info| for all fonts} @!max_strings=7500; {maximum number of strings; must not exceed |max_halfword|} @!string_vacancies=74000; {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=100000; {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} @!save_size=4000; {space for saving values outside of current group; must be at most |max_halfword|} @d hash_size=9500 {maximum number of control sequences; it should be at most about |(mem_max-mem_min)/10|} @d hash_prime=7919 {The thousandth in a list of 1000 primes. Run the primes program in LiterateProgramming to find out. It is reasonably close to 85\pct! of a |hash_size| of 9500} @d hyph_size=607 {another prime; the number of \.{\\hyphenation} exceptions} @d max_quarterword=511 {largest allowable value in a |quarterword|} @d max_halfword==262143 {largest allowable value in a |halfword|} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% The last two values are the critical ones. If you are going to make up 32-bit TeX at all, you might as well go the whole way. We could actually make the max_halfword larger if everybody would promise not to undump the core image. I once made up a TeX with over 1,000,000 as the value of max_halfword, but backed off from that after I found that the undumped image was 9 Megabytes. A TeX that size is a bad neighbor, especially when it is autonomous, as all undumped versions are. Don Knuth's omphaloskeptic version allows more flexibility, since the executable text is shared by several users, and apparently only the active part of a huge mem-max array is resident for each user. Even so, I will wait till someone complains about the present max_halfword before boosting it again. Pierre ------------------------ Via: UK.AC.ASTON.MAIL; Thu, 26 Apr 90 17:53 BST Via: UK.AC.NSFNET-RELAY; Thu, 26 Apr 90 17:46 BST Received: from vax.nsfnet-relay.ac.uk by sun.NSFnet-Relay.AC.UK Via Ethernet with SMTP id aq09309; 26 Apr 90 16:08 GMT Received: from math.ams.com by vax.NSFnet-Relay.AC.UK via NSFnet with SMTP id aa11151; 26 Apr 90 17:21 BST Received: from CUNYVM.CUNY.EDU by MATH.AMS.COM via SMTP with TCP; Thu, 26 Apr 90 12:23:03-EDT Received: from DM0MPI11.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with BSMTP id 1387; Thu, 26 Apr 90 12:06:39 EDT Date: Thu, 26 Apr 90 15:08:43 GMT From: PEB Comment: CROSSNET mail via SMTP@INTERBIT Return-Receipt-To: PEB@DM0MPI11.BITNET Sender: PEB%bitnet.dm0mpi11%edu.cuny.cunyvm@com.ams.math Date: 26 April 1990, 15:08:03 GMT From: Peter Breitenlohner (089) 32308-412 PEB at DM0MPI11 Max-Planck-Institut fuer Physik (Werner-Heisenberg-Institut) Foehringer Ring 6 D-8000 Muenchen 40 Subject: e-cm fonts; a DVIcopy processor; Re: Wayne Sullivan and Chris Thomson At the DANTE (german speaking TeX users group) meeting about a month ago several aspects of the use of TeX 3.0 were discussed. Among other things it became clear that it will take some time to get all the e-cm fonts ready (once a coding scheme for the upper 128 characters has been agreed on). Thus a temporary solution to realize them via virtual fonts will be helpful (and maybe even necessary to test the whole scheme as soon as possible). Moreover there are DVI drivers uncapable to handle fonts with more than 128 characters, and few DVI drivers can already handle virtual fonts. Thus a DVI=>DVI program resolving virtual fonts is needed, and it should be public domain (source included)! At the DANTE meeting I sort of promised to write such a program and now I finally got started to do just that. The program will be written in ``Knuth's Stanford Pascal'', i.e., essentially a subset of ANSI/ISO Pascal; in fact large portions of the program are stolen from existing programs such as DVItype, TFtoPL, VFtoVP and even TeX. All this is done, however, with particular emphasis on the aspect that it should be easy to make system dependent optimizations. A program such as DVIcopy should run as efficient as possible on a particular system for two reasons: (1) it might well be in use as preprocessor for other DVI drivers for quite some time; and (2) it can be thought of as DVI driver for a ficticious output device (the copy of the DVI file) and can thus serve as model for DVI drivers for real devices (probably even more so than DVItype). The program is, in fact, designed such that all code related to writing the copy of the DVI file is concentrated in one part and quite independent from the rest (reading DVI and VF, font substitutions etc.); thus it should be simple to replace that code by the code required for a real output device. DVIcopy will take care of most of the aspects discussed by Wayne and/or Chris: it will (hopefully) use good arithmetic; it will determine whether a character packet from a VF file requires a push/pop or not; etc. I agree with Chris that VF files should be produced via VPtoVF, not by copying bytes from DVI files (they must be scaled properly!), but it may be helpful to use TeX+DVItype to get a first approximation for the VPL data. One more point Re: Wayne and Chris: it is true that conversion to pixels in DVItype is different for rule dimensions and character widths (different rounding) and DVIcopy will clearly do its arithmetic the same way. DVIcopy's pixels are, however, dvi units (not necessarily scaled points!) and thus rounding should have little effect in the conversion from DVI's scaled size times VF's fix words to the resulting dvi units. I expect that a preliminary (moderately well tested) version of DVIcopy together with two change files (VM/CMS+VS Pascal and MS-DOS+Turbo Pascal) will be available in about two weeks. It will then take some time to eliminate all sorts of small kinks and bugs. A good many change files for various systems and feedback will certainly help in that respect. The program will (at least for the moment) be rather intolerant if any problems with DVI, TFM or VF files are encountered, it will refer the user to DVItype, TFtoPL or VFtoVP to obtain more details about the problem and will then terminate. Anything else would make things much more complicated and produce a considerable delay. Meanwhile I would welcome any suggestion about (1) how DVIcopy shall be distributed/made available and (2) features that should be included and/or aspects that should be considered (no guarantee that I'll do what you suggest but I promise that I'll at least think about it). With best regards Peter ------------------------ !! !! Files of interest !! [tex-archive]000aston.readme [tex-archive]000directory.list !! [tex-archive]000directory_dates.list [tex-archive]000directory.size !! [tex-archive]000last30days.files !! !! Editor - I have a tape labelled TeX 2.993(==3.0) LaTeX 2.09 Metafont 1.9 (2.0) !! Unix 4.2/3BSD & System V. Tar 1600 bpi blocked 20 1 file dated !! 28 March 1990 (from washington.edu). !! !! FTP access site uk.ac.aston.tex !! username public !! password public !! !! I have the facility to copy this tape for anyone who sends the following !! 1 2400 tape with return labels AND RETURN postage. (2.50 pounds sterling !! for UK users, payable to `Aston University') Outside UK please ask me. !! UK users send 4.25 for two tapes or 6.60 for three tapes. !! Send to !! !! P Abbott !! Computing Service !! Aston University !! Aston Triangle !! Birmingham B4 7ET !! !! A VMS backup of the archive requires 2 (two ) 2400' tapes at 6250bpi. !! Remaining details as above. !! !! A VMS backup of TeX 2.991 plus PSprint is available one tape is needed. !! !! Exabyte tape drive with Video 8 cassettes. !! !! Same formats available as 1/2in tapes. We use the following tapes !! SONY Video 8 cassette P5 90MP, MAXCELL Video 8 cassette P5-90 !! TDK Video 8 cassette P5-90MPB !! Postage 35p UK (stamp please), 1 pound sterling Europe, other areas 2 pounds !! !! OzTeX - Send 10 UNFORMATTED (800k) disks with return postage. !! !! Replies/submissions to info-tex@uk.ac.aston please !! distribution changes to info-tex-request@uk.ac.aston please !! !! end of issue