[comp.text] TeXhax Digest V89 #49

TeXhax@cs.washington.edu (TeXhax Digest) (06/20/89)

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" <CHAA006%vaxb.rhbnc.ac.uk@NSFnet-Relay.AC.UK>
Subject: Re: TeXhax digest V89 #36-- two responses
Keywords: TeX, Linotype, PostScript


Tony Scandora <B35048%ANLCMT.BITNET@Forsythe.Stanford.EDU> 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 <UCGADKW%euclid.ucl.ac.uk@NSS.Cs.Ucl.AC.UK> 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
<period> to be the same as that of <ampersand> 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 <INHB%MCGILLC.BITNET@UWAVM.ACS.WASHINGTON.EDU>
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 <U33297%UICVM.UIC.EDU@UWAVM.ACS.WASHINGTON.EDU>
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) <P.Taylor%vaxb.rhbnc.ac.uk@NSFnet-Relay.AC.UK>
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 
<Alien@Ese.Essex.Ac.Uk>) 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 <s>, 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 <s> 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) <UCGADKW%euclid.ucl.ac.uk@NSFnet-Relay.AC.UK>
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 <ekberg@home.csc.ti.com>
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 <munnari!csv.viccol.edu.au!DOUGCC@uunet.UU.NET>
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 <your name>    % 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
**************************
-------