summaryrefslogtreecommitdiff
path: root/dviware/beebe/updates/00mail.17
blob: b96af767985848fbd8e6b8a4e7109242cb33f410 (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
31-May-88 18:41:51-MDT,5098;000000000000
Date: Tue 31 May 88 18:41:51-MDT
From: "Nelson H.F. Beebe" <Beebe@SCIENCE.UTAH.EDU>
Subject: DVI driver family update #17
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: <12402826690.23.BEEBE@SCIENCE.UTAH.EDU>

                  DVI Driver Family Update #17
                           [31-May-88]


=============
A SHORT FLASH
=============

I thought  that #16  [26-May-88] would  be the  last issue  until
early fall, but I just discovered that an important bug in dvialw
found on February did not get recorded in the change file, and so
did not make it into the newsletter.  The day after posting  #16,
Jerry Leichter and I solved a long-standing bug in dvijep.   Here
are the change log entries.

[30-May-88]     {Thanks to Jerry Leichter (LEICHTER@Venus.YCC.Yale.Edu)
                for providing an example that exposed this bug.}
                In dvijep.c, rules are  output one dot too  high.
                According to the  HP documentation, the  position
                of a rule is the upper-left corner.  I took  this
                to mean that  the rule would  be output  starting
                just under  the pixel  at (x,y)  in that  corner.
                What they must mean is that (x,y) is the position
                of the  pixel in  the  upper-left corner  of  the
                filled area.   Change the  definitions of  RULE()
                and RULE2() about line  160 to reduce the  height
                value by 1 in the arguments to MOVETO():

diff -c dvijep.c,75 dvijep.c
*** dvijep.c,75 Wed May 18 09:42:01 1988
--- dvijep.c    Mon May 30 19:03:07 1988
***************
*** 162,174 ****
  lower-left corner, while the LaserJet  Plus uses the upper-left  corner.
  */
  #define RULE(x,y,width,height) {\
!       MOVETO(x,(y)+height);PUTESC;\
        sprintf(plotfs,"*c%da%dbP",width,height); OUTST(plotfs);\
  }
  /* Set rule of  same size as  previous one at  TeX position (x,y).   The
  device coordinates will be changed on completion. */
  #define RULE2(x,y) {\
!       MOVETO(x,(y)+rule_height);\
        PUTESC;OUTST("*cP");\
  }
  /* Set the current font and character in preparation for a  DOWNLOADCHAR */
--- 162,174 ----
  lower-left corner, while the LaserJet  Plus uses the upper-left  corner.
  */
  #define RULE(x,y,width,height) {\
!       MOVETO(x,(y)+height-1);PUTESC;\
        sprintf(plotfs,"*c%da%dbP",width,height); OUTST(plotfs);\
  }
  /* Set rule of  same size as  previous one at  TeX position (x,y).   The
  device coordinates will be changed on completion. */
  #define RULE2(x,y) {\
!       MOVETO(x,(y)+rule_height-1);\
        PUTESC;OUTST("*cP");\
  }
  /* Set the current font and character in preparation for a  DOWNLOADCHAR */

                The same correction must be made to dvilzr.c  for
                the DataProducts laser printer.

                I had previously  received reports of  suspicions
                of an error  in dvijep's rule  positions, but  no
                one ever was  able to  supply an  example that  I
                could  reproduce   locally.   Here   is   Jerry's
                excellent little test file:

\documentstyle[12pt]{article}
\def\vec(#1,#2){\put(0,0){\vector(#1,#2){50}}}
\begin{document}

\setlength{\unitlength}{.01in}
\begin{picture}(0,0)(100,100)
\vec(-1,0)
\vec(1,0)
\vec(0,1)
\vec(0,-1)
%
\vec(-4,1)\vec(-3,1)\vec(-2,1)\vec(-1,1)
\vec(4,1)\vec(3,1)\vec(2,1)\vec(1,1)
%
\vec(-3,2)\vec(-1,2)
\vec(3,2)\vec(1,2)
%
\vec(-4,3)\vec(-2,3)\vec(-1,3)
\vec(4,3)\vec(2,3)\vec(1,3)
%
\vec(-3,4)\vec(-1,4)
\vec(3,4)\vec(1,4)
%
\vec(-4,-1)\vec(-3,-1)\vec(-2,-1)\vec(-1,-1)
\vec(4,-1)\vec(3,-1)\vec(2,-1)\vec(1,-1)
%
\vec(-3,-2)\vec(-1,-2)
\vec(3,-2)\vec(1,-2)
%
\vec(-4,-3)\vec(-2,-3)\vec(-1,-3)
\vec(4,-3)\vec(2,-3)\vec(1,-3)
%
\vec(-3,-4)\vec(-1,-4)
\vec(3,-4)\vec(1,-4)
%
\end{picture}
\end{document}

                When printed  with  dvialw,  the  two  horizontal
                rules are  printed  correctly; before  the  above
                correction to  dvijep, they  were one  pixel  too
                high, (this gives a  visible white streak).   The
                correction should also fix the misalignment  with
                the arrowheads.

[30-May-88]
                The  following  bug  in  dvialw.c  was  fixed  on
                3-Feb-88, but unfortunately  didn't make it  into
                this log.

diff -c dvialw.c,78 dvialw.c,79
*** dvialw.c,78 Sun Nov  1 11:21:38 1987
--- dvialw.c,79 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);

                There was a missing ')' in the output.
-------