Slashdot Mirror


VA and HP Join Forces for Linux and Samba

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.

8 of 96 comments (clear)

  1. WebJetAdmin for RedHat by bridgette · · Score: 3

    HP's WebJetAdmin is network printer config/management software that supports RedHat.

    --
    - bridgette
  2. To print or not to print by Taco+Cowboy · · Score: 3




    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.


    --
    Muchas Gracias, Señor Edward Snowden !
  3. Re:Laserjet by voop · · Score: 3


    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?

    --
    -- "Life is a bitch - and she hates me..."
  4. Nice, HP, but why don't you... by Silicon_Knight · · Score: 3

    ... 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

  5. Competing printer solutions by XNormal · · Score: 3

    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.



    ----

    --
    Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
    1. Re:Competing printer solutions by printman · · Score: 3

      * 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.)

      --
      I print, therefore I am.
  6. Re:Finally by Flower · · Score: 3
    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.

    --
    I don't want knowledge. I want certainty. - Law, David Bowie
  7. Remote Printing to HP printers is flawless by Effugas · · Score: 3

    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
    http://www.doxpara.com