On May 2, 2011, at 9:32 AM, Rich Gray wrote:
> Ok, I'll wander in from the peanut gallery and probably expose my ignorance. I've only been following these festivities loosely, but the posts about total pages and then then the desire for a compressed size did catch my attention. Looking over ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf , from a server perspective, it bothers me greatly that it is not possible to find and extract pages from this format without uncompressing the images out to the desired page(s). Yes, the server will probably have the resources (disk and processor) to accomplish this, but given these are by definition large files, it seems like a bloody waste. If this is to become a widely used format, then ideally, it should be possible for a server to ingest and send these pages on their way with minimal overhead, unless the server really has to do some sort of reformatting.
If you want random access, you'll either want to do reformatting or generate an index of the PWG Raster file. Any server will be able to rapidly index a raster file...
(and keep in mind that a server will likely advertise support for a higher-level format like PDF anyways, so the client will likely supply that instead of PWG Raster...)
> I see two possibilities to make it easier on servers:
>> 1. chunk the data
Since we are not trying to define a new format, this isn't an option.
> 2. take a page from the PDF format and write the size of the preceding image data into a field in the FOLLOWING page header. This would require some sort of trailer record on the file. With this, a server could run backwards through the file, stepping from header to header and with low overhead find any desired page in the file.
Since CUPS Raster (the base format we are using for PWG Raster) does not have a trailer, we have no opportunity to do this, either.
__________________________________________________
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/20110502/3fc20428/attachment-0001.html>