ppd-cache.c: Use PPD size name from CUPS if size is standardized

[zdohnal]

Previously, if there were two sizes with the same size, but different names in PPD, the second was ignored during generating sizes for PPD cache. This behavior breaks already broken PPDs, which provide two or more different size names for the same width and length (which is incorrect), and if the ignored size was the PPD default (such as A4), user couldn't print a test page.

After this fix, we use PPD size name from CUPS if the size is standarized.

Fixes #29

[tillkamppeter]

This part of ppd-cache.c exists in both the versions of CUPS and libppd. We should try to keep the 2 in sync. Did you post a similar PR for CUPS?

[tillkamppeter]

Generally your change is OK, and it works at least if the default page size name is a standard one.

It does not work if

• The default page size name is not a standard one, then the page size in the cache would carry the standard name which is different to the default name. Here it has to be checked what the default name is and if we handle the size with the default name as PPD name, either do not change the PPD name to the standard one or also change the default name to the standard one.
• The default size is not a standard size In this case our size will not get its name changed and so in case of the size existing more than once with different names the first name in the list wins which is not necessarily the default name. So if we discard a size as duplicate and it happens to be the one with the default name, we have to keep it and discard the previously accepted size instead.

[szlt5]

I'm experiencing the same problem.
There are two papers of the same size with different opening direction on Japanese market: [Envelope NAGATA3] & [Envelope YOUGATANAGA 3].

[This is Envelope NAGATA3]

[This is Envelope YOUGATANAGA 3]

The two papers are printed well with cups-filter-1.x.
After upgrading to cups-filter-2, only the [NAGATA3] is printed well; the printed image on the [YOUGATANAGA 3] is cut off.

Can this PR fix this problem? @zdohnal
Anyway, I will test it after the PR is accepted. :)

[szlt5]

which provide two or more different size names for the same width and length (which is incorrect)

I think it is not incorrect.
There are several envelope papers with the same size are recognized as different papers because of the different opening orientations (Another example: Envelope C5 & Japanese Envelope size 6 (角形6号) ).

[zdohnal]

Can this PR fix this problem? @zdohnal Anyway, I will test it after the PR is accepted. :)

I'm sorry, I don't have time atm to work to incorporate changes which Till mentioned. If you would like to have it fixed sooner, feel free to take the PR and implement the changes Till mentioned.

which provide two or more different size names for the same width and length (which is incorrect)

I think it is not incorrect. There are several envelope papers with the same size are recognized as different papers because of the different opening orientations (Another example: Envelope C5 & Japanese Envelope size 6 (角形6号) ).

IMHO different opening orientation is not reflected in invocations of PageSize keyword options - PageSize covers length and width of paper, not where the text or opening gap is.

[michaelrsweet]

@szlt5

which provide two or more different size names for the same width and length (which is incorrect)

I think it is not incorrect. There are several envelope papers with the same size are recognized as different papers because of the different opening orientations (Another example: Envelope C5 & Japanese Envelope size 6 (角形6号) ).

Let's restate this: IPP's media size naming standard requires that sheet sizes (and that includes envelopes since they are fed like sheets) be represented using their portrait dimensions - the feed orientation is a separate attribute since the printer's paper path might pull media from any edge and that pull edge might even be (and often is) different based on the tray used.

Thus, two envelopes with the same physical dimensions use the SAME media size name but might report two different media feed orientations. From the standpoint of a PPD file, there is no way to differentiate between the media sizes. And if you had an IPP printer with both types of envelope loaded, you can expect the wrong things to happen...

WRT your example, how is the content cut off on the other envelope size? Is it a rotation issue (i.e. the envelope is fed in the landscape orientation but the content is printed portrait) or is the output correctly oriented but cut off?

[szlt5]

WRT your example, how is the content cut off on the other envelope size? Is it a rotation issue (i.e. the envelope is fed in the landscape orientation, but the content is printed portrait) or is the output correctly oriented but cut off?

It is not a rotation issue; it is an issue caused by the libcupsfilter2.x.
Print successful cases (Envelope NAGATA3): libcupsfilter2.x passed the right image.
Print error case (Envelope YOUGATANAGA 3): libcupsfilter2 passed a letter-sized image.

Print both page size well by using the libcupsfilter1.x

[szlt5]

Further investigation result:

• When generating sizes for PPD cache, use 0.5mm as the maximum delta.

pwg_media_t *				// O - PWG media name
pwgMediaForSize(int width,		// I - Width in hundredths of millimeters
		int length)		// I - Length in hundredths of millimeters
{
  // Adobe uses a size matching algorithm with an epsilon of 5 points, which
  // is just about 176/2540ths...  But a lot of international media sizes are
  // very close so use 0.5mm (50/2540ths) as the maximum delta.
  return (_pwgMediaNearSize(width, length, _PWG_EPSILON));
}

• After generating the PPD cache, the NAGATA3 is mapped to "jpn_chou3_120x235mm" but the YOUGATANAGA3 is abandoned.
• When printing YOUGATANAGA3, the code (in function ppdLoadAttributes) tries to find one in the PPD cache with the same size. The YOUGATANAGA3 size in the ppd file is 2 hundredths of millimetres (0.02mm) larger than "jpn_chou3_120x235mm" but the allowed error range is 1 hundredths of millimetres(0.01mm); so finding by size failed. The code uses the default size "letter" as instead.

	//
	// Try to find one with the same size...
	//

	if (!default_size)
		for (i = 0, pwg_size = pc->sizes; i < pc->num_sizes; i++, pwg_size++)
		{
			if (_PPD_PWG_EQUIVALENT(PWG_FROM_POINTS(ppd_size->width), pwg_size->width) &&
				_PPD_PWG_EQUIVALENT(PWG_FROM_POINTS(ppd_size->length), pwg_size->length))
			{
				default_size = pwg_size;
				break;
			}
		}

So the bug can be fixed by updating the macro _PPD_PWG_EQUIVALENT from 2 to 51 (0.5mm is consistent with the pwgMediaForSize). @tillkamppeter @zdohnal

[zdohnal]

@szlt5 if you know it is the correct fix, feel free to file a PR and Till will review it once he gets a chance. But IMHO widening the error range could bring more side effects than fixing matching of similar page size... by wdyt, @tillkamppeter ?

@tillkamppeter can you give us some fake PPD examples of the cases you mentioned we should cover? Tbh I had difficulty to imagine what you mean, and since I had other pressing matters, then I had difficulty to return back to it.

I hope once we see the PPD code examples of what you mean, it would be easier to implement it.

[michaelrsweet]

@szlt5 if you know it is the correct fix, feel free to file a PR and Till will review it once he gets a chance. But IMHO widening the error range could bring more side effects than fixing matching of similar page size... by wdyt, @tillkamppeter ?

@tillkamppeter can you give us some fake PPD examples of the cases you mentioned we should cover? Tbh I had difficulty to imagine what you mean, and since I had other pressing matters, then I had difficulty to return back to it.

I hope once we see the PPD code examples of what you mean, it would be easier to implement it.

The current epsilon value in the CUPS sources is 50 (equivalent to 0.5mm) which is what we should be using. Smaller values will only cause problems, and the half-millimeter tolerance is what we recommend at the PWG. Honestly most media sensors, if available, are only accurate to 1mm and the manufacturing tolerances for paper are similarly in the .Nmm range.

[zdohnal]

@szlt5 @michaelrsweet ok, I have created PR for change of delta and I tested it against the original problem, and unfortunately it did not fix it - so what @szlt5 found was another issue. The original still needs fixing.

[zdohnal]

Closing this due #46 .