324635 - Firefox 1.5 PostScript printing will not work (no output)

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Jason Keltz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050721 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050721 Firefox/1.0.6

With FireFox 1.0.6, printing worked fine.  With FireFox 1.5, printing does not work at all.  That is, any file I print results in no output at the printer.

After speaking with the printer vendor, they explained the problem.  The vendors print filter sets "/DeferredMediaSelection true" on all jobs.  This will ensure that the printer requests confirmation of paper size mismatches on the printer control panel.  PostScript also supports another option (setpagedevice PageSize) for setting a recovery policy.  The printer vendors software sets this to 2 (prompt user).   FireFox 1.5 now adds a "setpagedevice PageSize 3" as a recovery policy.  As far as I understand it, "PageSize 3" means to print out paper with the nearest size.

     <Excerpt from PostScript Reference>
     According to the Adobe PostScript specification, If
DeferredMediaSelection is true, policies 3 and 4 may result in a
     configuration error, since the needed adjustments to the current
transformation matrix cannot be deferred ( ref. PostScript
     language reference third edition : 6.2.7 Unsatisfied Parameter
Request, Table 6.9 ).

Sure enough, if you look at the difference in the PostScript output between 1.06 and 1.5 you see the differences:

1.06:
%%BeginProlog
/setpagedevice where
{ pop 1 dict
  dup /PageSize [ 612 792 ] put
  setpagedevice
} if


1.5:
%%BeginProlog
/setpagedevice where
{ pop 2 dict
  dup /PageSize [ 612 792 ] put
  dup /Policies 1 dict
    dup /PageSize 3 put
  put
  setpagedevice
} if


-----

I don't think that the web browser should be setting this behaviour at all.  This sounds like behaviour that should be set by the printer driver/filter as
requested by the user.




They also set "PageSize 2"

Reproducible: Always

Steps to Reproduce:
1. Print any file - it won't print.
2.
3.

Comment 1

[Kenneth Herron]

Leon, any chance you could look at this?

Comment 2

[Philip Withnall (unavailable)]

Just for reference, what is the vendor and make of your printer?

Comment 3

[Jason Keltz]

Ricoh AP4510.

(By the way, when I revert the couple of lines of code that changed in 1.5 PostScript code to the 1.0.6 code, printing works, although I miss the header at the very top of the page that displays in a PostScript viewer.  Nonetheless, this header doesn't even print on any of our HP printers either using the original 1.5 code, so I guess that's a different problem)

Comment 4

[Leon Sha]

(In reply to comment #1)
> Leon, any chance you could look at this?
>

Sorry for the later reply.
So can we do not set /PageSize 3 when /DeferredMediaSelection is true?

Comment 5

[Leon Sha]

(In reply to comment #1)
> Leon, any chance you could look at this?
> 

I have tried print a page using xerox N2825 without the following three lines.
----------------------------
  dup /Policies 1 dict
    dup /PageSize 3 put
  put
----------------------------
When I use the driver provide by xerox, there will be no problem.
While I was using Generic/Postscript driver, there will be bug 283437.

There may be two solution for this bug.
1. Remove the three lines, let driver/filter/system to handle pagesize problem.
2. Add handler for DeferredMediaSelection.

So KH, what is your opnion?
For me I prefer the first solution. As Jason said, this job should be done by driver/filter. But also, it is a pitty that Generic/Postscript driver didn't handle this page size problem.

Comment 6

[jsmeix]

I urgently recommend to do 1. (i.e. remove any printer-specific stuff
and let driver/filter/system handle it).


The following bug report in CUPS led me to this report.
http://www.cups.org/str.php?L1542
-------------------------------------------------------------------------
Mozilla's output also contains a setpagedevice command without
a corresponding Begin/EndFeature pair, which might cause problems
with some printers...
Please file a bug upstream with them to add:
  %%BeginFeature: *PageSize sizename
  ... existing code
  %%EndFeature: *PageSize
"sizename" would be "Letter", "A4", etc.
-------------------------------------------------------------------------
This means that it is not DSC compliant at the moment.
For details about DSC see the Adobe "PostScript Language
Document Structuring Conventions Specification".

When PostScript is not full DSC compliant it leads to arbitrary problems
with PostScript processing tools because such tools don't understand
the meaning of the PostScript code but process it by parsing it according
to the DSC comments.
Note that the CUPS pstops filter which is involved to print anything
is such a tool.

Examples:

It may fail to extract special pages to print only these pages.

It may fail to do number-up printing (e.g. two pages on one sheet)
because it must remove printer specific settings so that multiple
rotated/translated/scaled-down pages will be printed correctly
on one sheet (in particular on a PostScript printer).

For more details about the problem (here caused by OOo) see
https://bugzilla.novell.com/show_bug.cgi?id=80448
http://www.cups.org/str.php?L576
http://www.cups.org/str.php?L1161



Some general comments regarding any kind of printer specific stuff
in the PostScript output of any application program:

What most desktop users recognize as the "printing mess"
are 99% problems only in the applications.
(Of course business print system admins recognize several problems
 in the printing system but their problems are mostly not of much
 importance for desktop users.)

The biggest problem in the applications is that they don't
produce clean PostScript. With "clean PostScript" I mean
- printer independent PostScript
- scalable/rotatable/translatable PostScript
- DSC conforming PostScript
- by default only up to PostScript level 2
  special fonts (e.g. CJK) may require level 3 but even this
  would be possible (but complicated) even with level 1.

An application can
either
produce 100% ready-to-print printer specific data
and then it must be printed in "raw" mode to avoid that the
CUPS filtering system tries to filter the printer specific
data again (i.e. print like in "lp -d QUEUE -o raw file.prn")
or
it must produce 100% printer-independent generic data
(e.g. 100% printer-independent generic PostScript)
and then let the CUPS filtering system produce the printer
specific data from it.

The second problem in the applications is that they create
whatever nice looking document but they don't care about the
actual values for a particular printer:
- the paper size for which the document is made is not used
  on the printer (e.g. document is A4 but printer has Letter)
- the imaged area in the document is bigger than the imageable
  area of the printer

The print engines in the applications should ask the CUPS
printing system for the actual defaults of the queue to which
the user actually wants to print because this is the only way
which results the real facts and which matches to the printer
to which the printout should be actually sent.
As long as the applications ignore CUPS and make the printout
on their built-in assumptions the mess will never end.

Regarding the default media size values:
If an application cannot or does not want to be linked with CUPS,
the application can use the locale setting of the user who runs it
(in particular the "teritory" part of the locale) to determine
a reasonable default/fallback media size (usually A4 or Letter)
and if even this fails (or is not possible) it should use A4 as
fallback paper size because A4 is more often used on the whole
world than Letter.
In this case the imageable area must be fail-safe which means
there must be big unprinted margins (i.e. a small imaged area)
so that nothing is clipped on any printer (in particular older
inkjet printers cannot print the last 2cm at the bottom of the
sheet).

Comment 7

[Wolfgang Rosenauer [:wolfiR]]

So how about removing the whole setpagedevice command completely.
What feature would be lost in that case?

Comment 8

[jsmeix]

If any setpagedevice stuff was removed in any case,
no printer-specific stuff could be done if there is
no CUPS system available.

I.e. for old-stlye printing systems which do not offer support
for printer specific settings, it may be useful to offer printer
specific settings (at least only for PostScript printers)
directly in the application.

But if CUPS is used, printer specific settings in the PostScript
output of an application normally doesn't make sense - remember
the "either ... or" in my previous comment - for example for CAD
programs it makes sense to let them produce 100% printer (plotter)
specific output but a browser is no CAD program ;-)

Comment 9

[Kenneth Herron]

Leon, you submitted the original bug that added the PageSize policy. If you're comfortable with just removing the code again, that's fine with me.

As an alternative, We could add a pref to let the user specify a pagesize policy on a printer-by-printer basis, but I don't know if there's any real demand for the feature.

(In reply to comment #7)
> So how about removing the whole setpagedevice command completely.
> What feature would be lost in that case?

The block of code in question was originally added for bug 172525 to help the printer choose the right size paper for the job.

Comment 10

[Wolfgang Rosenauer [:wolfiR]]

(In reply to comment #6)
> Mozilla's output also contains a setpagedevice command without
> a corresponding Begin/EndFeature pair, which might cause problems
> with some printers...
> Please file a bug upstream with them to add:
>   %%BeginFeature: *PageSize sizename
>   ... existing code
>   %%EndFeature: *PageSize
> "sizename" would be "Letter", "A4", etc.

You could/should add this when you are on it.

Comment 11

[Leon Sha]

Attachment: Patch

Comment 12

[Leon Sha]

Comment on attachment 220112 [details] [diff] [review]
Patch

I'll mark bug 283437 as invalid if we fixed this bug.

Comment 13

[Wolfgang Rosenauer [:wolfiR]]

Comment on attachment 220112 [details] [diff] [review]
Patch

>+    "%%%%EndFeature: *PageSize\n",
>+    mPrintSetup->paper_name,

Thanks, but there is a bug in the CUPS bugtracking system.
The EndFeature must not contain the option again I've been told meanwhile.

So 
"%%%%EndFeature\n",
should be correct.

Comment 14

[Leon Sha]

Attachment: patch v2

Comment 15

[Kenneth Herron]

Comment on attachment 220114 [details] [diff] [review]
patch v2

This looks fine. Thanks, Leon.

Comment 16

[Leon Sha]

Checking in nsPostScriptObj.cpp;
/cvsroot/mozilla/gfx/src/ps/nsPostScriptObj.cpp,v  <--  nsPostScriptObj.cpp
new revision: 1.128; previous revision: 1.127
done