Numerical options: Values between the PPD choices (was: Foomatic 3.0 and KDE Print)

[Till Kamppeter]

Michael Goffioul wrote:
>>*OpenUI *GammaSaturation/Gamma correction on saturation HSV component:
>>PickOne
>>*FoomaticRIPOption GammaSaturation: float CmdLine C
>>*FoomaticRIPOptionPrototype GammaSaturation: " -satgamma %s"
>>*FoomaticRIPOptionRange GammaSaturation: 0.10 10.0
>>*OrderDependency: 250 AnySetup *GammaSaturation
>>*DefaultGammaSaturation: 1.0
>>*GammaSaturation 0.1/0.1: "%% FoomaticRIPOptionSetting: GammaSaturation=0.1"
>>*GammaSaturation 0.2/0.2: "%% FoomaticRIPOptionSetting: GammaSaturation=0.2"
>>*GammaSaturation 0.3/0.3: "%% FoomaticRIPOptionSetting: GammaSaturation=0.3"
>>
>>...
>>
>>*GammaSaturation 9.8/9.8: "%% FoomaticRIPOptionSetting: GammaSaturation=9.8"
>>*GammaSaturation 9.9/9.9: "%% FoomaticRIPOptionSetting: GammaSaturation=9.9"
>>*GammaSaturation 10.0/10.0: "%% FoomaticRIPOptionSetting:
>>GammaSaturation=10.0"
>>*CloseUI: *GammaSaturation
> 
> 
> I have another question concerning numerical option. Can you save a
> default value into the PPD file, that is different from all the choices.
> For example, can save 0.28 as default GammaSaturation in the example
> above. One way to do it would be to save 2 values:
> - the exact value in some "*Foomatic..." line
> - the nearest possible choice as normal PPD value
> Any Foomatic-aware system could then use the exact value. However, 
> after looking at PPD examples from Foomatic-2.9 (obtained from the
> experimental web site), I couldn't see any example of exact value
> saved in the PPD file. If this is impossible, then there's no point
> in showing such an option as plain numerical, instead of common
> choice.

When I save a default value which does not match one of the choices in 
the usual "*DefaultGammaSaturation: ..." line, foomatic-rip will take 
care of it. So for CUPS

    lpr -o GammaSaturation=1.372 file.ps

or for LPRng

    lpr -Z GammaSaturation=1.372 file.ps

(and naturally the same for every other spooler) will really apply 1.372 
for "GammaSaturation" in the print job.

Problem is that OpenOffice.org (or a PPD-aware Windows client) would 
show (and send) a wrong value. It is perhaps really the better solution 
to add another keyword which is for example

*FoomaticRIPDefaultGammaSaturation: 1.372

so that if the user has a Foomatic-aware application and sets the 
default to 1.372 the following defaults are set:

*FoomaticRIPDefaultGammaSaturation: 1.372
*DefaultGammaSaturation: 1.4

(1.4 is the closest existing choice to 1.372)

For the case that no valid (between min and max, not necessarily a given 
choice) value is provided on the command line, "foomatic-rip" should 
then use the "*FoomaticRIPDefaultGammaSaturation" as long as the 
"*DefaultGammaSaturation" is still the closest existing choice or an 
invalid value. If  "*DefaultGammaSaturation" is an existing choice which 
is not the closest one to "*FoomaticRIPDefaultGammaSaturation" one must 
assume that a PPD-aware, but not Foomatic-aware application has modified 
the default and this one has also to respect. Example:

The KDE Printing Manager sets

*FoomaticRIPDefaultGammaSaturation: 1.372
*DefaultGammaSaturation: 1.4

then "foomatic-rip" has to use GammaSaturation=1.372. Later on the user 
says:

lpadmin -p printer -o GammaSaturation=1.7

and this makes CUPS setting

*FoomaticRIPDefaultGammaSaturation: 1.372
*DefaultGammaSaturation: 1.7

CUPS does not know "*FoomaticRIPDefaultGammaSaturation" and so leaves 
that keyword untouched. Now the "*DefaultGammaSaturation" is not the 
closest existing choice to the "*FoomaticRIPDefaultGammaSaturation" any 
more, so "foomatic-rip" has to use GammaSaturation=1.7 now.

So all PPD- and not Foomatic-aware applications will use the closest of 
the values they know and for Foomatic-aware applications or the command 
line one will have the exact fine-tuning. I think I will implement it 
this way. WDYT?

    Till