Created attachment 15442 [details]
This patch should solve the problem.

cp->pmladek: please print to file an example document that shows the offending
behaviour. Emptying the list is not an option as it disables the options
provided by the PPD.

Unless you changed the resolution settings for a printer with spadmin, the
resolution command will not be part of the PostScript output of OOo, since the
resolution does not deviate from the default value.

Even if one of the device dependent commands cannot be executed by the
PostScript interpreter, it should ignore this as all PPD features are surrounded by

[{
} stopped cleartomark

which is supposed to make the interpreter forget the offending code if an error
occured.

If the generic PPD does not work for a printer i can only recommend using one
that fits. Simply making the generic PPD do nothing at all will break all
printers that actually can use these standard commands.

The main problem is that until OOo uses CUPS - which went into the 2.0 tree -
there simply is no way to get the right PPD for a printer. 

IMHO that leaves nothing to do for now.

> Unless you changed the resolution settings for a printer with spadmin, the
> resolution command will not be part of the PostScript output of OOo, since the
> resolution does not deviate from the default value.

Ha, this is the reason why I was not able to create an example postscript.

Unfortunately, I am not an expert in the printing stuff. I pasted only the
messages I got from our colleague who is not a registered user on
http://www.openoffice.org. I'll contact him. He would comment it better than me.

The crucial point is what Petr and Till and I explained:
OOo must not produce printer model specific PostScript code by default.
By default OOo must produce printer model independent PostScript code.

No application should produce printer specific data by default.
By default it is only the printing system which converts printer
model independent PostScript code into printer specific data.

Even if OOo uses CUPS library calls to receive the printer model
specific PPD file from the CUPS system OOo must not produce printer
model specific PostScript by default.
All what OOo should do by default in this case is:
* Read the *DefaultPageSize entry and then the matching *PaperDimension
  and *ImageableArea values to determine whether or not the content
  of a page fits in the imageable area.
  If the content of a page is bigger than the imageable area
  a popup may appear which lets the user choose to scale or to clip.
* Read the *DefaultResolution value to learn about the printer's
  default resolution and use this resolution by default for images
  which are produced by OOo.
  But this would lead to a new problem when the printer's default
  resolution is very high (e.g. *DefaultResolution: 2400dpi)
  because then the image may need more memory (RAM and swap)
  than there is available in the computer (not in the printer because
  a printer with default resolution 2400dpi has sufficient memory).
  To avoid this problem it may be better to use the *DefaultResolution
  entry and the *Resolution entries (if exist) to determine as default
  image rendering resolution one of the reasonable resolutions 300dpi,
  360dpi, 600dpi, 720dpi which fits best to the printer model (of course
  the user may choose another image rendering resolution).
  In contrast for images which are imported by the user
  OOo should leave the original image resolution and use PostScript
  translate and scale functions to place and scale an imported image.

The problem exists since a long time, therefore it is not urgent now.
Please take some time and read also the mails on LinuxPrinting.org.
Perhaps it is sufficient to save manpower and leave it as it is for
OOo version 1.x and solve the whole stuff only for OOo version 2.x?

"No application should produce printer specific data by default."

That's obviously a matter of opinion. By letting all printer specific commands
be done by the spooler you simply cut off all kinds of features. E.g. it is
suddenly not possible anymore to print in different paper formats within the
same document; it is impossible to select different paper trays for different
pages, ...

Most spoolers simply put a PostScript stream before the print job (think lpd or
SystemV print wheel). This automatically kills the possibility for the device
specific commands to change during the document which is simply unacceptable.

Regarding:
----------------------------------------------------------------
Even if one of the device dependent commands cannot be executed
by the PostScript interpreter ...
----------------------------------------------------------------

The problem is that the device dependent commands can be executed
by the PostScript interpreter (which is often Ghostscript) and
this leads to errors - please read the mails on LinuxPrinting.org.


Regarding:
---------------------------------------------------------------------
If the generic PPD does not work for a printer i can only recommend
using one that fits. Simply making the generic PPD do nothing at all
will break all printers that actually can use these standard commands.
---------------------------------------------------------------------

There are two misunderstandings:

1.
By default no printer specific stuff is to be set up in an application.
The application must use the existing queues of the printing system
with the existing fitering.

The printing system must have the PPD files but not the application.
How should OOo work perfectly for thousands of printer models?
Should OOo provide for each model a PPD or should a user in the
network get the PPD for each remote printer and install it into
her local OOo?
No.
The solution is the next item:

2.
By default the application is not responsible for printer specific stuff.
By default the printing system is responsible for this.
By default the application is responsible to produce printer independent
PostScript code so that the printing system can print it on
any of the available printers.

Since ever it was possible to move a print job from one queue
to another queue (for example CUPS has the "lpmove" command).
How should this work when the print job contains printer specific dats?
Only in very special cases the application may produce printer specific
data (e.g. Gimp for optimum results when printing images or CAD programs
may produce plotter specific HPGL code if there is no PostScript plotter).

Note my previous entry: I always wrote "by default".
Of course on special request the user can set whatever she likes and
let the application produce printer specific data (even Gimp produces
plain PostScript by default) but then the user knows that it is printer
specific and then the application must use the CUPS option "-o raw" to
tell the printing system not to filter the data but send it directly
to the printer.

Obviously it causes errors when an application produces printer
specific PostScript code and then it lets the printing system filter
this as if it was normal printer independent PostScript code.

"Simply making the generic PPD do nothing at all" is the solution
simply because "generic" is the opposite of "printer specific". 

"Read the mails on LinuxPrinting.org" - could you be a bit more specific ?
Reading all those mailing list archives there would take weeks.

Then you say, the user should NOT install the correct PPD for his printer -
that's wrong, he really, really should. If the printer is not the network, so
much the better, then the system administrator can do that centrally in the OOo
installation. The duplication was necessary up to now since usually NO ONE had
the correct PPD, not even the spooler since we only supported old lpd and
friends. With CUPS the user will not have to install a PPD since CUPS already
has the PPD.

You mention moving a print job to another queue which seems impossible to you if
there is device dependent code in the PostScript file. But actually the spooler
should simply do as Adobe itself suggests in the DSC spec: it should replace the
*Feature sections by those of the correct feature for the printer it moves the
job to.

You say: "By default the application is not responsible for printer specific stuff."
Please read my last comment: if the application wants to change paper size or
whatever during the document, then yes OF COURSE it needs to get this
information to the printer somehow. Since there is absolutely no way even with
CUPS to do this via the spooler, there is absolutely no way around putting the
device dependent code into the PostScript.

There is no need to SHOUT.

I meant those mails on LinuxPrintng.org for which there are
links in pmladek's initial comment.
Please note that those mails are a bit old and that therefore
the problem may no longer be the same - see (*) below - but we
didn't notice the change because we used a generic PPD without
any PostScript invocation values.

Again:
Please note the difference between what is done by default and
what the user can choose on special request - see what I wrote:
--------------------------------------------------------------------
Note my previous entry: I always wrote "by default".
Of course on special request the user can set whatever she likes and
let the application produce printer specific data
--------------------------------------------------------------------

Of course when the user needs special features like switching
paper size or paper tray within one print job then she can enable
any printer specific settings she needs (and then she must configure
OOo to use a printer specific PPD file), but this is neither the
default way to print nor is it a generic way to print.


You wrote:
------------------------------------------------------------------------
Unless you changed the resolution settings for a printer with spadmin,
the resolution command will not be part of the PostScript output of OOo,
since the resolution does not deviate from the default value.
------------------------------------------------------------------------
(*)
Only with spadmin or even for daily usage?
I.e. does this mean that OOo doesn't produce any printer specific
PostScript code if the user leaves the defaults in OOo's PPD as is?
But if the user selects any other value (e.g. "Letter" instead of "A4")
then OOo would produce printer specific PostScript code?

No need to SHOUT: actually i intended *of course* but wrote OF COURSE instead, sorry

I also read that mail again, but i still think it is not relevant to our case
here: first, OOo does not use CUPS at all; this is a new feature to go into OOo
2.0; second it seems to be about OOo 1.0.1,  which is severely outdated ;-).

Concerning your Letter/A4 question: no PPD feature that does not differ from the
default ever gets put out by OOo. In the case of A4 usually a command is output
because the default is Letter in most PPD files.

The problem the default of no device dependent commands as i see it is this
(i'll use PageSize as example here as it is the most commonly used feature):
- user loads document
- document is in (say) Tabloid
- in your model OOo will output as if Tabloid was present, but actually will not
tell the printer what is intended.
- PostScript is printed, but the printer never knew to print on Tabloid paper
- the user gets crap

Please keep in mind, that up to OOo1.1 we deal with lpr and similar commands
only. Usually there is not even a PostScript prolog configured that would
configure any device feature at all. If OOo does not tell the printer what paper
to use, then no one does it.

This changes somewhat when CUPS comes into play; in a way it is worse. CUPS
would tell the printer to use A4 explicitly and if OOo does not output device
dependent PostScript the user wouldn't get his tabloid at all unless he fiddled
with the CUPS system to set the default to tabloid. You will say now, that we
can set the paper with CUPS API, but then again, we cannot change the format or
any other feature later on.

Thanks a lot for the explanation.
In particular "OOo does not use CUPS at all; this is a new feature
to go into OOo 2.0" makes it obvious that the whole problem is only
because at the moment OOo is focused on a traditional printing system
but actually most Linux distributions use CUPS.
Therefore there must be some inconsistencies.
Perhaps our workaround to remove the PostScript invocation values from
OOos generic PPD is not too bad. Of course it disables any printer
specific feature in OOo but on the other hand it avoids some problems
and I think for our default users who print from OOo via "kprinter"
less problems are better than more features.

As I wrote:
I think it is best to save manpower and leave it as it is for
OOo version 1.x and solve the whole stuff only for OOo version 2.x

A longer time ago (in March 2003) I sent some very long mails with
my thoughts regarding printing from OOo with PPD to Michael T. Dean.
If you are interested I could make an attachment to this issue.

If we're talking really just about resolution, then there is no problem at all;
setting the resolution is not really useful anyway on "Generic PostScript". In
fact i could live with removing the Resolution feature once and for all in the
SGENPRT PPD as this would default to 300dpi for OOo.

But i wouldn't want to remove all device dependent code per se, which is what i
understood you wanted.

Please attach your mails if you want to; if there are any issues regarding
printing in OOo i am always interested.

removing resolution entry in CWS vclppbugs4

fixed in CWS vclppbugs4

verified

fix is in 645m46, closing