Michael,
Thanks for the response to earlier comments from Xerox. Just a few additional comments on the same topic.
Given your explanation to Justin, and other "industry efforts", Xerox will accept your rejection of 1 through 5 (copied below for reference), although we believe IPP should have avoided PDL specific attributes. We have two ways to obtain the same information. The network overhead of attribute coloring is minimal and can be mitigated through parallel requests or technologies such as "Volley.
It is best the PWG mirror every IPP attribute in the PWG Semantic Model even if they are a side-effect of the protocol or of targeting specific markets/use cases.
Thanks,
/Daniel.
Here are the five comments (copied from an earlier email note):
IPP Attributes should be document format independent. Existing semantics should be used when they exist or corrected when additional semantics are required.
1) "jpeg-k-octets-supported" should be dropped in favor of the existing "k-octets-supported".
a. Note that IPP attribute coloring can be used to obtain document format specific values when required.
In actual implementation, the existing attribute (with multiple queries) was too inefficient. This attribute has been widely implemented in IPP printers since 2010.
My preference is to reject this request.
2) "pdf-k-octets-supported" should be dropped in favor of the existing "k-octets-supported".
In actual implementation, the existing attribute (with multiple queries) was too inefficient. This attribute has been widely implemented in IPP printers since 2010.
My preference is to reject this request.
(For reference, a Client might need to determine supported file formats and sizes in order to determine which format to send to the Printer. And certain file formats such as PWG Raster generally are streamed on both the Client and Printer so the job-k-octets-supported value is MAX vs. some smaller value for PDF or JPEG)
3) "pdf-versions-supported" should be dropped in favor of the existing "document-format-details-supported" ("document-format" and "document-format-version" members).
"document-format-version" is localized text, "document-format-details-supported" is a list of member attributes supported by the "document-format-details" attribute, and "document-format-version-supported" is a list of all of the localized version strings that are supported for all formats that is optionally filtered by document-format when you do a Get-Printer-Attributes request.
Since there is no way to register localized text values, filtering those values with multiple Get-Printer-Attributes requests is inefficient, and this attribute is supported by most IPP+PDF printers since 2010, my preference is to reject this request.
4) "jpeg-x-dimension-supported" and "jpeg-y-dimension-supported" should apply to any image format. The names should be changed to "max-image-x-dimension-supported" and "max-image -x-dimension-supported".
These attributes have been widely implemented since 2010. And as I've noted before doing multiple Get-Printer-Attributes requests is really inefficient.
My preference is to reject this request.
5) "printer-dns-sd-name" should be applicable to any service. The name should be changed to "dns-sd-name".
With a few exceptions, we prefix all Printer Description attributes that are not associated with Job/Document Template attributes with "printer-". And since DNS-SD is a *service* discovery protocol, not a device discovery protocol, I don't think dropping the "printer-" prefix or using an alternate prefix like "device-" makes sense. And FWIW CUPS has implemented "printer-dns-sd-name" for a very long time (since CUPS 1.2/2005 IIRC).
Scaling should not be print specific.
IPP = Internet Printing Protocol, so we are necessarily focused on printing. And as has been done in the past, SM can (and probably should) map print-scaling to ScalingMode (or whatever), just as print-quality is mapped to Quality, printer-resolution => Resolution, etc.
The PWG Semantic Model already defined a collection for scaling (i.e., "scaling"). Apparently we didn't quite get it right. The current definition allows for explicit scaling (i.e., "scaling-height" and "scaling-width") or a boolean for "auto-scaling". The explicit scaling member should be kept. The Boolean "auto-scaling" should be deprecating and an attribute with a unique name (e.g., "auto-scale-mode") should replace it with the semantics defined for "print-scaling"
FWIW, CUPS previously supported two other attributes for scaling in the past - "scaling" (scale to a percentage of the media size) and "natural-scaling" (scale to a percentage of the document size). This allowed for "poster" printing over multiple media sheets, among other things, but had a lot of limitations and implementation issues. (BTW, we only ever supported symmetric scaling: scaling-width == scaling-height)
I *can* see the use case for copy - copy this hardcopy document and enlarge to 200% - but for print the 99% use case is "enlarge this document/image to fit/fill these (media) dimensions". In many cases there are no (reliable) physical dimensions to work with, so saying "enlarge to 200%" has no meaning. However, you can always say "fit/fill the document data on the requested media".
Also, the current Scaling group in SM is not part of the Print service, just under the Copy, FaxIn, FaxOut, and Scan services (under <service>DocumentProcessing).
My preference is to reject this request.
From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Michael Sweet
Sent: Friday, September 06, 2013 10:05 AM
To: Justin Hutchings
Cc: ipp at pwg.org
Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based Printing Extensions specification and has comments
Justin,
Fair enough, we do have use cases but will highlight for each of the attributes.
On Sep 6, 2013, at 12:53 PM, Justin Hutchings <justhu at microsoft.com<mailto:justhu at microsoft.com>> wrote:
Thanks for your quick response, Mike. It might be worthwhile to articulate the rationale as to why these are required in the spec. I didn't pick up on all that during my read through.
Thanks!
Justin
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Friday, September 6, 2013 7:00 AM
To: Justin Hutchings
Cc: ipp at pwg.org<mailto:ipp at pwg.org>; Ira McDonald; Paul Tykodi
Subject: Re: [IPP] Microsoft has reviewed the IPP Transaction-Based Printing Extensions specification and has comments
Justin,
Thank you for your feedback! Quick comments inline...
On Sep 5, 2013, at 6:06 PM, Justin Hutchings <justhu at microsoft.com<mailto:justhu at microsoft.com>> wrote:
- OpenXPS has a MIME type of application/oxps, not application/OpenXPS (http://www.iana.org/assignments/media-types/application/oxps)
Oops, will fix.
- This spec appears to have a bunch of content which is completely unrelated to the transaction based printing. Why are we throwing these into what would otherwise be a very straightforward, to-the-point spec?
These have particular application to commercial print services and service discovery.
o Print-scaling-supported
o Print-scaling-default
These provide control over the final imposition/scaling of the document data on the output media - important particularly for commercial print services.
o Printer-dns-sd-name
This is used for service discovery; we need to have a way to configure the service name.
o Printer-kind
This is used for service selection/filtering - again, if you are looking for a print service that supports the kind of document you are printing, you need this information.
(this is also part of the DNS-SD TXT record, but DNS-SD is not the only way to do discovery)
o Jpeg-*
o Pdf-*
These are used to inform the Client of limits for direct photo and PDF printing - having dealt with a lot of commercial print shops over the years, it is VERY important for the Client to be able to know whether they support a particular flavor of PDF or have limits in the maximum size/dimensions of print files.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
_______________________________________________
ipp mailing list
ipp at pwg.org<mailto:ipp at pwg.org>
https://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20130913/c3ae7b34/attachment.html>