________________________________
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Monday, April 25, 2011 3:18 PM
To: Petrie, Glen
Cc: ptykodi at tykodi.com; ipp at pwg.org
Subject: Re: [IPP] Requested Additions to PWG Raster
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.
[gwp] I agree; that does not change my statement.
(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] Great this says you "have a unique Id for PWG Raster" and that the
PageSize field of CUPS raster can never be used for PWG raster since the
value must be all 0' to uniquely identify a PWG Raster. This new
identification MUST be stated in the PWG raster specification as the new
identifier.
[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.
[gwp] I don't understand your reply.
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.
[gwp] If the printer does not support anything other than "portrait";
that is given in the printer capabilities and the printer will not
receive a job outside of it capabilities. If the printer does receive a
job outside of its capabilities; it will best effort and must not be
required to "jump through hops" to do something it could not do. We are
sending raster to the printer not an image.
[gwp] If the printer is capable of duplex; it is the client that sets
the flip/orientation; and, thus, only the client worries about how to
"flip" or not flip the content. The printer only knows to do duplex; it
does not need to know the flip or orientation the raster. Remember this
is raster, not image.
...
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.
[gwp] Why would or should any printer "tweak" the raster. The raster
must be in the correct format; otherwise it is not (printer) raster.
This is a raster format, not an image format. If you want to change the
specification to PWG Image specification; then I would agree that the
printer can perform transforms on the image data. But raster means it
be "poured" in the printer and printed as delivered; that is, the raster
was generated for the printer for this reason.
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/d9b23c3f/attachment-0001.html>