home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / postscri / 6504 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  6.0 KB
  1. Xref: sparky comp.lang.postscript:6504 comp.periphs.printers:4075
  2. Newsgroups: comp.lang.postscript,comp.periphs.printers
  3. Path: sparky!uunet!news.univie.ac.at!iiasa.ac.at!iiasa!curry
  4. From: curry@iiasa.ac.at (Jim  CURRY)
  5. Subject: Bug in LJ-4M PS-processor -- Verified
  6. Message-ID: <curry.728181261@iiasa>
  7. Sender: news@iiasa.ac.at
  8. Reply-To: curry@iiasa.ac.at
  9. Organization: IIASA, Laxenburg, Austria
  10. Date: Thu, 28 Jan 1993 00:34:21 GMT
  11. Lines: 102
  12.  
  13. On Sun 24 Jan, I (curry@iiasa.ac.at) wrote:
  14.  
  15. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  16. + I believe that there is an "arithmetic" bug in my LJ-4M's PS-processor.
  17. + The bug turned up in the output of a complex LaTeX-dvips document:
  18. + the PS file prints correctly on an LJ-3 with HP-PS-cartridge,
  19. + but on the LJ-4M, one character in a particular math formula prints
  20. + in the wrong place -- it is shifted to the left by about 4cm.
  21. + I've isolated the bug, and reduced it to this simple self-contained code:
  22. + =========================================================================
  23. + 72 300 div 72 300 div neg scale   300 -3000 translate  % set dvips coords
  24. + 
  25. + 412 1000  moveto   /xxx1 currentpoint pop 100 string cvs def
  26. +  14    0 rmoveto   /xxx2 currentpoint pop 100 string cvs def
  27. +   2    0 rmoveto   /xxx3 currentpoint pop 100 string cvs def
  28. + 
  29. + /Courier findfont [ 50 0 0 -50 0 0 ] makefont setfont 300 1200 moveto
  30. + xxx1 show (  ) show xxx2 show (  ) show xxx3 show (  ) show  showpage
  31. + =========================================================================
  32. + That is, set units to 1/300 inch, with y-origin at top of page;
  33. + then just do an absolute move followed by two relative x-moves,
  34. + recording the current x after each move.  (In the original code,
  35. + the first "rmoveto" was actually a "show" of a char of width 14.)
  36. + Print the three remembered x-values.  (The y-values don't matter.)
  37. + 
  38. + On my LJ-4M, the values are 412.0, 426.0, and then 940.0 (not 428.0)!
  39. +                                                    ^^^^^      ^^^^^
  40. + I say that this exhibits an "arithmetic" bug because the incorrect result
  41. + depends sensitively on the x-values used and on the two rmoveto's.  
  42. + Specifically, the final x-position becomes correct if I do any of:
  43. +        (a)  replace "412" with "413" or "412.0001" or some random value,
  44. +     or (b)  replace "2" with "1" or "3" or "2.0001" or some random value,
  45. +     or (c)  replace the double "rmoveto" with a single "16 0 rmoveto",
  46. +     or (d)  replace the "2 0 rmoveto" with "1 0 rmoveto  1 0 rmoveto".
  47. + 
  48. + I'd appreciate it if a few people with LJ-4M's could run the above code
  49. + and let me know whether the last number is right (428.0) or wrong (940.0),
  50. + together with the firmware revision data (from the "SELF TEST" page).
  51. + Mine are:  Formatter Number: S4601104CJ2     Firmware Datecode: 19920603
  52. +            Installed Personalities: PCL (19920511)  POSTSCRIPT (19920610)
  53. + 
  54. + E-mail is probably best for responses; I'll post a report on the results.
  55. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  56.  
  57. Many thanks to the 12 people who responded.
  58.  
  59. Of the 12 responses:  5 said "right(428)", and 7 said "wrong(940)".
  60.  
  61. There was no "right/wrong" correlation with data from the "SELF-TEST" page.
  62.     All had "POSTSCRIPT" as 19920610.  All had either 19920413 or 19920603
  63.     for "Firmware Datecode"; some of each flavor were "right" and "wrong".
  64.     All "PCL" dates were 19920414 or 19920511, corresponding to "Firmware".
  65.     All "Formatter Numbers" were unique -- they are serial-numbers, I guess.
  66.  
  67. BUT there WAS a 100% "right/wrong" correlation with "geography":
  68.  
  69.     5 "right (428)"  --  ALL were from US/CANADA
  70.     7 "wrong (940)"  --  ALL were from UK/EUROPE
  71.  
  72. Noticing that correlation, and recognizing the fact that there's only one
  73. real difference between the cultures on the two sides of the Atlantic, :-)
  74. I tried putting a "letter" command at the top of my test.  With "letter",
  75. my printer (which has an a4-cassette) produces the "right (428)" result.
  76. By symmetry, I predict that prepending an "a4" command to the test code
  77. will produce the "wrong (940)" result on a printer with a letter-cassette.
  78.  
  79. So I guess (with some confidence) that "the 940 bug" exists on all LJ-4's,
  80. at least when "a4" is forced.  If that's not the case, I'd like to know.
  81.  
  82. I should also report that I now have a second example of "the 940 bug".
  83. I can't easily reduce this one to simple moveto/rmoveto commands as above,
  84. because it involves a rather long "(str)show rmoveto (str)show..." sequence.
  85. But on request, I can supply a dvips-created file in which the equivalent of
  86.   ... (Eur) show -1 0 rmoveto (ope) show ...  % where -1 is kerning for r-o
  87. prints the "ope" at x=940, whereas the "ope" is printed where it's supposed
  88. to be if "-1" is changed to "-1.001", or if other minor perturbations
  89. to x-values are made, or if "letter" is invoked.  (I am NOT making this up; 
  90. I swear that this second example really did occur on the word "Europe"!)
  91.  
  92. This bug worries me.  It can happen anywhere on any page at any time,
  93. even in documents that haven't been changed at all, except for "innocuous"
  94. things such as increasing the left-margin by 1/30000 of an inch!
  95. I have no way to estimate how frequently the bug can be expected to occur,
  96. but I note that I have seen it happen twice in two days,
  97. in contexts that are completely unrelated to each another.
  98.  
  99. As a temporary measure, for the locally-important case of dvips output,
  100. I'll probably try adding a small x-offset (like .001) to the matrix that
  101. dvips uses.  I know that this avoids the bug in the two cases I've seen;
  102. and since dvips does everything in integer multiples of its units,
  103. I have some hope that introducing a non-integer perturbation might help.
  104.  
  105. Any other ideas or comments?
  106.  
  107. In any case, I'll talk to my local HP rep in the morning.
  108. (Feel free to use this info if you want to talk to yours.)
  109.  
  110.        Jim Curry                    ||  E-mail:    curry@iiasa.ac.at
  111.        International Institute for  ||  Telephone: +43-2236-71521-204
  112.           Applied Systems Analysis  ||  Telefax:   +43-2236-71313
  113.        A-2361 Laxenburg // Austria  ||  Telex:     079137 iiasa a
  114.  
  115.