[comp.text] TeXhax Digest V88 #90

TeXhax@Score.Stanford.EDU (TeXhax Digest) (10/16/88)

TeXhax Digest   Saturday, October 15, 1988   Volume 88 : Issue 90

Moderator: Malcolm Brown

Today's Topics:

               Need a new (cm) version of dviqms driver
                                bigTeX
                   Re:  TeX/LaTeX math <=> Macsyma
                      RE:  TeXhax Digest V88 #87
                   Re:  Question (UNIX, typesetter)
                TFM file for Adobe's Lucida Math font
                         svi2ps with lw fonts
                            LaTeX bug (?)
                          More on Bug in TeX
                            Hershey fonts
                     DVIEW adapter compatibility.
                 Re: Journals that accept TeX (flame)
                     a problem with footnotes...
                      Re: Page Make-up Challenge
            Full width figures and tables in twocolumn.sty
                      whence an FTPable DosTex?
                          Fig Mix-up Fix-up

----------------------------------------------------------------------

Date:     Fri, 7 Oct 88 12:36 EDT
From:     <FREELS%UTKVX3.BITNET@Forsythe.Stanford.EDU>
Subject:  Need a new (cm) version of dviqms driver

We need a dvi to qms-800 driver for VAX VMS.  We are running an old version
of dviqms which was set up for the am fonts.  It prints with many errors
and could not even find the cmssbx10 font.  I don't know who the author
of this program is but it seems to be what we want since it also handles
\special{}.  Could someone tell me where to get the latest and greatest
version for the cm fonts.  I tried Beebe's list and could not find a qms driver
there.  I can bitnet files to the following addresses:

freels%utkvx1.bitnet@cunyvm.cuny.edu

or via an arpanet link to another computer:

freelsj%oak.span%sdsc.bitnet@cunyvm.cuny.edu

I can also ftp files to the first address.

Any help is appreciated.

Jim (615)482-9031 ext 433

------------------------------

Date: Sat, 8 Oct 88 01:27 +1000
From: Douglas Miller <munnari!csv.viccol.edu.au!DOUGCC@uunet.UU.NET>
Subject: bigTeX

In TUGboat Volume 8 (1987) No. 2, Adrian F. Clark of British Aerospace offered
his "bigTeX" enhancements to TeX users via JANET at address
UK.AC.KCL.PH.IPG::ALIEN. I haven't been able to contact this address; is there
someone else who could send it to me (or tell me where I can pick it up from)?

Thanks.

------------------------------

Date: Fri, 7 Oct 88 18:38:00 +0100
From: unido!tellus.mathematik.uni-Bremen.de!bengt@uunet.UU.NET
Subject: Re:  TeX/LaTeX math <=> Macsyma

> Does anyone have code or ideas for easily converting from Macsyma
> equation output (any form) to LaTeX or TeX mathematical input? 

A few year ago I wrote a program for this, called MacEQ2TeX.  It is
used like this: By setting the variable typeset true in Macsyma,
Macsyma produces troff/eqn output in the d-lines.  This logfile is
then processed by MacEQ2TeX, which produces a (plain-) TeX file.

The output is as good as you can ask for, the biggest "bug" is that
Macsyma's typesetting routines are fairly weak.  The program is in
regular use at the Department of Automatic Control in Lund, Sweden.
There is a full TeX-manual, and some switches to e.g. interpret a2 as
$a_2$ etc.

MacEQ2TeX is unfortunately awfully bad written; I did not really
understand the problem when I wrote the program, but forced it to work
by numerous patches.  It is written in heavily VMS-dependent Pascal
(the worst language there is for string/character manipulation...)
:-(.  For this reason, and since I for the moment does not have access
neither to Macsyma or VMS, I am not willing to maintain it.  (However,
it would possibly be fairly easy to use it for Maple.)

The program is free and comes with documentation and macros, however
UNSUPPORTED.  Bugreports to /dev/null.  Contact me for distribution.

Bengt Martensson					+49 421 218-2952
Institut fur Dynamische Systeme, Universitat Bremen 	+49 421 171713 (home)
Postfach 330 440, D-2800 Bremen 33    
F.R.G.				      bengt@mathematik.uni-Bremen.DE  OR
                             bengt%mathematik.uni-Bremen.DE@uunet.uu.net

------------------------------

Date: Fri,  7 Oct 88 16:26:33 MST
From: Entia non sunt multiplicanda praeter necessitatem <JMS@mis.arizona.edu>
Subject: RE:  TeXhax Digest V88 #87

Victor Eijkhout <U641000%HNYKUN11.BITNET@Forsythe.Stanford.EDU> writes
about journals that accept TeX.

As the editor of one of those journals, I'd like to respond.  

First, his comment seems to be directed at expensively produced journals
like those from SIAM.  In that respect, I have to agree with his comments:
journals which accept TeX in lieu of sending out to typesetters may,
in fact, be reducing the quality of their journals.

However, journals like the ACM SIG newsletters do not have the luxury
of having outside typesetters.  These journals normally accept 
camera-ready copy, and print it as received.  In this case, accepting TeX is 
a big win, since we would rather have all articles published with the TeX
styles than some with worse-than-TeX and some with better-than-TeX
typesetting.   While the one or two most influential journals in a field
may be able to afford typesetting, all of the rest usually do some
variation on camera-ready.

His fear that journals may cut their typesetting budget and not 
move those monies into a TeXpert position is also well founded.  But
that's an editorial decision that each journal must make.  If costs
are rising so much that the options are either (1) cut costs or (2)
increase subscription prices, many publishers may decide on (1)
before (2).  Some journals are more interested in putting out the
information than having it look great.  To other journals, especially
the most important ones, quality of typesetting is very imporant.  
A valid point might be that some journals will ignorantly drop their
typesetter without getting a TeX hacker.  In that case, gentle 
reminders from their readers are usually all that are required.

For the journal I edit, the main benefits of getting TeX source directly
from the authors are: (1) our ability to print on better-than-300dpi devices,
(2) ease of entering the articles into electronic databases, and (3)
a shortened editing cycle.  While (1) and (2) are obvious, (3) is a 
serious plus for us.  By accepting articles over electronic mail, I
can fix a simple typograpical error or remove a problematic reference
(our journal does not allow articles which have "commercial" content;
often this can be fixed by the ommission of only a few lines) without
having to go through the cycle of consulting the author.  In cases
where the time-to-print is short (20 days after deadline for submission;
95% of articles arrive on deadline day), this means that I can print
articles which otherwise would have to be rejected.

As long as I'm writing this, I should point out that this was Barbara Beeton's
idea (if you don't know who Barbara is, you should) and that she
also created a customized style sheet for both TeX and LaTeX which made
articles fit into the pre-existing format perfectly.  

-- Joel M Snyder, Univ of Arizona Dep't of MIS, Tucson, AZ, 85721  --
--    BITNET: jms@arizmis  Internet: jms@mis.arizona.edu           --
--    Phone: 602.621.2748 Best Ice Cream: Toscanini's Chocolate #3 --

------------------------------

Date: Fri, 7 Oct 88 19:54:57 EDT
From: Chris Torek <chris@mimsy.umd.edu>
Subject: Re:  Question (UNIX, typesetter)

This information is not definitive, as I do not work with VMS, but I
have had a few brushes with it in the past (and survived mostly unscathed).

In TeXhax Digest V88 #87 Daniel Zwillinger <zwilling%linus@mitre-bedford.ARPA>
asks about sending a DVI file to a VMS machine:

>1) I first sent them a   tar   tape.  They couldn't read it.

There are public domain (or otherwise reasonably unrestricted) programs
available for VMS which will read `tar' format tapes.  (VMS's native
tape format is (a version of) ANSI standard labelled tapes.  There are
public domain programs for Unix which will read and write ANSI standard
labelled tapes, but they generally do not work well with binary files
like DVI files.)

>2) I then sent them a tape created with dd (the disk dump command).
>   They could read part of it, but not all of it.

This, too, is nonsense: VMS is perfectly capable of reading the last
partial record.  The `copy' command will not do it without some sort of
special fuss; for all I know, one may have to write VMS FORTRAN (or
other suitable language) code to call QIO directly.  It can, however,
be done.

Finally:

>Apparently the order of the bytes is different in a VMS and a UNIX
>system.  What to do ?

The byte order is identical.  The problem is most likely something else
entirely.  For whatever reasons, at least one common VMS TeX has chosen
to violate the proper DVI file encoding.  A DVI file is supposed to end
with between 4 and 7 bytes of 223's.  Apparently RMS makes it
inordinately difficult and/or inefficient to deal with anything other
than fixed 512 byte records, so instead, this VMS TeX pads with
anywhere up to 511 223s.  You will probably get the best results by
padding your original DVI file with extra 223 bytes until its size is a
multiple of 512.  For instance:

	% cat fill.c
	#include <stdio.h>
	main(argc, argv) char **argv; {
		register int i = argc > 1 ? atoi(argv[1]) : 0;
		register int fill = argc > 2 ? atoi(argv[2]) : 0;
		while (--i >= 0) (void) putchar(fill);
		exit(0);
	}
	% cc -o fill fill.c

(This is a `fill files with bytes' program---somewhat simplistic, for
it has no error checking.  Nonetheless, it should suffice.)

	% ls -l foo.dvi
	-rw-r--r--  1 chris        1844 Oct  7 11:05 foo.dvi
	% bc
	1844/512*512-1844+512
	204

(If this number were 512, the file would already be the proper length;
here, it is the amount of fill needed.  Append 204 223s:)

	% fill 204 223 >> foo.dvi
	% ls -l foo.dvi
	-rw-r--r--  1 chris        2048 Oct  7 11:09 foo.dvi

(Now nicely filled, so copy to tape:)

	% dd if=foo.dvi of=/dev/rmt8 bs=512
	4+0 records in
	4+0 records out
	%

The tape file should now be easy to read using MOUNT/FOREIGN and
COPY, and (assuming they do use this peculiar padding) should work
with their software.

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

------------------------------

Date:         Fri, 07 Oct 88 23:37:55 EDT
From:         Peter Galko <PTRPB%UOTTAWA.BITNET@Forsythe.Stanford.EDU>
Subject:      TFM file for Adobe's Lucida Math font

Adobe has a beta version of a Lucida Math font which can be used to replace
the CM math fonts.  I have a copy of this font and I would like to try to
test it out with TeX, but Adobe does not provide the TFM files for the fonts
and their AFM files doe not provide enough information to generate the TFM
file for the math fonts.

Is their anyone out their who has produced the TFM file (especially as a PL
file) who would be willing to pass on a copy and save me trying to find the
time to try to generate one myself.  Apparently Barry Smith of Blue Sky
Research has worked one out by hand but I have been unsuccessful in obtaining
a copy from him. Any help on this matter would be appreciated.


Prof. Peter Galko                      E-mail: PTRPB@UOTTAWA.BITNET
Department of Electrical Engineering
Room A-509, Colonel By Hall            Telephone: (613)-564-7097
770 King Edward Avenue
University of Ottawa
OTTAWA, Ontario
CANADA
K1N 6N5

------------------------------

Date: 10/08/88  1122
From: <guil%FRCICG71.BITNET@CUNYVM.CUNY.EDU>
Subject: svi2ps with lw fonts

I am looking for a dvi2ps which works with LaserWriter resident fonts.
Where can i get one dvi2ps.c (for my Unix System V machine) with
these possiblities ?

Thanks in advance

Laurent Guillope        Universite de Grenoble   France
Institut Fourier Laboratoire de mathematiques
GUIL@FRCICG71.Bitnet

------------------------------

Date: Sat, 8 Oct 88 14:34 PDT
From: Don Hosek <DHOSEK%YMIR.BITNET@Forsythe.Stanford.EDU>
Subject: LaTeX bug (?)

While producing a document for the Model United Nations club that called for
double sided printing with an inside margin greater than the outside margin,
I discovered the following problem: the titlepage is printed as a LEFT hand
page rather than a right hand page (understandalby enough from a programmers'
standpoint since 0 IS even). I think that this is a flaw in the way that LaTeX
handles the titlepage: perhaps this should be changed in a future version of
LaTeX.

-dh

------------------------------

Date:         Sat, 08 Oct 88 22:24:30 CST
From:         Huang Chi-Cheng <GT7B0002%TWNMOE10.BITNET@Forsythe.Stanford.EDU>
Subject:      More on Bug in TeX

This is mail I just sent to Prof. Knuth. If any one of TeXhax who also
had the experience what I had ,and has a solution is appreciated for
contacting with me .
----------------------------Original message----------------------------
 Prof. Knuth
            I'm not asking you to debug for me. I just doubted that there
  might be a bug in TeX. I used a primitive command \parshape with correct
   syntax but get an error message(or hang on the machine even worse).
  The following is the way I used :

                             - - - - - - - - - - % more than 5 lines of text
          paragraph 1        - - - - - - - - - - %without comtaining other
                                     .           %commands .
                                     .
                             - - - - - - - - - -
                             \par
                             \paeshape=40 0pt 15pc 0pt 15pc ... 0pt 15pc
                                       %exactly 40 speifications.
         paragraph 2         - - - - - - - - - - %about 8 lines text without
                             - - - - - - - - - - %other commands.
                                      .
                                      .
                             - - - - - - - - - -
                             \par
                             \parshape=40 0pt 15pc ... 0pt 15pc % 40 spec.
                             - - - - - - - - - - -%about 8 lines text without
                             - - - - - - - - - - -% other commands.
         paragraph 3                  .
                                      .
                             - - - - - - - - - - -
                             \par
                             - - - - - - - - - - - %remaining text
                                      .
                                      .
                             \end
     I tried \tracingall to debug,but it appeared nonsence to me that when
 TeX gobbled all the contents of par.3 and reached \par ,he gived me an
 error message "Infinite glue shrinkage found in a paragraph" before doing
 line breaking algorithm(But I did nothing about glue).How did all this happen?
      There is one important thing no mentioned,the number of line in 1st par.
 must be more than 5 ,otherwise nothing would happen.Each line above is about
 60 characteres .The machine I used is PC/AT,and running PCTeX v1.50(which is
 TeX 2.0 I guess).
                         email address:  gt7b0002@twnmoe10.bitnet
                                         N.C.T.U  Huang Cheng

------------------------------

Date:	Sun, 9 Oct 88 13:33:16 EDT
From:	Jeff Kesner <jok%gpu.utcs.toronto.edu@RELAY.CS.NET>
Subject: Hershey fonts

This submission is being sent in response to a question in texhax [#70].
I (jok@gpu.utcs.toronto.edu) am posting this submission for my father, Oliver.
Consequently, everything after this paragraph is written by him.  I will
accept any responses and forward them to him.  His interest in TeX
revolves around multi-lingual (hobby) desktop publishing.

Hershey fonts for the IBM PC are available from SoftCraft, Inc., and from
Austin Code Works. The SoftCraft set consists of four separate databases:
  HERSHEY.CHR  1594 characters
  ORIENT.CHR    758 char.
  PERSIAN.CHR   135 char.
  HEBREW.CHR     49 char.
The HERSHEY.CHR database includes, besides several Roman typefaces, Greek,
Russian, German Fraktur, and a variety of graphic symbols; the ORIENT.CHR
database has hiragana, katakana, and 623 kanji characters.

The format of the SoftCraft Hershey databases is given in their "Font Editing:
EFONT/CFONT User's Manual" on p. A5-2. Using this description, I wrote the
following Turbo Pascal 4.0 program to generate METAFONT source code from the
Hershey plotter directives:

%%% Sorry to have to do this, but Oliver's submission is too long for
%%% digest distribution (about 14K).   The submission can be FTPed
%%% from the machine "score.stanford.edu" by GETting the file
%%% "<tex.texhax>kesner.txh".   A copy of the file has been forwarded
%%% to TEX-L for BITNET distribution.              Malcolm

------------------------------

Date:         Sun, 09 Oct 88 23:01:54 IST
From:  "Jacques J. Goldberg" <PHR00JG%TECHNION.BITNET@Forsythe.Stanford.EDU>
Subject:      DVIEW adapter compatibility.

In spite of my efforts, I haven't been clear enough, it seems.

DVIEW works RIGHT AWAY with CGA, EGA and VGA cards ( I personally have
tested that on many PC, clones and PS2's).

With the SIMCGA40 stay resident patch it also works perfectly with
Hercules adaptors. That's what I run at home.

SIMCGA40 is available on the same servers as DVIEW, request <MSDOS.SCREEN>
SIMCGA40.ARC.

------------------------------

Date:     Mon, 10 Oct 88 09:26 N
From:     <POPPELIE%HUTRUU51.BITNET@Forsythe.Stanford.EDU> (Nico Poppelier)
Subject: Re: Journals that accept TeX (flame)

In TeXhax #87 Victor Eijkhout (U641000@HNYKUN11.BITNET) wrote:
> Some scientific journals allow authors to submit articles
> in the form of TeX code. I have two reasons not to be
> overly enthousiastic about this.
> ...
> I don't want to see a layman's layout anymore than I want to
> study a layman's articles.
>
> Let's hope this sparks some discussion.

A very simple answer is (of course): the scientific journals should
 - use LaTeX and _not_ TeX
 - design their own document style, to be used with LaTeX.

That way the author need only worry about the _contents_ and the
document style takes care of the layout --- provided the author
refrains from putting in his/her own macro's, change parameters etc...
(these rules can be stated in 'Instructions to the Authors').


         Nico Poppelier
         Theoretical Nuclear Physics
         University of Utrecht, The Netherlands

------------------------------

Date: Mon, 10 Oct 88 10:24:32 EDT
From: Mr. Scott Bodarky (ART-UGRAD) <bodarky@umbc3.UMD.EDU>
Subject: a problem with footnotes...

I am using the following footnote macros, which are modifications of 
ones recently published here in TeXhax.  The problem that I am having 
seems to occur when a footnote occurs at the very begining of a page,
when stuff that was originally supposed to go at the end of the
preceding page didn't quite make it, and was bumped to the next page.
Unfortunately, the numbering still applies to the previous page, so that
the first footnote on the new page is numbered as the last one on the
preceding.  If anyone knows of a solution to this, I would be greatly
appreciative...

\catcode`\@=11
\newcount\notenum
\notenum=1
{\catcode`p=12 \catcode`t=12 \gdef\\#1pt{#1}}
\let\getfactor=\\
\newdimen\footnotebaselineskip \footnotebaselineskip=10pt
  \dimen0=\footnotebaselineskip 
  \multiply\dimen0 by 1024
  \divide \dimen0 by \hsize 
  \multiply\dimen0 by 64
\xdef\fudgefactor{\expandafter\getfactor\the\dimen0 }
\def\footnote{$^{\footnumberfont\the\notenum}$\vfootnote}
\def\vfootnote#1{\insert\footins{\floatingpenalty=20000%
                                 \setbox0=\hbox{\footnumberfont\the\notenum%
                                                \penalty10000\hskip.5em%
                                                \footnotesize#1\hfil\break}%
                                 \dp0=0pt\ht0=\fudgefactor\wd0%
                                 \box0}%
                 \global\advance\notenum by 1}
\def\pagecontents{\ifvoid\topins\else\unvbox\topins\fi%
   \dimen0=\dp255\unvbox255% open up \box255
   \ifvoid\footins\else% footnote info is present
     \vskip\skip\footins%
     \footnoterule%
     \global\setbox1=\vbox{\makefootnoteparagraph}\unvbox1\fi%
   \ifr@ggedbottom\kern-\dimen@\vfil\fi%
   \notenum=1}
\def\footnoterule{\kern-3\p@
  \hrule width 2truein \kern 2.6\p@} % the \hrule is .4pt high
\def\makefootnoteparagraph{\unvbox\footins \makehboxofhboxes
  \setbox0=\hbox{\unhbox0 \removehboxes}
  \baselineskip=\footnotebaselineskip\noindent\unhbox0\par }
\def\makehboxofhboxes{\setbox0=\hbox{}
  \loop\setbox2=\lastbox
  \ifhbox2 \setbox0=\hbox{\box2\unhbox0}\repeat}
\def\removehboxes{\setbox0=\lastbox
  \ifhbox0{\removehboxes}\unhbox0 \fi}
\catcode`\@=12

Thanks,
Scott Bodarky
bodarky@umbc2, bodarky@umbc3
The Center for Studies in Nineteenth Century Music
College Park, MD.

------------------------------

Date:    Mon Oct 10 16:52:24 MET 1988
From:    XITIJSCH%DDATHD21.BITNET@Forsythe.Stanford.EDU
Subject: Re: Page Make-up Challenge

I have just read the submission of D. Rogers to TeXhax #86 and find the
problem very interesting. (I also struggle with the insertions...)
But I just want to make a comment on the comment because the
real solution is unknown to me, too:

Why not use \vadjust for the page break within a paragraph?
I think with a definition of

   \def\MidParPageBreak{%
      \vadjust{\vfill\eject}%
      }

the placement of \MidParPageBreak somewhere in the line that shall be
the last of the page will end the page but the paragraph will not be ended.
This is because the \vadjust constitutes a whatsit which comes in
effect after the line breaking have been done.
The \vadjust will also do at the last line of a paragraph.

I don't have a TeXbook here right now and don't remember if a whatsit
changes the space factor -- perhaps it must be restored afterwards.
Furthermore it may be that the macro must pay attention to the
preceding penalty values so that the line breaking is not damaged.
But this can be incorporated easily in the above macro.

Perhaps this can help in painful page breaking processes.
If there are any difficulties with the usage of a \vadjust in this
problem it would be fine to hear why.

                                Joachim


   TH Darmstadt
   Institut f\"ur Theoretische Informatik
   Joachim Schrod
   Alexanderstr. 24            Bitnet: XITIJSCH@DDATHD21
                                  (Please try again if I don't answer ---
   D-6100 Darmstadt               our Bitnet connection is very instable...)
   West Germany

------------------------------

Date:	  Mon, 10 Oct 88 09:37:12 PDT
From:     MINER%UTA.MFENET@NMFECC.ARPA
Subject:   Full width figures and tables in twocolumn.sty

  Has anyone ever implemented full width figures and tables in twocolumn.sty?
  This is similar to the optional arguement in \twocolumn which allow a
  title to go across both columns. This would also be useful in the case of
  a long complex equation which would need to go across both columns.

  Thanks,

  Buff Miner
  miner%uta.mfenet@nmfecc.arpa   ARPANET
  miner@utadnx                   BITNET
  (512) 471-5548                 PHONE

------------------------------

Date: 10 Oct 1988 13:32:19 CDT
From: Granroth@IOWA.PHYSICS.UIOWA.EDU
Subject: whence an FTPable DosTex?

Where may I copy (SPAN) or FTP (Internet) a complete copy of DosTex?
Please CC a reply directly to me since I miss much of TexHax.
Thanks!

Larry Granroth                  SPAN        IOWASP::GRANROTH
726 Van Allen Hall      	internet    GRANROTH@IOWA.PHYSICS.UIOWA.EDU
The University of Iowa	        NASAMAIL    LGRANROTH
Iowa City, IA  52242-1479       TELEMAIL    [LGRANROTH/JPL/NASA] NASAMAIL
U. S. A.                        PHONE       (319) 335-1960

"But why do I need Unix?  I don't even have a harem."  - VMS user

------------------------------

Date: Mon, 10 Oct 88 15:27:07 EDT
From: beck@svax.cs.cornell.edu (Micah Beck)
Subject: Fig Mix-up Fix-up

All versions of Fig 1.4 have a somewhat tricky problem with the use of
interpolated spline objects.  When drawing them on the screen, Fig reverses
the sense of forward and backward arrows.  Then, when they are printed
using f2p or f2ps, the same reversal is made.  Although the printed and screen
versions end up the same, the reversal messes up some Fig features such as
autoarrow which assume consistency between object types.

I am including two patches with this note: 

	1) fig.patch		patches the Fig program, F2p and F2ps
				works on Fig, Fig-FS, and XFig

	2) fig2tex.patch	patches the Fig2tex program

Fig2tex is part of the TransFig package.  The other TransFig translators
(fig2ps, fig2epic) seem to be correct.

When you apply these patches, the sense of arrows in any figures which use
interpolated splines will be reversed.  It is important to patch both Fig
and the backend translator, or else you will get inconsistent results.

The patches follow.  They are also available via anonymous FTP from
svax.cs.cornell.edu in directory ~ftp/pub/fig.

Micah Beck			beck@cs.cornell.edu
Cornell CS Department


----- START fig.patch ----- cut here ----- cut here ----- cut here -----

*** intspline.c.orig	Fri Oct  7 10:43:47 1988
--- intspline.c	Fri Oct  7 10:44:32 1988
***************
*** 176,192 ****
  
  	p1 = s->points;
  	cp1 = s->controls;
! 	if (s->for_arrow)
  	    draw_arrow(round(cp1->rx), round(cp1->ry), p1->x,
! 			p1->y, s->for_arrow, op);
  	for (p2 = p1->next, cp2 = cp1->next; p2 != NULL;
  		p1 = p2, cp1 = cp2, p2 = p2->next, cp2 = cp2->next) {
  	    bezier_spline((float)p1->x, (float)p1->y, cp1->rx, cp1->ry,
  			cp2->lx, cp2->ly, (float)p2->x, (float)p2->y, op);
  	    }
! 	if (s->back_arrow)
  	    draw_arrow(round(cp1->lx), round(cp1->ly), p1->x,
! 			p1->y, s->back_arrow, op);
  	}
  
  #define		T		0.45
--- 176,192 ----
  
  	p1 = s->points;
  	cp1 = s->controls;
! 	if (s->back_arrow)
  	    draw_arrow(round(cp1->rx), round(cp1->ry), p1->x,
! 			p1->y, s->back_arrow, op);
  	for (p2 = p1->next, cp2 = cp1->next; p2 != NULL;
  		p1 = p2, cp1 = cp2, p2 = p2->next, cp2 = cp2->next) {
  	    bezier_spline((float)p1->x, (float)p1->y, cp1->rx, cp1->ry,
  			cp2->lx, cp2->ly, (float)p2->x, (float)p2->y, op);
  	    }
! 	if (s->for_arrow)
  	    draw_arrow(round(cp1->lx), round(cp1->ly), p1->x,
! 			p1->y, s->for_arrow, op);
  	}
  
  #define		T		0.45
*** f2p.c.orig	Sat Aug  6 22:33:27 1988
--- f2p.c	Fri Oct  7 10:53:10 1988
***************
*** 467,475 ****
  	cp1 = s->controls;
  	x2 = p1->x/ppi; y2 = convy(p1->y/ppi);
  
! 	if (s->for_arrow)
  	    draw_arrow_head(cp1->rx/ppi, convy(cp1->ry/ppi), x2, y2,
! 		s->for_arrow->ht/ppi, s->for_arrow->wid/ppi);
  
  	for (p2 = p1->next, cp2 = cp1->next; p2 != NULL;
  		p1 = p2, cp1 = cp2, p2 = p2->next, cp2 = cp2->next) {
--- 467,475 ----
  	cp1 = s->controls;
  	x2 = p1->x/ppi; y2 = convy(p1->y/ppi);
  
! 	if (s->back_arrow)
  	    draw_arrow_head(cp1->rx/ppi, convy(cp1->ry/ppi), x2, y2,
! 		s->back_arrow->ht/ppi, s->back_arrow->wid/ppi);
  
  	for (p2 = p1->next, cp2 = cp1->next; p2 != NULL;
  		p1 = p2, cp1 = cp2, p2 = p2->next, cp2 = cp2->next) {
***************
*** 481,489 ****
  	    fprintf(tfp, "\n");
  	    }
  
! 	if (s->back_arrow)
  	    draw_arrow_head(cp1->lx/ppi, convy(cp1->ly/ppi), x2, y2,
! 		s->back_arrow->ht/ppi, s->back_arrow->wid/ppi);
  	}
  
  bezier_spline(a0, b0, a1, b1, a2, b2, a3, b3)
--- 481,489 ----
  	    fprintf(tfp, "\n");
  	    }
  
! 	if (s->for_arrow)
  	    draw_arrow_head(cp1->lx/ppi, convy(cp1->ly/ppi), x2, y2,
! 		s->for_arrow->ht/ppi, s->for_arrow->wid/ppi);
  	}
  
  bezier_spline(a0, b0, a1, b1, a2, b2, a3, b3)
*** f2ps.c.orig	Sat Aug  6 22:33:28 1988
--- f2ps.c	Fri Oct  7 10:54:59 1988
***************
*** 398,406 ****
  	set_linewidth(s->thickness);
  	a = s->controls;
  	p = s->points;
! 	if (s->for_arrow)
  	    draw_arrow_head(a->rx, a->ry, (float)p->x,
! 			(float)p->y, s->for_arrow->ht, s->for_arrow->wid);
  
  	set_style(s->style, s->style_val);
  	fprintf(tfp, "%% Interpolated spline\n");
--- 398,407 ----
  	set_linewidth(s->thickness);
  	a = s->controls;
  	p = s->points;
! 
! 	if (s->back_arrow)
  	    draw_arrow_head(a->rx, a->ry, (float)p->x,
! 			(float)p->y, s->back_arrow->ht, s->back_arrow->wid);
  
  	set_style(s->style, s->style_val);
  	fprintf(tfp, "%% Interpolated spline\n");
***************
*** 419,424 ****
--- 420,426 ----
  	if (s->for_arrow)
  	    draw_arrow_head(a->lx, a->ly, (float)p->x,
  			(float)p->y, s->for_arrow->ht, s->for_arrow->wid);
+ 
  	}
  
  genps_ctl_spline(s)

----- END fig.patch ----- cut here ----- cut here ----- cut here -----

----- START fig2tex.patch ----- cut here ----- cut here ----- cut here -----
*** fig2tex.c.orig	Fri Oct  7 11:12:13 1988
--- fig2tex.c	Fri Oct  7 11:14:30 1988
***************
*** 610,618 ****
  	cp1 = s->controls;
  	x2 = p1->x/ppi; y2 = convy(p1->y/ppi);
  
! 	if (s->for_arrow)
  	    draw_arrow_head(cp1->rx/ppi, convy(cp1->ry/ppi), x2, y2,
! 		s->for_arrow->ht/ppi, s->for_arrow->wid/ppi);
  
  	fprintf(tfp, "\\plot %6.3f %6.3f ", x2, y2);
  	for (p2 = p1->next, cp2 = cp1->next; p2 != NULL;
--- 610,618 ----
  	cp1 = s->controls;
  	x2 = p1->x/ppi; y2 = convy(p1->y/ppi);
  
! 	if (s->back_arrow)
  	    draw_arrow_head(cp1->rx/ppi, convy(cp1->ry/ppi), x2, y2,
! 		s->back_arrow->ht/ppi, s->back_arrow->wid/ppi);
  
  	fprintf(tfp, "\\plot %6.3f %6.3f ", x2, y2);
  	for (p2 = p1->next, cp2 = cp1->next; p2 != NULL;
***************
*** 624,632 ****
  	    }
  	fprintf(tfp, "\t/\n");
  
! 	if (s->back_arrow)
  	    draw_arrow_head(cp1->lx/ppi, convy(cp1->ly/ppi), x2, y2,
! 		s->back_arrow->ht/ppi, s->back_arrow->wid/ppi);
  	}
  
  bezier_spline(a0, b0, a1, b1, a2, b2, a3, b3)
--- 624,632 ----
  	    }
  	fprintf(tfp, "\t/\n");
  
! 	if (s->for_arrow)
  	    draw_arrow_head(cp1->lx/ppi, convy(cp1->ly/ppi), x2, y2,
! 		s->for_arrow->ht/ppi, s->for_arrow->wid/ppi);
  	}
  
  bezier_spline(a0, b0, a1, b1, a2, b2, a3, b3)
----- END fig2tex.patch ----- cut here ----- cut here ----- cut here -----

------------------------------

End of TeXhax Digest
**************************
-------