[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

Michael Sweet msweet at apple.com
Sat Sep 14 01:01:13 UTC 2013


Daniel,

The "print-scaling" attribute, as defined in the IPP Transaction-Based Printing Extensions, is already implemented in shipping IPP printers and CUPS since v1.6.

*If* we wanted percent scaling (which I do not support), we'd need to define a print-scaling-col attribute or something (a different name).  However, since SM Scaling is not part of Print (it is specifically used for hardcopy documents) I don't think we need to tie IPP to it. And I think we will have a hard time agreeing on what the percentages are based on - remember CUPS tried both percent-of-output-media and percent-of-input-document and neither worked well.


On Sep 13, 2013, at 4:45 PM, Manchala, Daniel <Daniel.Manchala at xerox.com> wrote:

> 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
>  
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair




More information about the sm3 mailing list