TeXhax Digest Tuesday, May 17, 1988 Volume 88 : Issue 46 [SCORE.STANFORD.EDU]TEXHAX46.88 Moderator: Malcolm Brown Today's Topics: man.sty ? The \new family Re: TeX-C bug or feature? Metafont parameters for DEC LPS40? gargantuan.TeX Bug fix for ctex device drivers Re: Zero TFM checksums (TeXhax #41,#43) Driver for IBM 4216 laser printer? LaTeX problem Re: TeXhax Digest V88 #43 (LaTeX Notes) ---------------------------------------------------------------------- Date: Fri, 6 May 88 13:25 EDT From: DAVIS%blue.sdr.slb.com@RELAY.CS.NET Subject: man.sty ? I am trying to put together a LaTeX style for our local guide that looks somewhat like a cross between the Sun System Management manual, and the PostScript Reference manual. Essential features are: 1) Should be completely compatible with existing article or report documentstyles, in that no new commands are added (ie; you add `man' to the options list to get this layout, or drop it, and get the default. 2) Section headings are written as marginal notes, \reversemarginpar-style (ie; left of right hand page), and flush right with the text body, bar some hskip to separate them. 3) The body is shifted across the page, leaving a wide margin on the left hand edge of a right hand page. 4) Running headers somewhat like those in the LaTeX Manual, but with the right page section entry right-justified against the page number, along the lines of: \markboth{pageno \hfill over full page rule}% {\hfill sectionname pageno over full page rule} It would be something like: sample page for man.sty 1 ----------------------------------------------------------- THIS IS MAN.STY IN ACTION text goes here and here and here and here a text goes here and here and here and here a text goes here and here and here and here a text goes here and here and here and here a text goes here and here and here and here a text goes here and here and here and here a text goes here and here and here and here a text goes here and here and here and here a 1. section more text, on a specific subject goes here text goes here and here and here and here a text goes here and here and here and here a text goes here and here and here and here a text goes here and here and here and here a text goes here and here and here and here a a sub-section text on yet another subject goes here and t with a long text goes here and here and here and here a header text goes here and here and here and here a text goes here and here and here and here a What I've done so far is a kludge - redefining \section etc. in terms of \marginpar, and having to ensure that there is no \parskip after margin notes. This means that no proper section entries are made in the toc file. I also tried redefining \section etc., in terms of \@startsection, but because the width of the section `header' varies, padding and right-justifying it against the body using INDENT and AFTERSKIP appears beyond my feeble skills. So, has anyone out there done something like this ? I don't want to have to return to troff -man, but I do want a readable documentstyle (or option), which I regret, for our purposes, the standards are not..... And Leslie, having consulted both John Ryder and Hart's Rules for Compositors (OUP) I am convinced that sectioning should be visible from layout rather than simply section numbering and heading point size. Simply scrolling one section heading directly under another does not answer this need. I have to say that I think that the PostScript manuals are the only books I've seen that have been done with `our-type' of computer typesetting that I find pleasing to the eye, and TeX didn't even get a look in... (Maybe Steele's "Common Lisp" too, so its a hung vote...) Yours in eager hope...... Paul Davis Schlumberger Cambridge Research, Cambridge, UK davis@blue.sdr.slb.com +44 223 325282 ps: Sebastian Rahtz -- have you sussed out how to use PostScript and dvi2ps to rotate TeX boxes yet ? I'd love to know how its done.... ------------------------------ From: Subject: The \new family Date: Fri, 06 May 88 23:03:35 EDT Is there a good reason why these are all defined to be \outer? There was a question about \newread recently, and I had a problem with trying to use \newcount within a macro. I would up copying the definition from the TeXbook, without the \outer. What I was wondering is am I tempting fate? Did Donald Knuth simply decide that all declarations should be made on the global level, or is somthing going to break if I persist in my foolishness? Thanks, Andrew Marc Greene (amgreene@athena.mit.edu) Member, Student Information Processing Board, MIT ---------------------------------------------------------------------------- ``When the buds are blossoming, smiling welcome to the Spring, Lovers choose a wedding day; life is love in merry May!'' - W.S.Gilbert ------------------------------ Date: Sat, 7 May 88 16:49:43 EDT From: Chris Torek Subject: Re: TeX-C bug or feature? [Note to the TeXhax moderator: this, or most of this, may be irrelevant to the TeXhax list. I shall let you decide.] >line_diff := line_number(r) - bestline; > line_number and bestline are halfwords ( unsigned 16 bit values) > line_diff is a integer ( long in C ie 32 bit signed) >Is the difference between 2 unsigned values unsigned? What if >line_number(r) < bestline? This happens in the TRIP test. As long as you stick to the two basic integer types (`int' and `long') and their unsigned variants, `old C' typing is very simple: unsignedness is `sticky'. Once a value becomes unsigned it stays unsigned; when signed and unsigned values are mixed by a binary operator, the result is unsigned. Hence the difference between two unsigned values is unsigned. The *size* of the result is the larger of the sizes of the two operands. Here both are unsigned int, so the result is unsigned int. This is then assigned to a long, so it must be widened; the unsignedness remains sticky, and the result is an unsigned long, which is summarily stuffed into line_diff, later to be considered signed. If (say) line_number(r)=5 and bestline=7, we get 0x0005 - 0x0007 = 0xfffe (if int is 16 bits) 0x00000005 - 0x00000007 = 0xfffffffe (int 32 bits) The former is widened without sign extension to 0x0000fffe, or 65534. This is correct and proper if int is 16 bits long. (If int is 32 bits long, there is no question here; the result is 0xfffffffe, which is later interpreted as signed, or -2.) But there is a problem here: all of this is true only if we stick with `int' and `long'. The types of line_number(r) and bestline are probably `unsigned short', which is not one of the `basic types'. Now the picture gets more complicated. `New C'---the C being defined by an ANSI committee---has different sign extension rules. I shall not go into details, but say only that the eventual result is the same: on a machine with 16 bit `int's, the assignment sets line_diff to 65534, while on a machine with 32 bit `int's, the assignment sets line_diff to -2. (This problem does not come up in Pascal TeXes for two reasons: Pascal has no `unsigned' concept; and Pascal TeXes run only on machines with 32 bit integer arithmetic anyway.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris ------------------------------ From: ramshaw@src.dec.com (Lyle Ramshaw) Date: 7 May 1988 1146-PDT (Saturday) Subject: Metafont parameters for DEC LPS40? Has anyone determined good settings of the Metafont device-dependent parameters (blacker, o_correction, fillin, and the write-white flag) to produce Computer Modern rasters tuned for the DEC LPS40 printer? The LPS40 is a PostScript printer that uses a Ricoh-6000-series write-white marking engine. (The settings that are suggested on the Unix TeX tape for the Ricoh 4080 do not work very well on the LPS40.) Lyle ------------------------------ Date: Sat, 7 May 88 13:07:50 PDT From: mackay@june.cs.washington.edu (Pierre MacKay) Subject: gargantuan.TeX On a 32-bit compiler, the following patch, applied to ctex.ch, should give you a TeX with a really capacious appetite. The latest version of web2c, in web2c.shar.Z on ~ftp/pub at june.cs.washington.edu makes it unnecessary even to change the memory.h structure. This compiles to a 3+MB core image on an Ultrix machine. ----------------------------diff file for "patch"-------------------- *** ctex.ch Tue Apr 5 09:21:52 1988 as delivered with web2c --- CTEX.CH Sat Apr 30 12:05:07 1988 adjusted for a gargantuan TeX *************** *** 160,172 **** @!pool_name='TeXformats:TEX.POOL '; {string of length |file_name_size|; tells where the string pool appears} @y ! @!mem_max=65530; {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|} @!mem_min=0; {smallest index in \TeX's internal |mem| array; must be |min_halfword| or more; must be equal to |mem_bot| in \.{INITEX}, otherwise |<=mem_bot|} ! @!buf_size=500; {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|} @!error_line=79; {width of context lines on terminal error messages} --- 160,172 ---- @!pool_name='TeXformats:TEX.POOL '; {string of length |file_name_size|; tells where the string pool appears} @y ! @!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|} @!mem_min=0; {smallest index in \TeX's internal |mem| array; must be |min_halfword| or more; must be equal to |mem_bot| in \.{INITEX}, otherwise |<=mem_bot|} ! @!buf_size=1000; {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|} @!error_line=79; {width of context lines on terminal error messages} *************** *** 173,203 **** @!half_error_line=50; {width of first lines of contexts in terminal error messages; should be between 30 and |error_line-15|} @!max_print_line=79; {width of longest text lines output; should be at least 60} ! @!stack_size=200; {maximum number of simultaneous input sources} @!max_in_open=15; {maximum number of input files and error insertions that can be going on simultaneously} ! @!font_max=120; {maximum internal font number; must not exceed |max_quarterword| and must be at most |font_base+256|} ! @!font_mem_size=36000; {number of words of |font_info| for all fonts} @!param_size=60; {maximum number of simultaneous macro parameters} @!nest_size=40; {maximum number of semantic levels simultaneously active} ! @!max_strings=4400; {maximum number of strings; must not exceed |max_halfword|} ! @!string_vacancies=15000; {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=45000; {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=2000; {space for saving values outside of current group; must be at most |max_halfword|} @!trie_size=8000; {space for hyphenation patterns; should be larger for \.{INITEX} than it is in production versions of \TeX} @!dvi_buf_size=16384; {size of the output buffer; must be a multiple of 8} @!file_name_size=1024; {file names shouldn't be longer than this} ! @!pool_name='tex.pool'; {string of length |file_name_size|; tells where the string pool appears} ! @!mem_top=65530; {largest index in the |mem| array dumped by \.{INITEX}; must be substantially larger than |mem_bot| and not greater than |mem_max|} @z --- 173,203 ---- @!half_error_line=50; {width of first lines of contexts in terminal error messages; should be between 30 and |error_line-15|} @!max_print_line=79; {width of longest text lines output; should be at least 60} ! @!stack_size=300; {maximum number of simultaneous input sources} @!max_in_open=15; {maximum number of input files and error insertions that can be going on simultaneously} ! @!font_max=240; {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} @!param_size=60; {maximum number of simultaneous macro parameters} @!nest_size=40; {maximum number of semantic levels simultaneously active} ! @!max_strings=6600; {maximum number of strings; must not exceed |max_halfword|} ! @!string_vacancies=25000; {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=75000; {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|} @!trie_size=8000; {space for hyphenation patterns; should be larger for \.{INITEX} than it is in production versions of \TeX} @!dvi_buf_size=16384; {size of the output buffer; must be a multiple of 8} @!file_name_size=1024; {file names shouldn't be longer than this} ! @!pool_name='TEX.POOL'; {upper case, so that it can coexist with tex.pool} {string of length |file_name_size|; tells where the string pool appears} ! @!mem_top=262140; {largest index in the |mem| array dumped by \.{INITEX}; must be substantially larger than |mem_bot| and not greater than |mem_max|} @z *************** *** 227,236 **** must not be less than |mem_min|} @d font_base=0 {smallest internal font number; must not be less than |min_quarterword|} ! @d hash_size=3000 {maximum number of control sequences; it should be at most ! about |(mem_max-mem_min)/10|, but 3000 is already quite generous} ! @d hash_prime=2551 {a prime number equal to about 85\% of |hash_size|} ! @d hyph_size=307 {another prime; the number of \.{\\hyphenation} exceptions} @z %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --- 227,238 ---- must not be less than |mem_min|} @d font_base=0 {smallest internal font number; must not be less than |min_quarterword|} ! @d hash_size=9500 {maximum number of control sequences; it should be at most ! about |(mem_max-mem_min)/10|, so we can be really generous} ! @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\% of a |hash_size| of 9500} ! @d hyph_size=607 {another prime; the number of \.{\\hyphenation} exceptions} @z %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% *************** *** 743,751 **** @d max_halfword==65535 {largest allowable value in a |halfword|} @y @d min_quarterword=0 {smallest allowable value in a |quarterword|} ! @d max_quarterword=255 {largest allowable value in a |quarterword|} @d min_halfword==0 {smallest allowable value in a |halfword|} ! @d max_halfword==65535 {largest allowable value in a |halfword|} @z %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --- 745,753 ---- @d max_halfword==65535 {largest allowable value in a |halfword|} @y @d min_quarterword=0 {smallest allowable value in a |quarterword|} ! @d max_quarterword=511{largest allowable value in a |quarterword|} @d min_halfword==0 {smallest allowable value in a |halfword|} ! @d max_halfword==262143{largest allowable value in a |halfword|} @z %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Email: mackay@june.cs.washington.edu Pierre A. MacKay Smail: Northwest Computing Support Group TUG Site Coordinator for Lewis Hall, Mail Stop DW10 Unix-flavored TeX University of Washington Seattle, WA 98195 (206) 543-6259 ------------------------------ Subject: Bug fix for ctex device drivers Date: Sun, 08 May 88 14:36:16 PDT From: vahe@math.ucla.edu We got our new distribution of TeX from U. of Washington last week. In looking through it, I found a bug in the Imagen printer driver, which I'd fixed locally, was still present in the distribution. You may see it if you have an environment similar to ours: the TeX files are edited and TeX'ed on a PC, then the DVI file is uploaded to a Vax for printing on our Imagen. (Actually, the file in question is also used by the ctex Versatec driver, so you may see it in that context as well.) The problem we were having was that "imagen1" was balking at some DVI files produced by PC-TeX; it asked "are you sure this is a DVI file?" because it couldn't find the postamble. To make the fix in the context of the remaining code would've been difficult; rather than make a mess of #ifdef's, I just made a new routine. I think it's a reflection on the quality of Chris Torek's code that I was able to make the change as painlessly as I did. Anyway, a set of context diffs are at the end of this message. The file in question is ./tex82/TeXdevices/ctex/lib/findpost.c . The comments included should clarify the bug and the fix. --Vahe Sarkissian, UCLA Math. Sci. vahe@math.ucla.edu *** findpost.orig.c Mon Sep 7 10:38:56 1987 --- findpost.c Sun May 8 14:10:58 1988 *************** *** 27,32 **** --- 27,56 ---- * number, preceded by the four byte postamble pointer; but at least * one VMS TeX must pad to a full `sector'. */ + /* + * The above is not correct. The DVItype program, as authoritative on + * DVI format, states regarding postambles: + * + * The [last] byte is followed by four or more bytes that are all + * equal to the decimal number 223 (i.e., 337 in octal). TeX puts + * out four to seven of these trailing bytes, until the total length + * of the file is a multiple of four bytes, since this works out + * best on machines that pack four bytes per word; but any number + * of 223's is allowed, as long as there are at least four of them. + * + * Thus assuming "at most seven DVI_FILLER bytes" is wrong. In fact, + * PC-TeX seems to put out liberal amounts of DVI_FILLER at the end. + * + * The original code was efficient, but had to assume a certain + * number of bytes. Since the postamble is only read once anyway, + * efficiency is not really a consideration. Plus, like I always + * say, it's better to get the right answer slowly than the wrong + * answer fast.... + * + * Vahe Sarkissian, UCLA Math. Sci., 4/13/88. + */ + + #ifdef ORIGINAL_CODE #ifdef vms #define POSTSIZE 530 /* make only VMS pay for its errors; */ #else *************** *** 88,90 **** --- 112,146 ---- fseek(f, offset, 0); return (0); /* success */ } + + #else !ORIGINAL_CODE + + FindPostAmble(f) + register FILE *f; + { + register long offset; + register i32 n; + + offset = -4; /* At least four bytes of DVI_FILLER must be present. */ + do { + offset -= 1; + (void) fseek(f, offset, 2); + n = fgetbyte(f); + } while (n == DVI_FILLER); + + if (n != DVI_VERSION) + return (-1); /* Bad version of DVI file */ + + /* + * Position file four bytes before DVI_VERSION byte, + * and read a long. Use that long to seek to the + * beginning of the postamble itself. + */ + offset -= 4; + (void) fseek(f, offset, 2); + fGetLong(f, n); + offset = n; + (void) fseek(f, offset, 0); + return (0); /* success */ + } + #endif ORIGINAL_CODE ------------------------------ Date: Sun, 08 May 88 21:48:40 BST From: CET1%phoenix.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK Subject: Re: Zero TFM checksums (TeXhax #41,#43) In Texhax #43, Joachim Schrod claims that > ... there are only two places where the > ignoring of zero checksums is handled: > (1) In TeX, the program. (section 542, where the TFM format > is explained -- the remark about zero checksums is parenthesized) > (2) In the article of David Fuchs about the PXL file format (Type 1001). > This article appeared in TUGboat, Vol. 2 (1981) [sic!], No. 3. This is almost true. Essentially the same description of TFM format appears in one or two other places (e.g. TFtoPL). The copy in the the METAFONT listing has had the remarks about special treatment for zero checksums removed! The descriptions of GF and PK files simply refer to their checksums as being equal to that in the TFM file, without further elaboration. As Joachim implies in his P.S., the prototype DVI-interpreting program is DVItype. DVItype *doesn't* have a full description of TFM files in the text... however, the code does *implement* the rule about ignoring checksum mismatches if either the DVI or TFM value is zero. (Of course, DVItype is unusual in actually reading the checksum and TFM widths from a TFM file, rather than their copies in a PXL/GF/PK file.) > So, if there's a driver which doesn't follow the ``standard > specification,'' don't blame the author, blame the documentation. OK, now it's confession time. My DVI-converting programs produce a warning message if there is a checksum mismatch, regardless of whether either checksum is zero. This is not because I was unaware of the situation as described above. It is because I felt that providing this bypass was misguided. In Cambridge, there are many implementations of TeX, from a variety of sources, running on mainframes to micros. Each is liable to have acquired its TFM and PXL/GF/PK files in a different way. DVI files are often moved between these machines. The checksum mechanism is an important component in keeping things in step. If some implementation is trying to *suppress* these checks by using zero checksums, I surely want to know about it, so that I can *suppress* the implementation! Pierre's admission (TeXhax #41) that he once flooded the world with zero-checksum TFM files rather reinforces my opinion. I have to admit that I wouldn't feel able to take this line if the programs involved treated a checksum mismatch as a hard error. P.S. On a lighter note: once every 4,000,000,000 fonts or so, METAFONT will generate a zero checksum! Try, for example font_size 16pt#; mode_setup; beginchar(94,48.95708pt#,0pt#,0pt#); endchar; beginchar(95,48.95709pt#,0pt#,0pt#); endchar; end. (Saying "headerbyte 1: 0,0,0,0;" is cheating!) Chris Thompson Cambridge University Computing Service JANET: cet1@uk.ac.cam.phx ARPA: cet1%phx.cam.ac.uk@nss.cs.ucl.ac.uk ------------------------------ Date: Mon, 9 May 1988 09:39 EDT From: Brian Holmes Subject: Driver for IBM 4216 laser printer? After looking through the laser driver list, I could find any drivers for an IBM 4216 laser printer. I don't know very much about this printer but does anyone know of a driver that will work? ******************************************************************* * Brian Holmes * * Wayne State University * * Detroit Michigan * * * * BITNET : BHOLMES@WAYNEST1 * * INTERNET : Brian_Holmes%WU@UM.CC.UMICH.EDU * * UUCP : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES * ------------------------------ Date: Mon, 9 May 88 07:58:30 EST From: HOOVER Subject: LaTeX problem On page 49 of the LaTeX book there is an example right before section 3.3.5 that uses the array environment to display a multilined formula with a large left parethesis ({) preceding the equations. I need to do something similar using numbered equations. I tried substituting the array environment with the eqnarray environment, but that did not work. LaTeX complained about \endgroup. Is there a simple solution to getting a large left parenthesis ({) preceding a multilined numbered equation? Something like this large { surrounding y = 2ab + c (12) a = 4b (13) b = 25 (14) c = 5b (15) Any help is welcomed! Please respond directly to bitnet : acs03174 at UDACSVM internet : anita@vax1.acs.udel.edu Anita Hoover University of Delaware ------------------------------ Date: Mon, 9 May 88 09:31:48 PDT From: lamport@src.dec.com (Leslie Lamport) Subject: Re: TeXhax Digest V88 #43 (LaTeX Notes) FISHER%SCR.SDSCNET@Sds.Sdsc.Edu writes: I am using the article.sty file from LaTeX in combination with BibTeX 0.98i to generate a document with citations and am having some overfull box problems. Due to the unfortunate circumstances I find myself in, I need to use a .bst file on the order of Oren Patashnik's natsci.bst. When I use this .bst, the citation labels in the text get rather lengthy, and can extend over the righthand margin considerably, so I get something that looks like: |-----------------text--------------------| |-----------------text--------------------| |-----------------text---------[Johnson and Johnson, 1988]. |-----------------text--------------------| |-----------------text--------------------| I have seen this occur with standard .bst files that generate lists of numbers in the text that extend beyond the margin as well, although the problem in this case is usually less severe. Is there some trick to getting this to work right (i.e., splitting the cite across two lines)? When you're producing the camera-ready, final, ultimate version, you can simply replacing "\cite{j-and-j]" with "[Johnson and Johnson, 80]". After producing this version, be sure to put back the original \cite command for your revised version. This will take less time than composing a message to TeXHaX. Eric Ole Barber writes: I'm using \clearpage to force all figures in a section into the same section, and start a new section on a fresh page. If \clearpage has to force out a page of floats, then no figures appear on the first page of the next section. Is this a conjecture or an observation? There is, to my knowledge, nothing to prevent a figure from appearing on the page following the floats put out by a \clearpage. As with any suspected bug, please send me the shortest file you can make that exhibits the problem. Leslie Lamport ------------------------------ %%% %%% Concerning subscriptions, address changes, unsubscribing: %%% BITNET: send a one-line mail message to LISTSERV@TAMVM1.BITNET: %%% SUBSCRIBE TEX-L % to subscribe %%% %%% All others: send mail to %%% texhax-request@score.stanford.edu %%% please send a valid arpanet address!! %%% %%% %%% All submissions to: texhax@score.stanford.edu %%% %%%\bye %%% ------------------------------ End of TeXhax Digest ************************** -------