From fnatter at gmx.net Sat Jul 1 07:07:33 2017 From: fnatter at gmx.net (Felix Natter) Date: Sat, 01 Jul 2017 16:07:33 +0200 Subject: [cups] Question regarding cups-pdf In-Reply-To: <53f7ea83-a63b-1b3d-455b-6b54678868c5@actiu.net> (Narcis Garcia's message of "Sun, 7 May 2017 17:27:05 +0200") References: <53f7ea83-a63b-1b3d-455b-6b54678868c5@actiu.net> Message-ID: <8737agi72y.fsf@bitburger.home.felix> hello cups experts, Narcis Garcia writes: > El 07/05/17 a les 17:15, Felix Natter ha escrit: >> >> Yes, my machine is configured to put the output PDFs into ~/PDF: >> Out ${HOME}/PDF >> >> But as I wrote in my previous mail, when printing from firefox or gedit, >> I see output files there. If I print from a java app, I don't see this >> (als not in /var/spool/cups-pdf/ANONYMOUS), even though if I print from >> the same java app on Windows to "PDFCreator", printing *does* work. >> >> Many Thanks and Best Regards, >> > > Then the problem is between Java (package? version?) and CUPS-PDF. > Does same Java print successfully to other printers? Sorry for the delay, I now managed to install a parallel port card and configure my printer. Printing to this (real) printer works just fine. So I think this affects cups-pdf. Does anyone have an idea why I can print from the java application (Freeplane) just fine, but if I use cups pdf, no PDF appears in ~/PDF (despite "Out ${HOME}/PDF" in cups-pdf.conf)? Shall I add debug statements to /usr/lib/cups/backend/cups-pdf? Any hints? Many Thanks and Best Regards, -- Felix Natter From ggunselm at emporia.edu Wed Jul 5 15:19:32 2017 From: ggunselm at emporia.edu (Glen Gunselman) Date: Wed, 5 Jul 2017 22:19:32 +0000 Subject: [cups] Using CUPS client with Windows Print Server In-Reply-To: <0f2c0f34-708e-fafd-5419-5506f855d13a@pppl.gov> References: <0f2c0f34-708e-fafd-5419-5506f855d13a@pppl.gov> Message-ID: I do not know how wise or unwise this may be but I am having luck using Windows print servers using LPD. I defined the printers to Oracle Linux 6.9 using the following syntax: lpadmin -p -v lpd:/// We just moved the application from Solaris 10 servers to Oracle Linux 6.9 servers about 2 months ago and I wanted to keep the application changes to a minimum. We do not do a lot of printing but this is working well for us. HTH, Glen -----Original Message----- From: cups [mailto:cups-bounces at cups.org] On Behalf Of Prentice Bisbal Sent: Wednesday, June 28, 2017 3:55 PM To: cups at cups.org Subject: [cups] Using CUPS client with Windows Print Server Hi, I've setup CUPS servers and clients in the past. On the clients, I'd create a client.conf file with a single line: the ServerName directive which specified the name of the CUPS server. I'm now in an environment where we have a lot of Linux servers and workstations, but our main print server is a Windows Print Server running IIS/8.5. Our existing Linux systems all have their own CUPS server setup which duplicates the printers setup on the Windows Print Server. This is a lot of duplicate effort. I'd prefer to just use the Windows Print Server, since it supports IPP, which I've asked the Windows Admins to enable. That way, someone else can manage the printers for me. ;) After having IPP enabled on the printer server, I created a client.conf file with the appropriate ServerName setting. After doing this 'lpstat -a' just hangs. An inspection of the network traffic between the client and server shows that the server keeps informing the client that the object has moved: > Content-Type: text/html; charset=UTF-8 > Location: http://print-srv/printers/ > Server: Microsoft-IIS/8.5 > Date: Wed, 28 Jun 2017 20:43:08 GMT > Content-Length: 149 > > Document Moved >

Object Moved

This document may be found HREF="http://print-srv/printers/">here > 16:43:08.839665 IP pbisbal-lt-c7.pppl.gov.39246 > > print-srv1.pppl.gov.ipp: Flags [P.], seq 115927:116126, ack 47180, win > 65392, length 199 > E..... at .@... > ....}.1.N.wQ....A.EP..p....POST / HTTP/1.1 > Content-Length: 635 > Content-Type: application/ipp > Host: print-srv1.pppl.gov:631 > User-Agent: CUPS/1.6.3 (Linux 3.10.0-514.10.2.el7.x86_64; x86_64) IPP/2.0 > Expect: 100-continue It appears that the client is trying to access the printer at the wrong path. Is there any way to get a CUPS client to work with Windows Print Server/IIS? Thanks, Prentice _______________________________________________ cups mailing list cups at cups.org https://lists.cups.org/mailman/listinfo/cups From pbisbal at pppl.gov Thu Jul 6 06:52:17 2017 From: pbisbal at pppl.gov (Prentice Bisbal) Date: Thu, 6 Jul 2017 09:52:17 -0400 Subject: [cups] Using CUPS client with Windows Print Server In-Reply-To: References: <0f2c0f34-708e-fafd-5419-5506f855d13a@pppl.gov> Message-ID: Glen, I am currently using the Windows print server over LPD in a similar, but very unmangeable way. IPP is more modern protocol, and without knowing all the differences, I assume IPP is a "better" protocol (why else would it have been created?). In your environment, can users specify different options from the command-line, like two-sided, landscape, etc? That's one of the issues we're having here, which is why I'd like to switch to IPP. Prentice On 07/05/2017 06:19 PM, Glen Gunselman wrote: > I do not know how wise or unwise this may be but I am having luck using Windows print servers using LPD. > > I defined the printers to Oracle Linux 6.9 using the following syntax: > > lpadmin -p -v lpd:/// > > We just moved the application from Solaris 10 servers to Oracle Linux 6.9 servers about 2 months ago and I wanted to keep the application changes to a minimum. We do not do a lot of printing but this is working well for us. > > HTH, > Glen > > > -----Original Message----- > From: cups [mailto:cups-bounces at cups.org] On Behalf Of Prentice Bisbal > Sent: Wednesday, June 28, 2017 3:55 PM > To: cups at cups.org > Subject: [cups] Using CUPS client with Windows Print Server > > Hi, > > I've setup CUPS servers and clients in the past. On the clients, I'd > create a client.conf file with a single line: the ServerName directive > which specified the name of the CUPS server. > > I'm now in an environment where we have a lot of Linux servers and > workstations, but our main print server is a Windows Print Server > running IIS/8.5. Our existing Linux systems all have their own CUPS > server setup which duplicates the printers setup on the Windows Print > Server. This is a lot of duplicate effort. > > I'd prefer to just use the Windows Print Server, since it supports IPP, > which I've asked the Windows Admins to enable. That way, someone else > can manage the printers for me. ;) > > After having IPP enabled on the printer server, I created a client.conf > file with the appropriate ServerName setting. After doing this 'lpstat > -a' just hangs. An inspection of the network traffic between the client > and server shows that the server keeps informing the client that the > object has moved: > >> Content-Type: text/html; charset=UTF-8 >> Location: http://print-srv/printers/ >> Server: Microsoft-IIS/8.5 >> Date: Wed, 28 Jun 2017 20:43:08 GMT >> Content-Length: 149 >> >> Document Moved >>

Object Moved

Message-ID: Hello, We've been experimenting with using a "print server" Mac that connects to our shared Windows print queues via smb printing and then "shares" these printers so other macs on the network can use the Mac OS native method to connect to the Windows printers. The Mac that is sharing the Windows printers is also in our MS AD domain. Access to the printers is restricted to domain users. A normal Mac just adds the printer using the control panel with the "default" option to browse for shared printers. On first print, the user is prompted for their MS AD username and password. We are also using DNS-SD or wide-area bonjour so the Mac clients find the Mac print server printers even across VLAN boundaries. I do have a question: How does CUPS handle the case where the client Mac is using a different driver/PPD than the Mac print server? Does it use what's installed on the client or server? Thanks, James Ketterer Director of IT Infrastructure DePauw University, 602 S. College, Julian Math and Science Room 127, Greencastle IN 46135 JamesKetterer at depauw.edu | www.depauw.edu On Thu, Jul 6, 2017 at 9:52 AM, Prentice Bisbal wrote: > Glen, > > I am currently using the Windows print server over LPD in a similar, but > very unmangeable way. IPP is more modern protocol, and without knowing all > the differences, I assume IPP is a "better" protocol (why else would it > have been created?). > > In your environment, can users specify different options from the > command-line, like two-sided, landscape, etc? That's one of the issues > we're having here, which is why I'd like to switch to IPP. > > Prentice > > > On 07/05/2017 06:19 PM, Glen Gunselman wrote: > >> I do not know how wise or unwise this may be but I am having luck using >> Windows print servers using LPD. >> >> I defined the printers to Oracle Linux 6.9 using the following syntax: >> >> lpadmin -p -v lpd://> server>/ >> >> We just moved the application from Solaris 10 servers to Oracle Linux 6.9 >> servers about 2 months ago and I wanted to keep the application changes to >> a minimum. We do not do a lot of printing but this is working well for us. >> >> HTH, >> Glen >> >> >> -----Original Message----- >> From: cups [mailto:cups-bounces at cups.org] On Behalf Of Prentice Bisbal >> Sent: Wednesday, June 28, 2017 3:55 PM >> To: cups at cups.org >> Subject: [cups] Using CUPS client with Windows Print Server >> >> Hi, >> >> I've setup CUPS servers and clients in the past. On the clients, I'd >> create a client.conf file with a single line: the ServerName directive >> which specified the name of the CUPS server. >> >> I'm now in an environment where we have a lot of Linux servers and >> workstations, but our main print server is a Windows Print Server >> running IIS/8.5. Our existing Linux systems all have their own CUPS >> server setup which duplicates the printers setup on the Windows Print >> Server. This is a lot of duplicate effort. >> >> I'd prefer to just use the Windows Print Server, since it supports IPP, >> which I've asked the Windows Admins to enable. That way, someone else >> can manage the printers for me. ;) >> >> After having IPP enabled on the printer server, I created a client.conf >> file with the appropriate ServerName setting. After doing this 'lpstat >> -a' just hangs. An inspection of the network traffic between the client >> and server shows that the server keeps informing the client that the >> object has moved: >> >> Content-Type: text/html; charset=UTF-8 >>> Location: http://print-srv/printers/ >>> Server: Microsoft-IIS/8.5 >>> Date: Wed, 28 Jun 2017 20:43:08 GMT >>> Content-Length: 149 >>> >>> Document Moved >>>

Object Moved

This document may be found >> HREF="http://print-srv/printers/">here >>> 16:43:08.839665 IP pbisbal-lt-c7.pppl.gov.39246 > >>> print-srv1.pppl.gov.ipp: Flags [P.], seq 115927:116126, ack 47180, win >>> 65392, length 199 >>> E..... at .@... >>> ....}.1.N.wQ....A.EP..p....POST / HTTP/1.1 >>> Content-Length: 635 >>> Content-Type: application/ipp >>> Host: print-srv1.pppl.gov:631 >>> User-Agent: CUPS/1.6.3 (Linux 3.10.0-514.10.2.el7.x86_64; x86_64) IPP/2.0 >>> Expect: 100-continue >>> >> It appears that the client is trying to access the printer at the wrong >> path. Is there any way to get a CUPS client to work with Windows Print >> Server/IIS? >> >> Thanks, >> Prentice >> _______________________________________________ >> cups mailing list >> cups at cups.org >> https://lists.cups.org/mailman/listinfo/cups >> _______________________________________________ >> cups mailing list >> cups at cups.org >> https://lists.cups.org/mailman/listinfo/cups >> > > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups > From bobmyers45 at me.com Wed Jul 5 16:49:56 2017 From: bobmyers45 at me.com (Robert Myers) Date: Wed, 05 Jul 2017 16:49:56 -0700 Subject: [cups] Fax and Faxing in Apple Mac 10.6 Server, need help sharing fax. Message-ID: <79BA65C1-388A-4CC9-834C-8A4A1E87E167@me.com> https://gist.github.com/essandess/8c0722794562821a24e6cd6fcec3bb8b I wonder if possible if you have any ideas why I can not get this to work. I have spent hours fooling around with this. Cup 2.0 does if fact create a Fax but the fax will not dial just completes. If you look at the tread you will see my efforts. Thank you, Bob Myers bobmyers45 at me.com Office (707) 864-9374 Fax (707) 864-9375 Cell (925) 980-2827 From ggunselm at emporia.edu Thu Jul 6 14:23:28 2017 From: ggunselm at emporia.edu (Glen Gunselman) Date: Thu, 6 Jul 2017 21:23:28 +0000 Subject: [cups] Using CUPS client with Windows Print Server In-Reply-To: References: <0f2c0f34-708e-fafd-5419-5506f855d13a@pppl.gov>

Message-ID: As a rule users not are logging in and printing. The app is creating the report(s) and printing using a script. It's my understanding that the script is prepending the appropriate HP PCL to the file before printing. Are you familiar with the lpadmin "-i interface" option? I have some printers using "-i pcl.sh", where pcl.sh contains: cat pcl.sh #! /bin/bash # created 3/20/2017 # Command line arguments job="$1" user="$2" title="$3" numcopies="$4" options="$5" filename="$6" # prefix output with HPJCL reset command echo "^[&k2G" cat "$filename" If you wanted to roll your own I think you could parse "options" and chose a prefix. Getting a "driver" that supports the options/printer should work but I have researched that option. Are you using printers that support HP PCL? Glen -----Original Message----- From: cups [mailto:cups-bounces at cups.org] On Behalf Of Prentice Bisbal Sent: Thursday, July 06, 2017 8:52 AM To: cups at cups.org Subject: Re: [cups] Using CUPS client with Windows Print Server Glen, I am currently using the Windows print server over LPD in a similar, but very unmangeable way. IPP is more modern protocol, and without knowing all the differences, I assume IPP is a "better" protocol (why else would it have been created?). In your environment, can users specify different options from the command-line, like two-sided, landscape, etc? That's one of the issues we're having here, which is why I'd like to switch to IPP. Prentice On 07/05/2017 06:19 PM, Glen Gunselman wrote: > I do not know how wise or unwise this may be but I am having luck using Windows print servers using LPD. > > I defined the printers to Oracle Linux 6.9 using the following syntax: > > lpadmin -p -v lpd:/// > > We just moved the application from Solaris 10 servers to Oracle Linux 6.9 servers about 2 months ago and I wanted to keep the application changes to a minimum. We do not do a lot of printing but this is working well for us. > > HTH, > Glen > > > -----Original Message----- > From: cups [mailto:cups-bounces at cups.org] On Behalf Of Prentice Bisbal > Sent: Wednesday, June 28, 2017 3:55 PM > To: cups at cups.org > Subject: [cups] Using CUPS client with Windows Print Server > > Hi, > > I've setup CUPS servers and clients in the past. On the clients, I'd > create a client.conf file with a single line: the ServerName directive > which specified the name of the CUPS server. > > I'm now in an environment where we have a lot of Linux servers and > workstations, but our main print server is a Windows Print Server > running IIS/8.5. Our existing Linux systems all have their own CUPS > server setup which duplicates the printers setup on the Windows Print > Server. This is a lot of duplicate effort. > > I'd prefer to just use the Windows Print Server, since it supports IPP, > which I've asked the Windows Admins to enable. That way, someone else > can manage the printers for me. ;) > > After having IPP enabled on the printer server, I created a client.conf > file with the appropriate ServerName setting. After doing this 'lpstat > -a' just hangs. An inspection of the network traffic between the client > and server shows that the server keeps informing the client that the > object has moved: > >> Content-Type: text/html; charset=UTF-8 >> Location: http://print-srv/printers/ >> Server: Microsoft-IIS/8.5 >> Date: Wed, 28 Jun 2017 20:43:08 GMT >> Content-Length: 149 >> >> Document Moved >>

Object Moved

This document may be found > HREF="http://print-srv/printers/">here >> 16:43:08.839665 IP pbisbal-lt-c7.pppl.gov.39246 > >> print-srv1.pppl.gov.ipp: Flags [P.], seq 115927:116126, ack 47180, win >> 65392, length 199 >> E..... at .@... >> ....}.1.N.wQ....A.EP..p....POST / HTTP/1.1 >> Content-Length: 635 >> Content-Type: application/ipp >> Host: print-srv1.pppl.gov:631 >> User-Agent: CUPS/1.6.3 (Linux 3.10.0-514.10.2.el7.x86_64; x86_64) IPP/2.0 >> Expect: 100-continue > It appears that the client is trying to access the printer at the wrong > path. Is there any way to get a CUPS client to work with Windows Print > Server/IIS? > > Thanks, > Prentice > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups _______________________________________________ cups mailing list cups at cups.org https://lists.cups.org/mailman/listinfo/cups From lucek.com at gmail.com Tue Jul 11 02:15:06 2017 From: lucek.com at gmail.com (Lucjan Kisiel) Date: Tue, 11 Jul 2017 11:15:06 +0200 Subject: [cups] CUPS always installs some default driver Message-ID: Hi, I installed both Cups and Samba to automatically install printer and drivers to it after clicking. And it almost work but... When I click on printer it ask me about install driver , ok, and it install printer. But later when I click in Windows (10 Pro 64bit) to see printer preferences I see some very poor options like it install some default driver like on picture attached. What is going on becaue I have no idea really where the cause could be. I did everything , I uploaded both x32 and x64 drivers to Cupsa, I executed cupsaddsmb successfully, I restarted daemons, I don't know...Please help I have Cups 2.2.3 and Samba 4.6.5 wrkilu From lucek.com at gmail.com Tue Jul 11 02:23:12 2017 From: lucek.com at gmail.com (Lucjan Kisiel) Date: Tue, 11 Jul 2017 11:23:12 +0200 Subject: [cups] CUPS always installs some default driver In-Reply-To: References: Message-ID: If you have problem with opening attachment please see the screenshot here: http://lk.net.pl/data/konica-poor.gif ,and this isn't any virus, be calm 2017-07-11 11:15 GMT+02:00 Lucjan Kisiel : > Hi, > I installed both Cups and Samba to automatically install printer and > drivers to it after clicking. And it almost work but... When I click on > printer it ask me about install driver , ok, and it install printer. But > later when I click in Windows (10 Pro 64bit) to see printer preferences I > see some very poor options like it install some default driver like on > picture attached. What is going on becaue I have no idea really where the > cause could be. I did everything , I uploaded both x32 and x64 drivers to > Cupsa, I executed cupsaddsmb successfully, I restarted daemons, I don't > know...Please help > > I have Cups 2.2.3 and Samba 4.6.5 > wrkilu > > -- Lucjan Kisiel tel. 692 467 870 From riny.heuvelman at live.nl Tue Jul 11 15:39:10 2017 From: riny.heuvelman at live.nl (riny heuvelman) Date: Tue, 11 Jul 2017 22:39:10 +0000 Subject: [cups] my cups works flawless In-Reply-To: References: Message-ID: Wondering which OS is installed on the cups server. Never experienced any problems after installing cups and my printer is a 10 year old HP all-in-one USB printer. Even AirPrint from my iPhone or iPad as well as anything I send from windows laptop, NOT windows 10 by the way ________________________________ Van: cups namens cups-request at cups.org Verzonden: dinsdag 11 juli 2017 21:00:00 Aan: cups at cups.org Onderwerp: cups Digest, Vol 44, Issue 5 Send cups mailing list submissions to cups at cups.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.cups.org/mailman/listinfo/cups or, via email, send a message with subject or body 'help' to cups-request at cups.org You can reach the person managing the list at cups-owner at cups.org When replying, please edit your Subject line so it is more specific than "Re: Contents of cups digest..." Today's Topics: 1. CUPS always installs some default driver (Lucjan Kisiel) 2. Re: CUPS always installs some default driver (Lucjan Kisiel) ---------------------------------------------------------------------- Message: 1 Date: Tue, 11 Jul 2017 11:15:06 +0200 From: Lucjan Kisiel To: cups at cups.org Subject: [cups] CUPS always installs some default driver Message-ID: Content-Type: text/plain; charset="UTF-8" Hi, I installed both Cups and Samba to automatically install printer and drivers to it after clicking. And it almost work but... When I click on printer it ask me about install driver , ok, and it install printer. But later when I click in Windows (10 Pro 64bit) to see printer preferences I see some very poor options like it install some default driver like on picture attached. What is going on becaue I have no idea really where the cause could be. I did everything , I uploaded both x32 and x64 drivers to Cupsa, I executed cupsaddsmb successfully, I restarted daemons, I don't know...Please help I have Cups 2.2.3 and Samba 4.6.5 wrkilu ------------------------------ Message: 2 Date: Tue, 11 Jul 2017 11:23:12 +0200 From: Lucjan Kisiel To: cups at cups.org Subject: Re: [cups] CUPS always installs some default driver Message-ID: Content-Type: text/plain; charset="UTF-8" If you have problem with opening attachment please see the screenshot here: http://lk.net.pl/data/konica-poor.gif ,and this isn't any virus, be calm 2017-07-11 11:15 GMT+02:00 Lucjan Kisiel : > Hi, > I installed both Cups and Samba to automatically install printer and > drivers to it after clicking. And it almost work but... When I click on > printer it ask me about install driver , ok, and it install printer. But > later when I click in Windows (10 Pro 64bit) to see printer preferences I > see some very poor options like it install some default driver like on > picture attached. What is going on becaue I have no idea really where the > cause could be. I did everything , I uploaded both x32 and x64 drivers to > Cupsa, I executed cupsaddsmb successfully, I restarted daemons, I don't > know...Please help > > I have Cups 2.2.3 and Samba 4.6.5 > wrkilu > > -- Lucjan Kisiel tel. 692 467 870 ------------------------------ Subject: Digest Footer _______________________________________________ cups mailing list cups at cups.org https://lists.cups.org/mailman/listinfo/cups ------------------------------ End of cups Digest, Vol 44, Issue 5 *********************************** From nag at mailbox.org Wed Jul 26 03:01:46 2017 From: nag at mailbox.org (nag at mailbox.org) Date: Wed, 26 Jul 2017 12:01:46 +0200 (CEST) Subject: [cups] Printing CCITT and JBIG2 encoded images fails Message-ID: <1237900284.8889.1501063306879@office.mailbox.org> Hi All, I am experiencing problems with printing PDF files containing images which are CCITT or JBIG2 encoded. They print to solid black pages with little artefacts at the bottom of the page. I am using CUPS 2.2.4, Arch Linux 4.11.9-1 and a Canon ImageRunner C1028i and installed the driver from here: https://aur.archlinux.org/packages/cndrvcups-lb-bin/. Plain text PDFs and PDFs containing JPEG encoded images print flawlessly. 'cupsfilter --list-filters' on the respective files returns "gziptoany", as it does on every PDF i tested. 'cupsfilter --list-filters -P /usr/share/cups/modelCNCUPSIRC1030ZK.ppd -e' on the respective file lists following filters apart from 'gziptoany': 'pstoufr2cpca' and 'commandtops'. Here is a paste of my printers.conf: http://sprunge.us/OHSR Following lines show up in my error_log, no matter whether the job succeedes (with plain text PDFs and/or PDFs containing JPEGs) or fails: E [25/Jul/2017:15:08:26 +0200] [Job 41] src = bidiCommon.c, line = 1195, err = 0¥nDEBUG: Connecting to 192.168.178.89:9100 E [25/Jul/2017:15:09:46 +0200] [Job 42] src = bidiCommon.c, line = 1195, err = 0¥nDEBUG: Connecting to 192.168.178.89:9100 E [25/Jul/2017:15:15:16 +0200] [Job 43] src = bidiCommon.c, line = 1195, err = 0¥nDEBUG: Connecting to 192.168.178.89:9100 Does anyone have any idea what the problem could be? Printing the same documents under Ubuntu 16.04 worked just fine. Many thanks and best regards, Emilio Reggi From msweet at apple.com Wed Jul 26 06:41:57 2017 From: msweet at apple.com (Michael Sweet) Date: Wed, 26 Jul 2017 09:41:57 -0400 Subject: [cups] Printing CCITT and JBIG2 encoded images fails In-Reply-To: <1237900284.8889.1501063306879@office.mailbox.org> References: <1237900284.8889.1501063306879@office.mailbox.org> Message-ID: <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> Emilio, If the driver is the same, it is probably a change in poppler or Ghostscript causing the problem. > On Jul 26, 2017, at 6:01 AM, nag at mailbox.org wrote: > > Hi All, > > I am experiencing problems with printing PDF files containing images which are CCITT or JBIG2 encoded. They print to solid black pages with little artefacts at the bottom of the page. I am using CUPS 2.2.4, Arch Linux 4.11.9-1 and a Canon ImageRunner C1028i and installed the driver from here: https://aur.archlinux.org/packages/cndrvcups-lb-bin/. Plain text PDFs and PDFs containing JPEG encoded images print flawlessly. > > 'cupsfilter --list-filters' on the respective files returns "gziptoany", as it does on every PDF i tested. > 'cupsfilter --list-filters -P /usr/share/cups/modelCNCUPSIRC1030ZK.ppd -e' on the respective file lists following filters apart from 'gziptoany': 'pstoufr2cpca' and 'commandtops'. > > Here is a paste of my printers.conf: http://sprunge.us/OHSR > > Following lines show up in my error_log, no matter whether the job succeedes (with plain text PDFs and/or PDFs containing JPEGs) or fails: > > E [25/Jul/2017:15:08:26 +0200] [Job 41] src = bidiCommon.c, line = 1195, err = 0¥nDEBUG: Connecting to 192.168.178.89:9100 > E [25/Jul/2017:15:09:46 +0200] [Job 42] src = bidiCommon.c, line = 1195, err = 0¥nDEBUG: Connecting to 192.168.178.89:9100 > E [25/Jul/2017:15:15:16 +0200] [Job 43] src = bidiCommon.c, line = 1195, err = 0¥nDEBUG: Connecting to 192.168.178.89:9100 > > Does anyone have any idea what the problem could be? Printing the same documents under Ubuntu 16.04 worked just fine. > > Many thanks and best regards, > Emilio Reggi > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups _________________________________________________________ Michael Sweet, Senior Printing System Engineer From jlord at advancedinfomanagement.com Wed Jul 26 12:02:55 2017 From: jlord at advancedinfomanagement.com (Joel Lord) Date: Wed, 26 Jul 2017 15:02:55 -0400 Subject: [cups] CUPS takes 100% CPU/file descriptor leak Message-ID: <2073989a-c164-32a6-eede-8d917169cde2@advancedinfomanagement.com> Yeah, I know, yet another of these. Running CUPS 2.1.3 on Ubuntu 16. Seeing this particular problem on a server that is fed by other CUPS servers, and which then speaks to printers. That is, the only inbound print jobs to this server are coming from CUPS elsewhere. I don't know if this matters and am not in a position to find out, sadly. At the end of *receiving* a print job, it doesn't appear to quite finish. The job gets turned around and prints successfully, but the socket from the upstream server is never closed out. Digging in with strace I'm seeing epoll_wait return a bunch of results, then a whole cycle of recvfrom and poll for each fd epoll_wait returns. Turning on debug logging, I'm seeing "Read: status=100" many, many times/second. Turning on debug2 logging, I see: d [26/Jul/2017:13:25:41 -0400] [Client 1007] cupsdReadClient: error=0, used=0, state=HTTP_STATE_POST_RECV, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=0, request=(nil)(), file=19 for each fd. So I found in the code for cupsdReadClient() that if httpGetReady returns 0 and if there is nothing further in the receive buffer (as determined with recv using MSG_PEEK) the connection is closed and it cleans up the connection. But that recv is coming back with at least 1 byte still to receive, so it's not done. But the job has already been passed along to the printer by this point and is on paper, so that byte (or more) really can't be very important, can it? Or is it possible I'm hitting a bug in the recvfrom system call such that it's reporting data in the buffer when there actually isn't? Problem is that since it's not going in to the "clean up the connection" code, we're leaking file descriptors with every print job as they're just accumulating in the CLOSE_WAIT state waiting on cupsd to actually call close() on them. Eating a CPU isn't a problem, I've got more than one. But over the course of a week I run out of file descriptors and the whole thing just falls over. A daily cron job to restart cupsd gets the job done, but that isn't really a solution to the underlying problem. Any ideas out there? -- Joel Lord Sr. Systems Architect Advanced Information Management From hoelzelj at mailbox.org Wed Jul 26 08:36:59 2017 From: hoelzelj at mailbox.org (Vom Mond) Date: Wed, 26 Jul 2017 17:36:59 +0200 (CEST) Subject: [cups] Printing CCITT and JBIG2 encoded images fails In-Reply-To: <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> References: <1237900284.8889.1501063306879@office.mailbox.org> <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> Message-ID: <355175251.1200.1501083419662@office.mailbox.org> Hi Michael, thank you for your quick reply. Do you have an idea how to narrow down the problem more, e.g. which of those two might be responsible? Best Emilio > Michael Sweet hat am 26. Juli 2017 um 15:41 geschrieben: > > Emilio, > > If the driver is the same, it is probably a change in poppler or Ghostscript causing the problem. > > > On Jul 26, 2017, at 6:01 AM, nag at mailbox.org wrote: > > > > Hi All, > > > > I am experiencing problems with printing PDF files containing images which are CCITT or JBIG2 encoded. They print to solid black pages with little artefacts at the bottom of the page. I am using CUPS 2.2.4, Arch Linux 4.11.9-1 and a Canon ImageRunner C1028i and installed the driver from here: https://aur.archlinux.org/packages/cndrvcups-lb-bin/. Plain text PDFs and PDFs containing JPEG encoded images print flawlessly. > > > > 'cupsfilter --list-filters' on the respective files returns "gziptoany", as it does on every PDF i tested. > > 'cupsfilter --list-filters -P /usr/share/cups/modelCNCUPSIRC1030ZK.ppd -e' on the respective file lists following filters apart from 'gziptoany': 'pstoufr2cpca' and 'commandtops'. > > > > Here is a paste of my printers.conf: http://sprunge.us/OHSR > > > > Following lines show up in my error_log, no matter whether the job succeedes (with plain text PDFs and/or PDFs containing JPEGs) or fails: > > > > E [25/Jul/2017:15:08:26 +0200] [Job 41] src = bidiCommon.c, line = 1195, err = 0¥nDEBUG: Connecting to 192.168.178.89:9100 > > E [25/Jul/2017:15:09:46 +0200] [Job 42] src = bidiCommon.c, line = 1195, err = 0¥nDEBUG: Connecting to 192.168.178.89:9100 > > E [25/Jul/2017:15:15:16 +0200] [Job 43] src = bidiCommon.c, line = 1195, err = 0¥nDEBUG: Connecting to 192.168.178.89:9100 > > > > Does anyone have any idea what the problem could be? Printing the same documents under Ubuntu 16.04 worked just fine. > > > > Many thanks and best regards, > > Emilio Reggi > > _______________________________________________ > > cups mailing list > > cups at cups.org > > https://lists.cups.org/mailman/listinfo/cups > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer > > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups From msweet at apple.com Wed Jul 26 12:34:05 2017 From: msweet at apple.com (Michael Sweet) Date: Wed, 26 Jul 2017 15:34:05 -0400 Subject: [cups] Printing CCITT and JBIG2 encoded images fails In-Reply-To: <355175251.1200.1501083419662@office.mailbox.org> References: <1237900284.8889.1501063306879@office.mailbox.org> <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> <355175251.1200.1501083419662@office.mailbox.org> Message-ID: Emilio, The CUPS error_log will show which filter(s) are used for the job, at which point you can determine which packages are involved. IIRC the cups-filters PDF to PostScript filter (which will likely be invoked for this driver) can be configured to use either, so look at the /usr/lib/cups/filter/pdftops script to determine which program is getting used. > On Jul 26, 2017, at 11:36 AM, Vom Mond wrote: > > Hi Michael, > > thank you for your quick reply. Do you have an idea how to narrow down the problem more, e.g. which of those two might be responsible? > > Best > Emilio > >> Michael Sweet hat am 26. Juli 2017 um 15:41 geschrieben: >> >> Emilio, >> >> If the driver is the same, it is probably a change in poppler or Ghostscript causing the problem. >> >>> On Jul 26, 2017, at 6:01 AM, nag at mailbox.org wrote: >>> >>> Hi All, >>> >>> I am experiencing problems with printing PDF files containing images which are CCITT or JBIG2 encoded. They print to solid black pages with little artefacts at the bottom of the page. I am using CUPS 2.2.4, Arch Linux 4.11.9-1 and a Canon ImageRunner C1028i and installed the driver from here: https://aur.archlinux.org/packages/cndrvcups-lb-bin/. Plain text PDFs and PDFs containing JPEG encoded images print flawlessly. >>> >>> 'cupsfilter --list-filters' on the respective files returns "gziptoany", as it does on every PDF i tested. >>> 'cupsfilter --list-filters -P /usr/share/cups/modelCNCUPSIRC1030ZK.ppd -e' on the respective file lists following filters apart from 'gziptoany': 'pstoufr2cpca' and 'commandtops'. >>> >>> Here is a paste of my printers.conf: http://sprunge.us/OHSR >>> >>> Following lines show up in my error_log, no matter whether the job succeedes (with plain text PDFs and/or PDFs containing JPEGs) or fails: >>> >>> E [25/Jul/2017:15:08:26 +0200] [Job 41] src = bidiCommon.c, line = 1195, err = 0¥nDEBUG: Connecting to 192.168.178.89:9100 >>> E [25/Jul/2017:15:09:46 +0200] [Job 42] src = bidiCommon.c, line = 1195, err = 0¥nDEBUG: Connecting to 192.168.178.89:9100 >>> E [25/Jul/2017:15:15:16 +0200] [Job 43] src = bidiCommon.c, line = 1195, err = 0¥nDEBUG: Connecting to 192.168.178.89:9100 >>> >>> Does anyone have any idea what the problem could be? Printing the same documents under Ubuntu 16.04 worked just fine. >>> >>> Many thanks and best regards, >>> Emilio Reggi >>> _______________________________________________ >>> cups mailing list >>> cups at cups.org >>> https://lists.cups.org/mailman/listinfo/cups >> >> _________________________________________________________ >> Michael Sweet, Senior Printing System Engineer >> >> _______________________________________________ >> cups mailing list >> cups at cups.org >> https://lists.cups.org/mailman/listinfo/cups > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups _________________________________________________________ Michael Sweet, Senior Printing System Engineer From msweet at apple.com Wed Jul 26 12:39:39 2017 From: msweet at apple.com (Michael Sweet) Date: Wed, 26 Jul 2017 15:39:39 -0400 Subject: [cups] CUPS takes 100% CPU/file descriptor leak In-Reply-To: <2073989a-c164-32a6-eede-8d917169cde2@advancedinfomanagement.com> References: <2073989a-c164-32a6-eede-8d917169cde2@advancedinfomanagement.com> Message-ID: Joel, The first thing I'd check is whether the problem happens with newer versions of CUPS - I believe we addressed an issue like this in 2.2.0... > On Jul 26, 2017, at 3:02 PM, Joel Lord wrote: > > Yeah, I know, yet another of these. > > Running CUPS 2.1.3 on Ubuntu 16. Seeing this particular problem on a server that is fed by other CUPS servers, and which then speaks to printers. That is, the only inbound print jobs to this server are coming from CUPS elsewhere. I don't know if this matters and am not in a position to find out, sadly. > > At the end of *receiving* a print job, it doesn't appear to quite finish. The job gets turned around and prints successfully, but the socket from the upstream server is never closed out. Digging in with strace I'm seeing epoll_wait return a bunch of results, then a whole cycle of recvfrom and poll for each fd epoll_wait returns. Turning on debug logging, I'm seeing "Read: status=100" many, many times/second. Turning on debug2 logging, I see: > > d [26/Jul/2017:13:25:41 -0400] [Client 1007] cupsdReadClient: error=0, used=0, state=HTTP_STATE_POST_RECV, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=0, request=(nil)(), file=19 > > for each fd. > > So I found in the code for cupsdReadClient() that if httpGetReady returns 0 and if there is nothing further in the receive buffer (as determined with recv using MSG_PEEK) the connection is closed and it cleans up the connection. But that recv is coming back with at least 1 byte still to receive, so it's not done. But the job has already been passed along to the printer by this point and is on paper, so that byte (or more) really can't be very important, can it? Or is it possible I'm hitting a bug in the recvfrom system call such that it's reporting data in the buffer when there actually isn't? > > Problem is that since it's not going in to the "clean up the connection" code, we're leaking file descriptors with every print job as they're just accumulating in the CLOSE_WAIT state waiting on cupsd to actually call close() on them. Eating a CPU isn't a problem, I've got more than one. But over the course of a week I run out of file descriptors and the whole thing just falls over. A daily cron job to restart cupsd gets the job done, but that isn't really a solution to the underlying problem. > > Any ideas out there? > > -- > Joel Lord > Sr. Systems Architect > Advanced Information Management > > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups _________________________________________________________ Michael Sweet, Senior Printing System Engineer From till.kamppeter at gmail.com Wed Jul 26 12:45:49 2017 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Wed, 26 Jul 2017 16:45:49 -0300 Subject: [cups] Printing CCITT and JBIG2 encoded images fails In-Reply-To: References: <1237900284.8889.1501063306879@office.mailbox.org> <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> <355175251.1200.1501083419662@office.mailbox.org> Message-ID: <43b97998-2664-ce3c-39ee-705b5b595237@gmail.com> On 07/26/2017 04:34 PM, Michael Sweet wrote: > Emilio, > > The CUPS error_log will show which filter(s) are used for the job, at which point you can determine which packages are involved. IIRC the cups-filters PDF to PostScript filter (which will likely be invoked for this driver) can be configured to use either, so look at the /usr/lib/cups/filter/pdftops script to determine which program is getting used. > Note that the pdftops filter of cups-filters is not a script (none of the filters is a script currently because they need libcups to read the PPD file), but pdftops has an option to switch between the PDF renderers Ghostscript, Poppler, and MuPDF. So you can try out which works best for you. I, as upstream maintainer of cups-filters, can even add a quirk handler to the filter if the outcoming PostScript of a certain renderer interferes badly with the printer. See the /usr/share/doc/cups-filters/README.gz file: ---------- POSTSCRIPT PRINTING RENDERER AND RESOLUTION SELECTION If you use CUPS with this package and a PostScript printer then the included pdftops filter converts the print job data which is in PDF format into PostScript. By default, the PostScript is generated with Ghostscript's "ps2write" output device, which generates a DSC-conforming PostScript with compressed embedded fonts and compressed page content. This is resource-saving and leads to fast wire transfer of print jobs to the printer. Unfortunately, Ghostscript's PostScript output is not compatible with some printers due to interpreter bugs in the printer and in addition, processing (by Ghostscript or by the printer's interpreter) can get very slow with high printing resolutions when parts of the incoming PDF file are converted to bitmaps if they contain graphical structures which are not supported by PostScript. The bitmap problem especially occurs on input files with transparency, especially also the ones produced by Cairo (evince and many other GNOME/GTK applications) which unnecessarily introduces transparency even if the input PDF has no transparency. Therefore there are two possibilities to configure pdftops at runtime: 1. Selection of the renderer: Ghostscript, Poppler, pdftocairo, Adobe Reader, or MuPDF Ghostscript has better color management and is generally optimized more for printing. Poppler produces a PostScript which is compatible with more buggy built-in PostScript interpreters of printers and it leads to a somewhat quicker workflow when graphical structures of the input PDF has to be turned into bitmaps. Adobe Reader is the PDF renderer from Adobe, the ones who created PDF and PostScript. pdftocairo is a good choice for the PDF output of Cairo (for example when printing from evince). It is less resource-consuming when rasterizing graphical elements which cannot be represented in PostScript (like transparency). Note that pdftocairo only supports PDF input using DeviceRGB, DeviceGray, RGB or sGray and is not capable of generating PostScript level 1. So its support is only experimental and distributions should not choose it as default. The selection is done by the "pdftops-renderer" option, setting it to "gs", "pdftops", "pdftocairo", "acroread", "mupdf", or "hybrid": Per-job: lpr -o pdftops-renderer=pdftops ... Per-queue default: lpadmin -p printer -o pdftops-renderer-default=gs Remove default: lpadmin -p printer -R pdftops-renderer-default By default, pdftops uses Ghostscript if this does not get changed at compile time, for example by the Linux distribution vendor. Hybrid means Ghostscript for most printers, but Poppler's pdftops for Brother, Minolta, and Konica Minolta. Printer make and model information comes from the PPD or via the "make-and-model" option. 2. Limitation of the image rendering resolution If graphical structures of the incoming PDF file have to be converted to bitmaps due to limitations of PostScript, the conversion of the file by pdftops or the rendering by the printer can get too slow if the bitmap resolution is too high or the printout quality can degrade if the bitmap resolution is too low. By default, pdftops tries to find out the actual printing resolution and sets the resolution for bitmap generation to the same value. If it cannot find the printing resolution, it uses 300 dpi. It never goes higher than a limit of 1440 dpi. Note that this default limit can get changed at compile time, for example by the Linux distribution vendor. The resolution limit for bitmaps can be changed to a lower or higher value, or be set to unlimited. This is done by the option "pdftops-max-image-resolution", setting it to the desired value (in dpi) or to zero for unlimited. It can be used per-job or as per-queue default as the "pdftops-renderer" option described above. The "pdftops-max-image-resolution" option is ignored when Adobe Reader is selected as PDF renderer. POSTSCRIPT PRINTING DEBUG MODE Sometimes a PostScript printer's interpreter errors, crashes, or somehow else misbehaves on Ghostscript's output. To find workarounds (currently we have already workarounds for Brother and Kyocera) it is much easier to work with uncompressed PostScript. To get uncompressed PostScript as output, send a job with the "psdebug" option, with commands like the following: lpr -P -o psdebug lp -d -o psdebug If you want to send your job out of a desktop application, run lpoptions -p -o psdebug to make "psdebug" a personal default setting for you. To extract the PostScript output for a developer to analyse it, clone your print queue to a one which prints into a file: cupsctl FileDevice=yes lpadmin -p test -E -v file:/tmp/printout \ -P /etc/cups/ppd/.ppd and print into this queue as described above. The PostScript output is in /tmp/printout after the job has completed. This option does not change anything if Poppler's pdftops is used as renderer. ---------- Please try out the options and tell us what works. Thanks. Till From jlord at advancedinfomanagement.com Wed Jul 26 12:48:44 2017 From: jlord at advancedinfomanagement.com (Joel Lord) Date: Wed, 26 Jul 2017 15:48:44 -0400 Subject: [cups] CUPS takes 100% CPU/file descriptor leak In-Reply-To: References: <2073989a-c164-32a6-eede-8d917169cde2@advancedinfomanagement.com> Message-ID: Hmmm... I'd checked the changelogs, but that might have been before I started cranking debug logging. Issue 4901, fixed in 2.2.1, MIGHT be it. More investigating to do... On 7/26/17 3:39 PM, Michael Sweet wrote: > Joel, > > The first thing I'd check is whether the problem happens with newer versions of CUPS - I believe we addressed an issue like this in 2.2.0... > > >> On Jul 26, 2017, at 3:02 PM, Joel Lord wrote: >> >> Yeah, I know, yet another of these. >> >> Running CUPS 2.1.3 on Ubuntu 16. Seeing this particular problem on a server that is fed by other CUPS servers, and which then speaks to printers. That is, the only inbound print jobs to this server are coming from CUPS elsewhere. I don't know if this matters and am not in a position to find out, sadly. >> >> At the end of *receiving* a print job, it doesn't appear to quite finish. The job gets turned around and prints successfully, but the socket from the upstream server is never closed out. Digging in with strace I'm seeing epoll_wait return a bunch of results, then a whole cycle of recvfrom and poll for each fd epoll_wait returns. Turning on debug logging, I'm seeing "Read: status=100" many, many times/second. Turning on debug2 logging, I see: >> >> d [26/Jul/2017:13:25:41 -0400] [Client 1007] cupsdReadClient: error=0, used=0, state=HTTP_STATE_POST_RECV, data_encoding=HTTP_ENCODING_LENGTH, data_remaining=0, request=(nil)(), file=19 >> >> for each fd. >> >> So I found in the code for cupsdReadClient() that if httpGetReady returns 0 and if there is nothing further in the receive buffer (as determined with recv using MSG_PEEK) the connection is closed and it cleans up the connection. But that recv is coming back with at least 1 byte still to receive, so it's not done. But the job has already been passed along to the printer by this point and is on paper, so that byte (or more) really can't be very important, can it? Or is it possible I'm hitting a bug in the recvfrom system call such that it's reporting data in the buffer when there actually isn't? >> >> Problem is that since it's not going in to the "clean up the connection" code, we're leaking file descriptors with every print job as they're just accumulating in the CLOSE_WAIT state waiting on cupsd to actually call close() on them. Eating a CPU isn't a problem, I've got more than one. But over the course of a week I run out of file descriptors and the whole thing just falls over. A daily cron job to restart cupsd gets the job done, but that isn't really a solution to the underlying problem. >> >> Any ideas out there? >> >> -- >> Joel Lord >> Sr. Systems Architect >> Advanced Information Management >> >> _______________________________________________ >> cups mailing list >> cups at cups.org >> https://lists.cups.org/mailman/listinfo/cups > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer > > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups -- Joel Lord Sr. Systems Architect Advanced Information Management From nag at mailbox.org Thu Jul 27 03:16:16 2017 From: nag at mailbox.org (Emilio Reggi) Date: Thu, 27 Jul 2017 12:16:16 +0200 Subject: [cups] Printing CCITT and JBIG2 encoded images fails In-Reply-To: <43b97998-2664-ce3c-39ee-705b5b595237@gmail.com> References: <1237900284.8889.1501063306879@office.mailbox.org> <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> <355175251.1200.1501083419662@office.mailbox.org> <43b97998-2664-ce3c-39ee-705b5b595237@gmail.com> Message-ID: <985d9e2d-c96a-6a9f-30d3-83b0e33285da@mailbox.org> Till, Michael, thank you very much for your helpful suggestions. I set up a file printing device (lpadmin ... file:/tmp/printout ...) and tested all renderers on it, of which each of them returned invalid postscript files (none of them were viewable with neither gv nor gsview). This phenomenon not only appeared with source files which fail to print on the 'real' printer, but with all source files I tested (Text only PDFs as well as PDFs containing JPEGs or CCITT and/or JBIG2). This is particularly interesting as Text-PDFs as well as JPEG-PDFs print well on the 'real' printer, which only returns black pages with CCITT and/or JBIG2 encoded sources. I also tried printing to the 'real' printer with different renderers being used (-o pdftops-renderer=), but no success. I would assume it to be helpful to provide you with the respective Postscript files. However, most of them are too big to attach here (gs-version 49MB; pdftops-version 25MB; pdftocairo-version 10MB; acroread-version 652 bytes; mupdf-version 652 bytes; hybrid-version 41MB). If needed, I can upload these files on your preferred filehoster. In an earlier post I wrote that printing respective files succeeded on Ubuntu 16.04. They also fail now under Ubuntu with the latest Canon driver installed UFR II/UFRII LT Printer Driver for Linux V3.40). Emilio Am 26.07.2017 um 21:45 schrieb Till Kamppeter: > On 07/26/2017 04:34 PM, Michael Sweet wrote: >> Emilio, >> >> The CUPS error_log will show which filter(s) are used for the job, at >> which point you can determine which packages are involved. IIRC the >> cups-filters PDF to PostScript filter (which will likely be invoked >> for this driver) can be configured to use either, so look at the >> /usr/lib/cups/filter/pdftops script to determine which program is >> getting used. >> > > Note that the pdftops filter of cups-filters is not a script (none of > the filters is a script currently because they need libcups to read the > PPD file), but pdftops has an option to switch between the PDF renderers > Ghostscript, Poppler, and MuPDF. So you can try out which works best for > you. I, as upstream maintainer of cups-filters, can even add a quirk > handler to the filter if the outcoming PostScript of a certain renderer > interferes badly with the printer. > > See the > > /usr/share/doc/cups-filters/README.gz > > file: > > ---------- > POSTSCRIPT PRINTING RENDERER AND RESOLUTION SELECTION > > If you use CUPS with this package and a PostScript printer then > the included pdftops filter converts the print job data which is > in PDF format into PostScript. By default, the PostScript is > generated with Ghostscript's "ps2write" output device, which > generates a DSC-conforming PostScript with compressed embedded > fonts and compressed page content. This is resource-saving and > leads to fast wire transfer of print jobs to the printer. > > Unfortunately, Ghostscript's PostScript output is not compatible > with some printers due to interpreter bugs in the printer and in > addition, processing (by Ghostscript or by the printer's > interpreter) can get very slow with high printing resolutions when > parts of the incoming PDF file are converted to bitmaps if they > contain graphical structures which are not supported by > PostScript. The bitmap problem especially occurs on input files > with transparency, especially also the ones produced by Cairo > (evince and many other GNOME/GTK applications) which unnecessarily > introduces transparency even if the input PDF has no transparency. > > Therefore there are two possibilities to configure pdftops at > runtime: > > 1. Selection of the renderer: Ghostscript, Poppler, pdftocairo, > Adobe Reader, or MuPDF > > Ghostscript has better color management and is generally optimized > more for printing. Poppler produces a PostScript which is > compatible with more buggy built-in PostScript interpreters of > printers and it leads to a somewhat quicker workflow when > graphical structures of the input PDF has to be turned into > bitmaps. Adobe Reader is the PDF renderer from Adobe, the ones who > created PDF and PostScript. pdftocairo is a good choice for the > PDF output of Cairo (for example when printing from evince). It > is less resource-consuming when rasterizing graphical elements > which cannot be represented in PostScript (like > transparency). Note that pdftocairo only supports PDF input using > DeviceRGB, DeviceGray, RGB or sGray and is not capable of > generating PostScript level 1. So its support is only experimental > and distributions should not choose it as default. > > The selection is done by the "pdftops-renderer" option, setting it > to "gs", "pdftops", "pdftocairo", "acroread", "mupdf", or "hybrid": > > Per-job: lpr -o pdftops-renderer=pdftops ... > Per-queue default: lpadmin -p printer -o pdftops-renderer-default=gs > Remove default: lpadmin -p printer -R pdftops-renderer-default > > By default, pdftops uses Ghostscript if this does not get changed > at compile time, for example by the Linux distribution vendor. > > Hybrid means Ghostscript for most printers, but Poppler's pdftops > for Brother, Minolta, and Konica Minolta. Printer make and model > information comes from the PPD or via the "make-and-model" option. > > 2. Limitation of the image rendering resolution > > If graphical structures of the incoming PDF file have to be > converted to bitmaps due to limitations of PostScript, the > conversion of the file by pdftops or the rendering by the printer > can get too slow if the bitmap resolution is too high or the > printout quality can degrade if the bitmap resolution is too low. > > By default, pdftops tries to find out the actual printing > resolution and sets the resolution for bitmap generation to the > same value. If it cannot find the printing resolution, it uses 300 > dpi. It never goes higher than a limit of 1440 dpi. Note that this > default limit can get changed at compile time, for example by the > Linux distribution vendor. > > The resolution limit for bitmaps can be changed to a lower or > higher value, or be set to unlimited. This is done by the option > "pdftops-max-image-resolution", setting it to the desired value > (in dpi) or to zero for unlimited. It can be used per-job or as > per-queue default as the "pdftops-renderer" option described > above. > > The "pdftops-max-image-resolution" option is ignored when Adobe > Reader is selected as PDF renderer. > > POSTSCRIPT PRINTING DEBUG MODE > > Sometimes a PostScript printer's interpreter errors, crashes, or > somehow else misbehaves on Ghostscript's output. To find > workarounds (currently we have already workarounds for Brother and > Kyocera) it is much easier to work with uncompressed PostScript. > To get uncompressed PostScript as output, send a job with the > "psdebug" option, with commands like the following: > > lpr -P -o psdebug > lp -d -o psdebug > > If you want to send your job out of a desktop application, run > > lpoptions -p -o psdebug > > to make "psdebug" a personal default setting for you. > > To extract the PostScript output for a developer to analyse it, > clone your print queue to a one which prints into a file: > > cupsctl FileDevice=yes > lpadmin -p test -E -v file:/tmp/printout \ > -P /etc/cups/ppd/.ppd > > and print into this queue as described above. The PostScript > output is in /tmp/printout after the job has completed. > > This option does not change anything if Poppler's pdftops is used > as renderer. > ---------- > > Please try out the options and tell us what works. Thanks. > > Till > > > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups From helgeblischke at web.de Thu Jul 27 07:53:23 2017 From: helgeblischke at web.de (Helge Blischke) Date: Thu, 27 Jul 2017 16:53:23 +0200 Subject: [cups] Printing CCITT and JBIG2 encoded images fails In-Reply-To: <985d9e2d-c96a-6a9f-30d3-83b0e33285da@mailbox.org> References: <1237900284.8889.1501063306879@office.mailbox.org> <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> <355175251.1200.1501083419662@office.mailbox.org> <43b97998-2664-ce3c-39ee-705b5b595237@gmail.com> <985d9e2d-c96a-6a9f-30d3-83b0e33285da@mailbox.org> Message-ID: <8B6D7F2D-07EB-4946-97ED-906A5E2A7896@web.de> > Am 27.07.2017 um 12:16 schrieb Emilio Reggi : > > Till, Michael, > > thank you very much for your helpful suggestions. > > I set up a file printing device (lpadmin ... file:/tmp/printout ...) and > tested all renderers on it, of which each of them returned invalid > postscript files (none of them were viewable with neither gv nor gsview). > This phenomenon not only appeared with source files which fail to print > on the 'real' printer, but with all source files I tested (Text only > PDFs as well as PDFs containing JPEGs or CCITT and/or JBIG2). This is > particularly interesting as Text-PDFs as well as JPEG-PDFs print well on > the 'real' printer, which only returns black pages with CCITT and/or > JBIG2 encoded sources. > I also tried printing to the 'real' printer with different renderers > being used (-o pdftops-renderer=), but no success. > > I would assume it to be helpful to provide you with the respective > Postscript files. However, most of them are too big to attach here > (gs-version 49MB; pdftops-version 25MB; pdftocairo-version 10MB; > acroread-version 652 bytes; mupdf-version 652 bytes; hybrid-version > 41MB). If needed, I can upload these files on your preferred filehoster. > > In an earlier post I wrote that printing respective files succeeded on > Ubuntu 16.04. They also fail now under Ubuntu with the latest Canon > driver installed UFR II/UFRII LT Printer Driver for Linux V3.40). > > Emilio > Emilio, you could upload the file(s) to DropBox and send me the link to access the file(s) (maybe off the list if you have doubts). Helge From nag at mailbox.org Thu Jul 27 08:24:33 2017 From: nag at mailbox.org (Emilio Reggi) Date: Thu, 27 Jul 2017 17:24:33 +0200 Subject: [cups] Printing CCITT and JBIG2 encoded images fails In-Reply-To: <8B6D7F2D-07EB-4946-97ED-906A5E2A7896@web.de> References: <1237900284.8889.1501063306879@office.mailbox.org> <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> <355175251.1200.1501083419662@office.mailbox.org> <43b97998-2664-ce3c-39ee-705b5b595237@gmail.com> <985d9e2d-c96a-6a9f-30d3-83b0e33285da@mailbox.org> <8B6D7F2D-07EB-4946-97ED-906A5E2A7896@web.de> Message-ID: <7a539902-85fb-4983-40b2-94b385472e86@mailbox.org> Helge, thank you for your consideration. Here are the links: https://www.dropbox.com/s/om3o80g0xngct6m/printout-acroread?dl=0 https://www.dropbox.com/s/pnmptsxgosuguld/printout-hybrid?dl=0 https://www.dropbox.com/s/zosdlf505a33nom/printout-mupdf?dl=0 https://www.dropbox.com/s/395vrwek009ln4o/printout-pdftocairo?dl=0 https://www.dropbox.com/s/9gu00z2mlewv9nz/printout-pdftops?dl=0 https://www.dropbox.com/s/rlh6k3w18iy77rm/printout-gs?dl=0 Best Emilio Am 27.07.2017 um 16:53 schrieb Helge Blischke: > > > Emilio, > > you could upload the file(s) to DropBox and send me the link to access the file(s) (maybe off the list if you have doubts). > > Helge > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups > From helgeblischke at web.de Thu Jul 27 11:32:47 2017 From: helgeblischke at web.de (Helge Blischke) Date: Thu, 27 Jul 2017 20:32:47 +0200 Subject: [cups] Printing CCITT and JBIG2 encoded images fails In-Reply-To: <7a539902-85fb-4983-40b2-94b385472e86@mailbox.org> References: <1237900284.8889.1501063306879@office.mailbox.org> <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> <355175251.1200.1501083419662@office.mailbox.org> <43b97998-2664-ce3c-39ee-705b5b595237@gmail.com> <985d9e2d-c96a-6a9f-30d3-83b0e33285da@mailbox.org> <8B6D7F2D-07EB-4946-97ED-906A5E2A7896@web.de> <7a539902-85fb-4983-40b2-94b385472e86@mailbox.org> Message-ID: > Am 27.07.2017 um 17:24 schrieb Emilio Reggi : > > Helge, > > thank you for your consideration. Here are the links: > > https://www.dropbox.com/s/om3o80g0xngct6m/printout-acroread?dl=0 > https://www.dropbox.com/s/pnmptsxgosuguld/printout-hybrid?dl=0 > https://www.dropbox.com/s/zosdlf505a33nom/printout-mupdf?dl=0 > https://www.dropbox.com/s/395vrwek009ln4o/printout-pdftocairo?dl=0 > https://www.dropbox.com/s/9gu00z2mlewv9nz/printout-pdftops?dl=0 > https://www.dropbox.com/s/rlh6k3w18iy77rm/printout-gs?dl=0 > > Best > Emilio > Thanks for the links. I looked into the files – obviously they are UFR II files, and I have no means to analyze them. To check the PostScript files, you could turn the ‚*cupsFilter‘ line in the print to file PPD into a comment (replace the leading "*“ by "*%“) and share the resulting PostScript files. But I think your problem will be a b ug in the pstoufr2cpca filter. Helge From elaine.hartle1 at gmail.com Thu Jul 27 11:46:38 2017 From: elaine.hartle1 at gmail.com (Elaine Hartle) Date: Thu, 27 Jul 2017 13:46:38 -0500 Subject: [cups] Please remove me from the CUPS email list Message-ID: <8EC0E268-AB8B-46A4-9907-BD0A41965F22@gmail.com> Thank you. Elaine Andries Hartle elaine.hartle1 at gmail.com From empbilly at gmail.com Thu Jul 27 12:54:43 2017 From: empbilly at gmail.com (Elias Pereira) Date: Thu, 27 Jul 2017 16:54:43 -0300 Subject: [cups] Please remove me from the CUPS email list In-Reply-To: <8EC0E268-AB8B-46A4-9907-BD0A41965F22@gmail.com> References: <8EC0E268-AB8B-46A4-9907-BD0A41965F22@gmail.com> Message-ID: Elaine, Access this link https://lists.cups.org/mailman/listinfo/cups and at the end you will have a field for your email to be removed from the list. On Thu, Jul 27, 2017 at 3:46 PM, Elaine Hartle wrote: > Thank you. > > Elaine Andries Hartle > elaine.hartle1 at gmail.com > > > > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups > -- Elias Pereira From nag at mailbox.org Fri Jul 28 03:55:58 2017 From: nag at mailbox.org (Emilio Reggi) Date: Fri, 28 Jul 2017 12:55:58 +0200 Subject: [cups] Printing CCITT and JBIG2 encoded images fails In-Reply-To: References: <1237900284.8889.1501063306879@office.mailbox.org> <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> <355175251.1200.1501083419662@office.mailbox.org> <43b97998-2664-ce3c-39ee-705b5b595237@gmail.com> <985d9e2d-c96a-6a9f-30d3-83b0e33285da@mailbox.org> <8B6D7F2D-07EB-4946-97ED-906A5E2A7896@web.de> <7a539902-85fb-4983-40b2-94b385472e86@mailbox.org> Message-ID: Helge, thank you very much for this helpful tip. Commenting the '*cupsFilter' line in the PPD indeed returned readable PS files. However, using the printer with did not succeed with the error "filterFailed", adding multiple printing tasks to the queue and returning blank white pages. Do you still need the Postscript files for further inspection? Otherwise, i would assume it is indeed a bug in the pstoufr2cpca filter, as you already suggested. Best regards Emilio Am 27.07.2017 um 20:32 schrieb Helge Blischke: > >> Am 27.07.2017 um 17:24 schrieb Emilio Reggi : >> >> Helge, >> >> thank you for your consideration. Here are the links: >> >> https://www.dropbox.com/s/om3o80g0xngct6m/printout-acroread?dl=0 >> https://www.dropbox.com/s/pnmptsxgosuguld/printout-hybrid?dl=0 >> https://www.dropbox.com/s/zosdlf505a33nom/printout-mupdf?dl=0 >> https://www.dropbox.com/s/395vrwek009ln4o/printout-pdftocairo?dl=0 >> https://www.dropbox.com/s/9gu00z2mlewv9nz/printout-pdftops?dl=0 >> https://www.dropbox.com/s/rlh6k3w18iy77rm/printout-gs?dl=0 >> >> Best >> Emilio >> > > Thanks for the links. > > I looked into the files – obviously they are UFR II files, and I have no means to analyze them. > > To check the PostScript files, you could turn the ‚*cupsFilter‘ line in the print to file PPD into a comment > (replace the leading "*“ by "*%“) and share the resulting PostScript files. > > But I think your problem will be a b ug in the pstoufr2cpca filter. > > Helge > > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups > From helgeblischke at web.de Fri Jul 28 04:12:54 2017 From: helgeblischke at web.de (Helge Blischke) Date: Fri, 28 Jul 2017 13:12:54 +0200 Subject: [cups] Printing CCITT and JBIG2 encoded images fails In-Reply-To: References: <1237900284.8889.1501063306879@office.mailbox.org> <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> <355175251.1200.1501083419662@office.mailbox.org> <43b97998-2664-ce3c-39ee-705b5b595237@gmail.com> <985d9e2d-c96a-6a9f-30d3-83b0e33285da@mailbox.org> <8B6D7F2D-07EB-4946-97ED-906A5E2A7896@web.de> <7a539902-85fb-4983-40b2-94b385472e86@mailbox.org>

Message-ID: <882E538D-0D85-4CFA-99D8-C4CD27756F2F@web.de> > Am 28.07.2017 um 12:55 schrieb Emilio Reggi : > > Helge, > > thank you very much for this helpful tip. Commenting the '*cupsFilter' > line in the PPD indeed returned readable PS files. However, using the > printer with did not succeed with the error "filterFailed", adding > multiple printing tasks to the queue and returning blank white pages. > > Do you still need the Postscript files for further inspection? > Otherwise, i would assume it is indeed a bug in the pstoufr2cpca filter, > as you already suggested. > > Best regards > Emilio > Emilio, if you can display the PostScript files with gv or GsView, it is almost certainly a bug in the pstoufr2cpca filter. I’d suggest to get the latest available package containing this filter from your Linux distributor or from Canon (you’ll need to specify what Linux you are using, I think). If nothing goes, I happen to have a source tarball from about Dec 2015 to Apr 2016. But there is a lot of dependencies you need to obey when compiling that stuff, which means the need to install a lot of development packages in advance. Helge From nag at mailbox.org Fri Jul 28 07:57:43 2017 From: nag at mailbox.org (Emilio Reggi) Date: Fri, 28 Jul 2017 16:57:43 +0200 Subject: [cups] Printing CCITT and JBIG2 encoded images fails In-Reply-To: <882E538D-0D85-4CFA-99D8-C4CD27756F2F@web.de> References: <1237900284.8889.1501063306879@office.mailbox.org> <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> <355175251.1200.1501083419662@office.mailbox.org> <43b97998-2664-ce3c-39ee-705b5b595237@gmail.com> <985d9e2d-c96a-6a9f-30d3-83b0e33285da@mailbox.org> <8B6D7F2D-07EB-4946-97ED-906A5E2A7896@web.de> <7a539902-85fb-4983-40b2-94b385472e86@mailbox.org>

<882E538D-0D85-4CFA-99D8-C4CD27756F2F@web.de> Message-ID: Helge, and everybody else in this thread: thank you for your patient and competent help. I contacted the maintainer of the respective package (https://aur.archlinux.org/packages/cndrvcups-lb/) and reffered him/her to this thread. As soon as I have the latest version installed I will get back here with the results. Have a nice weekend! Emilio Am 28.07.2017 um 13:12 schrieb Helge Blischke: > >> Am 28.07.2017 um 12:55 schrieb Emilio Reggi : >> >> Helge, >> >> thank you very much for this helpful tip. Commenting the '*cupsFilter' >> line in the PPD indeed returned readable PS files. However, using the >> printer with did not succeed with the error "filterFailed", adding >> multiple printing tasks to the queue and returning blank white pages. >> >> Do you still need the Postscript files for further inspection? >> Otherwise, i would assume it is indeed a bug in the pstoufr2cpca filter, >> as you already suggested. >> >> Best regards >> Emilio >> > > Emilio, > > if you can display the PostScript files with gv or GsView, it is almost certainly a bug > in the pstoufr2cpca filter. > > I’d suggest to get the latest available package containing this filter from your Linux > distributor or from Canon (you’ll need to specify what Linux you are using, I think). > > If nothing goes, I happen to have a source tarball from about Dec 2015 to Apr 2016. > But there is a lot of dependencies you need to obey when compiling that stuff, > which means the need to install a lot of development packages in advance. > > Helge > > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups > From nag at mailbox.org Mon Jul 31 02:54:33 2017 From: nag at mailbox.org (Emilio Reggi) Date: Mon, 31 Jul 2017 11:54:33 +0200 Subject: [cups] Printing CCITT and JBIG2 encoded images fails In-Reply-To: References: <1237900284.8889.1501063306879@office.mailbox.org> <131C35E0-60AD-4DCD-B623-E5B5F74EAFB1@apple.com> <355175251.1200.1501083419662@office.mailbox.org> <43b97998-2664-ce3c-39ee-705b5b595237@gmail.com> <985d9e2d-c96a-6a9f-30d3-83b0e33285da@mailbox.org> <8B6D7F2D-07EB-4946-97ED-906A5E2A7896@web.de> <7a539902-85fb-4983-40b2-94b385472e86@mailbox.org>

<882E538D-0D85-4CFA-99D8-C4CD27756F2F@web.de> Message-ID: <28b786c6-61cb-9304-4ade-7530a992d459@mailbox.org> Installing the latest Canon drivers (3.40; https://aur.archlinux.org/packages/cndrvcups-lb/) and common libraries (3.80) did the trick. Thanks to everybody for all the help :) Emilio Am 28.07.2017 um 16:57 schrieb Emilio Reggi: > Helge, > > and everybody else in this thread: thank you for your patient and > competent help. > I contacted the maintainer of the respective package > (https://aur.archlinux.org/packages/cndrvcups-lb/) and reffered him/her > to this thread. > As soon as I have the latest version installed I will get back here with > the results. > > Have a nice weekend! > Emilio > > Am 28.07.2017 um 13:12 schrieb Helge Blischke: >> >>> Am 28.07.2017 um 12:55 schrieb Emilio Reggi : >>> >>> Helge, >>> >>> thank you very much for this helpful tip. Commenting the '*cupsFilter' >>> line in the PPD indeed returned readable PS files. However, using the >>> printer with did not succeed with the error "filterFailed", adding >>> multiple printing tasks to the queue and returning blank white pages. >>> >>> Do you still need the Postscript files for further inspection? >>> Otherwise, i would assume it is indeed a bug in the pstoufr2cpca filter, >>> as you already suggested. >>> >>> Best regards >>> Emilio >>> >> >> Emilio, >> >> if you can display the PostScript files with gv or GsView, it is almost certainly a bug >> in the pstoufr2cpca filter. >> >> I’d suggest to get the latest available package containing this filter from your Linux >> distributor or from Canon (you’ll need to specify what Linux you are using, I think). >> >> If nothing goes, I happen to have a source tarball from about Dec 2015 to Apr 2016. >> But there is a lot of dependencies you need to obey when compiling that stuff, >> which means the need to install a lot of development packages in advance. >> >> Helge >> >> _______________________________________________ >> cups mailing list >> cups at cups.org >> https://lists.cups.org/mailman/listinfo/cups >> > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups > From chelsea at 11th-hoursignings.com Mon Jul 31 16:53:43 2017 From: chelsea at 11th-hoursignings.com (Chelsea Addison) Date: Mon, 31 Jul 2017 16:53:43 -0700 Subject: [cups] Brother HL-L6200dwt Message-ID: Hi Everyone - I hope someone can help me - I have an iMac that I bought new about 2 months ago, it’s running Sierra 10.12.6 and I have a Brother laser printer HL-L6200dwt using the CUPS driver 4.0.3 with dual paper trays - letter 1st tray and legal 2nd tray. I’m also using Adobe Acrobat DC. I bought this particular printer because according to Brother the printer will tray switch between the letter and legal size paper the same as it does with a Windows computer. There’s even a video on YouTube explaining how to set up the printer with iMac so that it’ll tray switch. I print legal mortgage loan document packages that are a mixture of letter and legal and the packages are upwards of 200 pages, whatever format the documents are uploaded to me is the way it’s required to be printed and presented. If i I was to print only the letter and then only the legal I would then have to put it back in order which is time consuming and extremely frustrating. When I spoke to Brother and Apple they both attempted every possible scenario to correct the problem with no solution being achieved. I’ve scoured the internet, the Apple and Adobe forums and found that there are a multitude of other people having the same issue. Brother swears by the CUPS driver and insists that it should be working. Apple points the finger back at Brother saying it’s a driver problem. The Adobe help section also suggests using the postscript driver in the event the CUPS one doesn’t work but again, didn’t work. When I print the documents I choose the “fit to PDF size” option and shrink to fit (but I’ve also tried other variations) on the Adobe print dialogue box everything looks great but it prints the papers with the top margin pushed down about 3 inches which then chops off the bottom portion. We tried the print as image option and scale to fit as well. Any help you can provide will be very much appreciated. Thank you! Chelsea Addison San Diego, CA From msweet at apple.com Mon Jul 31 18:00:00 2017 From: msweet at apple.com (Michael Sweet) Date: Mon, 31 Jul 2017 21:00:00 -0400 Subject: [cups] Brother HL-L6200dwt In-Reply-To: References: Message-ID: <5CE94E92-4822-448D-8D81-2D64B863FDF3@apple.com> Chelsea, Right now the macOS print APIs do NOT support multiple page sizes in a single document job. Direct submission of a PDF will work to a PDF printer (and this Brother printer does support PDF) so you can probably use "lp" to submit the PDF directly, but if you print from any application the output will get scaled/fit to a single size. (If you can give me the Apple bug number off-line I can look into why you weren't told this...) > On Jul 31, 2017, at 7:53 PM, Chelsea Addison wrote: > > Hi Everyone - > > I hope someone can help me - I have an iMac that I bought new about 2 months ago, it’s running Sierra 10.12.6 and I have a Brother laser printer HL-L6200dwt using the CUPS driver 4.0.3 with dual paper trays - letter 1st tray and legal 2nd tray. I’m also using Adobe Acrobat DC. > > I bought this particular printer because according to Brother the printer will tray switch between the letter and legal size paper the same as it does with a Windows computer. There’s even a video on YouTube explaining how to set up the printer with iMac so that it’ll tray switch. I print legal mortgage loan document packages that are a mixture of letter and legal and the packages are upwards of 200 pages, whatever format the documents are uploaded to me is the way it’s required to be printed and presented. If i I was to print only the letter and then only the legal I would then have to put it back in order which is time consuming and extremely frustrating. When I spoke to Brother and Apple they both attempted every possible scenario to correct the problem with no solution being achieved. I’ve scoured the internet, the Apple and Adobe forums and found that there are a multitude of other people having the same issue. > Brother swears by the CUPS driver and insists that it should be working. Apple points the finger back at Brother saying it’s a driver problem. The Adobe help section also suggests using the postscript driver in the event the CUPS one doesn’t work but again, didn’t work. > > When I print the documents I choose the “fit to PDF size” option and shrink to fit (but I’ve also tried other variations) on the Adobe print dialogue box everything looks great but it prints the papers with the top margin pushed down about 3 inches which then chops off the bottom portion. We tried the print as image option and scale to fit as well. > > Any help you can provide will be very much appreciated. > > Thank you! > > > Chelsea Addison > San Diego, CA > _______________________________________________ > cups mailing list > cups at cups.org > https://lists.cups.org/mailman/listinfo/cups _________________________________________________________ Michael Sweet, Senior Printing System Engineer