Apache OpenOffice (AOO) Bugzilla – Issue 62535
Default printer not working
Last modified: 2006-02-25 13:05:23 UTC
In OOo 2.0.2 m4 sk, if attempted to print, an error appears "No default printer found. Please select printer and start again". If I select the default printer manually, the OK button activates itself, however if I press it, nothing happens. Printing to networked printers work, AFAI have tryed. The OOo 2.0.0 prints well, this is a new issue.
I cn confirm this with m4 under Debian If I want to change Properties, OOo crashed so I changed to P1
set keyword: regression
Not P1! I've just installed a new m4 in linux and in short, I do not confirm. Please provide more details about your system and installation.
It must be at least P2 because it's a release stopper. It's unpossible to print a text document with the printer you configure especially in 2.0.1. if I want to configure a new printer with ./spadmin I get the following error message: ./spadmin: line 233: 14687 Speicherzugriffsfehler "$sd_prog/$sd_binary" "$@" This error isn' in 2.0.1 and not in RC1 of 2.0.2 My system is Debian Sarge with the OOo build of Pavel OOB680_m4
@hi now I see on our German dev list (dev@de.openoffice.org) that this bug was also in RC2 of 2.0.2.
this seems to be related to pavel's builds only. Fresh install of Sun's RC3-> printing is ok for me Fresh install of pavel's RC4 -> printing fails as described
I think this is because OOo is trying to read SGENPRT.PS from share/psprint/driver/... This is with current configure based builds: pid 6963] lstat64("/SGENPRT", <unfinished ...> [pid 6963] open("/SGENPRT", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 6963] lstat64("/SGENPRT", 0xbfffc040) = -1 ENOENT (No such file or directory) [pid 6963] open("/SGENPRT", O_RDONLY) = -1 ENOENT (No such file or directory) This is with added driver directory from previous versions: [pid 7019] lstat64("/SGENPRT", <unfinished ...> [pid 7019] open("/SGENPRT", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 7019] lstat64("/disk3/oo/TEST/program/../share/psprint/driver/SGENPRT.PS", {st_mode=S_IFREG|0644, st_size=24364, ...}) = 0 [pid 7019] open("/disk3/oo/TEST/program/../share/psprint/driver/SGENPRT.PS", O_RDONLY) = 24 [pid 7019] lstat64("/disk3/oo/TEST/program/../share/psprint/driver/SGENPRT.PS", {st_mode=S_IFREG|0644, st_size=24364, ...}) = 0 [pid 7019] open("/disk3/oo/TEST/program/../share/psprint/driver/SGENPRT.PS", O_RDONLY) = 24 [pid 7019] lstat64("/SGENPRT", 0xbfffce7c) = -1 ENOENT (No such file or directory) [pid 7019] open("/SGENPRT", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 7019] lstat64("/disk3/oo/TEST/program/../share/psprint/driver/SGENPRT.PS", {st_mode=S_IFREG|0644, st_size=24364, ...}) = 0 [pid 7019] open("/disk3/oo/TEST/program/../share/psprint/driver/SGENPRT.PS", O_RDONLY) = 25 Q1: why is it reading /SGENPRT? Any configure based build doesn't contain psprint/driver and psprint/fontmetric directory, thus can't print. Looks like this is duplicate to #i62068#. Right?
Caolan: someon on IRC told me you had the same problem.
Confirmed too in rc4, Pavel's build-1. System: SuSE 10.0, CUPS with commercial turboprint.de driver, networked Canon S750 printer over LPR server (a soapbox from Asus). After copying ../psprint/driver/ from older installation into ~/.openoffice.org2/user/psprint/ printing started work.
tuharsky: Peter, please download this: http://tmp.janik.cz/OpenOffice.org/psprint.tar.gz put it into share/psprint and try again please. Is it better now?
Similar problem in GNU/Linux sparc build m157. Works correctly after putting files into share/psprint from http://tmp.janik.cz/OpenOffice.org/psprint.tar.gz
Yup, I have it too after I built. Looks simply to be config_office issue 62068. without-afms and without-ppds are effectively enabled by default, which is a nice feature I'd like to use in the future :-) except that the minimal SGENPRT.PS is the default OOo printer so should still be included with or without-ppd, and the defaults should should be the same behavour as internal builds like pavel says of course :-)
Yes, this is duplicate or reopened #i62068#. *** This issue has been marked as a duplicate of 62068 ***
Closing duplicate