summaryrefslogtreecommitdiff
path: root/dviware/beebe/updates/00mail.4
blob: 150018016904f930effec52230867d1d23e7cbf5 (plain)
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
25-Feb-87 11:33:35-MST,3082;000000000000
Mail-From: BEEBE created at 25-Feb-87 11:33:31
Date: Wed 25 Feb 87 11:33:31-MST
From: "Nelson H.F. Beebe" <Beebe@UTAH-SCIENCE.ARPA>
Subject: DVI driver update #4
To: $90%dhdurz1.bitnet@WISCVM.WISC.EDU, austins%ucbcmsa.edu@UTAH-CS.ARPA,
    cel@CITHEX.CALTECH.EDU, crawford-j%ohio-state.arpa@UTAH-CS.ARPA,
    crm8701%tamvenus.bitnet@WISCVM.WISC.EDU,
    david%ci-dandelion.uucp@EDDIE.MIT.EDU,
    gaspard%hroeur5.bitnet@WISCVM.WISC.EDU,
    james%vaxe.coe.northeastern.edu@UTAH-CS.ARPA,
    lamy%ai.toronto.edu@RELAY.CS.NET, mpc91b%dgogwd01.bitnet@WISCVM.WISC.EDU,
    rjones%uwovax.bitnet@WISCVM.WISC.EDU, rs%gnome.cs.cmu.edu@UTAH-CS.ARPA,
    stone%ruthep.rutgers.edu@UTAH-CS.ARPA,
    system%uvphys.bitnet@WISCVM.WISC.EDU, thobe@EE.UCLA.EDU,
    x854%ddagsi3.bitnet@WISCVM.WISC.EDU, zeffi%finabo.bitnet@WISCVM.WISC.EDU
cc: BEEBE@UTAH-SCIENCE.ARPA
X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <12281911255.16.BEEBE@UTAH-SCIENCE.ARPA>

Yesterday, we hit yet another problem with VMS C, and  today
I found a workaround.  The  symptom was that the  PostScript
macros prefixed to the .dvi-alw output file were  truncated.
I recompiled  DVIALW with  the  debugger this  morning,  and
single-stepped it through cppsfile(), verifying that all the
macros  got  written.   When  I  examined  the  output  file
closely, it  found that  the  truncation point  was  exactly
after  character  number   2048,  which   is  an   extremely
suspicious number, being a power  of two, and a multiple  of
the VMS file blocksize.

I haven't time now to step around in the library to find out
why it  is happening,  but I  have found  a workaround.   In
dviinit.h, I had arranged for  the output file to be  opened
in fixed-block binary mode, since  that was required by  the
Kellerman & Smith spooler  program which drives our  Imagen.
By reverting to stream-lf  form for all  by the Imagen,  the
problem disappears in the  PostScript output, and it  prints
correctly.  Here is the relevant section of dviinit.h:

#if    OS_VAXVMS
    /* Create fixed-length binary 512-byte instead of stream organization
       so Kellerman & Smith IMPRINT spooler will handle it. */
#if    IMPRESS
    plotfp = FOPEN(dvoname,"wb","rfm=fix","bls=512","mrs=512");
#else
    plotfp = FOPEN(dvoname,"wb");
#endif
#else
    plotfp = FOPEN(dvoname,"wb");
#endif

It is  possible  that this  will  break some  of  the  other
drivers, but since the only output device I have attached to
the VAX 8600 is the Imagen  8/300, it is hard to test.   Our
present FTP on the VAX is very poor and it is very difficult
to transfer  files  to another  machine  without  gratuitous
insertion of CRLF  pairs every so  often, or other  fiddling
with the binary data.  An FTP replacement from CMU should be
installed soon, but until then, it will not be feasible  for
me to really check the output from the VAX.

Feedback from user sites is therefore most welcome.
-------