TeXhax Digest Wednesday, March 16, 1988 Volume 88 : Issue 26 [SCORE.STANFORD.EDU]TEXHAX26.88 Editor: Malcolm Brown Today's Topics: PATGEN Addison-Wesley and MicroTeX and TeXtures New bibtex.web TeXhax Makeindex (TeXhax Digest V88 #22) NEWFFC for the LN03 Varying the Numbering Style in Enumerate Environments. overfull hboxes and "nroff" A-problem-with-\immediate-and-\write-in-TeX (TeXhax Digest V88 #22) LaTeX-3Jan_to_22Feb.diffs making fonts for ln03 Additions to TEXFONT.MEMO ---------------------------------------------------------------------- Date: Fri, 11 Mar 88 10:59 N From: (Nico Poppelier) Subject: PATGEN Last week I obtained PATGEN.WEB from a VMS distribution tape (and after minor changes implemented it on an Atari 1040ST. In case anyone is interested: I produced working versions of TANGLE and WEAVE for the Atari, with reasonably small change files). The .TEX file extracted with WEAVE produces output starting at page 45 and apparently PATGEN.TEX is the Appendix of a bigger document. Question: Where can I get the other pages, pp. 1--45, and what is in it? Nico Poppelier (BITNET address: Poppelier@Hutruu51) ------------------------------ Date: 11 Mar 1988 09:59:18 EST From: Irvin.Lustig%BASIE.Princeton.EDU@Princeton.EDU Subject: Addison-Wesley and MicroTeX and TeXtures Not only has Addison-Wesley stopped supporting MicroTeX for the PC's, they are also discontinuing support of TeXtures for the Macintosh family. However, Kellerman and Smith, the authors of TeXtures, have taken over support of all users and future sales. So at least Addison-Wesley hasn't left everybody in the dark. By the way, the latest version of TeXtures (1.01) supports typesetting in the backround under Multifinder. Hence, one can type one document or work in another program while typesetting a document. The $25 upgrade price is definitely worth it. -Irv Lustig Assistant Professor Dept. of Civil Engineering and Operations Research Princeton University irv%basie@princeton.edu ------------------------------ Date: 11-MAR-1988 11:13:19 GMT From: ABBOTTP%aston.ac.uk@NSS.Cs.Ucl.AC.UK Subject: New bibtex.web I am trying to ftp a copy of bibtex.web from score.stanford.edu for the UK community but due to its size I have time out problems. Is there any chance that the file could be split into smaller parts for ftp purposes. I connect to score through several systems each with different time out parameters and I have no batch ftp facilities only interactive. As a result of the last TUGBOAT several people have asked to be added to the UKTeX distribution list. I have acknowledged all the requests and asked for acknowledgement that I have the correct address. Some have not replied so if you have asked to be added and are not receiving the digests please send again. Peter Abbott ______________________ Computing Service JANET abbottp@uk.ac.aston Aston University ARPA pabbott@nss.cs.ucl.ac.uk Aston Triangle or abbottp%uk.ac.aston@nss.cs.ucl.ac.uk Birmingham B4 7ET UUCP ...!ukc!aston!abbottp U.K. BITNET abbottp%uk.ac.aston@ac.uk Tel (+44) 21 359 5492 ------------------------------ Date: Fri, 11 Mar 88 08:06:43 PST From: mackay@june.cs.washington.edu (Pierre MacKay) Subject: Makeindex (TeXhax Digest V88 #22) Since Makeindex is part of UCBerkeley's VorTeX, and subject to license, it has not been possible to put it out for general distribution. (I have never actually seen it myself.) Recent correspondence with Berkeley suggests that it may be possible to arrange for Makeindex to be separated from the rest of VorTeX, and added to public network software and packages like the Unix TeX distribution. Pierre A. MacKay TUG Site Coordinator for Unix-flavored TeX ------------------------------ Date: Fri, 11 Mar 88 08:32 PST From: SHECTMAN%SETI@icdc.llnl.gov Subject: NEWFFC for the LN03 Here at Lawrence Livermore Labs, we locally distribute TeX with a bunch of command files and additional programs that cause pixel files to be created the first time they are encountered in a DVI file (yes, I remember that I said I would post these changes to TeXhax, and I will when I get time to fill out the paper work necessary). A system manager bringing up TeX for the first time on a group of systems that only had LN03's for output devices encountered the problem that only the file owners could reference the pixel files created by NEWFFC. They checked the sources, and found that NEWFFC creates files with only OWNER access. Enclosed is the differences file that shows the minor change to create the pixel files with the current default protection. It could just as easily have been set to give the world access. It is not clear why the originator of NEWFFC chose to be so restrictive. ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: From: VAXPM::ELLIS "Phone 2-5952" 11-MAR-1988 08:17 To: SETI::SHECTMAN Subj: TEX Bob, I found in newffc.c where the file protection was being set. Following is the differences between the two source files. ************ File SYS$SYSDEVICE:[ELLIS]NEWFFC.C;1 1258 strf = creat(fs,0700); 1259 if (strf == -1) { ****** File SYS$SYSDEVICE:[ELLIS]NEWFFC.C;2 1258 /* strf = creat(fs,0700); */ 1259 strf = creat(fs,0000); /* R.Palasek LLNL for Tom 3/9/88 */ 1260 if (strf == -1) { ************ Number of difference sections found: 1 Number of difference records found: 2 DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=SYS$SYSDEVICE:[ELLIS]NEWFFCDIF.TXT;1- SYS$SYSDEVICE:[ELLIS]NEWFFC.C;1- SYS$SYSDEVICE:[ELLIS]NEWFFC.C;2 ------------------------------ Subject: Varying the Numbering Style in Enumerate Environments. Date: Fri, 11 Mar 88 12:47:48 PST From: Robert Kasper In TexHax V88 #22 HANCHE%NORUNIT.BITNET@CUNYVM.CUNY.EDU writes: > Date: Fri, 26 Feb 88 21:10:17 ECT > From: HANCHE%NORUNIT.BITNET@CUNYVM.CUNY.EDU > Subject: Varying the Numbering Style in Enumerate Environments. > > Sub-Title: LaTeX Manual Baby Bug > > A student wanted roman numerals numbering the items in his enumerate > environments. Neither he nor I could find out how to do that from the > LaTeX Manual. It did not take much poking around, however, to discover > that the solution is to issue the command > > \renewcommand{\labelitemi}{\roman{itemi}} > > (Replace the two occurences of itemi by itemii, itemiii, or itemiv > whenever appropriate.) > > This seems to be such a useful thing that it should have been mentioned > in the LaTeX manual. Leslie, please take note in case there will be a > second edition. Others might want to scribble a note on the bottom of > p.165 in their own copies... We have also tried to change the numbering style for the items of enumerate environments with no success. We tried redefining \theenumi according to the instructions given in Section 5.3 (p. 92) of the LaTex manual as follows: --- BEGIN EXAMPLE --- \renewcommand{\theenumi}{\roman{enumi}} \begin{enumerate} \item asserting or retracting a unary predicate on $I$; \item changing the value of one of $I$'s roles; \item changing the type of an individual adjacent to $I$. \end{enumerate} \renewcommand{\theenumi}{\arabic{enumi}} --- END EXAMPLE --- This did not have any effect; the items are still labeled with arabic numerals. Changing the \labelitem command by: \renewcommand{\labelitemi}{\roman{itemi}} did not have any effect either. (I would only expect it to control the labeling of itemized lists, not enumerated lists). Why are these commands not behaving as documented? -- Bob Kasper Arpanet: VAXA.ISI.EDU ------------------------------ Date: Fri, 11 Mar 88 16:54:55 EST From: Bernie Cosell Subject: overfull hboxes and "nroff" I've been shifting my habits and using TeX for more-and-more of my typesetting chores (I still have to use troff a fair amount (man pages and the like)). I like TeX quite a lot: I find it predictable and easy to use, and I'm always impressed by the top-notch job it does. ON THE OTHER HAND... (you _knew_ this was going to be a flame, right?? :-) TeX does have a couple of quirks that I find maddening... even more so considering the care and completeness that has been lavished on so much of it. Lemme roll out my two biggest nuisances... if there are tricks and such for dealing with them I would VEYR much like to know, since it would make my life a bunch more pleasant: 1) overfull hboxes. I just got bonged, _again_, by making a minor change to a document (I replaced "the file" with "{\tt }") and getting bagged by an overfull hbox. It basically trashed the document (unless you like things sticking out 1/2" into the right margin). This leads me to three inquiries: a) Is there some magical way to parse the cryptic (to say the least) info in the log file to figure out HOW to fix the overfull box? Aside from giving me the offending box (which was what was obvious), I'm not sure how to fix it. I've been spraying negative penalties around earlier in the paragraph to get it to loosen things up a bit (my current opinion -- to be confirmed by looking at the doc if I can ever get it to work..:-( is to set the previous three or four lines a bit loose and so move the {\tt} to the next line, instead of having all-good lines and then a HUGE whitespace on the one line). How can I figure out how much negative penalty I'll need to "tune" that paragraph up? Which leads me to my second problem: b) How can I fix it so it _stays_ fixed? Assume I brute-force stick in enough penalty-tuning to get TeX to respect the margins. Now I edit the paragraph a little bit. Now all of those penalties are inappropriate. How will I know? Should I hope that I'll get some kind of _underfull_ box complaint and then go through numerous rounds of tuning and tweaking again to get the paragraph to look OK? Is there some automatic way to "patch" this in a way that won't haunt me for the entire life of the document. c) I _really_ thought you could run TeX in a mode where its action on overfull boxes was to complain to the log, and THEN begin relaxing its fussiness criteria so that it would do "as well as it could" to get the paragraph set. I've pawed through my TeX book some now and I can't find it -- did I imagine (or maybe "hope for") that mode, or did I just miss seeing how to get it set up. 2) nroff. I'm having a VERY hard time coping with a laserprinter-only typesetting world. Yes, I know, a monospaced document is trash and doesn't deserve to live. But still... I find that I now essentially _can't_ work on documents from home any more. There's no decent way to preview things short of driving into work and picking up a draft off the laserwriter (this is true even on my SUN here at work: we long ago shifted to having LaTeX use the built-in fonts on the laserwriter.... of course now there aren't any appropriate fonts on-line, and so dvi2sun doesn't work). And back in my t/nroff days I actually used nroff to DO monospace formatting - on-line documentation for programs, chunks of stuff to be distributed by email. Is there some hackery I can use to get TeX to set up monospace, ASCII compatible documents? Thanks for your patience... /Bernie\ ps, on a related note, are there any plans to "civilize" *running* TeX? One comment that seems to be a VERY common one we get when we try to get TeX more widely used around the company is that it is AWFUL to use - apparently the simplest of typos touches off a barrelfull of incomprehensible error messages. Even when you can figure out what what error it is telling you about, it all feels much harsher and less-nicely-engineered than it could be. Mostly i don't have a lot of trouble with this (aside from trying to figure out how to finesse overfull hboxes... :-), but it sure is forboding for the non-technically-inclined. /B\ __ / ) Bernie Cosell /--< _ __ __ o _ BBN Labs, Cambridge, MA 02238 /___/_(<_/ (_/) )_(_(<_ cosell@bbn.com ------------------------------ Date: Fri, 11 Mar 88 14:29:05 PST From: mackay@june.cs.washington.edu (Pierre MacKay) Subject: A-problem-with-\immediate-and-\write-in-TeX (TeXhax Digest V88 #22) The problem is not with either \immediate or \write. If you consider the page-breaker in "How TeX breaks lines up into pages" you will see that the results you are getting are inevitable. You may be able to fine tune them a bit, but a section header that comes before the page breaker has been triggered is bound to think it is on the previous page. The safest approach, if your submission deadline is approaching, is to be prepared to do a bit of hand editing on the contents file for the final draft. You may have to anyway. You could also look at the value in \pagedepth, adjusted as sugggested on TeXbook p. 123, and modify your page-number accordingly. But I should think that with a clearly defined feature such as a section head, you could usually force TeX to consider the possibility of page-breaking before it does the \write. I have one format that writes headers dependent on the content of the page for continuous text. It gets things right about 90% of the time, and I confess I have never felt it worth the time to try for any greater consistency. On the last pass, I do some hand editing. Unless you have an absolutely HUGE table of contents, I would suggest that hand editing is the most expeditious way to meet a deadline. Pierre A. MacKay TUG Site Coordinator for Unix-flavored TeX ------------------------------ Date: Fri, 11 Mar 88 14:35:06 PST From: mackay@june.cs.washington.edu (Pierre MacKay) Subject: LaTeX-3Jan_to_22Feb.diffs Here are the diffs for a set of new files which I got from Score just before TeXhax went on vacation. Pierre A. MacKay TUG Site Coordinator for Unix-flavored TeX %%% Pierre's submission is too long (34K) for digest distribution. You %%% can FTP it from SCORE.STANFORD.EDU by getting the file %%% mkdiffs.txh %%% As usual, a copy has been forwarded to TEX-L for BITNET distribution. %%% Malcolm ------------------------------ Date: Fri, 11 Mar 88 18:27:59 EST From: crl@maxwell.physics.purdue.edu (Charles R. LaBrec) Subject: making fonts for ln03 As someone who has been playing with LN03's for quite a while, I thought that I should speak up at last. My time for playing with it is decreasing at a rather rapid rate, so I have not tested things out extensively. For those of you who are not familiar with it, the LN03 uses a write-white engine. It does not register single-pixel width lines very reliably (actually, close to not at all). Metafont does not deal with such beasts very well. If you make blacker great enough to eliminate single pixel-width lines, you greatly distort the characters. My first attempt was to use the write-white changes suggested in the Metafont distribution. This involved adding some "max(x,2)" to strategic places in cmbase.mf . However, I quickly learned that these were not good enough. In particular, "o"s had gaps where a pixel didn't register. If memory serves, the top looked something like: ##### .#####. ## ## where "." shows the pixel that burned off. From this, I decided that the write-white fixes didn't go far enough, and so performed some wholesale surgery on cmbase. I believe that diffs are available from the Metafont directory in the file labrec.txh . The problem was that I feel the "fixes" are a gigantic kluge that best be left unseen. However, they did produce acceptable results, and from this success I created a set of "cm" fonts for ditroff that we are now using for our LN03's. Besides being a kluge, the "fixes" create a cmmf that can only be used with a write-white engine, thus eliminating the advantages of modes. I have recently started toying with a new idea. I have added a new mode-specific internal called blacker_min and redefined define_whole_blacker_pixels and define_whole_vertical_blacker_pixels to use this value instead of (effectively) 1. I felt that this would have the desired effect, since most line widths are set using these macros. Here is the addition to our local.mf: newinternal blacker_min; def define_whole_blacker_pixels(text t) = forsuffixes $=t: $:=hround($.#*hppp+blacker); if $<=blacker_min-1: $:=blacker_min; fi endfor enddef; def define_whole_vertical_blacker_pixels(text t) = forsuffixes $=t: $:=vround($.#*hppp+blacker); if $<=blacker_min-1: $:=blacker_min _o_; fi endfor enddef; % Here are conventions for local output devices: % decln mode: for the DEC LN03 (Ricoh engine, a write-white device) mode_def declniii = % proofing:=0; % no, we're not making proofs fontmaking:=1; % yes, we are making a font tracingtitles:=0; % no, don't show titles in the log pixels_per_inch:=300; blacker:=0.2; % make pens a bit blacker blacker_min:=2; % most everything should be at least 2 pixels wide fillin:=-0.2; % darken diagonals a bit o_correction:=0.5; % don't overshoot as much enddef; Initial results have been encouraging, but fall far short of being "exhaustive" tests. Strokes seem to be sufficiently broad to avoid gaps due to pixel burn-off. However, I have seen one distortion in characters: the bar in the "e" is one pixel row too high. The problem is that the vertical placement of the bar in romanl.mf uses good.y bar_height (using pen tiny.nib), but doesn't draw it with tiny.nib. The actual width is .6[thin_join,vair]. It turns out that for cmr12, tiny.nib is 1 and thin_join and vair are 2. Thus good.y puts the bar at a half-integral y coord, when it should be drawn on an integral one. I would almost want to classify this as a bug in romanl.mf, but I'm not sure. I'll let others more familiar with the fonts to ponder it. So, here is my two cents worth. Do with it what you will, and tell me if the solution is a good one, bad one, or something in between. Charles LaBrec crl @ maxwell.physics.purdue.edu ------------------------------ Date: Fri, 11 Mar 88 22:03:59 EST From: dow@wjh12.harvard.edu (Dominik Wujastyk) Subject: Additions to TEXFONT.MEMO TEXFONT.MEMO [An index at the end of this document lists the fonts discussed.] Introduction, History and Revision notes This memorandum seeks to give a reasonably complete survey of the fonts that are available for use with the TeX typesetting software. I would be grateful for any relevant information that you may have that is not already mentioned. While keeping the memo concise, I have given all the information that I currently have. In other words, this is it: there is probably nothing more to be learned by contacting me directly than is already in the memo. I have also given everything I know about how to get more information about each font, so follow those leads rather than contacting me. I first started compiling this Memorandum late in 1987, as a note to myself and my immediate Indological colleagues. But it seemed little extra work to include more information in it about other fonts I have heard of, and doing this has greatly widened its usefulness to TeX users in general. As this memo has grown beyond its original purpose, and more people are requesting it, I think it is now worth adding the following notes giving a date for the current revision. I shall post these revision notes to TeXhax from time to time, and send the latest version of the memo to score.stanford.edu. This way people will know whether there is enough new stuff in it to be worth downloading it (again). Revision Notes March 10, 1988: Added information on Listserve access to Goldberg's Arabic; Knuth's Devanagari la; Billawala's Pandora; new person may work on Tamil; Icelandic; Times Roman in Metafont; two people may work on Telugu; IPA now available from Washington; Bitstream font family for TeX; HP2TeX conversion of HP soft fonts to TeX fonts. Since the tail has started to wag the dog, I have reformatted the memo slightly, removing some of the bias towards Indic matters, to make it a more general note about TeX fonts. Index added. General tidy up and removal of infelicities. %%% The update to Dominik's memo is now available for FTPing. You can %%% `get' the file from the machine [SCORE.STANFORD.EDU] via anonymous %%% FTP. The file is stored as %%% wujastyk.txh %%% A copy of the revision has been forwarded to TEX-L for BITNET. The %%% memo is now roughly 50K in length. %%% Malcolm ------------------------------ %%% %%% subscriptions, address changes to: texhax-request@score.stanford.edu %%% please send a valid arpanet address!! %%% %%% BITNET distribution: subscribe by sending the following %%% line to LISTSERV@TAMVM1.BITNET: %%% SUBSCRIBE TEX-L %%% %%% submissions to: texhax@score.stanford.edu %%% %%%\bye %%% ------------------------------ End of TeXhax Digest ************************** -------