Glen,
Let me preface my response with this: I don't want to define an entirely new and complex raster format. I believe the consensus at the F2F was the same.
That said, my comments are inline below...
On Feb 3, 2011, at 6:31 AM, Petrie, Glen wrote:
> Hello All,
>> I have been thinking more on the details of the proposed raster format.
>> 1. I would propose the name: PWG HCD Raster (PHR)
We only use "HCD" in the IDS group, and as several people pointed out in the F2F we don't want the name or format to be too closely tied to any one aspect of a HCD/MFD/printer/whatever.
> ------------------------------------------------------------------------------------------------------
> Assumptions:
> ==========
> 1. A PHR is a separate entity from the Job Ticket; that is, the PHR is not contained in the Job Ticket but is referenced by the Job Ticket
> => A PHR must have sufficient header data to describe "What is this?" But does not contain HCD Job Ticket attributes.
I don't believe that the job ticket referenced the document; rather, the job associates the job ticket with the document(s) in the job.
>> 2. A PHR is usable-by or generated-by one or more HCD Services (Print, Scan, Fax, Copy).
> => A PHR must have sufficient header data to describe "What is this?"
Why? What problem are you trying to solve?
> 3. A PHR is usable-by or generated-by one or more external Services (Print-Preview, Post-Processing, Transforms).
> => A PHR must have sufficient header data to describe "What is this?"
Again, why? What problem are you trying to solve?
> 4. A PHR may contain 1-to-many rasters.
> => For more than one raster, the individual raster may be on one or separate page.
> Example: Scan multiple regions of the same page. (Smart form processing)
> Example: N-up the next four raster.
> => The bounding region of the raster must be recorded.
Let me reiterate a point I made in the F2F - we really don't want to design yet another raster format. IIRC PDF/is does allow for more than one image stream per page and is far better suited to this particular use case. PWG Raster/CUPS Raster is a simple page-based raster format.
> 5. A PHR is usable-in or generated-in a mobile, cloud, soho, business or production environment.
> => There may be limitation or requirement based on system resources.
This is already discussed in the draft spec and it the motivation behind using PackBits/RLE as the basic compression algorithm over higher-performing (but higher-resource) algorithms.
> ------------------------------------------------------------------------------------------------------
> Discussion Items
> =============
> Full page raster => Each raster is the same size as the media size.
> To support assumption 5 for the mobile environment; this need is impractical. Device in the mobile environment typical have insufficient system resources to generate a full page raster at a print dpi. One could argue that the mobile device/application could “stream-out” the full page raster. This is often referred to as banded output of the raster content. However, I still contend that encoding useless top/bottom/left/right white space is wasteful.
>> => A requirement to make PHR input/output streamable.
Yes, and if you'll notice this is in the current draft already and a specific feature of CUPS Raster.
(and sending whitespace for the margins is trivial, very space efficient, and generally simpler for the client)
> To support assumption 2, this need is not required. Example of scanning a region. The region may be 1in x 1in or 3in x 10in or 8.5in x 11.0in but to put these in a PHR of 8.5 in x 11.0 has not value and consume resources.
>> => The bounding region should be recorded and raster should be the size of the bounding region.
>> Practical examples:
> Print: I would like to place the next 10 raster in the PHR on a single page. Yes, the client could have done this but would be required to.
> Scan: I would like scan 3 areas of the 8.5 in x 11.0 in document and record in a PHR. By recording the bounding region of each raster; then each raster could be associated with a field on the original scanned document such as date, name, amount, etc. This would be extremely usefully to external Services.
PDF/is can address the multi-image per page case.
For the simple 1-image case the PWG Raster can just provide the area scanned (and not be a full page - again this isn't a print-only format), and could even provide multiple "pages", one per area scanned.
> Term “HW Resolution”
> The reference to ‘HW’ within the PHR is not important to HCD services. The reference to “resolution” is not technically correct. What is important to HCD/External services is the Raster DPI. In addition, there is concept of fast-scan / slow-scan and fast-print / slow-print directions which imply different DPI’s in each direction. Any scaling (integer or otherwise) between the “preferred (actual) DPI” of the raster and the Job Ticket DPI is determinable by the HCD service.
>> => The PHRHDR should record the raster horizontal and vertical DPI’s.
Actually we want Pixels Per Inch (PPI). WRT the format, PPI == DPI == HWResolution, the difference is in the name and not the actual semantics.
> ...
> Structure and Format of PHRHDR
> ==========================
> ...
> [96] --- [99] CmpRasterLen Length in bytes of compressed raster to follow
This kills streaming...
________________________________________________________________________
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/cloud/attachments/20110203/1c572967/attachment-0001.html>