UKTeX V89 #17 Friday 5 May 1989 IMPORTANT - Changes in the format of the Aston Archive. 3rd UKTUG Meeting UniTeX Systems' address \everypage (as it were) indexes to UKTeX and TeXhax FAO Dunstan Vavasour, re. TeX-Unmoderated (lack of) Subject lines in UKTeX leads to exclusion from synopsis ! "saving" points in MF European TeX courses at Exeter 1989 concrete fonts in LaTeX Second report from the TUG DVI Driver standards committee APPENDICES AT THE END OF CHAPTERS EPSON LQ Compatible dvi to PS programs Linotronic 300 mode_def Editor Peter Abbott Some systems were 'off' over Easter so the first two items from #16 are repeated. Latest TeXhax in the Archive is #32 Latest TeXmag in the Archive is V3N2 --------------------------------- Subject: IMPORTANT - Changes in the format of the Aston Archive. Aston Archive Format During May there will be a number of changes in the way information is stored in the Aston Archive. The top level will be labelled TEX-ARCHIVE and the last 30 days files etc will refer to this structure. Access to files via PUBLIC will be available for a limited period. Files will disappear from PUBLIC during MAY. Not all files are currently available in the new archive but they will be moved during May. Also note the address for the mail server is now texserver@uk.ac.aston.tex (UK format) or texserver@tex.aston.ac.uk (rest of the world) As a reminder to get help on using the mail server please send a message to texserver@uk.ac.aston.tex (UK format) and include in the message the following lines all starting in column 1 --- return address in UK format help Peter Abbott (on behalf of the Archivists) --------------------------------- Subject: 3rd UKTUG Meeting UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG The 3rd UKTUG meeting is scheduled for Wednesday July 5 1989 at Aston University, Birmingham The proposed theme is `Fonts, Design and Use' (4th meeting early october in London) UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG UKTUG --------------------------------- Date: Mon, 01 May 89 15:45:38 From: CS1CWM @ SHEFFIELD.PRIMEA Subject: UniTeX Systems' address Peter: Ewart's address and the address of UniTex Systems remain the same for the time being: they are (it is?) UniTeX Systems 12 Daleview Road Sheffield S8 0EJ England Tel: +44 742 351489 Tlx: 547938 for UniTeX Ewart has moved to Bristol University and can be reached there by phone. At present he cannot be reached by email but if anybody wants to send messages through me I will pass them on when he's back in Sheffield at weekends. Chris Martin (CS1CWM@SHEF.PA) --------------------------------- Received: from caxton.ecs.soton.ac.uk by hilliard.ecs.soton.ac.uk; Mon, 1 May 89 17:39:50 BST From: spqr@uk.ac.soton.ecs Date: Mon, 1 May 89 17:42:43 BST Message-Id: <21642.8905011642@caxton.ecs.soton.ac.uk> Cc: lac@uk.ac.soton.ecs Subject: \everypage (as it were) Today I wanted to add a \special to every page (it rotates the page through 90 degrees), and I ended up with \special{dvitops:landscape}% \edef\@PlainOutput{\the\output}% \def\@LandScapeOutput{\@PlainOutput% \ifnum\outputpenalty<-'1000000000\else\special{dvitops:landscape}\fi% % the conditional seems necessary, for otherwise you never leave the document, % as the final list never gets empty effectively redefining the output routine, and it seems to do what I want. But is there a more general way of doing what I want, which is to output some special each time I vomit a page, without worrying about whether some internal macro has reset \output temporarily? I'm pretty ignorant of output routines, so I may not know something obvious. The philosophical answer I may get back is that if I want to affect every page, I should have an option on the dvi driver. But I have to have a style file anyway, and it seems a pity to make users remember to use specific options with some style files. --------------------------------- Received: from robin.cs.nott.ac.uk by much.Cs.Nott.AC.UK id aa28494; 2 May 89 9:02 BST Received: from clan by Robin.Cs.Nott.AC.UK id aa20880; 2 May 89 9:02 BST Date: Tue, 2 May 89 9:02:15 BST From: David Osborne Subject: indexes to UKTeX and TeXhax Message-ID: <8905020902.aa06247@clan.nott.ac.uk> i have created keyword-in-context (kwic) indexes for UKTeX and TeXhax for 1987, 1988 and 1989 (issues 01--15 for UKTeX, issues 01--25 for TeXhax). the files are in the new [TEX-ARCHIVE] tree, in the directory [TEX-ARCHIVE.DIGESTS.INDEXES] with filenames UKTEXyy.IDX and TEXHAXyy.IDX where yy is the year. i hope to keep the 1989 indexes reasonably up to date as new issues of the digests appear; it can be automated once i get full communications on my Unix system. dave osborne (on behalf of TeX Archive maintainers' group) - -- David Osborne | JANET: d.osborne@uk.ac.nott.clan Cripps Computing Centre | BITNET: d.osborne%uk.ac.nott.clan@ukacrl.bitnet University of Nottingham |Internet: d.osborne%uk.ac.nott.clan@nsfnet-relay.ac.uk Nottingham NG7 2RD, UK | (Phone: +44 602 484848 x2064) --------------------------------- Date: Tue, 2 MAY 89 12:29:34 BST From: CHAA006@UK.AC.RHBNC.VAXB Subject: FAO Dunstan Vavasour, re. TeX-Unmoderated Sender: JANET"CHAA006@UK.AC.RHBNC.VAXB" Reply-to: Philip Taylor (RHBNC) Originally-to: $UK-TEX Mailer: Janet_Mailshr V3.3a (02-Feb-1989) Dunstan --- my attempts to acknowledge your request to join TeX-Unmoderated resulted in failure. As your mail header contains conflicting information, would you please advise me in the text of a mail message what the preferred route is from Janet to your system ? Philip Taylor (TeX Unmoderator) Royal Holloway and Bedford New College. Via: [000008010080.FTP.MAIL]; Sat, 29 Apr 89 18:55 BST Date: Sat, 29 Apr 89 18:55:14 BST From: mmdf@uk.ac.cam.cl Subject: Mail Delivery Failure to uk.ac.rl.gm - Timeout Sender: root@uk.ac.cam.cl Message-ID: <8904291855.aa27947@scaup.cl.Cam.AC.UK> The NIFTP process was unable to deliver your mail to host uk.ac.rl.gm over janet. The reason given by the local host was: The NIFTP process gave up after 43 attempts over 103 hours Your message was not delivered to the following addresses: Dunstan_Vavasour%uk.co.gec-epl@uk.ac.rl.gm --------------------------------- Date: Tue, 2 May 89 16:09 BST From: Harry Fearnley Subject: (lack of) Subject lines in UKTeX leads to exclusion from synopsis ! Peter A minor quibble - it would be nice if a one-line synopsis appeared for *all* contributions - in UKTeX V89 #16, there were at least 2 messages which did not simply because the contributors failed to supply one. Could you **strongly** encourage contributors to do so - their contribution/question may be missed because it does not appear in the table of contents. Thanks Harry +++Editor - The favourite culprits are contributors using VAX VMS systems. It only requires the /opt option to allow you to include a subject line. There are the others who also simply use the reply which gives the subject RE: UKTeX V?? #?? +++ --------------------------------- Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 2683; Tue, 02 May 89 21:55:07 BS Received: from UICVM by UKACRL.BITNET (Mailer X1.25) with BSMTP id 5378; Tue, 02 May 89 21:55:06 B Received: by UICVM (Mailer R2.02) id 3136; Tue, 02 May 89 15:53:10 CDT Date: Tue, 02 May 89 15:51:53 CDT From: Don Hosek Subject: "saving" points in MF I figured out how to solve my problem with points the other night while I was asleep (!)... The reason I couldn't use save x,y was that I needed to keep the x and y points that were passed to the radical; BUT if I did something like: def beginradical(text t) = begingroup; save a,b; forsuffixes $ = t: a$:=x$; b$:=y$; endfor save x,y; forsuffixes $ = t: x$:=a$; y$:=b$; a$:=whatever; b$:=whatever; endfor enddef; def endradical = endgroup enddef; and then defined each radical to do something like: def futatsu(suffix @,$) = beginradical(@,$); % This used to be |beginradical(101,102,103,104)| x101=x@+thick; y101=y102=y$-thick; x102=x$-thick; x103=x@; y103=y104=y@+thin; x104=x$; horiz(101,102); horiz(103,104); endradical; enddef; The big difference in this approach is that rather than getting rid of the points I want to destroy, I keep the points I want to save. There's something wrong with TeX and MF... I wrote my best TeX macro while drunk and solved my hardest MF problem while asleep :-) - -dh ------------------------------------------------------------------ Don Hosek Internet: U33297@UICVM.UIC.EDU 3916 Elmwood Bitnet: U33297@UICVM.BITNET Stickney, IL 60402 DHOSEK@YMIR.BITNET Work: 312-996-2981 UUNet: dhosek@jarthur.claremont.edu JANET: U33297%UICVM.UIC.EDU@UK.AC.EARN-RELAY ------------------------------------------------------------------ --------------------------------- Date: Wed, 03 May 89 15:24:31 BST From: BOOTH.CM@UK.AC.EXETER Subject: European TeX courses at Exeter 1989 Message-ID: ADVANCE NOTICE EUROPEAN TeX COURSES on behalf of TUG Beginning/Intermediate TeX 10th--14th July 1989 Advanced TeX/Macro Writing 18th--22nd September 1989 Beginning METAFONT 26th--29th September 1989 These three courses are all taking place at Exeter University, using networked IBM-PC compatibles etc etc. Note the new METAFONT course (being given by Doug Henderson of PC METAFONT fame). Watch this space for more details, or contact me on: BOOTH.CM@EXETER Cathy Booth, University of Exeter Computer Unit, Maths & Geology Building, North Park Road, Exeter, EX4 4QE, Devon, U.K. Tel: Exeter (0392) 263945 --------------------------------- Received: by vulcan. (4.0/SMI-4.0) id AA05408; Wed, 3 May 89 17:41:41 BST Date: Wed, 3 May 89 17:41:41 BST From: alien@uk.ac.essex.ese.vulcan (Adrian F. Clark) Message-Id: <8905031641.AA05408@vulcan.> Subject: concrete fonts in LaTeX Sender: JANET"alien@uk.ac.essex.ese" (Adrian Clark) Has anyone out there yet written a "concrete LaTeX" :-) i.e., a style file to make Knuth's concrete fonts available to LaTeX users? Adrian F. Clark JANET: alien@uk.ac.essex.ese ARPA: alien%uk.ac.essex.ese@nss.cs.ucl.ac.uk BITNET: alien%uk.ac.essex.ese@ac.uk Smail: Dept. of Electronic Systems Engineering, Essex University, Wivenhoe Park, Colchester, Essex C04 3SQ, U. K. Phone: (+44) 206-872432 (direct) "The great tragedy of Science--the slaying of a beautiful hypothesis by an ugly fact." -- T H Huxley (1825-95) --------------------------------- Received: from UKACRL by UK.AC.RL.IB (Mailer X1.25) with BSMTP id 1601; Wed, 03 May 89 22:27:05 BS Received: from UICVM by UKACRL.BITNET (Mailer X1.25) with BSMTP id 6879; Wed, 03 May 89 22:19:54 B Received: by UICVM (Mailer R2.02) id 8996; Wed, 03 May 89 14:31:39 CDT Date: Wed, 03 May 89 14:31:26 CDT From: Don Hosek Subject: Second report from the TUG DVI Driver standards committee ********************************************************************** * Report from the DVI Driver standards Committee * ********************************************************************** By Tom Reid and Don Hosek The first few months of 1989 have shown a healthy increase in the discussion in the DVI driver standards discussion. For those people with network access, much has been done to provide for the dissemination of the information which has come through our hands. The group has a LISTSERV discussion group, DRIV-L, which is the primary means of communication between its members. The list is set up so that anyone who wants to contribute ideas may do so by sending mail to DRIV-L@TAMVM1 (Bitnet) or DRIV-L@TAMVM1.TAMU.EDU (Internet). These notes will be automatically be distributed to the membership of the group. Archives of past discussions as well as papers on the topic and the current versions of standards documentation, programs, and macros are stored on the Clarkson archive in the dvi-standard group. Individuals with FTP access may obtain the files from sun.soe.clarkson.edu in the directory pub/dvi-standard. Those without FTP access may still obtain the files via e-mail using the same mechanism as is used by the LaTeX style collection, substituting dvi-standard for latex-style where appropriate. For example, to obtain the file driv-l.log8809 and a list of other files, one might send a message to archive-server@sun.soe.clarkson.edu which looks like: path fschwartz%hmcvax.bitnet@clvm.clarkson.edu get dvi-standard driv-l.log8809 index dvi-standard By the TUG meeting in August, we hope to have much of the proposed standard documented and available from the archive. Bitnet users may also obtain log files from Listserv@tamvm1 by sending the command get driv-l log{\it yymm} to Listserv@tamvm1 where yy is the last two digits of the year and mm is the month, expressed as a two digit number. For example, to obtain the log from September, 1988, one would send the command get driv-l log8809 to Listserv. Listserv commands should be sent either as the first line of a single-line mail message or as an interactive message (TELL on CMS, SEND on VMS). The remainder of this article outlines some preliminary results of the committee's work. Persons interested in implementing portions of this standard should contact check the Clarkson archive or contact Robert McGaffey to obtain the most recent information on the standard. 1. \special commands The committee has decided that the \special commands defined to date will be labeled as "experimental" and later classified as "production" after they've undergone sufficient testing to justify the reclassification. Experimental \special commands are distinguished by the prefix X_. Further work on the precise syntactical rules for \special are under development. 1.1 Interface One of the early decisions of the committee was that \special will be treated as a primitive command which the end user should never need to type. Instead, \special should be accessed through a high level macro set. This has the additional advantage that users at beta test sites will usually not be affected by changes to the syntax or names of \special commands. This is important since when a \special changes status from "experimental" to "production," its name will change as noted above. The committee is developing macros for both plain TeX and LaTeX to interface with the developing standard. At the present time, only preliminary versions of these macros have been written, but a full macro set for both plain TeX and LaTeX should be be available by the publication time of this article. 1.2 Scope \special commands have been broken down into six classes depending on what portion of the DVI output they would affect. Global: These \special commands affect the entire document. Examples of this class of \special include commands for selecting duplex printing or setting the printing orientation (portrait, landscape, etc.). Page: These \special commands affect only the page on which they are printed. Examples of this class include requests for feeding of special paper from an auxiliary tray ({\it e.g.,\/} for a cover sheet) or a single-page change in orientation. Box: These \special commands affect a block of output that is enclosed in a TeX box (and thus is, by necessity on a single page). For example, a command to rotate a block of text would fall under this class. Delimited: These \special commands are those that affect a block of output which is not necessarily enclosed by a TeX box or contained entirely on a single page. For example, a \special command to set color would fall into this class. Output generating: These \special commands are those which generate self-contained output of some sort. For example, the X_vec \special of Section 1.3 falls into this class. Attribute setting: These \special commands modify the next output generating command which appears on the current page. If no output generating command follows an attribute setting command, the command is ignored and the DVI driver program should issue a warning. An example of this class of commands would be the X_linewidth \special described in Section 1.3. The remainder of this section will consist of additional notes on those classes of \special commands which need additional comment. Global specials Global specials, it has been decided, will be required to appear on the first page of the document. They will either be identified with a prefix (X_global:), delimited by a pair of \special commands (X_begin_globals ... X_end_globals) or some similar scheme. One issue that has not been decided is whether the first page containing the global \special commands should be the first page of text or a special page on its own. Having global options specified as part of the actual first page of text minimizes the impact on existing drivers. However, it does present some problems with existing macro packages in regard to ensuring that the options are output at the right place. This problem stems from the fact that the \special commands used to convey the options to the drivers are normally placed in the body of the document. Macro packages which place headline text or entirely separate title pages prior to writing the first part of the "body" of the document will cause text to appear in the DVI file before the global options. Headline text may or may not have any impact upon the global options, but separate title pages will prevent the global options from being on the first page of the DVI file. To get around this problem, the mechanism used for passing global information will need to "cooperate" with the output routine within the macro package. Requiring an entirely separate page at the start of the DVI file avoids the need for special interaction with the output routines of various macro packages. Instead of placing \special commands in the body of the first page, a separate macro is used which issues a separate \shipout containing the \special commands. This approach makes things easier for programs which sort or otherwise reorganize a DVI file since no culling of global options from the first text page is necessary. However, the separate page technique has an undesired effect: it produces a blank page on existing drivers which do not understand the options page. Box specials A box \special command, since it will always be entirely typeset on a single page, will be enclosed in a TeX box (\hbox or \vbox). In the DVI output, box structure is reflected by surrounding push and pop commands. For example, the TeX commands: normal \hbox{\special{abc} special} text generate the following DVI code: "normal" push right xxx "abc" "special" pop right "text" A DVI driver can exploit this for a command such as X_rotate by maintaining on the DVI stack, values for items such as rotation_angle. Delimited specials The committee has not found an effective way to deal with open block \special commands yet. They will probably need to be issued in cooperation with the output routine, to insure that every delimited command is broken down into matching pairs of \special commands on each page within its bounds. This approach is necessary for two reasons: o If pages are reordered for any reason (e.g., reverse ordering for laser printers which stack output face up) the driver should not need to have to scan the entire file to insure that it does not inadvertently break up a pair of \special commands producing a delimited command. o Without special care being taken, an delimited command which spans pages may inadvertently affect page headers and footers which are typeset between the beginning and ending blocks. 1.3 Graphics commands Three techniques for including graphics have been discussed. These are: 1. Make graphics entirely with TeX primitives. 2. Use METAFONT to build a graphic as a font. 3. Allow the driver to include a device-specific graphic. Graphics by TeX Handling graphics entirely with TeX macros and primitives which use dots or characters from a special graphics font is a technique which has been in use for some time. The LaTeX picture environment and PiCTeX work in this way with the former assembling characters from a graphic font and the latter using closely spaced dots. In TUGboat 10(1), (This article also appeared in TeXhax.89.007) David F. Rogers proposed a series of TeX macros to provide plotting primitives; these macros would generally be used by TeX input generated by some graphics package. The macros which were proposed created graphics by closely spacing dots along each line in the same manner as PiCTeX. The problem posed by creating graphics in this manner is that TeX must store all of the graphic elements in memory at once for an entire page quickly exceeding TeX's capacity. To calculate the memory needs, the technique for positioning each dot was defined. This is: \kern\DX \raise\Y \hbox{\DOT}% where \DX is a dimension register giving the displacement in the "x" direction from the previous point and \Y is a dimension register giving the displacement in the "y" direction from the reference point of the graph. \DOT defines the plotting symbol and \DX accounts for the width of this symbol. In memory, TeX saves \kern\DX in a kern node, the raised hbox in an hlist node, and the plotting symbol in a char_node. These take two words, seven words, and one word of memory, respectively, for a total of ten words per dot. A normal-size implementation of TeX with 64k-words of memory allows about 6000 dots to be positioned before it runs out of memory (assuming that no other macros are loaded and neglecting other text on the page). Spacing the dots at 100 per inch, this gives about 60 inches which is not sufficient for many graphs. To enhance the capacity of this graphics technique, we decided to use a \special to add a vector drawing capability to TeX and DVI drivers and use the \special instead of closely-spaced dots. This changes the TeX command sequence to: \kern\DX \raise\Y \hbox{% \special{X_vec \number\XC \space \number\YC}% where \XC and \YC are dimension registers giving the components of the vector. Component values in scaled points are likely to be six-digit numbers with an additional minus sign for negative numbers. Thus, an average length for the \special string is likely to be around 18 characters. In memory, a \special is saved in a two-word whatsit node which points to the \special string. Thus the total memory needs, counting the kern and hlist nodes, will average 29 words per vector which allows roughly 2000 vectors. This may be sufficient for many graphs, but falls somewhat short for complex three-dimensional surface plots. (One sample 3D surface plot consisted of 13,000 vectors.) Two \special commands have been defined for graphics of this sort (and specialized commands for more complicated graphic elements will be defined in the future). The commands defined are: X\_linewidth n: Specify that the following vector is to be drawn with a line width of n DVI units (scaled points for TeX). Vectors are normally 1 point in width. If no vector follows the X_linewidth \special on this page, the command is ignored and the DVI driver program should issue a warning. X\_vec Dx, Dy: Draw a diagonal line from the current point to the point which is offset by Dx and Dy from the current point. Dx and Dy are specified in terms of DVI units. Graphics by METAFONT A different approach to graphics inclusion is to use METAFONT to produce the graphic as a character of a font and position it using TeX's normal character positioning capabilities. The advantage of this technique is that the graphic is in a format which many drivers will already accept. METAPLOT by Pat Wilcox (See the AmigaTeX notes of March 12, 1989 or TeXMaG V3N3 for information about this package.) is one example of a package which takes this approach. However, the technique has a number of drawbacks: Graphic fonts are resolution-dependent; a separate graphic font is needed for different resolution devices. METAFONT records changes in pixel values across a scan line when it builds a character. Thus, the memory needs depend upon the complexity of the graphic in addition to the size and resolution of the device. To circumvent this limitation, it is necessary to break the whole graphic into smaller pieces. It is important to ensure that the heights and widths of each piece are integral numbers of pixels to allow them to be reassembled without the alignment problems which occur for letters within words. Including device-dependent files With this approach, the DVI driver processes a special Graphics Description File (GDF) which, among other things, indicates the names and formats of separate graphic files in device-dependent format. A driver searches this list to find a file in a format appropriate for the device it supports. This allows a greatly simplified graphic files to be defined for previewing purposes while a detailed, higher resolution version is used when the DVI file is printed. GDF files are processed both by TeX and by the DVI driver. TeX \inputs the file and executes code at the start of the file. This code sets some dimension and box registers giving the size of the graphic then terminates with an \endinput to return control to the macro which did the \input. The portion of the GDF file following the \endinput is processed by the driver. The driver section of the file consists of a series of keywords which identify lines that apply to a particular graphics format, rotation, etc. The driver scans these lines searching for a format which it understands. Depending on the driver and the graphics format, additional lines may have to be searched for other attributes such as rotation. Eventually, the name of the graphics file to be included will be found and the driver will incorporate it into the output file. In TUGboat 10(1), Bart Childs, Alan Stolleis, and Don Berryman suggested another scheme for using \special for inclusion of device-dependent graphics files in "A portable graphics inclusion." 2. Additional reference material In addition to the works mentioned in the Editor's note at the end of our last report, the following may also be of interest: Guntermann, Klaus and Joachim Schrod. "High quality DVI drivers" Available from the Clarkson archive as the file schrod-guntermann1.tex Hosek, Don. "Proposed DVI \special command standard" Available from the Clarkson archive as the file hosek1.tex. In addition, anyone interested in implementing any portion of the developing standard should read the logs available from the Clarkson archive or Listserv@tamvm1. ------------------------------------------------------------------ Don Hosek Internet: U33297@UICVM.UIC.EDU 3916 Elmwood Bitnet: U33297@UICVM.BITNET Stickney, IL 60402 DHOSEK@YMIR.BITNET Work: 312-996-2981 UUNet: dhosek@jarthur.claremont.edu JANET: U33297%UICVM.UIC.EDU@UK.AC.EARN-RELAY ------------------------------------------------------------------ --------------------------------- Date: Thu, 04 May 89 12:27:39 From: PM1MJP @ SHEFFIELD.PRIMEA Subject: APPENDICES AT THE END OF CHAPTERS From +-------------------------------------+ | Dr M J Piff, | | Department of Pure Mathematics, | | University of Sheffield, | | The Hicks Building, | | Hounsfield Road, | | SHEFFIELD S3 7RH, | | England. | | Tel. SHEFFIELD(0742)768555 Ext 4431 | | JANET address: PM1MJP@UK.AC.SHEF.PA | +-------------------------------------+ Subject: Dave Cook's request for a way of putting appendices in chapters. % Dear Dave, % The following seems to work, by setting up chapters locally. It is set % up to only do a \clearpage with each appendix, rather than a \cleardoublepage. % The problem with the table of contents marking is that there is a fixed % width box for each sectional number, and you can easily overflow this width % by having too many chapters. The l@part and l@chapter set \@tempdima, % and the other l@ commands use the third parameter to \l@dottedtocline to % set the width of the boxes. Thus, if your manual has a lot of chapters, % and appendices up to M say, I suggest you set these values pretty large. % The following should work for up to 99 chapters, and 26 appendices to each! % Mike. \documentstyle{book} \newcounter{SavedChapter} \makeatletter \def\l@chapter#1#2{\pagebreak[3] \vskip 1.0em plus 1pt % space above chapter line \@tempdima 2.6em % width of box holding chapter number \begingroup \parindent \z@ \rightskip \@pnumwidth \parfillskip -\@pnumwidth \bf % Boldface. \leavevmode % TeX command to enter horizontal mode. #1\hfil \hbox to\@pnumwidth{\hss #2}\par \endgroup} \def\l@section{\@dottedtocline{1}{1.5em}{3.4em}} \def\l@subsection{\@dottedtocline{2}{3.8em}{4.3em}} \def\l@subsubsection{\@dottedtocline{3}{7.0em}{5.2em}} \def\l@paragraph{\@dottedtocline{4}{10em}{6.1em}} \def\l@subparagraph{\@dottedtocline{5}{12em}{7.1em}} \newenvironment{Appendix}{% \setcounter{SavedChapter}{\arabic{chapter}} \setcounter{chapter}{0} \def\thechapter{\arabic{SavedChapter}.\Alph{chapter}} \def\@chapapp{Appendix} \def\chapter{\clearpage \thispagestyle{plain} \global\@topnum\z@ \@afterindentfalse \secdef\@chapter\@schapter} \def\@chapter[##1]##2{\ifnum \c@secnumdepth >\m@ne \advance\c@chapter 1 \edef\@currentlabel{\p@chapter \thechapter} \typeout{Appendix\space\thechapter.} \addcontentsline{toc}{chapter}{\protect \numberline{\thechapter}##1}\else \addcontentsline{toc}{chapter}{##1}\fi \chaptermark{##1} \addtocontents{lof}{\protect\addvspace{10pt}} \addtocontents{lot}{\protect\addvspace{10pt}} \if@twocolumn \@topnewpage[\@makechapterhead{##2}] \else \@makechapterhead{##2} \@afterheading \fi} }{\setcounter{chapter}{\arabic{SavedChapter}}} \makeatother \begin{document} \tableofcontents \setcounter{chapter}{55} \chapter{one}\null \begin{Appendix} \setcounter{chapter}{12} \chapter{Appendix 1.A}\null \chapter{Appendix 1.B}\null \end{Appendix} \chapter{two}\null \end{document} --------------------------------- Date: Thu, 4 May 89 12:49 GMT From: DR. JOHN CARROLL, NIHE, DUBLIN 9 <75003678@VAX1.NIHED.IE> Subject: EPSON LQ Compatible Hello Peter, We have am EPSON LQ 1500 compatible printer in NIHE (the model is in fact a STAR NB 24-15 which I understand is quite popular in the UK). Do you know if a TeX driver exists for such printers (in the Archive or elsewhere). Your advice will be appreciated. Best wishes, John Carroll ~~~~~~~~~~~~ --------------------------------- From: Sebastian Rahtz Date: Thu, 4 May 89 19:35:12 BST Message-Id: <26177.8905041835@hilliard.ecs.soton.ac.uk> Subject: dvi to PS programs There is considerable confusion over public domain dvi to PostScript drivers. The Aston archive contains a number of different offerings, and it might be helpful to list them here, in a rearranged setup which I hope Archive users will find useful. The drivers are all to be found in [TEX-ARCHIVE.DRIVERS.DVI2PS] There are other systems in [TEX-ARCHIVE.DRIVERS] which create PostScript, but these are the obvious ones commonly in use: [.CARLETON] The original Unix Carleton/MIT version (Neil Holtz etc), now more or less redundant. No support for PS fonts. [.OOSTRUM] A much newer and improved version of Carleton by Piet van Oostrum, which uses PostScript fonts etc (as recently posted on eeunet). [.DVI-TO-PS] An update of Carleton, done in parallel with Oostrum, from Washington. Does not use PS fonts (I think). [.PSDVI] A PS fonts *only* program, presumably of limited use! [.DVITOPS] A completely new program by James Clark, supporting PS fonts, figures etc. If you want to include PS figures, you need the `psfig' macros for all but dvitops, which includes builtin support for EPSF files. Stephan Bechtolsheim's "yet another dvi2ps", called dvitps, is being obtained at the moment. The other obvious ones to try, if none of these have what you need, are Trevorrow's PSPRINT (but that is Vax specific, I believe), and the commercial offerings of Arbortext and Personal TeX. What to do, if you are just entering the field? My advice would be as follows: a) are you a VMS Vax? get Trevorrow's software. well-tested and in widespread use b) are you a fairly standard Unix site? get Clark's dvitops or Oostrum's dvi2ps. If you want a choice of TeX or Adobe encoding, Clark or Bechtolsheim offer specific support. c) MSDOS? Dominik Wujastyk reports success with dvitops. d) do you want some LaTeX font setups and style files? you'll find offerings of amended lplain.tex & lfonts.tex and/or style files in: [TEX-ARCHIVE.DRIVERS.DVI2PS.OOSTRUM] [TEX-ARCHIVE.DRIVERS.DVI2PS.DVITOPS] [TEX-ARCHIVE.FONTS.ADOBE.PSLATEX.WOLCSKO] [TEX-ARCHIVE.FONTS.ADOBE.PSLATEX.TAYLOR] Its not obvious which are "best". I'll leave recommendations to others! Would anyone care to comment on the above, and flesh out this catalogue? Where do all those DEC printers called LN0* fit into this? Sebastian Rahtz --------------------------------- Date: 4-MAY-1989 22:08:31 GMT From: EFIA4580@UK.AC.QUEENS-BELFAST.CENTRE.VAX1 From : S.Gilmore@uk.ac.qub.v1 Stephen Gilmore Department of Computer Science The Queen's University of Belfast University Road Belfast BT7 1NN Northern Ireland Dear Mr. Abbott, I'd like to get the AMS symbol founts for our VAX/VMS implementation of LaTeX. I was able to get the 10 point PXL files from [PUBLIC.TEX.AMSFONTS.PXL300] but I cannot find 11 or 12 point versions. I tried to make them from the 329 and 360 PL files but without success - in particular DVItoVDU crashes when using the PXL files (which I generated using PKtoPXL). Do 11 and 12 point versions exist for the VAX? If so, could you get them for the archive? I'm not a TeXnician: just a Formal Methodist seduced into computer typesetting. It may be possible to make the larger point files with the tools available but I don't know how. Thank you. Yours sincerely, Stephen Gilmore --------------------------------- Date: Fri, 5 May 89 9:43 GMT + 1200 From: TeXnician Subject: Linotronic 300 mode_def Mode Def for Linotronic 300. Could somebody please supply me with the appropriate METAFONT mode_def for a Linotronic L300 PostScript imagesetter. I would like to produce camera-ready of a LaTeX document that uses the Times Family of fonts (PostScript version) but also the CM Symbol (10pt only) and the CM Uppercase Greek (10pt) which I have hacked out of the CMR10 font. Only these 2 CM fonts are used in this document and the Greek font only consists of 12 (or 14?) characters. Also, what resolution is it best to produce them (i.e., the CM fonts used) at---1270 or the full 2540dpi? Why I am on the subject---the new Compugraphic 9600P PostScript image setter looks pretty good (and reasonably priced albeit too expensiove for us at this stage). Has anybody had any experience with it yet? What about the new Varityper 4300P PostScript Imagesetter? Both of them look superior (and cheaper---at least in New Zealand) than the comparable Linotronic L200. Graeme McKinstry Computing Services Centre, University of Otago, Dunedin, NEW ZEALAND. E-mail: graeme%otago.ac.nz@relay.cs.net --------------------------------- !! !! Files of interest !! [public]000aston.readme [public]000directory.list !! [public]000directory_dates.list [public]000directory.size !! [public]000last30days.files !! !! Editor - I have a tape labelled TeX 2.95 LaTeX 2.09 Metafont 1.7 !! Unix 4.2/3BSD & System V. Tar 1600 bpi blocked 20 1 file dated !! 30 January 1989 (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. !! !! 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 !! !! Replies/submissions to info-tex@uk.ac.aston please !! distribution changes to info-tex-request@uk.ac.aston please !! !! end of issue