[IPP] Requested Additions to PWG Raster

[IPP] Requested Additions to PWG Raster

Petrie, Glen glen.petrie at eitc.epson.com
Mon Apr 25 13:28:07 UTC 2011


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:ptykodi at tykodi.com] 
Sent: Friday, April 22, 2011 4:28 PM
To: Petrie, Glen
Cc: ipp at pwg.org; 'Ira McDonald'; 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:  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: 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.

 

Glen

 

 

________________________________

From: Ira McDonald [mailto:blueroofmusic at gmail.com] 
Sent: Friday, April 22, 2011 11:52 AM
To: Petrie, Glen; Ira McDonald
Cc: Michael Sweet; 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.

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
<http://sites.google.com/site/highnorthinc> 
mailto:blueroofmusic at gmail.com
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
<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.

 

Glen

 

 

________________________________

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


_______________________________________________
ipp mailing list
ipp at pwg.org
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, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20110425/d394b8ea/attachment-0001.html>


More information about the ipp mailing list