[Desktop-packages] [Bug 1066423] Re: [Upstream] Calc can't print, export to PDF, or print preview
cuichi - I originally found the problem on a single-screen desktop system so can't check on then behavior you see. Unfortunately the upstream bug has had no attention from the LO developers since submission in October. I don't know if there's a way to bump something so it appears on the radar of whomever does triaging there? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1066423 Title: [Upstream] Calc can't print, export to PDF, or print preview Status in LibreOffice Productivity Suite: Confirmed Status in “libreoffice” package in Ubuntu: Triaged Bug description: 1) lsb_release -rd Description: Ubuntu 12.10 Release: 12.10 2) apt-cache policy libreoffice-calc libreoffice-calc: Installed: 1:3.6.2~rc2-0ubuntu3 Candidate: 1:3.6.2~rc2-0ubuntu3 Version table: *** 1:3.6.2~rc2-0ubuntu3 0 500 http://archive.ubuntu.com/ubuntu/ quantal/main i386 Packages 100 /var/lib/dpkg/status 3) What is expected to happen in Calc via a terminal: cd ~/Desktop wget https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1066423/+attachment/3397788/+files/loprob.ods localc --nologo loprob.ods Export to PDF, Print Preview, or print and it does so. 4) What happens when you: + Export to PDF is one gets a pop up noting: LibreOffice 3.6 Error saving the document loprob: Write Error. The file could not be written. + Page Preview it comes up with a blank gray background rather than a preview. Original Report Comments: + print Nothing was printed, but libreoffice displayed the string 'gtk printer' on the xterm console from which it was invoked, and left a directory and file '/tmp/luppt6wq.tmp/luppt6ws.tmp' behind. The .tmp file is an exact copy of the .ods spreadsheet with which LO was invoked. The CUPS printer manager and logs in /var/log/cups do not show a job corresponding to my attempt to print and I have no problem printing via other apps such as Firefox. I do not believe this is a CUPS issue. I believe this behavior to have begun after my most recent package update which seems to have pulled in a new version of the libreoffice binary relative to the original Ubuntu 12.04 installation. The behavior is highly sensitive to the contents of the spreadsheet. I have attached the offending document and it repeatably demonstrates the print/page preview problem described. However, if the final sheet (Sheet10) of the document is deleted, the problem goes away and print/page preview function properly once again. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: libreoffice-calc 1:3.5.4-0ubuntu1.1 ProcVersionSignature: Ubuntu 3.2.0-32.51-generic-pae 3.2.30 Uname: Linux 3.2.0-32-generic-pae i686 ApportVersion: 2.0.1-0ubuntu14 Architecture: i386 Date: Sat Oct 13 17:51:40 2012 InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Release i386 (20120423) ProcEnviron: TERM=xterm PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/tcsh SourcePackage: libreoffice UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/1066423/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1054923] Re: Window raises on click even if set not to raise in window manager settings (in Xfce)
This appears to be related to the Chromium codebase bug http://code.google.com/p/chromium/issues/detail?can=2q=87103colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20Modifiedid=87103 ** Bug watch added: code.google.com/p/chromium/issues #87103 http://code.google.com/p/chromium/issues/detail?id=87103 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1054923 Title: Window raises on click even if set not to raise in window manager settings (in Xfce) Status in “chromium-browser” package in Ubuntu: New Bug description: Steps to reproduce: 1) Disable Raise window when clicking inside application window in Window Manager (xfwm?) settings in Xfce (in Focus tab). 2) Move another window to partly overlap chromium browser window 3) click on the chromium browser window below title bar Result: the window raises Expected result: window should not raise ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: chromium-browser 20.0.1132.47~r144678-0ubuntu0.12.04.1 ProcVersionSignature: Ubuntu 3.2.0-31.50-generic 3.2.28 Uname: Linux 3.2.0-31-generic i686 ApportVersion: 2.0.1-0ubuntu13 Architecture: i386 Date: Sun Sep 23 13:03:55 2012 Desktop-Session: DESKTOP_SESSION = xubuntu XDG_CONFIG_DIRS = /etc/xdg/xdg-xubuntu:/etc/xdg:/etc/xdg XDG_DATA_DIRS = /usr/share/xubuntu:/usr/local/share/:/usr/share/:/usr/share Env: MOZ_PLUGIN_PATH = None LD_LIBRARY_PATH = None InstallationMedia: Xubuntu 11.10 Oneiric Ocelot - Beta i386 (20110901) ProcEnviron: LANGUAGE=en_US:en TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: chromium-browser UpgradeStatus: Upgraded to precise on 2012-09-22 (0 days ago) chromium-default: CHROMIUM_FLAGS= To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1054923/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1000253] Re: Brother HL-1440 printing extra page with PJL codes
I'm guessing by the lack of response to my comments above that there's little prospect of CUPS printing working for me again anytime in the forseeable future. Right now I can only print by actually attaching the printer to a WinXP instance running in VirtualBox, but this is way too annoying and resource-intensive to keep doing. Before I give up and punt to another distro, would anyone care to comment on the feasibility of ripping out the entire 12.10 userspace print stack and replacing with the one from 10.04, which worked perfectly well for me for years? I'm guessing I'll run into dependency hell that will make it practically impossible, but maybe it's not as bad as I'm imagining? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1000253 Title: Brother HL-1440 printing extra page with PJL codes Status in “cups” package in Ubuntu: Fix Released Status in “cups” source package in Precise: Fix Released Bug description: When I send a job to the printer, it often (but not always) has an extra page before my print job with what appears to be PJL codes being printed out as text. It usually looks something like this: JL SET MEDIATYPE-REGULAR @PJL SET SOURCETRAY=AUTO @PJL SET RESOLUTION=300 @PJL SET (the last line may be cut off by the right margin) This behavior started after I switched to Ubuntu 12.04. I am assuming this problem is in the printer driver (or somewhere in the print handling sequence), since it appears when printing from different programs. Release: 12.04 Package version: 1.5.2-9ubuntu1 Per instructions, I am attaching a print job I captured which shows the error. [IMPACT] Users of the Brother HL-1440 (and some other printers) get pages with PJL commands when they print after the upgrade from Lucid LTS or Oneiric to Precise LTS. In Precise the problem was solved by an ugly workaround of blacklisting the usblp kernel module in the first CUPS SRU. This solution breaks printing for other users, those who use proprietary printer drivers with CUPS backends based on the old /dev/usb/lp* device files and also users who send jobs by directly sending data to the /dev/usb/lp* device files. This worked under Lucid LTS. The libusb-based USB backend of CUPS was far from completely implemented. It lacked the ability to communicate uni-directionally with devices which are not able to communicate bi-directionally, refrain from re-attaching the usblp kernel module after printing for some devices, reset the printer after printing the job, ... In the proposed package these adaptations for devices with quirks are done in the USB backend. Especially this backend now works with said Brother printer by built-in exception rules for this model, so that the communication is done uni-directionally and the usblp kernel module will not get re-attached to the printer after printing the job. This makes the printer working without blacklisting the usblp module. So this second SRU is an improved solution. [TESTCASE] Unfortunately, for reproducing this bug one needs the actual printer. Connect a Brother HL-1440 to the USB port of the computer. With stock Precise (without updates) you will not be able to print correctly, you will get the PJL code. After applying the already available updates (including the first SRU for CUPS) you will be able to print, but only because the usblp kernel module is blacklisted. Remove the blacklisting via sudo mv /etc/modprobe.d/blacklist-cups-usblp.conf ~ sudo modprobe usblp and you will get the problem again. After installing the proposed package the kernel module is not blacklisted any more and you will still be able to print. If you are on a Precise with all updates and you have a print queue with an URI containing /dev/usb/lp* you will not be able to print. This worked with stock Precise and works again with the proposed package. You can easily test this with any Ubuntu-supported USB printer: lpadmin -p test -E -v parallel:/dev/usb/lp0 -m PPD file which works with this printer lpadmin -p test -o PageSize=A4 lp- d test ~/.bashrc The printing on this queue works on stock Precise, does not work on Precise with all updates (usblp is blacklisted) and works again with the proposed package. [Regression Potential] The patch looks perhaps more dramatic than it is. This is because several code sections are put into if blocks, indenting all the (unchanged) code lines. This especially happens because now we suppress
[Desktop-packages] [Bug 1000253] Re: Brother HL-1440 printing extra page with PJL codes
I regret to say that the problem did *not* stay away. After rebooting, I get the page with the PJL codes and a bunch of blank pages corresponding to pages of the document that should be printed. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1000253 Title: Brother HL-1440 printing extra page with PJL codes Status in “cups” package in Ubuntu: Fix Released Status in “cups” source package in Precise: Fix Released Bug description: When I send a job to the printer, it often (but not always) has an extra page before my print job with what appears to be PJL codes being printed out as text. It usually looks something like this: JL SET MEDIATYPE-REGULAR @PJL SET SOURCETRAY=AUTO @PJL SET RESOLUTION=300 @PJL SET (the last line may be cut off by the right margin) This behavior started after I switched to Ubuntu 12.04. I am assuming this problem is in the printer driver (or somewhere in the print handling sequence), since it appears when printing from different programs. Release: 12.04 Package version: 1.5.2-9ubuntu1 Per instructions, I am attaching a print job I captured which shows the error. [IMPACT] Users of the Brother HL-1440 (and some other printers) get pages with PJL commands when they print after the upgrade from Lucid LTS or Oneiric to Precise LTS. In Precise the problem was solved by an ugly workaround of blacklisting the usblp kernel module in the first CUPS SRU. This solution breaks printing for other users, those who use proprietary printer drivers with CUPS backends based on the old /dev/usb/lp* device files and also users who send jobs by directly sending data to the /dev/usb/lp* device files. This worked under Lucid LTS. The libusb-based USB backend of CUPS was far from completely implemented. It lacked the ability to communicate uni-directionally with devices which are not able to communicate bi-directionally, refrain from re-attaching the usblp kernel module after printing for some devices, reset the printer after printing the job, ... In the proposed package these adaptations for devices with quirks are done in the USB backend. Especially this backend now works with said Brother printer by built-in exception rules for this model, so that the communication is done uni-directionally and the usblp kernel module will not get re-attached to the printer after printing the job. This makes the printer working without blacklisting the usblp module. So this second SRU is an improved solution. [TESTCASE] Unfortunately, for reproducing this bug one needs the actual printer. Connect a Brother HL-1440 to the USB port of the computer. With stock Precise (without updates) you will not be able to print correctly, you will get the PJL code. After applying the already available updates (including the first SRU for CUPS) you will be able to print, but only because the usblp kernel module is blacklisted. Remove the blacklisting via sudo mv /etc/modprobe.d/blacklist-cups-usblp.conf ~ sudo modprobe usblp and you will get the problem again. After installing the proposed package the kernel module is not blacklisted any more and you will still be able to print. If you are on a Precise with all updates and you have a print queue with an URI containing /dev/usb/lp* you will not be able to print. This worked with stock Precise and works again with the proposed package. You can easily test this with any Ubuntu-supported USB printer: lpadmin -p test -E -v parallel:/dev/usb/lp0 -m PPD file which works with this printer lpadmin -p test -o PageSize=A4 lp- d test ~/.bashrc The printing on this queue works on stock Precise, does not work on Precise with all updates (usblp is blacklisted) and works again with the proposed package. [Regression Potential] The patch looks perhaps more dramatic than it is. This is because several code sections are put into if blocks, indenting all the (unchanged) code lines. This especially happens because now we suppress using the back channel for selected printers (and also printers which claim to be uni-directional only). The code was developed in several steps and uploaded step-by-step to my PPA. There the reporters of the bugs covered by this SRU and some additional bugs (bug 902535, bug 995111) tested it intensively. They did not hit any regressions compared to stock Precise or the first CUPS SRU. The code is also applied to the CUPS package in Quantal and this also did not cause any
[Desktop-packages] [Bug 1000253] Re: Brother HL-1440 printing extra page with PJL codes
And, following up by setting -o usb-unidir-default=true , now the behavior is sporadic - some print jobs give me a cover page with PJL codes and nothing else, some give me the PJL codes followed by blank pages, and some give me my actual print job. The most frustrating aspect is the randomness / lack of reproducibility :-( Again this is with a stock Ubuntu 12.10 install on an HL-1450 printer, printing several ways (direct print of PostScript file, print from PDF reader, print from Firefox). lsusb results: Bus 004 Device 003: ID 04f9:000e Brother Industries, Ltd HL-1450 series Bus 005 Device 002: ID 046d:c52e Logitech, Inc. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1000253 Title: Brother HL-1440 printing extra page with PJL codes Status in “cups” package in Ubuntu: Fix Released Status in “cups” source package in Precise: Fix Released Bug description: When I send a job to the printer, it often (but not always) has an extra page before my print job with what appears to be PJL codes being printed out as text. It usually looks something like this: JL SET MEDIATYPE-REGULAR @PJL SET SOURCETRAY=AUTO @PJL SET RESOLUTION=300 @PJL SET (the last line may be cut off by the right margin) This behavior started after I switched to Ubuntu 12.04. I am assuming this problem is in the printer driver (or somewhere in the print handling sequence), since it appears when printing from different programs. Release: 12.04 Package version: 1.5.2-9ubuntu1 Per instructions, I am attaching a print job I captured which shows the error. [IMPACT] Users of the Brother HL-1440 (and some other printers) get pages with PJL commands when they print after the upgrade from Lucid LTS or Oneiric to Precise LTS. In Precise the problem was solved by an ugly workaround of blacklisting the usblp kernel module in the first CUPS SRU. This solution breaks printing for other users, those who use proprietary printer drivers with CUPS backends based on the old /dev/usb/lp* device files and also users who send jobs by directly sending data to the /dev/usb/lp* device files. This worked under Lucid LTS. The libusb-based USB backend of CUPS was far from completely implemented. It lacked the ability to communicate uni-directionally with devices which are not able to communicate bi-directionally, refrain from re-attaching the usblp kernel module after printing for some devices, reset the printer after printing the job, ... In the proposed package these adaptations for devices with quirks are done in the USB backend. Especially this backend now works with said Brother printer by built-in exception rules for this model, so that the communication is done uni-directionally and the usblp kernel module will not get re-attached to the printer after printing the job. This makes the printer working without blacklisting the usblp module. So this second SRU is an improved solution. [TESTCASE] Unfortunately, for reproducing this bug one needs the actual printer. Connect a Brother HL-1440 to the USB port of the computer. With stock Precise (without updates) you will not be able to print correctly, you will get the PJL code. After applying the already available updates (including the first SRU for CUPS) you will be able to print, but only because the usblp kernel module is blacklisted. Remove the blacklisting via sudo mv /etc/modprobe.d/blacklist-cups-usblp.conf ~ sudo modprobe usblp and you will get the problem again. After installing the proposed package the kernel module is not blacklisted any more and you will still be able to print. If you are on a Precise with all updates and you have a print queue with an URI containing /dev/usb/lp* you will not be able to print. This worked with stock Precise and works again with the proposed package. You can easily test this with any Ubuntu-supported USB printer: lpadmin -p test -E -v parallel:/dev/usb/lp0 -m PPD file which works with this printer lpadmin -p test -o PageSize=A4 lp- d test ~/.bashrc The printing on
[Desktop-packages] [Bug 1000253] Re: Brother HL-1440 printing extra page with PJL codes
FWIW, I just updated to Ubuntu 12.10 and cups 1.6.1-0ubuntu11, and this problem has once again gone away for me - hopefully it will stay gone this time. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1000253 Title: Brother HL-1440 printing extra page with PJL codes Status in “cups” package in Ubuntu: Fix Released Status in “cups” source package in Precise: Fix Released Bug description: When I send a job to the printer, it often (but not always) has an extra page before my print job with what appears to be PJL codes being printed out as text. It usually looks something like this: JL SET MEDIATYPE-REGULAR @PJL SET SOURCETRAY=AUTO @PJL SET RESOLUTION=300 @PJL SET (the last line may be cut off by the right margin) This behavior started after I switched to Ubuntu 12.04. I am assuming this problem is in the printer driver (or somewhere in the print handling sequence), since it appears when printing from different programs. Release: 12.04 Package version: 1.5.2-9ubuntu1 Per instructions, I am attaching a print job I captured which shows the error. [IMPACT] Users of the Brother HL-1440 (and some other printers) get pages with PJL commands when they print after the upgrade from Lucid LTS or Oneiric to Precise LTS. In Precise the problem was solved by an ugly workaround of blacklisting the usblp kernel module in the first CUPS SRU. This solution breaks printing for other users, those who use proprietary printer drivers with CUPS backends based on the old /dev/usb/lp* device files and also users who send jobs by directly sending data to the /dev/usb/lp* device files. This worked under Lucid LTS. The libusb-based USB backend of CUPS was far from completely implemented. It lacked the ability to communicate uni-directionally with devices which are not able to communicate bi-directionally, refrain from re-attaching the usblp kernel module after printing for some devices, reset the printer after printing the job, ... In the proposed package these adaptations for devices with quirks are done in the USB backend. Especially this backend now works with said Brother printer by built-in exception rules for this model, so that the communication is done uni-directionally and the usblp kernel module will not get re-attached to the printer after printing the job. This makes the printer working without blacklisting the usblp module. So this second SRU is an improved solution. [TESTCASE] Unfortunately, for reproducing this bug one needs the actual printer. Connect a Brother HL-1440 to the USB port of the computer. With stock Precise (without updates) you will not be able to print correctly, you will get the PJL code. After applying the already available updates (including the first SRU for CUPS) you will be able to print, but only because the usblp kernel module is blacklisted. Remove the blacklisting via sudo mv /etc/modprobe.d/blacklist-cups-usblp.conf ~ sudo modprobe usblp and you will get the problem again. After installing the proposed package the kernel module is not blacklisted any more and you will still be able to print. If you are on a Precise with all updates and you have a print queue with an URI containing /dev/usb/lp* you will not be able to print. This worked with stock Precise and works again with the proposed package. You can easily test this with any Ubuntu-supported USB printer: lpadmin -p test -E -v parallel:/dev/usb/lp0 -m PPD file which works with this printer lpadmin -p test -o PageSize=A4 lp- d test ~/.bashrc The printing on this queue works on stock Precise, does not work on Precise with all updates (usblp is blacklisted) and works again with the proposed package. [Regression Potential] The patch looks perhaps more dramatic than it is. This is because several code sections are put into if blocks, indenting all the (unchanged) code lines. This especially happens because now we suppress using the back channel for selected printers (and also printers which claim to be uni-directional only). The code was developed in several steps and uploaded step-by-step to my PPA. There the reporters of the bugs covered by this SRU and some additional bugs (bug 902535, bug 995111) tested it intensively. They did not hit any regressions compared to stock Precise or the first CUPS SRU. The code is also applied to the CUPS package in Quantal and this also did not cause any regression bug report yet. I have tested the
[Desktop-packages] [Bug 1066423] Re: Calc can't print, export to PDF, or print preview
I have reported this upstream at https://bugs.freedesktop.org/show_bug.cgi?id=55966 Thanks for the quick triage! ** Bug watch added: freedesktop.org Bugzilla #55966 https://bugs.freedesktop.org/show_bug.cgi?id=55966 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1066423 Title: Calc can't print, export to PDF, or print preview Status in “libreoffice” package in Ubuntu: Triaged Bug description: 1) lsb_release -rd Description: Ubuntu 12.10 Release: 12.10 2) apt-cache policy libreoffice-calc libreoffice-calc: Installed: 1:3.6.2~rc2-0ubuntu3 Candidate: 1:3.6.2~rc2-0ubuntu3 Version table: *** 1:3.6.2~rc2-0ubuntu3 0 500 http://archive.ubuntu.com/ubuntu/ quantal/main i386 Packages 100 /var/lib/dpkg/status 3) What is expected to happen in Calc via a terminal: cd ~/Desktop wget https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1066423/+attachment/3397788/+files/loprob.ods localc --nologo loprob.ods Export to PDF, Print Preview, or print and it does so. 4) What happens when you: + Export to PDF is one gets a pop up noting: LibreOffice 3.6 Error saving the document loprob: Write Error. The file could not be written. + Page Preview it comes up with a blank gray background rather than a preview. Original Report Comments: + print Nothing was printed, but libreoffice displayed the string 'gtk printer' on the xterm console from which it was invoked, and left a directory and file '/tmp/luppt6wq.tmp/luppt6ws.tmp' behind. The .tmp file is an exact copy of the .ods spreadsheet with which LO was invoked. The CUPS printer manager and logs in /var/log/cups do not show a job corresponding to my attempt to print and I have no problem printing via other apps such as Firefox. I do not believe this is a CUPS issue. I believe this behavior to have begun after my most recent package update which seems to have pulled in a new version of the libreoffice binary relative to the original Ubuntu 12.04 installation. The behavior is highly sensitive to the contents of the spreadsheet. I have attached the offending document and it repeatably demonstrates the print/page preview problem described. However, if the final sheet (Sheet10) of the document is deleted, the problem goes away and print/page preview function properly once again. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: libreoffice-calc 1:3.5.4-0ubuntu1.1 ProcVersionSignature: Ubuntu 3.2.0-32.51-generic-pae 3.2.30 Uname: Linux 3.2.0-32-generic-pae i686 ApportVersion: 2.0.1-0ubuntu14 Architecture: i386 Date: Sat Oct 13 17:51:40 2012 InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Release i386 (20120423) ProcEnviron: TERM=xterm PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/tcsh SourcePackage: libreoffice UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1066423/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1066423] [NEW] libreoffice calc 3.5.4.2 can't print or print preview
Public bug reported: What I expected to happen: printing a spreadsheet from Libreoffice Calc would print it. What happened instead: Nothing was printed, but libreoffice displayed the string 'gtk printer' on the xterm console from which it was invoked, and left a directory and file '/tmp/luppt6wq.tmp/luppt6ws.tmp' behind. The .tmp file is an exact copy of the .ods spreadsheet with which LO was invoked. The CUPS printer manager and logs in /var/log/cups do not show a job corresponding to my attempt to print and I have no problem printing via other apps such as Firefox. I do not believe this is a CUPS issue. Attempting to do 'Page Preview' from within LO on the same spreadsheet comes up with a blank gray background rather than a preview. I believe this behavior to have begun after my most recent package update which seems to have pulled in a new version of the libreoffice binary relative to the original Ubuntu 12.04 installation. The behavior is highly sensitive to the contents of the spreadsheet. I have attached the offending document and it repeatably demonstrates the print/page preview problem described. However, if the final sheet (Sheet10) of the document is deleted, the problem goes away and print/page preview function properly once again. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: libreoffice-calc 1:3.5.4-0ubuntu1.1 ProcVersionSignature: Ubuntu 3.2.0-32.51-generic-pae 3.2.30 Uname: Linux 3.2.0-32-generic-pae i686 ApportVersion: 2.0.1-0ubuntu14 Architecture: i386 Date: Sat Oct 13 17:51:40 2012 InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Release i386 (20120423) ProcEnviron: TERM=xterm PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/tcsh SourcePackage: libreoffice UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: libreoffice (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug i386 precise ** Attachment added: Spreadsheet demonstrating print/page preview problem https://bugs.launchpad.net/bugs/1066423/+attachment/3397788/+files/loprob.ods -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/1066423 Title: libreoffice calc 3.5.4.2 can't print or print preview Status in “libreoffice” package in Ubuntu: New Bug description: What I expected to happen: printing a spreadsheet from Libreoffice Calc would print it. What happened instead: Nothing was printed, but libreoffice displayed the string 'gtk printer' on the xterm console from which it was invoked, and left a directory and file '/tmp/luppt6wq.tmp/luppt6ws.tmp' behind. The .tmp file is an exact copy of the .ods spreadsheet with which LO was invoked. The CUPS printer manager and logs in /var/log/cups do not show a job corresponding to my attempt to print and I have no problem printing via other apps such as Firefox. I do not believe this is a CUPS issue. Attempting to do 'Page Preview' from within LO on the same spreadsheet comes up with a blank gray background rather than a preview. I believe this behavior to have begun after my most recent package update which seems to have pulled in a new version of the libreoffice binary relative to the original Ubuntu 12.04 installation. The behavior is highly sensitive to the contents of the spreadsheet. I have attached the offending document and it repeatably demonstrates the print/page preview problem described. However, if the final sheet (Sheet10) of the document is deleted, the problem goes away and print/page preview function properly once again. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: libreoffice-calc 1:3.5.4-0ubuntu1.1 ProcVersionSignature: Ubuntu 3.2.0-32.51-generic-pae 3.2.30 Uname: Linux 3.2.0-32-generic-pae i686 ApportVersion: 2.0.1-0ubuntu14 Architecture: i386 Date: Sat Oct 13 17:51:40 2012 InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Release i386 (20120423) ProcEnviron: TERM=xterm PATH=(custom, user) LANG=en_US.UTF-8 SHELL=/bin/tcsh SourcePackage: libreoffice UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1066423/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1000253] Re: Brother HL-1440 printing extra page with PJL codes
Till @#77: Initially I tried just lpadmin -p queue -o usb-unidir-default=true which did not change anything. Then I applied the full set of commands in comment #59: cancel -a sudo chmod +x /lib/udev/udev-configure-printer lpadmin -p queue -R usb-no-reattach lpadmin -p queue -R usb-unidir mv /etc/modprobe.d/blacklist-cups-usblp.conf ~ sudo rmmod usblp sudo modprobe usblp and at that point I could print successfully. Re lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 002: ID 046d:c040 Logitech, Inc. Corded Tilt-Wheel Mouse Bus 004 Device 004: ID 04f9:000e Brother Industries, Ltd HL-1450 series Bus 005 Device 002: ID 046d:c52e Logitech, Inc. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1000253 Title: Brother HL-1440 printing extra page with PJL codes Status in “cups” package in Ubuntu: Fix Released Status in “cups” source package in Precise: Fix Released Bug description: When I send a job to the printer, it often (but not always) has an extra page before my print job with what appears to be PJL codes being printed out as text. It usually looks something like this: JL SET MEDIATYPE-REGULAR @PJL SET SOURCETRAY=AUTO @PJL SET RESOLUTION=300 @PJL SET (the last line may be cut off by the right margin) This behavior started after I switched to Ubuntu 12.04. I am assuming this problem is in the printer driver (or somewhere in the print handling sequence), since it appears when printing from different programs. Release: 12.04 Package version: 1.5.2-9ubuntu1 Per instructions, I am attaching a print job I captured which shows the error. [IMPACT] Users of the Brother HL-1440 (and some other printers) get pages with PJL commands when they print after the upgrade from Lucid LTS or Oneiric to Precise LTS. In Precise the problem was solved by an ugly workaround of blacklisting the usblp kernel module in the first CUPS SRU. This solution breaks printing for other users, those who use proprietary printer drivers with CUPS backends based on the old /dev/usb/lp* device files and also users who send jobs by directly sending data to the /dev/usb/lp* device files. This worked under Lucid LTS. The libusb-based USB backend of CUPS was far from completely implemented. It lacked the ability to communicate uni-directionally with devices which are not able to communicate bi-directionally, refrain from re-attaching the usblp kernel module after printing for some devices, reset the printer after printing the job, ... In the proposed package these adaptations for devices with quirks are done in the USB backend. Especially this backend now works with said Brother printer by built-in exception rules for this model, so that the communication is done uni-directionally and the usblp kernel module will not get re-attached to the printer after printing the job. This makes the printer working without blacklisting the usblp module. So this second SRU is an improved solution. [TESTCASE] Unfortunately, for reproducing this bug one needs the actual printer. Connect a Brother HL-1440 to the USB port of the computer. With stock Precise (without updates) you will not be able to print correctly, you will get the PJL code. After applying the already available updates (including the first SRU for CUPS) you will be able to print, but only because the usblp kernel module is blacklisted. Remove the blacklisting via sudo mv /etc/modprobe.d/blacklist-cups-usblp.conf ~ sudo modprobe usblp and you will get the problem again. After installing the proposed package the kernel module is not blacklisted any more and you will still be able to print. If you are on a Precise with all updates and you have a print queue with an URI containing /dev/usb/lp* you will not be able to print. This worked with stock Precise and works again with the proposed package. You can easily test this with any Ubuntu-supported USB printer: lpadmin -p test -E -v parallel:/dev/usb/lp0 -m PPD file which works with this printer lpadmin -p test -o PageSize=A4 lp- d test ~/.bashrc The printing on this queue
[Desktop-packages] [Bug 1000253] Re: Brother HL-1440 printing extra page with PJL codes
I regret to say that after a recent package update, this problem reappeared for me. I have the cups 1.5.3-0ubuntu4 package installed. Applying the patches in comment #59 does work around the problem however. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1000253 Title: Brother HL-1440 printing extra page with PJL codes Status in “cups” package in Ubuntu: Fix Released Status in “cups” source package in Precise: Fix Released Bug description: When I send a job to the printer, it often (but not always) has an extra page before my print job with what appears to be PJL codes being printed out as text. It usually looks something like this: JL SET MEDIATYPE-REGULAR @PJL SET SOURCETRAY=AUTO @PJL SET RESOLUTION=300 @PJL SET (the last line may be cut off by the right margin) This behavior started after I switched to Ubuntu 12.04. I am assuming this problem is in the printer driver (or somewhere in the print handling sequence), since it appears when printing from different programs. Release: 12.04 Package version: 1.5.2-9ubuntu1 Per instructions, I am attaching a print job I captured which shows the error. [IMPACT] Users of the Brother HL-1440 (and some other printers) get pages with PJL commands when they print after the upgrade from Lucid LTS or Oneiric to Precise LTS. In Precise the problem was solved by an ugly workaround of blacklisting the usblp kernel module in the first CUPS SRU. This solution breaks printing for other users, those who use proprietary printer drivers with CUPS backends based on the old /dev/usb/lp* device files and also users who send jobs by directly sending data to the /dev/usb/lp* device files. This worked under Lucid LTS. The libusb-based USB backend of CUPS was far from completely implemented. It lacked the ability to communicate uni-directionally with devices which are not able to communicate bi-directionally, refrain from re-attaching the usblp kernel module after printing for some devices, reset the printer after printing the job, ... In the proposed package these adaptations for devices with quirks are done in the USB backend. Especially this backend now works with said Brother printer by built-in exception rules for this model, so that the communication is done uni-directionally and the usblp kernel module will not get re-attached to the printer after printing the job. This makes the printer working without blacklisting the usblp module. So this second SRU is an improved solution. [TESTCASE] Unfortunately, for reproducing this bug one needs the actual printer. Connect a Brother HL-1440 to the USB port of the computer. With stock Precise (without updates) you will not be able to print correctly, you will get the PJL code. After applying the already available updates (including the first SRU for CUPS) you will be able to print, but only because the usblp kernel module is blacklisted. Remove the blacklisting via sudo mv /etc/modprobe.d/blacklist-cups-usblp.conf ~ sudo modprobe usblp and you will get the problem again. After installing the proposed package the kernel module is not blacklisted any more and you will still be able to print. If you are on a Precise with all updates and you have a print queue with an URI containing /dev/usb/lp* you will not be able to print. This worked with stock Precise and works again with the proposed package. You can easily test this with any Ubuntu-supported USB printer: lpadmin -p test -E -v parallel:/dev/usb/lp0 -m PPD file which works with this printer lpadmin -p test -o PageSize=A4 lp- d test ~/.bashrc The printing on this queue works on stock Precise, does not work on Precise with all updates (usblp is blacklisted) and works again with the proposed package. [Regression Potential] The patch looks perhaps more dramatic than it is. This is because several code sections are put into if blocks, indenting all the (unchanged) code lines. This especially happens because now we suppress using the back channel for selected printers (and also printers which claim to be uni-directional only). The code was developed in several steps and uploaded step-by-step to my PPA. There the reporters of the bugs covered by this SRU and some additional bugs (bug 902535, bug 995111) tested it intensively. They did not hit any regressions compared to stock Precise or the first CUPS SRU. The code is also applied to the CUPS package in Quantal and this also did not
