Download it now!
Bug 106963 - Print Dialog: PPD conflicts may lead to valid printer options being unavailable
Summary: Print Dialog: PPD conflicts may lead to valid printer options being unavailable
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
5.3.1.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Printer-Settings
  Show dependency treegraph
 
Reported: 2017-04-05 05:34 UTC by Stephane Peter
Modified: 2019-01-05 12:59 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
PPD file exhibiting the behavior (223.15 KB, text/plain)
2017-10-25 07:46 UTC, Stephane Peter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephane Peter 2017-04-05 05:34:44 UTC
Description:
I am using a PostScript printer in CUPS with PPD options like the following:

*OpenUI *StapleType/Staple/Eco (Staple-Free): PickOne
*OrderDependency: 50.0 AnySetup *StapleType
*DefaultStapleType: StapleOff
*StapleType StapleOff/Off: "<</Staple 0 >> systemdict /setpagedevice get exec"
*StapleType StapleON/Staple: ""
*StapleType StapleFree/Eco (Staple-Free): ""
*CloseUI: *StapleType

The last two choices in this option (StapleON and StapleFree) are not presented in the printing dialog, under the device properties tab. I believe they are likely being skipped because they do not emit code.

However this is incorrect behavior as these choices should still be available to the user, as in this case the absence of code triggers the features (as weird as it may seem).


Steps to Reproduce:
1. Choose to print any document in LibreOffice
2. Select a printer device using a PPD with an option that includes choices with empty strings.
3. Hit "Properties..." then the Device tab.

Actual Results:  
The corresponding options do not show in the device properties dialog and are therefore out of reach to the user.

Expected Results:
All choices as defined in the PPD, even those including empty strings, should be shown in the user interface for device properties.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30
Comment 1 Buovjaga 2017-04-26 09:06:38 UTC
I found the thing where this needs to be taken into consideration: http://opengrok.libreoffice.org/xref/core/vcl/unx/generic/printer/ppdparser.cxx#853
Comment 2 Michael Weghorn 2017-10-25 06:28:45 UTC
(In reply to Stephane Peter from comment #0)
> Description:
> I am using a PostScript printer in CUPS with PPD options like the following:
> 
> [...]

Thank you for reporting this. Is it possible to attach the actual PPD file to this bug report? I think this make it much easier to analyse the problem.
Comment 3 Stephane Peter 2017-10-25 07:46:30 UTC
Created attachment 137278 [details]
PPD file exhibiting the behavior

Here is a sample PPD file from Canon, with a StapleType option as described.
Comment 4 Michael Weghorn 2017-10-25 11:41:55 UTC
Thanks for attaching the PPD file.

I have had a look at this. The reason why the latter two values for "StapleLocation" are not shown is that they conflict with other options from the PPD being set.
The "UIConstraints" directives in the PPD file specify which pair of options may not be set together.

For example:

The default value for "StaplePos" is "PosNone" and the PPD File contains (among others) the following directives:

~~~
*UIConstraints: *StaplePos PosNone *StapleType StapleON
*UIConstraints: *StapleType StapleON *StaplePos PosNone
~~~

This means that the value "StapleON" for "StapleType" cannot be set together with the value "PosNone" for "StaplePos".

What LibreOffice currently does is that it hides values incompatible with other options currently being set; therefore "StapleType StapleON" is not available (since "StaplePos PosNone" is currently set).

At first sight, it seems like  the conflicts between the various stapling-related options (or rather their values) in your PPD file might keep each other from being shown so that there is no way to enable stapling from the print dialog with the given default values.


At least one way to still make it possible to use those options is to set the default options for a printer accordingly. It is also possible to create a CUPS printer instance with a different set of options as default values, e.g. if your printer is called "myprinter", you can create a printer instance "myprinter/myinstance" with the following command:

    lpoptions -p myprinter/myinstance -o StaplePos=1PRB -o StapleType=StapleON -o OptFIN=StplFinU1

After that (and restarting LibreOffice), an additional printer "myprinter/myinstance" should show up in the print dialog where stapling is enabled by default. You will also see the respective options being available and set in the dialog.

At least for the options in the so called "InstallableOptions" section in the PPD file, correct values should be set system-wide as they describe hardware-specific aspects, e.g. "OptFIN" describes whether a (and what kind of) finisher is installed.

(You can also see the situation with the conflicts when you use an application using the Gtk+ print dialog, e.g. Firefox: As soon as you select the value "Staple" for the option "Staple/Eco (Stpale-Free)", a warning will appear that some settings in the dialogue do conflict.)
Comment 5 Xisco Faulí 2018-01-17 15:08:47 UTC
@Michael Weghorn, how we should proceed with this issue? Should it be closed as RESOLVED NOTABUG or should it be moved to NEW?
Comment 6 Michael Weghorn 2018-01-17 19:59:52 UTC
(In reply to Xisco Faulí from comment #5)
> @Michael Weghorn, how we should proceed with this issue? Should it be closed
> as RESOLVED NOTABUG or should it be moved to NEW?

In my opinion, moving to NEW is more appropriate (which I do hereby).
While the situation with the given PPD might be "special" in some sense, it is still valid and other print dialogs (like the Gtk one) handle conflicting options in another way that does not show the described problem.

Fixing the problem would probably require a fundamental change in how conflicts in options are handled.
Comment 7 Michael Weghorn 2018-01-17 20:02:16 UTC
I'm also changing the title according to my observations in comment 4.