Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution'
On Wed 19 Jul 2017 at 01:59:55 +, brian m. carlson wrote: > At this point, I don't have access to the printer anymore, so I can't > test any further. I think your change probably doesn't make things > worse for people with that printer, so I'd suggest closing this bug > report at this point. A user writing to debian-user has a MFC-9340CDW and, with cups-filters 1.16.0-2, initially reported a "garbled printout", On reflection, he amended his description in https://lists.debian.org/debian-user/2017/08/msg00164.html Looks like some (inadvertent) testing of the committed fix, Cheers, Brian.
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution'
On Mon, Jul 17, 2017 at 11:19:39PM -0300, Till Kamppeter wrote: > This is all very strange. > > What do you get if you run the command > > driverless > > This should make the printer's IPP URI appear. Now run > > driverless [IPP URI] > out.ppd > > with [IPP URI] replaced by the printer's IPP URI, the output of the first > command. > > out.ppd then is a valid and working PPD for your printer, using it in > driverless mode. It did not do that. I ran that by hand. All I got when doing "driverless list" was the following (from my other printer): DEBUG: Started ippfind (PID 194908) DEBUG: Started post-processing (PID 194909) "driverless:ipp://HPFC3FDB1C3D52.local:631/ipp/print" en "HP" "HP Officejet 7610 series, driverless, cups-filters 1.14.1" "MFG:HP;MDL:Officejet 7610 series;CMD:PCL,AppleRaster,JPEG,URF;" DEBUG: PID 194908 (ippfind) exited with no errors. DEBUG: PID 194909 (Post-processing) exited with no errors. At this point, I don't have access to the printer anymore, so I can't test any further. I think your change probably doesn't make things worse for people with that printer, so I'd suggest closing this bug report at this point. -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution'
This is all very strange. What do you get if you run the command driverless This should make the printer's IPP URI appear. Now run driverless [IPP URI] > out.ppd with [IPP URI] replaced by the printer's IPP URI, the output of the first command. out.ppd then is a valid and working PPD for your printer, using it in driverless mode. Till
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution'
On Mon, Jul 17, 2017 at 09:09:09PM -0300, Till Kamppeter wrote: > On 07/17/2017 08:34 PM, brian m. carlson wrote: > > > > It does not appear to fix the problem. The PPD that's generated is > > identical and still contains the 600x2 resolution. I will lose access > > to the printer tomorrow, unfortunately, so I'll be unable to test > > further. > > > > The actual change takes place in > /usr/lib/x86_64-linux-gnu/libcupsfilters.so.1.0.0. So you if you do not do a > full "make install", you need to run the command > > sudo cp .libs/libcupsfilters.so.1.0.0 /usr/lib/x86_64-linux-gnu/ I actually applied it to the latest Debian package, ran dpkg-source --commit, and rebuilt it. But I didn't install the shared library. Let me do that and try again. So the code does indeed work in that the driverless mode is no longer selected, which means that I have to fall back to PCL mode, which does what I requested. I no longer see a driverless option for that, and I get the following messages from system-config-printer: No ID match for device ipp://172.16.0.5:631/ipp/print: MFG:;MDL:; No ID match for device ipp://172.16.0.5:631/ipp/print: MFG:;MDL:; No ID match for device ipp://172.16.0.5:631/ipp/print: MFG:;MDL:; No ID match for device ipp://172.16.0.5:631/ipp/print: MFG:;MDL:; Unknown value for media-col: (unknown IPP value tag 0x34) Choices: ['media-bottom-margin', 'media-left-margin', 'media-right-margin', 'media-size', 'media-source', 'media-top-margin', 'media-type'] Selecting from choices: media-bottom-margin No ID match for device ipp://172.16.0.5:631/ipp/print: MFG:;MDL:; No ID match for device ipp://172.16.0.5:631/ipp/print: -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
On 07/17/2017 08:34 PM, brian m. carlson wrote: It does not appear to fix the problem. The PPD that's generated is identical and still contains the 600x2 resolution. I will lose access to the printer tomorrow, unfortunately, so I'll be unable to test further. The actual change takes place in /usr/lib/x86_64-linux-gnu/libcupsfilters.so.1.0.0. So you if you do not do a full "make install", you need to run the command sudo cp .libs/libcupsfilters.so.1.0.0 /usr/lib/x86_64-linux-gnu/ to apply the fix to your system. Till
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
On Mon, Jul 17, 2017 at 03:08:09PM -0300, Till Kamppeter wrote: > I have now added a fallback mechanism to the PPD generator in cups-filters > which does not accept resolutions < 75 dpi. > > It is committed (rev. 7652) to the upstream BZR repository. Please test. It does not appear to fix the problem. The PPD that's generated is identical and still contains the 600x2 resolution. I will lose access to the printer tomorrow, unfortunately, so I'll be unable to test further. -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
I have now added a fallback mechanism to the PPD generator in cups-filters which does not accept resolutions < 75 dpi. It is committed (rev. 7652) to the upstream BZR repository. Please test. Till
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
On Sun 16 Jul 2017 at 19:42:21 +, brian m. carlson wrote: > retitle 868360 cups-filters-core-drivers: recommends non-functional > driverless operation > kthxbye > > On Sun, Jul 16, 2017 at 05:17:14PM +0100, Brian Potkin wrote: > > On Sun 16 Jul 2017 at 14:38:44 +, brian m. carlson wrote: > > > The printer resolution is indeed returned in an IPP query, as you'll see > > > in the data provided. However, cups only accepts the PWG raster format > > > resolution and ignores the printer resolution. If the driverless > > > printing option provided all three resolution options (600 dpi, 600x2400 > > > dpi, and 600x2 dpi), it would be easy to simply configure the printer to > > > use one of the other options as a default. > > > > > > I do view this aspect as a bug in cups. I should be able to pick any > > > resolution that the printer supports. > > > > When it generates a PPD cups-browsed does fill in missing essential > > options with defaults. Whether it corrects values for attributes (or > > whether it is seen as desirable to do so) I do not know. > > The printer resolution was indeed provided, as the dump I attached to > this bug report specified. There was no reason to restrict me to only > only the PWG resolution instead of allowing me to pick the other > resolutions supported by the printer. > > This package indicates that the driverless PPD operation is > "recommended". I've provided five ways in which the driverless > operation could work on this printer, but as it stands this recommended > driver is non-functional. > > If CUPS is going to recommend this driver as the best option, it should > work usefully out of the box with little to no configuration, which it > currently does not. CUPS should either adopt one of the five proposed > resolutions or stop indicating this driver is recommended. Perhaps a > blacklist of known-broken devices should be built. A bug in a vendor's implementation becomes a bug in the printing system? We will await the vendor's response to make a judgement (Brother printer users seem very shy about changing a line in a PPD and testing out and reporting on an idea. Not to worry. We will eventually get to the bottom of it). -- Brian.
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
retitle 868360 cups-filters-core-drivers: recommends non-functional driverless operation kthxbye On Sun, Jul 16, 2017 at 05:17:14PM +0100, Brian Potkin wrote: > On Sun 16 Jul 2017 at 14:38:44 +, brian m. carlson wrote: > > The printer resolution is indeed returned in an IPP query, as you'll see > > in the data provided. However, cups only accepts the PWG raster format > > resolution and ignores the printer resolution. If the driverless > > printing option provided all three resolution options (600 dpi, 600x2400 > > dpi, and 600x2 dpi), it would be easy to simply configure the printer to > > use one of the other options as a default. > > > > I do view this aspect as a bug in cups. I should be able to pick any > > resolution that the printer supports. > > When it generates a PPD cups-browsed does fill in missing essential > options with defaults. Whether it corrects values for attributes (or > whether it is seen as desirable to do so) I do not know. The printer resolution was indeed provided, as the dump I attached to this bug report specified. There was no reason to restrict me to only only the PWG resolution instead of allowing me to pick the other resolutions supported by the printer. This package indicates that the driverless PPD operation is "recommended". I've provided five ways in which the driverless operation could work on this printer, but as it stands this recommended driver is non-functional. If CUPS is going to recommend this driver as the best option, it should work usefully out of the box with little to no configuration, which it currently does not. CUPS should either adopt one of the five proposed resolutions or stop indicating this driver is recommended. Perhaps a blacklist of known-broken devices should be built. -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
On Sun 16 Jul 2017 at 14:38:44 +, brian m. carlson wrote: > On Sun, Jul 16, 2017 at 12:34:05AM +0100, Brian Potkin wrote: > > On Sat 15 Jul 2017 at 19:40:04 +, brian m. carlson wrote: > > > * Validate data. Nobody is going to print a two-pixel raster image, and > > > cups should not accept it as a valid (and in this case, the only > > > valid) option. > > > > cups and cupsfilters have both accepted and fixed past bugs in their > > implementation of driverless printing. In some cases cups has made > > allowances for deficiencies in a manufacturer's implementaion of IPP > > Everywhere. But where does it end? > > > > Assuming this is a firmware bug, doesn't the vendor (who after all is > > using a well defined standard) have the reponsibility, especially if > > the issue is drawn to their attention by an affected user? If AirPrint > > was involved you could well imagine they would jump to it. > > I have put in a support request with them. However, I have no way to > prove that this actually affects AirPrint, as I don't have any modern > Apple devices. I'm pretty sure my alternative is going to be returning > the printer. > > I will say that cups is clearly accepting invalid data. How can a > printer have a resolution of 600 dpi and only accept 600x2 raster > images? If the printer returned 600x-1 resolution, would cups accept > that as well? It would interesting to know Brother's response. > > > * Use the printer resolution instead of the PWG resolution when > > > generating raster images. At the very least, these should be > > > resolution options for configuration in addition to the PWG > > > resolution. > > > > Surely the printer resolution is what is returned by an IPP query? > > Either that, or it is in a supplied PPD. > > The printer resolution is indeed returned in an IPP query, as you'll see > in the data provided. However, cups only accepts the PWG raster format > resolution and ignores the printer resolution. If the driverless > printing option provided all three resolution options (600 dpi, 600x2400 > dpi, and 600x2 dpi), it would be easy to simply configure the printer to > use one of the other options as a default. > > I do view this aspect as a bug in cups. I should be able to pick any > resolution that the printer supports. When it generates a PPD cups-browsed does fill in missing essential options with defaults. Whether it corrects values for attributes (or whether it is seen as desirable to do so) I do not know. > The vendor does not supply a plain PPD for Linux. They provide a > proprietary driver. While that may work for my x86 machines, that will > not work for my ARM, MIPS, or PowerPC machines. > I made a suggestion on -user a week or two ago about this issue but no > response came back. I will repeat it here: > > The PPD in /etc/cups/ppd has a line beginning *cupsFilter:. . > Alter the line to read > >*cupsFilter: "application/vnd.cups-raster 50 rastertohp" > > Restart cups and do > >lp -d /etc/nsswitch > > That file prints out perfectly on my PCL/PCLX capable LaserJet. (I > used a Brother PPD, with the altered line, for your printer). > >I am unsure about "50" in the *cupsFilter: line. "0" might be better. -- Brian.
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
On Sun, Jul 16, 2017 at 12:34:05AM +0100, Brian Potkin wrote: > On Sat 15 Jul 2017 at 19:40:04 +, brian m. carlson wrote: > > * Validate data. Nobody is going to print a two-pixel raster image, and > > cups should not accept it as a valid (and in this case, the only > > valid) option. > > cups and cupsfilters have both accepted and fixed past bugs in their > implementation of driverless printing. In some cases cups has made > allowances for deficiencies in a manufacturer's implementaion of IPP > Everywhere. But where does it end? > > Assuming this is a firmware bug, doesn't the vendor (who after all is > using a well defined standard) have the reponsibility, especially if > the issue is drawn to their attention by an affected user? If AirPrint > was involved you could well imagine they would jump to it. I have put in a support request with them. However, I have no way to prove that this actually affects AirPrint, as I don't have any modern Apple devices. I'm pretty sure my alternative is going to be returning the printer. I will say that cups is clearly accepting invalid data. How can a printer have a resolution of 600 dpi and only accept 600x2 raster images? If the printer returned 600x-1 resolution, would cups accept that as well? > > * Use the printer resolution instead of the PWG resolution when > > generating raster images. At the very least, these should be > > resolution options for configuration in addition to the PWG > > resolution. > > Surely the printer resolution is what is returned by an IPP query? > Either that, or it is in a supplied PPD. The printer resolution is indeed returned in an IPP query, as you'll see in the data provided. However, cups only accepts the PWG raster format resolution and ignores the printer resolution. If the driverless printing option provided all three resolution options (600 dpi, 600x2400 dpi, and 600x2 dpi), it would be easy to simply configure the printer to use one of the other options as a default. I do view this aspect as a bug in cups. I should be able to pick any resolution that the printer supports. The vendor does not supply a plain PPD for Linux. They provide a proprietary driver. While that may work for my x86 machines, that will not work for my ARM, MIPS, or PowerPC machines. -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
On Sat 15 Jul 2017 at 19:40:04 +, brian m. carlson wrote: > On Sat, Jul 15, 2017 at 08:16:19PM +0100, Brian Potkin wrote: > > On Fri 14 Jul 2017 at 22:48:32 +, brian m. carlson wrote: > > > > > This does fix the problem. Since this printer supports PCL, I can also > > > use the hpijs-pcl5c driver in the mean time. > > > > Is this a bug in Brother's printer? It looks like it is. > > It does look like a firmware bug to report this resolution. However, > I think cups could improve upon its behavior in several ways: > > * Validate data. Nobody is going to print a two-pixel raster image, and > cups should not accept it as a valid (and in this case, the only > valid) option. cups and cupsfilters have both accepted and fixed past bugs in their implementation of driverless printing. In some cases cups has made allowances for deficiencies in a manufacturer's implementaion of IPP Everywhere. But where does it end? Assuming this is a firmware bug, doesn't the vendor (who after all is using a well defined standard) have the reponsibility, especially if the issue is drawn to their attention by an affected user? If AirPrint was involved you could well imagine they would jump to it. > * Prefer PCL, PostScript, and PDF over PWG. People specifically buy > printers that support the former languages. I've never heard of PWG > raster format as a selling point. The URF PDL is not a selling point; but Airprint is. PWG is (I think) a requirement for Google Cloud Print. People may not have heard of either raster format but it's all under the hood. Many less costly printers nowadays do not have PCL, PostScript or PDF as an accepted PDL, but they do have URF and/or PWG. It is a good avenue for avoiding proprietary drivers and plugins. > * Use the printer resolution instead of the PWG resolution when > generating raster images. At the very least, these should be > resolution options for configuration in addition to the PWG > resolution. Surely the printer resolution is what is returned by an IPP query? Either that, or it is in a supplied PPD. > * Stop suggesting driverless configurations as the recommended option if > they're obviously broken or not going to work. No bugs in PCL, PostScript or PDF interpreters? No bugs in PPDs? We would end up not "recommending" anything. :) -- Brian.
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
On Sat, Jul 15, 2017 at 08:16:19PM +0100, Brian Potkin wrote: > On Fri 14 Jul 2017 at 22:48:32 +, brian m. carlson wrote: > > > This does fix the problem. Since this printer supports PCL, I can also > > use the hpijs-pcl5c driver in the mean time. > > Is this a bug in Brother's printer? It looks like it is. It does look like a firmware bug to report this resolution. However, I think cups could improve upon its behavior in several ways: * Validate data. Nobody is going to print a two-pixel raster image, and cups should not accept it as a valid (and in this case, the only valid) option. * Prefer PCL, PostScript, and PDF over PWG. People specifically buy printers that support the former languages. I've never heard of PWG raster format as a selling point. * Use the printer resolution instead of the PWG resolution when generating raster images. At the very least, these should be resolution options for configuration in addition to the PWG resolution. * Stop suggesting driverless configurations as the recommended option if they're obviously broken or not going to work. -- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204 signature.asc Description: PGP signature
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
On Fri 14 Jul 2017 at 22:48:32 +, brian m. carlson wrote: > On Fri, Jul 14, 2017 at 06:42:34PM -0300, Till Kamppeter wrote: > > > > Replace > > > > -- > > *DefaultResolution: 600x2dpi > > *OpenUI *cupsPrintQuality/Print Quality: PickOne > > *OrderDependency: 10 AnySetup *cupsPrintQuality > > *DefaultcupsPrintQuality: Normal > > *cupsPrintQuality Normal/Normal: "<>setpagedevice" > > *cupsPrintQuality High/High: "<>setpagedevice" > > *CloseUI: *cupsPrintQuality > > -- > > > > by > > > > -- > > *DefaultResolution: 600x600dpi > > *OpenUI *cupsPrintQuality/Print Quality: PickOne > > *OrderDependency: 10 AnySetup *cupsPrintQuality > > *DefaultcupsPrintQuality: Normal > > *cupsPrintQuality Normal/Normal: "<>setpagedevice" > > *cupsPrintQuality High/High: "<>setpagedevice" > > *CloseUI: *cupsPrintQuality > > -- > > > > Do not forget to restart CUPS after editing or replacing your PPD file. > > > > Please tell whether this change fixes your problem. > > This does fix the problem. Since this printer supports PCL, I can also > use the hpijs-pcl5c driver in the mean time. Is this a bug in Brother's printer? It looks like it is. -- Brian.
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
On Fri, Jul 14, 2017 at 06:42:34PM -0300, Till Kamppeter wrote:
> It seems that the printer answers the wrong resolution (firmware bug). Under
> the printer's attributes I have found:
>
> > DEBUG2: Attr: pwg-raster-document-resolution-supported
> > DEBUG2: Value: 600x2dpi
I have just updated the firmware to the latest version, thinking that
might be the problem. The results are exactly the same as with the old
firmware.
> Please run the following command:
>
> ipptool -tv ipp://copper.local:631/ipp/print get-printer-attributes.test >
> ipp-attrs.txt
>
> and attach the file ipp-attrs.txt to your answer to this bug report. Thanks.
Attached.
> To be able to print for the time being, please edit your PPD file as
> follows:
>
> Replace
>
> --
> *DefaultResolution: 600x2dpi
> *OpenUI *cupsPrintQuality/Print Quality: PickOne
> *OrderDependency: 10 AnySetup *cupsPrintQuality
> *DefaultcupsPrintQuality: Normal
> *cupsPrintQuality Normal/Normal: "<>setpagedevice"
> *cupsPrintQuality High/High: "<>setpagedevice"
> *CloseUI: *cupsPrintQuality
> --
>
> by
>
> --
> *DefaultResolution: 600x600dpi
> *OpenUI *cupsPrintQuality/Print Quality: PickOne
> *OrderDependency: 10 AnySetup *cupsPrintQuality
> *DefaultcupsPrintQuality: Normal
> *cupsPrintQuality Normal/Normal: "<>setpagedevice"
> *cupsPrintQuality High/High: "<>setpagedevice"
> *CloseUI: *cupsPrintQuality
> --
>
> Do not forget to restart CUPS after editing or replacing your PPD file.
>
> Please tell whether this change fixes your problem.
This does fix the problem. Since this printer supports PCL, I can also
use the hpijs-pcl5c driver in the mean time.
--
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
"/usr/share/cups/ipptool/get-printer-attributes.test":
Get-Printer-Attributes:
attributes-charset (charset) = utf-8
attributes-natural-language (naturalLanguage) = en
printer-uri (uri) = ipp://copper.local:631/ipp/print
Get printer attributes using Get-Printer-Attributes [PASS]
RECEIVED: 4472 bytes in response
status-code = successful-ok (successful-ok)
attributes-charset (charset) = utf-8
attributes-natural-language (naturalLanguage) = en
copies-default (integer) = 1
finishings-default (enum) = none
media-default (keyword) = na_letter_8.5x11in
media-col-default (collection) = {media-type=stationery
media-size={x-dimension=21590 y-dimension=27940} media-bottom-margin=432
media-left-margin=432 media-right-margin=432 media-top-margin=432
media-source=auto}
orientation-requested-default (enum) = portrait
output-bin-default (keyword) = face-down
output-mode-default (keyword) = color
print-quality-default (enum) = normal
printer-resolution-default (resolution) = 600dpi
sides-default (keyword) = one-sided
print-color-mode-default (keyword) = color
copies-supported (rangeOfInteger) = 1-1
finishings-supported (enum) = none
media-supported (1setOf keyword) =
iso_a4_210x297mm,na_letter_8.5x11in,na_legal_8.5x14in,na_executive_7.25x10.5in,iso_a5_148x210mm,iso_a6_105x148mm,iso_b5_176x250mm,jis_b5_182x257mm,na_number-10_4.125x9.5in,iso_dl_110x220mm,iso_c5_162x229mm,na_monarch_3.875x7.5in,na_index-3x5_3x5in,om_folio_210x330mm,custom_min_76.2x127mm,custom_max_215.9x355.6mm
media-col-supported (1setOf keyword) =
media-type,media-size,media-top-margin,media-left-margin,media-right-margin,media-bottom-margin,media-source
orientation-requested-supported (1setOf enum) = portrait,landscape
output-bin-supported (keyword) = face-down
output-mode-supported (1setOf keyword) = color,auto,monochrome
print-quality-supported (1setOf enum) = normal,high
printer-resolution-supported (1setOf resolution) = 600dpi,2400x600dpi
sides-supported (1setOf keyword) =
one-sided,two-sided-long-edge,two-sided-short-edge
print-color-mode-supported (1setOf keyword) = auto,color,monochrome
generated-natural-language-supported (1setOf naturalLanguage) = en,fr
printer-uri-supported (uri) = ipp://copper.local./ipp/print
uri-security-supported (keyword) = none
uri-authentication-supported (keyword) = none
printer-name (nameWithoutLanguage) = copper
printer-location (textWithoutLanguage) =
printer-info (textWithoutLanguage) = Brother MFC-9340CDW
printer-make-and-model (textWithoutLanguage) = Brother MFC-9340CDW
printer-state (enum) = idle
printer-state-reasons (keyword) = none
ipp-versions-supported (1setOf keyword) = 1.0,1.1,2.0
operations-supported (1setOf enum) =
Print-Job,Validate-Job,Cancel-Job,Get-Job-Attributes,Get-Jobs,Get-Printer-Attributes
multiple-document-jobs-supported (boolean) = false
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
It seems that the printer answers the wrong resolution (firmware bug). Under the printer's attributes I have found: DEBUG2: Attr: pwg-raster-document-resolution-supported DEBUG2: Value: 600x2dpi Please run the following command: ipptool -tv ipp://copper.local:631/ipp/print get-printer-attributes.test > ipp-attrs.txt and attach the file ipp-attrs.txt to your answer to this bug report. Thanks. To be able to print for the time being, please edit your PPD file as follows: Replace -- *DefaultResolution: 600x2dpi *OpenUI *cupsPrintQuality/Print Quality: PickOne *OrderDependency: 10 AnySetup *cupsPrintQuality *DefaultcupsPrintQuality: Normal *cupsPrintQuality Normal/Normal: "<>setpagedevice" *cupsPrintQuality High/High: "<>setpagedevice" *CloseUI: *cupsPrintQuality -- by -- *DefaultResolution: 600x600dpi *OpenUI *cupsPrintQuality/Print Quality: PickOne *OrderDependency: 10 AnySetup *cupsPrintQuality *DefaultcupsPrintQuality: Normal *cupsPrintQuality Normal/Normal: "<>setpagedevice" *cupsPrintQuality High/High: "<>setpagedevice" *CloseUI: *cupsPrintQuality -- Do not forget to restart CUPS after editing or replacing your PPD file. Please tell whether this change fixes your problem. Till
Bug#868360: cups-filters-core-drivers: driverless sets bizarre 600x2 resolution
Package: cups-filters-core-drivers
Version: 1.14.1-1
Severity: normal
I have a Brother MFC-9340CDW printer on the local LAN. When using the
driverless configuration, the resolution is set to 600x2 dpi, resulting
in the printer printing literally two lines on the page. The resolution
of the printer is either 600x600 or 600x2400 dpi.
The output of the command is below. You can see that it recognizes the
correct resolution, but emits the incorrect one in the PPD. I suspect
something is getting truncated somewhere.
genre ok % /usr/lib/cups/driver/driverless cat ipp://copper.local:631/ipp/print
DEBUG2: Attr: attributes-charset
DEBUG2: Value: utf-8
DEBUG2: Keyword: utf-8
DEBUG2: Attr: attributes-natural-language
DEBUG2: Value: en-us
DEBUG2: Keyword: en-us
DEBUG2: Attr: copies-default
DEBUG2: Value: 1
DEBUG2: Keyword: (null)
DEBUG2: Attr: finishings-default
DEBUG2: Value: none
DEBUG2: Keyword: (null)
DEBUG2: Attr: media-default
DEBUG2: Value: na_letter_8.5x11in
DEBUG2: Keyword: na_letter_8.5x11in
DEBUG2: Attr: media-col-default
DEBUG2: Value: {media-type=stationery media-size={x-dimension=21590
y-dimension=27940} media-bottom-margin=432 media-left-margin=432
media-right-margin=432 media-top-margin=432 media-source=auto}
DEBUG2: Keyword: (null)
DEBUG2: Attr: orientation-requested-default
DEBUG2: Value: portrait
DEBUG2: Keyword: (null)
DEBUG2: Attr: output-bin-default
DEBUG2: Value: face-down
DEBUG2: Keyword: face-down
DEBUG2: Attr: output-mode-default
DEBUG2: Value: color
DEBUG2: Keyword: color
DEBUG2: Attr: print-quality-default
DEBUG2: Value: normal
DEBUG2: Keyword: (null)
DEBUG2: Attr: printer-resolution-default
DEBUG2: Value: 600dpi
DEBUG2: Keyword: (null)
DEBUG2: Attr: sides-default
DEBUG2: Value: one-sided
DEBUG2: Keyword: one-sided
DEBUG2: Attr: print-color-mode-default
DEBUG2: Value: color
DEBUG2: Keyword: color
DEBUG2: Attr: copies-supported
DEBUG2: Value: 1-1
DEBUG2: Keyword: (null)
DEBUG2: Attr: finishings-supported
DEBUG2: Value: none
DEBUG2: Keyword: (null)
DEBUG2: Attr: media-supported
DEBUG2: Value:
iso_a4_210x297mm,na_letter_8.5x11in,na_legal_8.5x14in,na_executive_7.25x10.5in,iso_a5_148x210mm,iso_a6_105x148mm,iso_b5_176x250mm,jis_b5_182x257mm,na_number-10_4.125x9.5in,iso_dl_110x220mm,iso_c5_162x229mm,na_monarch_3.875x7.5in,na_index-3x5_3x5in,om_folio_210x330mm,custom_min_76.2x127mm,custom_max_215.9x355.6mm
DEBUG2: Keyword: iso_a4_210x297mm
DEBUG2: Keyword: na_letter_8.5x11in
DEBUG2: Keyword: na_legal_8.5x14in
DEBUG2: Keyword: na_executive_7.25x10.5in
DEBUG2: Keyword: iso_a5_148x210mm
DEBUG2: Keyword: iso_a6_105x148mm
DEBUG2: Keyword: iso_b5_176x250mm
DEBUG2: Keyword: jis_b5_182x257mm
DEBUG2: Keyword: na_number-10_4.125x9.5in
DEBUG2: Keyword: iso_dl_110x220mm
DEBUG2: Keyword: iso_c5_162x229mm
DEBUG2: Keyword: na_monarch_3.875x7.5in
DEBUG2: Keyword: na_index-3x5_3x5in
DEBUG2: Keyword: om_folio_210x330mm
DEBUG2: Keyword: custom_min_76.2x127mm
DEBUG2: Keyword: custom_max_215.9x355.6mm
DEBUG2: Attr: media-col-supported
DEBUG2: Value:
media-type,media-size,media-top-margin,media-left-margin,media-right-margin,media-bottom-margin,media-source
DEBUG2: Keyword: media-type
DEBUG2: Keyword: media-size
DEBUG2: Keyword: media-top-margin
DEBUG2: Keyword: media-left-margin
DEBUG2: Keyword: media-right-margin
DEBUG2: Keyword: media-bottom-margin
DEBUG2: Keyword: media-source
DEBUG2: Attr: orientation-requested-supported
DEBUG2: Value: portrait,landscape
DEBUG2: Keyword: (null)
DEBUG2: Keyword: (null)
DEBUG2: Attr: output-bin-supported
DEBUG2: Value: face-down
DEBUG2: Keyword: face-down
DEBUG2: Attr: output-mode-supported
DEBUG2: Value: color,auto,monochrome
DEBUG2: Keyword: color
DEBUG2: Keyword: auto
DEBUG2: Keyword: monochrome
DEBUG2: Attr: print-quality-supported
DEBUG2: Value: normal,high
DEBUG2: Keyword: (null)
DEBUG2: Keyword: (null)
DEBUG2: Attr: printer-resolution-supported
DEBUG2: Value: 600dpi,2400x600dpi
DEBUG2: Keyword: (null)
DEBUG2: Keyword: (null)
DEBUG2: Attr: sides-supported
DEBUG2: Value: one-sided,two-sided-long-edge,two-sided-short-edge
DEBUG2: Keyword: one-sided
DEBUG2: Keyword: two-sided-long-edge
DEBUG2: Keyword: two-sided-short-edge
DEBUG2: Attr: print-color-mode-supported
DEBUG2: Value: auto,color,monochrome
DEBUG2: Keyword: auto
DEBUG2: Keyword: color
DEBUG2: Keyword: monochrome
DEBUG2: Attr: generated-natural-language-supported
DEBUG2: Value: en,fr
DEBUG2: Keyword: en
DEBUG2: Keyword: fr
DEBUG2: Attr: printer-uri-supported
DEBUG2: Value: ipp://copper.local./ipp/print
DEBUG2: Keyword: ipp://copper.local./ipp/print
DEBUG2: Attr: uri-security-supported
DEBUG2: Value: none
DEBUG2: Keyword: none
DEBUG2: Attr: uri-authentication-supported
DEBUG2: Value: none
DEBUG2: Keyword: none
DEBUG2: Attr: printer-name
DEBUG2: Value: copper[en]
DEBUG2: Keyword: copper
DEBUG2: Attr: printer-location
DEBUG2: Value: [en]
DEBUG2: Keyword:
DEBUG2: Attr: printer-info
DEBUG2: Value: Brother MFC-9340CDW[en]
DEBUG2: Keyword: Brother MFC-9340CDW
DEBUG2: Attr: printer-make-and-model
DEBUG2: Value: Brother
