TeXhax Digest Tuesday, February 4, 1991 Volume 92 : Issue 001 Moderators: Tiina Modisett and Pierre MacKay %%% The TeXhax digest is brought to you as a service of the TeX Users Group %%% %%% in cooperation with the UnixTeX distribution service at the %%% %%% University of Washington %%% %%%Moderator's note: Funding for the TeXhax Digest ceased in October 1991, %%%which is why none have been published in the past few months. We were %%%recently informed that funding is available for TeXhax for 1992, and %%%we have therefore resumed publication of it. Today's Topics: Mode Defs for NEC Silentwriter 2 90??? mac@iesd.auc.dk (Kaj Didriksen) AMSFonts for Textures posted to e-MATH Re: Problem with \bgroup \egroup in the definition of an environment Possible TeX bug discovered -- boxes and rules -------------------------------------------------------------------------- Date: Fri, 8 Nov 91 14:39:51 CST From: coleman@di.uregina.ca (Dr. Coleman) Subject: Mode Defs for NEC Silentwriter 2 90??? Keywords: mode_def, NEC Silentwriter 2 90 Can someone please tell me where to get them? Do they differ from those for an Apple Laserwriter II NT? Thanks. Robert Coleman Mathematics Department University of Regina Regina, Saskatchewan coleman@di.uregina.ca ------------------------------------------------------------------------------ Date: 8 Nov 91 10:29:44 From: mac@iesd.auc.dk (Kaj Didriksen) Subject: OzTeX Keywords: OzTeX, \special Hi, I'm an OzTeX user with a common problem: the \special command for inclusion of PostScript figures. I don't program TeX like a pro but have been programming PostScript for a year. The following is a solution for including PostScript in OzTeX documents. That I did. The thing is, that OzTeX puts the origin of the figure at the point where the \special command was found. OzTeX then prints the figure using the BoundingBox comment in the header of the PoscScript file. The BoundingBox comment is a description of the size of the figure and a description of the offset of the figure in PostScript coordinates and points. It is parsed as lower-left x-coordinate (llx), lower-left y-coordinate (lly), upper-right x-coordinate (urx) and upper-right y-coodinate (ury). To put the figure at the point, where OzTeX found the \special command, we have to make the BoundingBox comment look like this 0 0 (urx-llx) (ury-lly). We can tell the PostScript printer to calculate this for us bu putting these PostScript commands after the filename in the \special command: -llx -lly translate This prints the figure at the ''right spot''. Well, if we want the figure to center on the page we can put a \centerline around the \special command like this: \centerline{\special{psfile.ps}} This will not put the figure at the corect location because all we have done is to offset the origin. We have to place the figure half it's width to the left. this we can tell the PostScript printer by using the following PostScript commands after the filename in the \special command, like this: -0.5 urx llx sub mul 0 translate. The only problem left is to get the llx, lly, urx and urx numbers from the PostScript file. I told you that I don't program TeX so good, but I can read TeX! I found a styleoption called psfig that can do a lot of things to a PostScript file on a UNIX machine!!! Okay, but this psfig did read in the PostScript file and assigned llx,lly,urx and ury to variables \epsf@llx, \epsf@lly, \epsf@urx and \epsf@ury. I modyfied the psfig style to read like this at a certain point in the file: \centerline{\special{\@p@sfile \space -\epsf@llx \space -\epsf@lly \space translate \space -0.5 \space \epsf@urx \space \epsf@llx \space sub \space mul \space 0 \space translate}} the ps-file to include is assigned to \@p@sfile. THIS WORKS. Okay I have not yet removed all the unneaded TeX commands in the psfig file, but as of now I have a styleoption for OzTeX users that will place all PostScript figures correctly and centered on the page (not the physical page, but the page that LaTeX puts text into). If you want my styleoption mail me and I will send it to you. mac@iesd.auc.dk -------------------------------------------------------------------------- Date: Wed 6 Nov 91 15:06:14-EST From: Ralph Youngen Subject: AMSFonts for Textures posted to e-MATH Keywords: AMSFonts, TeXtures In response to several requests, we have posted the Macintosh version of the AMSFonts for use with Textures to e-MATH.ams.com. These fonts are stored as as BinHex'd StuffIt archives in the directory /ams/macintosh. For convenience, the AMS-LaTeX 1.1 and AMS-TeX 2.1 distributions are also stored in this same manner in the same directory. As always, please let us know if anyone finds problems with any of these files. Thanks. Ralph Youngen Technical Support Manager American Mathematical Society Internet: REY@MATH.AMS.COM ------------------------------------------------------------------------ Date: Tue, 5 Nov 91 09:12:46 CST From: max@nic.gac.edu (Max Hailperin) Subject: Re: Problem with \bgroup \egroup in the definition of an environment Keywords: environment, \bgroup \egroup I'm writing regarding the problems with the multicolpar.sty file, where there was a missing } in the \end{multicolpar} but putting an \egroup there didn't seem to help. The fundamental problem is that there is not one but *two* \bgroup's in the \mutlicolumnparallelparagraphs that need to be closed off (one for the \vtop, then an outer one for the \hbox). Therefore, if you had added a second \egroup to the one you already had in the ending part of the environment declaration, the error message about the missing } would have gone away. However, this doesn't properly solve the problem, in that it would not produce the proper spacing of the last row of paragraphs if the number of paragraphs were not evenly divisible by the number of colummns. [Actually, if the number of paragraphs was one more than a multiple of the number of columns the correct spacing would result as well, but with an underfull box warning. Hence, for the two column case the correct appearance would always be produced, sometimes just with a warning.] Therefore, to ensure proper spacing, it is necessary that \end{multicolpar} automatically introduce the requisite number of empty paragraphs to round up to the next multiple of the column count. This can be done by adding the definition of \endmulticolumnparallelparagraphs shown below and then changing the \newenvironment so that that command replaces the \egroup you have. Actually, there is one further problem I see with your definition, namely that it makes no provision for extra leading above and below the multicolpar environment. I would suggest therefore that you may also want to put a \begin{trivlist}\item[] into the beginning part of the environment definiton and the matching \end{trivlist} into the ending part, as shown below. This is completely independent of the \endmulticolumnparallelparagraphs part, and may not be appropriate to your application. =============== suggested change/addition to multicolpar.sty =============== \newenvironment{multicolpar}[1]{\begin{trivlist}\item[]% \multicolumnparallelparagraphs{#1}{2em}}% {\endmulticolumnparallelparagraphs\end{trivlist}} \def\endmulticolumnparallelparagraphs{% \egroup % end the vtop \advance\columnsleft-1 \ifnum\columnsleft>0 \hfil\vtop\bgroup\hbox to \hsize{} \endmulticolumnparallelparagraphs \else \egroup % end the \hbox \xpar \fi} ------------------------------------------------------------------------ Date: Fri, 08 Nov 1991 09:24:50 CST From: "Hunter Goatley, WKU" Subject: Possible TeX bug discovered -- boxes and rules Keywords: TeX, bug, boxes and rules This message documents what I believe is a bug in TeX. I welcome any corrections or explanations for what's going on. At the end of this message is a file (with comments) that demonstrates my claim. Just use plain TeX to process it. In my newsletter macros, I used a slight variation of the \boxit macro from exercise 21.3 in _The TeXbook_ to put boxes around article titles. For a long time, I've known about a problem with the boxes' rules not meeting properly on the right-hand side. As Rex Shudde <0024P@NAVPGS.BITNET> pointed out: >It's as if both the top & bottom horizontal rules run too far >to the right (or as if the right hand vertical bar is pulled to the right a >bit). Is this a glitch of some sort? > Before releasing the macros to the world, I tried my best to get rid of that anomaly, and was partially successful. It doesn't happen with all rule sizes; in fact, changing the rule size can cause the opposite effect: the vertical rule on the right will actually extend *past* the top and bottom horizontal rules. The \boxit macro is almost identical to Knuth's solution to exercise 21.3 in _The TeXbook_. All of my experiments led me to believe that it is some kind of bug in TeX (since the output is identical over several different DVI drivers under both VMS and DOS). If anyone finds a bug in what *I'm* doing, or has any suggestions, I'd be glad to hear about it. I've spent several hours trying various combinations. Each time I think I have it solved, I find more examples that fail. Hunter Hunter Goatley, VAX Systems Programmer, Western Kentucky University goathunter@wkuvx1.bitnet, 502-745-5251 % % Hunter Goatley, goathunter@WKUVX1.BITNET, November 8, 1991 % % The following TeX code demonstrates what I believe to be a bug in TeX's % processing of rules and boxes. % % The \boxit macro below is exactly the same as Knuth's answer to exercise % 21.3 in _The TeXbook_, except that I have added the ability to specify % the size of the rules and the amount of space to leave around the box. % \font\big=cmss17 \font\little=cmss9 \def\boxit#1{\vbox{\hrule height\boxitrule\hbox{\vrule width\boxitrule% \kern\boxitspace% \vbox{\kern\boxitspace#1\kern\boxitspace}\kern\boxitspace% \vrule width\boxitrule}\hrule height\boxitrule}} % % Now define the dimens used for the width of the rules and the spaces % \newdimen\boxitrule \boxitrule=1.2pt \newdimen\boxitspace \boxitspace=3pt % % A macro to calculate the extra width of a boxit'ed box. Used to subtract % the width of the box from \hsize so the box doesn't stick out. % \def\setboxwid{\boxitwidth=2\boxitrule \advance\boxitwidth by2\boxitspace} % % A macro used in my newsletter macros to do article titles. The inner box % rules are half the size of the outer box rules. % \def\articletitle#1#2{{% \setboxwid % Calculate width of outer box \advance\hsize by-\boxitwidth % Bring hsize in so it's not too wide \vskip 10pt plus 5pt % Skip some space \boxit{% % Box the box \divide\boxitrule by 2 % Make inside box lines thinner \setboxwid % Calculate width of inner box \advance\hsize by-\boxitwidth % Bring hsize in for inner box too \boxit{% % Box the text \vbox{\noindent % Create a box \centerline{\big #1} % Print title of article \centerline{\little #2} % Print article byline }}}}} % Create the text box %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Now do an article title using the default boxitrule (1.2pt) and boxitspace % (3pt). After it, do a plain \boxit. % % BOTH OF THESE COME OUT JUST FINE!!! % \articletitle{Hello, world}{by me} \bigskip \boxit{\vbox{\hsize=4in\centerline{Hello, world}}} \bigskip % % NOW, change the \boxitrule size to 2pt and do the same thing. This time, % the right-hand vrule on the outer box of the article title extends a % little too far to the right. The difference is only something like % half a point, but it is noticeable (particularly when viewed by something % like XDVI). % % Note that the plain \boxit doesn't have the problem. % \boxitrule=2pt \articletitle{Hello, world}{by me} \bigskip \boxit{\vbox{\hsize=4in\centerline{Hello, world}}} % % Now, to *really* demonstrate the bug, change the boxitrule to 20pt and % just do some text. The text below lies; the first one is OK and the % other two stick out to the right. % % I first used "No more examples" and found the problem. To make more sense, % I changed the text to "Sticks out at 20pt" and the problem went away! % ("Sticks..." is about 2pts narrower than "No...") The problem came back % with "Not OK at 20pt". Changing boxitrule to other sizes may or may not % produce the problem. I've never been able to find any kind of pattern % to this (IMHO) MAJOR bug in TeX. % \boxitrule=20pt \bigskip \boxit{\hbox{Sticks out at 20pt}} \bigskip \boxit{\hbox{Not OK at 20pt}} \bigskip \boxit{\vbox{\hbox{No more examples}}} \bye ----------------------------------------------------------------------- %%% Further information about the TeXhax Digest, the TeX %%% Users Group, and the latest software versions is available %%% in every tenth issue of the TeXhax Digest. %%% %%% Concerning subscriptions, address changes, unsubscribing: %%% %%% BITNET: send a one-line mail message to LISTSERV@xxx %%% SUBSCRIBE TEX-L % to subscribe %%% or UNSUBSCRIBE TEX-L %%% %%% Internet: send a similar one line mail message to %%% TeXhax-request@cs.washington.edu %%% JANET users may choose to use %%% texhax-request@uk.ac.nsf %%% All submissions to: TeXhax@cs.washington.edu %%% %%% Back issues available for FTPing as: %%% machine: directory: filename: %%% JUNE.CS.WASHINGTON.EDU TeXhax/TeXhaxyy.nnn %%% yy = last two digits of current year %%% nnn = issue number %%% %%%\bye %%% End of TeXhax Digest ************************** -------