Re: The nightmarish problem of installing a printer
On 22-9-2010 21:35, Matthew Seaman wrote: On 22/09/2010 20:04:25, Dick Hoogendijk wrote: You're certainly not the only one liking CUPS. I long hesitated to use it, but once I'd decided to do so, I wouldn't go back to lpr. No way. It's very easy to set up and does a great job. CUPS is OK but most FreeBSD people don't seem to think so. I don't get it. CUPS is really nice *when it works*. If you're lucky and have managed to buy the right sort of printer hardware, and the Gods are smiling upon you, then CUPS will serve you well. The list of supported hardware is very very long, so this part shouldn't be so hard. On the other hand, when CUPS is bad, it is truly awful. Excessively hard to debug; impossible to fix without Guru-level powers. One of those No user serviceable parts inside sort of things. This might be true. I guess this is a valid reason not to use it if you want to be able to debug things yourself _AND_ if you are a code guru. CUPS works brilliantly when I plug my printer's USB cable directly into my Mac. But I've never yet managed to print to exactly the same printer via CUPS when it is plugged into my FreeBSD server. Hmm, strange. CUPS works very well when I use a linux server, but it also works very well on my main server, now running OpenSolaris-b134. I would not want to be offensive, but could it be something inside the FreeBSD code that makes it harder to function w/ CUPS? It really is a pity, because it really is very easy to set printers up _AND_ share them over you LAN at the same time. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
Personally, for bulk printing, and even more so for intermittent printing (the kind where ink dries up and gets tossed away when you use the printer once every blue moon), most users would save a _LOT_ of money by looking at a laser printer instead. +1 Take a good look at Xerox'es Phaser line (used to be tektronix phaser). They're no longer pawn-your-firstborn expensive, they're reliable, and they basically speak every standard protocol on the market (including both Postscript and PCL). ... The cheapest multi-function laser recommended by you is the Phaser 6128MFP, an obviously loss-loser. The next version is $1500 ... The Phaser 6130 (which uses C, M, Y, and K toner cartridges rather than the wax sticks that Tektronix introduced) was $400 about 4 years ago. it would be total over-kill, and a gross waste of money, to install one in my home. I believe Gordon Bell, the founder of DEC, once said almost exactly that about home computers :) A couple of years ago I got very tired of buying ink cartridges. I search and found the Samsung scx-4725fn for a very good price. Laser, network, all-in-one. It is not color but that was not a requirement for me. Just hook it up to the network and create a simple /etc/printcap and add the ip to /etc/hosts and away you go. A quick search shows it can still be purchased for under $300 US. Ditto for the Samsung ML-2571N, except that it is just a printer and it was about $60 a few years ago IIRC. (I am partial to the N model, which is directly network connected. Essentially the same printer, but without the network port, goes for maybe $10 less. IMO it's well worth $10 to just plug it in and have it work.) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
Warren Block wbl...@wonkity.com wrote: If someone comes up with a working GDI printer emulation layer, that would make a great port. They already did, and it's already in ports. It's (part of) wine. Unfortunately it uses CUPS. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Tue, Sep 21, 2010 at 5:24 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: A) *THEY* developed the interface specifications. They license printer manufacurers to build to it. They _would_ obejct if somebody used their technology to compete against them. B) As it is, to _use_ one of those printers, you *HAVE*TO*BY* a MS O/S. if one could use those printers -without- a MS O/S, that is a 'provable' loss in MS O/S sales -- one sales loss for -each- non-MS system that has such a printer attached. If this were true, and there really were a big conspiracy on Microsoft's part to make manufacturers only support Windows, then you wouldn't see cheap printers that support both Windows and MacOS X. In reality, such printers are pretty easy to find. Never attribute to malice that which can be explained by simple economics. ;) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Wed, 22 Sep 2010 10:27:05 -0700 David Brodbeck g...@gull.us articulated: On Tue, Sep 21, 2010 at 5:24 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: A) *THEY* developed the interface specifications. They license printer manufacurers to build to it. They _would_ obejct if somebody used their technology to compete against them. B) As it is, to _use_ one of those printers, you *HAVE*TO*BY* a MS O/S. if one could use those printers -without- a MS O/S, that is a 'provable' loss in MS O/S sales -- one sales loss for -each- non-MS system that has such a printer attached. If this were true, and there really were a big conspiracy on Microsoft's part to make manufacturers only support Windows, then you wouldn't see cheap printers that support both Windows and MacOS X. In reality, such printers are pretty easy to find. I just heard a rumor that FreeBSD is secretly in collusion with Microsoft and the printer manufacturer's consortium to advance the usage of printers on the Win32/64 platform. By refusing to create an environment in which printers can use tested and certified drivers on a non-windows operating system, they are secretly contributing to Microsoft's continued domination in the PC market. Slash-Dot will unequivocally be denying the accuracy of this story; however, we all are aware that they are secretly being paid by the EC in an attempt to diminish Microsoft's market share. Unfortunately, I cannot substantiate these claims; however, as has been demonstrated numerous times on this forum, documentation of subversive acts is not a requirement. In fact, it might well be called counter-productive. -- Jerry ✌ freebsd.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Be careful of reading health books, you might die of a misprint. Mark Twain ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Wed, Sep 22, 2010 at 11:36 AM, Peter A. Giessel pgies...@mac.com wrote: The question you are missing is *HOW* does MacOS X print to all these cheap printers? Lets take a couple of screen captures from Mac OS X.6 (Apple's latest released OS) with all current updates installed: http://giessel.org/pictures/OSX_printers1.png http://giessel.org/pictures/OSX_printers2.png Hmm, CUPS, and Gutenprint Are these methods available for FreeBSD? In some cases, yes. In other cases, where the manufacturer is supplying an OS X driver that doesn't come with CUPS/Gutenprint, the additional driver bits may not be FreeBSD-compatible. I may be the only person here who actually likes CUPS. Yes, it's complicated from a software standpoint, but configuring it is much less opaque. Printers really are complicated, so having a GUI to help set them up is nice. I remember having to manually write and debug filter scripts and edit /etc/printcap by hand, and I'm quite glad those days are over. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On 22-9-2010 20:40, David Brodbeck wrote: OI may be the only person here who actually likes CUPS. Yes, it's complicated from a software standpoint, but configuring it is much less opaque. You're certainly not the only one liking CUPS. I long hesitated to use it, but once I'd decided to do so, I wouldn't go back to lpr. No way. It's very easy to set up and does a great job. CUPS is OK but most FreeBSD people don't seem to think so. I don't get it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On 22/09/2010 20:04:25, Dick Hoogendijk wrote: On 22-9-2010 20:40, David Brodbeck wrote: OI may be the only person here who actually likes CUPS. Yes, it's complicated from a software standpoint, but configuring it is much less opaque. You're certainly not the only one liking CUPS. I long hesitated to use it, but once I'd decided to do so, I wouldn't go back to lpr. No way. It's very easy to set up and does a great job. CUPS is OK but most FreeBSD people don't seem to think so. I don't get it. CUPS is really nice *when it works*. If you're lucky and have managed to buy the right sort of printer hardware, and the Gods are smiling upon you, then CUPS will serve you well. On the other hand, when CUPS is bad, it is truly awful. Excessively hard to debug; impossible to fix without Guru-level powers. One of those No user serviceable parts inside sort of things. CUPS works brilliantly when I plug my printer's USB cable directly into my Mac. But I've never yet managed to print to exactly the same printer via CUPS when it is plugged into my FreeBSD server. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: The nightmarish problem of installing a printer
On 2010/09/22 at 9:27, g...@gull.us (David Brodbeck) wrote: If this were true, and there really were a big conspiracy on Microsoft's part to make manufacturers only support Windows, then you wouldn't see cheap printers that support both Windows and MacOS X. In reality, such printers are pretty easy to find. Never attribute to malice that which can be explained by simple economics. ;) The question you are missing is *HOW* does MacOS X print to all these cheap printers? Lets take a couple of screen captures from Mac OS X.6 (Apple's latest released OS) with all current updates installed: http://giessel.org/pictures/OSX_printers1.png http://giessel.org/pictures/OSX_printers2.png Hmm, CUPS, and Gutenprint Are these methods available for FreeBSD? Mainly what Apple did was pre-install and pre-configure in a user-friendly way CUPS and Gutenprint. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
From owner-freebsd-questi...@freebsd.org Wed Sep 22 12:25:37 2010 Date: Wed, 22 Sep 2010 10:27:05 -0700 From: David Brodbeck g...@gull.us To: freebsd-questions@freebsd.org Subject: Re: The nightmarish problem of installing a printer On Tue, Sep 21, 2010 at 5:24 PM, Robert Bonomi bon...@mail.r-bonomi.com w= rote: A) *THEY* developed the interface specifications. They license printer manufacurers to build to it. =A0 They _would_ obejct if somebody used their technology to compete against them. B) As it is, to _use_ one of those printers, you *HAVE*TO*BY* a MS O/S. =A0 if one could use those printers -without- a MS O/S, that is a =A0 'provable' loss in MS O/S sales -- one sales loss for -each- non-MS =A0 system that has such a printer attached. If this were true, and there really were a big conspiracy on Microsoft's part to make manufacturers only support Windows, then you wouldn't see cheap printers that support both Windows and MacOS X. In reality, such printers are pretty easy to find. NICE STRAWMAN. But that was -not- the point of the discussion that I was addressing. The QUESTION ASKED was 'why would Microsoft object if somebody else implemented -their- printer-driver technology. And the answer to -that- question -is- found in 'simple economics' -- if somebody did so, it would represent a 'potential loss' in MS operating system sales. The potential threat of MS taking issue (and possible legal action) against someone who develops a usable 'windows clone' printing subsystem, is not 'in iteself' a 'deal breaker' that preents it from happening. It is mrerely more nails in the lid of the coffin. Eliminate the other barriers and you still have that one to worry about. eliminate -only- it, and the coffin lid is -still- nailed down. MS knows better than to try to dictate what markets printer manufacturers can build for. if a manufacturer wants to develop for a _competing_ market using _competing_ technology, no problem. If a manufacturer wanted to develop for a competing (with oter microsoft produts -- i.e. were every sale of the 'competing' product is a potential 'lost sale' of a MS product) market, *using*MICROSOFT's*tecnology, the big problem. NOTE WELL I did -not- claim there is any 'conspiracy' on MS's part to force printer manuracturers into only supporting window. There isn't. Printer manufacturers _chose_ to roll out devices that work only when coupled with host-based software that they provie for Windows, and Windows *ONLY*. They have, probably rightly, concluded that the -cost- of providing drivers for other environments (or even the cost of making the specifications avaialable) is more than the profits that that (relatively speaking) small number of additional sales would bring in. They build for their 'primary market', and if cost-minimization for -that- market means that the device is 'unusable' in a niche market that would bring in minimal revenues, they =don't=care=. Regardless of how 'inconvenient' it is for the users _in_ that niche 'market. There's also another thing going on with regard to the low-end inkjet printers. What does it tell you when you can buy a _new_ printer, _with_ a set of ink cartridge for roughly 50% more than the cost of a set of replacement cartriges? Hint, it's the same strategy that King Gilette used to sell safety razors. The 'total cost of ownership' of an inkjet printer is _obscene_ when figured on a per-page basis, with highly intermittant use. Used 'reglarly but lightly' the cost of ownership is merely riciculously high. But the customers _don't_ tink about te purchases that way. If the purchase price is rock bottom, who cares about the 'operating cost' applies. unless they're using it regularly enough that they see ink as an expence at least monthly. Guess why printer manufactures now put 'smart chips' _in_ the cartridge so that when the page count has been reached, it _stops_working even if there are 'consumables' still in the package. Aw, shucks, you can't _re-fill_ that cartridge with cheap ink. Guess who is crying all theway to the banke over -that- little problem. wry grin Summary: the obstacles to developing a 'shim'/'wrapper' around a Windows printer driver to allow te use of cheap 'Winprinters' in a Unix environment. 1) the 'appication side' interface it would is incompatbile with *every* existing Unix application that produces print output. 2) providing a lowlevel /'translator' to map between the output calls that existant print-producing packages usa and the windows environment 'expects' is an enitre _additional_ undertaking that would have to be done. 3) (2) _cannot_ be done 'perfectly' there are concepts on the Unix side for which there are -no- windows equivalents. And vice-versa. 4) WINDOWS applications are the only things that directly produce output 'compatible' with this new printing system. (a) absent the translator discueesed in (2), the a unix
Re: The nightmarish problem of installing a printer
On Tue, 21 Sep 2010 02:42:22 +0200 C. P. Ghost cpgh...@cordula.ws articulated: On Mon, Sep 20, 2010 at 7:16 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Adapting MS-Windows print drivers is not 'practical' either. A windows print driver is embedd in the O/S KERNEL, with _system_ calls_ (not mere 'library' routines) that implement the 'device-dependant' rendering of layout/formating directions. One then takes the 'opaque object' so produced and sends it (via _another_ set of system calls) to the 'output' function of that same driver. Is that really so? How about writing some emulation shim like ndis(4) for winprinters? Please correct me if I'm wrong, as I'm not a Windows systems programmer, but this is what I'm thinking about. As far as I understand Windows printing, there are two aspects to resolve, given a vendor supplied windriver binary blob: 1/ the windriver gets some (opaque) data from the GDI+ -- maybe a bitmap, with some meta data. 2/ the windriver interprets this data however it sees fit, and then talks to the NT kernel (maybe via DLL calls) to send electrical impulses to the printer. Now, the data formats of 1/ (GDI stuff) is probably well defined (and therefore published) in gdiplus.dll or something similar and is the same for all windriver blobs. The API/ABI needed to talk to the NT kernel is probably defined in the Windows DDK (or whatever it is called nowadays). So, in both cases, we have stable API/ABI interfaces on both sides of the windriver binary blob: 1/, 2/ at the upper half, and 2/ at the bottom half. So, if we wanted to use those windriver blobs just like in the ndis(4) case, all we need is an emulation shim for both interfaces. Maybe 1/ is already covered by Wine (?) so we could borrow some code from there; and 2/ is basically a matter of mapping the subset of NT calls needed to read from and write to Windows ports to Unix calls to read and write to our Unix devices. Again, I'm no Windows programmer, and it is probably more involved than this. But the basic idea remains: the interfaces on both sides of the windriver binary blobs is pretty stable and (I think) not a secret at all. In the Unix world, printing is handled _externally_ to the kernel. The application must have =its=own=means= of deciding what formatting/layout commands to use -- it _can't_ query the O/S for this info; the O/S simply doesn't have it. Well, it doesn't matter if the windriver shims run as userland daemon or (partially) inside the kernel. The point here is that the windriver - NT, and windriver - GDI+ interface are both stable and not difficult to understand, so both can be emulated. At least theoretically. In practice, it takes some time and effort to get it right, quite obviously. The bottom line is that installing and running a printer on a Window's machine is usually far easier than on a *nix variation. Even sharing a printer on a network in a Windows environment is simpler. On a separate note, I have friends who claim that the Ubuntu printer installation routine is similar to the Window's one and works quite well for most mainstream printers. I read something a few months ago that Ubuntu was working on using Window's printer drivers directly in Ubuntu. I cannot confirm that; however, it would certainly be a worthwhile avenue to explore. -- Jerry ✌ freebsd.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On 21.09.2010 13:37, Jerry wrote: The bottom line is that installing and running a printer on a Window's machine is usually far easier than on a *nix variation. Even sharing a printer on a network in a Windows environment is simpler. Actually ... no. Unless you are talking about the keep HP happy by purchasing ink every week usb-printers. Personally, for bulk printing, and even more so for intermittent printing (the kind where ink dries up and gets tossed away when you use the printer once every blue moon), most users would save a _LOT_ of money by looking at a laser printer instead. Take a good look at Xerox'es Phaser line (used to be tektronix phaser). They're no longer pawn-your-firstborn expensive, they're reliable, and they basically speak every standard protocol on the market (including both Postscript and PCL). //Svein -- +---+--- /\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE +---+--- If you really are in a hurry, mail me at svein-mob...@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. Picture Gallery: https://gallery.stillbilde.net/v/svein/ signature.asc Description: OpenPGP digital signature
Re: The nightmarish problem of installing a printer
On Tue, 21 Sep 2010 14:16:16 +0200 Svein Skogen (Listmail account) svein-listm...@stillbilde.net articulated: On 21.09.2010 13:37, Jerry wrote: The bottom line is that installing and running a printer on a Window's machine is usually far easier than on a *nix variation. Even sharing a printer on a network in a Windows environment is simpler. Actually ... no. Unless you are talking about the keep HP happy by purchasing ink every week usb-printers. Personally, for bulk printing, and even more so for intermittent printing (the kind where ink dries up and gets tossed away when you use the printer once every blue moon), most users would save a _LOT_ of money by looking at a laser printer instead. Take a good look at Xerox'es Phaser line (used to be tektronix phaser). They're no longer pawn-your-firstborn expensive, they're reliable, and they basically speak every standard protocol on the market (including both Postscript and PCL). 1) I was not referring specifically to HP 2) Personally, I have never had a printer connected via USB 3) I was referring to connecting a printer via a wireless connection, a very common occurrence and one I employ in my home. It is also becoming more common in business environments since it makes relocating a printer far simpler. The cheapest multi-function laser recommended by you is the Phaser 6128MFP, an obviously loss-loser. The next version is $1500. I can buy a lot of ink for that. I agree that a laser printer is fine for a business environment; however, it would be total over-kill, and a gross waste of money, to install one in my home. -- Jerry ✌ freebsd.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ From 0 to what seems to be the problem officer in 8.3 seconds. Ad for the new VW Corrado signature.asc Description: PGP signature
Re: The nightmarish problem of installing a printer
On Tue, 21 Sep 2010 08:58:58 -0400 Jerry freebsd.u...@seibercom.net wrote: On Tue, 21 Sep 2010 14:16:16 +0200 Svein Skogen (Listmail account) svein-listm...@stillbilde.net articulated: On 21.09.2010 13:37, Jerry wrote: The bottom line is that installing and running a printer on a Window's machine is usually far easier than on a *nix variation. Even sharing a printer on a network in a Windows environment is simpler. Actually ... no. Unless you are talking about the keep HP happy by purchasing ink every week usb-printers. Personally, for bulk printing, and even more so for intermittent printing (the kind where ink dries up and gets tossed away when you use the printer once every blue moon), most users would save a _LOT_ of money by looking at a laser printer instead. Take a good look at Xerox'es Phaser line (used to be tektronix phaser). They're no longer pawn-your-firstborn expensive, they're reliable, and they basically speak every standard protocol on the market (including both Postscript and PCL). 1) I was not referring specifically to HP 2) Personally, I have never had a printer connected via USB 3) I was referring to connecting a printer via a wireless connection, a very common occurrence and one I employ in my home. It is also becoming more common in business environments since it makes relocating a printer far simpler. The cheapest multi-function laser recommended by you is the Phaser 6128MFP, an obviously loss-loser. The next version is $1500. I can buy a lot of ink for that. I agree that a laser printer is fine for a business environment; however, it would be total over-kill, and a gross waste of money, to install one in my home. A couple of years ago I got very tired of buying ink cartridges. I search and found the Samsung scx-4725fn for a very good price. Laser, network, all-in-one. It is not color but that was not a requirement for me. Just hook it up to the network and create a simple /etc/printcap and add the ip to /etc/hosts and away you go. A quick search shows it can still be purchased for under $300 US. http://computers.pricegrabber.com/printers/Samsung-SCX-4725FN-All-One/m34785285.html No CUPS needed. Robert ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Tue, 21 Sep 2010 02:42:22 +0200, C. P. Ghost cpgh...@cordula.ws wrote: On Mon, Sep 20, 2010 at 7:16 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Is that really so? How about writing some emulation shim like ndis(4) for winprinters? Please correct me if I'm wrong, as I'm not a Windows systems programmer, but this is what I'm thinking about. One big problem is that Windows doesn't equal Windows. I had customers who intendedly bought some printer, then needed to switch to another Windows, and then found their printer useless as there was no specific driver available anymore. Creating compatibility layers for printer drivers that do not care about compatibility at all is like shooting a moving target. As I am not a Windows person, I could only imagine that this would be much more difficult than printer manufacturers (who sit at the source) agreeing to simply use an existing and documented standard. So, in both cases, we have stable API/ABI interfaces on both sides of the windriver binary blob: 1/, 2/ at the upper half, and 2/ at the bottom half. I really doubt about a stable interface, or situations as described above wouldn't have happened. So, if we wanted to use those windriver blobs just like in the ndis(4) case, all we need is an emulation shim for both interfaces. Maybe 1/ is already covered by Wine (?) so we could borrow some code from there; and 2/ is basically a matter of mapping the subset of NT calls needed to read from and write to Windows ports to Unix calls to read and write to our Unix devices. Keep in mind there are stupid things in the world as patents, intelellectual property, licensing fees and copyrighted secret codes. At the moment there was a program (or any other kind of facility) that makes Winprinters accessible by *ANY* OS (not only FreeBSD, but maybe all BSDs and Linusi and Solaris and who knows what else), MICROS~1 would start violently screaming as someone is eating from their cake. Keep in mind that Winprinters are an important target platform for home users who PAY for Windows and PAY for a compatible printer. They pay once every two years or so. MICROS~1 and the printer manufacturers can't stand it if one uses their products too long, as long-term use does imply NO FURTHER SALES. And now imagine that a user can fully use all features of a formerly-Winprinter all-in-one ink pee copier scanner fax machine - where would be his need to buy a Windows to do that as he can now use FreeBSD for free? Of course, this consideration is very far away from any technical understanding - as typical for lawpersons who make money from bullshit. :-) But the basic idea remains: the interfaces on both sides of the windriver binary blobs is pretty stable and (I think) not a secret at all. In that case, I would ask myself: Why hasn't it been done already? If your assumption was right, it would already work. As it currently does not work, I would check your assumption. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Tue, 21 Sep 2010 08:58:58 -0400, Jerry freebsd.u...@seibercom.net wrote: The cheapest multi-function laser recommended by you is the Phaser 6128MFP, an obviously loss-loser. The next version is $1500. I can buy a lot of ink for that. I agree that a laser printer is fine for a business environment; however, it would be total over-kill, and a gross waste of money, to install one in my home. This depends on what you're printing at home. If you mostly use it for B/W text and graphics, buying a used (!) office-class laser printer is cheaper than buying some ink-pee home consumer device. Keep in mind that you can *not use* the laser printer for some time without problems, but if you *not use* an ink-pee printer for some time, it will dry out the ink and maybe damage the printing heads (if separate), or even let the ink flow through the printer. I have seen that already - very unpleasant. Instead, office-class laser printers are more efficient in use of good refurbished toner cartridges. I'm using a HP Laserjet 4 for example as a copying center (low-end computer, parallel scanner, parallel printer). The last time I bought a toner cartridge was in 2004, and right now, it's starting to fade. I'm using this system VERY often. The printer itself is more than 15 years in my hands now, and I HEAVILY used it. You simply can't break good printers. But if you require photo-printing, maybe on specific papers, or you need a device for making colored copies, using a typical home consumer device is often the better solution. When I need digital photos printed out, I take the data to the drugstore as they can do much better (and water-resistant!) than ink-pee. A TODAY's office-class laser printer surely looks like overkill for a home setting, I agree here. But keep in mind used ones are also good - IF they are good. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Tue, 21 Sep 2010 07:37:22 -0400, Jerry freebsd.u...@seibercom.net wrote: The bottom line is that installing and running a printer on a Window's machine is usually far easier than on a *nix variation. Even sharing a printer on a network in a Windows environment is simpler. But much more expensive, and especially if we're talking networked settings, more complicated to manage (think about offices for example), which makes it more expensive again (support). Additionally, using ink-pee printers in office settings usually is considered a no-go, as it is very unprofessional, inefficient, and did I mention it? Expensive. :-) On a separate note, I have friends who claim that the Ubuntu printer installation routine is similar to the Window's one and works quite well for most mainstream printers. I read something a few months ago that Ubuntu was working on using Window's printer drivers directly in Ubuntu. I cannot confirm that; however, it would certainly be a worthwhile avenue to explore. That sounds interesting. Users coming from a Windows background could then easily put in the printer CD (if they didn't throw it away already) and install drivers. Of course, that's not how UNIX does things - here, all the things you need to interact with hardware are provided by the OS ideally, or by packages you can install if needed - with less forced inter- action. But that's reality, not a happy UNIX dreamland where you would just plug in the printer and let the kernel and userland deamons make it available for printing and scanning immediately. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Tue, 21 Sep 2010 07:16:21 -0700, Robert travelin...@cox.net wrote: A couple of years ago I got very tired of buying ink cartridges. I search and found the Samsung scx-4725fn for a very good price. Laser, network, all-in-one. It is not color but that was not a requirement for me. Just hook it up to the network and create a simple /etc/printcap and add the ip to /etc/hosts and away you go. So THAT's what I call handling it easily. As the printer (!!!) does take care of the most things, it's easy to install it as everything you need is to make it known to your network and write a line into /etc/printcap. The HP Laserjet 4000 duplex I have at home (yes, it's true) also has a built-in printer server, so programs like lpq and lprm can query the printer queue INSIDE THE PRINTER. That's a very nice feature for office settings as there is no need to buy a PC and a Windows to make a printer server. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Tue, Sep 21, 2010 at 5:43 PM, Polytropon free...@edvax.de wrote: On Tue, 21 Sep 2010 02:42:22 +0200, C. P. Ghost cpgh...@cordula.ws wrote: On Mon, Sep 20, 2010 at 7:16 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Is that really so? How about writing some emulation shim like ndis(4) for winprinters? Please correct me if I'm wrong, as I'm not a Windows systems programmer, but this is what I'm thinking about. One big problem is that Windows doesn't equal Windows. I had customers who intendedly bought some printer, then needed to switch to another Windows, and then found their printer useless as there was no specific driver available anymore. Creating compatibility layers for printer drivers that do not care about compatibility at all is like shooting a moving target. As I am not a Windows person, I could only imagine that this would be much more difficult than printer manufacturers (who sit at the source) agreeing to simply use an existing and documented standard. So I assume that the binary blobs of those winprinters are different for different versions of Windows. So there would be two (or three?) set of interfaces to emulate instead of just one. So, in both cases, we have stable API/ABI interfaces on both sides of the windriver binary blob: 1/, 2/ at the upper half, and 2/ at the bottom half. I really doubt about a stable interface, or situations as described above wouldn't have happened. The stable interface is likely tied to one specific Windows release: say, one for XP and one for Windows 7. Since most winprinters are supposed to (still) run on XP, they come with an XP windriver blob, and that's all what matters w.r.t. interface stability. So, if we wanted to use those windriver blobs just like in the ndis(4) case, all we need is an emulation shim for both interfaces. Maybe 1/ is already covered by Wine (?) so we could borrow some code from there; and 2/ is basically a matter of mapping the subset of NT calls needed to read from and write to Windows ports to Unix calls to read and write to our Unix devices. Keep in mind there are stupid things in the world as patents, intelellectual property, licensing fees and copyrighted secret codes. Yes, that's indeed the real problem. A legal, not a technical one. At the moment there was a program (or any other kind of facility) that makes Winprinters accessible by *ANY* OS (not only FreeBSD, but maybe all BSDs and Linusi and Solaris and who knows what else), MICROS~1 would start violently screaming as someone is eating from their cake. Keep in mind that Winprinters are an important target platform for home users who PAY for Windows and PAY for a compatible printer. They pay once every two years or so. MICROS~1 and the printer manufacturers can't stand it if one uses their products too long, as long-term use does imply NO FURTHER SALES. And now imagine that a user can fully use all features of a formerly-Winprinter all-in-one ink pee copier scanner fax machine - where would be his need to buy a Windows to do that as he can now use FreeBSD for free? As far as I understand this, Microsoft doesn't manufacture those winprinters, so why would they screem if those printers were able to run on other platform too? You can even see it the other way: for every winprinter manufactured (or, more precisely, for every windriver sold), Microsoft may get a fixed share due to patent royalties from the manufacturer. So, suppose a manufacturer sells more of his winprinters to BSD/Linux/Solaris/... folks because we had this shim, it would translate to more patent royalties to Microsoft too. So it is in Microsoft's interest not only NOT to kick and scream, but actually to encourage those winprinters by publishing the needed interfaces. It can only increase sales, and they will get more kickbacks from those additional sales. Of course, this consideration is very far away from any technical understanding - as typical for lawpersons who make money from bullshit. :-) That's for sure. ;-) But the basic idea remains: the interfaces on both sides of the windriver binary blobs is pretty stable and (I think) not a secret at all. In that case, I would ask myself: Why hasn't it been done already? If your assumption was right, it would already work. As it currently does not work, I would check your assumption. :-) I don't know why it hasn't been done up to now. After all, this is nothing but an exercise in mapping one set of interfaces onto another set of interfaces. We've done this kind of interface matching with with the Linuxulator, NDIS is another good example, and the Wine guys are doing a great job too. I fail to see a compelling TECHNICAL reason why Windows drivers in general (and windrivers in particular) couldn't be docked to Unix systems. Of course, legal reasons are a different matter. Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... Regards, -cpghost. -- Cordula's
Re: The nightmarish problem of installing a printer
On Tue, 21 Sep 2010 19:36:00 +0200, C. P. Ghost cpgh...@cordula.ws wrote: At the moment there was a program (or any other kind of facility) that makes Winprinters accessible by *ANY* OS (not only FreeBSD, but maybe all BSDs and Linusi and Solaris and who knows what else), MICROS~1 would start violently screaming as someone is eating from their cake. Keep in mind that Winprinters are an important target platform for home users who PAY for Windows and PAY for a compatible printer. They pay once every two years or so. MICROS~1 and the printer manufacturers can't stand it if one uses their products too long, as long-term use does imply NO FURTHER SALES. And now imagine that a user can fully use all features of a formerly-Winprinter all-in-one ink pee copier scanner fax machine - where would be his need to buy a Windows to do that as he can now use FreeBSD for free? As far as I understand this, Microsoft doesn't manufacture those winprinters, so why would they screem if those printers were able to run on other platform too? Very simple: Whenever you are using FreeBSD (or any other operating system that is not Windows), you are NOT using Windows. MICROS~1's monopoly is based upon three pillars: Mind share, usage share, and in conclusion, market share. That again is what matters to printer manufacturers, as they are told the secret keys about how to make their printer work on Windows. You can even see it the other way: for every winprinter manufactured (or, more precisely, for every windriver sold), Microsoft may get a fixed share due to patent royalties from the manufacturer. So, suppose a manufacturer sells more of his winprinters to BSD/Linux/Solaris/... folks because we had this shim, it would translate to more patent royalties to Microsoft too. That's not logical as the package, the shiny box on the shelf that the customer wants, already contains a CD (or today, a DVD) with drivers for Windows, as this is the PC, and there's nothing else. Users of non-Windows operating systems are a niche market that does not persist in the scope of manufacturers. They are happy selling more and more cheap units (than fewer more expensive units). For them and for MICROS~1 it's a win-win situation, as the customer always pays. So it is in Microsoft's interest not only NOT to kick and scream, but actually to encourage those winprinters by publishing the needed interfaces. It can only increase sales, and they will get more kickbacks from those additional sales. Insignificant amounts, does not pay. The MICROS~1 concept of software ecosystems does not tolerate anything different. Keep in mind the three pillars mentioned before - they would be in danger. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Tue, 21 Sep 2010 19:47:27 +0200 Polytropon free...@edvax.de articulated: On Tue, 21 Sep 2010 19:36:00 +0200, C. P. Ghost cpgh...@cordula.ws wrote: At the moment there was a program (or any other kind of facility) that makes Winprinters accessible by *ANY* OS (not only FreeBSD, but maybe all BSDs and Linusi and Solaris and who knows what else), MICROS~1 would start violently screaming as someone is eating from their cake. Keep in mind that Winprinters are an important target platform for home users who PAY for Windows and PAY for a compatible printer. They pay once every two years or so. MICROS~1 and the printer manufacturers can't stand it if one uses their products too long, as long-term use does imply NO FURTHER SALES. And now imagine that a user can fully use all features of a formerly-Winprinter all-in-one ink pee copier scanner fax machine - where would be his need to buy a Windows to do that as he can now use FreeBSD for free? As far as I understand this, Microsoft doesn't manufacture those winprinters, so why would they screem if those printers were able to run on other platform too? Very simple: Whenever you are using FreeBSD (or any other operating system that is not Windows), you are NOT using Windows. MICROS~1's monopoly is based upon three pillars: Mind share, usage share, and in conclusion, market share. That again is what matters to printer manufacturers, as they are told the secret keys about how to make their printer work on Windows. There is no secret key mindset involved. Peruse the MSDN and and you will find tons of documentation on designing and writing drivers for virtually anything you can imagine that is currently available on the Window's platform. It is to Microsoft's advantage to have as many products as possible operational on their platform. They even have specialized forums to answer technical questions regard driver development. You can even see it the other way: for every winprinter manufactured (or, more precisely, for every windriver sold), Microsoft may get a fixed share due to patent royalties from the manufacturer. So, suppose a manufacturer sells more of his winprinters to BSD/Linux/Solaris/... folks because we had this shim, it would translate to more patent royalties to Microsoft too. I have not been able to locate any documentation that that would substantiate your claim that Microsoft receives any reimbursement/compensation from device manufacturers. Would you please post the source of your claim. That's not logical as the package, the shiny box on the shelf that the customer wants, already contains a CD (or today, a DVD) with drivers for Windows, as this is the PC, and there's nothing else. Users of non-Windows operating systems are a niche market that does not persist in the scope of manufacturers. They are happy selling more and more cheap units (than fewer more expensive units). For them and for MICROS~1 it's a win-win situation, as the customer always pays. Printer manufacturers, or manufacturers of other devices for that matter, sell what the public wants. The public in general wants inexpensive printers. I can guarantee you that if there were no market for it, it would not be offered. I know several users with $50 printers that are used only a few time a month or less. Purchasing a more expensive unit would not be cost effective. Everyone does not need a $2000+ laser printer. Manufacturers are smart enough to fill that niche. So it is in Microsoft's interest not only NOT to kick and scream, but actually to encourage those winprinters by publishing the needed interfaces. It can only increase sales, and they will get more kickbacks from those additional sales. Insignificant amounts, does not pay. The MICROS~1 concept of software ecosystems does not tolerate anything different. Keep in mind the three pillars mentioned before - they would be in danger. Keep in mind that you have failed to produce one shred of documentation to back up your claim of kickbacks. -- Jerry ✌ freebsd.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ signature.asc Description: PGP signature
Re: The nightmarish problem of installing a printer
On Tue, Sep 21, 2010 at 8:43 PM, Jerry freebsd.u...@seibercom.net wrote: On Tue, 21 Sep 2010 19:47:27 +0200 Polytropon free...@edvax.de articulated: On Tue, 21 Sep 2010 19:36:00 +0200, C. P. Ghost cpgh...@cordula.ws wrote: At the moment there was a program (or any other kind of facility) that makes Winprinters accessible by *ANY* OS (not only FreeBSD, but maybe all BSDs and Linusi and Solaris and who knows what else), MICROS~1 would start violently screaming as someone is eating from their cake. Keep in mind that Winprinters are an important target platform for home users who PAY for Windows and PAY for a compatible printer. They pay once every two years or so. MICROS~1 and the printer manufacturers can't stand it if one uses their products too long, as long-term use does imply NO FURTHER SALES. And now imagine that a user can fully use all features of a formerly-Winprinter all-in-one ink pee copier scanner fax machine - where would be his need to buy a Windows to do that as he can now use FreeBSD for free? As far as I understand this, Microsoft doesn't manufacture those winprinters, so why would they screem if those printers were able to run on other platform too? Very simple: Whenever you are using FreeBSD (or any other operating system that is not Windows), you are NOT using Windows. MICROS~1's monopoly is based upon three pillars: Mind share, usage share, and in conclusion, market share. That again is what matters to printer manufacturers, as they are told the secret keys about how to make their printer work on Windows. There is no secret key mindset involved. Peruse the MSDN and and you will find tons of documentation on designing and writing drivers for virtually anything you can imagine that is currently available on the Window's platform. It is to Microsoft's advantage to have as many products as possible operational on their platform. They even have specialized forums to answer technical questions regard driver development. That's exactly my point. Their interfaces are NOT closed or secret, and we could (technically) implement against those interfaces. You can even see it the other way: for every winprinter manufactured (or, more precisely, for every windriver sold), Microsoft may get a fixed share due to patent royalties from the manufacturer. So, suppose a manufacturer sells more of his winprinters to BSD/Linux/Solaris/... folks because we had this shim, it would translate to more patent royalties to Microsoft too. I have not been able to locate any documentation that that would substantiate your claim that Microsoft receives any reimbursement/compensation from device manufacturers. Would you please post the source of your claim. I wrote Microsoft *may* get a fixed share ..., not Microsoft gets a fixed share... That's an assumption, but probably a safe one, due to the way software patents work. Maybe they get paid, or maybe not: it's their decision. Details may (or may not) be included in the Windows DDK EULAs and associated documents. That's not logical as the package, the shiny box on the shelf that the customer wants, already contains a CD (or today, a DVD) with drivers for Windows, as this is the PC, and there's nothing else. Users of non-Windows operating systems are a niche market that does not persist in the scope of manufacturers. They are happy selling more and more cheap units (than fewer more expensive units). For them and for MICROS~1 it's a win-win situation, as the customer always pays. Printer manufacturers, or manufacturers of other devices for that matter, sell what the public wants. The public in general wants inexpensive printers. I can guarantee you that if there were no market for it, it would not be offered. I know several users with $50 printers that are used only a few time a month or less. Purchasing a more expensive unit would not be cost effective. Everyone does not need a $2000+ laser printer. Manufacturers are smart enough to fill that niche. The whole point of winprinters, winmodems etc... is to cut costs for manufacturers. They save (little) money in silicon, and compensate by providing a software Ersatz. There's no Microsoft conspiracy there. It's just unfortunate that we have not yet emulated the environment those software drivers expect, that's all. At least for i386 (and maybe amd64), that should be possible. On ARM, SPARC and other platforms, emulation would be a LOT more difficult, as we would need to hook in a i386 CPU interpreter as well... ;-) So it is in Microsoft's interest not only NOT to kick and scream, but actually to encourage those winprinters by publishing the needed interfaces. It can only increase sales, and they will get more kickbacks from those additional sales. Insignificant amounts, does not pay. The MICROS~1 concept of software ecosystems does not tolerate anything different. Keep in mind the three pillars mentioned
Re: The nightmarish problem of installing a printer
I once used an inkjet printer and almost went broke keeping it fed with ink. I found a refurbished Brother HL-2040 Laser printer at Tiger Direct for $89. It's been running now for almost 3 years and I'm only on my second toner cartridge. To be honest, we're all on a big paperless effort and I rarely print anything these days. With PDF files and new software like Bluebeam Revu I just don't have the need to print much. But since I occassionally do print and the kids need it from time to time for school I have my laser setup on a FreeBSD server which serves all segments in my LAN, including the separate wireless LAN for laptops. CUPS is installed on my server as a dependency for other apps but I don't use it to print. I used to run it with a parallel cable but when I updated my server I had to switch to the USB port on the printer. And I just use simple LPR printing from the windows clients. Now I won't say it was that easy but once it was up and running it's hands free. The FreeBSD server uses ghostscript and a simple filter file which envokes gs. The /etc/printcap file is very simple too. I set the windows clients up to use a postscript printer driver to send the files to the server which it then processes and prints. All is well and I never have any trouble with it. One day soon I will have to purchase another toner cartridge but those are available at several sources. Don't be intimidated by printing under FreeBSD. It's really quite simple unless you're trying to use one of those WinPrinters which will only run with M$. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
I think conspiracy theories miss the point. The reason more printers work on Windows than on FreeBSD is if you don't support Windows, you can't sell printers to 92% of computer users. This is an extremely powerful incentive to spend money on writing Windows drivers. The financial incentive is not really there to spend time writing drivers for FreeBSD. There just aren't enough FreeBSD users who will buy your printer to pay for it. It's simple market economics, unfortunately. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
From cpgh...@cordula.ws Mon Sep 20 19:40:36 2010 Date: Tue, 21 Sep 2010 02:42:22 +0200 Subject: Re: The nightmarish problem of installing a printer From: C. P. Ghost cpgh...@cordula.ws To: Robert Bonomi bon...@mail.r-bonomi.com Cc: freebsd-questions@freebsd.org On Mon, Sep 20, 2010 at 7:16 PM, Robert Bonomi bon...@mail.r-bonomi.com w= rote: Adapting =A0MS-Windows print drivers is not 'practical' either. =A0A wi= ndows print driver is embedd in the O/S KERNEL, =A0with _system_ calls_ (not mere 'library' routines) that implement the 'device-dependant' rendering of layout/formating directions. =A0One then takes the 'opaque object' so produced and sends it (via _another_ set of system calls) to the 'output' function of that same driver. Is that really so? How about writing some emulation shim like ndis(4) for winprinters? Please correct me if I'm wrong, as I'm not a Windows systems programmer, but this is what I'm thinking about. As far as I understand Windows printing, there are two aspects to resolve, given a vendor supplied windriver binary blob: 1/ the windriver gets some (opaque) data from the GDI+ -- maybe a bitmap, with some meta data. 2/ the windriver interprets this data however it sees fit, and then talks t= o the NT kernel (maybe via DLL calls) to send electrical impulses to the printer. If only it _were_ sometine even approaching that simple! Unfortunately, it *isn't*. *IF* UNIX applications produced their output in the form of gdi calls, the approach you descibe _would_ be viable. But they don't. And therein lies all the complications. UNIX applications are almost entirely self-contained with regard to printing, A postscript producting app can make use of a printer-specific 'hints' file that provides 'standardized' means of accessing printer features for which 'implementation details' are left up to the manufacurer -- e.g. paper source tray 'numbering'; do trays start rom zero or one? are they numbered consecutively? and which is which? (just for starter :) Windows passes -individual- objects to the printer driver, which may return a 'rendered' vesion _to_ Windows, which windoes ten merges with otheer rendered objects to produce next phase of the page which eventually goes through the driver a final time, and that bitstring is sent to the hardware. If one has an application that doesn't work that way, and autonomously produces an output data stream of 'some' form, there is a *MAJOR* hurdle in 'reverse engineering' that data stream back to 'objects' that can be fed to the Windows prinding model. as the manufacturer's printer driver expects. If that isn't bad enough, there is no guarantee the the exact steps and sequences of operations that wee used to _produce_that data-strem, even _HAVE_ a direct equivalent inthe Windows printing model. (Heck this problem shows up _witin_ windows with different supported printers, thats _why_ the applicationi has to adjust _its_ output logic to adapt to the way the paritcular printer does things.o When you're 'reverse engineering' from a set of concrete details to a set of abstractions, *what*do*you*do* when you have a sequence of 'details' that doesn't match _any_ of the possible abstractions in the target environment? Begin to get the idea? Devloping the kind of 'shimp' you envision would be a significantly larger, harder, and more time-consuming project than the development of Ghostscript. and by the time the reqired team of engineers got through the years of work involved, the chances are -very- good that nobody would be making 'that kind' of printer driver any more. '95 drivers are not usablewith XP, XP drivers are not compatible With Vista, Vista - Windows 7, I'm not sure about.` ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
From cpgh...@cordula.ws Tue Sep 21 12:34:21 2010 Date: Tue, 21 Sep 2010 19:36:00 +0200 Subject: Re: The nightmarish problem of installing a printer From: C. P. Ghost cpgh...@cordula.ws To: Polytropon free...@edvax.de Cc: Robert Bonomi bon...@mail.r-bonomi.com, freebsd-questions@freebsd.org On Tue, Sep 21, 2010 at 5:43 PM, Polytropon free...@edvax.de wrote: On Tue, 21 Sep 2010 02:42:22 +0200, C. P. Ghost cpgh...@cordula.ws wrote: Keep in mind there are stupid things in the world as patents, intelellectual property, licensing fees and copyrighted secret codes. Yes, that's indeed the real problem. A legal, not a technical one. At the moment there was a program (or any other kind of facility) that makes Winprinters accessible by *ANY* OS (not only FreeBSD, but maybe all BSDs and Linusi and Solaris and who knows what else), MICROS~1 would start violently screaming as someone is eating from their cake. Keep in mind that Winprinters are an important target platform for home users who PAY for Windows and PAY for a compatible printer. They pay once every two years or so. MICROS~1 and the printer manufacturers can't stand it if one uses their products too long, as long-term use does imply NO FURTHER SALES. And now imagine that a user can fully use all features of a formerly-Winprinter all-in-one ink pee copier scanner fax machine - where would be his need to buy a Windows to do that as he can now use FreeBSD for free? As far as I understand this, Microsoft doesn't manufacture those winprinters, so why would they screem if those printers were able to run on other platform too? A) *THEY* developed the interface specifications. They license printer manufacurers to build to it. They _would_ obejct if somebody used their technology to compete against them. B) As it is, to _use_ one of those printers, you *HAVE*TO*BY* a MS O/S. if one could use those printers -without- a MS O/S, that is a 'provable' loss in MS O/S sales -- one sales loss for -each- non-MS system that has such a printer attached. You can even see it the other way: for every winprinter manufactured (or, more precisely, for every windriver sold), Microsoft may get a fixed share due to patent royalties from the manufacturer. So, suppose a manufacturer sells more of his winprinters to BSD/Linux/Solaris/... folks because we had this shim, it would translate to more patent royalties to Microsoft too. So it is in Microsoft's interest not only NOT to kick and scream, but actually to encourage those winprinters by publishing the needed interfaces. It can only increase sales, and they will get more kickbacks from those additional sales. Of course, this consideration is very far away from any technical understanding - as typical for lawpersons who make money from bullshit. :-) That's for sure. ;-) But the basic idea remains: the interfaces on both sides of the windriver binary blobs is pretty stable and (I think) not a secret at all. In that case, I would ask myself: Why hasn't it been done already? If your assumption was right, it would already work. As it currently does not work, I would check your assumption. :-) I don't know why it hasn't been done up to now. After all, this is nothing but an exercise in mapping one set of interfaces onto another set of interfaces. We've done this kind of interface matching with with the Linuxulator, NDIS is another good example, and the Wine guys are doing a great job too. I fail to see a compelling TECHNICAL reason why Windows drivers in general (and windrivers in particular) couldn't be docked to Unix systems. Of course, legal reasons are a different matter. Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Tue, 21 Sep 2010, C. P. Ghost wrote: On Tue, Sep 21, 2010 at 5:43 PM, Polytropon free...@edvax.de wrote: In that case, I would ask myself: Why hasn't it been done already? If your assumption was right, it would already work. As it currently does not work, I would check your assumption. :-) I don't know why it hasn't been done up to now. After all, this is nothing but an exercise in mapping one set of interfaces onto another set of interfaces. We've done this kind of interface matching with with the Linuxulator, NDIS is another good example, and the Wine guys are doing a great job too. I fail to see a compelling TECHNICAL reason why Windows drivers in general (and windrivers in particular) couldn't be docked to Unix systems. Of course, legal reasons are a different matter. Technically possible. The brute-force method would be to run a VM with Windows and the real driver, then just capture input and output. Sure it's tricky, but those are just details. But look at this another way: It's a difficult and demanding programming job, with lots of details that have to be just right, may or may not be easy to find without reverse engineering, and an ongoing support headache that will never end. Kind of like Gutenprint; I wonder if they have a perspective on it. What all this effort achieves is support for the most cost-reduced, bottom-of-the-line printers from every manufacturer. It's probably more effective to put some emphasis in the Handbook on the problems with host-based printers (the polite euphemism for Winprinter). The issue is confused by printers that aren't host-based, but use proprietary PDLs. If someone comes up with a working GDI printer emulation layer, that would make a great port. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Mon, Sep 20, 2010 at 7:16 PM, Robert Bonomi bon...@mail.r-bonomi.com wrote: Adapting MS-Windows print drivers is not 'practical' either. A windows print driver is embedd in the O/S KERNEL, with _system_ calls_ (not mere 'library' routines) that implement the 'device-dependant' rendering of layout/formating directions. One then takes the 'opaque object' so produced and sends it (via _another_ set of system calls) to the 'output' function of that same driver. Is that really so? How about writing some emulation shim like ndis(4) for winprinters? Please correct me if I'm wrong, as I'm not a Windows systems programmer, but this is what I'm thinking about. As far as I understand Windows printing, there are two aspects to resolve, given a vendor supplied windriver binary blob: 1/ the windriver gets some (opaque) data from the GDI+ -- maybe a bitmap, with some meta data. 2/ the windriver interprets this data however it sees fit, and then talks to the NT kernel (maybe via DLL calls) to send electrical impulses to the printer. Now, the data formats of 1/ (GDI stuff) is probably well defined (and therefore published) in gdiplus.dll or something similar and is the same for all windriver blobs. The API/ABI needed to talk to the NT kernel is probably defined in the Windows DDK (or whatever it is called nowadays). So, in both cases, we have stable API/ABI interfaces on both sides of the windriver binary blob: 1/, 2/ at the upper half, and 2/ at the bottom half. So, if we wanted to use those windriver blobs just like in the ndis(4) case, all we need is an emulation shim for both interfaces. Maybe 1/ is already covered by Wine (?) so we could borrow some code from there; and 2/ is basically a matter of mapping the subset of NT calls needed to read from and write to Windows ports to Unix calls to read and write to our Unix devices. Again, I'm no Windows programmer, and it is probably more involved than this. But the basic idea remains: the interfaces on both sides of the windriver binary blobs is pretty stable and (I think) not a secret at all. In the Unix world, printing is handled _externally_ to the kernel. The application must have =its=own=means= of deciding what formatting/layout commands to use -- it _can't_ query the O/S for this info; the O/S simply doesn't have it. Well, it doesn't matter if the windriver shims run as userland daemon or (partially) inside the kernel. The point here is that the windriver - NT, and windriver - GDI+ interface are both stable and not difficult to understand, so both can be emulated. At least theoretically. In practice, it takes some time and effort to get it right, quite obviously. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
Steven Friedrich free...@insightbb.com wrote: Common Unix Printing System certainly sounds as if the intent was to be the ONE thing that is used for printing. Whether they did a good job of it is another question entirely :( I think that you don't fully apreciate the task at hand. When Unix was first invented, there were no laser printers, ink jets, USB, etc. That no one can create a one-size fits all solution OWES to the fact it's simply not always possible to unify disparate designs. They weren't designed to be interoperable. Technology keeps marchng forward. We need to discard all of it eventually. Back in the CP/M and early MS-DOS days, similar doubts were raised regarding display systems. Fortunately, those doubts did not stop some developers from doing what others thought impossible. The results included X11, which has been rather durable for a considerable time. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
From owner-freebsd-questi...@freebsd.org Mon Sep 20 07:11:41 2010 Date: Mon, 20 Sep 2010 05:20:52 -0700 From: per...@pluto.rain.com To: free...@insightbb.com Cc: freebsd-questions@freebsd.org Subject: Re: The nightmarish problem of installing a printer Steven Friedrich free...@insightbb.com wrote: Common Unix Printing System certainly sounds as if the intent was to be the ONE thing that is used for printing. Whether they did a good job of it is another question entirely :( I think that you don't fully apreciate the task at hand. When Unix was first invented, there were no laser printers, ink jets, USB, etc. That no one can create a one-size fits all solution OWES to the fact it's simply not always possible to unify disparate designs. They weren't designed to be interoperable. Technology keeps marchng forward. We need to discard all of it eventually. Back in the CP/M and early MS-DOS days, similar doubts were raised regarding display systems. Fortunately, those doubts did not stop some developers from doing what others thought impossible. The results included X11, which has been rather durable for a considerable time. snort, snicker, gasp ROTFLMAO X works IF AND ONLY IF you have: 1) software that uses and responds to the *PUBLISHED* protocol for communicatins between applications and servers 2) a server that _knows_ how to communicate to the actual display device. either because that device behaves in compliance with a PUBLISHED specification, or because somebody who 'knows the secrets' has provided it. There has been an *EXACTLY* EQUIVALENT solution for printers for more than two decades. It's called PostScript. The problem with supporting modern WinPrinters is that a signficant amount of the 'smarts' necessary to produce a printed page are *NOT* in the printer. they are on the 'driver' that the printer manufacturer supplies (and only as MS-WINDOWS(r) code). They 'know the secrets' (see #2 above), of how to talk to the stupid hardware, and provide a 'standard interface' (the windows device driver) on the 'upstream' side of that software. Unfortunately, that is the *only* interface THEY provide -- you can't talk PostScript to it, you can't talk PCL to it, you cant talk X to it, you can't even talk Plain ASCII to it. Since _nobody_else_ knows the secrets of how to actually communite with that stupid hardware, we _CANNOT_ write a driver to use the device, no matter how much we would like to. *UNLESS* the manufacturer releases the protocol info (see #2 above) for direct device communiction, that is. Some hardware 'speaks' a standard' language, and is plug-and-play interchangable with any other device that speaks the same language, without *ANY* changes (not even a different 'device driver') to whatever it is connected to. As long as the connecting device has *a* driver tat supports that standard. Hardware that speaks a 'proprietary' language requires a 'customized' driver on the host system -- one that knows how to translate from the format that applications use to what the printer understands. *IF* the proprietary language is _documented_ -- i.e. =published= (see #2m above) -- then *anybody* with an incendive to do so *CAN* do so. *WITHOUT* such documentation, from *somewhere*, we are simply =unable= to do the things necessary to utilize that printer. No matter _how- 'attractive it is. Adapting MS-Windows print drivers is not 'practical' either. A windows print driver is embedd in the O/S KERNEL, with _system_ calls_ (not mere 'library' routines) that implement the 'device-dependant' rendering of layout/formating directions. One then takes the 'opaque object' so produced and sends it (via _another_ set of system calls) to the 'output' function of that same driver. In the Unix world, printing is handled _externally_ to the kernel. The application must have =its=own=means= of deciding what formatting/layout commands to use -- it _can't_ query the O/S for this info; the O/S simply doesn't have it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Sat, 18 Sep 2010 23:27:13 +0200 dan gl...@live.com articulated: 2 - HP Photosmart C3180. Once I installed HPLIP and adjusted some permissions I used a hp sw tool to update the CUPS printers' database (all with the __default__ 8.1 kernel). I then Succesfully printed a test page and successfully tested the device as a scanner (blank scanning of the plate). The annoying and computer-time-consuming part was recompiling gtk and qt with CUPS support, that was not the default when I first installed everything. In the end, CUPS was also easy to use to share the 1st printer in our small and simple network. I used the HPLIP port in conjunction with CUPS to get my home c6180 printer working. The FAX portion sucks, and probably always will. I just FAX from one of my Windows machines when the need arises. The printing thought is adequate. I still have not figured out how to get the CF, XD, etc ports to work with FreeBSD. They do work with Windows, so I know that they are working correctly. Luckily, I rarely utilize them anyway. I was wondering what hp sw tool to update the CUPS printers' database you are referring to. -- Jerry ✌ freebsd.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Time and tide wait for no man. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On 19.09.2010 13:34, Jerry wrote: On Sat, 18 Sep 2010 23:27:13 +0200 dangl...@live.com articulated: 2 - HP Photosmart C3180. Once I installed HPLIP and adjusted some permissions I used a hp sw tool to update the CUPS printers' database (all with the __default__ 8.1 kernel). I then Succesfully printed a test page and successfully tested the device as a scanner (blank scanning of the plate). The annoying and computer-time-consuming part was recompiling gtk and qt with CUPS support, that was not the default when I first installed everything. In the end, CUPS was also easy to use to share the 1st printer in our small and simple network. I used the HPLIP port in conjunction with CUPS to get my home c6180 printer working. The FAX portion sucks, and probably always will. I just FAX from one of my Windows machines when the need arises. The printing thought is adequate. I still have not figured out how to get the CF, XD, etc ports to work with FreeBSD. They do work with Windows, so I know that they are working correctly. Luckily, I rarely utilize them anyway. I was wondering what hp sw tool to update the CUPS printers' database you are referring to. Sorry :-) The statement is obviously a bit ambiguous - if not incorrect. I used hp-setup (one of those kde applications included in HPLIP): it tries to discover printers on the usb bus and then a suitable ppd file for the printer one chooses to install. Later, when all the required data are collected it adds the chosen printer in CUPS (like if one selects Add a printer in CUPS - Section Administration). There are many hp tools installed under /usr/local/bin - including a device manager that seems to work fine with kde4. This last one is so in love with this system that even if it has not been asked to do so every time I start up kde I find it always loaded. For a test SD card that I had and I wanted to read: I turned off the printer, inserted the card and then I turned on the printer (stupid, eh ? :-) ). After these huge efforts ;) I found the card (ready to be mounted) under /dev/msdosfs/ . daniele ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Sun, 19 Sep 2010 15:50:32 +0200 dan gl...@live.com articulated: On 19.09.2010 13:34, Jerry wrote: On Sat, 18 Sep 2010 23:27:13 +0200 dangl...@live.com articulated: 2 - HP Photosmart C3180. Once I installed HPLIP and adjusted some permissions I used a hp sw tool to update the CUPS printers' database (all with the __default__ 8.1 kernel). I then Succesfully printed a test page and successfully tested the device as a scanner (blank scanning of the plate). The annoying and computer-time-consuming part was recompiling gtk and qt with CUPS support, that was not the default when I first installed everything. In the end, CUPS was also easy to use to share the 1st printer in our small and simple network. I used the HPLIP port in conjunction with CUPS to get my home c6180 printer working. The FAX portion sucks, and probably always will. I just FAX from one of my Windows machines when the need arises. The printing thought is adequate. I still have not figured out how to get the CF, XD, etc ports to work with FreeBSD. They do work with Windows, so I know that they are working correctly. Luckily, I rarely utilize them anyway. I was wondering what hp sw tool to update the CUPS printers' database you are referring to. Sorry :-) The statement is obviously a bit ambiguous - if not incorrect. I used hp-setup (one of those kde applications included in HPLIP): it tries to discover printers on the usb bus and then a suitable ppd file for the printer one chooses to install. Later, when all the required data are collected it adds the chosen printer in CUPS (like if one selects Add a printer in CUPS - Section Administration). I am familiar with that. I thought that you had discovered something new. There are many hp tools installed under /usr/local/bin - including a device manager that seems to work fine with kde4. This last one is so in love with this system that even if it has not been asked to do so every time I start up kde I find it always loaded. For a test SD card that I had and I wanted to read: I turned off the printer, inserted the card and then I turned on the printer (stupid, eh ? :-) ). After these huge efforts ;) I found the card (ready to be mounted) under /dev/msdosfs/ . Well, I am not about to go through that BS. For the few times that I actually do need that functionality, I will just use my Windows machines. I would file a bug report against this behavior except that I don't have the slightest idea where to file the bug report; i.e., FreeBSD, KDE/Gnome, someone else, all the above? It becomes more than mildly infuriating, although users of Windows do have a nice laugh from time to time. -- Jerry ✌ freebsd.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ Hawkeye's Conclusion: It's not easy to play the clown when you've got to run the whole circus. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Fri, Sep 17, 2010 at 2:45 AM, Chabane HEMDANI hemdani2...@gmail.com wrote: I'm computer science teacher at university of Tizi-ouzou in Algeria. I'm using FreeBSD since 2007 when I discover it by chance when searching in the Web something about Linux. Since that date, I always invited and recommended to my students to install and use this magical and my favorite system. However, all my students retort me that they have a problem of installing their printers. I have so this problem, so I can't tell good-bye definitively to winosor and Linux. I always need them for printing. I've search, read, learn, follow instructions about nearly all the web-documentation about installing a new printer to work under cups without any success. I've an HP Laser Jet 1018 printer and tools given by package print/hplip don't work correctly. I'm using FreeBSD 8.1-RELEASE I've rebuild a kernel without ulpt. I modified my /etc/rc.conf to enable cupsd and hpiod and hpssd. I modified /etc/devfs.rules like suggested by cups (see pkg_info -D cups-base-1.4.4 ). I've made many other configurations like that suggested at http://diablotins.org/index.php/Imprimer,_hplip http://diablotins.org/index.php/Imprimer,_hplip%20 and finally, I've given to my students the wrong answer that no one can print under FreeBSD ! Sometimes, permissions can be the problem: http://farid.hajji.name/blog/2010/02/02/printing-woes-on-freebsd-8-with-cups/ Please where is the problem? Please help me to help others. Please help me to enlarge the FreeBSD users community. Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Fri, 17 Sep 2010 15:10:45 -0700, per...@pluto.rain.com wrote: Polytropon free...@edvax.de wrote: I would like to have ONE thing that is used for printing, and that does support ALL printers ... Isn't that exactly what CUPS is supposed to be? Obviously not. Look at the dependencies, the bloat, and the overall complicatedness of installing a printer. Also, the documentation situation could be better. When dealing with CUPS, foomatic and Gutenprint also enter the field, as well as hp*d stuff that is not included (and needs additional attention). There needs to be lots of action besides CUPS to get it working for certain printers. Try - with CUPS - to install a dotmatrix printer on a parallel port that is currently NOT connected. Last time I checked, this was not possible. Under one point of view you are right: CUPS has been become a quite standard assumption for many programs. If you install them, they will install CUPS (even if you're already running apsfilter or nothing, just pure system's lpd). I see this when printing from Gimp: /usr/local/bin/lpstat: Unable to connect to server, clearly a CUPS message. This also shows that it doesn't integrate with system services that well, but its use seems to be hardcoded into programs. From this opinion, you might get the impression that I don't like CUPS. You are right. But that's no problem as I don't have to use it. :-) I would LOVE to accept CUPS as a versatile part of the FreeBSD infrastructure, if it just wouldn't be that bloated, complicated, generally accepted as a default (in that case, it would have the potential of maybe becoming part of the base system), and finally abandoning the point of view that is has to cater Windows-typical kinds of thinking - ununderstandable, illogical. Of course I assume that you know that printer manufactureres that build home consumer crap are not interested in following established standards and recommendations, so THEY are the primary cause of trouble with printers. This is not CUPS's or FreeBSD's fault. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Sat, 18 Sep 2010 14:15:25 +0200 Polytropon free...@edvax.de articulated: On Fri, 17 Sep 2010 15:10:45 -0700, per...@pluto.rain.com wrote: Polytropon free...@edvax.de wrote: I would like to have ONE thing that is used for printing, and that does support ALL printers ... Isn't that exactly what CUPS is supposed to be? Obviously not. Look at the dependencies, the bloat, and the overall complicatedness of installing a printer. Also, the documentation situation could be better. When dealing with CUPS, foomatic and Gutenprint also enter the field, as well as hp*d stuff that is not included (and needs additional attention). There needs to be lots of action besides CUPS to get it working for certain printers. The same could be said in regards to a lot of other applications. Try - with CUPS - to install a dotmatrix printer on a parallel port that is currently NOT connected. Last time I checked, this was not possible. Under one point of view you are right: CUPS has been become a quite standard assumption for many programs. If you install them, they will install CUPS (even if you're already running apsfilter or nothing, just pure system's lpd). I see this when printing from Gimp: /usr/local/bin/lpstat: Unable to connect to server, clearly a CUPS message. This also shows that it doesn't integrate with system services that well, but its use seems to be hardcoded into programs. From this opinion, you might get the impression that I don't like CUPS. You are right. But that's no problem as I don't have to use it. :-) I would LOVE to accept CUPS as a versatile part of the FreeBSD infrastructure, if it just wouldn't be that bloated, complicated, generally accepted as a default (in that case, it would have the potential of maybe becoming part of the base system), and finally abandoning the point of view that is has to cater Windows-typical kinds of thinking - ununderstandable, illogical. You keep insisting that it is complicated; yet, you fail to specifically state what it is that you are failing to comprehend. Your bloat comment makes no sense at all. What you consider bloat another user might well consider essential. Should we deny them in order to satisfy you? Of course I assume that you know that printer manufactureres that build home consumer crap are not interested in following established standards and recommendations, so THEY are the primary cause of trouble with printers. This is not CUPS's or FreeBSD's fault. What standards? Some arbitrary protocol that you or some other unofficial entity has determined to be the ONLY ACCEPTABLE protocol. It could very well be said that FreeBSD, and perhaps others, are failing to implement the commonly used protocols presently in effect by printer manufacturers. It is THEIR product. They have an ABSOLUTE right to create and distribute THEIR product as THEY see fit. The constant and repetitious rantings that manufacturers are failing to follow some arbitrary, self proclaimed standard is wearing thin. Perhaps if the FreeBSD team decided to jump on the band wagon as opposed to trying to reinvent the wheel, the ease of integrating devices into the system would be simplified and thereby enhance the OS's standing and acceptance. They again, bitching, complaining and blaming others is easier, and unfortunately, the common norm in today's society. Never do for yourself, what you can blame on others has become the new battle call. -- Jerry ✌ freebsd.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ If the rich could pay the poor to die for them, what a living the poor could make! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Sat, 18 Sep 2010 08:50:30 -0400, Jerry freebsd.u...@seibercom.net wrote: On Sat, 18 Sep 2010 14:15:25 +0200 Polytropon free...@edvax.de articulated: Obviously not. Look at the dependencies, the bloat, and the overall complicatedness of installing a printer. Also, the documentation situation could be better. When dealing with CUPS, foomatic and Gutenprint also enter the field, as well as hp*d stuff that is not included (and needs additional attention). There needs to be lots of action besides CUPS to get it working for certain printers. The same could be said in regards to a lot of other applications. That's sadly true. Many years ago, you could pkg_add -r progname and then be sure that you have exactly what you needed. Today, this is often a problem, just think about OpenOffice or Firefox. Mainly X related stuff tends to dissolve, as X itself does. Parts of such software get faster obsoleted than properly docu- mented. I think this is just a normal side-effect of rapid application development, or maybe the natural way of how soft- ware evolves per se, to take advantage of faster and better hardware. You keep insisting that it is complicated; yet, you fail to specifically state what it is that you are failing to comprehend. I mentioned the inability to install a printer that is currently not connected, and in this special case, it was a parallel dotmatrix printer. Your bloat comment makes no sense at all. With today's big hard disks, lots of RAM and fast processors you will be mostly right: Resources are plenty, so the need for efficient programming isn't present anymore. Especially in GUI projects there are abstractions of abstractions of abstractions of libraries depending on libraries depending on libraries - of course intended, as it's much easier to access resources in this way than accessing the bare metal. What you consider bloat another user might well consider essential. That's surely true. Should we deny them in order to satisfy you? I'm speaking out for choice. If tool A isn't able to do the job, there is another tool B that is. But as soon as tool A is mandatory and can't be replaced, subsequent calls will refer to A statically, and B will be out of scope, and out of support, so it won't work anyway. Pop goes the choice. What standards? Some arbitrary protocol that you or some other unofficial entity has determined to be the ONLY ACCEPTABLE protocol. In X, PS is the standard for printing output. For printers itself, there is PS, PCL and ESC/P, to name the three most known ones. But what about printers that need to be injected a firmware before they will be a printer? Or a printer that just as a specific driver for some arbitrary outdated Windows? This is NOT standards. Just imagine every printer manufacturer would make his own plugs. With parallel / Centronics, USB and RJ45 (for network printers) we have standardized connectors. Why can't we have standard printer protocols, which means: Why can't manufactureres just use what's already established? Now you might ask: WHERE is it established? Compare office-class equipment to home consumer crap. You will see that all the expensive printers can do at least PS or PCL (and in most cases both, and maybe some more). They use the standards that are common for those printers. Why not use them for home consumer products as well? Where's the big problem (the BIG problem that causes it NOT to be possible)? Technical answers are welcome. It could very well be said that FreeBSD, and perhaps others, are failing to implement the commonly used protocols presently in effect by printer manufacturers. That could be said, yes. Implementing a protocol requires the protocol to be KNOWN. That might often be a problem. It is THEIR product. They have an ABSOLUTE right to create and distribute THEIR product as THEY see fit. You are right. The conclusion on my side is NOT to by products that are incompatible. The constant and repetitious rantings that manufacturers are failing to follow some arbitrary, self proclaimed standard is wearing thin. As I did prove, it's not about self proclaimed standards, it's about established ones, and they don't seem to be very arbitrary as they are widely spread. You will notice that arbitrary stuff is only present in niche markets, or already died out. Perhaps if the FreeBSD team decided to jump on the band wagon as opposed to trying to reinvent the wheel, the ease of integrating devices into the system would be simplified and thereby enhance the OS's standing and acceptance. I'd love to see that - just an example: If one buys a combined inkpee printer with scanner, attaching it to the system should make an ulpt and uscanner device available. The ulpt will understand PCL or any halfway standardized protocol that can easily be installed to the system as a printer filter (driver). The uscanner will be accessible by (x)sane / scanimage through its connection to
Re: The nightmarish problem of installing a printer
Date: Sat, 18 Sep 2010 08:50:30 -0400
From: Jerry freebsd.u...@seibercom.net
To: FreeBSD freebsd-questions@freebsd.org
Subject: Re: The nightmarish problem of installing a printer
You keep insisting that it is complicated; yet, you fail to
specifically state what it is that you are failing to comprehend. Your
bloat comment makes no sense at all. What you consider bloat
another user might well consider essential. Should we deny them in order
to satisfy you?
CUPS is an overly complex attempt t provide a 'general case' solution a
problem that is, in fact, *INSOLVABLE* in the classical UNIX environment.
CUPS supports a -very- small subset of that 'general case' *beyond* that
which is supported by the traditional, and =far simpler= mechanisms.`o
And, CUPS, itself, addresses -only- one half of te underlying issue, to
start with.
The _one_ thing that CUPS does have going for it is that it allows an
application -- one which is *WRITTEN*AROUND* CUPS capabilities, to output
a 'partial' print file, and have CUPS insert the missing parts. Nice
idea', usable only in CUPS-aware apps. Needless to say, there are very
few of those. So this is a 'benefit' that is of 'no benefit' to most users.
FACT: to print anything more complex than plain ASCII' one has to have
a methodology of conveying 'formatting' information (typeface, point-size,
positioning, orientation, etc.,etc., ad nauseum) to the output device.
IN A MANNER IN WHICH THAT DEVICE UNDERSTANDS. To do -that- requires that
the software -producing- the data stream _know_ what the printer is
capable of, and how to tell it what to do. CUPS does *NOT* include any
means to get that information _to_ the output producing application. Hence
it is only 'half an answer _at_best_. It attempts to 'work around' this
limitation in a half-assed way, by utilizing additional _external_ tools
to convert from a 'standard' means of conveying formatting information
(de jure standards of Postscript, and .PDF, and de facto standard PCL 5)
into the proprietary gobbledygook that a few specific models of printer
require. Don't have one of that handful of devices that (a) don't speak
a standard protocol ,and (b) do speak something that an 'extension' that
you _do_ have can generate, and you *still* can't print to that printer.
UNLESS it does speak a standard protocol -- in which case you don't need
CUPS at all.
Virtually _every_ application for the UNIX world outputs in one of three
formats: Plain ASCII, PostScript / PDF, or HP PCL(PCL5).
{Bleep}ing WinPrinters can't even print ASCII text without it having
been 'translated' by the driver available *only* from the manufacturer,
let alone being able to deal with either of the 'smarter' page formats.
If you want to play in the Unix world, having a printer that is capable
of PLAIN TEXT (ASCII) output is an absolute necessity. If you want
'formatted' output, it is necessary to have 'something' that understands
the protocol that is output by whatever you use to compose in. This can
be a device that natively speaks the language _or_ something for which
a 'translator service exists. In -either- of those situations the
traditional 'lpr/lpd' print spooler is adequate for the task.
What standards? Some arbitrary protocol that you or some other
unofficial entity has determined to be the ONLY ACCEPTABLE protocol. It
could very well be said that FreeBSD, and perhaps others, are failing
to implement the commonly used protocols presently in effect by
printer manufacturers. It is THEIR product. They have an ABSOLUTE right
to create and distribute THEIR product as THEY see fit.
Yup. and if *THEY* choose to market a product that is _unusable_ by part
of their potential market, _that_too_ is their 'right'. It's nobody's
_fault_ that a product *designed* exclusively with the needs of -one-
market segment in mind is 'unusable' in a different market segment. it
_is_, however a 'reality' with which those in that 'different' market
segment must (a) be aware of, and (b) deal with, as a part of deciding
to be _in_ that different market segment.
The constant and repetitious rantings that manufacturers are failing to
follow some arbitrary, self proclaimed standard is wearing thin.
You, Sir, fit the categorization of he who knoweth not, and knoweth not
that he knoweth not, in the sense of the traditional Middle Eastern proverb.
(those unfamiliar with the saying are encouraged to Google the phrase.)
The issue is -not- whether the manufacturer 'follows a standard', but
whether or not the device uses a *PUBLISHED* communications protocol.
IF a device uses a proprietary communications protocol, one can do
the same thing *IF* ( AND *ONLY* *IF*) one has the specifications of
that protocol to work wit. There are disadvantages to writing to a
proprietary protocol -- you can talk only to things that speak that
particular language, where a 'standard' protocol allows one to talk
to any device that speaks the standard language
Re: The nightmarish problem of installing a printer
On 17.09.2010 02:45, Chabane HEMDANI wrote: I'm computer science teacher at university of Tizi-ouzou in Algeria. I'm using FreeBSD since 2007 when I discover it by chance when searching in the Web something about Linux. Since that date, I always invited and recommended to my students to install and use this magical and my favorite system. However, all my students retort me that they have a problem of installing their printers. I have so this problem, so I can't tell good-bye definitively to winosor and Linux. I always need them for printing. I've search, read, learn, follow instructions about nearly all the web-documentation about installing a new printer to work under cups without any success. I've an HP Laser Jet 1018 printer and tools given by package print/hplip don't work correctly. I'm using FreeBSD 8.1-RELEASE I've rebuild a kernel without ulpt. I modified my /etc/rc.conf to enable cupsd and hpiod and hpssd. I modified /etc/devfs.rules like suggested by cups (see pkg_info -D cups-base-1.4.4 ). I've made many other configurations like that suggested at http://diablotins.org/index.php/Imprimer,_hplip http://diablotins.org/index.php/Imprimer,_hplip%20 and finally, I've given to my students the wrong answer that no one can print under FreeBSD ! Please where is the problem? Please help me to help others. Please help me to enlarge the FreeBSD users community. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org :-) Definitely, I am feeling very lucky. We have 2 multi-functional devices here. 1 - Samsung SCX-4100 . Once I installed SPLIX and the CUPS system, I manually added the device to CUPS (using SCX-4200 ppd file) and print 2-3 test pages. For the moment I have not tried scanning. (p.s. for printing, I tried first using lpd and the foomatic filter but the filtering process unexpectedly broke: probably a misconfiguration with foomatic or a bug in it). 2 - HP Photosmart C3180. Once I installed HPLIP and adjusted some permissions I used a hp sw tool to update the CUPS printers' database (all with the __default__ 8.1 kernel). I then Succesfully printed a test page and successfully tested the device as a scanner (blank scanning of the plate). The annoying and computer-time-consuming part was recompiling gtk and qt with CUPS support, that was not the default when I first installed everything. In the end, CUPS was also easy to use to share the 1st printer in our small and simple network. To close, a sincere thank you to all the people directly/indirectly involved in all the branches (mailing lists too :-) ) of this project. daniele ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
Polytropon free...@edvax.de wrote: On Fri, 17 Sep 2010 15:10:45 -0700, per...@pluto.rain.com wrote: Polytropon free...@edvax.de wrote: I would like to have ONE thing that is used for printing, and that does support ALL printers ... Isn't that exactly what CUPS is supposed to be? Obviously not. Er, I said is supposed to be, not is :) Common Unix Printing System certainly sounds as if the intent was to be the ONE thing that is used for printing. Whether they did a good job of it is another question entirely :( ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Saturday 18 September 2010 6:09:57 pm per...@pluto.rain.com wrote: Polytropon free...@edvax.de wrote: On Fri, 17 Sep 2010 15:10:45 -0700, per...@pluto.rain.com wrote: Polytropon free...@edvax.de wrote: I would like to have ONE thing that is used for printing, and that does support ALL printers ... Isn't that exactly what CUPS is supposed to be? Obviously not. Er, I said is supposed to be, not is :) Common Unix Printing System certainly sounds as if the intent was to be the ONE thing that is used for printing. Whether they did a good job of it is another question entirely :( ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org I think that you don't fully apreciate the task at hand. When Unix was first invented, there were no laser printers, ink jets, USB, etc. That no one can create a one-size fits all solution OWES to the fact it's simply not always possible to unify disparate designs. They weren't designed to be interoperable. Technology keeps marchng forward. We need to discard all of it eventually. If you want easy, peasy printing success under *nix, choose a Postscript capable printer that has a network connection and supports IPP. Make sure the priner has a .ppd file available for it. You can get this file for free before buying the printer itself. I use (and love) my Brother HL-6050DN mono Laser. I'd like to get a Brother color laser, but it has to wait... -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Sat, 18 Sep 2010 15:09:57 -0700, per...@pluto.rain.com wrote: Polytropon free...@edvax.de wrote: On Fri, 17 Sep 2010 15:10:45 -0700, per...@pluto.rain.com wrote: Polytropon free...@edvax.de wrote: I would like to have ONE thing that is used for printing, and that does support ALL printers ... Isn't that exactly what CUPS is supposed to be? Obviously not. Er, I said is supposed to be, not is :) Common Unix Printing System certainly sounds as if the intent was to be the ONE thing that is used for printing. Whether they did a good job of it is another question entirely :( It seems that you are mis-interpreting the C in CUPS. :-) The Common refers to the fact - and this really is an advantage - that similar versions of CUPS can be used across many UNIX and Linux operating systems; there's also support for the big desktop environ- ments KDE and Gnome. Even Mac OS X uses it. This makes it common. In fact, it's great that one can use PPD files on all those systems that have CUPS, but the *need* to refer to arbitrary external files (instead of using what's installed - like gs) makes it less useful, but still powerful, and sadly very complex and sometimes complicated. Maybe this is the price of being common to many different systems... For further autopsy of Common refer to the C in CDE. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Fri, 17 Sep 2010 01:45:54 +0100 Chabane HEMDANI hemdani2...@gmail.com wrote: I've search, read, learn, follow instructions about nearly all the web-documentation about installing a new printer to work under cups without any success. I've an HP Laser Jet 1018 printer and tools given by package print/hplip don't work correctly. I'm using FreeBSD 8.1-RELEASE I've rebuild a kernel without ulpt. I modified my /etc/rc.conf to enable cupsd and hpiod and hpssd. I modified /etc/devfs.rules like suggested by cups (see pkg_info -D cups-base-1.4.4 ). I've made many other configurations like that suggested at http://diablotins.org/index.php/Imprimer,_hplip http://diablotins.org/index.php/Imprimer,_hplip%20 and finally, I've given to my students the wrong answer that no one can print under FreeBSD ! Which is wrong, all you need is a printer, that is _supported_. Please where is the problem? The LaserJet 1018 uses another protocol, so you need aditional software. Take a look at these sites: http://www.openprinting.org/printer/HP/HP-LaserJet_1018 http://foo2zjs.rkkda.com/ Before buying the next printer, see whether or not it is supported by Cups http://www.cups.org/ppd.php . Same goes for your students. Andreas -- GnuPG key : 0x2A573565|http://www.gnupg.org/howtos/de/ Fingerprint: 925D 2089 0BF9 8DE5 9166 33BB F0FD CD37 2A57 3565 pgpy4L8v397s2.pgp Description: PGP signature
Re: The nightmarish problem of installing a printer
On Fri, 17 Sep 2010 01:45:54 +0100 Chabane HEMDANI hemdani2...@gmail.com wrote: I've search, read, learn, follow instructions about nearly all the web-documentation about installing a new printer to work under cups without any success. I've an HP Laser Jet 1018 printer and tools given by package print/hplip don't work correctly. I'm using FreeBSD 8.1-RELEASE I've rebuild a kernel without ulpt. I modified my /etc/rc.conf to enable cupsd and hpiod and hpssd. I modified /etc/devfs.rules like suggested by cups (see pkg_info -D cups-base-1.4.4 ). I've made many other configurations like that suggested at http://diablotins.org/index.php/Imprimer,_hplip http://diablotins.org/index.php/Imprimer,_hplip%20 and finally, I've given to my students the wrong answer that no one can print under FreeBSD ! Which is wrong, all you need is a printer, that is _supported_. Please where is the problem? The LaserJet 1018 uses another protocol, so you need aditional software. Take a look at these sites: http://www.openprinting.org/printer/HP/HP-LaserJet_1018 http://foo2zjs.rkkda.com/ Before buying the next printer, see whether or not it is supported by Cups http://www.cups.org/ppd.php . Same goes for your students. Andreas -- GnuPG key : 0x2A573565|http://www.gnupg.org/howtos/de/ Fingerprint: 925D 2089 0BF9 8DE5 9166 33BB F0FD CD37 2A57 3565 I got an HP Laser 1018 - works perfectly fine using the foo2zjs drivers, and I do believe ultp0. I can send you my configs once I get home if you want. The real pain which I keep forgetting after a reload or on new pc, was having to initialize [cat firmware /dev/ulpt0] each time the computer is rebooted [ie @reboot in cron]. ]Peter[ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On 9/17/2010 2:14 AM, Peter wrote: On Fri, 17 Sep 2010 01:45:54 +0100 Chabane HEMDANIhemdani2...@gmail.com wrote: I've search, read, learn, follow instructions about nearly all the web-documentation about installing a new printer to work under cups without any success. I've an HP Laser Jet 1018 printer and tools given by package print/hplip don't work correctly. I'm using FreeBSD 8.1-RELEASE I've rebuild a kernel without ulpt. I modified my /etc/rc.conf to enable cupsd and hpiod and hpssd. I modified /etc/devfs.rules like suggested by cups (see pkg_info -D cups-base-1.4.4 ). I've made many other configurations like that suggested at http://diablotins.org/index.php/Imprimer,_hplip http://diablotins.org/index.php/Imprimer,_hplip%20 and finally, I've given to my students the wrong answer that no one can print under FreeBSD ! Which is wrong, all you need is a printer, that is _supported_. Please where is the problem? The LaserJet 1018 uses another protocol, so you need aditional software. Take a look at these sites: http://www.openprinting.org/printer/HP/HP-LaserJet_1018 http://foo2zjs.rkkda.com/ Before buying the next printer, see whether or not it is supported by Cups http://www.cups.org/ppd.php . Same goes for your students. Andreas -- GnuPG key : 0x2A573565|http://www.gnupg.org/howtos/de/ Fingerprint: 925D 2089 0BF9 8DE5 9166 33BB F0FD CD37 2A57 3565 I got an HP Laser 1018 - works perfectly fine using the foo2zjs drivers, and I do believe ultp0. I can send you my configs once I get home if you want. The real pain which I keep forgetting after a reload or on new pc, was having to initialize [cat firmware /dev/ulpt0] each time the computer is rebooted [ie @reboot in cron]. ]Peter[ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org The issue I tend to get is cups doesnt have permission to access the /dev/ulpt... i have to add an entry in devfs.conf to all it to print ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Fri, Sep 17, 2010 at 01:45:54AM +0100, Chabane HEMDANI wrote: I'm computer science teacher at university of Tizi-ouzou in Algeria. I'm using FreeBSD since 2007 when I discover it by chance when searching in the Web something about Linux. Since that date, I always invited and recommended to my students to install and use this magical and my favorite system. However, all my students retort me that they have a problem of installing their printers. I have so this problem, so I can't tell good-bye definitively to winosor and Linux. I always need them for printing. I've search, read, learn, follow instructions about nearly all the web-documentation about installing a new printer to work under cups without any success. I've an HP Laser Jet 1018 printer and tools given by package print/hplip don't work correctly. I'm using FreeBSD 8.1-RELEASE I've rebuild a kernel without ulpt. I modified my /etc/rc.conf to enable cupsd and hpiod and hpssd. I modified /etc/devfs.rules like suggested by cups (see pkg_info -D cups-base-1.4.4 ). I've made many other configurations like that suggested at http://diablotins.org/index.php/Imprimer,_hplip http://diablotins.org/index.php/Imprimer,_hplip%20 and finally, I've given to my students the wrong answer that no one can print under FreeBSD ! Please where is the problem? Please help me to help others. Please help me to enlarge the FreeBSD users community. Many congratulations on your efforts to promote FreeBSD! I'm not going to tell you how to print with CUPS as it's too complicated and fragile for my liking. Have you thought about using lpd(8)? If your printer can understand Postscript (and I believe HP Laserjets can) then this can be a fairly simple process as you just send the raw PS to the printer with lpr(1) via a spool and filter. My filter: #!/bin/sh cat - echo \f # and my printcap(5) isn't overly complicated either and the format is well documented in it's manpage. Most Unix applications can produce Postscript or PDF (which can be converted to PS with ps2pdf which comes with Ghostscript) and LaTeX can produce PS with dvips. I recommend LaTeX for all users, especially university based users who are going to produce thesis/technical docs. Anyway, just a thought. Setting up lpd is documented in the Handbook of course. If your printer can't speak Postscript then you have to use Ghostscript and something like apsfilter with lpd. Regards, -- Frank Contact info: http://www.shute.org.uk/misc/contact.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Fri, 17 Sep 2010, Frank Shute wrote: I'm not going to tell you how to print with CUPS as it's too complicated and fragile for my liking. Agreed. Have you thought about using lpd(8)? If your printer can understand Postscript (and I believe HP Laserjets can) then this can be a fairly simple process as you just send the raw PS to the printer with lpr(1) via a spool and filter. My filter: #!/bin/sh cat - echo \f # That might not even be necessary; it just adds a formfeed to the job, which PostScript doesn't need. Helps with some PCL jobs, and PS printers usually do PCL also. and my printcap(5) isn't overly complicated either and the format is well documented in it's manpage. My lpd doc is an attempt to put everything about lpd in one place, with simple but complete examples: http://www.wonkity.com/~wblock/docs/html/lpdprinting.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Fri, 17 Sep 2010 18:10:56 +0100, Frank Shute fr...@shute.org.uk wrote: I'm not going to tell you how to print with CUPS as it's too complicated and fragile for my liking. If you have a printer that understands at least SOME standards, maybe you want to look at apsfilter instead of CUPS; apsfilter is a lightweight, but still powerful collection of printer filters that supports many standards. Have you thought about using lpd(8)? If your printer can understand Postscript (and I believe HP Laserjets can) then this can be a fairly simple process as you just send the raw PS to the printer with lpr(1) via a spool and filter. If the printer can understand PCL, as many HP Laserjet products do (at least the professional ones from office class product lines), you can also use apsfilter for that. In this case, it's even to be considered an overhead as apsfilter uses gs (ghostscript) to turn the PS input into PCL. A short read of man gs should give you all you need to know about how to use PCL for your printer. Oh, and professional office-class printers usually are networked printers, so no need to mess with silly USB. :-) Most Unix applications can produce Postscript or PDF (which can be converted to PS with ps2pdf which comes with Ghostscript) and LaTeX can produce PS with dvips. Postscript is *the* default output format for printing in UNIX in general, as well as in X. For LaTeX, there's pdflatex to produce PDF output directly, a very useful tool for automated document production and printing. (Yes, you don't need Acrobat Reader to print PDF files, you can just use lpr *.pdf to get a stack of PDF files printed without any further interaction.) I recommend LaTeX for all users, especially university based users who are going to produce thesis/technical docs. Absolutely. If your printer can't speak Postscript then you have to use Ghostscript and something like apsfilter with lpd. As I mentioned. Sadly, there nowadays is a whole bunch of printing stuff, obsoleting one unified system that is to be used for printing. What comes to my mind? Of course CUPS, hpijs, Gutenprint, Foomatic, Gimp-print, several deamons and datafiles... what a mess - it's almost like WIndows. Sorry. I would like to have ONE thing that is used for printing, and that does support ALL printers, and that does not force the user to search the web (bah!) for some arbitrary binary files. Of course, that's what printer manufacturers seem to want: Incompatible, non-standard and complicated crap, requiring bloated software to run. That's not how UNIX experience should be. My take: Whenever possible, get a professional printer. Think BEFORE you buy it. Even used (!) office-class hardware is acceptable. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
On Fri, Sep 17, 2010 at 06:10:56PM +0100, Frank Shute wrote: On Fri, Sep 17, 2010 at 01:45:54AM +0100, Chabane HEMDANI wrote: I'm computer science teacher at university of Tizi-ouzou in Algeria. I'm using FreeBSD since 2007 when I discover it by chance when searching in the Web something about Linux. Since that date, I always invited and recommended to my students to install and use this magical and my favorite system. However, all my students retort me that they have a problem of installing their printers. I have so this problem, so I can't tell good-bye definitively to winosor and Linux. I always need them for printing. I've search, read, learn, follow instructions about nearly all the web-documentation about installing a new printer to work under cups without any success. I've an HP Laser Jet 1018 printer and tools given by package print/hplip don't work correctly. According to http://www.openprinting.org/printer/HP/HP-LaserJet_1018 it is best to use the foo2zjs driver: http://foo2zjs.rkkda.com/ But it only works in black and white. Please where is the problem? Printers these days are by-and-large built for MS windoze, without much thought for other operating systems. So they tend to use unpublished communications protocols or only work with the driver that works on windoze. When shopping for a printer, preferably look for one that understands the PostScript page description language. Those will work in FreeBSD and Linux without problems. These tend to be more high-end models, and may be more expensive when new. Secondhand they are probably more affordable, especially for students! If that is not an option, try for a printer that is supported by ghostscript (the print/ghostscript8 port) You can see the printers it supports by running 'make config' in /usr/ports/print/ghostscript8. Printers that use the PCL (HP) or ESC/P (epson) printing protocols should work without problems. Alternatively look for a printer that is supported by the gutenprint driver; http://www.openprinting.org/driver/gutenprint/ When you are thinking about buying a certain model of printer, _always_ check the openprinting database to see if it will work _before_ buying it: http://www.openprinting.org/printers Postscript (and I believe HP Laserjets can) then this can be a fairly Some do, particularly high-end models. Most consumer-oriented stuff does not. Hope this helps! Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgp2wBiEVoDvi.pgp Description: PGP signature
Re: The nightmarish problem of installing a printer
Polytropon free...@edvax.de wrote: I would like to have ONE thing that is used for printing, and that does support ALL printers ... Isn't that exactly what CUPS is supposed to be? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
The nightmarish problem of installing a printer
I'm computer science teacher at university of Tizi-ouzou in Algeria. I'm using FreeBSD since 2007 when I discover it by chance when searching in the Web something about Linux. Since that date, I always invited and recommended to my students to install and use this magical and my favorite system. However, all my students retort me that they have a problem of installing their printers. I have so this problem, so I can't tell good-bye definitively to winosor and Linux. I always need them for printing. I've search, read, learn, follow instructions about nearly all the web-documentation about installing a new printer to work under cups without any success. I've an HP Laser Jet 1018 printer and tools given by package print/hplip don't work correctly. I'm using FreeBSD 8.1-RELEASE I've rebuild a kernel without ulpt. I modified my /etc/rc.conf to enable cupsd and hpiod and hpssd. I modified /etc/devfs.rules like suggested by cups (see pkg_info -D cups-base-1.4.4 ). I've made many other configurations like that suggested at http://diablotins.org/index.php/Imprimer,_hplip http://diablotins.org/index.php/Imprimer,_hplip%20 and finally, I've given to my students the wrong answer that no one can print under FreeBSD ! Please where is the problem? Please help me to help others. Please help me to enlarge the FreeBSD users community. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: The nightmarish problem of installing a printer
Hello, First things first, does cups see your printer ? Do you use lpradmin or the web-interface for adding the printer ? Second, did you try using http://foo2qpdl.rkkda.com/ for the driver ? Third, can you post error logs ? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
