Re: MFC 7840W under CUPS
On Sun, 12 Feb 2012 10:00:38 -0500, Jerry wrote: It appears that ps is no-longer the format of choice but is being replaced by PDF, a format that is natively supported by many printers. Jerry, I wanted to point out that PS still seems to be the format that _applications_ use as output format for printing. Even though especially office applications (such as Abiword or LibreOffice) have a built-in PDF file generator, the printing output that is sent to the printing subsystem (lpr, CUPS, whatever) is in PS format and gets converted to what the printer needs by the proper printer filter (driver). The print to file output method typically creates PS, at least on UNIX, Linux, MacOS X and other operating system families. If printers would natively support PDF data instead of unknown arbitrary commands to move the printing head - things would be MUCH LESS complicated on the OS's side. Data just needs to be generated in PDF natively, or converted from PS to PDF (simple task) by the printer filter, and then just sent to a specific network address (just as netcat could do). That would nearly eliminate the need for printer drivers I think. The only thing that comes to my mind is... how does it handle duplexing and other printer-HARDWARE specific things? Can they also be coded in a PDF file? Really, I like the approach of having PDF as a universal printer language (even though it's not 100% safe from a security point of view, but that doesn't matter on the home consumer market anyway). It would remove any need complicated things like (in my opinion) the CUPS configuration. You just need to enter the IP of the printer - done; and it doesn't even matter of this is a wired or wireless connection! Maybe even lowest-end USB devices can accept a PDF data stream... Think about that: % netcat 192.168.123.456 /tmp/printing.pdf or even % cat /tmp/inkpee.pdf /dev/ulpt0 to make the printer start printing... With standardized PDF instructions, there would be no need for artificial OS barriers. PDF is known. No need to port any drivers, to create wrappers or jump though hoops. Note that the system's DEFAULT printing facility (the printer spooler) would be a perfect means to plug in. Printer filters could be easily implemented, i. e. only _one_ filter needs to be present: one that converts an application's PS to PDF and the send it to the printer's local port or IP address. All the parts needed for that task are already present (and have been for many years). Would be interesting to see how this develops. Thanks for sharing that info, sounds really 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: MFC 7840W under CUPS
On 02/17/12 23:14, Polytropon wrote: On Sun, 12 Feb 2012 10:00:38 -0500, Jerry wrote: It appears that ps is no-longer the format of choice but is being replaced by PDF, a format that is natively supported by many printers. Jerry, I wanted to point out that PS still seems to be the format that _applications_ use as output format for printing. Even though especially office applications (such as Abiword or LibreOffice) have a built-in PDF file generator, the printing output that is sent to the printing subsystem (lpr, CUPS, whatever) is in PS format and gets converted to what the printer needs by the proper printer filter (driver). The print to file output method typically creates PS, at least on UNIX, Linux, MacOS X and other operating system families. If printers would natively support PDF data instead of unknown arbitrary commands to move the printing head - things would be MUCH LESS complicated on the OS's side. Data just needs to be generated in PDF natively, or converted from PS to PDF (simple task) by the printer filter, and then just sent to a specific network address (just as netcat could do). That would nearly eliminate the need for printer drivers I think. The only thing that comes to my mind is... how does it handle duplexing and other printer-HARDWARE specific things? Can they also be coded in a PDF file? Really, I like the approach of having PDF as a universal printer language (even though it's not 100% safe from a security point of view, but that doesn't matter on the home consumer market anyway). It would remove any need complicated things like (in my opinion) the CUPS configuration. You just need to enter the IP of the printer - done; and it doesn't even matter of this is a wired or wireless connection! Maybe even lowest-end USB devices can accept a PDF data stream... Think about that: % netcat 192.168.123.456 /tmp/printing.pdf or even % cat /tmp/inkpee.pdf /dev/ulpt0 to make the printer start printing... With standardized PDF instructions, there would be no need for artificial OS barriers. PDF is known. No need to port any drivers, to create wrappers or jump though hoops. Note that the system's DEFAULT printing facility (the printer spooler) would be a perfect means to plug in. Printer filters could be easily implemented, i. e. only _one_ filter needs to be present: one that converts an application's PS to PDF and the send it to the printer's local port or IP address. All the parts needed for that task are already present (and have been for many years). Would be interesting to see how this develops. Thanks for sharing that info, sounds really good. PDF is not exactly PS, but it does use a subset of the instructions. As near as I can tell this is how they're using it, as it is only 1.7 or so onwards. The other thing you will notice is that its mostly on MFC's, so I believe they're using the PS chipset to encode a scanned doc to PDF; I'm not sure it works the other way around, and I may even be wrong about what they're doing but I think it is very suspect. A PS chipset is only an interpreter - it cannot normally encode PS, only read a PS stream and rasterise it. But they may have extended it in only this case. As for printing PDF, maybe... time will only tell. ___ 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: MFC 7840W under CUPS
On Fri, 17 Feb 2012 23:33:33 +1000, Da Rock wrote: PDF is not exactly PS, but it does use a subset of the instructions. That's correct, but both formats share essential parts of functionality. Conversion between them is relatively easy. The other thing you will notice is that its mostly on MFC's, so I believe they're using the PS chipset to encode a scanned doc to PDF; I'm not sure it works the other way around, and I may even be wrong about what they're doing but I think it is very suspect. Yes, PDF output of scanned documents (even multi-page ones) seems to be standard today (which is mostly a welcome solution for storing and re-printing scanned documents). A PS chipset is only an interpreter - it cannot normally encode PS, only read a PS stream and rasterise it. But they may have extended it in only this case. As for printing PDF, maybe... time will only tell. I held a short lecture about PS many years ago. If I remember my own words correctly, the PS circuit in a printer is a little processor complex that processes the PS programming language to do rasterization (from vector data or embedded pixel objects), it could do calculations, some transformations (like rotation), some other functions (like repeating the output n times, use or not use the duplexer etc. depending on the printer's hardware). If this facility could be used to generate data and send it back through the network interface, or keep it in local storage so network access can pick it up (e. g. by FTP, NFS, CIFS/SMB), things would be easy as those mechanisms can be kept internally in the printer without requiring arbitrary drivers to make things work. -- 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: MFC 7840W under CUPS
On 02/17/12 23:33, Da Rock wrote: On 02/17/12 23:14, Polytropon wrote: On Sun, 12 Feb 2012 10:00:38 -0500, Jerry wrote: It appears that ps is no-longer the format of choice but is being replaced by PDF, a format that is natively supported by many printers. Jerry, I wanted to point out that PS still seems to be the format that _applications_ use as output format for printing. Even though especially office applications (such as Abiword or LibreOffice) have a built-in PDF file generator, the printing output that is sent to the printing subsystem (lpr, CUPS, whatever) is in PS format and gets converted to what the printer needs by the proper printer filter (driver). The print to file output method typically creates PS, at least on UNIX, Linux, MacOS X and other operating system families. If printers would natively support PDF data instead of unknown arbitrary commands to move the printing head - things would be MUCH LESS complicated on the OS's side. Data just needs to be generated in PDF natively, or converted from PS to PDF (simple task) by the printer filter, and then just sent to a specific network address (just as netcat could do). That would nearly eliminate the need for printer drivers I think. The only thing that comes to my mind is... how does it handle duplexing and other printer-HARDWARE specific things? Can they also be coded in a PDF file? Really, I like the approach of having PDF as a universal printer language (even though it's not 100% safe from a security point of view, but that doesn't matter on the home consumer market anyway). It would remove any need complicated things like (in my opinion) the CUPS configuration. You just need to enter the IP of the printer - done; and it doesn't even matter of this is a wired or wireless connection! Maybe even lowest-end USB devices can accept a PDF data stream... Think about that: % netcat 192.168.123.456 /tmp/printing.pdf or even % cat /tmp/inkpee.pdf /dev/ulpt0 to make the printer start printing... With standardized PDF instructions, there would be no need for artificial OS barriers. PDF is known. No need to port any drivers, to create wrappers or jump though hoops. Note that the system's DEFAULT printing facility (the printer spooler) would be a perfect means to plug in. Printer filters could be easily implemented, i. e. only _one_ filter needs to be present: one that converts an application's PS to PDF and the send it to the printer's local port or IP address. All the parts needed for that task are already present (and have been for many years). Would be interesting to see how this develops. Thanks for sharing that info, sounds really good. PDF is not exactly PS, but it does use a subset of the instructions. As near as I can tell this is how they're using it, as it is only 1.7 or so onwards. The other thing you will notice is that its mostly on MFC's, so I believe they're using the PS chipset to encode a scanned doc to PDF; I'm not sure it works the other way around, and I may even be wrong about what they're doing but I think it is very suspect. A PS chipset is only an interpreter - it cannot normally encode PS, only read a PS stream and rasterise it. But they may have extended it in only this case. As for printing PDF, maybe... time will only tell. What I forgot to add is that it would be no more difficult to print PDF as it is to print PS - you'd use the same functions but a slight difference in the quantity of data. I have yet to see a printer that will do it though ___ 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: MFC 7840W under CUPS
On Fri, 17 Feb 2012 14:14:47 +0100 Polytropon articulated: Think about that: % netcat 192.168.123.456 /tmp/printing.pdf I can do either: nc 192.168.1.100 9100 /tmp/print.pdf or nc 192.168.1.100 9100 /tmp/print.ps right now without any problems. If you looked at the http://www.linuxfoundation.org/collaborate/workgroups/openprinting page, and you apparently did, then you will have noticed the Making Printing Just Work concept that I suggested several months ago, only to be met by the usual naysayers claiming it would never happen or be feasible. Obviously, these are the same individuals who claimed that the bumblebee could not fly. If you have not all ready checked out http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format, you might want to give it a quick once over. It is very informative. -- Jerry ♔ 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: MFC 7840W under CUPS
On 02/17/12 23:57, Polytropon wrote: On Fri, 17 Feb 2012 23:33:33 +1000, Da Rock wrote: PDF is not exactly PS, but it does use a subset of the instructions. That's correct, but both formats share essential parts of functionality. Conversion between them is relatively easy. The other thing you will notice is that its mostly on MFC's, so I believe they're using the PS chipset to encode a scanned doc to PDF; I'm not sure it works the other way around, and I may even be wrong about what they're doing but I think it is very suspect. Yes, PDF output of scanned documents (even multi-page ones) seems to be standard today (which is mostly a welcome solution for storing and re-printing scanned documents). A PS chipset is only an interpreter - it cannot normally encode PS, only read a PS stream and rasterise it. But they may have extended it in only this case. As for printing PDF, maybe... time will only tell. I held a short lecture about PS many years ago. If I remember my own words correctly, the PS circuit in a printer is a little processor complex that processes the PS programming language to do rasterization (from vector data or embedded pixel objects), it could do calculations, some transformations (like rotation), some other functions (like repeating the output n times, use or not use the duplexer etc. depending on the printer's hardware). If this facility could be used to generate data and send it back through the network interface, or keep it in local storage so network access can pick it up (e. g. by FTP, NFS, CIFS/SMB), things would be easy as those mechanisms can be kept internally in the printer without requiring arbitrary drivers to make things work. RIP processors do/did that. They're normally an external computer system designed to do just that: act as a print server (sometimes a bit like CUPS with a web interface) and you can store, hold, print jobs. Graphics organisations still use them, but since processors are so fast these days they don't always bother with some printers. With these functions, the operator could receive a print job and direct it to whatever printer was available/best suited and run it. Some used them in the larger print shops for online printing from major contracts to automate the processing of jobs (immediate/monthly/weekly, etc). You could also send the ripped file (or a PS encoded one) anywhere you want as well. The files were normally sent RAW and processed on the RIP to whatever was needed or wanted, and there was PS on the machine. These things were hooked up directly to the printer (no network - could be though - just a scsi connection directly to the print engine) so they had no real need for PS except to encode it. The ones I worked on were NT based and some linux based ones. Fun times... :) ___ 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: MFC 7840W under CUPS
On 02/18/12 00:22, Jerry wrote: On Fri, 17 Feb 2012 14:14:47 +0100 Polytropon articulated: Think about that: % netcat 192.168.123.456 /tmp/printing.pdf I can do either: nc 192.168.1.100 9100 /tmp/print.pdf or nc 192.168.1.100 9100 /tmp/print.ps right now without any problems. If you looked at the http://www.linuxfoundation.org/collaborate/workgroups/openprinting page, and you apparently did, then you will have noticed the Making Printing Just Work concept that I suggested several months ago, only to be met by the usual naysayers claiming it would never happen or be feasible. Obviously, these are the same individuals who claimed that the bumblebee could not fly. You realise that you could do this with PS for ages? Nothing has changed as such in years... Finding a printer that accepts PS? That was the problem. Mostly the issue is with GDI or some other propietry printer. If the manufacturers accept a standard (and that means M$ needs to stop interfering, which it seems they now are and are moving away from GDI themselves) then it will all just work. PCL isn't much different, and most respectable printers have been using that since the beginning of time, or thereabouts, just more of them now. You will find it hard to convince graphics to give up PS though, its pretty deeply rooted in their culture :) If you have not all ready checked out http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format, you might want to give it a quick once over. It is very informative. ___ 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: MFC 7840W under CUPS
On Sat, 11 Feb 2012 23:17:29 +0100 Polytropon articulated: On Sun, 05 Feb 2012 21:21:59 +0100, Ouyang Xueyu wrote: Hello, I have Freebsd 8.2 and CUPS installed and try to print on my Brother MFC 7840W printer. The printer is accessible by a static IP address, is configured in CUPS but everytime I only get blank pages when I'm trying to print. Does anybody know a solution for this behaviour? The technical specification of the printer at http://www.brother-usa.com/mfc/modeldetail.aspx?PRODUCTID=MFC7840W#.TzbkwOsS-Jo indicates that it does understand PCL. Just for testing, you could try to _not_ use CUPS and send PCL to the printer directly, either by the system's spooling mechanism (which seems to be considered depricated now as the big desktop environments and some stand-alonge applications consider CUPS the only printing interface, which they seem to hardcode into the programs) or by the direct way, using its network connection (which is a good thing, better than USB in my opinion). Really - if the specifications say the printer can do PCL and has some kind of PS, why should it be complicated to get that excellent capabilities working with CUPS? Here is a simple test that you can use: First print something from an application (web browser, text processing program, image manipulator etc.), but send the output to a file. Most print dialogs offer a print to file choice. Save the result to /tmp/print.ps - I'll use this name for demonstration, you can use any other name. Then verify what you've printed to be a PostScript file. % file /tmp/print.ps /tmp/print.ps: PostScript document text conforming DSC level 3. You can verify the content to be printed using any PS viewer, e. g. gv or gs, or whatever comes with your desktop environment. If it is a valid PS file, you can do two things: a) Test if the printer's BR-Script3 is PS-compatible: % nc 192.168.123.456 9100 /tmp/print.ps Let's assume that 192.168.123.456 is the IP of the printer. :-) Let's also assume that port 9100 is the port where the printer accepts jobs. Some printers use different ports for their different personalities. See the documentation which port to use. If unsure, leave it blank. b) Test if the printer does understand PCL. Same assumptions apply. % printf \033k2G | nc 192.168.123.456 9100 % gs -q -dBATCH -dNOPAUSE -dPARANOIDSAFER -dSAFER \ -sDEVICE=ljet4 -sPAPERSIZE=a4 -r600x600 \ -sOutputFile=- /tmp/print.ps | nc 192.168.123.456 9100 You can see that this test specifies a ljet4 printer driver. This refers to the HP Laserjet 4 and 4000 families, but it does produce PCL, so it should be fine. Report back if this works (i. e. _which_ of them, and if not, with which unexpected results). If it does work, my suggestion would be to dump CUPS and use the system's default mechanism with a man made printer filter. It's very easy. Easier than dealing with the CUPS blackbox in my opinion... I can accomplish this on my Brother MFC-9560CDW saving in either PS or PDF format. In fact, it appears that the industry is moving away from the ps format and towards the pdf format. However, none of this explains why CUPS has so thoroughly screwed up the printing process, nor why it should demand so much user intervention to set up a printer that on most modern operating systems is trivial at best. -- Jerry ♔ 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: MFC 7840W under CUPS
On 02/12/12 23:33, Jerry wrote: On Sat, 11 Feb 2012 23:17:29 +0100 Polytropon articulated: On Sun, 05 Feb 2012 21:21:59 +0100, Ouyang Xueyu wrote: Hello, I have Freebsd 8.2 and CUPS installed and try to print on my Brother MFC 7840W printer. The printer is accessible by a static IP address, is configured in CUPS but everytime I only get blank pages when I'm trying to print. Does anybody know a solution for this behaviour? The technical specification of the printer at http://www.brother-usa.com/mfc/modeldetail.aspx?PRODUCTID=MFC7840W#.TzbkwOsS-Jo indicates that it does understand PCL. Just for testing, you could try to _not_ use CUPS and send PCL to the printer directly, either by the system's spooling mechanism (which seems to be considered depricated now as the big desktop environments and some stand-alonge applications consider CUPS the only printing interface, which they seem to hardcode into the programs) or by the direct way, using its network connection (which is a good thing, better than USB in my opinion). Really - if the specifications say the printer can do PCL and has some kind of PS, why should it be complicated to get that excellent capabilities working with CUPS? Here is a simple test that you can use: First print something from an application (web browser, text processing program, image manipulator etc.), but send the output to a file. Most print dialogs offer a print to file choice. Save the result to /tmp/print.ps - I'll use this name for demonstration, you can use any other name. Then verify what you've printed to be a PostScript file. % file /tmp/print.ps /tmp/print.ps: PostScript document text conforming DSC level 3. You can verify the content to be printed using any PS viewer, e. g. gv or gs, or whatever comes with your desktop environment. If it is a valid PS file, you can do two things: a) Test if the printer's BR-Script3 is PS-compatible: % nc 192.168.123.456 9100 /tmp/print.ps Let's assume that 192.168.123.456 is the IP of the printer. :-) Let's also assume that port 9100 is the port where the printer accepts jobs. Some printers use different ports for their different personalities. See the documentation which port to use. If unsure, leave it blank. b) Test if the printer does understand PCL. Same assumptions apply. % printf \033k2G | nc 192.168.123.456 9100 % gs -q -dBATCH -dNOPAUSE -dPARANOIDSAFER -dSAFER \ -sDEVICE=ljet4 -sPAPERSIZE=a4 -r600x600 \ -sOutputFile=- /tmp/print.ps | nc 192.168.123.456 9100 You can see that this test specifies a ljet4 printer driver. This refers to the HP Laserjet 4 and 4000 families, but it does produce PCL, so it should be fine. Report back if this works (i. e. _which_ of them, and if not, with which unexpected results). If it does work, my suggestion would be to dump CUPS and use the system's default mechanism with a man made printer filter. It's very easy. Easier than dealing with the CUPS blackbox in my opinion... I can accomplish this on my Brother MFC-9560CDW saving in either PS or PDF format. In fact, it appears that the industry is moving away from the ps format and towards the pdf format. However, none of this explains why CUPS has so thoroughly screwed up the printing process, nor why it should demand so much user intervention to set up a printer that on most modern operating systems is trivial at best. By most modern OS you mean Winblow$? You realise of course that aside from Windows and MS' other colossal clusterfuns they all use lpr and/or cups - I know of quite a few windows installations that use cups as well. I could be ignorant of a couple of OS', but I doubt it (excepting plan9). In the earlier versions (NT based) Windows used to use lpr as well I believe, and I don't think that has changed since. So the differences in setup and installation are minimal and very similar unless I'm very much mistaken and the fairies have come and are installing printers for windows now. Local printers are a slightly different case, but you still need to make some selections and input. Most would call cups trivial as well, and then would put the blame on the manufacturers in errant implementations. But the foomatic project has really done a wonderful job putting together a system that works for some many different models, and a lot of printers have now got offerings of drivers to the linux and open source community. The biggest problem comes with using many interpreters of a single language. Thankfully pcl works on the majority of printers (network), and is practically a standard in the enterprise world, so you're still not marooned with a paper weight :) Unless you're a printshop and/or into graphic arts pcl will be more than sufficient for use. If you are working in graphic arts then I doubt you'd be using a brother or something that doesn't use pure ps anyway. ___
Re: MFC 7840W under CUPS
On Mon, 13 Feb 2012 00:25:06 +1000 Da Rock articulated: The biggest problem comes with using many interpreters of a single language. Thankfully pcl works on the majority of printers (network), and is practically a standard in the enterprise world, so you're still not marooned with a paper weight :) Unless you're a printshop and/or into graphic arts pcl will be more than sufficient for use. If you are working in graphic arts then I doubt you'd be using a brother or something that doesn't use pure ps anyway. You might want to check out: http://www.linuxfoundation.org/collaborate/workgroups/openprinting. It appears that ps is no-longer the format of choice but is being replaced by PDF, a format that is natively supported by many printers. In addition, there is an active project creating a wrapper framework for the manufacturer's Windows/Mac OS X drivers, like the ndiswrapper for WLAN cards, which is something I suggested a long time ago. -- Jerry ♔ 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: MFC 7840W under CUPS
On 02/13/12 01:00, Jerry wrote: On Mon, 13 Feb 2012 00:25:06 +1000 Da Rock articulated: The biggest problem comes with using many interpreters of a single language. Thankfully pcl works on the majority of printers (network), and is practically a standard in the enterprise world, so you're still not marooned with a paper weight :) Unless you're a printshop and/or into graphic arts pcl will be more than sufficient for use. If you are working in graphic arts then I doubt you'd be using a brother or something that doesn't use pure ps anyway. You might want to check out: http://www.linuxfoundation.org/collaborate/workgroups/openprinting. It appears that ps is no-longer the format of choice but is being replaced by PDF, a format that is natively supported by many printers. In addition, there is an active project creating a wrapper framework for the manufacturer's Windows/Mac OS X drivers, like the ndiswrapper for WLAN cards, which is something I suggested a long time ago. That line between ps and pdf became blurred a long time ago. The essentially have the same root. As for MacOSX drivers I'd find that interesting given its similarities and shared root with FreeBSD, and the origin of cups (at least the biggest backer). I don't know the value of creating a wrapper for Windows drivers given they use PCL mostly anyway. Main advantage I'd suppose is in GDI drivers... As a printer specialist I stay well away from printers that don't support a standard anyway - I'll usually expect PCL at least. They're not worth the hassle, and they may be cheap but you get what you pay for in the end. If I was to buy a printer I buy to suit the need and maybe allow for expansion; so if I needed a high quality graphics printer it would generally support all OS' anyway, desktop I would do the same. Don't try to cut cost or you can end up cutting something else as well - the manufacturers will always get their pound of flesh one way or another: cheap printer = expensive parts/ink/toner, and more. And if thats not true, then they're too cheap and simply not worth it- frustration central (on _any_ OS that is!). ___ 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: MFC 7840W under CUPS
On Sun, 05 Feb 2012 21:21:59 +0100, Ouyang Xueyu wrote: Hello, I have Freebsd 8.2 and CUPS installed and try to print on my Brother MFC 7840W printer. The printer is accessible by a static IP address, is configured in CUPS but everytime I only get blank pages when I'm trying to print. Does anybody know a solution for this behaviour? The technical specification of the printer at http://www.brother-usa.com/mfc/modeldetail.aspx?PRODUCTID=MFC7840W#.TzbkwOsS-Jo indicates that it does understand PCL. Just for testing, you could try to _not_ use CUPS and send PCL to the printer directly, either by the system's spooling mechanism (which seems to be considered depricated now as the big desktop environments and some stand-alonge applications consider CUPS the only printing interface, which they seem to hardcode into the programs) or by the direct way, using its network connection (which is a good thing, better than USB in my opinion). Really - if the specifications say the printer can do PCL and has some kind of PS, why should it be complicated to get that excellent capabilities working with CUPS? Here is a simple test that you can use: First print something from an application (web browser, text processing program, image manipulator etc.), but send the output to a file. Most print dialogs offer a print to file choice. Save the result to /tmp/print.ps - I'll use this name for demonstration, you can use any other name. Then verify what you've printed to be a PostScript file. % file /tmp/print.ps /tmp/print.ps: PostScript document text conforming DSC level 3. You can verify the content to be printed using any PS viewer, e. g. gv or gs, or whatever comes with your desktop environment. If it is a valid PS file, you can do two things: a) Test if the printer's BR-Script3 is PS-compatible: % nc 192.168.123.456 9100 /tmp/print.ps Let's assume that 192.168.123.456 is the IP of the printer. :-) Let's also assume that port 9100 is the port where the printer accepts jobs. Some printers use different ports for their different personalities. See the documentation which port to use. If unsure, leave it blank. b) Test if the printer does understand PCL. Same assumptions apply. % printf \033k2G | nc 192.168.123.456 9100 % gs -q -dBATCH -dNOPAUSE -dPARANOIDSAFER -dSAFER \ -sDEVICE=ljet4 -sPAPERSIZE=a4 -r600x600 \ -sOutputFile=- /tmp/print.ps | nc 192.168.123.456 9100 You can see that this test specifies a ljet4 printer driver. This refers to the HP Laserjet 4 and 4000 families, but it does produce PCL, so it should be fine. Report back if this works (i. e. _which_ of them, and if not, with which unexpected results). If it does work, my suggestion would be to dump CUPS and use the system's default mechanism with a man made printer filter. It's very easy. Easier than dealing with the CUPS blackbox in my opinion... -- 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: MFC 7840W under CUPS
On Sun, 05 Feb 2012 21:21:59 +0100 Ouyang Xueyu articulated: Hello, I have Freebsd 8.2 and CUPS installed and try to print on my Brother MFC 7840W printer. The printer is accessible by a static IP address, is configured in CUPS but everytime I only get blank pages when I'm trying to print. Does anybody know a solution for this behaviour? I have the same problem with a different Brother printer. I have used every PPD file I could fine including the one from new Win7 machine. You did not state what program(s) you are attempting to print from. If given the option, choose the LPR option in the menu. It works for me. I have supplied every piece of information I could find on this problem to the CUPS people without getting any useful results. It seems, and this is just a guess -- but a good one in my opinion -- that it is a FreeBSD phenomenon. Brother does supply driver setups for Linux but that is about it. Good luck, I just plan gave up. The time and trouble involved in getting it to work was simply not worth the effort involved. By the way, what CUPS version? -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __ A bird in the bush usually has a friend in there with him. ___ 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: MFC 7840W under CUPS
On 02/06/12 22:21, Jerry wrote: On Sun, 05 Feb 2012 21:21:59 +0100 Ouyang Xueyu articulated: Hello, I have Freebsd 8.2 and CUPS installed and try to print on my Brother MFC 7840W printer. The printer is accessible by a static IP address, is configured in CUPS but everytime I only get blank pages when I'm trying to print. Does anybody know a solution for this behaviour? I have the same problem with a different Brother printer. I have used every PPD file I could fine including the one from new Win7 machine. You did not state what program(s) you are attempting to print from. If given the option, choose the LPR option in the menu. It works for me. I have supplied every piece of information I could find on this problem to the CUPS people without getting any useful results. It seems, and this is just a guess -- but a good one in my opinion -- that it is a FreeBSD phenomenon. Brother does supply driver setups for Linux but that is about it. Good luck, I just plan gave up. The time and trouble involved in getting it to work was simply not worth the effort involved. By the way, what CUPS version? If you can supply the debug info then we can have a crack at what exactly is happening. Personally I come from the print industry and have significant experience with printers and drivers (and other factors), I'm sure there are others in the same position. The more information there is available, the more eyes on it, and the sooner a fix could come along. ___ 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
MFC 7840W under CUPS
Hello, I have Freebsd 8.2 and CUPS installed and try to print on my Brother MFC 7840W printer. The printer is accessible by a static IP address, is configured in CUPS but everytime I only get blank pages when I'm trying to print. Does anybody know a solution for this behaviour? X. ___ 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: MFC 7840W under CUPS
On 02/06/12 06:21, Ouyang Xueyu wrote: Hello, I have Freebsd 8.2 and CUPS installed and try to print on my Brother MFC 7840W printer. The printer is accessible by a static IP address, is configured in CUPS but everytime I only get blank pages when I'm trying to print. Does anybody know a solution for this behaviour? Only one thing for it- turn on debug in the config. If you still can't see the problem then post the output here, but there's not much else we can say yet without it. HTH ___ 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
