Subject: TeXhax Digest V89 #49 From: TeXhax Digest Errors-To: TeXhax-request@cs.washington.edu Maint-Path: TeXhax-request@cs.washington.edu To: TeXhax-Distribution-List:; Reply-To: TeXhax@cs.washington.edu TeXhax Digest Monday, May 15, 1989 Volume 89 : Issue 49 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 %%% Today's Topics: Macro question Re: TeXhax digest V89 #36-- two responses Re: TeXhax Digest #36 Re: LaTeX footnotes...using letters or numbers as identifiers LaTeX: What changes may one legimately make to LFonts.TeX Persian and Arabic for TeX (METAFONT) Printing bitmaps in a LaTeX document Re: Problems with verbatim environment ---------------------------------------------------------------------------- Date: Wed, 10 May 89 14:10:57 CDT From: Cliff Bergman <@CCVAX.IASTATE.EDU:S2.CHB@ISUMVS.BITNET> Subject: Macro question Keywords: macro, parameter, testing Can someone please tell me how to test for an empty parameter in a macro. Specifically, I would like a device, \ifnull, so that after the definition \def\xyz#1*{\ifnull#1 \donullstuff \else \dootherstuff} the macro call: \xyz foo* will execute \dootherstuff, while \xyz* will \donullstuff. What is an appropriate definition of \ifnull? Cliff Bergman s2.chb@isumvs.bitnet --------------------------------------------------------------------------- Date: Wed, 10 MAY 89 12:22:42 BST From: CHAA006%vaxb.rhbnc.ac.uk@NSFnet-Relay.AC.UK Reply-To: "JANET CHAA006@UK.AC.RHBNC.VAXB" Subject: Re: TeXhax digest V89 #36-- two responses Keywords: TeX, Linotype, PostScript Tony Scandora asked about outputting TeX to a Linotronic photo-typesetter. >Our group of TeX/LaTeX users has been using 300 dpi laser printers for a long >time. Now we want to see important stuff printed on our 1200 dpi Linotype >typesetter than speaks only PostScript, as far as we know. I can think of >four ways to do it: > >Compute the PK fonts for that magnification and use DVIALW. I suspect that >computing the fonts may take a while and that PostScript files that contain >1200 dpi fonts may be pretty hefty. Has anyone done it? How bad is it? Yes, I've generated the fonts at 1270dpi. For all 74 canonical CM fonts at all seven canonical \magstep s, a total of about 24 hours CPU time on a VAX 8700/8800 cluster were involved. The files are available from the Aston archive in the U.K. I would acknowledge the kind donation of machine resources by British Petroleum Exploration to enable the generation of these fonts over one weekend. >Convert the METAFONT descriptions of the TeX/LaTeX fonts to scalable >PostScript >fonts and download them. Is that possible? Has anyone >done it? It's being done. I have no references to hand, but maybe ArborText and/or NorthLake are involved. >Come up with the font metrics for the standard PostScript fonts and use them. >This would probably require a PostScript plain.tex and lplain.tex that would >make DVI files that can only be printed on PostScript printers and would not >look like documents that use the TeX fonts. I've heard rumors that this has >been done. Would anyone care to substantiate same? No problem. It's definitely been done. I will make PS-Plain available on the Aston TeX-Server if required. >Convince Adobe to add the TeX/LaTeX fonts to the standard PostScript fonts. >I won't hold my breath for that one. Nor I. -0-0-0-0-0-0- Dominik Wujastyk made a suggestion concerning "Decimal alignment in LaTeX". Looking at Domninik's TeX, I {\it think} that he is using an ampersand as well as a full-stop. In Plain TeX, a more elegant solution would involve changing the \catcode of to be the same as that of for the duration of the table, thus alllowing natural alignment without additional formatting. Perhaps Dominik or another LaTeX guru could advise as to whether this solution would be equally applicable in LaTeX ? Philip Taylor Royal Holloway and Bedford New College -------------------------------------------------------------------------- Date: TUE 09 MAY 1989 17:11:00 EDT From: INHB000 Subject: Re: TeXhax Digest #36 Keywords: LaTeX, decimals The code contributed by Dominik Wujastyk in #36 can be improved considerably. Here is how I would have done it (I include only a portion of his table) \documentstyle{article} \pagestyle{empty} \begin{document} \begin{table}[htbp] \begin{center} \catcode`\<=\active \def<#1.#2>{\hbox to 40pt{\hbox to 25pt{\hss#1.}\hbox to 15pt{#2\hss}}} \def\p#1{\multicolumn{1}{p{40pt}|}{\small #1}} \begin{tabular}{|l|*4{c|}} \hline &\p{OLIVE}&\p{ORAN\-GES}&\p{COLO\-CYNTH}&\p{WINES}\\ \hline &&&&\\[-2.3ex] \hline 1885 &<2.25>&<7.05>&<2021.25>&<2.40>\\ \hline 1886 &<1.90>&<9.-->&<--.>&<3.10>\\ \hline 1887 &<12.50>&<24.-->&<605.-->&<2.12>\\ \hline 1888 &<6.25>&<21.20>&<1512.50>&<1.87>\\ \hline \end{tabular} \end{center} \end{table} \end{document} Several points to note. First the column headers are done the way they should: with parboxes. Second, I have used the * command for repetitive columns; this simplifies things somewhat. Third, the columns all have the same width and the decimals all appear in the same place, which is under your control. Fourth, I have added lines. The vertical lines are there only to clarify the spacing. The horizontal are there to illustrate how to get a double horizontal line without getting a gap as on pages 64 (bottom) and 182 (top) of the LaTeX book. In doing this I discovered that the \multicolumn command eats the following vertical line, so that the seemingly equivalent code: \def\p#1 {\multicolumn{1}{|p{45pt}}{\small #1}} \begin{center} \begin{tabular}{|l*4{|c}|} \hline does not produce the same effect. This is explained at the bottom of page 64, but I had never noticed it before (so much for italics). I have one final question. How and where is \@xifnch defined in LaTeX? As far as I can tell, the following code has to be what defines it, but I cannot see how: \def\:{\let\@sptoken= } \: % this makes \@sptoken a space token \def\:{\@xifnch} \expandafter\def\: {\futurelet\@tempc\@ifnch} This is crucial to understanding how \@ifnextchar works, although fortunately not to using it. Michael Barr ------------------------------------------------------------------------------ Date: Tue, 09 May 89 10:45:50 CDT From: Don Hosek Subject: Re: LaTeX footnotes...using letters or numbers as identifiers Keywords: LaTeX, footnotes On page 99 of the LaTeX book, it indicates that footnotes in a minipage are typeset using lowercase letters. The reason for this is that a minipage with a footnote is generally used in the following context: \begin{table} \begin{minipage}{\textwidth} \begin{center} \begin{tabular}{l} line 1\footnote{Footnote text here}\\ line 2 \end{tabular} \end{center} \end{minipage} \medskip \caption{A table with a footnote} \label{fg:mptbfn} \end{table} Which will make the footnotes part of the floating insertion (which is as it should be, if you think about it). The style of a minipage footnote is determined by \thempfootnote (see pp. 91-2 of the LaTeX manual). Similarly, the style of the normal footnotes is determined by \thefootnote. A complete list of numbering commands is given on page 175. There is a somewhat misleading statement as regards \fnsymbol, on that page. While it is true that \fnsymbol can only be used in math mode, it is not stated that \thefootnote and \thempfootnote are _always_ called in math mode. dh Don Hosek Internet: U33297@UICVM.UIC.EDU 3916 Elmwood Bitnet: U33297@UICVM.BITNET Stickney, IL 60402 DHOSEK@YMIR.BITNET Work: 312-996-2981 UUNet: dhosek@jarthur.claremont.edu JANET: U33297%UICVM.UIC.EDU@UK.AC.EARN-RELAY ----------------------------------------------------------------------------- Date: Tue, 9 MAY 89 15:28:20 BST From: CHAA006%vaxb.rhbnc.ac.uk@NSFnet-Relay.AC.UK Reply-To: Philip Taylor (RHBNC) Subject: LaTeX: What changes may one legimately make to LFonts.TeX Keywords: LaTeX, LFonts.TeX During a discussion concerning whether Ps-LFonts.TeX (a version of LFonts.TeX which uses PostScript fonts wherever possible) could legitimately be renamed LFonts.TeX, whilst still complying with the requirements of LaTeX and its author (Leslie Lamport), a colleague in the U.K. (Adrian Clark ) responded to a message of mine asserting that one must {\it never} rename Ps-LFonts.TeX to LFonts.TeX by saying: >>> I appreciate that you're trying to make a distinction and acknowledge >>> that your approach is correct in that context. But, to be pedantic, >>> there's no requirement mentioned in Lamport's book that LaTeX's fonts >>> should be CM-based. Indeed, lfonts.tex is *supposed* to be subject to >>> local modifications; and Lamport states in his book that the `local >>> guide' should contain details of which fonts are available and at what >>> sizes. So there's no `official' distinction between LaTeX-with-CM and >>> LaTeX-with-PS...although, I admit, this could lead to confusion. to which I responded: >>> I agree; you are correct. However, I feel that LL is WRONG ! (Just as I >>> feel Knuth was wrong in placing the origin at (1,1)). If I send a document >>> to a site , expressed in LaTeX, am I not to assume that when that site >>> processes the document, it will produce a (semantically) identical DVI file >>> to that which I produce locally ? If so, then must ascribe identical >>> semantics to the names of any fonts which I reference (even though the >>> glyphs themselves may be different). Ergo, the only changes one can >>> legitimately make to LFonts.TeX are (a) to add new fonts, and (b) to >>> replace the existing fonts with equivalents which have (\it identical >>> font metrics). The question is: which of us (if either) is correct ? Philip Taylor Royal Holloway and Bedford New College. ------------------------------------------------------------------------- Date: Wed, 10 May 89 14:01 From: Wujastyk (on GEC 4190 Rim-D at UCL) Subject: Persian and Arabic for TeX (METAFONT) Keywords: METAFONT, fonts, Persian, Arabic Jacques Goldberg has almost finished Arabic and Persian fonts, designed in METAFONT for use with TeX. He needs to do a little work on the preprocessor, and that's about all, to make the fonts distributable. He said it might take only a matter of hours. But it sounded from his letter as if he has rather lost heart with this project, and feels that no one is at all interested. So why should he make an effort? So, if you have any interest in seeing Arabic and Persian fonts made available for use with TeX, please send an encouraging note to Jacques, who is on Bitnet as GOLWS @ CERNVM . Dominik cc. HUMANIST -------------------------------------------------------------------------- Date: Tue, 9 May 89 18:02:48 CDT From: Tom Ekberg Subject: Printing bitmaps in a LaTeX document Keywords: LaTeX, bitmaps Back in January I was exploring how to get images into LaTeX documents and after using it a while I thought I would share my experiences with other TeXhackers. I tried three approaches to the problem and ended up with one which was reasonable in terms of the following areas: * performance in terms of host processing, meaning mostly that TeX runs fast enough. * doesn't require too much disk space. * prints fast enough. * is easy for a user to use. Other areas of interest, but not as important are: * ability to use more than one printer class. * not generating special fonts. This is important for our font daemon on one of our printers which has a fixed set of fonts that it knows about. * resolution independence. The first approach used MetaFont to generate glyphs to render the image and then paste them together in LaTeX. This approach split the image up into columns (if the image was too large) and then generated MetaFont commands to assign a column to a character. To generate the image, all one needs to do is to display those characters in the new font. This approach worked well since the C preprocessor for MetaFont that I wrote was quite fast, LaTeX ran quickly and the printer generated output at a reasonable speed. The only time bottleneck is MetaFont -- it can run rather slow, even on our MIPS 2000. A serious problem was that the imagen printer that I used keeps all of the font glyphs it loads in its memory until the print job completes. If several large images are to be printed, the first ones may succeed and the latter ones may fail because room is not available in the printer to store them. A variant to this was attempted where all of the image fonts used the same font family for the printer (imagen1, enco and deco were used to edit the file sent to the imagen). This didn't work because once a character in an Impress font is defined, subsequent redefinitions have no effect. There is no way to clear out font definitions either. The second approach was to use the sprite code obtained from V88I106 of TEXHAX. This approach used TeX to generate the image by forming rules for each scan line of the bitmap. The idea is to go through each row of the bitmap and look for a 1 bit, then, starting there, look for the next 0 bit and make a TeX horizontal rule of the appropriate length. Iteration continues on subsequent pixels in the scan line and then through all rows of the bitmap. The collection of TeX rules generated in this manner will cause the image to be regenerated. The advantage of this is that no special fonts are required, so the font space problems of the first approach are avoided. It also works on any printer and supports zooming and shrinking. A larger version of LaTeX was required to accommodate the sprite definitions. The default size of LaTeX's main storage table is 64K units (bytes, words or something); a new version was created which was 4meg units which wasn't quite large enough for the TI parking lot map I digitized (monochrome 1728x2000), but was large enough for my space shuttle bitmap (monochrome 1024x1500). The serious problem with this approach is that there are two time bottlenecks: it takes a long time for TeX to generate commands for the image, and it takes our imagen printer even longer to render the image. One case took more than 10 minutes on our MIPS for a 1 page file with a 576x720 bitmap and about 15 minutes for the printer. The first approach only required a long time if the bitmap was changed (reexecuting MetaFont), while this approach requires a long time all of the time. A preprocessor could be written to reduce the first problem by having the preprocessor generate the horizontal rules instead of having TeX do it (eliminating the level of command interpretation), but the printer will still take a long time. Summarizing, the MetaFont approach is reasonably fast, but one can run into font space problems in the printer. The sprite approach looks better on the surface, but it takes an unacceptably long amount of processing time. Both approaches are still viable for small images. The third approach that was investigated was to take a bitmap, generate the Impress file for it, and then have the imagen printer read the resultant file (well, pipe). This required a \special command to be implemented, hence a special version of the iptex (DVI->Impress) program. This was the last approach attempted because it only works for the imagen printer and it required modification of the standard iptex program (I am mostly a normal user). A LaTeX \bitmap macro was written to be the user-interface. Its arguments are: (1) the name of the bitmap file (2) and (3) the (X,Y) offset into the bitmap where the image starts. (4) and (5) the width and height in pixels of the image (6) the justification for the image. This can be one of l, c, or r, standing for left, centered, and right, respectively. (7) the magnification for the image. Only integers >0 are allowed. This macro makes a LaTeX box of the appropriate size and justification for the bitmap and generates the \special command for iptex. The large number of arguments in the macro should ensure its generality. For example, one could print the entire bitmap at a magnification of 1, and later in the document zoom in on other parts of the same bitmap at a magnification of 3. In addition to the LaTeX macro, the bitmap->imagen code was inserted into the imagen1 program. Imagen1 is the program which the shell script iptex calls to perform the .dvi -> Impress translation. The imagen1 addition processes the \special{bm...} command which contains the arguments specified by the user in the LaTeX \bitmap macro. Additional arguments generated by the LaTeX \bitmap macro are passed via the \special command giving the current values of the margins, text width, and bitmap type. The dimensions are used to place the image at the proper position on the page and for image size error checking. The bitmap type is passed in the event that someone adds support for bitmaps other than those from the TI Explorer computer. This third approach to printing images in LaTeX documents has been used by me and others in our group since January of this year. It meets the criteria mentioned earlier in that it is very fast for LaTeX, the only disk space required is for the bitmap, it prints reasonably fast and is easy for the user to use. The only special problem for the user is to determine the size of the bitmap (needed by LaTeX to generate a box of the appropriate size where the image will go). This was addressed by writing a program whose sole purpose is to print out information about the bitmap. -- tom (aisle C-4L), ekberg@csc.ti.com -------------------------------------------------------------------------- Date: Wed, 10 May 89 13:08 +1000 From: Douglas Miller Subject: Re: Problems with verbatim environment Keywords: LaTeX, environment definition On 11 Apr 89, uunet!eutrc4!rcpt@entropy.ms (Piet Tutelaers) asks: > a) Why does the following environment definition not work? > > 1:\documentstyle{article} > 2:\begin{document} > 3:\newenvironment{showinput}{\begin{quote}% > 4:\begin{verbatim}}{\end{verbatim}\end{quote}} > 5: > 6:\begin{showinput} > 7:\newenvironment{showinput}{\begin{quote}% > 8:\begin{verbatim}}{\end{verbatim}\end{quote}} ^^^^^^^^^^^^^^ > 9:\end{showinput} > 10: > 11:\end{document} > ! Extra }, or forgotten \endgroup. > l.8 \begin{verbatim}}{\end{verbatim}\end{quote}} Because the \end{verbatim} terminates the verbatim started by the \begin{verbatim} in the definition of showinput. The string "\end{verbatim}" is the one thing not allowed in a verbatim environment! You will probably need to define your own version of verbatim, called something else. > b) Is it possible to create a generalized environment in which each line > of text can be processed by a macro? Suppose we have an environment > `gedicht' to create verse's in which each line is numbered: You can do this by using \obeylines to make each line a separate paragraph and \everypar to process the line. In the `gedicht' example the skeleton of the code might be: \obeylines \everypar{\addtocounter{line}{1}\makebox[1cm][r]{\arabic{line}}~} \def\par{leavevmode\endgraf} % preserve blank lines in `gedicht' > c) The LaTeX document, as far as I have seen, does not explicitly forbid > spaces between the arguments of the \newenvironment: > \newenvironment{nam}[args]{begdef}{enddef} > ^? ^? ^? ^? > Where are spaces allowed and where not, and why? The LaTeX book (page 19) says ``Spaces between the command name and its argument(s) are ignored, but there should be no spaces beween separate arguments''. This is because a space is a valid argument delimiter in TeX. LaTeX commands don't have spaces between arguments in their macro definitions, so the may not appear between arguments when the commands are used. --------------------------------------------------------------------------- %%% 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 %%% %%% Concerning subscriptions, address changes, unsubscribing: %%% BITNET: send a one-line mail message to LISTSERV@xxx %%% where xxx is the nearest geographical site in the %%% tree shown below %%% SUBSCRIBE TEX-L % to subscribe %%% or UNSUBSCRIBE TEX-L %%% Here is the BITNET re-distribution tree as shown in a recent %%% REVIEW (The geography is guessed at from the subscription list) %%% %%% CLVM TAMVM1 FINHUTC %%% | | (Finland, UK, Scand, CERN) %%% | | | %%% TeXhax ----> UWAVM ----- MARIST ----- EB0UB011 ----- BNANDP11 %%% | (France,Italy,Spain) (Belgium) %%% | | %%% UBVM HEARN --- DEARN %%% (Netherlands) (Germany) %%% %%% Internet: send a similar one line mail message to %%% TeXhax-request@cs.washington.edu %%% Please be sure you send a valid internet address!! %%% in the form name@domain or name%routing@domain %%% and use the style of the Bitnet one-line message, so that %%% we can find your subscription request easily. %%% %%% All submissions to: TeXhax@cs.washington.edu %%% %%% Back issues available for FTPing as: %%% machine: directory: filename: %%% JUNE.CS.WASHINGTON.EDU TeXhax/TeXhaxyy.nn %%% yy = last two digits of current year %%% nn = issue number %%% %%% For further information about TeX Users Group services and publications %%% contact Karen at KLB@SEED.AMS.COM or write to TUG at %%% TeX Users Group %%% P.O. Box 9506 %%% Providence, R.I. 02940-9506 %%% Telephone (401) 751-7760 %%% %%% Current versions of the software now in general distribution: %%% TeX 2.95 (2.98 coming) metafont 1.7 %%% plain.tex 2.94 plain.mf 1.7 %%% LaTeX 2.09 ( 8/10/88) cmbase.mf see cm85.bug %%% SliTeX 2.09 gftodvi 1.7 %%% tangle 2.9 gftopk 1.4 %%% weave 2.9 gftype 2.2 %%% dvitype 2.9 pktype 2.2 %%% pltotf 2.3 pktogf 1.0 %%% tftopl 2.5 mft 0.3 %%% BibTeX 0.99c %%% AmSTeX 1.1d %%%\bye %%% End of TeXhax Digest ************************** -------