Subject: RE: [IPP] Requested Additions to PWG Raster

From: "Rich Gray" <[email-masked]>
Date: Mon, 2 May 2011 12:32:46 -0400

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
<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.
 
I see two possibilities to make it easier on servers:
1. chunk the data
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.  
 
My humble $.02
 
Rich
 
Richard B. Gray
Senior Software Engineer
Plus Technologies LLC
444 Alexandersville Road
Miamisburg, OH 45342-3568
+1 937-847-0614 ext. 2405
+1 937-384-0842 fax
877-899-7587 toll free
[email-masked]
www.plustechnologies.com

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Petrie, Glen
Sent: Friday, April 22, 2011 1:33 PM
To: Michael Sweet
Cc: [email-masked]
Subject: RE: [IPP] Requested Additions to PWG Raster

As stated below, I do understand objection to adding the field.  I would
to hear from other PWG members on the addition of these fields.

Glen

________________________________

From: Michael Sweet [mailto:[email-masked]] 
Sent: Friday, April 22, 2011 10:20 AM
To: Petrie, Glen
Cc: [email-masked]
Subject: Re: [IPP] Requested Additions to PWG Raster

On Apr 22, 2011, at 9:34 AM, Petrie, Glen wrote:

	... 

	[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.

It really isn't a matter of "may not provide", 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.

[gwp] As I stated in my original request, I am not worried about the
printer, it will accept the streaming input just fine.  I want the size
information for navigation of a many page raster without having to
decompress pages in a serial manor.   I am not jerry-rigging anything.
I do not understand your comment "that just won't work".  It works fine.
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.  I don't understand your objection to assigning the field.

	... 

	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.

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.

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.  

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.

[gwp] Again, I do not understand your objection. 

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 02 May 2011 21:43:41 -0700

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:

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