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