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

(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.

Created attachment 137278 [details]
PPD file exhibiting the behavior

Here is a sample PPD file from Canon, with a StapleType option as described.

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.)

@Michael Weghorn, how we should proceed with this issue? Should it be closed as RESOLVED NOTABUG or should it be moved to NEW?

(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.

I'm also changing the title according to my observations in comment 4.

*** Bug 81821 has been marked as a duplicate of this bug. ***

Still reproducible with current master, s. bug 81821 comment 12.

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: edb953cfb77c7ad6578a191b48c47c25d8d59d11
CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

Hi, I'm running LibreOffice v7.0.4.2 on Debian testing.

On this version is indeed possible to select the paper size but with my Samsung SL-M4020 printer I'm unable to print envelopes even after fixing the PPD until cupstestppd is happy and by deleting all the constraints with MediaType none (this allows at least to select envelope paper sizes).

In order to correctly print an envelope fed into the manual feeder (it needs to be printed at the center of the page) I have to select the "Envelope" MediaType: all the constraints now look ok but when I select any envelope PageSize (i.e.: EnvDL) only the "Printer Default" MediaType remains available.

I triple checked all the UIConstraints in the PPD file and I'm unable to figure out what's preventing the selection. Attaching the PPD here.

Is this a LibreOffice bug? Could you give some advice?

Created attachment 170097 [details]
Fixed Samsung SL-M4020 PPD (envelope MediaType not selectable)

(In reply to Mau from comment #11)
> Hi, I'm running LibreOffice v7.0.4.2 on Debian testing.
> 
> On this version is indeed possible to select the paper size but with my
> Samsung SL-M4020 printer I'm unable to print envelopes even after fixing the
> PPD until cupstestppd is happy and by deleting all the constraints with
> MediaType none (this allows at least to select envelope paper sizes).
> 
> In order to correctly print an envelope fed into the manual feeder (it needs
> to be printed at the center of the page) I have to select the "Envelope"
> MediaType: all the constraints now look ok but when I select any envelope
> PageSize (i.e.: EnvDL) only the "Printer Default" MediaType remains
> available.
> 
> I triple checked all the UIConstraints in the PPD file and I'm unable to
> figure out what's preventing the selection. Attaching the PPD here.
> 
> Is this a LibreOffice bug? Could you give some advice?

If I understood the steps correctly, this works here for me, also with 7.0.4.2 on Debian testing:

* set up (dummy) printer with the PPD
* select the printer in print dialog
* go to "Properties"
* select "Use only paper size from printer preferences"
* select paper size "DL Env."
* optionally: select "Paper Tray": "MP/Manual Feeder"
* go to "Device" tab and select "Paper Type" -> "Envelope" (which is present)

Maybe options set in some user-specific ~/.cups/lpoptions might play a role? You can also try (temporarily) deleting more "UIConstraints" lines from the PPD for testing to see which one was relevant.

If the PPD value does not appear in your case, this might be the issue described here.

(In reply to Michael Weghorn from comment #13)
> [...]
> * go to "Device" tab and select "Paper Type" -> "Envelope" (which is present)
> 
> Maybe options set in some user-specific ~/.cups/lpoptions might play a role?
> You can also try (temporarily) deleting more "UIConstraints" lines from the
> PPD for testing to see which one was relevant.
> 
> If the PPD value does not appear in your case, this might be the issue
> described here.

First of all thanks for your reply.

You're right Michael. I posted a version of the PPD with the stanza

*UIConstraints: *PageRegion [all but envelope/none page regions] *MediaType Envelope 
*UIConstraints: *MediaType Envelope *PageRegion [all but envelope/none page regions]

commented out (lines 1361 to 1383 of my PPD). My bad.

That explains why you were able to select the MediaType Envelope: commenting out this stanza makes things work.

The answer remains: if there is no *UIConstraints preventing the selection of "DL Env." PageRegion along with the "Envelope" MediaType, why does enabling this stanza (as in the original PPD) change things?

Oddly enough, the "4x6" PageRegion also has a stanza which allows only the "Card" and "none" MediaTypes but in this case "CardStock" appears in the list available for selection without the need to disable the stanza.

I'm also wondering whether it makes sense to have constraints for PageRegions when the same constraints exist for the PageSizes.

Regarding ~/.cups/lpoptions, getting rid of it unfortunately didn't change things when the above mentioned stanza is not commented out.

(In reply to Mau from comment #14)
> You're right Michael. I posted a version of the PPD with the stanza
> 
> *UIConstraints: *PageRegion [all but envelope/none page regions] *MediaType
> Envelope 
> *UIConstraints: *MediaType Envelope *PageRegion [all but envelope/none page
> regions]
> 
> commented out (lines 1361 to 1383 of my PPD). My bad.
> 
> That explains why you were able to select the MediaType Envelope: commenting
> out this stanza makes things work.
> 
> The answer remains: if there is no *UIConstraints preventing the selection
> of "DL Env." PageRegion along with the "Envelope" MediaType, why does
> enabling this stanza (as in the original PPD) change things?

This was the relevant line causing that behaviour:

    *UIConstraints: *PageRegion Letter *MediaType Envelope

It's not clear to me at once why this is the case; would probably need further analysis in the source code. I suggest to open a separate bug report to handle this aspect further.


> I'm also wondering whether it makes sense to have constraints for
> PageRegions when the same constraints exist for the PageSizes.

While the two are usually the same, there is some difference between the two. The PPD specification contains more details. (I don't remember any more...)

> Regarding ~/.cups/lpoptions, getting rid of it unfortunately didn't change
> things when the above mentioned stanza is not commented out.

OK, that's expected; was just an idea on where the difference between behaviour for me and you came from, but that was the different PPD in use (lines commented out or not).

Thanks. Opened bug 140816.

Dear Stephane Peter,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug