Description: Running LibreOffice v7.0.4.2 on Debian testing. With my Samsung SL-M4020ND 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. Commenting out the stanza *UIConstraints: *PageRegion [all but envelope/none page regions] *MediaType Envelope *UIConstraints: *MediaType Envelope *PageRegion [all but envelope/none page regions] (lines 1361 to 1383 of my PPD) allows "Envelope" MediaType selection; oddly enough, it seems that commenting out the single *UIConstraints: *PageRegion Letter *MediaType Envelope row is enough (see bug 106963 comment 15): perhaps the selected PageSize/PageRegion is ignored and the default is taken into consideration? Attaching the PPD and some screenshots, thanks Steps to Reproduce: 1. prepare a DL sized (110mmx220mm) document 2. select "Print..." 3. verify that the paper size matches, if it doesn't select "DL Envelope 110mm x 220mm" 4. press the "Properties..." button 5. verify that the paper size matches the document, if it doesn't check "Use paper size from printer settings" and select "DL Env.", "Horizontal" 6. select the "Device" tab 7. select "Paper Type" Actual Results: Only "Printer Default" paper type appears Expected Results: "Printer Default" and "Envelope" paper types can be selected Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.4.2 Build ID: 00(Build:2) CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: it-IT (it_IT.UTF-8); Interfaccia utente: it-IT Debian package version: 1:7.0.4-3 Calc: threaded
Created attachment 170228 [details] Fixed Samsung SL-M4020 PPD (envelope MediaType not selectable)
Created attachment 170229 [details] Page Style of the tested document
Created attachment 170230 [details] Printer properties - "Paper" tab
Created attachment 170231 [details] Printer properties - "Device" tab
Confirmed, s. bug 106963 comment 15
As of 7.1.7 on Mac OSX 11.6 I have no reason to suspect that other OS's are any different but this is the skinny from the UX in layman's terms. Selecting different orientations for the envelope and selecting different feed positions creates different paper definitions. Sounds like I'm stating the obvious but bear with me. The printer will have a paper definition for an envelope, e.g. DL. The left/right position of the envelope with respect to the feed chute is controlled by the way writer defines the paper definition (again bear with me). To print to the left or right edges of the chute, writer will define a page larger than the envelope and represent the envelope using a frame within that page. The position of the frame determines the position of the envelope within the feed chute. The page chosen should be taken from the PPD or other printer system defined source as should the position of the envelope with respect to that page and therefore the feed chute. I have an HP printer and the paper definition is consistent with the envelope definition, so the page and envelope definitions are identical and therefore on the screen, this appears as a DL envelope. On other printers like my old Epson, it appeared as a sheet of A4 paper in landscape with a DL size frame top right. On my old Samsung the DL was bottom right. In both cases the chute had a slider that moved from the right to left to make the chute narrower. PageRegion is the paper definition that the frame will be on and the MediaType will be the what is offered to the user as the media i.e. DL Envelope or just envelope. Many printer manufactures cut down on the amount of work they have to do to write a PPD by defining something like a sheet of A4 as "Envelope" regardless of the actual size of the envelope. It doesn't care it simply starts printing in one corner of the page regardless and relies on writer limit where it actually prints. "Envelope" can select other things apart from dimensions too but were only interested dimensions here. Where there are lots of envelope definitions in the PPD (which may or may not be presented to the user for selection in media) it is likely that the printer actually has knowledge of these sizes and cares about them too. Typically these printers (like my HP) have an adjustable chute in which both guides move so that the envelope regardless of size remains central. So, seeing that you have a PageRegion of Letter and a MediaType of Envelope it assumes all envelopes fit on a sheet of Letter size and not all do. Selecting a PageRegion large enough to carry the desired envelope or a region that places the envelope in the correct corner to start with. HTH.
I admit that I barely got only a part of what you wrote. That said, this printer too have an adjustable chute in which both guides move so that the envelope regardless of size remains central. I still don't understand why *UIConstraints: *PageRegion Letter *MediaType Envelope prevents Envelope media type selection altogether, regardless of the page region. Can your considerations explain this? Thanks
(In reply to Michael Weghorn from comment #5) > Confirmed, s. bug 106963 comment 15 I think this bug is a duplicate of Bug 115481. What do you think?
(In reply to João Paulo from comment #8) > (In reply to Michael Weghorn from comment #5) > > Confirmed, s. bug 106963 comment 15 > > I think this bug is a duplicate of Bug 115481. What do you think? My understanding from quickly getting over both tickets is that the issue described here is that some printer/PPD options cannot be selected in the print dialog, while in tdf#115481, the paper size that *was* selected isn't applied correctly. If so, that looks to me at first as if it might be 2 different issues, but I haven't investigated further. What do you think?
Dear Mau, 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