<p class=MsoNormal><font size=3 color=blue face=Cambria><span style='font-size:
12.0pt;font-family:Cambria;color:blue'>I believe the current fields for
proposed to use the driver-specific same are not needed.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 color=blue face=Cambria><span style='font-size:
12.0pt;font-family:Cambria;color:blue'>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. &nbsp;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.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 color=blue face=Cambria><span style='font-size:
12.0pt;font-family:Cambria;color:blue'>Therefore, I am opposed to adding the
specific PWR element for Horizontal and Vertical Transform. &nbsp;If a vendor
which to use transforms, then it is part of their driver specific information
but not an official PWG Raster element.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 color=blue face=Cambria><span style='font-size:
12.0pt;font-family:Cambria;color:blue'>Thus, not officially specifying the
elements above or any new elements in the driver data space continues to make
CUPS and PWG raster 100% compatible but allow drivers (vendors) to add them and
other data as they deem necessary.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>I can add them, with the caveat that some of the cupsInteger fields
will be used for PWG Raster.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 color=blue face=Cambria><span style='font-size:
12.0pt;font-family:Cambria;color:blue'>I would like to request that that 16
integer, 16 floating point and 16 string that are denoted in CUPS raster as
driver-defined be added to the PWG raster.<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 color=blue face=Cambria><span style='font-size:
12.0pt;font-family:Cambria;color:blue'>I realize it is a mute point for this
request since the data elements are already reserved in CUPS raster and, as
such, are by defacto, inherited by the PWG raster (even if in the shadow or not
specifically declared) as long as the PWG raster maintains 100% compatible with
CUPS raster.<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 color=blue face=Cambria><span style='font-size:
12.0pt;font-family:Cambria;color:blue'>These fields do not jerry-rig additions
to either the CUPS or PWG raster since they are already defined by CUPS.<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>Where we are
currently reaching out to some printer manufacturers who have previously not
participated in PWG activities (portable printer manufacturers, thermal
transfer-direct thermal printer manufacturers) to let them know about the IPP
Anywhere project and the PWG Raster Format, I am in favor of waiting for a
little while to see if we get some interest from the reach out activities
before making a final decision on your request.<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color="#1f497d" face=Calibri><span
style='font-size:11.0pt;font-family:Calibri;color:#1F497D'>If we do get some
participation from the printer manufacturers outlined above, they might also
find some value in the feature you are requesting so I believe it is a little
premature to reject the idea of adding the field at this time.<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 color=blue face=Cambria><span style='font-size:
12.0pt;font-family:Cambria;color:blue'>It is an optional field and completely
testable in an interoperability test.<u1:p></u1:p></span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 color=blue face=Cambria><span style='font-size:12.0pt;font-family:Cambria;
color:blue'>As stated below, I do understand objection to adding the field.
&nbsp;I would to hear from other PWG members on the addition of these fields.</span></font><u1:p></u1:p><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 color=blue face=Cambria><span style='font-size:12.0pt;font-family:Cambria;
color:blue'>[gwp] The important case is the size of the compressed raster data.
The decompressed size is recorded only if the raster is uncompressed.</span></font><u1:p></u1:p><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 color=blue face=Cambria><span style='font-size:12.0pt;font-family:Cambria;
color:blue'>[gwp] I agree that some (a few or a lot) of implementation may not
provide the information but as I said, I am requesting that the assignment be
made and those who can (want to) may record the size information.</span></font><u1:p></u1:p><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>It really isn't a
matter of &quot;may not provide&quot;, in most cases clients (and printers)
simply can't buffer hundreds of megabytes of raster data I can add the field,
but since most producers of PWG Raster will not be able to supply the
compressed size of the raster no printer will be able to depend on it anyways,
so IMHO it is best to have the printer, if it is going to do any local
processing of full page images, use its own optimal internal storage format
than try to gerry-rig something into the format that just won't work.<u1:p></u1:p><o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 color=blue face=Cambria><span style='font-size:12.0pt;font-family:Cambria;
color:blue'>[gwp] As I stated in my original request, I am not worried about
the printer, it will accept the streaming input just fine. &nbsp;I want the
size information for navigation of a many page raster without having to
decompress pages in a serial manor. &nbsp;&nbsp;I am not jerry-rigging
anything.&nbsp; I do not understand your comment &#8220;that just won&#8217;t
work&#8221;. &nbsp;It works fine.&nbsp; In fact, I wrote a routine that will
find the size-only of compressed page by running the compression routine
without storing the compressed data. &nbsp;I don&#8217;t understand your
objection to assigning the field.</span></font><u1:p></u1:p><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>I would actually
prefer to flag the file as version 3 which is an uncompressed CUPS Raster with
the version 2 page header. And in the case of local processing, you'll likely want
to use native word order (another feature of CUPS Raster that we are not
bringing along for PWG Raster...)<u1:p></u1:p><o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>My main point was
that if you are concerned about having a standard representation for
intermediate data, CUPS Raster already provides that. If you are trying to
tweak PWG Raster for use as an internal representation format then I'd rather
not put that in the standard since internal formats are OOS for any PWG
standard.<u1:p></u1:p><o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>Would it be
sufficient to document an uncompressed version of PWG Raster (with the
&quot;RAS3&quot; file header) and then mark the native word order support as
out-of-scope for the spec but something that might be used internally?<u1:p></u1:p><o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>Since the format
does not support this, I would be opposed to adding something that would be
used only for an internal representation of a PWG Raster file.<u1:p></u1:p><o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><br>
-- <br>
This message has been scanned for viruses and <br>
dangerous content by <a href="http://www.mailscanner.info/" target="_blank"><b><span
style='font-weight:bold'>MailScanner</span></b></a>, and is <br>
believed to be clean. <u1:p></u1:p><o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><br>
-- <br>
This message has been scanned for viruses and <br>
dangerous content by <a href="http://www.mailscanner.info/"><b><span
style='font-weight:bold'>MailScanner</span></b></a>, and is <br>
believed to be clean. <u1:p></u1:p><o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><br>
-- <br>
This message has been scanned for viruses and <br>
dangerous content by <a href="http://www.mailscanner.info/"><b><span
style='font-weight:bold'>MailScanner</span></b></a>, and is <br>
believed to be clean. <o:p></o:p></span></font></p>