[Printing-architecture] "no-color-management" not a good idea for a name of a boolean CUPS option

[Printing-architecture] "no-color-management" not a good idea for a name of a boolean CUPS option

[Till Kamppeter]

Hi,

I have encountered a problem with the "no-color-management" and
cupsGetOption() not be able to recognize that the user has supplied "-o
no-color-management" on the command line.

If you have an arbitrary boolean option in CUPS filters or backends,
like "xxx" the variants

   -o xxx
   -o xxx=1
   -o xxx=on
   -o xxx=yes
   -o xxx=true

are supposed to let it be interpreted as set and

   -o noxxx
   -o xxx=0
   -o xxx=off
   -o xxx=no
   -o xxx=false

let it be interpreted as not set. To support the "-o noxxx" case
cupsGetOption() seems to split a "no" in the beginning of the name off
if there is no '='. Therefore "no-color-management=" works but
"no-color-management" not. The latter is probably interpreted as
"-color-management=false".

Mike, am I right with this?

So I suggest something like "calibration-mode", "cm-calibration-mode",
"cm-calibration", or similar.

WDYT?

   Till

Re: [Printing-architecture] "no-color-management" not a good idea for a name of a boolean CUPS option

[Michael Sweet]

Till,

On Jun 12, 2014, at 6:13 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:
> ...
> let it be interpreted as not set. To support the "-o noxxx" case
> cupsGetOption() seems to split a "no" in the beginning of the name off
> if there is no '='. Therefore "no-color-management=" works but
> "no-color-management" not. The latter is probably interpreted as
> "-color-management=false".
> 
> Mike, am I right with this?

Yes.

> So I suggest something like "calibration-mode", "cm-calibration-mode",
> "cm-calibration", or similar.

Or just use "color-managemnt" as the option so you can specify "nocolor-management" or "color-management=false".  The filter will see "nocolor-management".

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Re: [Printing-architecture] "no-color-management" not a good idea for a name of a boolean CUPS option

[Chris Murphy]

On Jun 12, 2014, at 4:13 AM, Till Kamppeter <till.kamppeter@gmail.com> wrote:

> Hi,
> 
> I have encountered a problem with the "no-color-management" and
> cupsGetOption() not be able to recognize that the user has supplied "-o
> no-color-management" on the command line.
> 
> If you have an arbitrary boolean option in CUPS filters or backends,
> like "xxx" the variants
> 
>   -o xxx
>   -o xxx=1
>   -o xxx=on
>   -o xxx=yes
>   -o xxx=true
> 
> are supposed to let it be interpreted as set and
> 
>   -o noxxx
>   -o xxx=0
>   -o xxx=off
>   -o xxx=no
>   -o xxx=false
> 
> let it be interpreted as not set. To support the "-o noxxx" case
> cupsGetOption() seems to split a "no" in the beginning of the name off
> if there is no '='. Therefore "no-color-management=" works but
> "no-color-management" not. The latter is probably interpreted as
> "-color-management=false".
> 
> Mike, am I right with this?
> 
> So I suggest something like "calibration-mode", "cm-calibration-mode",
> "cm-calibration", or similar.

I agree that color management is too general a term and it's confusing what it means. So it's useful in the form of cm- to make it easier to find color management related switches, but the switches themselves have separate names:

cm-linearization
cm-calibration
cm-ICC
cm-3DLUT

And so on, each with a Boolean value. 


Chris Murphy

Re: [Printing-architecture] "no-color-management" not a good idea for a name of a boolean CUPS option

[Joseph Simon]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

Hi Till,

I agree on the name change for the CUPs bool option.
The name "cm-calibration" seems to make the most sense, and I will make the
change in the filters.

Joe Simon
On Jun 12, 2014 3:12 AM, "Till Kamppeter" <till.kamppeter@gmail.com> wrote:

> Hi,
>
> I have encountered a problem with the "no-color-management" and
> cupsGetOption() not be able to recognize that the user has supplied "-o
> no-color-management" on the command line.
>
> If you have an arbitrary boolean option in CUPS filters or backends,
> like "xxx" the variants
>
>    -o xxx
>    -o xxx=1
>    -o xxx=on
>    -o xxx=yes
>    -o xxx=true
>
> are supposed to let it be interpreted as set and
>
>    -o noxxx
>    -o xxx=0
>    -o xxx=off
>    -o xxx=no
>    -o xxx=false
>
> let it be interpreted as not set. To support the "-o noxxx" case
> cupsGetOption() seems to split a "no" in the beginning of the name off
> if there is no '='. Therefore "no-color-management=" works but
> "no-color-management" not. The latter is probably interpreted as
> "-color-management=false".
>
> Mike, am I right with this?
>
> So I suggest something like "calibration-mode", "cm-calibration-mode",
> "cm-calibration", or similar.
>
> WDYT?
>
>    Till
>

[-- Attachment #2: Type: text/html, Size: 1774 bytes --]

Re: [Printing-architecture] "no-color-management" not a good idea for a name of a boolean CUPS option

[Till Kamppeter]

OK, Joseph.

Thank you to everyone to give your opinion.

   Till

On 06/12/2014 08:15 PM, Joseph Simon wrote:
> Hi Till,
> 
> I agree on the name change for the CUPs bool option.
> The name "cm-calibration" seems to make the most sense, and I will make
> the change in the filters.
> 
> Joe Simon
> 
> On Jun 12, 2014 3:12 AM, "Till Kamppeter" <till.kamppeter@gmail.com
> <mailto:till.kamppeter@gmail.com>> wrote:
> 
>     Hi,
> 
>     I have encountered a problem with the "no-color-management" and
>     cupsGetOption() not be able to recognize that the user has supplied "-o
>     no-color-management" on the command line.
> 
>     If you have an arbitrary boolean option in CUPS filters or backends,
>     like "xxx" the variants
> 
>        -o xxx
>        -o xxx=1
>        -o xxx=on
>        -o xxx=yes
>        -o xxx=true
> 
>     are supposed to let it be interpreted as set and
> 
>        -o noxxx
>        -o xxx=0
>        -o xxx=off
>        -o xxx=no
>        -o xxx=false
> 
>     let it be interpreted as not set. To support the "-o noxxx" case
>     cupsGetOption() seems to split a "no" in the beginning of the name off
>     if there is no '='. Therefore "no-color-management=" works but
>     "no-color-management" not. The latter is probably interpreted as
>     "-color-management=false".
> 
>     Mike, am I right with this?
> 
>     So I suggest something like "calibration-mode", "cm-calibration-mode",
>     "cm-calibration", or similar.
> 
>     WDYT?
> 
>        Till
> 

Re: [Printing-architecture] "no-color-management" not a good idea for a name of a boolean CUPS option

[Joseph Simon]

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

Hi everyone,

Rev. 7225 of 'cups-filters' now replaces "no-color-management" with
"cm-calibration" for the bool option. So the following commands should work
without the added '=' symbol, and will disable ICC profile management:

$ rastertopdf 1 foo bar 1 "cm-calibration" input.ras >>output.pdf
$ foomatic-rip -p foo -o cm-calibration

Joe Simon




On Thu, Jun 12, 2014 at 2:22 PM, Till Kamppeter <till.kamppeter@gmail.com>
wrote:

> OK, Joseph.
>
> Thank you to everyone to give your opinion.
>
>    Till
>
> On 06/12/2014 08:15 PM, Joseph Simon wrote:
> > Hi Till,
> >
> > I agree on the name change for the CUPs bool option.
> > The name "cm-calibration" seems to make the most sense, and I will make
> > the change in the filters.
> >
> > Joe Simon
> >
> > On Jun 12, 2014 3:12 AM, "Till Kamppeter" <till.kamppeter@gmail.com
> > <mailto:till.kamppeter@gmail.com>> wrote:
> >
> >     Hi,
> >
> >     I have encountered a problem with the "no-color-management" and
> >     cupsGetOption() not be able to recognize that the user has supplied
> "-o
> >     no-color-management" on the command line.
> >
> >     If you have an arbitrary boolean option in CUPS filters or backends,
> >     like "xxx" the variants
> >
> >        -o xxx
> >        -o xxx=1
> >        -o xxx=on
> >        -o xxx=yes
> >        -o xxx=true
> >
> >     are supposed to let it be interpreted as set and
> >
> >        -o noxxx
> >        -o xxx=0
> >        -o xxx=off
> >        -o xxx=no
> >        -o xxx=false
> >
> >     let it be interpreted as not set. To support the "-o noxxx" case
> >     cupsGetOption() seems to split a "no" in the beginning of the name
> off
> >     if there is no '='. Therefore "no-color-management=" works but
> >     "no-color-management" not. The latter is probably interpreted as
> >     "-color-management=false".
> >
> >     Mike, am I right with this?
> >
> >     So I suggest something like "calibration-mode",
> "cm-calibration-mode",
> >     "cm-calibration", or similar.
> >
> >     WDYT?
> >
> >        Till
> >
>
>

[-- Attachment #2: Type: text/html, Size: 3276 bytes --]

Re: [Printing-architecture] "no-color-management" not a good idea for a name of a boolean CUPS option

[Till Kamppeter]

On 06/13/2014 01:52 AM, Joseph Simon wrote:
> Hi everyone,
> 
> Rev. 7225 of 'cups-filters' now replaces "no-color-management" with
> "cm-calibration" for the bool option. So the following commands should
> work without the added '=' symbol, and will disable ICC profile management:
> 
> $ rastertopdf 1 foo bar 1 "cm-calibration" input.ras >>output.pdf
> $ foomatic-rip -p foo -o cm-calibration
> 
> Joe Simon

I have looked into foomatic-rip and it seems that the "cm-calibration"
option only works when using foomatic-rip in direc/spooler-less mode. To
make it also working in CUPS mode you will probably also have to check
it in the first loop in the process_cmdline_options() function.

In imagetoraster you are not only renamimg the option and the variable
but also dropping "else cm_off = 0;" With this probably you need to
preset the variable to zero at declaration ("int cm_calibrate = 0;").

Rest seems to be OK.

Please check these points, as I only reviewed your commit but did not
actually test it.

It would be also nice if you add to all filters with the
"cm-calibration" option a line which generates debug log output telling
whether "cm-calibration" was set or not, like

fprintf(stderr, "DEBUG: Color Management: %s\n", cm_calibrate ?
"Calibration mode/deactivated" : "Standard mode/activated");

   Till

Re: [Printing-architecture] "no-color-management" not a good idea for a name of a boolean CUPS option

[Joseph Simon]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

Hi Till,

I have made the additions and fixes in rev. 7228.

Joe
On Jun 15, 2014 2:09 AM, "Till Kamppeter" <till.kamppeter@gmail.com> wrote:

> On 06/13/2014 01:52 AM, Joseph Simon wrote:
> > Hi everyone,
> >
> > Rev. 7225 of 'cups-filters' now replaces "no-color-management" with
> > "cm-calibration" for the bool option. So the following commands should
> > work without the added '=' symbol, and will disable ICC profile
> management:
> >
> > $ rastertopdf 1 foo bar 1 "cm-calibration" input.ras >>output.pdf
> > $ foomatic-rip -p foo -o cm-calibration
> >
> > Joe Simon
>
> I have looked into foomatic-rip and it seems that the "cm-calibration"
> option only works when using foomatic-rip in direc/spooler-less mode. To
> make it also working in CUPS mode you will probably also have to check
> it in the first loop in the process_cmdline_options() function.
>
> In imagetoraster you are not only renamimg the option and the variable
> but also dropping "else cm_off = 0;" With this probably you need to
> preset the variable to zero at declaration ("int cm_calibrate = 0;").
>
> Rest seems to be OK.
>
> Please check these points, as I only reviewed your commit but did not
> actually test it.
>
> It would be also nice if you add to all filters with the
> "cm-calibration" option a line which generates debug log output telling
> whether "cm-calibration" was set or not, like
>
> fprintf(stderr, "DEBUG: Color Management: %s\n", cm_calibrate ?
> "Calibration mode/deactivated" : "Standard mode/activated");
>
>    Till
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2099 bytes --]

Re: [Printing-architecture] "no-color-management" not a good idea for a name of a boolean CUPS option

[Till Kamppeter]

Looks OK, thank you very much.

   Till


On 06/15/2014 02:56 PM, Joseph Simon wrote:
> Hi Till,
> 
> I have made the additions and fixes in rev. 7228.
> 
> Joe