Ira, I believe the property refers to the functional mode the printer is to use or was used to produce the output. That is; the printer is printing in or instructed to print in a ""color mode"". If this property was meant to represent the "state" of the output; then for print, and later for scan and fax, it should be (have been) called "color-space". Then it would make more sense to have used the prefix "image" (versus even the word "imaging"); so we have image-color-space (the printed image, the scanned image, the fax image - the key here it is the image and the device functionality or device capabilities or device mode.).
So the device is instructed (or uses) to have a specific
print-color-mode, scan-color-mode or fax-color-mode to produce an (hard or electronic) image that has an image-color-space
what about "device-color-mode"
Glen
________________________________
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Tuesday, April 19, 2011 12:49 PM
To: Petrie, Glen; Ira McDonald
Cc: Mitchell, Andrew (Solutions Architect); tom.hastings at alum.mit.edu; Michael Sweet; ipp at pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
Hi,
On reflection, I tend to agree with Andrew that we should
(in general) use the 'imaging-' prefix for our new attributes.
But I *think* we meant the new 'print-color-mode' property
to refer specifically to hardcopy output (print).
I don't think it fits well w/ scan (output image format) or fax.
All - note that we generally *drop* the 'print-' or 'job-' or
whatever prefix in the PWG Semantic Model XML Schema
in order to reuse the "same" (well similar) attribute at more
than one level of the system/service/job/document hierarchy.
Pete - please chime in with your opinion here.
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 <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 Tue, Apr 19, 2011 at 3:06 PM, Petrie, Glen <glen.petrie at eitc.epson.com> wrote:
If the "color-mode" refers to the capability (setting) of the scanner or the fax; then I vote for 1. below to clearly denote this. An image does not have a "color-mode"; it has a color space. Mode implies functionality not a state.
Glen
-----Original Message-----
From: ipp-bounces at pwg.org [mailto:ipp-bounces at pwg.org] On Behalf Of Mitchell, Andrew (Solutions Architect)
Sent: Tuesday, April 19, 2011 12:00 PM
To: tom.hastings at alum.mit.edu; 'Ira McDonald'; 'Michael Sweet'
Cc: ipp at pwg.org
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
OK, my 2¢.
We need to decide if naming a NEW attribute that applies to more then just print with the print- prefix makes sense. A agree that renaming existing attributes does not make sense, and using the print- attributes in scan (and fax) rather then renaming them is logical. But if we are going to say attributes that are originally defined in Scan (or Fax) start with imaging- while if they first show up in IPP Everywhere (or some other doc like JPS3) we name them print- that doesn't seam quite right. My preference would be either:
1. Call everything that is not scan (or fax) specific print-, no matter where it is first defined. For scan or fax specific, call them scan- and fax-.
2. Start using the imaging- prefix everywhere that the term is NOT print specific.
We are going to expand the model which is heavily rooted in print to other services, I'd just like to have a consistent naming convention for how we move forward. 1 seems more confusing to me since it means keeping the print- name moving forward, and we'll have to maintain the table as to what is print specific and what isn't, but 1 also seems more true to the roots of IPP. I however personally vote for 2 since it clearly implies our broader scope of the protocol moving forward.
As for just dropping the print- prefix, while it works for color-mode, I think we need to take a harder look to make sure it makes sense everywhere. Note that I view this as simply a different way of naming option 2. If we pick option 2 we need to then pick the naming convention.
OK, so that was a bit more the 2¢ worth.
Andrew
From: Tom Hastings <tom.hastings at verizon.net<mailto:tom.hastings at verizon.net>>
Reply-To: "tom.hastings at alum.mit.edu<mailto:tom.hastings at alum.mit.edu>" <tom.hastings at alum.mit.edu<mailto:tom.hastings at alum.mit.edu>>
Date: Tue, 19 Apr 2011 18:45:45 +0000
To: 'Ira McDonald' <blueroofmusic at gmail.com<mailto:blueroofmusic at gmail.com>>, 'Michael Sweet' <msweet at apple.com<mailto:msweet at apple.com>>
Cc: "ipp at pwg.org<mailto:ipp at pwg.org>" <ipp at pwg.org<mailto:ipp at pwg.org>>
Subject: RE: [IPP] "print-color-mode" or "imaging-color-mode"?
I agree with Ira. On the other hand, one other alternative for the name would just to drop the "print-" prefix and call it "color-mode".
Tom
________________________________
From: ipp-bounces at pwg.org<mailto:ipp-bounces at pwg.org> [mailto:ipp-bounces at pwg.org] On Behalf Of Ira McDonald
Sent: Monday, April 18, 2011 15:35
To: Michael Sweet; Ira McDonald
Cc: ipp at pwg.org<mailto:ipp at pwg.org>
Subject: Re: [IPP] "print-color-mode" or "imaging-color-mode"?
Hi Mike,
My two cents.
No - let's keep the name "print-color-mode" to cohere with the
zillion other print-xxx or printer-xxx attributes.
In the new IPP Scanner and Fax objects lets just globally apply
most/many existing IPP Printer attributes in big table(s) with
a rationale for why some attributes are not applicable to the
other multifunction objects.
Unless almost all Printer attributes *are* applicable, which I begin
to suspect is the case (and have a short table of the exceptions).
I think we should reserve use of he "imaging-" prefix for only new
attributes defined first for Scanner, Fax, etc. objects for IPP
Everywhere Second Edition.
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<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 Mon, Apr 18, 2011 at 4:52 PM, Michael Sweet <msweet at apple.com<mailto:msweet at apple.com>> wrote:
All,
If we consider scanning and printing of forms, the "bi-level" (threshold) mode makes sense for both. Do we want to rename "print-color-mode" to "imaging-color-mode" in anticipation of using is for other MFD services in 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.
_______________________________________________
ipp mailing list
ipp at pwg.org<mailto: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<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.
_______________________________________________
ipp mailing list
ipp at pwg.orghttps://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/20110419/99843f9a/attachment-0001.html>