1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
|
26-May-88 18:15:50-MDT,26245;000000000001
Date: Thu 26 May 88 18:15:48-MDT
From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
Subject: DVI driver family update #16
To: "DVI mailing list part 2": ;
cc: BEEBE@SCIENCE.UTAH.EDU
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <12401511229.12.BEEBE@SCIENCE.UTAH.EDU>
DVI Driver Family Update #16
[26-May-88]
============
INTRODUCTION
============
This newsletter should have gone out a couple of months ago,
but I have just been too busy. Utah is in the process of
planning for the purchase of a supercomputer, and I've been
serving on the technical committee for it since Oct-87.
Bids have now come in, and evaluations are underway.
I will be away from Salt Lake from 9-June to 5-August, and
unfortunately, will not be able to get Version 2.11 released
before I leave. I therefore felt that this issue had better
get out now, or you won't hear from me until September.
With my current mail volume, I expect that it will take 3 to
4 weeks after my return just to open and answer mail,
sigh...
============
MAKE PROGRAM
============
One of the notes below comments on a bug in the
public-domain version of Make. Ignore the comment about
volunteer efforts for preparing a fix. Since Easter, I've
developed a brand new ground-up reimplementation of Make
which on completion of testing will be available on the same
terms as the DVI family. This new implementation is
designed from the start to eliminate all the misfeatures of
other Makes, add features of newer Unix Makes, plus
directives similar to those of the C preprocessor (but with
! instead of # prefixes), conform completely to January 1988
draft ANSI C, run on multiple operating systems, and conform
(mostly) to the syntax of Unix Make. It is being tested
locally on a dozen different machines representing 5
hardware architectures and 4 operating systems. I'd hoped
to have it ready for beta testing before my June departure,
but alas, that will not be possible either. The current
version is working locally, has about 8800 lines of code in
itself and support software, plus about 100 pages of
documentation in two manuals. If any of you are interested
in getting your name in for a beta test release, send me
mail to that effect; it will, however, require that you have
Internet access for FTP, because I will not send tapes or
floppies, and it is too big for easy electronic mail
distribution.
=======
TURBO C
=======
Several people tried (unsuccessfully) to implement the
driver family on the IBM PC with Turbo C 1.0. The large
number of bugs that were being reported on the net
discouraged me from even buying it (one of the bugs resulted
in the reciprocal of division results being returned). I
bought version 1.5, and made some extensive tests with it on
the DVI family, the ELEFUNT elementary function test
package, and on my new Make implementation.
The good news is that Turbo C 1.5 is fast; compilation of
one DVI driver on the PC XT drops from 35 minutes with
Microsoft C 5.0 to 7 minutes with Turbo C 1.5.
The bad news is that the compiler is fatally flawed for C
programs containing floating-point, to the extent that even
random numeric constants are compiled into incorrect values!
I won't go into further details about this. A 10-page
letter to Borland International resulted in a positive
response from the software development director, and my
appointment as a beta test site for 2.0, which in-house at
least, fixes all the bugs I reported.
Given that the discounted price of Microsoft C is about
$350, and that of Turbo C about $45, it would be nice to
switch to Turbo C. For the new Make, which has no
floating-point usage, Turbo C performs admirably, and I've
not detected any bugs that affect Make.
The Turbo C library is not as complete as the Microsoft C
library; it lacks the <sys/xxx.h> files, <signal.h> and
signal(), utime(), and probably some others. The output
.EXE files seem to be somewhat smaller than those from
Microsoft C 5.0, and TLINK is much faster than LINK. LINK
can also be used with Turbo C output. Although Turbo C does
support most draft ANSI C syntax, it does not issue as many
helpful diagnostics as Microsoft C does, nor does it have an
option to produce ANSI style declarations from existing
code. Also, Turbo C's command line options are not
standard; instead of "cc -o foo foo.c", you have to write
"tcc -efoo foo.c" (no space after -e), which requires
additional nuisance changes in Makefiles.
Wildcard command-line expansion for compiled programs is
automatic; with Microsoft C, a special library routine has
to be loaded.
=====================
LATEX EDITING SUPPORT
=====================
I have developed some extensive support for editing LaTeX
files in GNU Emacs, which is widely available and runs on
most Unix and VMS systems. We are shipping Emacs copies on
VMS BACKUP tapes with the DVI drivers. The latex.el library
is now at beta test release 0.07, with 34 sites
participating.
latex.el grew out of a translation from TECO to Lisp of the
editing support I developed for TOPS-20 Emacs, which is
described in our Local LaTeX Guide; many of you have seen it
(it is accessible for ANONYMOUS FTP from SCIENCE.UTAH.EDU in
APS:<TEX.PUB.LOCAL-GUIDE>. Thanks to the ease of
programming in Lisp, I have added many new features,
including the availability on a key of every macro in the
LaTeX book, together with helpful information about macro
arguments. There is also support for SliTeX. The current
development version (pre-0.08) of latex.el is 2513 lines
long.
The library has a LaTeX-gripe function that makes it easy
for users to mail comments to me while they are still in the
editor , and I have several submissions that contain good
ideas that I'd like to implement before the final release.
I'd hoped to finish up the test before my departure, and
make an official release of latex.el to the Free Software
Foundation, but again, this will not be possible until at
least August.
===========
MAKEINDEX
===========
One of the changes recorded below is a correction to
TeXindex. After uncovering some further misfeatures of
TeXindex that make it unable on the IBM PC to handle index
files larger than 32767 bytes long (that in itself is a long
story), I turned my efforts to seeing if MakeIndex could be
gotten to work on non-Unix environments. That indeed was
the case, after a fair amount of work, and a couple of
months ago, an announcement of it was made on TeXhax.
MakeIndex now runs on all the systems that the DVI driver
family runs under (except IBM VM/CMS), and is a much
superior system. There was initial confusion about its
release status, because it was developed at the Berkeley
VORTeX project, which licenses its software for a fee. That
has been worked out, and MakeIndex may be freely
distributed; if that had not happened, I would have turned
elsewhere in search of a public indexing system. Pehong
Chen and Leslie Lamport have done an excellent job of
MakeIndex, and I urge you to get it and adopt it. Copies
are available for ANONYMOUS FTP from UCBVAX.BERKELEY.EDU,
SCIENCE.UTAH.EDU, CTRSCI.UTAH.EDU, and
JUNE.CS.WASHINGTON.EDU. It will become part of the
Washington Unix TeX distribution, and is also included on
DVI tapes that we ship from Utah.
=======================
DVI DRIVER DEVELOPMENTS
=======================
Since the 2.10 release in November, 1987, the DVI family has
seen the addition of two new drivers, DVIADX, for the Anadex
Silent Scribe 72dpi and 144 dpi dot matrix printers and
DVIGP, for the Phillips GP 72dpi and 144dpi dot matrix
printers. With these two, I am discontinuing the practice
of maintaining separate programs for different resolutions
of the same device (as was done for the Apple Imagewriter,
Okidata, and Epson printers); local recompilation with
different compile-time switch values can produce programs to
support the two resolutions.
A significant new development during the past month has been
the first successful port of the family to IBM VM/CMS using
the Waterloo C compiler; the changes have been merged into
my development sources, and will be available when 2.11
comes out. Shashi Sathaye at the University of Kentucky
gets credit for this; I've sent her a copy of the current
sources for verification of the merged changes. A couple of
weeks after I received her changes, I got notification from
Russell Fulton at the University of Auckland in New Zealand
that the start of a port to VM/CMS had also been made there.
Previous attempts elsewhere with the SAS and IBM C compilers
have been stymied by compiler bugs.
I've also received from Julian Perry an update for 2.10 of
the changes to dvijep.c to support portrait and landscape
printing, and Steven H. Gutfreund has supplied modifications
to support \special{}. Neither of these are currently
merged into the master sources, because I'm awaiting the
completion of the TeX Users Group committee report on
standardization of \special{}s and other DVI driver
features. On request, I have mailed the changes to
individuals who wanted to merge them into their own private
versions of dvijep.
Thanks to the good efforts of the following people:
"DVICAN@science.utah.edu":
! The DVICAN mailing list [25-May-88] !
beebe@science.utah.edu, !Nelson H.F. Beebe!
bertheau%FRINRA72.BITNET@cunyvm.cuny.edu, !Yves Bertheau!
DLT%STAR.RL.AC.UK@cunyvm.cuny.edu, !David Terrett!
friesland%rz.informatik.uni-hamburg.dbp.de@RELAY.CS.NET, !Gerd Friesland!
rjjt%oberon.sv.dg.com@cs.utah.edu, !Richard J.J. Tobias!
TFYS-PP%FINOU.BITNET@cunyvm.cuny.edu, !Pekka Pietilainen!
dvican@science.utah.edu ! !
!**** Last Line ****
dvican, the driver for the Canon LBP 8 A2, has been
substantially improved. I've formed a small mailing list
(the above people) to exchange correspondence about it; if
any of you on this larger DVI list (currently 224 sites)
have a Canon A2, let me know (soon), so I can get you on the
small list too.
==============
CHANGE HISTORY
==============
Because of the work noted in the preceding section, the
development directories have many more changes than are
recorded here. These here are ones that you might want to
patch into your local sources if they appear to impact you;
if not, just sit tight and wait for 2.11.
[18-May-88]
In dvijep.c about line 180, change
{PUTESC; sprintf(plotfs,"*c%dE",MAP_CHAR(ch)); OUTST(plotfs); }\
to
{PUTESC; sprintf(plotfs,"*cd%dE",MAP_CHAR(ch)); OUTST(plotfs); }\
This correction sets the font number to 0; the
old one works on the HP LaserJet, but might break
on clones.
[14-Apr-88]
Changed system() in vaxvms.c to allow warning and
information status returns to be treated as
success. The body of system() now reads:
t.dsc$w_length = strlen(s);
t.dsc$a_pointer = s;
t.dsc$b_class = DSC$K_CLASS_S;
t.dsc$b_dtype = DSC$K_DTYPE_T;
/* The 3 low-order bits of stat are
0 (warning),
1 (success),
2 (error),
3 (information), or
4 (severe or fatal error)
Consider values of 0, 1, or 3 to be success. LIB$SPAWN
will usually return SS$_NORMAL, independent of the value
of stat.
*/
if (LIB$SPAWN(&t,0,0,0,0,0,&stat) != SS$_NORMAL)
return (127);
switch (stat & 7)
{
case 0:
case 1:
case 3:
return (0);
default:
return (127);
}
[07-Mar-88]
Changed type of main() in keytst.c and lptops.c
from void to int, and inserted return(0) at end
to keep lint and VAX VMS C compiler happy. Draft
ANSI C (Oct-86 and Jan-88) does not specify what
the type of main() should be, and most compilers
don't care. VMS C 2.3 however produces an
annoying warning message if main() is not of type
int; I view this behavior as erroneous, because
main() is only a convention in C, and it is
possible to write C programs in many
implementations that do not have a main().
[02-Mar-88]
Added code to findpost.h to ignore trailing NULs
in a .DVI file, borrowing code from readpxl.h and
readgf.h that do the same thing for font files.
Users (including me) have been annoyed by the
inability of the drivers to handle a .DVI file
which has passed through a VAX VMS system where
gratuitous NULs are appended to pad the file
length to a multiple of 512 bytes.
This effort revealed another problem under VAX
VMS, and that is that the code in FSEEK() in
vaxvms.c on a request to position at end-of-file
actually positions before the last character,
instead of after it. An attempt at correcting
this was foiled by the VMS library ftell() which
returns 0 when the position set by FSEEK() is
outside the actual file limits, and while FTELL()
can correct the brain-damaged value returned by
ftell(), it cannot distinguish a nonsensical 0
result from ftell() at end-of-file from one at
the beginning of the file. Consequently, it has
been necessary in findpost.h to bump the
postambleptr value by one.
Since this modification can be installed
independently in even old versions of the DVI
driver family, and a context difference listing
is larger than findpost.h, here is the complete
new version:
/* -*-C-*- findpost.h */
/*-->findpost*/
/**********************************************************************/
/****************************** findpost ******************************/
/**********************************************************************/
void
findpost()
{
register long postambleptr;
register BYTE i;
register UNSIGN16 the_char; /* loop index */
(void) FSEEK (dvifp, 0L, 2); /* goto end of file */
/* VAX VMS binary files are stored with NUL padding to the next
512 byte multiple. We therefore search backwards to the last
non-NULL byte to find the real end-of-file, then move back from
that. Even if we are not on a VAX VMS system, the DVI file might
have passed through one on its way to the current host, so we
ignore trailing NULs on all machines. */
while (FSEEK(dvifp,-1L,1) == 0)
{
the_char = (UNSIGN16)fgetc(dvifp);
if (the_char)
break; /* exit leaving pointer PAST last non-NUL */
UNGETC((char)the_char,dvifp);
}
postambleptr = FTELL(dvifp) - 4;
#if OS_VAXVMS
/* There is a problem with FSEEK() that I cannot fix just now. A
request to position to end-of-file cannot be made to work correctly,
so FSEEK() positions in front of the last byte, instead of past it.
We therefore modify postambleptr accordingly to account for this. */
postambleptr++;
#endif
(void) FSEEK (dvifp, postambleptr, 0);
while (TRUE)
{
(void) FSEEK (dvifp, --(postambleptr), 0);
if (((i = (BYTE)nosignex(dvifp,(BYTE)1)) != 223) &&
(i != DVIFORMAT))
(void)fatal("findpost(): Bad end of DVI file");
if (i == DVIFORMAT)
break;
}
(void) FSEEK (dvifp, postambleptr - 4, 0);
(void) FSEEK (dvifp, (long)nosignex(dvifp,(BYTE)4), 0);
}
[20-Feb-88]
We have uncovered a bug in the public-domain
multi-operating-system make utility, pdmake.
When a file in a dependent list must itself be
built by application of a rule, the value of $<
gets changed to reflect that new file, but is
subsequently not restored to its value for the
original target file. Make will then apply the
rule for the target file, but use the wrong file
name. This situation never occurred before,
because dependent files are usually just include
files, which never have to be built by
application of a rule. The workaround in such a
case is to replace use of $< in a rule by
$*.suffix.
Here is a simple makefile that illustrates the
bug:
DEBUG = /NOTRACE /NODEBUG
BFLAGS = /NOLIST $(DEBUG)
.SUFFIXES: .obj .l32 .b32 .r32
.b32.obj:
echo
echo '.B32.OBJ:'
echo '$$@' = [$@]
echo '$$*' = [$*]
echo '$$<' = [$<]
echo '$$?' = [$?]
bliss $(BFLAGS) /OBJECT=$*.obj $<
.r32.l32:
echo
echo '.R32.L32:'
echo '$$@' = [$@]
echo '$$*' = [$*]
echo '$$<' = [$<]
echo '$$?' = [$?]
bliss /library=$*.l32 $<
ftp_user.obj: ftp.l32 cli.l32
To try it, create 3 empty files: cli.r32,
ftp.r32, and ftp_user.b32, and then type "make
-n". Unix make will correctly say
echo '$<' = [ftp_user.b32]
while pdmake will incorrectly say
echo '$<' = [cli.r32]
If the .b32.obj rule is changed to replace $< by
$*.b32, pdmake will work correctly.
Unfortunately, after spending a day and a half on
this bug, I cannot offer a program correction to
fix it, and I cannot spend more time on it.
Volunteer efforts are welcome.
The call sequence is such that make() calls
dyndep() which sets $< in a call to setmacro(),
then make() calls make1() which calls docmd2()
which calls expand() which then substitutes for
$<. If a file in the dependency list must be
made, make() will call itself recursively before
calling make1(), and that call substitutes a new
value of $<. The problem is that the code in
dyndep() to set $< cannot be used directly in
make1() before the docmd2() call, because at that
point, a rule is not being expanded, and a change
to $< would require knowledge about the files
which does not seem to be available there.
[06-Feb-88]
Revised lpt.ps to handle formfeed and tabs.
[03-Feb-88]
Alfred Ganz (ganz-alfred@yale.arpa) has been
updating the catdvi program which converts Unix
troff C/A/T output to a TeX DVI file; the
existing version only knows about the very old
DVI format version 1. In doing so, he found a
bug in setchar() in dvialw.c. DVI files output
by TeX normally will not cause setchar() to be
entered. There is a missing close parenthesis
that should have been output about line 106 in
setchar(). Here is a Unix context difference
(diff -c) listing; '+' marks the inserted line.
*** dvialw.c,78 Sun Nov 1 11:21:38 1987
--- dvialw.c Wed Feb 3 16:38:28 1988
***************
*** 1080,1085 ****
--- 1080,1086 ----
}
OUT_CHR('(');
OUT_XCHR(c);
+ OUT_CHR(')');
if (ycp != str_ycp)
{
OUT_NUM(xcp);
[03-Feb-88] {Adobe Transcript warning}
Alfred Ganz (ganz-alfred@yale.arpa) reports that
the Adobe Transcript spooler on his machine does
not do page accounting correctly when the input
file contains a Ctl-D (the last character
produced by dvialw). That character is there to
signal end-of-job to the printer; although it
would normally be supplied by a spooler program,
dvialw is used on many machines (e.g. IBM PC)
with less sophisticated connections to the
printer, and it therefore supplies the Ctl-D
itself. If you are using Transcript, check the
accounting records it creates, and if necessary,
comment out the final line
OUT_CHR('\004'); /* PostScript end-of-job signal */
in devterm() in dvialw.c. A similar patch should
be applied to lptops.c; look for the line
if (putchar('\004') == EOF) /* CTL-D for EOF signal */
and change it to output a newline ('\n') instead.
[25-Jan-88]
A couple of users have commented on the slow
speed and large output file sizes of dvil3p for
the DEC LN03+. The contributor, John Sauter
(sauter%dssdev.DEC@decwrl.dec.com), clarifies:
``Yes, it does create bitmaps. If you have an
LN03-PLUS but no font cartridges DVIL3P will
work, whereas DVI2LN3 (Flavio Rose's program)
requires at least one font RAM cartridge but does
not require the upgrade to full graphics (LN03 to
LN03-PLUS).''
It would clearly be desirable to have another
version that supported a downloaded font
mechanism like the Flavio Rose driver.
Volunteers, anyone? I have no LN03 access
locally to do it myself.
[20-Jan-88] {VAX VMS Warning}
I have observed that under VAX VMS, when a font
substitution file is used, the drivers may issue
the following (spurious) message:
%fontsub(): Bad font substitution at line 3 in file [TEX_INPUTS:texfonts.sub]:
[SYS$INPUT]
Current TeX page counters: [0]
They then continue correctly with the requested
substitution:
%Substituting font file [amcsc10 [mag 1369]] by [SYS$TEX:[TEX.CM.274]cmcsc10.pk
[mag 1369]]
Current TeX page counters: [0]
Simply relinking the program (WITHOUT
recompilation) with the debugger and running it
again causes the message to disappear. I am
therefore inclined to suspect a VMS code
generation error; since the message is harmless,
I do not propose to investigate it further.
Since VMS lacks the ability to insert a debugger
into the address space at run-time, like TOPS-20
can, it would be very difficult to track down
this error; the above output indicates that the
current input line read "SYS$INPUT", when in fact
no such string is found in texfonts.sub.
[13-Jan-88]
TEXIDX.C needs some changes to work correctly
under VAX VMS because of flaws in the VMS
library. Somehow it got overlooked for testing.
Here is a Unix context difference listing of the
changes (diff -c old new):
*** texidx.c,13 Sat Nov 14 23:21:38 1987
--- texidx.c Wed Jan 13 11:51:49 1988
***************
*** 51,56 ****
--- 51,59 ----
#include <stdio.h>
#include <ctype.h>
+ #define READ read
+ #define EXIT exit
+
#ifdef KCC_20
#include <file.h>
#define tops20
***************
*** 57,62 ****
--- 60,69 ----
#else
#ifdef OS_VAXVMS
#include <file.h>
+ #undef READ
+ #define READ vms_read
+ #undef EXIT
+ #define EXIT vms_exit
#else
#ifdef OS_ATARI
#else
***************
*** 413,419 ****
}
flush_tempfiles (tempcount);
! exit (0);
}
/* This page decodes the command line arguments to set the parameter variables
--- 420,426 ----
}
flush_tempfiles (tempcount);
! EXIT (0);
}
/* This page decodes the command line arguments to set the parameter variables
***************
*** 1027,1033 ****
if (desc < 0)
fatal ("failure reopening %s", infile);
! file_size = read (desc, data, total);
file_data = data;
data[file_size] = 0;
--- 1034,1040 ----
if (desc < 0)
fatal ("failure reopening %s", infile);
! file_size = READ (desc, data, total);
file_data = data;
data[file_size] = 0;
***************
*** 1676,1682 ****
char *s1, *s2;
{
error (s1, s2);
! exit (1);
}
/* Print error message. `s1' is printf control string, `s2' is arg for it. */
--- 1683,1690 ----
char *s1, *s2;
{
error (s1, s2);
!
! EXIT (1);
}
/* Print error message. `s1' is printf control string, `s2' is arg for it. */
-------
|