Bug 61189 - PDF printing mode problem: HP LaserJet + media type + no tray + user prompt (refer comment #10)
Summary: PDF printing mode problem: HP LaserJet + media type + no tray + user prompt (...
Status: CLOSED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: Other Linux (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Print
  Show dependency treegraph
 
Reported: 2013-02-20 21:18 UTC by crxssi
Modified: 2023-12-26 07:25 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
PPD (Postscript Printer Description) file for HP PS printers (14.20 KB, application/vnd.cups-ppd)
2013-02-22 17:22 UTC, crxssi
Details
We aim to deliver simple, easy and affordable solutions to cash app users. Our team of knowledgeable, dedicated and proficient cash app representatives make legitimate efforts to organize better suppo (deleted)
2020-03-04 12:37 UTC, mike jorg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description crxssi 2013-02-20 21:18:30 UTC
When you select to use PDF printing mode (which is the default in LO 4.0+), print jobs are no longer requesting paper sizes in postscript page printers.  If you change to the more traditional postscript printing mode (uncheck Tools-> Options-> LibreOffice-> Print-> Printer-> "PDF as Standard Print Job Format") the problem disappears.

This is probably specific to Linux (or perhaps Linux and MacOS).  We are using LO 4.0.0 on RHEL 6 using CUPS 1.4.2.  Printers tested are HP Laserjets P3015, 4250, 2400, and Xerox Document Centres.  The PPD's used are for postscript printers (which is all we use).

Steps to reproduce:

* On Linux + CUPS + PS printer PPD + PDF printing mode, open Writer.
* Create a document.
* Format-> Page-> Page-> Format-> choose some non-loaded size like "legal".
* File-> Print.  Note the paper size is set to "legal".  Print the document.
* The printer will print it on letter sized paper without warnings.

I have tried several loaded or unloaded page and paper sizes and NONE of them work when in PDF printing mode.  The correct behavior if you send a legal sized job to a page printer and the printer has no legal paper loaded, it should alert the user to load legal and if it has legal sized paper loaded in a tray, it will print it to that tray. 

This is an extremely serious problem for us (my 150+ users).  Fortunately, we can still revert back to postscript printing for all users as a workaround until there is a fix.
Comment 1 Robinson Tryon (qubit) 2013-02-21 03:12:56 UTC
(U 12.04.2, LO 4.0.0.3)


> On Linux + CUPS + PS printer PPD + PDF printing mode,

Using CUPS+Gutenprint v5.2.8-pre1

> open Writer.

Yep

> Create a document.

Pasted in some text I needed to print out (Hel Ved - Norway firewood specialists).

> Format-> Page-> Page-> Format-> choose some non-loaded
> size like "legal".

Chose "Legal"

Note: I have no Legal-sized tray in my printer

> File-> Print.  Note the paper size is set to "legal".
> Print the document.

Confirmed: paper size is set as Legal
(it's listed right above the preview graphic)

> The printer will print it on letter sized paper without
> warnings.

Confirmed: document printed on letter-sized paper; no warnings issued

> If you change to the more traditional postscript printing
> mode (uncheck Tools-> Options-> LibreOffice-> Print->
> Printer-> "PDF as Standard Print Job Format") the problem
> disappears.

NACK: I am not warned if I print a Legal-sized paper when I set the standard job format as PS. However, this may be a result of not having a Legal-sized paper tray.

In both cases, the printed page has no bottom margin -- the lines continued right off the bottom of the page.

---

Result: I would expect to be warned about my document page size not matching the tray of my printer.

I'm not marking this bug as NEW because I'm unable to confirm that PS printing fixes the issue. It's possible I'm seeing a different behavior of LO + the printing system.

Todo: We need someone with a more similar system to confirm this one.
Comment 2 crxssi 2013-02-22 17:19:13 UTC
I have some additional information.  Through testing we discovered (by accident) that in PDF printing mode, the paper size will go through to the printer if a tray is selected.  Normally, users should not select a tray (our PPD has an option for "Automatic" which is the default).  The printer will select the appropriate tray based on the paper size and media type in the document.  This is the most "proper" way to perform printing to intelligent, multi-tray, page printers (although most people don't do this).

Using our PPD (or perhaps some other), the strange behavior can be illustrated with this example:

* Format-> Page-> Page-> "#10 Envelope"
* File-> Print (it will print on letter on default tray)
* File-> Print-> Properties-> Paper tray-> "Tray 2" (printer will ask user to load COM10 in tray 1).

Unfortunately, this complicates this issue, but at least it is progress.  I am attaching the PPD to this bug after this message to help with possible troubleshooting by someone else.  It is called HP_LaserJet_4000+4200+P3000_series-PS-LTTCH.ppd" and should work with any reasonably new (last several years) HP PS Laserjet printer.  Make sure when setting up a printer in CUPS that the default media source is "Automatically Select" and the default media type is "None".
Comment 3 crxssi 2013-02-22 17:22:07 UTC
Created attachment 75333 [details]
PPD (Postscript Printer Description) file for HP PS printers

PPD (Postscript Printer Description) file for HP Postscript printers.  This will work with any reasonably recent, business-class HP Laserjet.  Specifically tested with 4000, 4200, P3015.
Comment 4 crxssi 2013-03-01 19:27:54 UTC
I have tested that the latest OpenOffice, version 3.4.1, has the same problem.
Comment 5 Joel Madero 2013-03-01 19:30:49 UTC Comment hidden (no-value)
Comment 6 Joel Madero 2013-04-14 18:48:10 UTC
unfortunately triaging this is going to require some serious hardware (modern day PS laser jet printer)....trying to find someone to actually confirm the problem :-/

@crxssi - apologies for the delay, we're trying
Comment 7 crxssi 2013-04-14 20:32:16 UTC
(In reply to comment #6)
> unfortunately triaging this is going to require some serious hardware
> (modern day PS laser jet printer)....trying to find someone to actually
> confirm the problem :-/
> 
> @crxssi - apologies for the delay, we're trying

Thanks for the update.

You are correct, a cheap inkjet printer is not going to help with troubleshooting in this case.  It really requires a multi tray, Postscript, color laser printer.

Let me know if there is any other way I can help.
Comment 8 crxssi 2013-07-26 13:21:41 UTC
This severe bug is still not fixed.  Same results in LO 4.1.  Thank goodness there is still a option to select PS printing, which does not having this problem.
Comment 9 Owen Genat (retired) 2013-11-09 01:00:34 UTC
I have a HP LaserJet 4050 TN on my network here which would seem to be in the same class of printers mentioned in the description and comment #3. If I can be of any assistance in further testing please let me know. The printer is made available via CUPS v1.5.3-5+deb7u1 under 3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686 GNU/Linux using an IPP connection. I do not have cups-driver-gutenprint or printer-driver-gutenprint installed. Here are some details from /etc/cups/ppd/HP4050_5.PPD if this helps at all:

*FormatVersion: "4.3"
*FileVersion: "1.1.2 X"
[...]
*%====================================
*%         Fit to Page
*%====================================
*OpenUI *HPOption_PaperPolicy/Fit to Page: PickOne
*OrderDependency: 10 AnySetup *HPOption_PaperPolicy
*DefaultHPOption_PaperPolicy: PromptUser
*HPOption_PaperPolicy PromptUser/Prompt User: "
   <</DeferredMediaSelection true>> setpagedevice"
*End
*HPOption_PaperPolicy NearestSizeAdjust/Nearest Size and Scale: "
   <</DeferredMediaSelection false>> setpagedevice
   <</Policies << /PageSize 3 >> >> setpagedevice"
*End
*HPOption_PaperPolicy NearestSizeNoAdjust/Nearest Size and Crop: "
   <</DeferredMediaSelection false>> setpagedevice
   <</Policies << /PageSize 5 >> >> setpagedevice"
*End
*?HPOption_PaperPolicy: "(PromptUser) = flush"
*CloseUI: *HPOption_PaperPolicy

In CUPS under Printer > select printer > Administration pull-down, select Set Default Options, I have Fit to Page: Prompt User.

CUPS defaults: job-sheets=none, none media=iso_a4_210x297mm sides=one-sided

I tested printing an example document with the page size set to Legal, under Crunchbang 11 running LO v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a. Regardless of whether I printed using a Printer Language Type of "PDF" or "PostScript (Level from driver)" I received a prompt at the printer indicating that the Legal paper size is unavailable. The job was held in both cases until I manually intervened.
Comment 10 tmacalp 2013-11-27 22:17:23 UTC
--------------------------------------
Quick Summary
--------------------------------------
My conclusion is that there is an issue with LO and stable (older) versions of the print stack that affects certain printers.  LibreOffice PDF-mode printing does not work properly with the RHEL6/CentOS6, openSUSE, or Mageia CUPS servers.  I was NOT able to reproduce the bug with CUPS servers running on the current Arch, Ubuntu 12.04, or Debian 7.2.  Postscript mode printing still functions properly.


--------------------------------------
Introduction/Overview
--------------------------------------
This ended up being quite a bit more complicated than I anticipated, so sorry if this is rather lengthy.  I tested to a number of postscript printers using a various CUPS servers and discovered some interesting results.  Out of our 3 main classes of network postscript printers (Xerox, Konica, and HP Laserjet), this issue only seems to affect our HPs.

All tests were generated in the same environment--Fedora 17 workstation running LibreOffice 4.1.2.3.  The jobs were then processed by various CUPS servers, all with printers configured using the PPDs supplied by crxssi.  I tried PPDs from openprinting.org and experienced the same issue.

I then conducted a number of tests to figure out exactly what is happening with the bug.  Most of the tests were to our primary RHEL6 print server(CUPS 1.4.2/foomatic 4.0.7) and my Fedora 17 workstation's print server (CUPS 1.5.4/foomatic 4.0.8).  Both of these print environments gave the same error originally reported.  After I learned exactly how to trigger the error, I tested various print servers.

I'm rather new to the world of CUPS/foomatic/gutenprint, but I think our issue is related to foomatic.  From what I've read, foomatic filters are used to convert non-postscript (LO PDF-mode) jobs to the printer's language specified in the PPD file.  Older versions of this package seem to be a common theme with systems that suffer from this error.  Unfortunately, my final test system, Mageia 3, disputes this hypothesis by showing a similar error to openSUSE while running a newer foomatic.  Maybe someone with a better understanding could weigh in.

In the post above, Owen wasn't able to reproduce the bug using Crunchbang, which I believe is based on Debian.  As mentioned above, I wasn't able to replicate the bug under Debian, so I guess that fits.


--------------------------------------
LibreOffice Environment
--------------------------------------
As mentioned in the overview above, all tests were performed from 32bit Fedora17 running LibreOffice 4.1.2.3.  I set my workstation's CUPS server to browse the various CUPS servers I created on bridge-networked virtual machines.


--------------------------------------
Print servers
--------------------------------------
64bit RHEL6 (Primary remote CUPS)
  CUPS 1.4.2
  foomatic 4.0.4

32bit Fedora 17 (Workstation local CUPS)
  CUPS 1.5.4
  foomatic-filters 4.0.8
  
Virtualbox remote CUPS servers created (all servers up-to-date via standard repos):
32bit CentOS 6.4
  CUPS 1.4.2
  foomatic 4.0.4

32bit Arch Linux
  CUPS 1.7.0
  foomatic-filters 4.0.17

32bit Ubuntu 12.04.3 LTS
  CUPS 1.5.2
  foomatic-filters 4.0.16

32bit Debian 7
  CUPS 1.5.3
  foomatic-filters 4.0.17

32bit openSUSE 13.1
  CUPS 1.5.4
  foomatic-filters 4.0.12

32bit Mageia 3
  CUPS 1.5.4
  foomatic-filters 4.0.17

--------------------------------------
Printers involved
--------------------------------------
These are the classes of printers involved.  The HP Laserjet printers are standard workgroup network postscript printers.  The Xerox/Konica Minolta machines are all large multi-tray copiers.

HP Laserjet 4000,4200,4250,and p3015
These were the machines that show the bug.  They always seem to pass the media TYPE(preprinted/letterhead/plain/etc...).  If page SIZE is not loaded in a tray, fit to page on the next largest size.  If a tray IS manually specified, everything works properly and the printer asks for that media to be loaded.  In a business environment, with multi-tray printers, you shouldn't have to specify which tray to use.  You should be able to allow the printer to automatically either select a tray that has that type/size paper assigned to it or prompt you to load it into the manual feed tray.

Xerox 245/255/5675
Always seems to work perfectly, prompting user to load paper when appropriate.

Konica Minolta bizhub 754
Always seems to work perfectly, prompting user to load paper when appropriate.


--------------------------------------
Detailed Bug Description
--------------------------------------
My test was to:
1. Create a new Writer document
2. Format Page
3. Apply border as a page style to see an outline to see if the error was fit-to-page or cropping
4. Change page size to specified size for test, mostly legal.
5. File->print
6. Change paper size to match formatted page, since LibreOffice 4.1.2.3 doesn't do this for you anymore and leaves this set to letter.
7. Make any other changes to media type/paper tray specified in the test, otherwise all settings were left as automatic or none.

The case where printing fails is when the printer...
* Is a HP Laserjet
* Is only using media size/type to automatically select a tray
* Doesn't have a tray already assigned to the requested media size/type
* Needs to prompt the user to load in the bypass tray.

If you print to a size/type that is currently loaded in a tray, the printer WILL use that media size/type to choose the correct tray.

If you manually specify the bypass tray, it will behave correctly, asking for the correct specified paper/media type to be inserted into the bypass tray.

It's only when the printer doesn't have the paper type/media type immediately loaded/assigned to a tray that it will give up and dump the job to plain letter.  It should prompt the user to load the correct media into the bypass tray, like it does when using the Postscript printing engine.

Even on CUPS servers affected by the bug, pdf-mode printing apparently passes tray/media settings perfectly on the Xerox machines and Konica-Minolta.  


--------------------------------------
Specific tests using RHEL6 CUPS 1.4.2/foomatic 4.0.4 and Fedora 17 CUPS 1.5.4/foomatic 4.0.8
--------------------------------------
The tests below are formatted into three columns
Requested: What paper size/type was requested by the LO job
Loaded: If the paper was actually loaded/assigned to a tray in the printer
Result: Actual result of the test

===========================
HP Laserjet 4000,4200,4250,and p3015
===========================
Requested		Loaded		Result
plain letter		Yes		pass - printed plain letter

preprinted letter	no		pass - asked for preprinted letter in bypass

plain legal		no		FAIL - printed plain LETTER instead of legal and fit it to page when printed

plain legal in bypass	no		pass - asked for plain legal in bypass

preprinted legal	no		FAIL - asked for preprinted LETTER instead of legal in bypass


We normally only stock letter sized paper in the trays, so I assigned one of them to be heavy plain legal.
heavy plain legal	yes		pass - printed heavy plain legal

prepunched legal	no		FAIL - asked for prepunched LETTER instead of legal in bypass


===========================
Xerox WorkCentre 245/255/5675 
===========================
Requested		Loaded?		Result
plain letter		Yes		pass - printed plain letter

preprinted letter	no		pass - asked for preprinted letter in bypass tray

plain legal		yes		pass - printed plain legal

preprinted legal	no		pass - asked for preprinted legal in bypass tray


===========================
Konica Minolta bizhub 754
===========================
Requested		Loaded		Result
plain letter		Yes		pass - printed plain letter

letterhead letter	no		pass - asked for letterhead letter in bypass tray

plain legal		yes		pass - printed plain legal

letterhead legal	no		pass - asked for letterhead legal in bypass tray

plain long bond		no		pass - asked for plain long bond in bypass tray



--------------------------------------
Specific tests using various VirtualBox printing environments
--------------------------------------

Arch Linux CUPS 1.7.0/Foomatic 4.0.17 (Works fine)
===========================
HP Laserjet 4000,4200,4250,and p3015
===========================
Requested		Loaded		Result
plain letter		Yes		pass - printed plain letter

preprinted letter	no		pass - asked for preprinted letter in bypass

plain legal		no		pass - asked for plain legal in bypass

plain legal in bypass	no		pass - asked for plain legal in bypass

preprinted legal	no		pass - asked for preprinted legal in bypass


openSUSE Linux CUPS 1.5.4/Foomatic 4.0.12 (FAIL)
===========================
HP Laserjet 4000,4200,4250,and p3015
===========================
plain legal		no		FAIL - printed plain LETTER instead of legal and cropped off the bottom of page


CentOS6 CUPS 1.4.2/foomatic 4.0.7 (FAIL)
===========================
HP Laserjet 4000,4200,4250,and p3015
===========================
plain legal		no		FAIL - printed plain LETTER instead of legal and fit it to page when printed


Ubuntu 12.04 CUPS 1.5.2/foomatic 4.0.16 (Works fine)
===========================
HP Laserjet 4000,4200,4250,and p3015
===========================
plain legal		no		pass - asked for plain legal in bypass


Debian 7.2 CUPS 1.5.3/foomatic 4.0.17 (Works fine)
===========================
HP Laserjet 4000,4200,4250,and p3015
===========================
plain legal		no		pass - asked for plain legal in bypass


Mageia 3 CUPS 1.5.4/Foomatic 4.0.17 (FAIL)
===========================
HP Laserjet 4000,4200,4250,and p3015
===========================
plain legal		no		FAIL - printed plain LETTER instead of legal and cropped off the bottom of page
Comment 11 Owen Genat (retired) 2013-11-29 23:30:22 UTC
(In response to comment #10)
> Debian 7.2 CUPS 1.5.3/foomatic 4.0.17 (Works fine)

To confirm this one aspect of comment #10, this is indeed the versions I have running here. As tmacalp suggested, Crunchbang 11 (my client system) is effectively Debian 7 and my server is Debian 7.

Thanks tmacalp for the terrific and comprehensive analysis.
Comment 12 crxssi 2013-11-29 23:58:27 UTC
I would rename this bug, if I had any clue what better to call it at this point.  Obviously it is not the case that it doesn't send paper sizes to all PS page printers and in all environments as I originally implied.  As can be seen by tmacalp's long and good testing posting, it is far from clear or simple.  My own testing leaves me terminally confused.

Even the behavior with PS printing is not perfect in all situations, but it appears to be much better (and more consistent) than PDF printing.  This is certainly one major reason that I hope the LO team doesn't plan to drop PS printing mode anytime soon ("soon" probably meaning years at this point).

For many of us, LO is one of the few applications where tray and media selection really matters a LOT... labels, letterhead, envelopes, transparencies, post cards, large signs, table tents, complex wide spreadsheets, card stock, etc.  And that is magnified in business where there are sophisticated, multi-tray lasers and copiers, often used by multiple people and departments with complex work flows.  In contrast, most other applications' printing being just simple stuff from browsers, accounting systems, Email, etc, that are all just printed on plain letter paper (or plain A4 for people in most other countries).

Finally, there could be significant debate over what really is "proper" behavior in many circumstances, further complicating the issue.
Comment 13 Owen Genat (retired) 2013-12-22 04:08:37 UTC
I think given the extensive detail in comment #10 that this can be confirmed, at least in-so-far as there is a problem of some description. Status set to NEW. Hopefully this will prompt some other more experienced people to review this bug. I think it will take an expert to determine whether it is some weird combination of CUPS+foomatic, HP-printer-related, LO-related, or something else.

(In reply to comment #12)
> I would rename this bug, if I had any clue what better to call it at this
> point.

You are not alone. I am going to be bold and have a go, based on the description provided by tmacalp: "PDF printing mode problem: HP LaserJet + media type + no tray + user prompt". Hopefully an expert will narrow it down and improve this.
Comment 14 akbar 2015-01-11 18:59:16 UTC Comment hidden (spam)
Comment 15 QA Administrators 2016-01-17 20:01:54 UTC Comment hidden (obsolete)
Comment 16 tmacalp 2016-01-29 16:11:27 UTC Comment hidden (obsolete)
Comment 17 QA Administrators 2017-03-06 13:45:58 UTC Comment hidden (obsolete)
Comment 18 tmacalp 2017-03-10 17:38:20 UTC
I can confirm this still affects:
Version: 5.3.0.3
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: x11; Layout Engine: new; 
Locale: en-US (en_US.UTF-8); Calc: group

when used with our same RHEL6 print stack.

I also discovered that the per-document printer language setting (Print->Properties->Device->Printer language type) is now completely ignored and reverted to global default (Tools->Options->LibreOffice->Print->PDF as standard print job format) as soon as you click ok.  But that's another bug.
Comment 19 QA Administrators 2018-03-11 03:41:02 UTC Comment hidden (obsolete)
Comment 20 Richard 2018-08-23 09:02:19 UTC Comment hidden (spam)
Comment 21 Jack Denial 2018-08-27 09:37:51 UTC Comment hidden (spam)
Comment 22 emni petro 2018-08-27 10:16:08 UTC Comment hidden (spam)
Comment 23 Aria Jones 2018-09-20 07:30:29 UTC Comment hidden (spam)
Comment 24 Janny Watson 2018-10-05 05:29:20 UTC Comment hidden (spam)
Comment 25 mohanashaw 2018-10-31 06:40:29 UTC Comment hidden (spam)
Comment 26 Jack Jone 2018-10-31 08:56:18 UTC Comment hidden (spam)
Comment 27 markcruz 2018-11-05 04:38:22 UTC Comment hidden (spam)
Comment 28 RAINSMITH 2018-11-12 06:54:02 UTC Comment hidden (spam)
Comment 29 Kaspersky 2018-11-17 06:11:12 UTC Comment hidden (spam)
Comment 30 Kaspersky 2018-11-17 06:12:41 UTC Comment hidden (spam)
Comment 31 Jack 2018-11-20 09:24:09 UTC Comment hidden (spam)
Comment 32 Saim Thomus 2018-11-23 08:11:51 UTC Comment hidden (spam)
Comment 33 emniclap 2019-02-27 10:20:56 UTC Comment hidden (spam)
Comment 34 emniclap 2019-02-27 10:21:57 UTC Comment hidden (spam)
Comment 35 Linda Graham 2019-03-10 04:44:51 UTC Comment hidden (spam)
Comment 36 ludochat 2019-04-05 07:22:02 UTC Comment hidden (spam)
Comment 37 ludochat 2019-04-05 07:22:42 UTC Comment hidden (spam)
Comment 38 Lizza Brown 2019-05-04 17:34:40 UTC Comment hidden (spam)
Comment 39 rayanwarner44 2019-05-25 05:11:26 UTC Comment hidden (spam)
Comment 40 Andre Russell 2019-06-06 10:29:17 UTC Comment hidden (spam)
Comment 41 James Smith 2019-06-19 10:28:47 UTC Comment hidden (spam)
Comment 42 brotherprintersupportnumber 2019-07-11 04:29:30 UTC Comment hidden (spam)
Comment 43 michaels johnson 2019-07-16 10:26:12 UTC Comment hidden (spam)
Comment 44 sofimariyam 2019-07-27 06:01:30 UTC Comment hidden (spam)
Comment 45 kevinlove44 2019-08-01 04:49:41 UTC Comment hidden (spam)
Comment 46 kevinlove44 2019-08-06 12:19:55 UTC Comment hidden (spam)
Comment 47 Tayloright 2019-09-13 08:07:28 UTC Comment hidden (spam)
Comment 48 adglevan 2019-10-10 18:16:16 UTC Comment hidden (spam)
Comment 49 Andre Russell 2019-11-01 07:17:59 UTC Comment hidden (spam)
Comment 50 adgroups 2019-11-19 19:20:08 UTC Comment hidden (spam)
Comment 51 jone cena 2019-12-09 11:26:04 UTC Comment hidden (spam)
Comment 52 Rebecca Smith 2019-12-13 10:16:44 UTC Comment hidden (spam)
Comment 53 jone pena 2019-12-21 07:18:13 UTC Comment hidden (spam)
Comment 54 adgwscorg 2020-01-13 08:31:24 UTC Comment hidden (spam)
Comment 55 adgwscorg 2020-01-13 08:33:15 UTC Comment hidden (spam)
Comment 56 adgwscin 2020-01-13 08:37:47 UTC Comment hidden (spam)
Comment 57 captainshop 2020-01-20 07:57:43 UTC Comment hidden (spam)
Comment 58 rebeccasmith52 2020-01-20 08:39:51 UTC Comment hidden (spam)
Comment 59 Electrical project solutions sydney 2020-01-24 04:22:34 UTC Comment hidden (spam)
Comment 60 Civicland Property Consultants and Valuers 2020-01-27 04:34:42 UTC Comment hidden (spam)
Comment 61 Aabir Abdallah 2020-01-28 08:24:25 UTC Comment hidden (spam)
Comment 62 Jack Alpha 2020-02-28 11:17:44 UTC Comment hidden (spam)
Comment 63 asad 2020-03-03 11:30:16 UTC Comment hidden (spam)
Comment 64 mike jorg 2020-03-04 12:37:06 UTC Comment hidden (spam)
Comment 65 Xisco Faulí 2020-03-04 12:50:29 UTC
The content of attachment 158382 [details] has been deleted for the following reason:

spam
Comment 66 yasir hussain 2020-03-06 06:41:34 UTC Comment hidden (spam)
Comment 67 Steven Findley 2020-07-21 15:53:58 UTC Comment hidden (spam)
Comment 68 Sameermehra 2020-07-29 17:49:59 UTC Comment hidden (spam)
Comment 69 Michael Weghorn 2020-12-16 09:49:28 UTC
Is this still an issue these days?

(In reply to tmacalp from comment #10)
> --------------------------------------
> Quick Summary
> --------------------------------------
> My conclusion is that there is an issue with LO and stable (older) versions
> of the print stack that affects certain printers.  LibreOffice PDF-mode
> printing does not work properly with the RHEL6/CentOS6, openSUSE, or Mageia
> CUPS servers.  I was NOT able to reproduce the bug with CUPS servers running
> on the current Arch, Ubuntu 12.04, or Debian 7.2.  Postscript mode printing
> still functions properly.
> [...]

This sounds like it *might* be an issue further down in the printing stack and worth taking a look what happens there.

If it's still an issue, the following might help to narrow it down:

1) set 'LogLevel debug' in /etc/cups/cupsd.conf
2) restart CUPS
3) print from LO as decribed here
4) attach the CUPS log file (or relevant parts for the last print process thereof here)
5) attach the file that LibreOffice generated for printing, which should be located at '/var/spool/cups/d<PRINT_JOB_ID>-001' (replace "<PRINT_JOB_ID>" with actual job ID)
Comment 70 Bestnewlyrics 2021-01-04 05:59:15 UTC Comment hidden (spam)
Comment 71 QA Administrators 2021-07-04 04:37:29 UTC Comment hidden (obsolete)
Comment 72 QA Administrators 2021-08-20 03:52:32 UTC Comment hidden (obsolete)
Comment 73 QA Administrators 2022-02-17 03:40:39 UTC Comment hidden (obsolete)
Comment 74 QA Administrators 2022-03-20 03:31:27 UTC
Dear crxssi,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp