schuster@panix.uucp (Michael Schuster) (01/01/91)
Recently there has been some discussion (from myself and others) about
problems with the HP PostScript cartridge. As promised, one of HP's
online CompuServe reps got back to me with answers to complaints arising
from myself, Don Lancaster, and this net. Here is the reply in its
entirety. Can you say "stonewall", boys and girls? Wait till I send this
to Don Lancaster.
=====beginning of forwarded text================================
Michael,
I had hoped to respond to your inquiries prior to the Christmas
Holiday. Unfortunately, researching these issues took longer
than expected. I apologize for any inconvenience this unforseen
delay might have caused for you.
As I was reading through your initial correspondence with Bill Loud and
Mr. Lancaster, I picked up on the following specific issues:
(1) Copypage Operator & Duplexing
(2) Arc & Setscreen Operators
(3) Unix Workstation Printing
(4) Complex Paths & Multiple Fonts
I have consulted with personnel from HP's Software Q&A and R&D
departments in order to prepare thorough responses to the issues
raised by Mr. Lancaster. You will find a response to each of
these issues in the paragraphs that follow.
1. The fact that the COPYPAGE operator does not store two pages
in memory is not considered to be a bug by HP or Adobe.
PostScript has always defined the COPYPAGE operator as a simplex
operator. It was not designed for multiframe buffers such as
those used in duplex printing.
2. HP acknowledges that the use of the ARC and SETSCREEN
operators, as demonstrated in SPOTDOTS, does fail with the HP
LaserJet PostScript cartridge. However, the use of those
operators in SPOTDOTS is unusual and not at all representative of
the intended use of the SETSCREEN operator.
The SETSCREEN operator was designed to allow users to define
their own grayscale pattern, if they want to use patterns other
than the device default. The last operand that the SETSCREEN
operator uses is a "spot function" that gets called once for each
pixel in the the halftone cell. The spot function's purpose is
to use the x and y coordinates of the pixel, which SETSCREEN puts
on the stack prior to calling the spot function, to leave a
number between -1 and 1 on the stack. This value determines the
order in which pixels within the cell are whitened to produce any
desired shade of gray.
Given the definition of the SETSCREEN operator and the spot
function, using the ARC operator within the spot function and
calling the SETSCREEN operator repeatedly, as demonstrated in
SPOTDOTS, is unusual. Other than SPOTDOTS, HP is not aware of any
applications or drivers whose implementation of the SETSCREEN
operator has caused any problems with th HP LaserJet PostScript
cartridge.
Even so, HP and Adobe are aware of this idiosyncracy and will
continue to investigate it.
3. HP has not been contacted by any customer experiencing
intermittent hang-ups when using a Unix Workstation and the
PostScript Cartridge, and as a result, we have not collected any
data on this potential issue. We are interested in working with
any user who has experienced difficulties of this nature. If you
can contact the customer that subscribes to the Unix
Communication Service, please encourage him to call HP's Personal
Peripherals Assist Group at (208) 323-2551. A trained technician
can help troubleshoot the problem, and if necessary, contact
other technical resources.
4. HP has not collected data which indicates that the PostScript
Cartridge will fail when given "too complex a path or too many
fonts in a job." As is the case with the usage of the PostScript
ARC & SETSCREEN operators, HP has not been made aware of any
applications or drivers, other than those provided by Mr.
Lancaster, whose implementation of complex paths and multiple
font selections have caused any problems with the PostScript
cartridge.
I was not able to determine, from your initial correspondence
whether you had personally experienced this difficulty or not.
If in fact you can duplicate this scenario, your input would be
of great assistance in our effort to track this potential issue.
I need the following information from you in order to initiate an
investigation.
- A printed self-test page after resetting your printer
- The front panel error message display after running the job
(if any)
- Another printed self-test page after running the job (do not
reset the printer)
- A copy of the file which causes this error condition
You can mail this information to me at the following address:
Curtis Reese
Hewlett-Packard
Boise Division
P.O. Box 15 MS516
Boise, ID 83707
This information will help me to effectively troubleshoot the
problem. I will make it a point to contact you within five
working days of the date that the data is received.
Michael, if we have "left a stone uncovered", do not hesitate to
contact me via e-mail. I look forward to hearing from you.
Sincerely,
Curtis Reese
==========end of forwarded message============================
--
l\ /l ' _ Mike Schuster ...!cmcl2!panix!schuster
l \/ l l l/ (_ NY Public Access CIS:70346,1745
l l l l\ (_ UNIX Systems MCI Mail,GEnie:MSCHUSTER wilker@gauss.math.purdue.edu (Clarence Wilkerson) (01/01/91)
I didn't get the impression that the HP reply was a stonewall, but just someone trying to not say more than they knew. Clarence Wilkerson
gaf@uucs1.UUCP (gaf) (01/04/91)
In article <1990Dec31.183001.6201@panix.uucp> schuster@panix.uucp (Michael Schuster) writes: >Recently there has been some discussion (from myself and others) about >problems with the HP PostScript cartridge. As promised, one of HP's >online CompuServe reps got back to me with answers to complaints arising >from myself, Don Lancaster, and this net. Here is the reply in its >entirety. Can you say "stonewall", boys and girls? Wait till I send this >to Don Lancaster. === reply deleted === After reading the reply from HP, I don't agree that they are stonewalling. It sounds to me like they're trying to get you (and anyone else having problems with their PS cart) to go through normal support channels. He acknowledged there were problems, and said they would continue to investigate them. He also said there was no hue and cry from the user community about these particular problems (translation: lower on their list of things-to-do than the ones people are hot about). That all seems reasonable to me. That you could reach some official company person on CompuServe, and that he would do any investigation and politely reply to you is a marvel in this age of "no support". By that I mean lots of companies (a) don't offer support at all, (b) hire support people whose IQ seems to be at the "you want fries with that?" level, or (c) charge outrageous rates for "real" support (where you can talk to someone who knows what you're talking about and will actually try your test cases). What more do you want from support? -- Guy Finney It's that feeling of deja-vu UUCS inc. Phoenix, Az all over again. ncar!noao!asuvax!hrc!uucs1!gaf sun!sunburn!gtx!uucs1!gaf
amichiel@rodan.acs.syr.edu (Allen J Michielsen) (01/05/91)
In article <370@uucs1.UUCP> gaf@uucs1.UUCP () writes: >In article <1990Dec31.183001.6201@panix.uucp> schuster@panix.uucp >>Recently there has been some discussion (from myself and others) about >>problems with the HP PostScript cartridge.... answers to complaints arising >>from myself, Don Lancaster, and this net >=== reply deleted === >After reading the reply from HP, I don't agree that they are stonewalling. ....more about hp, support, etc... Both HP's reply and Don Latest Computer Shopper article (which certainly is quite old due to magazine lead time), indicate several things clearly. 1. The Cartridges DO work. 2. The language 'difficulties/bugs/non-features' are a very minor problem. The bugs that mike & don (& others) point out are real. We could argue about the interpretation of them. If the same 'bug' existed in the apple laserwriter which has become 'the standard' by which all is measured, would they still be 'bugs', probably not. There are (somewhat) similiar bug that did and do exist in the apple application. HP's technical support has gone to some length to indicate their analysis of the bug (s). I disagree with HP on the duplex copypage analysis, but sort of agree with the others. (This leaves me open to seeing that others like don & mike may well disagree with hp on other points...) The problems associated with cutting a new rom set & version of the interpreter are many. I hope everyone can see that, and not just the cost factors either. There is the distribution costs, version support, .... all of it isn't cheap. I would much rather have them support the current (and in the future a few) versions of cartridges than (virtually) no support and hundreds of different versions of cartridges. I have printed quite well many many many postscript programs which I have written by hand. Some of these have been complex images taking as long as several hours to image. I have yet to have a program of mine NOT work on the HP cartridge. I completely agree that the error support of the cartridge compared to a full blown application is dissapointing, not to be expected, but still worth the cost factors involved in a limited budget like mine. The bottom line here, is find me a application that doesn't work on the HP cartridge. MOST people that should be buying these, use a application like wordperfect or lotus or first publisher or windows.... 99.99% of the time. Except for the windows bug (which affects MOST postscript devices including apples...and certainly is NOT related to ANY cartridge bugs...), I have yet to have a problem from ANY application using the cartridge. That is NOT to say that several applications did not require tweeking in their setup to properly work due to slight hardware differences and FEATURES unique to the HP printers. I must disagree with both don & mike analysis that the cartridge is too slow to be of any real considered value. Most of my throughput is on the same level as a apple or apple plus. Most of the time, the difference between the apple plus & IInt is small enough that if you took a swig of coffee you'd not know the difference. BUT it is not only possible but easy to write a involved program (like don does so well) that increases nearly a log factor the amount of time to image a page. I sometimes feel that some people are trying to built a realtime postscript display device from their printers, and this is outrageous in ANY form. I want a PRINTER to output paper that I want/need/use to do my job and make money. I'm not a publisher, and I'm not turning out tons of paper. In that analysis, the HP & cartridge is a great cost saving, functional solution to a output problem, and applaud HP & adobe for making it available at a reasonable price..... al -- Al. Michielsen, Mechanical & Aerospace Engineering, Syracuse University InterNet: amichiel@rodan.acs.syr.edu amichiel@sunrise.acs.syr.edu Bitnet: AMICHIEL@SUNRISE
brb@falcon.is (Bjorn R. Bjornsson) (01/06/91)
In article <1991Jan4.162536.10909@rodan.acs.syr.edu>, amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes: > The bugs that mike & don (& others) point out are real. Yes. > ... I have yet to have a program of mine NOT work on the > HP cartridge. Ditto. I have never seen the HP fail except using the example posted in this group, but then almost all of the thousands of pages have been generated by WordPerfect. I've seen a Lino RIP2 fail many times on some of this stuff although I'm not convinced it isn't the printing company's spooling software that's at fault. Does the Lino RIP2 have problems with long lines of PostScript code (600 - 1000 bytes)? Anyway, the HP cartridge has a nice feature that does away with complaints of pages missing due to paper jams. There's a 'setdojamrecovery' variable in the cartridge's statusdict that when set to true will print the page destined for the jammed paper on the next sheet. > I completely agree that the error support of the cartridge compared to a full > blown application is dissapointing, not to be expected, but still worth the > cost factors involved in a limited budget like mine. Agree, except for the exceedingly useful auto jam recovery feature. Bjorn R. Bjornsson brb@falcon.is