summaryrefslogtreecommitdiff
path: root/dviware/beebe/updates/00mail.4
diff options
context:
space:
mode:
Diffstat (limited to 'dviware/beebe/updates/00mail.4')
-rw-r--r--dviware/beebe/updates/00mail.465
1 files changed, 65 insertions, 0 deletions
diff --git a/dviware/beebe/updates/00mail.4 b/dviware/beebe/updates/00mail.4
new file mode 100644
index 0000000000..1500180169
--- /dev/null
+++ b/dviware/beebe/updates/00mail.4
@@ -0,0 +1,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.
+-------