ppd-mark: try to map PageSize to PPD if media is missing. Fixes #1375

[ValdikSS]

When CUPS prints to another CUPS over IPP, it uses PageSize instead of media or media-col, as it is assumed that PPD files (or at least the attribute values) are synced on both sides.

However this is not the case with ippeve or drvless auto-generated PPDs, where only Adobe names are used for page sizes instead of the values on the remote side, which makes page selection inconsistent.

Try to map Adobe names to PPD names on the server side, if only PageSize is provided in IPP request.

[michaelrsweet]

OK, "media" trumps InputSlot, MediaType, PageRegion, and PageSize. If "media" is not set then this mapping should be happening later in the cupsMarkOptions function, which calls ppd_mark_option.

What probably needs to happen here is for this PageSize logic to be moved to ppd_mark_option, otherwise we aren't covering all places that might mark a PPD size using a PWG name. Also, if ppd->cache is NULL, don't try the mapping...

[ValdikSS]

OK, "media" trumps InputSlot, MediaType, PageRegion, and PageSize. If "media" is not set then this mapping should be happening later in the cupsMarkOptions function, which calls ppd_mark_option.

I'm not sure if I follow. Right now as far as I understand marking PageSize in cupsMarkOptions with ppd_mark_option will overwrite InputSlot/MediaType to the defined in the PPD for this PageSize, proper InputSlot/MediaType would be (re)defined later in else clause if supplied over IPP, and that seems like an appropriate handling. Is this not correct?

Or wait, does the order of PageSize/Media/InputSlot/... matters, and they are not reordered on the server side before being processed? And if Media goes after PageSize, it will redefine?

Also, if ppd->cache is NULL, don't try the mapping...

Null check is present in _ppdCacheGetPageSize, I checked it

[michaelrsweet]

@ValdikSS

OK, "media" trumps InputSlot, MediaType, PageRegion, and PageSize. If "media" is not set then this mapping should be happening later in the cupsMarkOptions function, which calls ppd_mark_option.

I'm not sure if I follow. Right now as far as I understand marking PageSize in cupsMarkOptions with ppd_mark_option will overwrite InputSlot/MediaType to the defined in the PPD for this PageSize, proper InputSlot/MediaType would be (re)defined later in else clause if supplied over IPP, and that seems like an appropriate handling. Is this not correct?

Right now "PageSize" only handles PPD sizes while "media" handles both PPD and PWG size names. Your change overrides (without replacing the value of) PageSize when it isn't a PPD name in cupsMarkOptions, but there are other places where ppd_mark_option can get called. Thus, moving the PageSize PWG media size mapping logic into ppd_mark_option will ensure that both the right order of precedence and the mapping happen under all circumstances.

Or wait, does the order of PageSize/Media/InputSlot/... matters, and they are not reordered on the server side before being processed? And if Media goes after PageSize, it will redefine?

The order of processing matters, but there are multiple places where ppd_mark_option is called so we want to make sure the PWG media size name support is present in all of those code paths. The simplest fix is to move your PageSize change to the ppd_mark_option function.

Also, if ppd->cache is NULL, don't try the mapping...

Null check is present in _ppdCacheGetPageSize, I checked it

Fair enough, I wasn't sure and we don't usually have those sorts of checks in the private APIs.