Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When writing CUPS/PWG/Apple Raster compressed, byte-swapping never happens #5225

Closed
tillkamppeter opened this issue Jan 16, 2018 · 4 comments
Assignees
Milestone

Comments

@tillkamppeter
Copy link

In the function cupsRasterWritePixels() in filter/raster.c (libcupsimage) it was completely overlooked that when the output is compressed (r->compressed) AND byte-swap is needed (r-swapped AND high color depth > 8 bit) the byte-swapping has to done before compression.
I have found this by trying to print in the Adobe RGB color space with 16 bits per pixel (ADOBERGB48) in Apple Raster on my DeskJet 2540. This has given the correct structure but wrong colors on the print out. I have fixed the bug and after that I have gotten correct printouts in all 16-bit-per-pixel color spaces.

@tillkamppeter
Copy link
Author

Fix in pull request #5226.
I have tested all color depth on the DeskJet 2540 (Apple Raster), 8-bit and 16-bit and they are all working correctly now.
Note: rasterview has also a bug. It displayed the files correctly with this bug ond wrong after the fix.

@michaelrsweet
Copy link
Collaborator

Not taking PR #5226 but will provide a separate fix later today.

@michaelrsweet michaelrsweet self-assigned this Jan 16, 2018
@michaelrsweet michaelrsweet added this to the CUPS 2.3.x milestone Jan 16, 2018
michaelrsweet pushed a commit that referenced this issue Jan 17, 2018
… some

formats (Issue #5225)

filter/raster.c:
- Add debug logging for color spaces, modes, and offsets during writes.
- Fix byte swapping of compressed data in cupsRasterReadPixels.
- Add cups_copy_swap function that copies and swaps bytes.
- Use cups_copy_swap function when copying pixel data in cupsRasterWritePixels.

filter/testraster.c:
- Add logging of first 10 incorrect raster bytes.
- Fix PASS/FAIL logging of cupsRasterReadHeader2.
@michaelrsweet
Copy link
Collaborator

[master 7c91db7] The cupsRasterWritePixels function did not correctly swap bytes for some formats (Issue #5225)

@tillkamppeter
Copy link
Author

I have done the following tests to confirm that it works:

  • Build current snapshot of CUPS and install libcupsimage into the system
  • For screen display: Take rasterview 1.5 source, run make, then rebuild rasterview to use libcupsimage:
g++  -o rasterview RasterDisplay.o RasterView.o main.o -fPIE -pie -lfltk_images -lfltk -lX11 -lcupsimage
  • Take the high-color-depth-using PPD file x.ppd (attached, generated with cups-filters from the DeskJet 2540) and generate URF files running filter chains with the cupsfilter utility:
cupsfilter -p x.ppd -m image/urf -o ColorModel=Gray /usr/share/cups/data/testprint > g.urf
cupsfilter -p x.ppd -m image/urf -o ColorModel=RGB /usr/share/cups/data/testprint > s.urf
cupsfilter -p x.ppd -m image/urf -o ColorModel=AdobeRGB /usr/share/cups/data/testprint > a.urf

"Gray" and "AdobeRGB" are high color depth (16 bit) and RGB is normal color depth (8 bit). All display correctly in the rasterview from above and show the correct metadata, including bit depth and color space.

  • Printer test: Create a queue for the DeskJet 2540 with x.ppd. All three color modes come out correctly, so the printer supports the high color depths it advertises.

PPD file for these tests:
x.ppd.txt

michaelrsweet added a commit that referenced this issue Mar 7, 2018
- Fixed a compile issue when PAM is not available (Issue #5253)
- Documentation fixes (Issue #5252)
- Star Micronics printers need the "unidir" USB quirk rule (Issue #5251)
- The scheduler now supports using temporary print queues for older IPP/1.1 print queues like those shared by CUPS 1.3 and earlier (Issue #5241)
- The `cupsRasterWritePixels` function did not correctly swap bytes for some formats (Issue #5225)
- Added a USB quirk rule for Canon MP280 series printers (Issue #5221)
- The `ppdInstallableConflict` tested too many constraints (Issue #5213)
- More fixes for printing to old CUPS servers (Issue #5211)
- The `cupsCopyDest` function now correctly copies the `is_default` value (Issue #5208)
- The scheduler did not work with older versions of uClibc (Issue #5188)
- The scheduler now substitutes default values for invalid job attributes when running in "relaxed conformance" mode (Issue #5186)
- Fixed PAM module detection and added support for the common PAM definitions (Issue #5185)
- Fixed a journald support bug in the scheduler (Issue #5181)
- The cups-driverd program incorrectly stopped scanning PPDs as soon as a loop was seen (Issue #5170)
- Fixed group validation on OpenBSD (Issue #5166)
- Fixed the `ippserver` sample code when threading is disabled or unavailable (Issue #5154)
- The `cupsEnumDests` function did not include options from the lpoptions files (Issue #5144)
- The `SSLOptions` directive now supports `MinTLS` and `MaxTLS` options to control the minimum and maximum TLS versions that will be allowed, respectively (Issue #5119)
- The scheduler did not write out dirty configuration and state files if there were open client connections (Issue #5118)
- The `lpadmin` command now provides a better error message when an unsupported System V interface script is used (Issue #5111)
- The `lp` and `lpr` commands now provide better error messages when the default printer cannot be found (Issue #5096)
- No longer support backslash, question mark, or quotes in printer names (Issue #4966)
- The CUPS library now supports the latest HTTP Digest authentication specification including support for SHA-256 (Issue #4862)
- The `lpstat` command now reports when new jobs are being held (Issue #4761)
- The `lpoptions` command incorrectly saved default options (Issue #4717)
- The `ppdLocalizeIPPReason` function incorrectly returned a localized version of "none" (rdar:https://36566269)
- TLS connections now properly timeout (rdar:https://34938533)
- The IPP backend did not properly detect failed PDF prints (rdar:https://34055474)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants