PIN printing

Bug #1206985 reported by Tim Waugh
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
HPLIP
New
Undecided
Unassigned

Bug Description

It looks like PIN printing only works when all the relevant options are provided at job submission time... shouldn't it also use defaults specified in the PPD file?

Am I misunderstanding how PIN printing is meant to work?

Revision history for this message
Tim Waugh (twaugh) wrote :

In the hpps filter it says:

if 'HPPin' in options and 'noHPPinPrnt' not in options:

Shouldn't that be 'HPPinPrnt' instead of 'HPPin'? That's the name of the PPD option. The equivalent code in hplipjs.c says:

if (( strstr(argv[5], "HPPin")) && !(strstr (argv[5], "noHPPinPrnt")))

strstr() will obviously find HPPinPrnt, so that looks fine.

Revision history for this message
Gaurav (jeyaa) wrote :

Hi

For first question ppd defaults are taken if values are not supplied. e.g. if one of the digits are not selected default value of 'zero' is supplied. Though there is a issue that values are

For second question 'options' is a big python string and 'if' statement will search the substring 'HPPin' from 'options'. But I am deliberately searching for 'HPPin' it had to with the problem that applications like CPD or libreoffice doesn't parse PPD's in the same way. I am not able to recall the exact scenario.

Thanks
Gaurav

Revision history for this message
Tim Waugh (twaugh) wrote :

Ah, I see now that options is a string, not a list.

I still don't think the PPD defaults are used if digits are not supplied in the job options. The part that reads the PPD options is after the part that writes out the HOLDKEY string.

Revision history for this message
Gaurav (jeyaa) wrote :

The PPD is parsed by the applications like Common Priting Dialog( CPD), libreoffice etc. When we set up a queue we can see the PPD's default value under "Advanced > Secure Printing" in CPD. From there on the values (digits in this case ) are passed upon to cups filter.

Regards
Gaurav

Revision history for this message
Tim Waugh (twaugh) wrote :

So "lp file.pdf" doesn't work?

Revision history for this message
Gaurav (jeyaa) wrote :

 The 'HOLDKEY' is generated based upon the digit attributes (HPFIDIigit, HPSEDigit, etc defined in the PPD) present in the 'option' string. if any attribute is missing in the 'options' string that attribute is mapped to default value of zero in the code (default value is not read from the PPD though). For "lp -oHPPin file.pdf" the hold key generated will be '0000'

Revision history for this message
Tim Waugh (twaugh) wrote :

Why doesn't it use the default values from the PPD file?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.