Hello, On Aug 5 15:50 Ulrich Leopold wrote (shortened):
The problem seems to be the PageMedia in the postscript files sent to the printer. When the postscript files contain A4 everything seems to be fine. But when they contain "regular" or "plain" which should be also A4 formats then teh printer does not print. It seems to happen when I either print first to file or when certain applications are used ...
It seems you have a PostScript printer and the printer has A4 paper and therefore it doesn't print when in the PostScript files a different media type is set. Either configure the printer (see the printer's manual) to automatically fall back to use the A4 paper if an unmatching media type is set in the PostScript or make sure that those "certain applications" produce correct PostScript. Correct PostScript means: Either the application produces readymade printer specific PostScript which must be printed in "raw" mode (lp -o raw ...) or the application produces generic printer independent PostScript and let the CUPS system add the printer specific PostScript snippets via the CUPS pstops filter and the PPD file, see http://portal.suse.com/sdb/en/2004/05/jsmeix_print-cups-in-a-nutshell.html "What is a PPD file and how does it work?" OpenOffice.org and StarOffice are well known applications which don't produce generic printer independent PostScript but which produce somewhat printer specific PostScript which is not specific for the actual printer but which contains somewhat generic printer specific PostScript snippets from OOo's SGENPRT.PS PPD file. Such somewhat printer specific PostScript can cause any weird effects when it is printed on a real PostScript printer. I found perhaps a workaround how to get OOo's PostScript printer independent and hopefully sufficiently DSC conform: 1. OOo inserts printer specific PostScript snippets from its own PPD files (like /opt/OpenOffice.org/share/psprint/driver/SGENPRT.PS or /usr/lib/ooo-2.0/share/psprint/driver/SGENPRT.PS) but it shouldn't do this because it should produce printer independent PostScript code and leave the printer specific stuff to the printing system. 2. OOo inserts its printer specific PostScript snippets in a non DSC conformant way which results that PostScript processing tools (like the pstops filter of the printing system) fail or don't work as the user expects it (e.g. N-Up printing may leave the first page blank). 1.&2. => Simply remove OOo's printer specific PostScript snippets. According to what I have seen up to now, OOo has its printer specific PostScript snippets in a %%BeginPageSetup...%%EndPageSetup section. You should verify this for various OOo (and StarOffice) PostScript output by printing into a PostScript file and using for example: sed -n -e '/%%BeginPageSetup/,/%%EndPageSetup/p' file.ps Any %%BeginFeature...%%EndFeature stuff should appear in a %%BeginPageSetup...%%EndPageSetup section. This %%BeginFeature...%%EndFeature stuff is OOo's printer specific PostScript snippets. Therefore my workaround is print into a file.ps and do sed -i -e '/%%BeginPageSetup/,/%%EndPageSetup/d' file.ps and then print file.ps via lp command (without -o raw). This removes all %%BeginPageSetup...%%EndPageSetup sections completely (including the DSC comments) but I hope it is at least sufficiently DSC conform. For me for example N-Up printing works this way but I did only a few tests. I don't know whether or not it causes unwanted side-effects. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsmeix@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/