Follow Slashdot stories on Twitter


Forgot your password?

VA and HP Join Forces for Linux and Samba 96

aaf writes "VA and HP are working together to improve printing under Linux and Samba. Everything is and will be Open Source and the initial focus will be on improving existing Open Source printing software and enabling advanced functionality for Laserjets. It's all being developed and managed through SourceForge." While this is all LaserJet specific, I can't help but think that open sourcing everything will enable the community to build stronger cross-platform printing solutions for Linux.
This discussion has been archived. No new comments can be posted.

VA and HP developing Open Source printing

Comments Filter:
  • by Zurk ( 37028 )
    I dont see why Linux has bad printing mechanisms...i think lpr is perfectly good as a remote print spooler and the drivers + printtool utility with redhat work great with all my HP printers.
    Heck, ive even begun to replace HP JetDirect print servers with redhat or slackware we really need another print system ? Besides, even the CUPS guys [] are trying to build one...
  • by pb ( 1020 )
    Actually, Laserjets are far and away the printing platform used in business. And it's nice to see VA Linux supporting the community by using SourceForge, and HP promoting (even indirectly) Linux, where before some would have seen it as competition.
    I yearn for the day when companies write drivers for Linux(/Unix) and opensource them so that all Unixes can share in the glory, and we all laugh at Windows for a decade because it's fragmented, hard to use for longer than 30 minutes, and it locks you into proprietary solutions. :)
    pb Reply or e-mail; don't vaguely moderate [].
  • by EvlG ( 24576 )
    This is one of the few remaining spots in Linux that just plain stinks. I used to say that printing and ppp made Linux difficult/impossible for the masses to use. PPP is finally pretty easy to use, with tools like RP3, the debian PPP support, kPPP, etc. Looks like printing will finally work as well.

    I spent many, many hours trying to get my Linux workstation talking to the HP printers at work; after much failure I finally had success. I've never gotten printing to work reasonably well at all at home; trying to connect to my roommate's printer just didn't happen. We ended up sneaker-netting it, with printing to postscript and all. I had similar results with a Deskjet 600 physically connected to the box (ie, no network in the middle). Stuff would come out of the printer, but nothing was ever quite right. It was a classic case of configuration being prohibitively difficult, FOR NO GOOD REASON.

    Let's hope that what comes of this announcement can change things.
  • Actually, HP's base network printer drivers are mostly shell scripts - which are perfectly readable. Copyrighted, but readable and editable.

    Last time I checked, you could download them for free off of the HP site.

    Local print drivers are another story, but any printer with really really cool features should be networked anyway.
  • by bridgette ( 35800 ) on Wednesday January 26, 2000 @12:08AM (#1336505)
    HP's WebJetAdmin [] is network printer config/management software that supports RedHat.
  • I totally agree with this. I'm using RH6.1 and although it autodetected the HP DJ660Cse I had connected to the box, I can't print to it because it didn't drop anything into /etc/printcap.

    The box in question has a crappy video chipset and I don't even have a monitor connected to it, let alone a mouse and keyboard, so X is out of the question - thus printtool is also. I telnet into the box to do ANYTHING.

    So without having to learn all of the printcap commands OR installing and running X for ONE SINGLE APPLICATION, what's a person supposed to do?
  • IIRC, one of the reason RMS started the GNU thing was because of a printer with closed specs and no API to hack upton to add useful features.

    Now a decade later we have a major printer vendor with APIs and drivers out into the open on sourceforge ;-).
  • by Taco Cowboy ( 5327 ) on Wednesday January 26, 2000 @12:21AM (#1336508) Journal

    That is the question I have asked myself many, many times, whenever I play the role of "Linux advocate" and introducing Linux to the people around me.

    I can show them the amazing things Linux can do; The incredible value Linux represents; The wide array (and getting ever more wider) of softwares that run under Linux; The many platforms Linux runs under; but when it comes to printing, Linux takes a back seat, a back, back, back seat.

    If the joint effort between HP and VA is successful, then, I do not have to ask myself the "To print or not to print" question again, and I can go show them the amazing things Linux can do and I can put them on paper/slide/whatever.

    It's just another right step towards world domination.

  • for better color output and for double sided printing on the Deskjet 970 Clx series. Right now, only the driver for that other operating system supports duplex printing :-(
  • by voop ( 33465 ) on Wednesday January 26, 2000 @12:30AM (#1336510)

    I yearn for the day when companies write drivers for Linux(/Unix) and opensource them so that all Unixes can
    share in the glory, and we all laugh at Windows for a decade because it's fragmented, hard to use for longer
    than 30 minutes, and it locks you into proprietary solutions. :)

    Actually, what Linux (and Unix in general) needs is an architecture where it is straight forward for printer manufacturers to WRITE a (possibly binary-only) driver. The current solutions involving ghostscript and friends are too troublesome to write "drivers" for, requires the drivers be released under cirtain licences and does take some brains from the user to make work right.

    A unified system into which an arbitrary driver could easilly be plugged would yield a lot. Using something like the input- and output-filters of lpr is one option, which all too often seems to cause troubles for people. Ohh, and by the way that has the added overhead of the driver having to be able to interpret postscript (= what most Unix programs generate per default) in addition to its own "printer language".....

    That said, we also need decent libraries for interfacing the printer subsystem when writing applications - or have I been ignorant to what has been happening?
  • X can be run remotely. Try: export DISPLAY=host:0 where host is a unix box that _has_ X installed. It works great. (Don't forget to give permission for the display to be used with xhost)

    I always configure my non-X boxes by displaying on a remote machine with X; I even monitor resources with tools like lavaps, even if the box and display are physically many miles apart. Try it, it's fun.

  • This sounds pretty much like the 'server end' of printing... which is all very well for business use, but I'd like to see an attempt to address the 'desktop end'.

    What I want to see is 1440 dpi support for Epson Stylus printers, including the six-colour models. Once we have drivers for the photorealistic printers, we remove another significant 'but Linux cant do X' argument from the Windows crowd. After all, even if the GIMP is made to support CMYK, we get a quality Illustrator/Freehand clone, and a decent DTP package (hmm, will that wish list be resolved Real Soon Now?), we still can't get the best possible printing out of our shiny new colour printers...

  • I wish that when people write up stories as these, they'd actually explain what would be done about today's printing system. The print system used in linux does NOT suck, it's the same system that's been used for years without a problem. The fact that this article concentrates on SMB print sharing is a little off-topic I find, specially since there already exist the Common Unix Printing System. It already supports SMB, and although limited, the CUPS doesn't deserve to be one-uped by commercial entities that wish to simply create greater mind-share.

    I'd wish HP and VA would stick their noses out of the All-in-one solution (print drivers/SMB) and concentrate on drivers themselves, like as one post already described, for certain things like duplex printing.

    just my two 4:45am cents. :)

  • I have a deskjet 812 and it works (only with ghostscript), but the color looks like crap. My dad has a lexmark that looks better (under windows). I have always assumed that deskjets look like crap in unix because there is no photoRET-type layer in the drivers. To use photoRET would involve some image pre-processing (nothing the gimp couln't handle) and some special subset of PCL. Hopefully this will change. As a side note: the gimp printer plugin has support for a lot of deskjet printers, I have heard that they provide much better color quality than the ghostscript drivers (unfortunately they don't work with my printer so I can't confirm this).

  • by Silicon_Knight ( 66140 ) on Wednesday January 26, 2000 @12:45AM (#1336517)
    ... open the specifications, if not the code, to the Deskjet printers.

    Most home users, when they buy a HP, will buy a color inkjet, notibly the deskjets. These so call "Winprinters" require a Windows driver to convert the data to "Performance Printing Archetecture" (ie, kills your box's performance in order to print) and the PPA specs are NOT open. Fortunately for me and other unfortunate deskjet users, some brave soul out there had wrote a program called PBM2PPA that coverts postscript bitstream to PPA for printing. Of course, the conversion does a toll on my box and is only good for black and white, but at least printing is now a possibility...

    -=- SiKnight
  • Personally, I'd just like support for my lowly Epson Stylus 300 (stop laughing at the back), so I wouldn't have to reboot into Windows just to print something 8-(.
  • why not display printtool over the telnet session? just curious? i've had many linux boxes without a monitor and ran X applications on all of them simoultaniously to one X session.
  • I am involved in convincing users not to print every email, or print every web page. It has been difficult, but I have cut down on the amount of "post it" appointments and announcements.

    I have no desire to make printing for the user easier. If I could get away with it, I would put a delay on all print jobs of about 3 hours.

    Some of my older users want to file every print job in their own personal file cabinet. The infrastructure I have in place archives every piece of email and data in the servers. Everything is backed up with off site backups and a small backup cluster.

    Thank you for the involvment in open source HP and VIA, but I shall not drink of this wine.
  • For more information on the Initial Code Offering (ICO(TM)) of [...]

    These people are soooooooo amusing! They'll trademark anything!. In fact, I guess I can start dropping TM at random places...


  • by XNormal ( 8617 ) on Wednesday January 26, 2000 @01:08AM (#1336523) Homepage
    This is great news, but...

    Aren't we going to have too many different printing solutions out there? This announcement follows Corel's announcement about their own linux printing system. They may both be great systems, but probably incompatible and will leave application developers confused.

    Having multiple solutions for the same niche is normal for open source (KDE/Gnome and countless other examples) and for most cases I think it is actually a good thing. But somehow for printing I don't think this would be a good idea. I prefer to have just one way to print. Currently the de-facto standard is simply PostScript. It's not perfect but it works.

  • by Flower ( 31351 ) on Wednesday January 26, 2000 @01:20AM (#1336524) Homepage
    While this news out of HP is commendable I still wish they would reverse their stance when it comes to their DeskJet models.

    I actually took the time to try and get some information out of HP to see if I could maybe get some added functionality out of my DeskJet 970Cse. Specifically, using the duplex module and getting a resolution higher than 300x300. I've learned the following things:

    HP does not support using DeskJets in a *nix environment as they consider printer usage will be higher than what they reccomend. They run under the assumption that the printer will be networked and, I guess, not on a workstation.

    Requesting info on extended PCL codes and technical info on how the duplex module is initialized was a bust. Even though I informed them that I knew HP's policy re: linux but simply wanted information about the printer I got an email back with the policy statement, a responce that in order to change the printer's resolution I should click a tab and select 'Best', and a link to a list of regular PCL codes used in DOS (actually the only useful bit of info I have currently.)

    Next was going to the community board for my printer and requesting more info. Someone else had posted an inquiry for pretty much the same info I wanted and the moderator provided a phone number to another division. As the number was long distance I requested an email addy and the responce can be summed up as "Not familiar with that department. The number is it." Checking the other posts, I noted the common theme was check with your vendor. For linux, that pretty much means Ghostscript.

    Looked around Alladin's site and finally got around to downloading version 5.99 so I could look into the documentation. I read the comments re: the deskjet drivers and have pretty much given up on the idea of improving the drivers. Making a long story short (too late), the documentation for the driver reports:

    However, HP will not support user-level programming of this resolution-enhanced mode, one reason being that (I understand) all the dot spacing has to be done by the driver, and if you get it wrong, you can actually damage the print head.

    I really do like the printer. I am glad I bought it and considering my original purpose in buying it was not for use under linux I don't feel too bad as it looks like I'm stuck with less than optimal print quality. However, the bullet issue for my next printer will be linux support and unless HP rectifies this issue I don't think I could reccommend any of their DeskJet products to another linux user.

  • by Anonymous Coward
    Have you looked at the source for the UNIX true command? It consists of am AT&T copyright notice and nothing else. (TM)
  • Exactly. It's the Deskjets that need better printing support. Many (most?) Laserjets already support postscript, and so don't have much of a problem printing under linux right now.

    What we really need is a decent Postscript to PCL filter. Everything that's available now (ie. ghostscript) is just a reverse engineering attempt that doesn't work 100%. That, along with duplex support and cartridge alignment tools would the most usefull thing HP could do for Linux printing.
  • by Anonymous Coward
    Back in 1995 it was possible for a nominal fee
    to buy a collection of around ten books with a
    total of 2000+ pages from HP Amsterdam,
    describing all the details around the LaserJet
    printers (drivers, fonts, command languages, etc.
    pp.) for a nominal fee of around 80 Dutch Gulden.
    (barely covering the shiping costs of this
    pile of paper).

    When I had a delivery problem, I was even called
    by a high ranked HP sales rep who excused for the
    problem, send a replacement, and added a set
    of LaseJet toner as "pain compensation".

    In other words, HP was always very open when it
    comes to information about its printers and
    protocols to developers. You just have to ask the
    right persons, instead of whining about it.

  • ... sort of.

    Back in 1994 a HP LaserJet device driver for Linux was developed and released, which ran the specific BiTronics protocol (aka. IEEE something) LaserJets use: http://meta -0.0.1.lsm []

    According to the author, there was not much interest in the driver, including Linus not showing interest in including it in the kernel. So development stopped after the initial release. In other words, Linux could have had special HP support for years now, if there would have been a demand for it.

    Let's hope that this new effort by VA and HP will result in some strong HP support and improvements in the printing system.

  • I have a HP Deskjest 712C which works great. But apparently when I bought it I overlooked the phrase "Windows only" on the box. I've never been able to get it to work with linux and I am forced to keep windows on another partition so I can print.

    My only problem with linux really, is this issue.
  • So what sort of binary are these "Binary" filters going to be written in then? It wouldn't be i386 binary would it by any chance??? How is that going to run on my Alpha then?

    It is very easy to campaign against the Microsoft monopoly whilst supporting the i386 one!!
  • by Effugas ( 2378 ) on Wednesday January 26, 2000 @02:10AM (#1336531) Homepage
    There's no problems or issues with remotely using the advanced HP printer functionality embedded within their windows drivers. Their printer drivers can occasionally be...ahhh, ornery to install(to say the least), but they *do* distribute packages pretty much ready to be remotely installed via Samba.

    I'm not just speaking from my own personal usage--my "mere" Pentium 120 w/ 64MB of EDO SIMMs managed to serve the print needs of between 280 and 500 students distributed among about a dozen dorms across campus using Samba and the Caldera Openlinux Novell code.

    The server never even broke a sweat. I pretty much only had one chronic outage, and that was because of a rather nasty bug in Windows' TCP/IP stack. But heh, at least I got to discover it. :-)

    The press release is pretty short on facts, but I'd *guess* the following functionality is being worked on:

    A) Bidirectional Status Updates. As far as I know, Samba can't reflect back complex or custom status messages from the printer to the user.

    B) Document Titles. Samba doesn't know how to extract from Windows the title name of a print job--a common solution is to force Postscript prints and then extract the job title from the PS header, but that's not particularly the "correct" solution, particularly for a company like HP which has quite an investment in this little language called PCL...

    C) Database hooks. My print system had a rather extensive logging system, but it just output to plaintext. Samba's internal logs are all debug oriented. I wouldn't be surprised to see an "enterprise-class project" involving Samba to dump its logs straight into a SQL database.

    D) Enterprise-scale configuration managers. SWAT's good for what it is, but HP's golden cow is its laser printers and what they can do for businesses. If they're going into this, corps are saying that they want to follow Cisco's(ObPlug) lead and base their printing architectures around Linux and Samba. If HP wants to remain able to sell a competitive print management solution in that kind of market, contributing to Samba is an obvious move.

    E) Linux drivers. There are lots of features which don't exist on the Linux side which are standard on Windows. HP can simplify the installation and improve the feature-completeness of their printers for Linux clients, as well as allow IT staffs to implement high end filtering systems(i.e. force all prints to possess a confidentiality watermark) for their printers.

    Congrats to VA Linux, btw! We owe someone there some serious thanks. HP on board should be interesting.

    Yours Truly,

    Dan Kaminsky
    DoxPara Research
  • I don't know if this really is your problem, but I had a similar one. I couldn't get my HP DeskJet 660C to work with RH6.1, printtool wouldn't recognize that there was a printer attached to the parport, and therefore didn't write anything to /etc/printcap, no matter how hard I tried.

    This is appearantly a bug in modutils in Redhat 6.1, you can read about it here []. It did solve my problem, and printing now works smoothlessly.

  • Uhmm ... IIRC the HP Network cards have some major
    flaws ... (at least the older ones we have here)

    They can only have ONE connection at a time, that
    sounds not that bad, but if you print and have the
    print-queue open, samba would call lpq, which will
    try to open a second connection. As a result the
    lpq command will timeout afer some time, and during that time, the Windows client will FREEZE !
    That is a pretty nasty behaviour, one way to get
    around it, is to pipe the print-data to port 9100
    on the network cards, and don't use the internal
    lpd for it.

    I don't know if this is a flaw of the lpd of that card, or a generic problem with those cards.

  • Agreed. We have far too much of an abundance of next generation print technologies and not enough cooperation between the projects...

    * LPR
    * CUPS
    * Ghostscript
    * Minolta / SuSEs new printing system
    * HP / VAs new printing system
    * StarOffice's printing system
    * The GNOME print architecute
    * The KDE print architecture
    * XFS and Xfree86 4.0 [both have font servers which could benefit fron print integration]

    Could those involved in any of these technologies please comment about how they relate to other projects? A unified successor to LPR would be the best possible outcome for all. Technology should be command line or CLI interfaced, integrated with both desktop environments, cope equally well with the damnds of network and local printing, provide a system for open-sourced or binary only drivers, and have intelligent downloading and execution of drivers [unlike the NT model]. It also must be simple to develop for, compatible with a variety of existing standards [postscript, unix, lpr, etc]...

    Do you care? Then write to the developers wiht your concerns, and try and create dialogue between the projects. This is the Linux community and you have a direct say in the future of its architecture.
  • I agree, I've been running FreeBSD and samba for over a year now, except for the feature of knowing when the printer ink is empty and stuff like that. It's been perfect. So bidirectional contact would be nice, or a piece of printer monitoring software I can hook to a e-mail, telling me when it's dry.
  • It would be nice if they would make some kind of standard printer driver. Right now there are multible projects like this one!

    One example is SUSE and Minolta, which have teamed up to create drivers for Minolta's printers etc. (

    I hope they will cooporate (HP, Minolta, Canon, etc.), instead of developing each their standard.
    Nobody will benefit from that.

    Hopefully, because it is Open Source and available at SourceForge, the companies will see the advantage in joining this project and not create their own.

  • So what sort of binary are these "Binary" filters going to be written in then? It wouldn't be i386 binary would it by any chance??? How is that going to run on my Alpha then?

    It is very easy to campaign against the Microsoft monopoly whilst supporting the i386 one!!

    While I agree that it would be better to device a truely "open" approach, I also believe that it's not a very realistic goal. Face it: there are companies who go great lengths keeping secrets, and who believe that their own printer language is the most significant of all secrets. Wouldn't it be nice to be able to convince them all to give up that idea? Indeed - however I also take the more pragmatic approach, and merely saying that IF we want more support for "our" operating system from hardware manufacturers (such as printer manufacturers), then we have to (at least initially) play by their rules.

    Giving companies an opportunity to make binary-only drivers for their choise of Linux-platform and release alongside the binary-only versions of drivers for Windows and MacOS clearly cannot be a step in the wrong direction?

    Once they're on the band-wagon, then may realize that the platform-requests (valid - such as yours - saying "Why is Alpha / PPC / Sparc / x86 / StrongArm / mk68 not supported?") and requests for features, updates and such COMBINED with the willingness from the community to put in an active effort in developing and maintaining such themself is a motivation to give away also the source code.

    I believe, that most HW-manufacturers make money from MAKING HARDWARE not from writing drivers. I also believe, that most HW-manufacturers want access to as big a share of the market as possible. And I guess that the reason many haven't been supporting Linux and other unices is, that the market share is rather small and the efforts required to support that market is rather large (qua the lack of standardized, driver-based architectures).

    Besides, I am not one of those, who believe that all software should be GPL'ed. I believe that it is the developers right to choose whatever license he or she wants - and the users right to decide to use it or not.
  • by Anonymous Coward
    This announcement may or may not improve the image Linux has with the system administration community. But as someone with an in-depth technical marketing background (who is also a competent NT administrator), I have to wonder what are the priorities of Hewlett Packard. In marketing terms this is what we would call an SLP-product (solution looking for a problem).

    I have been actively monitoring the open source revolution since its very formation, over 4 years ago, and I am constantly stunned at the behind-the-paradigm, chasing-the-tail-lights behaviour of these traditional Unix vendors jumping on the Linux bandwagon.

    Are these big corporations (Sun, IBM, Hewlett Packard, Microsoft, etc) aware that Linux is not the product of of a carefully thought-out technology marketing strategy ? Do they know for instance that Linux has no mission statement, and until two years ago was developed by one guy (Linux Torvaldees) from his bedroom in Sweden on a low-powered PC?

    I suspect that if their marketing departments were aware of the flawed marketing message coming from the Linux developers, they would be much less keen to jump aboard this particular bandwagon!

    And now for my personal gripe. As the most techno-savvy person at our marketing agency, I am often called upon by the other creative associates to assist with PC problems when a more out-of-the-box approach is required. For this reason I am a bit worried that if our agency goes down the Linux route for its print servers, all my NT expertise gained over the years (including very advanced tasks that require administrator priveleges such as rebooting the Exchange server, and applying a Service Pack to the cdrom drive) will count for nothing. We will have to pay an expensive MCSE to come and fix our problems

    Can anyone see the problem with this ? Why should we pay $$$s to some third party ? Until Linux was installed we could fix the problem ourselves. I haven't met a computer problem yet that could not be fixed by either hitting ctrl-alt-del, or applying the very latest service packs from Microsoft. (and I have been in this game for a long time). This is why Linux quite simply cannot compete.

    To conclude, the large Unix vendors simply must come up with a retrospective marketing story for Linux. The developer types seem to think that a platform's success depends purely on technology. When will they grow up and realise that to compete in the real world, a coherent marketing strategy is not a luxury - it is a necessity !!! Without it, Linux and its derivatives (FreeBSD, Mandrake and OpenBSD) are doomed to failure.

    As usual I offer my "open source" marketing advice without charge, although sometimes I wonder why I bother when I see announcements like this from the likes of HP. I'm beginning to think that they "just don't get it".

  • There is decent linux support for HP's NETWORK printers.

    The LJ4000 supports PS and PCL so I have no idea why you must resort to ascii. If you have a JetDirect card, you should be able to configure it under linux with WebJetAdmin. I don't know why someone would want to put a high end laser printer on a paralel port anyway. At any rate, your LJ4000 problems should be fixable.

    The 697C is only supported for the desk top, it's lame that you can't get good *NIX support for the lower end printers, but the network printer software only supports network printers.
  • I recently went through compiling ghostscript with the hpdj driver for my Deskjet 660CSe and found the following in the gs-hpdj man page:

    I believe I've already pushed this driver a bit beyond what is sensible. My reasons are:
    + First, I have already included functionality for which I do not have sufficiently reliable documentation. After several unsuccessful attempts to coax more out of HP I have given up trying to improve on this situation, and designing hardware drivers by experimentation is in my opinion simply irresponsible. One of the three main design goals of hpdj was reliability....
    Lately, it appears that HP has not been as open as they used to be.
  • Hmm. I`ve managed to get my 610C working (using the 500C driver) at least to the extent that it can print some out. However, it`ll only print with the colour cartridge, meaning that simple text jobs take far too long (and it`s a waste of ink too). If HP can bring out better drivers for the Deskjet series, I`d be well happy.
  • I assume VA & HP are adding JetDirect "port" support into Linux, something that already exists (thank dog) in AIX.

    Under AIX, dealing with the Byzantine print system is truly easier when using JetDirect "ports".

    So, we can look forward to multiple logical queues to a single physical HP printer. Each queue could carry with it a series of paper, orientation and other defaults. Each queue could have bi-directional messages, like toner low, and it would propagate to client PCs (say Windows).

    All neat and tidy, but simple LPR/LPD, using PostScript has worked rather well for all our HP printers. Trouble always stems from older Windows software that has some built-in assumption of the end-device, forcing us to try a PCL driver to compensate.

    I look forward to dissecting the new printing mechanism. One less reason to have an NT print server.

  • That architecture (to develop printer drivers for Linux) is already available with CUPS ( [], GPL'd)

    Debian is including CUPS and LPR in their next distribution, and we're hoping more vendors will do the same.

    As for libraries, there are several people working on that, most notably Corel, the KDE folks, the GNOME folks, and the VA Linux folks. We've contributed code to the Corel (LGPL'd) and VA Linux efforts already.
  • HP has become more and more closed over the years with the DeskJet printers. Even registered developers (that have to sign a non-disclosure agreement) can't get a lot of the information.

    ALL of the newer DeskJet printers (970C, 2000C, 2500C) provide both the PPA and PCL interfaces; the PCL interface allows you to do 600 DPI in color, but not the multi-level stuff supported by the printer, and AFAIK not the duplexing stuff either (still waiting for a response on that one...)

    Of the vendors out there, ALPS has to be the most open, at least to developers. They gave us everything so we could write a driver for Linux that is as good as the Windows driver. EPSON gives us all the printer control info, but nothing on dithering algorithms or strategies to improve the output.

    HP is right above Canon and Lexmark...

  • Try using the DeskJet 660C (or 600 series, I forget) drivers with the 812C; the 812C does 600x300 DPI instead of the 300 DPI CREt in the older 800 series printers.
  • For the so-called "level 1" programming documents from EPSON, see:

  • by printman ( 54032 ) on Wednesday January 26, 2000 @04:23AM (#1336552) Homepage

    * LPR
    * CUPS
    * Ghostscript
    * Minolta / SuSEs new printing system
    * HP / VAs new printing system
    * StarOffice's printing system
    * The GNOME print architecute
    * The KDE print architecture
    * XFS and Xfree86 4.0 [both have font servers which could benefit fron print integration]

    I think you're confusing printing systems and printing interfaces.

    CUPS and LPR are the only printing systems listed above. To the best of my knowledge the HP and Minolta efforts are just filters and helper apps layered on top of LPR.

    GhostScript is just a program. It can be used to filter output for a printer (PostScript to PCL, for example), but it isn't a printing system.

    StarOffice (and Word Perfect, and name your application) include printer drivers but not a printing system.

    GNOME and KDE (and Corel, don't forget them) are providing an application interface for printing; they still need a printing system (currently LP/LPR/LPRng/CUPS)

    XFS and XFree86 can provide bitmapped fonts, but quite frankly they are not designed for the high-resolution output of a printer. Do you want your graphics card generating 600 DPI fonts and freezing your display while doing it?
    (GhostScript already supports Type1 and TrueType fonts, and you can share them with X to get the same widths, etc.)

  • No this isn't a server end thing. It is fairly neutral in that it is not a server or a client thing. It is a "fill in the gaps" sort of thing.

    Color managment and getting colors right is a really big deal. It will take a lot of coordinated work between the scanner people, the printer people, and the X server people, as well as work on the end user apps like gimp.
  • Support for printer XYZ through application RST just isn't the biggest problem for Linux applications. The problem is the fact that there is NO unified printing subsystem available to an application developer under Linux or any other UNIX/X11 system for that matter. At least not one that's actually in widespread use.

    CUPS absolutely does not count because it still relies on an having an application spit out postscript data. Generating postscript files and rendering an image on a GUI are two totally different problems requiring two totally seperate routines in an application to address them, requiring TWICE the work on an application developer. Ugh, what a total pain in the ass.

    This does not make for a good, flexible application development environment. And as a result, Linux applications are going to suffer. They will either provide no printing support at all or each application will take a different approach to the printing problem, leaving the end user with a collection of applications that all print differently. The latter is the situation I think we find ourselves in right now under Linux. Try printing with GIMP, XV, Netscape, WordPerfect, StarOffice, etc., etc... Each one does things differently with varying degrees of success.

    QT has an approach that gets a *little* closer, but still has a long way to go as it ultimately renders things in postscript anyway. This not only requires a GOOD postscript RIP, but also a good printer driver for that RIP. Introducing a generic RIP application into the middle of things just totally destroys any hope of getting optimized printer output for your new fangled, high powered, 6-color inkjet.

    Applications need to be able to pass rendering operations directly to the printer driver (which needs to be written *by* the manufacturer to ensure the best possible output quality). Currently this type of architecture is totally non-existant under Linux/X11 and we all seem to keep dancing around the issue with the introduction of things like CUPS and the QT printing subsystem. I gaurantee you, Linux will NOT compete with Windows on the desktop level until a *real* solution to the printing problem is crafted.

    This thing HP and VA are doing is not a *real* solution to the *real* problem.
  • Is it just me, or is anybody else scared that the folks responsible for the HP/UX bastardization of SysV print configuration are "improving" Linux printing?
  • I am working on the project. And here is what I can tell you so far. Most of the technologies that you mentioned are pieces to the overall printing puzzle. Quite a bit of what we at VA are doing for HP is to kind of fill in the gaps between the technologies.

    For example gnome-print generates PS and corel's stuff is designed to provide a C api to the print system. In other words it sends jobs to the printer. These technologies work together and are needed by each other.

    For example, one of the first things that I am working on is to make setting up a parallel printer easier by using the IEEE1284 information provided by the parallel port plug and play kernel module and using that to automatically setup the printer properly.

    Also let me assure you that I am a lazy programmer. I don't want to bother writing any code that I don't have to. Corel has some stuff, CUPS has some stuff, a few other people have some stuff. I am going to try to sew it all together not reinvent the wheel. Hopefully as the developers work together we will have more and more shared code.
  • by Anonymous Coward
    How can I use Economode with my 1100 then?
    If you read the Printing HOWTO, you'll see that I recommend using PDQ [], which will allow you to configure all those settings on a per-job basis; Economode would merely be a PJL command that you tack on the front of the job in PDQ's filter_exec script. The HOWTO has an example [] (scroll down to "Output Filtering") for the PJL variable DUPLEX; just use the variable ECONOMODE (value: ON or OFF) instead.

    If you really wish to be a good netizen, whip up a nice PDQ description with all the useful settings for your printer, and submit it to me for inclusion in the database [].

    - Grant Taylor
    Linux Printing HOWTO []

  • Don't be worried about that. HP is a logo and the HP/UX people are so far from the LaserJet people that it is almost like they work for different companies.
  • That sounds to me like you have old firmware in your JetDirect cards. I would recommend that you either use WebJetAdmin or my program npadmin to update your firmware.

    The newer cards accept the connection but don't accept any data until they are ready to print it.
  • I get decent imaging from the 970Cse by using the hpdj driver in ghostscript (it is compiled into the current aladdin-ghostscript as distributed in Debian, probably also in other distributions as well). Reading the documentation for this driver is very helpful.

    Here is the entry in my /etc/filter.magic (for magicfilter smart filtering):

    # PostScript
    0 %! filter /usr/bin/gs -q -dSAFER -dNOPAUSE -sDEVICE=hpdj -r600x600 -sColorMode=CMYK -sModel=unspec -sPrintQuality=1 -sOutputFile=- /etc/gs-enlighten-for-dj970cse - -c quit
    0 \004%! filter /usr/bin/gs -q -dSAFER -dNOPAUSE -sDEVICE=hpdj -r600x600 -sColorMode=CMYK -sModel=unspec -sPrintQuality=1 -sOutputFile=- /etc/gs-enlighten-for-dj970cse - -c quit

    I put the following in /etc/gs-enlighted-for-dj9700cse to make color pictures a little less dark:

    {0.45 exp} settransfer

    I don't know how to set-up duplex printing, but I find that manually doing duplex is fine using dvips when printing my papers or psselect when printing generic postscript files.

    dvips -D600 -A -r myfile.dvi

    prints the odd pages in reverse order. Then put output back in the input tray, and

    dvips -D600 -B myfile.dvi

    to print even pages on the back. For generic postscript,

    psselect -o -r | lpr

    re-insert paper

    psselect -e | lpr

    to print to the back of the pages.

  • What I want to know is...

    Why can't I buy a printer that understands PostScript for under $750? (Actually, that's Lexmark's cheap Optra 45 -- most are thousands of dollars!)

    Sure, Abode's licensing fees may be astronomical, but I've heard some "PostScript-compatible" printers actually use GhostScript. And I'm sure the necessary hardware doesn't cost THAT much these days. I suppose the sticking point could be the RAM -- but 16 MB is like $40 if you buy the old EDO DRAM SIMMS! I'm sure printers could get buy with slower (and therefore cheaper) RAM than that.

    If we could actually buy a cheap PostScript printer, we wouldn't be having this discussion.
  • Not only are LaserJets by far one of the most popular printer families used in business, most of the other laser class printers out there emulate HP printers. So this stuff is really a lot more applicable than it might seem. Software designed for LaserJets should work without modification on a lot of other brands of printers, and as long as it is open sourced, any minor differences and/or additional features in other brands of printers should be able to be tweaked by others in the community.

    I would think that this is a win-win for HP, as it should help them sell printers. Printers are probably HP's most successful long-term products. It also should help HP/UX, as you know, Samba isn't Linux specific.

  • At last! A coherent, real world perspective from a marketing professional. More marketing and less hype is the key if we wish to see our public domain operating systems flourish. 8-)
  • And this raises a point for me.

    The HP's are so well supported that everything these days speaks PCL. Unfortunately, HylaFax doesn't. If anyone knows of a free PCL->PS interpreter, they're reading this. Pointers?

    -- jra
  • >>You responded seriously to a Score:3 Funny.

    And you're funny too.

  • Well, the press release doesn't really say much. But I can state, as someone who just wrapped up a 90-system Linux/Samba/LPRng/multi-Laserjet installation, that whatever they're doing probably is just for show. To their credit, HP's midrange and high-end printers, ie Laserjets, have always been quite compliant with their own and Adobe's standards. I had no trouble getting this setup working without HP's help.

    The one thing that's bothered me is HP's refusal to acknowledge this fact and state on their web site "our printers work with (or w/o, as appropriate to the printer) Ghostscript on Unix." It's all microsoft this, microsoft that. I'm mildly confused that they go to the trouble to make sure they're compliant and compatible, then don't bother to advertise the fact. So in that sense, maybe this is a step in the right direction. But we really don't need more printing systems, and we really don't need major changes to the existing ones. It pretty much just works great already! Now, inkjet support, that's another matter...

  • I dismissed the "Windows only" small text on the side of the box, and bought the HP 710 Color deskjet.
    It uses PPA also, and Ghostscript can't handle it. There's a working black and white driver at this address [] (for HP 7x0, 820 and 1000 series) and I've just found that the same people are currently working on a color driver (see sourceforge []. Since HP won't release specs, they are forced to hack on the windows drivers to find the printer protocol.
    It's been a while since I'm using the b/w driver, and I'm too cheap to spend color ink testing alpha drivers... But I'll give this new drivers a spin.
    Anyway, I think that every manufacturer that wants to approach the open source world should first release specs for all their products (HP: does that ring a bell?)

    go Mnemonic []!!!
  • I have two huge HP-UX boxen and twenty-some jetdirect-equipped HP printers. The measure of control I have over these printers, and the ability to configure them as I please, is LAUGHABLE. For example, printer names have to be all upper-case and can't contain punctuation. I have all the latest HP printing software, incidentally, and it's best described as difficult, counter-intuitive and tedious to use. I used to think /etc/printcap was evil, now I long for its (relatively) fast & easy configuration.
    Using samba, LPD, and the Windows drivers gives me much better control than using HP's flagship products. And, the PC users can comprehend the printer names! I use samba's automagic printer driver download, but I have to do a lot of hand-editing because the files that HP is shipping to define the driver requirements of the entire HP5 lineup are corrupt (that's the .INF files). I always wondered why I couldn't properly use an HP5 unless I had both HP4 and HP5 drivers installed; now I know.
    And of course, there was at least one verion of JetAdmin for Win95/98 that raped your entire printing subsystem and could not be uninstalled... I had to reformat several hard drives in the IS department because people loaded that tarbaby.
    So, in short, having HP work on linux printing is like having Dr. Mengele check out your skin condition. I predict that HP will produce lots of barely useable crap that will get incorporated into every major distribution due to consumer demand.
    Here at my shop, I will never buy another HP printer. I haven't seen an HP printer since the ThinkJet that wasn't just a lamer version of a QMS printer anyway.
  • That can also be used against you :)

    When my machine doesn't crash, allows me to use Perl to do XML/XSL transforms with something other than beta software, and surf the web with the best browser available, I can also say
    "This would not have happened with Linux"

    This is not a troll, but I do wish some folks would realize that not all Win32 users are clueless idiots, begging Bill for a bone. If I want a good webserver, I'll use Apache on FreeBSD. If I want a good desktop, Win2k and Office2K. I have no desire to write my own Perl scripts to translate StarOffice docs to XML.
  • It was Tim Norman who wrote pbm2ppa, and I'm one of the lead developers (for the last few months) of the color replacement, pnm2ppa.

    It's ironic that they chose to use SourceForge, where we are also located. See this [] for our project.

    It would be nice if HP released the specs for their PPA printers, but we have received their final word on it, so we'll just have to reverse engineer the protocol more fully and hope to $DEITY that we don't kill anyone's printer.

    But I see the HP thing in a good light. Printing under Unix sucks. End of story. There needs to be proper bi-directional communication in a standard way on all Unixes, proper paper handling, easy to install drivers, easy to use multi-paper size print jobs and the ability to control the resolution on the fly. Until these things are fixed^Wwritten, printing on Unix will always be a third class citizen.

  • I can't beleive you people didn't see straight through this post.

    "I'm beginning to think that they "just don't get it"."
  • Another problem is that you can't even align the printer cartridges for the Deskjet 850C (and other 2 cartridge) printers without physically connecting the printer to a windows box. I have tried to go through the forum on HP's website to find a contact to get the information. Someone from HP eventually told me to contact the local office in Australia. That's just a waste of time. So I've borrowed a dot matrix printer to try to get a dump of the sequences to send to the printer - when I get some spare time.... Probably easier to get another brand of printer...
  • I realize these programs all cover diffferent aspects of the printing system that is Linux, and rely onn eachother in different ways. However, are Staroffice's drivers compatible with Corels?

    XFree86 and XFS can provide TrueType fonts - that's why current distributions use the external font server in the first place. XFree86 4.0 has Freetype, Truetype,a nd Type 1 fonts capabiltities. I don't think anyone seriously is interested in bitmap fonts anymore. But again, Staroffice has it's own font system.

    Likewise, which combination of system and interface is yours today? How well do they fit together? Is KDEs printing interface able to handle CUPS? Is it compatible with GNOME and Corels printing interfaces?

    Alll these questions and more will neeed to be answered. I think the poster below gave the response I'd like to ehar - that it's a matter of stitching these technologies together to form a tight and comprehensive framework. I really do hope the number of parties involved working on new and unique systems, interfaces, font management solution,s etc, can get together and come to the party.

  • I am going to pretend, for a moment, that you are a serious poster, and that your series of remarks were meant as sincere criticisms of Linux.

    That is a bit of a stretch, seeing as how your remarks about a "Linux registry setting," your juxtaposition of Mandrake and two of the BSDs, and your use of the words "rock solid," "scalable," and "NT Server" in the same sentence mark you as either a troll someone who has never used Linux.

    Or, I suppose, a marketing guy. In which case your confusion on these matters makes sense :).

    It seems to me that your own post proves that the Linux Marketing Juggernaut (LMG from now on) is kicking ass and taking names. After all, marketing is all about convincing people that a certain product is right for them.

    If the LMG has convinced the pointy-haired bosses at your firm that they need to chuck their tried and true NT Servers for Linux, then you can bet your sweet life that there is some serious marketing going on. After all, Microsoft spends billions convincing these same pointy-haired types that Windows NT is the coolest thing since sliced bread, and yet the LMG (with an advertising budget several orders of magnitude less than MS) is winning the customers.

    As for the Linux Windowing system, who cares if people don't know what it's called? It's not for sale separately anyhow. Linux is the name that your customers want to hear. The technical stuff is best left to the gearheads.

    And before you blame Linux for poor name recognition perhaps you should take a look at the predicament that "Windows NT" is in. After spending ungodly amounts of money on Windows NT branding, Microsoft is chucking the NT monniker to the winds. What does your marketing savvy have to say about that? It sounds to me like Microsoft wants to remake NT's image, I wonder why?
  • This is not for show! We are really trying to bridge some gaps in the printing technology that currently exists. We want to allow people to do things like have their output stapled or come from different paper trays. We want to make it easy to access the duplexer and stuff like that.

    We also want to do a bunch of user side stuff to make setting up parallel connected printer trivial.
  • Maybe I'm being ignorant here, but why couldn't some sort of module be written for the WINE project that allows Windows drivers to be used directly?

    Again, I may be in the dark here, but would the ideal situation be to hack out the printing API for windows and then just go and use the drivers that come with your printer out of the box?

    Sure, that means that the drivers would remain closed source, but since they're only useful with the hardware that one buys and come with that hardware anyway, it seems that doing this once would save people and manufacturers the time and money it takes to port their drivers to other OS's.

  • Actually, I just bought a Postscript printer for $350 once shipping & handling was factored in. It's the Lexmark Optra E310, and it handles Postscript Level 2 natively. List price on Lexmark's website is $400, although a Price Watch [] search ought to turn up some cheaper prices. Do a DejaNews search [] for "Lexmark Optra E310" and you can read about other people's experiences with this printer. I bought mine from Electrified [], where they list refurbished Optra E310's for $300 ($299, technically). Note that that does not include a parallel cable (though it does include a toner cartridge, otherwise I'd be a little steamed), which wound up costing me an extra $15. Add hefty shipping & handling fees (due, I suppose, to the weight of the package, although I'm sure I got overcharged there too), it still came out to about $350, which is cheaper than anywhere else I found.
    The real meaning of the GNU GPL:
  • the way it's going to work is that the "open source"
    project is samba. i started the "NT Domains for Unix"
    project as a samba development to get NT workstation
    logins. it turns out that you need NT printing, as well.
    so, HP is paying to have NT-style spoolss code in samba.
    looking through some of the other postings......
    yes, because there do not exist any NT-style drivers for
    linux, we are either going to have to get HP to write
    these, OR, we support NT printing "RAW" mode only.
    be interesting to see if HP bites on a GPL license
    for NT-style HP drivers for linux!
  • Ah, I see - you're targeting things like OfficeJet connectivity, the add-ons to the 1100 series, the 8000 series, etc. In that case, good luck. Sounds useful.
  • Let me guess: Your name is Stef, you suck at Quake, and you work at Columbia ISP, right? Is this a real post or are you pretending to be that clueless?

To write good code is a worthy challenge, and a source of civilized delight. -- stolen and paraphrased from William Safire