summaryrefslogtreecommitdiff
path: root/dviware/beebe/updates/00mail.8
blob: 05215def847af9efb0675bd9a6e3d4e6a0a0cd70 (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
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
29-Apr-87 18:45:30-MDT,9269;000000000001
Date: Wed 29 Apr 87 18:45:29-MDT
From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
Subject: DVI driver update #8
To: beebe@SCIENCE.UTAH.EDU, $90%dhdurz1.bitnet@WISCVM.WISC.EDU, AbbottP%uk.ac.aston.mail%uk.ac.rl.gb@CS.UCL.AC.UK,
    Anderson%URegina2.bitnet@WISCVM.WISC.EDU, AustinS%ucbcmsa.edu@CS.UTAH.EDU,
    Berg-lists%gsb-why@SCORE.STANFORD.EDU, Brent%CSUFresno.edu@RELAY.CS.NET,
    Carvalho%ernie.Berkeley.EDU@CS.UTAH.EDU, CEL@CITHEX.CALTECH.EDU,
    Celoni@SCORE.STANFORD.EDU, Cmi011%uk.ac.soton.ibm%ukacrl.bitnet@WISCVM.WISC.EDU,
    Crawford-J%ohio-state.arpa@CS.UTAH.EDU, CRM8701%tamvenus.bitnet@WISCVM.WISC.EDU,
    Dan%buchmd.bu-cs.arpa@CS.UTAH.EDU, David%ci-dandelion.uucp@EDDIE.MIT.EDU,
    French%TI-EG@RELAY.CS.NET, Friesland%rz.informatik.uni-hamburg.dbp.de%germany.csnet@RELAY.CS.NET,
    Gaspard%hroeur5.bitnet@WISCVM.WISC.EDU, Goodall%admin.okanagan.bcc.cdn@RELAY.CS.NET,
    Grandi@NOAO.ARPA, Harringt%irlearn.bitnet@WISCVM.WISC.EDU, James%vaxe.coe.northeastern.edu@CS.UTAH.EDU,
    JRP%nplpsg.uucp@CS.UTAH.EDU, Karney%ppc.mfenet@NMFECC.ARPA, Kuo%sask.bitnet@WISCVM.WISC.EDU,
    Lamy%ai.toronto.edu@RELAY.CS.NET, Math300%unlcdc3.bitnet@WISCVM.WISC.EDU,
    Mcvax!ukc!sjl@SEISMO.CSS.GOV, MPC91B%dgogwd01.bitnet@WISCVM.WISC.EDU,
    Radford%frgag51.bitnet@WISCVM.WISC.EDU, RJones%uwovax.bitnet@WISCVM.WISC.EDU,
    Rohlicek%v1.bbn.com@CS.UTAH.EDU, RS%gnome.cs.cmu.edu@CS.UTAH.EDU,
    Simon%m_scrvx2%slb-test.csnet@csnet-relay.CSNet, SPQR%uk.ac.soton.cm@CS.UCL.AC.UK,
    Stone%ruthep.rutgers.edu@RUTGERS.EDU, System%uvphys.bitnet@WISCVM.WISC.EDU,
    Syvaxtgs%hheouh51.bitnet@WISCVM.WISC.EDU, Thobe@EE.UCLA.EDU, Wendy%crnlgsm.bitnet@WISCVM.WISC.EDU,
    U04z%cbebda3t.bitnet@WISCVM.WISC.EDU, X854%ddagsi3.bitnet@WISCVM.WISC.EDU,
    Zeffi%finabo.bitnet@WISCVM.WISC.EDU, "*APS:<BEEBE.TEX.DVI>MAIL.TXT.1"@SCIENCE.UTAH.EDU
X-US-Mail: "Center for Scientific Computation, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <12298494041.11.BEEBE@SCIENCE.UTAH.EDU>

Two bug fixes are reported in this note.  The family has now
been distributed to  over 100  sites, and  my secretary  has
been busy  for several  days getting  packages mailed,  with
still a dozen or so to go out.

I  have  received  several  reports  of  promising  work  in
progress which is summarized in the following paragraphs.

At least one site (Doug  Henderson at Berkeley) is  adapting
dvialw    to    support    the    Mergenthaler    Linotronic
PostScript-based phototypesetter, and I hope to visit  there
next week.

A couple  of  sites  report work  (or  good  intentions)  on
enhancing the dvialw special command support.  Brendan McKay
at The Australian National  University in Canberra has  done
some very nice work adding PostScript support as TeX  macros
which result in \special{} commands,  and has a port to  the
Amiga well on the way.  He has also implemented the  virtual
font mechanism for VAX VMS.   I hope he'll consider  writing
up the PostScript work for TUGBoat!

Dean Guenther at Washington State University is implementing
the family on IBM VM/CMS using the Waterloo C compiler.

I also  have first  reports of  use of  dvialw with  the  TI
OmniLaser, which  sports  version  45.0  of  the  PostScript
interpreter (Apple's 2 LaserWriter models are versions  23.0
and 38.0 respectively); the use of the "NOTE" paper type  in
the dvialw.ps  /BOJ macro  needs to  be changed  to  LETTER,
since the  TI printer  doesn't  recognize that  paper  type.
This  can  be  handled  portably  by  some  inserting   some
PostScript code to  check for  the existence  of that  paper
type, but I want to wait and see what changes are needed for
the Mergenthaler  before  a  new  version  of  dvialw.ps  is
introduced.

The HPLJ+ driver, dvijep, is  known to work on the  Personal
Computer Products LaserImage 2000 (Ricoh engine), as well as
on a MIL-STD clone, the Mitek 110T.  Isaac Salzman at RDL is
fighting the  DataProducts LZR-1230,  which is  supposed  to
emulate the HPLJ+, but apparently has some problems.

For the VAX VMS implementation, the suggestion was raised by
Ned Freed at Harvey Mudd College of using a third parameter,
"ctx=stm", to fopen(), which apparently gets around the need
for special versions of fseek() and ftell() in vaxvms.c.   I
haven't done this for two reasons.  First, the option is not
documented; it was  found in  microfiche listings  of the  C
runtime library,  and could  disappear,  or be  changed,  in
future versions of VMS C.  Second, and most importantly, not
all existing software on VMS knows how to handle stream mode
files, which are new with VMS Version 4.  In particular, the
Kellerman and Smith TeX implementation and Imagen DVI driver
and spooler  program on  which we  rely heavily  on our  VMS
systems do not,  and require fixed  blocked 512-byte  binary
records for DVI  and font  files.  Changing  to stream  mode
would be very awkward for us.  The latest version of the K&S
software with Metafont and  enhanced support for our  Imagen
3320 printer is  on order,  and if it  includes stream  file
support, I  may  change  my position.   I  cannot  think  of
anything good to  say about  record-structured file  systems
like VMS and IBM MVS; the  MS-DOS, TOPS-20 and Unix view  of
files as simple byte streams makes life MUCH easier.

John Pavel at NPL reported some typos in the latest  edition
of  the  DVI  driver  documentation  in  dvidriver.ltx   and
dviman.texinfo.  I have fixed both of these, so some of  you
receiving later  copies  of  Version  2.07  will  have  them
incorporated.  I  regrettably  forgot  to  rerun  GNU  EMACS
texinfo-format-buffer on dviman.texinfo after I updated  it,
and consequently 3 errors slipped by.  Here is VAX VMS style
difference listing:

************
File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;5
  624      @item @b{@@}
  625          Redisplay current page with @i{startup} page positioning.
******
File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;3
  624      @item @b{@}
  625          Redisplay current page with @i{startup} page positioning.
************
************
File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;5
  634          2, @dots{}.  The @TeX{} page numbers are displayed in the
  635          status window. This is a recursive display; if you respond
******
File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;3
  634          2, @dots.  The @TeX{} page numbers are displayed in the
  635          status window. This is a recursive display; if you respond
************
************
File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;5
  917   EMAIL: Beebe@@Science.Utah.Edu (Internet)
  918   @end display
******
File SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;3
  917   EMAIL: Beebe@Science.Utah.Edu (Internet)
  918   @end display
************

Number of difference sections found: 3
Number of difference records found: 3

DIFFERENCES /IGNORE=()/MERGED=1/OUTPUT=SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.DIF;1-
    SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;5-
    SYS$LIBROOT:[PLOT79.TEX.DVI.DOC]DVIMAN.TEXINFO;3

In dvidriver.sty  for Version  2.07, you  need to  insert  a
missing macro which is used in the index file:

 \newcommand{\FNNX}[1]{{\tt #1}}

Finally, here are two bug fixes, both VMS-specific, and only
one affects the driver family as currently distributed.

[29-Apr-87]     from Brendan Mackay (munnari!anucsd.oz!bdm@seismo.CSS.GOV)
                In machdefs.h, change
                #define REWIND(fp)      fseek(fp,0L,0)
                to
                #define REWIND(fp)      FSEEK(fp,0L,0)
                This is not necessary for the family as distributed, but
                Brendan  has  implemented   the  virtual  font   changes
                necessary for VAX VMS; they should be incorporated in  a
                future release.

[29-Apr-87]     from Brendan Mackay (munnari!anucsd.oz!bdm@seismo.CSS.GOV)
                The code for vms_read() [in vaxvms.c] has problems.  One
                is that you don't  test for end of  file.  The other  is
                that there is a bug in the C library which prevents  you
                asking for  more than  65535  bytes at  a time.   It  is
                documented  that  no  more  than  65535  bytes  will  be
                returned, but not that you  can't ask for more.  If  you
                do,  it  reduces  your  request  mod  65536!   Here's  a
                replacement:

/**********************************************************************/
/*-->READ*/
int
READ(file_desc,buffer,nbytes)
register int file_desc;
register char *buffer;
register int nbytes;
{
    register int ngot;
    register int left;

    for (left = nbytes; left > 0; /* NOOP */)
    {
        ngot = read(file_desc,buffer,(left > 65024 ? 65024 : left));
        if (ngot < 0)
            return (-1);        /* error occurred */
        if (ngot == 0)          /* eof occurred */
            return(nbytes-left);
        buffer += ngot;
        left -= ngot;
    }
    return(nbytes-left);
}
-------