Subject: [IPP] Requested Additions to PWG Raster

From: "Petrie, Glen" <[email-masked]>
Date: Fri, 22 Apr 2011 07:35:10 -0700

I would like to request two additional optional fields be added to the
PWG Raster.  Since they are new to even CUPS raster they would need to
be reserved in the field known as "cupsInteger".  So, while the fields
would be optional to fill in, the fields need to be reserved in the
header definition .

I have found that is useful to have the size of the raster data and to
have the raster data that is uncompressed (, at least temporarily); thus
a compressed state flag is useful.

Once the PWG Raster is used by clients and printer, it will most likely
be used more universally by transforms and other processes (previews,
etc.) .  Currently is difficult to navigate the PWG Raster pages because
the size of the (compressed) raster is unknown; therefore, therefore,
the entire raster file must be serially decompressed to move from one
page to the next.  While I realize, for some resource limited device, it
is not possible to know the size of the (compressed) raster before
sending the data, it is very useful for both navigation and check if the
size of the (compressed) raster is known.   Being optional, if the size
information is not known then the field has value of zero.

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

cupsInteger[0:0] = Compressed (0)/Decompressed(1) raster data

cupsInteger[1]    = PageCount (as proposed by Michael Sweet below)

cupsInteger[2]    = Size, in bytes, of a (this) raster data (compressed
or uncompressed size)

glen

====

Lasted additions posted by Michael Sweet

1.	PWG Raster Review 

	a.
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippraster10-20110327-rev.pdf 
	b.	Issue: Would be nice to have total page count (if known)

		*	Proposal: Add PageCount (integer, 0 to 2^31-1)
to page header ("cupsInteger[0]" from CUPS Raster), which is already
used by several CUPS Raster printer drivers 
		*	0 means "I don't know how many pages" 
		*	> 0 means "this is how many pages are in the
entire document" 
		*	Every page gets the same value 

	c.	Issue: Need coordinate space of image (flip/rotate on
back side) 

		*	Proposal: Add HorizontalTransform(integer, -1 or
1) and VerticalTransform(integer, -1 or 1) to the page header
("cupsInteger[1]" and "cupsInteger[2]" from CUPS Raster) 
		*	"Normal" pages have values of 1 and 1 
		*	"Rotated" pages have values of -1 and -1 (180
degree rotation) 
		*	"Flipped" pages have values of 1 and -1
(vertical flip) or -1 and 1 (horizontal flip) 

	d.	Issue: Need bounding rectangle of any content to be
imaged on the page (ImageBox) 

		*	Proposal 1: * Use existing ImagingBBox (4 x
integer) from page header - simple bounding box in (integer) points 
		*	Proposal 2: Add ImageBottom (integer, 0-2^32-1),
ImageLeft (integer, 0-2^32-1), ImageRight (integer, 0-2^32-1), and
ImageTop (integer, 0-2^32-1) to the page header ("cupsInteger[3]"
through "cupsInteger[6]" from CUPS Raster) - simple bounding box in
pixels/lines 

	e.	Issue: Some confusion about why we need
pwg-raster-resolutions-support 

		*	Will be adding explanatory text to the
definition 
		*	Basically supported raster resolutions can be
different than supported hardware resolutions 

	f.	Issue: Some confusion about the compression algorithm 

		*	Will be adding examples for 1-bit grayscale and
32-bit CMYK images to clarify 
		*	Also have sample raster files available for
download 

	g.	Samples files: 

		*	Currently at
http://ftp.easysw.com/pub/cups/examples/PWGRasterSamples.zip 
		*	40MB download, 80MB worth of data 
		*	150dpi files for black-1, cmyk-8, sgray-8,
sgray-16, srgb-8, and srgb-16 
		*	Representative documents for email, line art,
maps, photos, and web pages 
		*	Issue: Where to place sample raster files? 

-- 
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: Fri, 22 Apr 2011 09:03:41 -0700

On Apr 22, 2011, at 7:35 AM, Petrie, Glen wrote:
> ... 
> Once the PWG Raster is used by clients and printer, it will most likely be used more universally by transforms and other processes (previews, etc.) .  Currently is difficult to navigate the PWG Raster pages because the size of the (compressed) raster is unknown; therefore, therefore, the entire raster file must be serially decompressed to move from one page to the next.  While I realize, for some resource limited device, it is not possible to know the size of the (compressed) raster before sending the data, it is very useful for both navigation and check if the size of the (compressed) raster is known.   Being optional, if the size information is not known then the field has value of zero.

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.

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

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

(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?

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: "Petrie, Glen" <[email-masked]>
Date: Fri, 22 Apr 2011 09:34:30 -0700

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. 

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

---

From: Michael Sweet <[email-masked]>
Date: Fri, 22 Apr 2011 10:19:45 -0700

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

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

---

From: "Petrie, Glen" <[email-masked]>
Date: Fri, 22 Apr 2011 10:33:05 -0700

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

	... 

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

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.

---

From: Ira McDonald <[email-masked]>
Date: Fri, 22 Apr 2011 14:51:51 -0400

Hi Glen,

I agree with Mike here in objecting to registering these fields.

PWG standards are supposed to only contain fields/attributes
that *could* be tested in an interoperability event.  It's not
plausible that a typical streaming client would know the size
when it's very large (when the feature's useful), so such a
feature's not interoperable or verifiable.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <[email-masked]>wrote:

>  ------------------------------
>
> *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
>
>
>
> [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.
>
>
>
> 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.
>
>
>
> ...
>
> 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...)
>
>
>
> 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
> something that would be used only for an internal representation of a PWG
> Raster file.
>
>
>
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

---

From: "Petrie, Glen" <[email-masked]>
Date: Fri, 22 Apr 2011 12:08:27 -0700

Uncle !!!!!!!!!

It is an optional field and completely testable in an interoperability
test.

Glen

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

Hi Glen,

Cheers,
- Ira

<http://sites.google.com/site/highnorthinc> 

On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen
<[email-masked]> wrote:

Glen

	... 

	... 

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

believed to be clean.

---

From: "Paul Tykodi" <[email-masked]>
Date: Fri, 22 Apr 2011 19:27:42 -0400

Hi Glen,

Where we are currently reaching out to some printer manufacturers who have
previously not participated in PWG activities (portable printer
manufacturers, thermal transfer-direct thermal printer manufacturers) to let
them know about the IPP Anywhere project and the PWG Raster Format, I am in
favor of waiting for a little while to see if we get some interest from the
reach out activities before making a final decision on your request.

If we do get some participation from the printer manufacturers outlined
above, they might also find some value in the feature you are requesting so
I believe it is a little premature to reject the idea of adding the field at
this time.

Best Regards,

/Paul

--

Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  [email-masked]
WWW:   <http://www.tykodi.com/> http://www.tykodi.com

From: [email-masked] [mailto:[email-masked]] On Behalf Of Petrie,
Glen
Sent: Friday, April 22, 2011 3:08 PM
To: Ira McDonald
Cc: [email-masked]
Subject: RE: [IPP] Requested Additions to PWG Raster

Uncle !!!!!!!!!

It is an optional field and completely testable in an interoperability test.

Glen

  _____  

Hi Glen,

Cheers,
- Ira

On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <[email-masked]>
wrote:

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

  _____  

... 

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

... 

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.  

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

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

---

From: "Petrie, Glen" <[email-masked]>
Date: Mon, 25 Apr 2011 06:28:07 -0700

Paul,

I would like to change my request to the following

I would like to request that that 16 integer, 16 floating point and 16
string that are denoted in CUPS raster as driver-defined be added to the
PWG raster.

I realize it is a mute point for this request since the data elements
are already reserved in CUPS raster and, as such, are by defacto,
inherited by the PWG raster (even if in the shadow or not specifically
declared) as long as the PWG raster maintains 100% compatible with CUPS
raster.

These fields do not jerry-rig additions to either the CUPS or PWG raster
since they are already defined by CUPS.

These fields do not cause any interpretability testing issues since they
are driver specific information.

Glen

From: Paul Tykodi [mailto:[email-masked]] 
Sent: Friday, April 22, 2011 4:28 PM
To: Petrie, Glen
Cc: [email-masked]; 'Ira McDonald'; [email-masked]
Subject: RE: [IPP] Requested Additions to PWG Raster

Hi Glen,

Where we are currently reaching out to some printer manufacturers who
have previously not participated in PWG activities (portable printer
manufacturers, thermal transfer-direct thermal printer manufacturers) to
let them know about the IPP Anywhere project and the PWG Raster Format,
I am in favor of waiting for a little while to see if we get some
interest from the reach out activities before making a final decision on
your request.

If we do get some participation from the printer manufacturers outlined
above, they might also find some value in the feature you are requesting
so I believe it is a little premature to reject the idea of adding the
field at this time.

Best Regards,

--

Paul Tykodi
Principal Consultant

Tel/Fax: 603-343-1820
Mobile:  603-866-0712
E-mail:  [email-masked]
WWW:  http://www.tykodi.com <http://www.tykodi.com/> 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Petrie, Glen
Sent: Friday, April 22, 2011 3:08 PM
To: Ira McDonald
Cc: [email-masked]
Subject: RE: [IPP] Requested Additions to PWG Raster

Uncle !!!!!!!!!

Glen

Hi Glen,

Cheers,
- Ira

Glen

	... 

(and printers) simply can't buffer hundreds of megabytes of raster data

	... 

believed to be clean. 

believed to be clean.

---

From: Mike Sweet <[email-masked]>
Date: Mon, 25 Apr 2011 06:51:24 -0700

I can add them, with the caveat that some of the cupsInteger fields will be used for PWG Raster.

Sent from my iPad

On Apr 25, 2011, at 6:28 AM, "Petrie, Glen" <[email-masked]> wrote:

> I would like to request that that 16 integer, 16 floating point and 16 string that are denoted in CUPS raster as driver-defined be added to the PWG raster.
>  
> I realize it is a mute point for this request since the data elements are already reserved in CUPS raster and, as such, are by defacto, inherited by the PWG raster (even if in the shadow or not specifically declared) as long as the PWG raster maintains 100% compatible with CUPS raster.
>  
> These fields do not jerry-rig additions to either the CUPS or PWG raster since they are already defined by CUPS.
> These fields do not cause any interpretability testing issues since they are driver specific information.
>  
> Glen
>  
>  
> Where we are currently reaching out to some printer manufacturers who have previously not participated in PWG activities (portable printer manufacturers, thermal transfer-direct thermal printer manufacturers) to let them know about the IPP Anywhere project and the PWG Raster Format, I am in favor of waiting for a little while to see if we get some interest from the reach out activities before making a final decision on your request.
>  
> If we do get some participation from the printer manufacturers outlined above, they might also find some value in the feature you are requesting so I believe it is a little premature to reject the idea of adding the field at this time.
>  
> Best Regards,
>  
> --
> Paul Tykodi
> Principal Consultant
> WWW:  http://www.tykodi.com
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Petrie, Glen
> On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <[email-masked]> wrote:
> 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
>  
>  
> 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.
>  
> ...

---

From: "Petrie, Glen" <[email-masked]>
Date: Mon, 25 Apr 2011 07:23:43 -0700

Doesn't "using them for PWG Raster" make the CUPS and PWG raster
incompatible?  

I believe the current fields for proposed to use the driver-specific
same are not needed.

1. "total number of pages" 

2. HorizontalTransform

3. VerticalTransform 

The Job Ticket will specify the output format (duplex, flip, rotate);
therefore, transforms data and information are part of the Job Ticket
and the raster must be transformed to the correct orientation required
so that the printer (or any consumer of the raster) does not know or
have to perform the transforms.  Raster data means the data is
rastered-out and should not require additional transforms (scaling might
be an exception); the transforms here may require the printer to have
rotation buffers which could be large and expensive to implement; not
desirable.

Therefore, I am opposed to adding the specific PWR element for
Horizontal and Vertical Transform.  If a vendor which to use transforms,
then it is part of their driver specific information but not an official
PWG Raster element.

The same logic applies to the total number of page.

Thus, not officially specifying the elements above or any new elements
in the driver data space continues to make CUPS and PWG raster 100%
compatible but allow drivers (vendors) to add them and other data as
they deem necessary.

Glen

From: Mike Sweet [mailto:[email-masked]] 
Sent: Monday, April 25, 2011 6:51 AM
To: Petrie, Glen
Cc: [email-masked]; [email-masked]
Subject: Re: [IPP] Requested Additions to PWG Raster

I can add them, with the caveat that some of the cupsInteger fields will
be used for PWG Raster.

Sent from my iPad

On Apr 25, 2011, at 6:28 AM, "Petrie, Glen" <[email-masked]>
wrote:

	Paul,

	I would like to request that that 16 integer, 16 floating point
and 16 string that are denoted in CUPS raster as driver-defined be added
to the PWG raster.

	I realize it is a mute point for this request since the data
elements are already reserved in CUPS raster and, as such, are by
defacto, inherited by the PWG raster (even if in the shadow or not
specifically declared) as long as the PWG raster maintains 100%
compatible with CUPS raster.

	These fields do not jerry-rig additions to either the CUPS or
PWG raster since they are already defined by CUPS.

	These fields do not cause any interpretability testing issues
since they are driver specific information.

	Glen

	From: Paul Tykodi [mailto:[email-masked]] 
	Sent: Friday, April 22, 2011 4:28 PM
	To: Petrie, Glen
	Cc: [email-masked]; 'Ira McDonald'; <mailto:[email-masked]>
[email-masked]
	Subject: RE: [IPP] Requested Additions to PWG Raster

	Hi Glen,

	Where we are currently reaching out to some printer
manufacturers who have previously not participated in PWG activities
(portable printer manufacturers, thermal transfer-direct thermal printer
manufacturers) to let them know about the IPP Anywhere project and the
PWG Raster Format, I am in favor of waiting for a little while to see if
we get some interest from the reach out activities before making a final
decision on your request.

	If we do get some participation from the printer manufacturers
outlined above, they might also find some value in the feature you are
requesting so I believe it is a little premature to reject the idea of
adding the field at this time.

	Best Regards,

	--

	Paul Tykodi
	Principal Consultant
	
	Tel/Fax: 603-343-1820
	Mobile:  603-866-0712
	E-mail:  <mailto:[email-masked]> [email-masked]
	WWW:  http://www.tykodi.com <http://www.tykodi.com/> 

	From: [email-masked] [mailto:[email-masked]] On Behalf
Of Petrie, Glen
	Sent: Friday, April 22, 2011 3:08 PM
	To: Ira McDonald
	Cc: <mailto:[email-masked]> [email-masked]
	Subject: RE: [IPP] Requested Additions to PWG Raster

	Uncle !!!!!!!!!

	It is an optional field and completely testable in an
interoperability test.

	Glen

	Cc: Michael Sweet; <mailto:[email-masked]> [email-masked]

	Hi Glen,

	
	Cheers,
	- Ira
	
	<http://sites.google.com/site/blueroofmusic>
	mailto: <mailto:[email-masked]> [email-masked]

	On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <
<mailto:[email-masked]> [email-masked]> wrote:

	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: <mailto:[email-masked]>
[email-masked]] 
	Sent: Friday, April 22, 2011 10:20 AM
	To: Petrie, Glen
	Cc: <mailto:[email-masked]> [email-masked]
	Subject: Re: [IPP] Requested Additions to PWG Raster

		... 

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

	

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

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

	-- 
	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 <http://www.mailscanner.info/>
, and is 
	believed to be clean.

---

From: Michael Sweet <[email-masked]>
Date: Mon, 25 Apr 2011 09:36:38 -0700

On Apr 25, 2011, at 7:23 AM, Petrie, Glen wrote:
> Doesn’t “using them for PWG Raster” make the CUPS and PWG raster incompatible?

Not at all. All of the cupsInteger, cupsReal, and cupsString fields are driver-specific use. In this case the "driver" is the generic IPP Everywhere/PWG Raster path.

> I believe the current fields for proposed to use the driver-specific same are not needed.
>  
> 1. “total number of pages”

Given that many existing CUPS Raster drivers want this information, I think this is at least useful information to expose (when available).

> 3. VerticalTransform

These *are* necessary if the raster data could be consumed by a different imaging device than originally targeted (likely in the Cloud case).

> The Job Ticket will specify the output format (duplex, flip, rotate); therefore, transforms data and information are part of the Job Ticket and the raster must be transformed to the correct orientation required so that the printer (or any consumer of the raster) does not know or have to perform the transforms.

The transform information for back sides are not exposed in job tickets, only as printer description attributes for clients who are generating the raster data. The assumption (and conformance requirement) is that the client will produce raster data in a supported color space, bit depth, resolution, dimensions, and coordinate space - this doesn't require the transform information in the header.

However, there are two specific use cases where that information may be necessary:

1. For fan-out devices, the IPP Printer may need to do transforms on the PWG Raster data to make it suitable for any of the devices.
2. For Cloud Printing the Cloud Imaging Provider may need to do transforms on the PWG Raster data to make it suitable for the Cloud Imaging Manager.

Since the transform information is not in the job ticket, does not express intent (i.e. all job template attributes tell you how to print a job - any descriptive elements are sent as operation attributes), and since that transform information is specific to PWG Raster documents, it makes sense to put the transform information in the PWG Raster document.

>  Raster data means the data is rastered-out and should not require additional transforms (scaling might be an exception); the transforms here may require the printer to have rotation buffers which could be large and expensive to implement; not desirable.
>  
> Therefore, I am opposed to adding the specific PWR element for Horizontal and Vertical Transform.  If a vendor which to use transforms, then it is part of their driver specific information but not an official PWG Raster element.
>  
> Thus, not officially specifying the elements above or any new elements in the driver data space continues to make CUPS and PWG raster 100% compatible but allow drivers (vendors) to add them and other data as they deem necessary.
>  
>  
> Glen
>  
>

---

From: "Petrie, Glen" <[email-masked]>
Date: Mon, 25 Apr 2011 09:45:16 -0700

Not at all. All of the cupsInteger, cupsReal, and cupsString fields are
driver-specific use. In this case the "driver" is the generic IPP
Everywhere/PWG Raster path.

[gwp] What, this is the very definition of incompatibility;  I a devices
receives a CUPS raster file with some vendor-data in the position of the
page number and it does not represent the page number then no telling
what will happen.

[gwp] If you change the PWG raster file identifier so it does not match
CUPS raster then is this not produce a conflict; because they would not
longer be the same thing.  Right now, no one reading a CUPS raster or
PWG raster change tell which is which.

	I believe the current fields for proposed to use the
driver-specific same are not needed.

Given that many existing CUPS Raster drivers want this information, I
think this is at least useful information to expose (when available).

2. HorizontalTransform

3. VerticalTransform 

These *are* necessary if the raster data could be consumed by a
different imaging device than originally targeted (likely in the Cloud
case).

[gwp] I disagree.  You mean that your/the proposed Job Ticket does have
the duplex setting or the layout orientation data.  If not, how can
someone ever generate the correct print output!!! 

have to perform the transforms.

The transform information for back sides are not exposed in job tickets,
only as printer description attributes for clients who are generating
the raster data. The assumption (and conformance requirement) is that
the client will produce raster data in a supported color space, bit
depth, resolution, dimensions, and coordinate space - this doesn't
require the transform information in the header.

However, there are two specific use cases where that information may be
necessary:

1. For fan-out devices, the IPP Printer may need to do transforms on the
PWG Raster data to make it suitable for any of the devices.

2. For Cloud Printing the Cloud Imaging Provider may need to do
transforms on the PWG Raster data to make it suitable for the Cloud
Imaging Manager.

Since the transform information is not in the job ticket, does not
express intent (i.e. all job template attributes tell you how to print a
job - any descriptive elements are sent as operation attributes), and
since that transform information is specific to PWG Raster documents, it
makes sense to put the transform information in the PWG Raster document.

 Raster data means the data is rastered-out and should not require
additional transforms (scaling might be an exception); the transforms
here may require the printer to have rotation buffers which could be
large and expensive to implement; not desirable.

 

Glen

Sent from my iPad

	Paul,

	Glen

	Hi Glen,

	Best Regards,

	--

	Paul Tykodi
	Principal Consultant
	
	Tel/Fax: 603-343-1820
	Mobile:  603-866-0712

	Uncle !!!!!!!!!

	Glen

	Hi Glen,

	
	Cheers,
	- Ira

	Glen

		... 

		...

---

From: Michael Sweet <[email-masked]>
Date: Mon, 25 Apr 2011 15:18:05 -0700

On Apr 25, 2011, at 9:45 AM, Petrie, Glen wrote:
> ... 
> 
> [gwp] What, this is the very definition of incompatibility;  I a devices receives a CUPS raster file with some vendor-data in the position of the page number and it does not represent the page number then no telling what will happen.
> 

By definition all of these fields are driver-specific and cannot be interpreted outside that particular driver.

(in this case a PWG Raster driver)
> [gwp] If you change the PWG raster file identifier so it does not match CUPS raster then is this not produce a conflict; because they would not longer be the same thing.  Right now, no one reading a CUPS raster or PWG raster change tell which is which.
> 

Actually, you can - if the PageSize field is all 0's, then it isn't a CUPS Raster file which will always have the media size in integer points... 
> [gwp] I disagree.  You mean that your/the proposed Job Ticket does have the duplex setting or the layout orientation data.  If not, how can someone ever generate the correct print output!!!
> 

The job ticket has "sides", which is an instruction to do duplex printing. However, it doesn't tell the printer how the raster data was generated.
> The Job Ticket will specify the output format (duplex, flip, rotate); therefore, transforms data and information are part of the Job Ticket and the raster must be transformed to the correct orienta…
The job ticket has "sides" and "orientation-requested". We don't require the printer support anything other than "portrait" orientation and the printer tells the client how to send the back side of duplex pages, so the client may have to pre-rotate/flip the bitmap data (or the intermediate format that is converted to a bitmap) before sending it to the printer.

However, there is no indication to the printer what rotation or flipping was actually done for a given page. That information is *not* present in the job ticket, and I would argue that it is not appropriate for inclusion in the job ticket because it is a) format-specific and b) informational rather than directive.
> Raster data means the data is rastered-out and should not require additional transforms (scaling might be an exception); the transforms here may require the printer to have rotation buffers which c…
Agreed.

> Therefore, I am opposed to adding the specific PWR element for Horizontal and Vertical Transform.  If a vendor which to use transforms, then it is part of their driver specific information but not…
That isn't the point of these fields - they are informational, not directive. A low-end printer will likely ignore them since the assumption is that the client did the right thing. Instead, this is for high-end printers and Cloud services that may need to "tweak" the raster document before sending it to the real output device.

> The same logic applies to the total number of page.
How?

---

From: "Petrie, Glen" <[email-masked]>
Date: Mon, 25 Apr 2011 15:41:41 -0700

From: Michael Sweet [mailto:[email-masked]] 
Sent: Monday, April 25, 2011 3:18 PM
To: Petrie, Glen
Cc: [email-masked]; [email-masked]
Subject: Re: [IPP] Requested Additions to PWG Raster

	... 

	[gwp] What, this is the very definition of incompatibility;  I a
devices receives a CUPS raster file with some vendor-data in the
position of the page number and it does not represent the page number
then no telling what will happen.

By definition all of these fields are driver-specific and cannot be
interpreted outside that particular driver.

[gwp] I agree; that does not change my statement.

	[gwp] If you change the PWG raster file identifier so it does
not match CUPS raster then is this not produce a conflict; because they
would not longer be the same thing.  Right now, no one reading a CUPS
raster or PWG raster change tell which is which.

Actually, you can - if the PageSize field is all 0's, then it isn't a
CUPS Raster file which will always have the media size in integer
points... 

[gwp] Great this says you "have a unique Id for PWG Raster" and that the
PageSize field of CUPS raster can never be used for PWG raster since the
value must be all 0' to uniquely identify a PWG Raster.  This new
identification MUST be stated in the PWG raster specification as the new
identifier.

	[gwp] I disagree.  You mean that your/the proposed Job Ticket
does have the duplex setting or the layout orientation data.  If not,
how can someone ever generate the correct print output!!! 

The job ticket has "sides", which is an instruction to do duplex
printing. However, it doesn't tell the printer how the raster data was
generated.

[gwp] I don't understand your reply.

	The Job Ticket will specify the output format (duplex, flip,
rotate); therefore, transforms data and information are part of the Job
Ticket and the raster must be transformed to the correct orientation
required so that the printer (or any consumer of the raster) does not
know or have to perform the transforms.

The job ticket has "sides" and "orientation-requested". We don't require
the printer support anything other than "portrait" orientation and the
printer tells the client how to send the back side of duplex pages, so
the client may have to pre-rotate/flip the bitmap data (or the
intermediate format that is converted to a bitmap) before sending it to
the printer.

However, there is no indication to the printer what rotation or flipping
was actually done for a given page. That information is *not* present in
the job ticket, and I would argue that it is not appropriate for
inclusion in the job ticket because it is a) format-specific and b)
informational rather than directive.

[gwp] If the printer does not support anything other than "portrait";
that is given in the printer capabilities and the printer will not
receive a job outside of it capabilities.  If the printer does receive a
job outside of its capabilities; it will best effort and must not be
required to "jump through hops" to do something it could not do.  We are
sending raster to the printer not an image.

[gwp] If the printer is capable of duplex; it is the client that sets
the flip/orientation; and, thus, only the client worries about how to
"flip" or not flip the content.  The printer only knows to do duplex; it
does not need to know the flip or orientation the raster. Remember this
is raster, not image. 

	...

	Raster data means the data is rastered-out and should not
require additional transforms (scaling might be an exception); the
transforms here may require the printer to have rotation buffers which
could be large and expensive to implement; not desirable.

Agreed.

That isn't the point of these fields - they are informational, not
directive. A low-end printer will likely ignore them since the
assumption is that the client did the right thing. Instead, this is for
high-end printers and Cloud services that may need to "tweak" the raster
document before sending it to the real output device.

[gwp] Why would or should any printer "tweak" the raster.  The raster
must be in the correct format; otherwise it is not (printer) raster.
This is a raster format, not an image format.  If you want to change the
specification to PWG Image specification; then I would agree that the
printer can perform transforms on the image data.  But raster means it
be "poured" in the printer and printed as delivered; that is, the raster
was generated for the printer for this reason. 

How?