attachment

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"/>  <style>  </style> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> After more consideration, I was not happy with requirement 3  and propose the following change <o:p></o:p> <o:p> </o:p> Was<o:p></o:p> <o:p> </o:p> 3. A PHRHDR shall record the horizontal (witdth) and vertical (height) DPI of the raster.<o:p></o:p> a. If a PHR contains raster for the same page of different DPI, all raster will be rendered by the HCD service at the largest DPI and shall be scaled by the HCD.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> To<o:p></o:p> <o:p> </o:p> 3. A PHRHDR shall record the horizontal (witdth) and vertical (height) DPI of the raster.<o:p></o:p> a. If a PHR contains raster for the same page of different DPI, all raster will be rendered by the HCD service at the DPI of the first raster for the page in PHR and shall scale all other raster for the same page to the DPI of the first raster.<o:p></o:p> <o:p> </o:p> Based on emails with Mike, I modified my proposal of the byte data at the end to <o:p></o:p> <o:p> </o:p> Was<o:p></o:p> <o:p> </o:p> [65] --- [95]                    0xEE                            Reserve byte for Vendor/Service/App<o:p></o:p> <o:p> </o:p> [96] --- [99]                    CmpRasterLen               Length in bytes of compressed raster to follow<o:p></o:p> <o:p> </o:p> [100] ----- >                    compressed raster data.<o:p></o:p> <o:p> </o:p> To<o:p></o:p> <o:p> </o:p> [65] --- [99]                    0xEE                            Reserve byte for Vendor/Service/App<o:p></o:p> <o:p> </o:p>  [100] ----- >                    compressed raster data.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div> <div class=MsoNormal align=center style='text-align:center'> <hr size=2 width="100%" align=center tabindex=-1> </div> From: mfd-bounces@pwg.org [mailto:mfd-bounces@pwg.org] On Behalf Of <st1:PersonName w:st="on">Petrie, Glen</st1:PersonName> Sent: Thursday, February 03, 2011 8:31 AM To: ipp@pwg.org; cloud@pwg.org; mfd@pwg.org Subject: [MFD] The Proposed PWG Raster<o:p></o:p> </div> <o:p> </o:p> Hello All,<o:p></o:p>  <o:p></o:p> I have been thinking more on the details of the proposed raster format.<o:p></o:p>  <o:p></o:p> 1. I would propose the name: PWG HCD Raster  (PHR)<o:p></o:p> <o:p> </o:p> ------------------------------------------------------------------------------------------------------ <o:p></o:p> Assumptions:<o:p></o:p> ==========<o:p></o:p> 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<o:p></o:p> => A PHR must have sufficient header data to describe "What is this?"  But does not contain HCD Job Ticket attributes.<o:p></o:p> <o:p> </o:p> 2. A PHR is usable-by or generated-by one or more HCD Services (Print, Scan, Fax, Copy).<o:p></o:p> => A PHR must have sufficient header data to describe "What is this?"<o:p></o:p> <o:p> </o:p> 3. A PHR is usable-by or generated-by one or more external Services (Print-Preview, Post-Processing, Transforms).<o:p></o:p> => A PHR must have sufficient header data to describe "What is this?"<o:p></o:p> <o:p> </o:p> 4. A PHR may contain 1-to-many rasters.<o:p></o:p> => For more than one raster, the individual raster may be on one or separate page.<o:p></o:p> Example: Scan multiple regions of the same page. (Smart form processing)<o:p></o:p> Example: N-up the next four raster.<o:p></o:p> => The bounding region of the raster must be recorded.<o:p></o:p> <o:p> </o:p> 5. A PHR is usable-in or generated-in a mobile, cloud, soho, business or production environment.<o:p></o:p> => There may be limitation or requirement based on system resources.<o:p></o:p> <o:p> </o:p> ------------------------------------------------------------------------------------------------------ <o:p></o:p> Discussion Items<o:p></o:p> =============<o:p></o:p> <ol style='margin-top:0in' start=1 type=1> <li class=MsoNormal style='mso-list:l0 level1 lfo3'>Full page raster => Each raster is the same size as the media size.<o:p></o:p></li> <ol style='margin-top:0in' start=1 type=a> <li class=MsoNormal style='mso-list:l0 level2 lfo3'>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. <o:p></o:p></li> </ol> </ol> <o:p> </o:p> => A requirement to make PHR input/output streamable.<o:p></o:p> <o:p> </o:p> <ol style='margin-top:0in' start=1 type=1> <ol style='margin-top:0in' start=2 type=a> <li class=MsoNormal style='mso-list:l0 level2 lfo3'>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.<o:p></o:p></li> </ol> </ol> <o:p> </o:p> => The bounding region should be recorded and raster should be the size of the bounding region.<o:p></o:p> <o:p> </o:p> Practical examples:<o:p></o:p> 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.<o:p></o:p> 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.<o:p></o:p> <o:p> </o:p> <ol style='margin-top:0in' start=2 type=1> <li class=MsoNormal style='mso-list:l0 level1 lfo3'>Term “HW Resolution”<o:p></o:p></li> <ol style='margin-top:0in' start=1 type=a> <li class=MsoNormal style='mso-list:l0 level2 lfo3'>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.<o:p></o:p></li> </ol> </ol> <o:p> </o:p> => The PHRHDR should record the raster horizontal and vertical DPI’s. <o:p></o:p> <o:p> </o:p> ------------------------------------------------------------------------------------------------------ <o:p></o:p> Requirements<o:p></o:p> ===========<o:p></o:p> 1. All internal PHR rasters shall have the same set of header content<o:p></o:p> => There is no separate pre-header within a PHR<o:p></o:p> <o:p> </o:p> PHRHDR === PWG HCD Raster Header<o:p></o:p> <o:p> </o:p> 2. A PHR shall be identifiable.<o:p></o:p> => There is an explicit identifier in the PHRHDR<o:p></o:p> => A PHRHDR contains the PHR format version<o:p></o:p> <o:p> </o:p> 3. A PHRHDR shall record the horizontal (witdth) and vertical (height) DPI of the raster.<o:p></o:p> a. If a PHR contains raster for the same page of different DPI, all raster will be rendered by the HCD service at the largest DPI and shall be scaled by the HCD.<o:p></o:p> <o:p> </o:p> 4. A PHRHDR shall record the width (horizontal) and height (vertical) number of pixels of the raster.<o:p></o:p> <o:p> </o:p> 5. A PHRHDR shall record the number of (8-bit) bytes in single horizontal raster line.<o:p></o:p> <o:p> </o:p> 6. A PHRHDR shall record the top and left position, relative to the media’s top-left physical corner, of the raster.<o:p></o:p> <o:p> </o:p> 7. A PHRDR shall record the Color Space, Color Order, Bits-per-pixel and Bits-per-color for the raster.<o:p></o:p> <o:p> </o:p> 8. A PHRHDR shall record the raster number for this raster and total number raster in the PHR<o:p></o:p> <o:p> </o:p> 9. A PHR shall be input and output streamable.<o:p></o:p> <o:p> </o:p> 10. A PHRHDR shall record a new page indicator.<o:p></o:p> <o:p> </o:p> 11. Byte order of PHR shall follow network convention of “big endian”.<o:p></o:p> <o:p> </o:p> 12. A PHRHDR shall record the duplex parameter for the raster.  This does mean that the duplex parameters are to be performed by the HCD; it means what duplex parameter were applied by the creator of the raster in the PHR.<o:p></o:p> <o:p> </o:p> 13. A PHRHDR shall record the type of compression used for the raster data.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> ------------------------------------------------------------------------------------------------------ <o:p></o:p> Terms and Definitions<o:p></o:p> =================<o:p></o:p> <o:p> </o:p> Later…. <o:p></o:p> <o:p> </o:p> <o:p> </o:p> ------------------------------------------------------------------------------------------------------ <o:p></o:p> Structure and Format of PHRHDR<o:p></o:p> ==========================<o:p></o:p> <o:p> </o:p> (I was not picky on order)<o:p></o:p> <o:p> </o:p> Bytes                            Value                            Description <o:p></o:p> ---------                           ------------------                  ------------------------------<o:p></o:p> [01] --- [10]                    PHR xxxxxx                  PHR identifier/Version<o:p></o:p> [11] --- [11]                    RasterNumber               Number, of total, for this raster<o:p></o:p> [12] --- [12]                    TotalRaster                    Total number of raster in PHR<o:p></o:p> [13] --- [16]                    RasterWidth                  Raster width in pixels<o:p></o:p> [17] --- [20]                    RasterHeight                 Raster height in pixels<o:p></o:p> [21] --- [24]                    RasterBPL                    Raster bytes-per-line<o:p></o:p> [25] --- [28]                    HorizDPI                       Raster DPI in horizontal direction<o:p></o:p> [29] --- [32]                    VertDPI                         Raster DPI in vertical direction<o:p></o:p> [33] --- [36]                    TopOffset                      Raster Top offset at raster vertical DPI<o:p></o:p> [37] --- [40]                    LeftOffset                      Raster left offset at raster horizontal DPI<o:p></o:p> [41] --- [41]                    NewPage                      Raster is on a new page flag<o:p></o:p> [42] --- [42]                    ColorSpaceID                Identification number for color space<o:p></o:p> [43] --- [43]                    BitsPerPixel                  Number of bits per pixel<o:p></o:p> [44] --- [44]                    BitsPerColor                  Number of bits per color <o:p></o:p> [45] --- [45]                    ColorOrderID                  Identification number for color ordering in a pixel<o:p></o:p> [46] --- [46]                    DuplexID                       Id number for duplex operation performed<o:p></o:p> [47] --- [47]                    CompressionID              Id number for raster compression method<o:p></o:p> [48] --- [64]                    0XFF                             Reserve byte for future by PWG<o:p></o:p> [65] --- [95]                    0xEE                            Reserve byte for Vendor/Service/App<o:p></o:p> <o:p> </o:p> [96] --- [99]                    CmpRasterLen               Length in bytes of compressed raster to follow<o:p></o:p> <o:p> </o:p> [100] ----- >                    compressed raster data.<o:p></o:p> <o:p> </o:p> See CUPS Raster for possible values of ID variables.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> -- This message has been scanned for viruses and dangerous content by <a href="http://www.mailscanner.info/">MailScanner</a>, and is believed to be clean. <o:p></o:p> </div> -- This message has been scanned for viruses and dangerous content by <a href="http://www.mailscanner.info/">MailScanner</a>, and is believed to be clean. </body> </html>