----------------------------------------------------------------------------- UKTeX V90 #24 Friday 27 July 1990 ----------------------------------------------------------------------------- Today's topics: RE: placement of figures RE: DVI Driver for HP DeskJet+ RE: For UKTeX Re: 24 pin Epson printer driver RE: Landscape mode for HP Laserjet driver? Re: funnies in the Aston archive RE: New Version of TeX The Level 0 Draft standard (v 0.03) -- Request for comments Specification of algorithim for handling rounding to device units Notes on: mode_def for IBM 4216 printer? further funnies in the Archive. LaTeX book style TeXserver gains reverse-address sanity \errorcontextlines setting in LaTeX HP DeskJet driver (dvidjp.c) Problems with TFM files PostScript previewer for VAXstation 3100? Seeking Questionnaires from the TUG '90 Meeting in TeXas... bibtex OzTeX hash size increase \pmod ----------------------------------------------------------------------------- Moderator: Peter Abbott This issue edited by: David Osborne (University of Nottingham) Submissions: uktex@uk.ac.aston Administration: uktex-request@uk.ac.aston Back Issues: These are stored in the Aston archive, in the directory DISK$TEX:[TEX-ARCHIVE.DIGESTS.UKTEX.90] Latest TeXhax: #51 Back Issues: These are stored in the Aston archive, in the directory DISK$TEX:[TEX-ARCHIVE.DIGESTS.TEXHAX.90] Latest TeXmag: V4 N2 Back Issues: These are stored in the Aston archive, in the directory DISK$TEX:[TEX-ARCHIVE.DIGESTS.TEX-MAG] ----------------------------------------------------------------------------- Subject: RE: placement of figures Date: Mon, 16 JUL 90 12:05:43 BST Originally-from:P.TAYLOR@UK.AC.RHBNC.VAX Sebastian --- >anyone out there having a rainy weekend and wants something to think >about? I am preparing a longish book with LaTeX (200 pages) with a lot >of floating tables and figures. the publisher complains, rightly, that >there are occasions when I refer to a table/figure on a right hand >page, and the object itself comes on the following left-hand page, >forcing the reader to keep turning the page (as opposed to flicking). >The figure is inserted in the text at the same place as the reference. > >SO, anyone got any suggestions about how to fix this up? it strikes me >as almost impossible to do algorithmically, even if LaTeX understood >about forcing tables/figures onto odd-numbered pages. Ian Gibson and I spent a lot of time investigating this problem in the preparation of "The Principles of Nutrional Assessment", and ended up fine-tuning the TeX source to achieve the desired end. `while' there are still figures in the wrong place `do' `begin' `edit' the TeX source, adjusting the positions of figures and refs; `TeX' the resulting file; `Preview' the resulting DVI file 'end [An algorithm if ever I saw one ..... !] ** Phil. ------------------------------ Subject: RE: DVI Driver for HP DeskJet+ Date: Mon, 16 JUL 90 15:32:53 BST Originally-from:P.TAYLOR@UK.AC.RHBNC.VAX Ben --- >Does anyone know of a good DVI driver (for MSDOS) for an HP DeskJet of >DeskJet Plus? RUMDJET. A copy has been distributed to the Archive group, and a copy will probably appear in the UK TeX archive in the near future. ** Phil. ------------------------------ Subject: RE: For UKTeX Date: Wed, 18 JUL 90 11:56:06 BST Originally-from:P.TAYLOR@UK.AC.RHBNC.VAX >13 July 1990 >Your reference >Our reference IC/SAS/0090Z/15 >Extension 2640 > >Dear peter, > >Further to our telephone conversation today, I confirm that I would be >interested in anywhere that Lloyd's of London could acquire .pk files for >the following TeX fonts (I have the .trm's): > >Palatino >New Century Schoolbook >Times >Zapf Chancery >Zapf Dingbats >Bookman >Courier >Helvetica The gentleman should be advised to contact Richard Kinch, of the Kinch Computer Company, 501 S. Meadow St., Ithaca, New York 14850, who will be pleased to supply these fonts in all canonical sizes for a mere $200-00. ** Phil. ------------------------------ Subject: Re: 24 pin Epson printer driver Date: Wed, 18 Jul 90 16:37:19 bst Originally-from:SPQR@UK.AC.SOUTHAMPTON.ECS NDN@UK.CO.NATIONAL-PHYSICAL-LAB.SEG writes: > The title says it all really - does anyone know of a DVI driver > giving output for 24 pin Epson printers? the emTeX package offers these; god knows if any of them have 24 pins. dvifx Epson FX-80/100 (horizontal resolution 240dpi, 216dpi vertical) dvip6l NEC P6/P7 (180dpi) dvip6m NEC P6/P7 (horizontal resolution 360dpi, 180dpi vertical) dvip6l NEC P6/P7 (360dpi) dviitoh C.Itoh 8510A dviaiw Apple Imagewriter sebastian ------------------------------ Subject: RE: Landscape mode for HP Laserjet driver? Date: Wed, 18 JUL 90 18:20:35 BST Originally-from:P.TAYLOR@UK.AC.RHBNC.VAX Nick --- >Is there available a driver for the HP Laserjet which supports >landscape mode? There is some correspondence in the Beebe collection >which suggests that one exists but there is no code for it. Any help >gratefully received, I think you will find that one of the EM-TeX drivers will do landscape (and considerably more besides). ** Phil. ------------------------------ Subject: Re: funnies in the Aston archive Date: Thu, 19 Jul 90 16:31:06 bst Originally-from:SPQR@UK.AC.SOUTHAMPTON.ECS CUDAT@UK.AC.WARWICK.CU writes: > While looking through the Aston archive a week or two ago I > found the following things:- thanks for taking the trouble to look! > The file [TEX-ARCHIVE.LANGS.XETTEX]00README.TEX doesn't seem to say > an awful lot. deleted > The file [TEX-ARCHIVE.FONTS.CMFONTS.PK.PK300]CMR10.300PK > seems to contain a bad fount. (I did remember not to copy it as a > text file, and several other founts in the same directory > seem fine.) I have sent a fresh copy. > The file [TEX-ARCHIVE.TEX.MS-DOS.EMTEX]DVIDRV.ENG seems to differ > substantially from the file called DVIDRV.ENG in the archive > in ENGDOC.BOO . hmm. odd. I have sent a fresh copy anyway > The file [TEX-ARCHIVE.DOC]ARCHIVE.TEX doesn't mention the > [TEX-ARCHIVE.TEX.MS-DOS....] directory. that file is way out of date; I have deleted it > Many thanks to the archivists for looking after all the goodies, > and I hope the above remarks help to make things even better. keep 'em coming! sebastian ------------------------------ Subject: RE: New Version of TeX Date: Fri, 20 JUL 90 16:34:02 BST From: TEX@UK.AC.CRANFIELD.RMCS TeX V3 for VAX/VMS ~~~~~~~~~~~~~~~~~~ In response to popular demand from those who don't have the resources and/or inclination to build TeX v3 from sources, I have installed the following VAX/VMS .OBJ files at Aston, together with other files required to run TeX. They are provided as object files to permit you to link them under your current version of VMS, since some users are still on v5.0 (or earlier) whilst others are more up-to-date. This version of TeX requires that you SET COMMAND TEX, using the TEX.CLD file to be found in [TEX-ARCHIVE.TEX.V3.VMS] at Aston. Don't forget to move the .FMT files, and TEX.POOL, into TEX$FORMATS: The distributed version of TEX.CLD expects the .EXE files to reside in TEX$EXE, but this can be changed with an editor. But TeX itself ONLY looks in TEX$FORMATS for its pool file. [TEX-ARCHIVE.BINARY.VMS]BIGINITEX.OBJ [TEX-ARCHIVE.BINARY.VMS]BIGTEX.OBJ [TEX-ARCHIVE.BINARY.VMS]BIG_TRIP.OBJ [TEX-ARCHIVE.BINARY.VMS]DVITYPE.OBJ [TEX-ARCHIVE.BINARY.VMS]INITEX.OBJ [TEX-ARCHIVE.BINARY.VMS]LPLAIN.FMT [TEX-ARCHIVE.BINARY.VMS]PLAIN.FMT [TEX-ARCHIVE.BINARY.VMS]PLTOTF.OBJ [TEX-ARCHIVE.BINARY.VMS]POOLTYPE.OBJ [TEX-ARCHIVE.BINARY.VMS]SPLAIN.FMT [TEX-ARCHIVE.BINARY.VMS]TANGLE.OBJ [TEX-ARCHIVE.BINARY.VMS]TEX.OBJ [TEX-ARCHIVE.BINARY.VMS]TEX.POOL [TEX-ARCHIVE.BINARY.VMS]TFTOPL.OBJ [TEX-ARCHIVE.BINARY.VMS]TRIP_INITEX.OBJ [TEX-ARCHIVE.BINARY.VMS]WEAVE.OBJ Brian {Hamilton Kelly} +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + 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) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------------ Subject: The Level 0 Draft standard (v 0.03) -- Request for comments From: Don Hosek Date: Sat, 21 Jul 1990 20:05 PDT Originally-To: texhax@edu.washington.cs.june, infotex@uk.ac.aston, tex-euro@bitnet.dhdurz1 Below is the Level 0 standard (draft 0.03) which will be in its final form for publication in the last regular issue of TUGboat for 1990. In the last month before the standard is being put in its final form, the TUG DVI standards committee is soliciting opinions from the TUG membership. If you have any comments about the specifications listed below, please send them to dhosek@ymir.claremont.edu, or, if that does not work, dhosek@ymir.bitnet. The appendices referenced are taken more-or-less directly from the descriptions of the file formats in DVItype, GFtype, PKtype and TFtoPL. The rounding error appendix will be sent separately. ----------------------------------------------------------------------- \documentstyle[ltugboat]{article} \title{A Draft Proposal for the ``Level~0'' {\tt DVI} Driver Standard} \author{Don Hosek\thanks{On behalf of the TUG {\tt DVI} Driver Standards Committee}} \makeatletter \newcounter{impnote} \def\theimpnote{\alph{impnote}} \def\impnote#1{{\def\@mpfn{impnote}% \let\thempfn=\theimpnote \footnote{#1}}} \makeatother \def\tensl{\sl} \let\App=\appendix \def\appendix{\App\small} % tighten up the ending pages of the standard. \hbadness=9999 % Cut down the amount of annoying messages generated... % For file format descriptions: \def\res#1{{\bf #1}} \def\sty#1{{\it #1}} \begin{document} \maketitle \emergencystretch=\hsize \divide\emergencystretch by 10 % I think this will encourage 10 words/line \begin{abstract} The following represents a minimal standard (level~0) for {\tt DVI} drivers. The complete standard will be presented as a series of ``tiers'' requiring increasingly stringent control over the output of {\tt DVI} drivers. A trip test for {\tt DVI} drivers will be created which will allow developers of {\tt DVI} drivers to insure that their drivers meet the standards developed here. The specifications here should be considered minimal and driver developers are encouraged to write drivers whose capabilities are beyond these specifications. This version of the Level~0 Standard presented here is draft~0.03. It has been reviewed by the TUG Driver Standards Committee and is now being presented to the TUG membership at large for review. This will form one portion of the TUG {\tt DVI} Driver Standard. \end{abstract} \section{Purpose of the Level~0 standard} The Level~0 Standard is meant to be a base standard to which all drivers should adhere. It is intended to allow all reasonable applications to be printed on all drivers. The basis for many of the specifications in this standard is the possible output of \TeX82; functions which can be implemented via a pre-processor are generally omitted ({\em e.g.,\/} page selection and sorting). Footnotes beginning with a letter are implementation notes and are hints on handling difficult circumstances for printers. \section{The {\tt DVI} file} As a rule, {\tt DVI} drivers should be able to interpret any {\tt DVI} file which falls within the following limits. These specifications are a {\em minimum\/}; good drivers will probably be able to handle {\tt DVI} files exceeding these limits ({\tt DVI} files which exceed the limits are likely to be rare, but might still occur). \subsection{{\tt DVI} commands} The driver should be able to interpret every {\tt DVI} command listed in appendix~\ref{dvi-format}. % See file dvi.tex \subsection{Characters} \subsubsection{Number of characters in a {\tt DVI} font} The driver should be able to handle fonts which have characters at any code in the range $0\le c<256$.\impnote{Some output devices will require {\tt DVI} fonts with more than a given number of characters to be broken into two or more device fonts when downloaded to the printer.} \subsubsection[{\tt DVI} character size]{{\tt DVI} character size\footnote{The values presented here and in the following sections are preliminary and subject to modification.}} The driver should be able to print any character up to a size of 600pt (horizontal) by 800pt (vertical).\impnote{Note that some output devices will require breaking down such a character into smaller pieces or drawing the character in graphics mode.} \subsubsection{Number of {\tt DVI} characters per page} The driver should be able to print a page containing as many as 20,000 {\tt DVI} characters. \subsubsection{Unusual characters} The driver should correctly handle (a)~characters with empty bitmaps ({\em e.g.,\/} the \SliTeX\ fonts) including characters whose horizontal escapement is~0, (b)~characters whose printable image is wider than its horizontal escapement, and (c)~characters with a negative horizontal escapement. \subsection {Rules} \subsubsection{Rule size} The driver should be able to print rules of any size up to 600pt (horizontal) by 800pt (vertical). \subsection{Number of rules per page} The driver should be able to print a page containing as many as 1000~rules. \subsection{Stack} The driver should have, as a minimum, a stack depth of 100 for {\tt DVI} {\it push\/} and {\it pop\/} commands. \subsection{Positioning on the page} \subsubsection{Location of the origin} The point $(0,0)$ in {\tt DVI} co\"{o}rdinates should be located at a point one inch from the top of the page and one inch from the left side of the page. \subsubsection{Changes in position due to characters and rules} The driver should accurately track movement using the pixel width from the font raster file and the {\tt TFM} width from either the font raster file or {\tt TFM} file with the {\tt TFM} width from the font raster file taking priority. This is described in appendix~\ref{rounding-algorithim}. Positioning of rules is handled similarly with the rounding done using the algorithim in appendix~\ref{rounding-algorithim}. The {\tt TFM} format is described in appendix~\ref{tfm-format}. \subsubsection{Range of movement} The driver should be able to handle movements in the {\tt DVI} file up to a total of $2^{31}$ {\tt DVI} units in any direction from the origin. \subsubsection{Objects off of the page} Any printable object which would lie entirely off the physical page should not be printed but any changes to positioning should still be taken into consideration. Any printable object which would lie partially off the physical page should either be clipped so that portion of the object that lies off the page is not printed or omitted entirely. \subsection{Fonts} \subsubsection{Font numbers} The driver should be able to accept font numbers (the parameter $k$ given by the {\it fnt\_def\/} command) in the range $0\le k<256$. \subsubsection{Distinct {\tt DVI} fonts} The driver should be able to handle any document containing 64 or fewer distinct {\tt DVI} fonts. \subsection{Specials} The Level~0 Standard requires no support for specials. Specials not officially defined by the {\tt DVI} driver standards committee should be flagged with a warning when read from the {\tt DVI} file. If any specials are ignored by the driver, the driver must issue a warning message. \section{Configuration} It should be possible for the installer of a driver to configure such things as the location and naming scheme of fonts, default paper size, etc.\ without having to recompile the driver. \section{Font files} \subsection{Font formats} The driver should be able to read {\tt PK} fonts with the location specifiable at run time. The {\tt PK} format is given in appendix~\ref{pk-format}. {\tt GF} support is optional. The {\tt GF} format is given in appendix~\ref{gf-format}. \subsection{The scaling number} The magnification and resolution of a font are incorporated into a scaling number of one of two types: \begin{description} \item[Magnification number] The magnification number is given by $5\times {\it resolution} \times {\it magnification\/}$ where the resolution is given in dots per inch (on devices with a non-unit aspect ratio, the horizontal resolution should be used) and a magnification of 1 indicates no magnification. This is an old naming scheme derived from the old 200~dpi \item[Resolution number] The resolution number is given by ${\it resolution} \times {\it magnification}$ where both values are as above. This is the preferred specification for {\tt GF} and {\tt PK} files. \end{description} \subsection{Magnifications} \subsubsection{Minimum set of magnifications} At the minimum, the driver should be able to load fonts at the following magnifications of its target resolution: 1.0 (magstep0), 1.095 (magstephalf), 1.2 (magstep1), 1.44 (magstep2), 1.728 (magstep3), 2.074 (magstep4), 2.488 (magstep5), 2.986 (magstep6), 3.583 (magstep7), 4.300 (magstep8), and 5.160 (magstep9). However, driver authors are encouraged to support all possible magnifications. \subsubsection{Margin of error} If a {\tt DVI} file requests a magnification within 2\,\% of a supported magnification, the driver should use that font without warning. \subsection{Missing fonts} If a font is missing the driver should continue processing and deal with the missing font in one of three ways: \begin{enumerate} \item Insert appropriate white space where the font would appear, \item Insert black rectangles of the size of the font given in the {\tt TFM} file, \item Print the characters from that font at a different size or from another font at the same size after issuing a warning. \end{enumerate} If methods 1 or 2 are used and the driver is unable to locate size information for the font in question, then the driver may simply ignore any {\it set\_char\/} or {\it put\_char\/} commands that occur while the current font is that font. Under no circumstances should a missing font cause a fatal error. \appendix % All appendices ommitted... for this distribution. The complete % standard can be obtained from ymir.claremont.edu in % [anonymous.tex.dvi-standard] % Mailserv users should send the command % SEND [TEX.DVI-STANDARD]00README.TXT % to find out what files are needed. %\input{dvi.tex} %\input{gf.tex} %\input{pk.tex} %\input{tfm.tex} % \input{vf.tex} %Since VF files are not referenced in level 0, % this is omitted for brevity's sake. \end{document} ------------------------------ Subject: Specification of algorithim for handling rounding to device units (v0.01) -- Request for Comments From: Don Hosek Date: Sun, 22 Jul 1990 14:37 PDT Originally-To: driv-l@bitnet.tamvm1, texhax@edu.washington.cs.june, infotex@uk.ac.aston, tex-euro@bitnet.dhdurz1 \documentstyle{article} \begin{document} \def\abs{{\rm abs}} \def\DVI{{\tt DVI}} \section{Handling rounding to device units---modified {\tt DVItype} algorithim} The algorithims presented here are adapted from {\tt DVItype}; they represent the base algorithim for handling rounding of co\"ordinates and widths of objects to device units. \subsection{Rounding \DVI\ units to device units} Whenever it is necessary to round some dimension given in \DVI\ units to the corresponding quantity in device units\footnote{For raster-oriented devices, this would be the distance between spots in the output. For other devices, this refers to the minimum addressable distance change, {\em e.g.,\/} on a pen-plotter, it would be the minimum pen step. Device units do not necessarily correspond to dot size and this distinction should be respected in writing a \DVI\ driver.} the conversion should be done as $\lceil Kn\rceil$ where $n$ is the dimension in \DVI\ units and $K$ is a constant which converts from \DVI\ units to device units.\footnote{Devices with non-unit aspect ratios will need to maintain separate constants for vertical and horizontal dimensions.} This description will use ${\it pixel\_round}(n)$ to refer to $\lceil Kn\rceil$. \subsection{Keeping track of the current horizontal and vertical position} The definition of \DVI\ files refers to six registers, $(h,v,w,x,y,z)$, which hold integer values in \DVI\ units. In practice, we also need registers ${\it hh}$ and ${\it vv}$, the pixel analogs of $h$ and $v$, since it is not always true that ${\it hh}={\it pixel\_round}(h)$ or ${\it vv}={\it pixel\_round}(v)$. Whenever the \DVI-reading program encounters an instruction that changes the current position, it should update $h$ and $v$ using pure \DVI\ units. If the change in position is due to a {\it set\_char} command, the driver should add the x-escapement value from the {\tt PK} or {\tt GF} file to $\it hh$ to get the new value for $hh$. For a horizontal movement from any other command, ${\it hh}$ should be set to be ${\it hh}+{\it pixel\_round}(x)$ if $x<0.2{\it quad}$ for a horizontal movement to the right or if $x>-0.9{\it quad}$ for a horizontal movement to the left. $\it quad$ is defined to be the design size of the current font in the \DVI\ file (after all necessary magnifications have been applied). If $x$ exceeds the bounds outlined above, ${\it hh}$ is set to be ${\it pixel\_round}(h+x)$. In this way, rounding errors are absorbed by interword spaces. For a vertical movement, ${\it vv}$ is set similarly except that $\it vv$ is set to ${\it vv}+{\it pixel\_round}(y)$ if $-0.8{\it quad}{\it max\_drift}$. If it is, then $\it max\_drift$ is added or subtracted to $hh$ to bring it closer to $Kh$. A similar check is made with $\it vv$ and $v$. $\it max\_drift$ should be set to $2$ for output devices with device units smaller than or equal to $1/200$ inches and $1$ for output devices with device units with device units greater than $1/200$ inches. \end{document} ------------------------------ Subject: Notes on: From: Don Hosek Date: Sun, 22 Jul 1990 14:43 PDT Originally-To: driv-l@bitnet.tamvm1, texhax@edu.washington.cs.june, infotex@uk.ac.aston, tex-euro@bitnet.dhdurz1 Specification of algorithim for handling rounding to device units (v0.01) -- Request for Comments Under separate cover has been sent the outline of the algorithim for handling rounding to device units for the Level 0 DVI driver standard. It differs from the DVItype algorithim in three significant ways: (1) the distances where hh and vv are set to pixel_round(h) and pixel_round(v) have been changed slightly; (2) the check for whether maxdrift correction should be applied has been modified slightly to give slightly better results in some cases (suggestion courtesy John Hobby). (3) max_drift has been given a more specific value. Again, comments are requested, please send them to dhosek@ymir.claremont.edu -dh ------------------------------ Subject: mode_def for IBM 4216 printer? From: Martin Ward Date: Mon, 23 Jul 90 09:48:32 BST Does anyone have a Metafont "mode def" for an IBM 4216 020 Personal Pageprinter (write-white engine)? The only write-white mode def I have is for a Rioch and it doesn't look right! Martin. My ARPANET address is: martin%EASBY.DUR.AC.UK@CUNYVM.CUNY.EDU OR: martin%uk.ac.dur.easby@nfsnet-relay.ac.uk UUCP:...!mcvax!ukc!easby!martin JANET: martin@uk.ac.dur.easby BITNET: IN%"MARTIN@EASBY.DURHAM.AC.UK" ------------------------------ Subject: further funnies in the Archive. Date: Mon,23 Jul 90 15:06:01 BST From: R.A.Reese@uk.ac.hull There is a directory of chapters of a manual on TeX for TROFF users, [.doc.textroff] and I successfully downloaded and decoded every chapter except TABLES.TEX_Z . This file looks similar to the others as received but uncompress doesn't produce anything like an ascii file. ------------------------------ Subject: LaTeX book style From: Peter King Date: Mon, 23 Jul 90 16:52:54 BST Does anyone know how to make the right hand header correspond to the last section header on the page rather than the first one. The problem only arise if there are more than one section starts on the same page. My publishers style asks for the last section header as the running head, whereas LaTeX uses the first. ( I believe the rationale is that the header should indicate which section is 'current' when you turn to the next page. ) -- Peter King, Computer Science Department JANET: pjbk@uk.ac.hw.cs Heriot-Watt University ARPA: pjbk@cs.hw.ac.uk 79 Grassmarket, Edinburgh EH1 2HJ or pjbk%cs.hw.ac.uk@ucl-cs Phone: (+44) 31 225 6465 Ext. 555 UUCP: ..!ukc!cs.hw.ac.uk!pjbk ------------------------------ Subject: TeXserver gains reverse-address sanity Date: Tue, 24 JUL 90 15:40:31 BST From: Brian {Hamilton Kelly} New facilities available at the UK TeX Archive mail server ========================================================== One of the commonest errors made by users of the Aston University TeX archive mail server, is to fail to provide a correct return address in requests. Very often, users forget to mention the appropriate gateway through which the traffic should be routed to depart from the UK. As seen by the user, they aren't getting the service required: from TeXserver's viewpoint, the message is sloshing around somewhere under the computer room floorboards. To avoid this problem, and generally make TeXserver more friendly, I've now provided preprocessing, in the code which despatches an acknowledgement of the request back to the requestor. This also removes the requirement to delimit the actual request by means of a line of three hyphens. Therefore, you may now mail with a message which starts with a valid TeXserver command (HELP, DIRECTORY, FILES, WHEREIS or SEARCH); however, this MUST be the first non-blank line of the body of your message (TeXserver removes valid RFC-822 headers, but see PS below). If you prefer, you may continue to use the old format for TeXserver requests, wherein everything is ignored before the first line which commences with three hyphens: in this format, the following line must be your return address as seen from Aston, and the TeXserver command then appears on the line after that. With the new format for requests, if you wish to use a different return address for the information to be mailed back to you (perhaps avoiding certain gateways which mangle ASCII during a conversion to/from EBCDIC), then you may specify the return address (including the necessary gateway) on the line preceding the TeXserver command; prefix any such alternate address with the directive PATH, followed by a space. If you fail to get any response from TeXserver (neither receipt nor requested information) it may be that your address is being misinterpreted by the incoming mailer, CBS_MAILSHR. DEC are aware of a bug in this, in that it always upcases usernames, so if you're on a system in which the case of letters in usernames is significant, you may always wish to provide a PATH directive, and thereby get the mail sent to your true username. Just to clarify things, assume that A.User@machine.univ.edu wants to get help from the server: under the old scheme he/she would have sent the following message (using ============== to delimit this from the rest of this announcement): =============================== any number of lines of rubbish that he/she cared to put in (although why they bothered, when there's no human to see, I wouldn't understand!) --- Here's the three hyphens, followed by return address A.User%edu.univ.machine@uk.ac.nsfnet-relay help =============================== Note that the little-endian address on the Internet has been reordered to Janet big-endian format, which is what UK gateways expect for mail from within the UK: they reverse it before remailing to the appropriate network. With the new format, this could reduce to just the command directive: =============================== help =============================== But if A.User's machine doesn't recognize A.USER as the correct individual, then he/she would have to specify: =============================== path A.User%edu.univ.machine@uk.ac.nsfnet-relay help =============================== Any difficulties should be reported to me at the address below: it would be useful if you could specify what operation you were attempting to perform (if possible, send me a copy of your request); also send copies of any response received from the TeXserver. Brian {Hamilton Kelly} +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + 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) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ P.S. Some users have rogue mailers, which erroneously introduce a blank line between the various fields which one assumes are meant to constitute a single RFC-822 header. This is ILLEGAL; RFC-822 states that the first blank line terminates the headers and introduces the message body: if you fail to get ANY response from TeXserver, try sending yourself a message via some roundabout route and verify that the headers are contiguous. If they appear OK to you, please mail me at the above address. ------------------------------ Subject: \errorcontextlines setting in LaTeX From: Chris Thompson Date: Tue, 24 Jul 90 13:59:20 BST In UKTeX #23, Rainer Sch\"opf and Sebastian Rahtz describe versions of lplain.tex and splain.tex that can be used with TeX 3.0. These versions set \errorcontextlines=5 (as plain.tex does). Perhaps this point ought to be reconsidered. Karl Berry's release notes for Unix TeX 3.0 say > (The other new parameter in TeX 3.0 that formats might want to set is > \errorcontextlines, but leaving it at zero does not seem inappropriate > for LaTeX.) {`other' in addition to \lefthyphenmin and \righthyphenmin, that is} which seemed very plausible to some of us here, especially given Donald Knuth's original description: > There's a new integer parameter called \errorcontextlines that > specifies the maximum number of two-line pairs of context displayed > with TeX's error messages (in addition to the top and bottom lines, > which always appear). Plain TeX now sets \errorcontextlines=5, but > higher level format packages might prefer \errorcontextlines=1 or > even \errorcontextlines=0. LaTeX would seem to be just such a `higher level format package'. Chris Thompson Cambridge University Computing Service JANET: cet1@uk.ac.cam.phx Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk ------------------------------ Subject: HP DeskJet driver (dvidjp.c) From: Ben Bacarisse Date: Tue, 24 Jul 90 13:58:12 +0100 I built the DeskJet varient of Nelson Beebe's dvi familiy on my PC yesterday. Unfortunately I have only 640K memory and the driver tries to allocate a full 8"x11" bitmap at 300 dpi! The RUMJET driver may overcome this restriction, but as it is "a hack of Beebe's dvi code" it may be very similar. Does anyone know? I am happy to help out by trying to get it running on my PC. In the meantime, I have been using Eberhard Mattes' excellent dvidot driver. This is designed for dot-matrix printers, but I have written a parameter file for it and a simple post-processor that does the required transfromation to raster scan format, as needed by the DeskJet. This works, but it requires that the whole document be stored on disc, as a bit image (3/4 to 1 Mbyte per page) before it can be twiddled and sent to the printer. Dvidot can't, it seems, send its output to a pipe. If anyone wants the configuration file and the bit-twiddling program, I would be happy to provide them. Ben. ------------------------------ Subject: Problems with TFM files From: Mark Manning Date: Wed, 25 Jul 90 10:49:50 BST I am currently trying to transfer the Euler fonts from the archive to our Suns (we do have the Euler fonts from the UNIX distribution tape, but not at all the magnifications we need). I have managed to transfer the PK files successfully (albeit with a spurious zero byte at the end of each file), but get the message Invalid value in command: - filename "[tex-archive.fonts.amsfonts.tfm]eufb10.tfm" record format incompatible with transfer code.' when I try to fetch the corresponding TFM files with exactly the same file transfer parameters. (We need to get the TFM files as well, because the archive's PK files have a different checksum from our TFM files.) I am sure this is a silly problem which everyone gets, and am sorry to trouble you; but your help in sorting this out would be much appreciated! I'd also be interested to know the date of the Euler fonts on the archive (to find out whether they are more up-to-date than ours). Thanks in advance for your help! Mark ------------------------------ Subject: PostScript previewer for VAXstation 3100? From: Hit-Man Date: Thu, 26 Jul 90 9:45 BST Hi, I wonder if any VAX/VMS gurus out there can help? I have recently started using DECwindows on a VAXstation 3100 / VMS 5.3 In their publication 'Overview of VMS DEC Windows' DEC mention briefly a PostScript previewer for DEC windows. However, this manual is for VMS 5.1, and I cannot find any more mention of a PostScript previewer. Has this ever been made available, or has it vanished in VMS 5.3 John Hearns , University of Glasgow ------------------------------ Subject: Seeking Questionnaires from the TUG '90 Meeting in TeXas... Date: Wed, 25 Jul 90 16:10:09 EST From: CHRISTINA_THIELE%CA.CARLETON@UK.AC.EARN-RELAY This is a reminder to all those who attended the 1990 TeX Users Group meeting in College Station, June 18--20. If you haven't already done so, would you please return your completed questionnaires to me. I have only received 47 so far, but I'm sure there are many more still out there -- we had over 150 people in attendance ;-)) Please send your questionnaires to the address below, or e-mail the answers to me at the address shown above (Subject = TAM Questionnaire). Or you can even FAX your questionnaire... The more questionnaires I have, the better we can plan next year's 12th Annual Meeting, in Providence, Rhode Island. Many thanks in advance... Snail: Christina Thiele E-mail: Christina_Thiele@carleton.ca Journal Production Centre DT 1711 Carleton University FAX: 613/788-2340 Ottawa, Ontario K1S 5B6 Canada Christina Thiele ------------------------------ Subject: bibtex Date: Thu, 26 Jul 90 17:07:38 +0100 Originally-from:N.CHAPMAN@UK.AC.UCL.CS i've always assumed that bibtex only works with latex, because that's what the documentation says, but thinking about it i can't see why it isn't possible to put together some suitable macros that will make it work with plain. am i being naive here, or, on the other hand, has someone else who doesn't like latex already done this? (i know about, and indeed use, tib, but i sometimes find the refer database format more restrictive than i'd like so i was interested in investigating something a bit more sophix.) ------------------------------ Subject: OzTeX hash size increase Date: Thu, 26 JUL 90 09:36:51 BST From: VDM@UK.AC.LEICESTER Does anyone have a version of OzTeX which has been generated with a hash size of > 5,000? At Leicester we have three projects which require the use of a large macro library which we would rather do on Macintoshes than on UNIX? Please contact Derek Andrews ajd@uk.ac.le.vax (JANET) ______________________ Many thanks for your help Regards Derek Andrews ------------------------------ Subject: \pmod Date: Fri, 27 Jul 90 10:26:28 From: PM1MJP@UK.AC.SHEFFIELD.PRIMEA ------------------------------------------------------------------------------ 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 Extension 4431. JANET MPiff@UK.AC.SHEF.PA or MPiff@UK.AC.SHEF.IBM ------------------------------------------------------------------------------ On p164 of The TeXBook it states that ``\pmod is to be used when `mod' occurs parenthetically at the end of a formula.'' Just how literally this is to be taken is shown when it is not placed at the end of a formula but at the beginning. To see why this should be necessary, suppose I wish to say that some values are taken (mod n), and wish the spacing to agree exactly with what is obtained in \pmod. Then it would seem perverse to have to type $({\rm mod}\,\,n)$ to achieve this, and more natural to type $\pmod n$. OK, but now see what happens if TeX decides to break the line just before math on. The previous line is not right justified. Did DEK mean the above quotation to be a description of the mathematical circumstances in which \pmod is generally used, or as a warning that it should not be used at the beginning of a formula? \pmod is, of course, safe mid-formula. Do any other maths control words in Plain TeX start with \allowbreak? Is this a bug or an annoying feature? Mike Piff ----------------------------------------------------------------------------- !! UK TeX ARCHIVE at ASTON UNIVERSITY: !! !! Files of interest !! [tex-archive]000aston.readme [tex-archive]000directory.list !! [tex-archive]000directory_dates.list [tex-archive]000directory.size !! [tex-archive]000last30days.files !! !! FTP access: site uk.ac.aston.tex !! username public !! password public !! !! !! 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) !! !! 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. !! !! ---Peter Abbott. !! !! end of issue