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: 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 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 Subject: RE: TeXhax Digest V88 #87 Victor Eijkhout 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 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 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 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 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: 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 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 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 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 %%% "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" 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 SIMCGA40.ARC. ------------------------------ Date: Mon, 10 Oct 88 09:26 N From: (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) 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 ************************** -------