https://bugs.freedesktop.org/show_bug.cgi?id=61189
--- Comment #10 from tmacalp <tmac...@gmail.com> --- -------------------------------------- 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 -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
