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.
hmm... (Score:2)
Heck, ive even begun to replace HP JetDirect print servers with redhat or slackware boxen..do we really need another print system ? Besides, even the CUPS guys [cups.org] are trying to build one...
Laserjet (Score:1)
<ZEALOT>
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.
</ZEALOT>
---
pb Reply or e-mail; don't vaguely moderate [152.7.41.11].
Finally (Score:2)
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.
Opens Source Drivers (Score:2)
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.
WebJetAdmin for RedHat (Score:3)
Re:Finally (Score:1)
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?
The loop is complete (Score:1)
Now a decade later we have a major printer vendor with APIs and drivers out into the open on sourceforge
To print or not to print (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.
I hope they also improve the Deskjet drivers... (Score:1)
Re:Laserjet (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?
Re:Finally (Score:1)
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.
End-user printing (Score:2)
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...
What's wrong with today's system? (Score:1)
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. :)
Re:I hope they also improve the Deskjet drivers... (Score:1)
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).
Nice, HP, but why don't you... (Score:3)
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
Re:End-user printing (Score:1)
Re:Finally (Score:1)
Good to see....But (Score:1)
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.
I... C... O... ! (Score:2)
These people are soooooooo amusing! They'll trademark anything!. In fact, I guess I can start dropping TM at random places...
Ciao(TM)
Competing printer solutions (Score:3)
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.
----
Re:Finally (Score:3)
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:
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.
Re:I... C... O... ! (Score:1)
Re:Nice, HP, but why don't you... (Score:1)
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.
Re:Nice, HP, but why don't you... (Score:1)
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.
There is extended LaserJet support in Linux... (Score:1)
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 lab.unc.edu/pub/Linux/kernel/patches/misc/bt-ALPHA -0.0.1.lsm [unc.edu]
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 feel bad about my printer. (Score:1)
My only problem with linux really, is this issue.
NO to binary filters! (Score:1)
It is very easy to campaign against the Microsoft monopoly whilst supporting the i386 one!!
Remote Printing to HP printers is flawless (Score:3)
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
Re:Finally (Score:2)
This is appearantly a bug in modutils in Redhat 6.1, you can read about it here [redhat.com]. It did solve my problem, and printing now works smoothlessly.
Re:Remote Printing to HP printers is flawless (Score:2)
flaws
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.
Regards,
Michael
Re:Competing printer solutions (Score:2)
* 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.
Re:Remote Printing to HP printers is flawless (Score:1)
Multible standards? (Score:1)
One example is SUSE and Minolta, which have teamed up to create drivers for Minolta's printers etc. (http://www.suse.com/PressReleases/minoltapr.html
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.
Re:NO to binary filters! (Score:2)
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.
HP to be crushed by the Linux bandwagon ? (Score:1)
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".
Re:networked printer - oh yeah? (Score:2)
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.
Re:Nice, HP, but why don't you... (Score:1)
----------------------------------
FUTURE DIRECTIONS
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.
Re:Finally (Score:2)
JetDirect (Score:1)
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.
Re:Laserjet (Score:2)
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.
Re:Finally (Score:2)
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...
Re:I hope they also improve the Deskjet drivers... (Score:1)
Re:End-user printing (Score:2)
Re:Printer Documentation Problem (Score:1)
Re:Competing printer solutions (Score:3)
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.)
Re:End-user printing (Score:1)
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.
Drivers ain't the problem (Score:1)
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.
Re:Remote Printing to HP printers is flawless (Score:2)
Re:Competing printer solutions (Score:1)
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.
Re:hmm... (Score:1)
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 [picante.com].
- Grant Taylor
Linux Printing HOWTO [picante.com]
Re:Remote Printing to HP printers is flawless (Score:1)
Re:Remote Printing to HP printers is flawless (Score:1)
The newer cards accept the connection but don't accept any data until they are ready to print it.
Use of Deskjet 970Cse (Score:1)
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 /usr/bin/gs -q -dSAFER -dNOPAUSE -sDEVICE=hpdj -r600x600 -sColorMode=CMYK -sModel=unspec -sPrintQuality=1 -sOutputFile=- /etc/gs-enlighten-for-dj970cse - -c quit /usr/bin/gs -q -dSAFER -dNOPAUSE -sDEVICE=hpdj -r600x600 -sColorMode=CMYK -sModel=unspec -sPrintQuality=1 -sOutputFile=- /etc/gs-enlighten-for-dj970cse - -c quit
0 %! filter
0 \004%! filter
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 file.ps | lpr
re-insert paper
psselect -e file.ps | lpr
to print to the back of the pages.
What I REALLY want to know is... (Score:1)
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.
Re:Laserjet (Score:2)
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.
Re:HP to be crushed by the Linux bandwagon ? (Score:1)
Re:networked printer - oh yeah? (Score:1)
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?
Cheers,
-- jra
-----
/. humor (Score:1)
And you're funny too.
Content-free Press Release (Score:2)
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...
HP: we want info on the PPA!!! (Score:1)
It uses PPA also, and Ghostscript can't handle it. There's a working black and white driver at this address [httptech.com] (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 [sourceforge.net]. 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 [mnemonic.org]!!!
HP printing is overrated (Score:1)
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
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.
Re:To FUD or not to FUD (Score:1)
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.
Re:Nice, HP, but why don't you... (Score:1)
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 [sourceforge.net] 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.
The website is live (Score:1)
Re:HP to be crushed by the Linux bandwagon ? (Score:1)
"I'm beginning to think that they "just don't get it"."
Catridge Alignment (Score:1)
Re:Competing printer solutions (Score:1)
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.
Linus Marketing Rocks! (Score:1)
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?
Re:Content-free Press Release (Score:1)
We also want to do a bunch of user side stuff to make setting up parallel connected printer trivial.
Why not WINE? (Score:2)
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.
--Cycon
Postscript printer for $400 list (Score:2)
-----
The real meaning of the GNU GPL:
Re:hmm... (Score:1)
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! http://samba.org
Re:Content-free Press Release (Score:1)
Re:HP to be crushed by the Linux bandwagon ? (Score:1)