Universal Print not supporting IPP tag "nameWithoutLanguage" for attribute "media-type-supported"

Copper Contributor


we are testing our custom Universal Print connector, which updates the printers' attributes using the ones coming from the printers via IPP.

We were able to print on some of the printers, specifically the ones for which the attribute "media-type-supported" was of type "1setOf(keyword)". Instead, we couldn't print on the printers which had "1setOf(nameWithoutLanguage)" as a type for that attribute: the spooler failed to send the print job to Universal Print.

Is this behavior intentional? Considering the IPP document describing that attribute, "keyword" and "name" (i.e. "nameWithLanguage" or "nameWithoutLanguage") should be allowed.


As a workaround, at the moment we are overriding that tag, but in the future we would like to validate the attributes using a fixed criterion, that's why we are reporting this issue.




4 Replies

Hello, we are also experiencing the same problem. Same printer but we cannot print on windows 20H2 and window 2004 versions.
When the media-type-supported property is overridden, only the first job can be sent to the Universal Printer, and from the second job no status or error messages are returned.
Do you have such a situation.
Can you send me the value you override?


Hi, I just want to point out that we are not overriding its value (or rather values, since it's a list) but its IPP tag(s). The values comes straight out of the printer, but sometimes they come with the tag "nameWithoutLanguage" (which byte value is 0x41), instead of "keyword" (0x44). So the only thing we do is changing that 0x41 bytes into 0x44.

However, you can find a json file in the attachments with such values and tags.


By the way - as far as I know - I can print multiple times when that workaround is used.

Yes as per IPP, media-type-supported can be either "keyword" or "name". However, Microsoft Windows supports only the "keyword" values and skips the "name" values for media-type-supported attribute.

thank you for confirming that.
Can you tell me if there is a way to know in advance which types and values are allowed/supported by Universal Print for the attributes to provide when registering the printer? It would be very helpful to perform some sort of validation before registering the printer.

For example, we are having issues with the attribute "pclm-strip-height-supported" which the IPP specification says should be of type integer (and be a power of 2), but supplying such values results in an error response.