[SM3] [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments

[SM3] [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments

[SM3] [IPP] Xerox has reviewed the IPP Transaction-Based Printing Extensions specification and has comments

Manchala, Daniel Daniel.Manchala at xerox.com
Fri Sep 13 20:45:59 UTC 2013


Michael,

The Semantic Model defines Scaling thus:

Scaling (complex) {
                ScalingHeight (range of int)
                ScalingWeight (range of int)
                AutoScaleMode (keyword) //values of 'auto, 'fit', 'auto-fit', 'fill' and 'none'; SM to change replace boolean with keyword.
                }

Why don't we translate this into IPP as follows?:

print-scaling(collection) {
                scaling-height(integer(1:100)) //expressed as a percentage.
                scaling-width(integer(1:100))
                auto-scale-mode(type2 keyword) //values of 'auto', 'auto-fit', 'fit', 'fill' and 'none'
                }


Thanks,
Daniel.


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

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.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair




More information about the sm3 mailing list