New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 706003 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

cups: black and white printjob printed in color

Project Member Reported by adlr@chromium.org, Mar 28 2017

Issue description

Chrome Version: 57.0.2987.75 (Official Build) beta (64-bit)
OS: 9202.37.0 (Official Build) beta-channel tricky

What steps will reproduce the problem?
(1) Print color email from Google Inbox
(2) In print dialog box, select Florida-color as printer and change to Black and White printing
(3) Print!

What is the expected result?

Black and white

What happens instead?

Color comes out of the printer
 
Labels: -Pri-1 Pri-2
Interesting!

Off the top of my head, I"ve no idea where the control for that lies -- if B&W is selected, is chrome supposed to send a B&W pdf to the print system, or is that handled at the print layer?

Will investigate, but lowering priority because trying to finish up stuff for 59

Comment 2 by skau@chromium.org, Mar 28 2017

Florida-color uses the generic PS PPD.  I suspect that Ricoh might specify black and white differently than what's in the PPD so the attribute gets ignored.  But we'll need to look into it to verify.

Comment 3 by skau@chromium.org, Apr 14 2017

Cc: -skau@chromium.org weifangsun@chromium.org justincarlson@chromium.org
Labels: -Pri-2 Pri-1
Owner: skau@chromium.org

Comment 4 by skau@chromium.org, Apr 14 2017

Labels: M-59
One of the partners is reporting this problem is widespread.  There might be a bug in how Chrome handles the color attributes.

Comment 5 by skau@chromium.org, Apr 14 2017

Status: Started (was: Assigned)

Comment 6 by skau@chromium.org, Apr 20 2017

There appears to be at least one problem here.  print-color-mode=monochrome is not being interpreted correctly by gstoraster.  cupsColorSpace should be 0 or 18 in this situation but it is set to 1 (RGB).

https://www.cups.org/doc/spec-raster.html

It is unknown if other problems exist in the pipeline.

I will investigate if pdftopdf is working correctly.

Comment 7 by skau@chromium.org, Apr 20 2017

Path known to fail:
pdftopdf -> gstoraster -> hpcups -> ipp

Autoconf paths seem to work.  However, PPDs are also different.  Those paths use:
pdftopdf -> gstoraster -> rastertopwg

Comment 8 by skau@chromium.org, Apr 28 2017

The root cause is that in ppd-cache.c, CUPS does not recognize values for ColorModel other than Gray.  This causes print-color-mode=monochrome to be dropped when encoding options for processing by the filters.  The fix for this is to add the non-standard gray values that we're aware of to the ppd parsing code.
Project Member

Comment 9 by bugdroid1@chromium.org, May 4 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/23cc92057a4e6e8e33ce2727ac1f909ec0e783c9

commit 23cc92057a4e6e8e33ce2727ac1f909ec0e783c9
Author: Sean Kau <skau@chromium.org>
Date: Thu May 04 02:40:25 2017

net-print/cups: Add non-standard grays to CUPS PPD parsing.

CUPS currenlty only parses the 'Gray' value for ColorModel.  This
prevents the IPP attribute print-color-mode=monochrome from being
encoded in print jobs when other Gray values are not recognized.

Gray values were derived by running the following over our PPD
repository:
grep '^\*ColorModel' *.ppd | sort | uniq

TEST=Print a test page in both Color and Black and White on a
printer using KGray and RGB as the ColorModel choices.
BUG= chromium:706003 

Change-Id: Ib833476d601abe306662a1d0e2b9d68461ce983d
Reviewed-on: https://chromium-review.googlesource.com/489463
Commit-Ready: Sean Kau <skau@chromium.org>
Tested-by: Sean Kau <skau@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Justin Carlson <justincarlson@chromium.org>

[modify] https://crrev.com/23cc92057a4e6e8e33ce2727ac1f909ec0e783c9/net-print/cups/cups-2.1.4.ebuild
[add] https://crrev.com/23cc92057a4e6e8e33ce2727ac1f909ec0e783c9/net-print/cups/files/cups-2.1.4-non-standard-grays.patch
[rename] https://crrev.com/23cc92057a4e6e8e33ce2727ac1f909ec0e783c9/net-print/cups/cups-2.1.4-r16.ebuild

Comment 10 by skau@chromium.org, May 4 2017

Labels: Merge-Request-59
Status: Fixed (was: Started)
Labels: Merge-Approved-59
Labels: -Merge-Request-59
Project Member

Comment 13 by bugdroid1@chromium.org, May 4 2017

Labels: merge-merged-release-R59-9460.B
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/549a7977401e9a26b0bd2d9f1bffc94d9e8e5169

commit 549a7977401e9a26b0bd2d9f1bffc94d9e8e5169
Author: Sean Kau <skau@chromium.org>
Date: Thu May 04 18:36:47 2017

net-print/cups: Add non-standard grays to CUPS PPD parsing.

CUPS currenlty only parses the 'Gray' value for ColorModel.  This
prevents the IPP attribute print-color-mode=monochrome from being
encoded in print jobs when other Gray values are not recognized.

Gray values were derived by running the following over our PPD
repository:
grep '^\*ColorModel' *.ppd | sort | uniq

TEST=Print a test page in both Color and Black and White on a
printer using KGray and RGB as the ColorModel choices.
BUG= chromium:706003 

Change-Id: Ib833476d601abe306662a1d0e2b9d68461ce983d
Previous-Reviewed-on: https://chromium-review.googlesource.com/489463
(cherry picked from commit 41a070188ed11fda151bbf3288679acab2dd938e)
Reviewed-on: https://chromium-review.googlesource.com/495808
Tested-by: Sean Kau <skau@chromium.org>
Trybot-Ready: Sean Kau <skau@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Commit-Queue: Sean Kau <skau@chromium.org>

[modify] https://crrev.com/549a7977401e9a26b0bd2d9f1bffc94d9e8e5169/net-print/cups/cups-2.1.4.ebuild
[add] https://crrev.com/549a7977401e9a26b0bd2d9f1bffc94d9e8e5169/net-print/cups/files/cups-2.1.4-non-standard-grays.patch
[rename] https://crrev.com/549a7977401e9a26b0bd2d9f1bffc94d9e8e5169/net-print/cups/cups-2.1.4-r16.ebuild

Project Member

Comment 14 by sheriffbot@chromium.org, May 8 2017

Cc: gkihumba@google.com
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 15 by skau@chromium.org, May 8 2017

Labels: -Merge-Approved-59
merged on Thursday

Comment 16 by skau@chromium.org, May 12 2017

Merged in 9460.26.0
Issue 742680 has been merged into this issue.

Comment 18 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment