#762 DNP QW410 / Citizen CZ-01: Incorrect 4x6 Image Width Causes Horizontal Scaling and Aliasing

[Torben Schinke]

You can see the aliasing/interpolation artifacts in the upper left corner underneath the blue umbrella at the diagonal cable in the attachment.

Analyis:

Gutenprint uses incorrect horizontal margins for 4x6 output on the DNP QW410 / Citizen CZ-01.

The printer protocol requires a 1408x1836 raster. Comparison with Citizen's official macOS driver shows that the correct active image area is:

x = 92..1315
width = 1224 pixels

Gutenprint currently defines 71-pixel margins:

DEFINE_PAPER(
  "w288h432", "4x6",
  PT(1408,300), PT(1836,300),
  PT(71,300), PT(71,300), 0, 0,
  DYESUB_PORTRAIT
)

This produces:

x = 71..1336
width = 1266 pixels

Consequently, Gutenprint horizontally scales the 1224x1836 CUPS raster to 1266x1836. The scaling is anisotropic and uses dyesub_interpolate(), which is point/nearest-neighbor sampling. It introduces clearly visible stair-step aliasing on diagonal edges.

The official macOS driver does not perform this scaling.

Tested Environment

Printer: Citizen CZ-01
USB ID: 1343:000c
Gutenprint: 5.3.4 and current master
CUPS raster: 1224x1836, RGB, 300 dpi
Output protocol raster: 1408x1836

Root Cause

The 71-pixel margins are defined internally in the Gutenprint dye-sub driver. They cannot be corrected through the PPD or standard CUPS scaling options.

Proposed Fix

Change the 4x6 horizontal margins from 71 to 92 pixels:

-  DEFINE_PAPER( "w288h432", "4x6", PT(1408,300), PT(1836,300), PT(71,300), PT(71,300), 0, 0, DYESUB_PORTRAIT),
+  DEFINE_PAPER( "w288h432", "4x6", PT(1408,300), PT(1836,300), PT(92,300), PT(92,300), 0, 0, DYESUB_PORTRAIT),

This gives the correct active width:

1408 - 92 - 92 = 1224

After applying the patch:

Gutenprint:    x=92..1315, width=1224
macOS driver:  x=92..1315, width=1224

The unnecessary horizontal resampling is eliminated, and physical test prints no longer show the aliasing artifacts.

The change was verified both with synthetic raster patterns and real photographs on the Citizen CZ-01.

AI Assistance Disclosure

AI tools assisted with analyzing the captured print streams and drafting this report. All measurements, comparisons, code changes, and physical print results described above were independently reproduced and verified on the actual hardware.

[Solomon Peachy]

The CZ-01 requires a raster image width of 1408 pixels on all prints. However, on 4" media, only the center 1266 pixels are used. 1408-1266 == 142. 142 / 2 == 71 (on either side) which not-so-coincidentally matches the DEFINE_PAPER definition of a full 1408 pixels wide, an "imageable area" of 1266 pixels, with 71 pixel non-printable margins on either side. This produces the following in the PPD:

*PageSize w288h432/4x6: "<</PageSize[337.920 440.640]/ImagingBBox null>>setpagedevice"
*ImageableArea w288h432/4x6:    "17.040 0.000 320.880 440.640"

(320.880-17.040)/72*300 = 1266 pixels wide
(440.640-0.000)/72*300 = 1836 pixels tall

Yet, for some reason, despite Gutenprint unambiguously telling you (and any application that queries this information) what image dimensions are expected (ie 1266x1836), you are deliberately submitting a source image that is different (ie 1224x1836), and are somehow surprised that that it is being scaled?

In other words: Submit the image with the dimensions that Gutenprint says it wants, not the size that a different driver wants.*

FYI, It was abundantly clear that AI tools were used to produce this not-a-bug report.

[Torben Schinke]

Thanks for pointing that out, it must have been to late for me. It was never my goal to offend anyone. I'm in no way an expert for printing machines and processes and I ported my photobox project from MacOS to a Linuxbox and considered everything between the printer and my invocation as a blackbox. From a user perspective I naturally expect that two blackboxes behave identical for the same input. Even though I double checked my params, I obviously used a "wrong" input. Convinced that my input was correct (also because it worked on another machine) and not considering Hyrum's Law, I indeed prompted the AI very specificly to "find and fix the difference".