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.
[gwp] I guess I was not considering LFP's.
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...
[gwp] The important case is the size of the compressed raster data. The
decompressed size is recorded only if the raster is uncompressed.
[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.
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
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...)
[gwp] Do you mean big/little-endian? I am nothing requesting the word
ordering flag (value) be used. The current specification is ok.
(In order words, we already have a way to specify an uncompressed
raster)
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?
[gwp] I believe the RAS3 is for the entire PWG Raster file. I am
requesting a flags (value) for individual pages.
Glen
________________________________________________________________________
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/20110422/1e9785a0/attachment-0001.html>