|
DMI News |
Previous Entry.. Next Entry.. Printer Woes
May 28, 2009 12:44 I'm not a technical newb, not by a long shot. I've been messing around with computers and electronics for a LONG time. I'm not saying that I don't get stumped frequently, but the simple things pretty much stay simple. Keep this in mind while I relate this story. One of my customers needs a new printer. This customer has been a customer of the family business since the early 80's, and somewhere in latter half of the 80's we upgraded them from a dot matrix printer (which they were using to print their invoices) to a laser printer. The design of the invoices was rather simple. Most of it was flat text, but there is some lettering on the invoices that is in a different and larger font. This was accomplished using some simple PCL language codes. No postscript or anything fancy like that. Obviously, the PCL language, at least that which we were using, was specific to HP laserjet printers. It it supposed to some degree on other printers, but as a rule, we just decided to stick with supporting HP printers exclusively, since as long as they remained backwards compatible, there wouldn't be an issue. Of course, I had long assumed that eventually there might come a day when it would be difficult to find a printer that would be easily backwards compatible, so we always kept alternative options available, but it woudl seem like supporting an old language set was never much of an issue. I mean, after all, when the printer supports postscript and other languages as well, and has a CPU better than what I had in my computer at the turn of the century, what difference would supporting an additional 20 codes take? Apparently none, because every HP laserjet printer we've tried in the last 20 years has supported it. Until 2 days ago. It's not like I didn't do my research. I just apparently didn't do it quite well enough. I had grown accustomed to the fact that, over time, more and more printers supported postscript directly. The additional cost to support it, verses not supporting it, especially when you have an onboard embedded print server and webserver, doesn't seem like much of a stretch. So I glanced at the "supported" languages, and postscript was listed as being supported. What I didn't competely notice or pay attention to was the "host based" text next to it. That's a fancy way of saying the printer doesn't support it at all, but the drivers do. It's the winmodem of printers. Why does this matter anyway? I'm not using postscript for the invoices anyhow, and definitely not for any of the other reports they print. That's true. But my alternative option for the invoices was to use Postscript, and I have made plans to move forward with a postcript invoice and phase out the old style. However, linux (the operating system they use) does have ghostscript, and can take a postscript source and convert it to the native language of the printer. The one I picked was "mostly" supported, but seemed to crank out a postscript file decently enough. I mean, it's not like this is a production environment or anything.... oh wait. However, trying to print out the original invoices clearly was not going to work. This printer did not support the PCL codes, but at the same time, it didn't work perfectly with postscript either. I could make that part work if I really had to, but.... There was a slightly larger problem. And this is where I refer to the "simple" things. I couldn't easily print out flat text. The most basic, low level, most well supported option of all. Just crank out flat text and have the printer churn out pages of text, unformatted, at 80x66, in plain old black and white text. That is all most of the reports require. And it couldn't do it. Of course, I could first convert my text to postscript and then print out the postscript after converting it back to printer language, but that changed the page size, which meant the page breaks were in the wrong places, and that started complicating matters even more. After about 4 hours of fussing with it, I started to consider the laundry list of things I would have to change, vs. going back to try to find another printer. Implenting a shiny new invoice is always a fun project, but it's not one I'm planning to do as a direct result of fixing another problem. That would just result in a bunch of new problems. Especially considering the fact that I'm sure I can find another printer that is compatible, even if I might have to throw a couple hundred $$ more at it. The most frustrating part of all of this was the fact that I couldn't get anyone to tell me if a specific printer would be backwards compatible. HP tech support was useless for this, and that was after the fact that I could barely understand him due to the accent. I perfectly understand the need to break away from the stoneage on these things, and if you're going to produce products that simply aren't going to support and complement previous products, that's a fact I can work with, and I can do what is necessary to upgrade my programs to handle it. But I need the necessary information to make these things happen. Some of us still live in a world where the interface with the printer is a bit more complicated than the little print icon on your screen. And I suppose I'm somewhat bummed by the fact that it's one more thing I'm going to have to waste a lot of time dealing with, because I'm going to have to be ready to deal with a number of unpredicatable futures just so I can properly continue operating in the present.
|