TEX@Score.Stanford.EDU (TeX Project ) (05/28/88)
TeXhax Digest Tuesday, May 17, 1988 Volume 88 : Issue 46
[SCORE.STANFORD.EDU]<TEX.TEXHAX>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: <amgreene@athena.MIT.EDU>
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 <chris@mimsy.umd.edu>
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 <BHOLMES%WAYNEST1.BITNET@forsythe.stanford.edu>
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 <anita@vax1.acs.udel.edu>
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 <your name> % 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
**************************
-------
-------