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 <spqr@uk.ac.soton.ecs>
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 <spqr@uk.ac.soton.ecs>
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 <DR7@UK.AC.RL.IB>
> 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 <CET1%uk.ac.cambridge.phoenix@uk.ac.nsfnet-relay>
Subject: Re: New E-cm virtual fonts for TeX 3.0
Message-ID: <A1FB72DCD610E450@UK.AC.CAM.PHX>
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 <spqr@uk.ac.soton.ecs>
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 <mt00@uk.co.eurotherm>,
Aston TeX Archivists <Archivegroup@Uk.Ac.Aston.VaxA>
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 <mt00@uk.co.eurotherm>
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} <TeX@Uk.Ac.Cranfield.RMCS>
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 <Archivegroup@Uk.Ac.Aston.VaxA>
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 <MALCOLM@UK.AC.ICRF>
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 <charles@uk.ac.oxford.convex>
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 <MALCOLM@UK.AC.ICRF>
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 <received 26 Feb 90 14:29:10 via EARN>
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 <mackay@edu.washington.cs.june>
Return-Path: <mackay@cs.washington.edu>
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 <PEB%bitnet.dm0mpi11@edu.cuny.cunyvm>
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