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).
> 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).
> 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.
>> 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: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> wrote:
>>> 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>> 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>> 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, 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.
>>>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>> _______________________________________________
>> ipp mailing list
>>ipp at pwg.org>>https://www.pwg.org/mailman/listinfo/ipp
________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
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/5ef4d451/attachment-0001.html>