[IPP] Requested Additions to PWG Raster

[IPP] Requested Additions to PWG Raster

Petrie, Glen glen.petrie at eitc.epson.com
Mon Apr 25 14:23:43 UTC 2011

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


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


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.







From: Mike Sweet [mailto:msweet at apple.com] 
Sent: Monday, April 25, 2011 6:51 AM
To: Petrie, Glen
Cc: ptykodi at tykodi.com; ipp at pwg.org
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" <glen.petrie at eitc.epson.com>



	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.






	From: Paul Tykodi [mailto:ptykodi at tykodi.com] 
	Sent: Friday, April 22, 2011 4:28 PM
	To: Petrie, Glen
	Cc: ipp at pwg.org; 'Ira McDonald'; <mailto:msweet at apple.com>
msweet at apple.com
	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
	TCS - Tykodi Consulting Services LLC
	Tel/Fax: 603-343-1820
	Mobile:  603-866-0712
	E-mail:  <mailto:ptykodi at tykodi.com> ptykodi at tykodi.com
	WWW:  http://www.tykodi.com <http://www.tykodi.com/> 

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


	Uncle !!!!!!!!!


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






	From: Ira McDonald [mailto:blueroofmusic at gmail.com] 
	Sent: Friday, April 22, 2011 11:52 AM
	To: Petrie, Glen; Ira McDonald
	Cc: Michael Sweet; <mailto:ipp at pwg.org> ipp at pwg.org
	Subject: Re: [IPP] Requested Additions to PWG Raster


	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.
	- Ira
	Ira McDonald (Musician / Software Architect)
	Chair - Linux Foundation Open Printing WG
	Co-Chair - TCG Hardcopy WG
	IETF Designated Expert - IPP & Printer MIB
	Blue Roof Music/High North Inc
	mailto: <mailto:blueroofmusic at gmail.com> blueroofmusic at gmail.com
	Christmas through April:
	  579 Park Place  Saline, MI  48176
	May to Christmas:
	  PO Box 221  Grand Marais, MI 49839


	On Fri, Apr 22, 2011 at 1:33 PM, Petrie, Glen <
<mailto:glen.petrie at eitc.epson.com> glen.petrie at eitc.epson.com> 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.






	From: Michael Sweet [mailto: <mailto:msweet at apple.com>
msweet at apple.com] 
	Sent: Friday, April 22, 2011 10:20 AM
	To: Petrie, Glen
	Cc: <mailto:ipp at pwg.org> ipp at pwg.org
	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

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

	ipp mailing list
	<mailto:ipp at pwg.org> ipp at pwg.org


	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. 

	ipp mailing list
	ipp at pwg.org

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/20110425/52def91e/attachment-0001.html>

More information about the ipp mailing list