Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
News

IETF Working On New Printing Standards 68

Posted by Hemos from the killin'-the-trees dept.
A reader writes: "The IETF has announced that they are developing new printing standards for network printing." Printing -- exciting, eh? But one of those necessary evils in life.
This discussion has been archived. No new comments can be posted.

IETF Working On New Printing Standards More

IETF Working On New Printing Standards

Comments Filter:
  • The HP printer lines aren't even driver compatable. The HP 820 doesn't speak the same language as the other HP printers (hence its lack of support by other non WinTel langugages)..

    So their own printers can't talk the same language how the hell will they handle internet printing ?

  • I have been looking at CUPS which is free/open software, but the company charges for filters. Does anyone know of an effort to write free filters for CUPS? If free filters were available it would have a much better chance to become a Unix standard.
  • Internet printing protocol. The ability to print to a printer anywhere from the Internet (more or less).

    Nice, yes, but will spammers decide to also start trading around 'Printer Numbers' containing printers open and ready to print? So besides opening that mailbox and dealing with 10 pieces of spam, we also have to deal with a printer that's been spammed. Of course, it would get spammed when we have that all-important report to print out...
    (hmm. Interesting DoS idea - flood the printer so the company keeps wasting paper/toner/ink/etc and no printouts can ever be made).

    I guess we'll need to have the requisite header printouts like on faxes too...
  • Simple. Wrapping.

    Think about your dream world of printing... you'd have a postscript compatable printer, and you'd print everything as ghostscript, it would trod neatly through the spool, into a corresponding parrallel or usb port, out into the printer, and magicaly appear on paper, just the way you wanted.

    Of course, this rarely happens in real life. If you want to print postscript information from unix to any "affordable" (read: spent the money you were going to spend on a real printer on Diablo II) printer, you need to convert it. Oddly enough, we've got GhostScript to do just that. And while it has some difficulty with particular printers, these difficulties are isolated, and are generally the fault of the printer manufacturer, for not releasing proper (read: complete) specs.

    Now, with the advent of another globally accepted standard in printing, we've got a chance to turn things around. If the standard gets itself a snazzy name (V.Print2000, LaserScript, etc) it'll be accepted by the mainstream printer manufacturers. This means that they will have to choose A) to provide software to convert IPP-compliant information to each of their proprietary formats, or B) to make all of their printers understand IPP-compliant information.

    And the moral of the story? IPP is this year's version of postscript. It may be new enough to sneak itself past the PHB's who run printing companies, or it may just end up being another fringe technology nobody ever talks about.
  • Hehe..hey butthead..those lame AC's replied. Cant you write anything entertaining except flames to other peoples trolls?
    Man..not original. Keep reading katz lamers, ignore my posts.
    Disclaimer: some AC's actually have posted funny responses. I guess not everyone has a "/" and a "." stuck up their ass.

  • Network Printing Standards (Score:3)

    by Greyfox ( 87712 ) on Monday July 10, 2000 @07:47PM (#944264) Homepage Journal
    Most of the stuff that at least the Printer Working Group [pwg.org] was working on last time I talked to them involved transport rather than rendering. They recognized that there was a problem with rendering languages too, but no one was doing anything about it.

    What would be really neat would be if they could implement a rendering model based either on XML + CSS, or DVI, both of which are open standards. An XML based rendering standard would have more hope of catching on, though a DVI based one would almost certainly yield (substantially) better output.

  • This is definitely a good thing. Having been a SysAdmin for a two small newspapers, a Win, and a Mac shop. It becomes quickly apparent that this is an area the Windows is way behind on.

    Postscript and AppleShare dominate all high end printers. You are very lucky (or unlucky) to find NetBeui on any postscript printer and if it is, it is usually flaky at best.

    Many a production night we would be stuck trying to print out a 100 MB job that would just disappear from the queue under NetBeui and the same goes from LPR support under Windows 95/98. I tried to get Mac protocol for Windows boxes but didn't want to pay the money.

  • Eck. Tired. Replace IPP with your favorite printed information format, as opposed to a network document delivery protocol.

  • 1996 (Score:3)

    by Robert S Gormley ( 24559 ) <robert@seabreeze.asn.au> on Monday July 10, 2000 @08:20PM (#944267) Homepage
    The standard has been around since 1996, fully documented and open. What this is is the IETF giving their stamp of approval (after concerns about security etc). Microsoft implemented the standard minus one feature, which allowed you to pass a URL to a printer, and have it download and print the document itself.
  • Describing how to send a document across a network (a printing protocol - IPP) in no way replaces or overlaps with a definition of the makeup of that page (a page definition language - PostScript).
  • Every OS is going to have to have it's own routines to convert data from Word, Star Office, Netscape, etc... into this IPP format.

    If I read you right, no. For the same reason I can happily spew stuff from Word to my Linux printserver via Samba, and also via "Print To File..." and then "lpr filename". The data being printed should be transparent or inconsequential to the protocol, so all that remains is a 'middleware' level between your print driver and printer.

  • IPP is nice in that status and printer capabilities can be returned from the printer. This means that conditions like paper out and ink levels can be reported back to the user.

    Except that it may well not be the end user who needs to know this. This is potentially more of the "treat the user as the admin" approach so common in Windows.
  • Of course MS jumped the gun. They always to when it comes to standards.
  • Speaking of CUPS and IPP, CUPS 1.1 [freshmeat.net] was announced today on Freshmeat. Among the new features is IPP 1.1 support.

    There's also a very informative comment attached to the freshmeat announcement.

  • >(A work around, since MS Internet Printing doesn't allow you to use ipp://...)

    instead of "ipp://" you should try "ipp:\\"

    that's how they did it in the article anyways.

    rofl at my own joke.

  • I think this discussion is about a system-independent equivalent of lpr. It will probably be far more confusing that lpr. This is a programming interface, just like lpr is supposed to be. One of the reasons people are fans of Linux is that the programming interface is much simpler and logical.

    Neither needs to be seen by the user. There is nothing on Linux that prevents the implementation of a "print" button that does popen("lpr") and then pipes the postscript there.

    The fact that lots of oss software writers don't bother doing this is a problem that needs to be addressed.

  • That'd most definetly fall under the unsolicited fax law, which is sufficently harsh and results in fines of $500 per fax and who knows what else..

    I don't think spammers would have the balls to do that, much as how unsolicited faxes are very rare.

  • You're being just as self centered, hoping that you can reap benefits of others work when you put no energy into the work. I dont really worry about what Linus and others think (but I will listen to what they have to say, and weigh it). Frankly, if Linux 'lost' in the mainstream desktop market, I'd still use linux, and so would a lot of other people. They'd keep making it better. The linux community is self sustaining, because it's based on hobby work, rather than commercial work. As long as one person is working on some part of linux, it's not dead.

    I'm happy if someone does some work that in the end benifits me, and I appreciate it. I will use printer drivers and stuff under linux if i happen to get a printer, but for me it's not a big priority. The original poster said very little useful, and was swearing a lot. Some shitty printer support, and even a 'loss' on the desktop market (which is hardly possible unless some other system with the same or stronger merits comes along) wont kill linux.
  • CUPS comes with 6 drivers/"filters" that cover roughly 60 - 70 % of all printers out there.

    CUPS supports _a_n_y_ present or future PostScript printer and lets you use all its built-in features like: duplexing, stapling and punching the output, changing the resolution, taking a red paper as a cover sheet from tray no.1 and the rest from tray no. 3 (white paper) etc. PostScript drivers are "free" in the sense: they're bundled with the hardware, they're provided by the manufacturer, their important information is written in a non-protected (technically and legally) ASCII file called "PostScript Printer Description" (PPD). In MS Windows and MacOS the Printer Driver Software parses the PPD, reads what features the printer supports (duplexing, stapling, punching...), generates a GUI (grafical user interface) and offers the user the choices (duplexing, stapling, punching,...) at his fingertips. Every vendor has his "own" set of commands to control the special features of "his" printer. As the PPD specification defined by Adobe is public, this is no harm in practical terms. And CUPS now is able to read, interprete these very same PPDs to generate a similar GUI for printing to a specific printer. The standard CUPS-GUI now is a fully functional web interface. That means you just grab the "free" PPD from a Mac or Windows box and copy it 1:1 onto your CUPS-enabled Linux/Unix box and you're done.

    What about support for non-PostScript printers?! CUPS uses the ingenious trick to describe _t_h_e_i_r_ capabilities likewise in a PPD. The art is to write those "fake" PPDs for a non-PostScript printer you don't hardly have any vendor-specific information about.

    That's why ESP PrintPro has advantages for some users or companies. It's commercial, it's closed, it costs money, it's a GUI for CUPS: but it comes with 2300 drivers /"PPDs" many of which are based on licensed NDA infos (Non Disclosure Agreements) by the device vendors and produce much better results than their standard ghostscript counterparts.

    As for "free" PPDs for standard ghostscript filters: they are under heavy development just now. Check out

    http://www.linuxprinting.org/

    It's the newly renamed home page of Grant Taylor, the author of the Linux Printing HOWTO. He has started to build a (so far incomplete) database about printers. In there goes infoormation about
    -- which model
    -- prints how well
    -- with what ghostscript driver
    -- supporting which ghostscript options?
    Everybody can help collect all the basic information.

    Now why is that so helpful in relation to "free" drivers/CUPS-PPDs?

    This bloke Grant has also written a script "cups-o-matic" which lets you generate a working CUPS-PPD (for non-PostScript printers!!!) which use standard GNU-ghostscript for the rasterization. Go there, choose the printer you want to use, see if there is enough info already in the database to generate a PPD for you online. If not: help to fill in the info. Grant hopes to be able to support _a_l_l_ ghostscript filters/drivers with their respective options through CUPS within 6 - 8 weeks...

    Now if KDE succeeded to create a "KUPS" frontend for CUPS in time...
  • Although I don't think your style to put your opinion helps a lot to get support, I agree on that:

    CUPS makes it very easy for hardware vendors and developers to get full Linux support for their boxes. Now there is a sort of standardised interface to printing, to a GUI - something that was deerly missing for Unix dektops for a long time

  • Re:What about lpr (Score:3)

    by elandal ( 9242 ) on Monday July 10, 2000 @05:23PM (#944279) Homepage
    Nobody's changing it. And there is more than one way to handle print spooling in Unix already.

    lpr isn't so great. I haven't reviewed IPP as I haven't needed it, but I assume it's designed to work in larger networks, too. Networks that suffer from failures, high latencies, low bandwidth, so on.

    Also, it's a single protocol approved by several OS companies. Meaning we don't need to set up samba on Unix or separate lpr on Windows - Unix will come with IPP as the standard print queue as will Windows. And Mac. And anything else You want. Perhaps even Bluetooth Palm with IPP - want the notes You wrote in the meeting onto paper? No need to first sync to computer and then print through samba which redirects to remote printer using lpr - the remote printer being two meters from where You stood when You wanted the notes on paper.
  • We're only dismissive because it's basically finished. Let's see: lpr and Postscript. and smb if you need to use Windoze. Everything else is window-dressing.
  • Adobe was too greedy.

    I had to beg to get a postscript printer at work. The vast majority of printers there are HP PCL LaserJets. Most of the postscript printers disappeared along with the Macs when Windows was declared to be the standard corporate platform.

  • Let me know when they start making 600 dpi, or even 300 dpi, CRTs.

    Maybe I'm too old, I find it much easier to read text printed on a good laser printer. CRTs are low rez and hard on my eyes.

  • printing is hard, lpr/smb not adequate (Score:3)

    by jetson123 ( 13128 ) on Monday July 10, 2000 @06:24PM (#944283)
    Printing is actually a surprisingly difficult problem: it involves something that amounts to executable content, authentication, accounting, downloading of drivers, envelopes/covers, transferring large amounts of data, collating, device configuration, content negotiation, security, DoS attacks, and other issues.

    The UNIX lpr protocol avoided dealing with most of those issues and assumes the whole world is PostScript or ASCII and having minimal security. And Windows now has a proprietary solution for installing drivers and other issues.

    I hope IPP won't go overboard. Many of the issues I mentioned, I think, are best left unaddressed, because if the printing protocol makes it too easy to create a proliferation of configurations and printer drivers, people will do just that. But something a bit more featureful based on HTTP I think would definitely be a step forward.

  • Authorisation. What's needed is more importantly the default set up of said servers/printers to require authenticated, authorised users, and not be world-writeable. Kinda like passwd'ing your root account. :)
  • I wonder if Marshall Rose's BXXP [slashdot.org] stuff mentioned on /. recent would have any bearing on this...

    I would think that it wouldn't be that hard to encorporate network printing into such a model. Oh well - one for the experts to work on... My experience with network printing is that to do it right is significantly harder than it first appears.

  • Lot's of OT's and trolls here. So I guess I'll add me dumb comments.

    The printer can be located anywhere on the Internet, from the supply room around the corner to a field office overseas to a commercial printing shop in town. I know that they then mention security, but there's going to be a lot of misconfigured printers. Portscan for insecure printers then bombs away.

    IPP is built on top of HTTP, which in turn runs over TCP/IP. Oh good. Does this mean ppl are going to also follow the HTTP standard?

    More than 50 products already support an experimental 1.0 Version of IPP. Wow, this must be a MS product numbering scheme. Experimental 1.0 Version? Alpha? Beta? Gamma? (This is a scientific joke; there was a paper with the authorship being, Ralph Alpher, Hans Bethe, George Gamow) Shouldn't this be a 0.9999999 version like it was for Gnome?

    Users will be able to print documents either within their enterprises or among enterprises instead of sending faxes. Yeah! Printing is available on the NC-1701's star ships.

    IPP provides a universal way for an end user to find out about a printer's capabilities, submit a print job to a printer, check on the status of a printer or print job and cancel a print job. IPP will also notify users when some other schmuck finally decides to put paper in the empty printer.

    The IETF's IPP working group is planning an interoperability demonstration in October that will include several IPP-compliant firewall packages. Wow, it must be tough to add to add a new port number to a firewall package.

    From a help desk perspective, companies are going to be able to converge three or four or five protocols, which makes the support issue much easier. The help desk problem is with stupid users, not with printer protocols. Where I work we use postscript (and PCL to a lesser degree) printers in a heterogeneous computing environment. The problem is stupid users.

    I repeat, Stupid Users. I repeat again, Stupid Users. A printer jam does not magically clear itself. A printer that is out of paper does not magically refill itself. A printer out of toner or ink has printing problems. You cannot print on a printer that is turned off (don't laugh, I had to tell this to someone while looking at the printer).

  • IPP is old news. The CUPS implementation was discussed long ago on Slashdot.

    The only new thing about this seems to be the introduction of the use of HTTP, seemingly predicated on the consideration that this gets you past the firewalls that hide the other ports.

    Which makes this about as secure as SOAP, which essentially implements DCOM atop HTTP.

    While it would be nice to have something a bit more sophisticated than LPD , that's hardly news when I've heard "Maddog" Hall comment on this more than once, and I don't hear him lecture every year.

  • Re:A change of pace (Score:1)

    by Anonymous Coward
    My GOD!

    I had to do a project in highschool french class about that song...

    Frightening to see it in a troll.

  • I actually use IPP (Score:3)

    by jefftp ( 35835 ) on Monday July 10, 2000 @09:10PM (#944290)
    I put together CUPS on a FreeBSD server. It's a dream.

    With a quick trip to Windows Update, download the Internet Printing update, and add printers with the location of http://corporation.com:631/printers/hp4000 (A work around, since MS Internet Printing doesn't allow you to use ipp://...) and bam, that machine can print to that printer from anywhere. Before anyone can print to the printer they need to A) be from an approved IP, and B) enter a user name and password. At the moment I'm not using SSL, but that's an option to add security.

    Currently I have no problem printing documents from anywhere in the state back to the home office.

    The CUPS suite can accept LPD print requests, with Samba can handle SMB print requests (although you'd only want to do that for NT 4 and Win3.1 clients). It has a web-based interface for both configuring/administering the printers as well as viewing the print queue. And print classes allow you to effortlessly set up a single queue for several printers.

    Of all the things Unix does right, printing was a administrative heap of dung until CUPS. If you're not using it, you're probably working too hard.

    If your office is moving to a dispersed office (everyone telecommuting) then CUPS and IPP is your best option for allowing workers, from home, to print back in the office.

    On a final note, I'm not really sure why anyone finds pushing IPP through a firewall difficult. It's all on TCP port 631. It's just HTTP. Maybe just that no current turn-key firewall software has a button/checkbox to "enable IPP"?
  • Except that it may well not be the end user who needs to know this. This is potentially more of the "treat the user as the admin" approach so common in Windows.

    Fine, so set it up to alert the admin instead of the end user. The fact of the matter is that there currently isn't any way to get this sort of status info using 'lpd'. I don't care who it gets reported to, but we need a protocol that will report it to someone.

  • Tarzan like global standards. He think they smart. Tarzan wonder: what were the other 25 companies? Do they "play well with others?"
  • Unix print spooling has worked fine until now - why change it?

    "Eww hard copy"
    - Mr The Plague, Hackers

  • CUPS (Score:1)

    by Anonymous Coward
    Isn't this CUPS (www.cups.org) program based on the IPP?
  • Yes... I know that printing may seem lame... but this is so very important to making the world go round'. We are living is a world that is becomming mor eand more dependant on networks... and we will always need to print. You just can't beat a hard copy. Paperless office? Bah.

    Peace Out.
  • Slashdot covered this back in March of 1999. You can find the original link here [slashdot.org].
  • did ms jump on the bandwagon too soon. if i remember, they added internet printing protocol to w2k. wonder if it will fit the standard, or will there a m4 standard as well?
  • Only in the Linux world? So you're saying that the only people who would like to see the office be clutter free are all Linux users? Not true. Traditional-minded business people like to have that "tangible matter in their hands" (I've heard this stated a lot by older co-workers). But in the future, business people are going to want to maximize efficiecinecy by eliminating walks to the printer, and endless paper shredding, and be more ecologically friendly by bypassing paper altogether (recycling is also cumbersome and time consuming - a drag on effiency).
  • lprng has a lot of cool features, and is quite an improvement over lpr. People considering other options should look into it

    /*
    *Not a Sermon, Just a Thought
    */

  • Re:printing kills trees (Score:1)

    by Anonymous Coward
    Pulp wood is an interesting thing. It needs to come from consistent stock to be much use. So it needs to come from commercial forests. You wouldn't want to use the paper from an 'old growth' forest. So using paper encourages the planting of trees for use in making paper. This is good, because it encourages the commercial growth of trees, which are important for air quality.

    Don't feel guilty about printing out things you want to keep hardcopy of. You're promoting photosynthesis and improved air quality.
  • I don't think this replaces PostScript. It seems to be about sending printer data across networks, and finding out about and monitoring printers.

    It doesn't seem to include a Page Description Language (which is what PostScript is).

  • it isn't the easiest thing to troll an AC. thanks for responding.
  • dude, relax. i dont have a printer. a lot of geeks dont. remember linux is primarily designed for geek users, by geek programmers who are also geek users. half of us dont need to print. frankly, I dont care too much if linux doesnt become a primary desktop end user OS in big business. I would rather geeky sys admins and the like use it to get the back end stuff done.

    cut down on the swearing, you'll sound smarter.
  • Having been a SysAdmin for a two small newspapers, a Win, and a Mac shop. [...] Postscript and AppleShare dominate all high end printers.

    Ermmm, no. PostScript dominates the high end, yes, but AppleShare doesn't have much of a showing any more. It's all TCP/IP over ethernet. In fact, at the high end, such as the larger newspapers (the ones I was working on sold in excess of 4 million copies/day), PostScript printers aren't found anywhere. PostScript is ripped to bitmap on a regular computer, and the bitmap is sent to an imager that prints a negative (or these days, direct to plate with a CTP machine). Similarly, proofs are ripped to bitmap, and then converted to a suitable format for the proofer in question, usually PCL.

  • While working at IBM, I outlined a plan that would have taken about 2 years to implement. The upshot of it was that we'd start out with simple print filters (Which is done and can be downloaded at www.printers.ibm.com) and progress toward a more Widows/OS2 type solution, where you define a rendering API and the various manufacturers would code to that API to create new printer drivers. My hope was that Xprt would turn out to be feasible since it's an already-defined standard, albiet a rarely used one.

    I was going to push for everything to be open sourced, but I've since left them and doubt they'll have the balls to follow through with any of it. Too bad for them; the UNIX market isn't particlarly huge, but it might make a billion here, a billion there for a company that's hip to it.

  • Re:What about lpr (Score:3)

    by Shimbo ( 100005 ) on Monday July 10, 2000 @11:07PM (#944306)
    Unix print spooling has worked fine until now - why change it?

    There are several things it doesn't address very well. The main one is that it is a hack on direct network connected printers: you can print to them but then the printer has no way of communicating status back.

    Compare with say, how printing on Appletalk works, where you open a bidirectional channel to the printer, and it tells you on the channel if it's out of paper or whatever.

    Furthermore, lpd includes no way of managing networked printers remotely. How do you set up access lists, or retrieve accounting information?

    lpr is a 'just good enough' protocol. Don't believe that it can't be improved on.

  • I mean, this is surprising. I've heard tales of people in like, jungles and stuff, who used paper, but I didn't think it happened here in our own country. Is paper expensive now that e-communication is the standard? Does it have to be imported from Brazil or something? I've heard that Cuban paper is the best paper in the world, but because of the embargo...

    :-) Not a troll, just a bit of humor...hehe.
  • Could somebody explain to me why it's a good idea to layer this on top of HTTP? As far as I can see, it doesn't really solve the firewall problem; the article specifically says they'll run on different ports so that admins can firewall all IPP traffic. Last I checked, HTTP actually used a fairly inefficient file-transfer mechanism. Given that the modern corporate document is filled with images and charts and sundry multimedia (and therefore bloats pretty quickly), wouldn't it make more sense to layer this on top of, say, FTP? Why is it layered on top of anything at all? What does HTTP provide that IPP needs?

    I'm sure there are some answers to these questions, because I believe in the IETF and I personally have only ever designed toy protocols, but I don't see the answers in the article.
  • All the High-End network printers come loaded with PostScript. It's not even an option on most of them. They assume that if you're doing workgroup printing, you're going to want PostScript. It's a good assumption. Whether you're looking at HP's network printers, the ones from Xerox or the ones from IBM (Workgroup printing is a piddly component -- the money making IBM printers take whole rooms and are usually used to print out entire magazines) PostScript is there.

    Of course, unless you're in a fortune 500 company, chances are they aren't too into the whole infrastructure of the thing and won't be too keen on getting workgroup printers.

  • Let me know when they start making 600 dpi, or even 300 dpi, CRTs.


    like these [xerox.com] ones ?
  • Well, it used to be 40% about 10 years ago.

    Is there anyone out there that knows the present ratio for tech support calls?

  • Or to make the difference even more clear, IPP is to Postscript as HTTP is to HTML (or PDF, JPEG, or whatever). IPP does not care what is in the document.

    /Don

  • What's really nice about standards like these is that they greatly simplify life for working with the products which support them. Think of how you'd be able to write drivers for your Palm, Cassiopeia, Windows Laptop, Linux Desktop, and C-64 all fairly easily because you're writing for the same basic interface/

  • \ vs / (Score:3)

    by zaugg ( 87876 ) on Monday July 10, 2000 @05:10PM (#944314)
    IPP is built on top of HTTP, which in turn runs over TCP/IP. IPP traffic is sent as a Multi-purpose Internet Mail Extensions-type using HTTP's feature for posting information. End users submit a print request using a command in the browser address line that starts with "ipp:\\" rather than "http:\\."

    Oops, hope the backslashes don't make there way into the protocol :)

    zaugg

    .sig free for six months

  • That's a sig, my friend. It just happened to fit the occassion.

    Yes, stereotypes are true, for the most part. But I'd expect someone who deems themselves worthy of judging others to have a little more ammo than oft-repeated, highly unoriginal quips. Stereotypes are only good when put to good purpose.
  • I haven't checked out the full spec yet, but this article makes it sound like it's going to require a separate directory service? This is going authenticate against its own database? This sounds like a database merging nightmare. And how is this going to make a "write once" driver? Every OS is going to have to have it's own routines to convert data from Word, Star Office, Netscape, etc... into this IPP format. So you're right back to multiple drivers, just not maybe in the same complexity. Personally I thought LPR spooling over TCP/IP was great. Simple, effective, and the security worked right off your platform of choice.
  • Every OS is going to have to have it's own routines to convert data from Word, Star Office, Netscape, etc... into this IPP format.

    Nope. IPP is a protocol, not a file format.

  • Good point. Another is....

    How many times do I need to redirect a printout to Someplace else on the planet. Esp. when the printer is on the Internet & (one would assume) so is the person. (E-mail, FTP whatever.

    If it is within the compnay (say the HP plotter in Eng) I can print to it with the Jetdirect software. (or windows shared with the printer shared.... but we wont talk about that).

    So what do you need another printing protocol for?
  • We're only dismissive because it's basically finished. Let's see: lpr and Postscript. and smb if you need to use Windoze. Everything else is window-dressing.

    Well, this is pretty exciting to those of us who actually make the printers... We make specialty industrial printers [zebra.com]. IPP is nice in that status and printer capabilities can be returned from the printer. This means that conditions like paper out and ink levels can be reported back to the user. As far as I know, lpd and SMB can't do that. (If they can, let me know! I've got a nice inkjet attached to my Linux box at home, and I'd love to get it to report ink levels to the Win98 clients that print to it!)

    Let's face it, printers today have more computing power than desktop machines did a few years ago. Let's treat them like the independent computers they are, rather than as some dumb peripheral plugged into an isolated machine.

  • Why in god's name should lpr return status!?!

    Here's what we do:

    lpr+krb -> lpd -> filter printer
    |
    user Heh, what a concept! Using instant messaging to send instant messages to users!

  • The fact is, right now paper-based documents (books, magazines) have superior user interface (even plain printouts, compared to normal CRT display). Before that changes, there won't be paperless society, not even paperless office.
  • Ahem. Go read the link you supplied, and also see www.dpix.com [dpix.com]. They've just started manufacturing the things, and are targetting high-margin military and medical applications.

    Besides, even if, by some miracle, I could actually purchase one of these things, the software infrastructure isn't there. All currently deployed and widely used windowing systems are pixel-dependant, and would be virtually unusable on something like this.
    --
    Change is inevitable.

  • According to the article:
    "Users will be able to print documents either within their enterprises or among enterprises instead of sending faxes."

    Well what wrong with just (email || ftp ) + ing) the fscking document in a format you can both read. e.g.:
    • Word, embedding fonts if neccessary
    • postscript
    • some sgml derived markup language
    • RTF
    • you get the idea
      • While it is still advantageous to have one standard its still possible to do the kinds of thing they are talking about.
  • The Microsoft collective wishes to assure the /. community that the URL feature was omitted for good reason. In our attempts to Innovete(tm) we are extending the DNS protocol. The new extensions will be availabe with our next service pack for Windows 2000. NT 4.0 users can purchase a license for the new technology for $999.
  • The benefit to having spammers junk-print Internet printers is that *FINALLY* businesses will pressure governments to make spamming illegal.

    'cause it'll cost them real dollars, in real goods, to print the junkmail. Right now, it's all just airy-fairy "virtual" spam, which they somehow don't consider to have a real cost.


    --
  • Re: Printing -- exciting, eh? But one of those necessary evils in life.

    Only in the linux world would the one killer biz app (transfering a document to paper) be treated with such a dismissive tone.
    ___

Slashdot Top Deals

Seen on a button at an SF Convention: Veteran of the Bermuda Triangle Expeditionary Force. 1990-1951.

Close