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

ippeveprinter and pagesize tolerance #487

Closed
jubork opened this issue Sep 21, 2022 · 3 comments
Closed

ippeveprinter and pagesize tolerance #487

jubork opened this issue Sep 21, 2022 · 3 comments
Assignees
Labels
enhancement New feature or request priority-medium
Milestone

Comments

@jubork
Copy link

jubork commented Sep 21, 2022

ippeveprinter (2.4.2) does not allow for any pagesize tolerance.
I'm not sure whether IPP standard allows for any.
The relevant code is (ippeveprinter.c:8779)

      for (i = 0; i < count ; i ++)
      {
        size  = ippGetCollection(supported, i);
        x_dim = ippFindAttribute(size, "x-dimension", IPP_TAG_ZERO);
        y_dim = ippFindAttribute(size, "y-dimension", IPP_TAG_ZERO);

        if (ippContainsInteger(x_dim, x_value) && ippContainsInteger(y_dim, y_value))
          break;
      }

The problem comes from the fact that IPP specifies page size in 0.01mm units,
while PPDs usually in integer postscript points (1/72 inch). The conversion between the two
may introduce small offset, and a print job submitted to ippeveprinter may
be rejected during verify phase.

The quick&dirty (very little testing done) patch below implements
more robust conversion algorithm, which seems to work for me
for a couple of printers/PPDs.

cups-2.4.2-pspoints.patch.txt

However, I think better approach would be to allow for some page size tolerance,
i.e. via command line option. The default could be zero for compatibility.

On a side note, the patch also improves handling of IPP_TAG_ENUM options.
Without it, conversion of enums to integer gives often zero (again very little
testing done).

@michaelrsweet
Copy link
Member

@jubork There is no hard requirement for media size tolerance, although the current guidance says the following:

A requested media size dimension matches a supported media dimension if it is within an implementation-defined tolerance. For example, PostScript specifies a tolerance of 5 points (5/72 of an inch = 1.7 mm) of a supported dimension, i.e., within 176 units of the value of the dimension.

The PWG media functions in libcups use a tolerance of 1mm.

@michaelrsweet michaelrsweet self-assigned this Sep 21, 2022
@michaelrsweet michaelrsweet added enhancement New feature or request priority-medium labels Sep 21, 2022
@michaelrsweet michaelrsweet added this to the v2.4.x milestone Sep 21, 2022
@michaelrsweet
Copy link
Member

Oh, and reviewing the patch we really couldn't use it - the encode.c changes would break existing clients, and I'm not sure how all the rounding/truncation you are doing will affect things (particularly for metric sizes).

The correct fix should allow for a tolerance range when checking...

@michaelrsweet
Copy link
Member

[master e2fb1f4] Allow media-size values to match within +/-1mm (Issue #487)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority-medium
Projects
None yet
Development

No branches or pull requests

2 participants