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/blueroofmusichttp://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, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20110422/c4915318/attachment-0001.html>