[Printing-architecture] "no-color-management" not a good idea for a name of a boolean CUPS option
Joseph Simon
jsimon383 at gmail.com
Thu Jun 12 23:52:54 UTC 2014
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 at 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 at gmail.com
> > <mailto:till.kamppeter at 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/printing-architecture/attachments/20140612/af69bcc4/attachment-0001.html>
More information about the Printing-architecture
mailing list