On Sun 16 Jul 2017 at 14:38:44 +0000, 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 +0000, 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 <queue_name> /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.
