Detecting Adobe Acrobat’s "Print in grayscale" Checkbox in CUPS Backend

[shubham_2242]

Hi Adobe Community,

I'm working on a custom CUPS printer backend for macOS and have encountered an issue specifically when printing from Adobe Acrobat.

In the Acrobat print dialog, there's a checkbox labeled “Print in grayscale (black and white)”. When a user checks this box and prints, I don't see any standard CUPS job option (like ColorModel, color, or cupsColorMode) passed to the backend. However, when users instead go into Printer > Printer Features > Color Mode and select "Grayscale", that option does correctly appear as ColorModel=Gray in the job options.

This makes it difficult to accurately capture the user’s color intent when the grayscale checkbox is used.

I'm trying to understand:

• Does this checkbox actually send any distinguishable job option to the backend?

• Or does it flatten the PDF to grayscale before sending, making it impossible to detect via job options?

• Has anyone found a reliable method to infer if this checkbox was used — maybe through PDF content inspection, internal tags, or hidden job options?

Any documentation, flags, or Acrobat-specific behavior details would be extremely helpful. I'm trying to ensure our backend respects the user's grayscale intent no matter which route they take in the print dialog.

[creative explorer]

@shubham_2242 it sounds like when you checks Acrobat's "Print in grayscale (black and white)" checkbox, Acrobat is indeed flattening or converting the PDF content to grayscale before handing it off to the CUPS spooler. This means the data arriving at your backend is already grayscale, and there's no explicit CUPS job option passed because Acrobat has already handled the color conversion at the application level. Detecting this reliably at the backend level without a standard job option is challenging. While theoretically, you might try PDF content inspection (e.g., checking for specific color spaces like DeviceGray, or the absence of DeviceRGB/CMYK objects), this would be complex, prone to error, and might not catch all scenarios (e.g., if a black-and-white image is still technically in an RGB color space but just contains grayscale data). 

Unfortunately, I can't see any widely documented public information about hidden job options or internal tags for this specific Acrobat checkbox. Your best bet for absolute certainty might be to continue recommending users use the "Printer Features > Color Mode" option if grayscale detection is critical for your backend's functionality.

[shubham_2242]

Hi Creative Explorer,

I’m developing a macOS printer driver using CUPS and PPD, and I’m currently trying to solve an issue related to how Adobe Acrobat handles grayscale printing.

The Issue:

When a user selects “Print in grayscale (black and white)” in Acrobat’s print dialog (not the system dialog), Acrobat converts the PDF content to grayscale before sending the job. However, the backend receives no job option like ColorModel=Gray, making it impossible for the driver to know whether the user intended to print in grayscale.

In contrast, when printing from other apps like Chrome, Safari, MS Word, or Preview:

• The PDF content is always in color, regardless of the user’s grayscale selection.

• The correct CUPS job option (ColorModel=Gray) is passed, allowing my driver to apply grayscale conversion if needed.

Why This Is a Problem:

My driver relies on ColorModel or similar options to process grayscale prints correctly. Since Acrobat skips this step and directly sends a pre-converted grayscale PDF (without flags), my logic breaks.

What I’d Like to Do:

To handle this properly, I want to detect which application sent the print job. If I can detect that the job came from Adobe Acrobat, I can:

• Use PDF content analysis to detect grayscale in Acrobat jobs.

• Use job options (ColorModel, etc.) for all other applications.

My Question:

Is there any way to identify the source application (like Adobe Acrobat) in a CUPS print job?

For example:

• Is there a CUPS field like job-originating-application-name?

• Is there any Adobe-specific metadata in the job that the backend could use?

Any suggestions or tips on detecting Acrobat as the job source would be a big help.

Thanks so much for your time!

Best regards,
Shubham Narang