On Apr 25, 2011, at 9:45 AM, Petrie, Glen wrote:
> ...
>> [gwp] What, this is the very definition of incompatibility; I a devices receives a CUPS raster file with some vendor-data in the position of the page number and it does not represent the page number then no telling what will happen.
>
By definition all of these fields are driver-specific and cannot be interpreted outside that particular driver.
(in this case a PWG Raster driver)
> [gwp] If you change the PWG raster file identifier so it does not match CUPS raster then is this not produce a conflict; because they would not longer be the same thing. Right now, no one reading a CUPS raster or PWG raster change tell which is which.
>
Actually, you can - if the PageSize field is all 0's, then it isn't a CUPS Raster file which will always have the media size in integer points...
> [gwp] I disagree. You mean that your/the proposed Job Ticket does have the duplex setting or the layout orientation data. If not, how can someone ever generate the correct print output!!!
>
The job ticket has "sides", which is an instruction to do duplex printing. However, it doesn't tell the printer how the raster data was generated.
> The Job Ticket will specify the output format (duplex, flip, rotate); therefore, transforms data and information are part of the Job Ticket and the raster must be transformed to the correct orientation required so that the printer (or any consumer of the raster) does not know or have to perform the transforms.
>The job ticket has "sides" and "orientation-requested". We don't require the printer support anything other than "portrait" orientation and the printer tells the client how to send the back side of duplex pages, so the client may have to pre-rotate/flip the bitmap data (or the intermediate format that is converted to a bitmap) before sending it to the printer.
However, there is no indication to the printer what rotation or flipping was actually done for a given page. That information is *not* present in the job ticket, and I would argue that it is not appropriate for inclusion in the job ticket because it is a) format-specific and b) informational rather than directive.
> ...
>> Raster data means the data is rastered-out and should not require additional transforms (scaling might be an exception); the transforms here may require the printer to have rotation buffers which could be large and expensive to implement; not desirable.
>Agreed.
> Therefore, I am opposed to adding the specific PWR element for Horizontal and Vertical Transform. If a vendor which to use transforms, then it is part of their driver specific information but not an official PWG Raster element.
>That isn't the point of these fields - they are informational, not directive. A low-end printer will likely ignore them since the assumption is that the client did the right thing. Instead, this is for high-end printers and Cloud services that may need to "tweak" the raster document before sending it to the real output device.
> The same logic applies to the total number of page.
>How?
________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20110425/72b269a0/attachment-0001.html>