attachment-0001
<html><head><base href="x-msg://124/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Apr 22, 2011, at 7:35 AM, Petrie, Glen wrote:</div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div lang="EN-US" link="blue" vlink="purple"><div class="Section1" style="page: Section1; "><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman'; "><span class="Apple-style-span" style="font-family: Cambria; ">... </span></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman'; "><font size="3" face="Cambria"><span style="font-size: 12pt; font-family: Cambria; ">Once the PWG Raster is used by clients and printer, it will most likely be used more universally by transforms and other processes (previews, etc.) . Currently is difficult to navigate the PWG Raster pages because the size of the (compressed) raster is unknown; therefore, therefore, the entire raster file must be serially decompressed to move from one page to the next. While I realize, for some resource limited device, it is not possible to know the size of the (compressed) raster before sending the data, it is very useful for both navigation and check if the size of the (compressed) raster is known. Being optional, if the size information is not known then the field has value of zero.</span></font></div></div></div></span></blockquote><div><br></div>However, cupsInteger is a 32-bit unsigned integer and thus can only represent sizes up to 2^32-1. It is very easy to go over 4GB with large format printers, e.g., for a 44" wide Stylus Pro printer, 24-bit sRGB at 720dpi would hit the 4GB limit at 63 inches in length for uncompressed data, maybe you'd get 100 inches with compression for a photographic print.</div><div><br></div><div>Now, we could use two cupsInteger slots for this (to provide a 64-bit length), however based on your following comments it sounds like you expect raster processing to happen with uncompressed data, for which you can calculate the length from the page header anyways. Also, you can expect that most, if not all implementations will *not* generate this information since the point of a streamable raster format is to not need to buffer up a whole lot of data...</div><div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div lang="EN-US" link="blue" vlink="purple"><div class="Section1" style="page: Section1; "><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman'; "><font size="3" face="Cambria"><span style="font-size: 12pt; font-family: Cambria; "><o:p></o:p></span></font></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman'; "><font size="3" face="Cambria"><span style="font-size: 12pt; font-family: Cambria; ">For most (all) processing, the raster data needs to be decompressed. (For transport it should also be compressed.) Therefore, it convenient to have the raster page data to be uncompressed; versus decompressing and compressing between processes. To denote this, a state flag is needed. This is also an optional field and the value of zero (0) means the data is compressed. I would not waste a whole integer on a flag, therefore, I would propose that one of the cupsInteger be reserved for flags</span></font></div></div></div></span></blockquote><div><br></div>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...)</div><div><br></div><div>(In order words, we already have a way to specify an uncompressed raster)</div><div><br></div><div>Would it be sufficient to document an uncompressed version of PWG Raster (with the "RAS3" file header) and then mark the native word order support as out-of-scope for the spec but something that might be used internally?</div><div><br></div><div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div lang="EN-US" link="blue" vlink="purple"><div class="Section1" style="page: Section1; "><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman'; "><font size="3" face="Cambria"><span style="font-size: 12pt; font-family: Cambria; "><o:p></o:p></span></font></div></div></div></span></blockquote></div><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>________________________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair<br></div></span>
</div>
<br><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>