🚀 go-pugleaf

On Sun 24 Jan, I (curry@iiasa.ac.at) wrote:

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ I believe that there is an "arithmetic" bug in my LJ-4M's PS-processor.
+ The bug turned up in the output of a complex LaTeX-dvips document:
+ the PS file prints correctly on an LJ-3 with HP-PS-cartridge,
+ but on the LJ-4M, one character in a particular math formula prints
+ in the wrong place -- it is shifted to the left by about 4cm.
+ I've isolated the bug, and reduced it to this simple self-contained code:
+ =========================================================================
+ 72 300 div 72 300 div neg scale   300 -3000 translate  % set dvips coords
+ 
+ 412 1000  moveto   /xxx1 currentpoint pop 100 string cvs def
+  14    0 rmoveto   /xxx2 currentpoint pop 100 string cvs def
+   2    0 rmoveto   /xxx3 currentpoint pop 100 string cvs def
+ 
+ /Courier findfont [ 50 0 0 -50 0 0 ] makefont setfont 300 1200 moveto
+ xxx1 show (  ) show xxx2 show (  ) show xxx3 show (  ) show  showpage
+ =========================================================================
+ That is, set units to 1/300 inch, with y-origin at top of page;
+ then just do an absolute move followed by two relative x-moves,
+ recording the current x after each move.  (In the original code,
+ the first "rmoveto" was actually a "show" of a char of width 14.)
+ Print the three remembered x-values.  (The y-values don't matter.)
+ 
+ On my LJ-4M, the values are 412.0, 426.0, and then 940.0 (not 428.0)!
+                                                    ^^^^^      ^^^^^
+ I say that this exhibits an "arithmetic" bug because the incorrect result
+ depends sensitively on the x-values used and on the two rmoveto's.  
+ Specifically, the final x-position becomes correct if I do any of:
+        (a)  replace "412" with "413" or "412.0001" or some random value,
+     or (b)  replace "2" with "1" or "3" or "2.0001" or some random value,
+     or (c)  replace the double "rmoveto" with a single "16 0 rmoveto",
+     or (d)  replace the "2 0 rmoveto" with "1 0 rmoveto  1 0 rmoveto".
+ 
+ I'd appreciate it if a few people with LJ-4M's could run the above code
+ and let me know whether the last number is right (428.0) or wrong (940.0),
+ together with the firmware revision data (from the "SELF TEST" page).
+ Mine are:  Formatter Number: S4601104CJ2     Firmware Datecode: 19920603
+            Installed Personalities: PCL (19920511)  POSTSCRIPT (19920610)
+ 
+ E-mail is probably best for responses; I'll post a report on the results.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Many thanks to the 12 people who responded.

Of the 12 responses:  5 said "right(428)", and 7 said "wrong(940)".

There was no "right/wrong" correlation with data from the "SELF-TEST" page.
    All had "POSTSCRIPT" as 19920610.  All had either 19920413 or 19920603
    for "Firmware Datecode"; some of each flavor were "right" and "wrong".
    All "PCL" dates were 19920414 or 19920511, corresponding to "Firmware".
    All "Formatter Numbers" were unique -- they are serial-numbers, I guess.

BUT there WAS a 100% "right/wrong" correlation with "geography":

    5 "right (428)"  --  ALL were from US/CANADA
    7 "wrong (940)"  --  ALL were from UK/EUROPE

Noticing that correlation, and recognizing the fact that there's only one
real difference between the cultures on the two sides of the Atlantic, :-)
I tried putting a "letter" command at the top of my test.  With "letter",
my printer (which has an a4-cassette) produces the "right (428)" result.
By symmetry, I predict that prepending an "a4" command to the test code
will produce the "wrong (940)" result on a printer with a letter-cassette.

So I guess (with some confidence) that "the 940 bug" exists on all LJ-4's,
at least when "a4" is forced.  If that's not the case, I'd like to know.

I should also report that I now have a second example of "the 940 bug".
I can't easily reduce this one to simple moveto/rmoveto commands as above,
because it involves a rather long "(str)show rmoveto (str)show..." sequence.
But on request, I can supply a dvips-created file in which the equivalent of
  ... (Eur) show -1 0 rmoveto (ope) show ...  % where -1 is kerning for r-o
prints the "ope" at x=940, whereas the "ope" is printed where it's supposed
to be if "-1" is changed to "-1.001", or if other minor perturbations
to x-values are made, or if "letter" is invoked.  (I am NOT making this up; 
I swear that this second example really did occur on the word "Europe"!)

This bug worries me.  It can happen anywhere on any page at any time,
even in documents that haven't been changed at all, except for "innocuous"
things such as increasing the left-margin by 1/30000 of an inch!
I have no way to estimate how frequently the bug can be expected to occur,
but I note that I have seen it happen twice in two days,
in contexts that are completely unrelated to each another.

As a temporary measure, for the locally-important case of dvips output,
I'll probably try adding a small x-offset (like .001) to the matrix that
dvips uses.  I know that this avoids the bug in the two cases I've seen;
and since dvips does everything in integer multiples of its units,
I have some hope that introducing a non-integer perturbation might help.

Any other ideas or comments?

In any case, I'll talk to my local HP rep in the morning.
(Feel free to use this info if you want to talk to yours.)

       Jim Curry                    ||  E-mail:    curry@iiasa.ac.at
       International Institute for  ||  Telephone: +43-2236-71521-204
          Applied Systems Analysis  ||  Telefax:   +43-2236-71313
       A-2361 Laxenburg // Austria  ||  Telex:     079137 iiasa a