Closed Bug 154027 Opened 22 years ago Closed 20 years ago

[ps] Support Postscript level 1 printers

Categories

(Core :: Printing: Output, enhancement, P1)

Product:
Core
Component:
Printing: Output
Platform:
x86
Linux
Type:
enhancement

Tracking

()

Status:
RESOLVED DUPLICATE of bug 182324
Milestone:
mozilla1.3alpha

People

(Reporter: nbi, Unassigned)

References

Details

Attachments

(1 file)

A page which won't print
112.54 KB, application/postscript
Details 
The postscript produced by selecting print (for example, pick any job ad on
www.monster.com) in Mozilla 1.0 is substantially different from the postscript
produced by older browsers such as Netscape 4.79. Although viewable via
ghostscript/gv the Mozilla 1.0 postscript does not print on my Oki OL-840+ Level
1 Postscript printer although the Netscape 4.79 produced postscript does. There
are no options in Mozilla that I'm aware of that set a Postscript compatibility
mode, in fact I can't even find a full blown printer setup.
*** Bug 154028 has been marked as a duplicate of this bug. ***
Reporter:
Which print module do you use - PostScript (default) or Xprint ?
I printed in the normal manner, by selecting 'file' then 'print'.
"Postscript/default" is the only printer choice given. I don't know what the
Xprint or Postscript "modules" are. As an end user should I need to?
nbi@xnet.com wrote:
> I printed in the normal manner, by selecting 'file' then 'print'.
> "Postscript/default" is the only printer choice given. I don't know what the
> Xprint or Postscript "modules" are.

See http://xprint.mozdev.org/ or
http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/

> As an end user should I need to?

Well, if you have this kind of problem or want to print non-ISO-Latin1 and/or
MathML then the Xprint module offers a working alternative... see
http://mozilla.org/releases/mozilla1.0/#printing
Summary: 'print' produces un-printable postscript → [ps] 'print' produces un-printable postscript
This is totally unacceptable. Something that was working in previous browsers
has been broken during the development of Mozilla. The right thing to do is to
fix it where it is broken, in Mozilla, not to try to mask it via an addon such
as Xprint (which may not solve the problem anyway). It is unreasonable to
suggest that people spend time with Xprint which according to its documentation
isn't a mature and stable application yet. What happens when I discover that
Xprint is incompatible with my working LPRng printing system? Are you going to
tell me that I should purchase a new laser printer? I'm not trying to print
anything unusual or exotic. I don't need Xprint for printing from Netscape 4.79
so why should I need it for Mozilla?

I don't know how the postscript is being generated, but it seems that someone
ought to know how Netscape 4.79 is generating it correctly. Given that knowledge
why is it not possible to implement a user selectable postscript generation? For
instance, selecting postscript printer p479 uses whatever implementation was
used in Netscape 4.79 to generate postscript whereas Postscript/default uses the
existing implementation. Or alternatively the choice of postscript generation
could be a printer property. At any rate there are pragmatic ways of solving
this problem without subjecting users to addons which may not work.
nbi@xnet.com wrote:
> This is totally unacceptable. Something that was working in previous browsers
> has been broken during the development of Mozilla. The right thing to do is to
> fix it where it is broken, in Mozilla, not to try to mask it via an addon such
> as Xprint (which may not solve the problem anyway).

Mozilla's Xprint module is not an add-on, it's a full replacement for the
PostScript module.

> It is unreasonable to
> suggest that people spend time with Xprint which according to its 
> documentation
> isn't a mature and stable application yet.

Ugh... who said that ? Where did you get info from ?
IMHO (I am the author and module owner :) the Xprint module is fully functional
and very stable.

> What happens when I discover that
> Xprint is incompatible with my working LPRng printing system?

The Linux version of Xprt (Xprint server side) is AFAIK working with LPng (and
CUPS) and has been tested with it multiple times...

> Are you going to
> tell me that I should purchase a new laser printer?

No, I did not suggest that...

> I'm not trying to print
> anything unusual or exotic. I don't need Xprint for printing from Netscape 
> 4.79 so why should I need it for Mozilla?

Mozilla's Xprint module supports additional features which were not supported in
NS4.x and cannot be supported via Mozilla's PostScript module (for example:
Support for multiple printers with multiple _different_ configurations, font
download, support for all locales/encodings including arabic, thai, chinese,
japanese and even MathML(!!) - and much more).

> I don't know how the postscript is being generated, but it seems that someone
> ought to know how Netscape 4.79 is generating it correctly. Given that 
> knowledge
> why is it not possible to implement a user selectable postscript generation?

Well, we could morph this bug into a RFE for supporting PS Level 1 printers for
compatibility, but the question is if anyone will work on this anytime soon...
;-(

> For
> instance, selecting postscript printer p479 uses whatever implementation was
> used in Netscape 4.79 to generate postscript whereas Postscript/default
> uses the
> existing implementation. Or alternatively the choice of postscript generation
> could be a printer property. At any rate there are pragmatic ways of solving
> this problem without subjecting users to addons which may not work.

Again, Mozilla's Xprint module is a full replacement for the PostScript module,
both can coexists but people usually prefer the Xprint module once they learned
how it works... :)
I tried an additional experiment, I tried printing problem pages via the Windows
version of Mozilla 1.0. Lo and behold - it works! So at least I have a sort of
workaround for the problem, I can boot to Windows. Grrr. This experiment should
certainly remove any remaining doubt. Why is Mozilla 1.0 producing valid
postscript under Windows, but not under Linux?? Clearly the OS has nothing to do
with the generated postscript. Somehow the postscript implementation for Linux
has been botched and it should definitely be fixed. It should be an easy enough
matter for the subject matter experts to compare the Windows postscript
generation vs. Linux and to reconcile the two (However it's being done, Windows
seems to be doing it right. Is Mozilla using gs for this?). 

Regarding disposition of this bug, I obviously believe it's something that
should be fixed and I think I presented a fairly solid case for that. If nobody
at Mozilla believes it's worth doing then so be it. The Xprint module is not a
simple drop in and replace operation, but I'm willing to give it a try if the
author provides concise documentation. My willingness to try it though should
not be interpreted as passing on this bug; I still want to see it fixed. At any
rate I don't think it's neccessary to consume more Bugzilla bandwidth so I'll
correspond with the Xprint author directly. 
Folks, my comments of 6/25 deserve some response. Clearly something is very
wrong if the same version on different platforms produces different postscript.
The postscript should be platform independent.
what's the status of this?
What's it going to take to see some action on this issue??
-->
Assignee: rods → dcone
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Target Milestone: --- → mozilla1.3alpha
> Folks, my comments of 6/25 deserve some response. Clearly something is very
> wrong if the same version on different platforms produces different postscript.
> The postscript should be platform independent.

 Well, by now, you may have realized why there's no response
at all... :-) Anyway, let me tell you what I know. 

> Why is Mozilla 1.0 producing valid
> postscript under Windows, but not under Linux?? Clearly the OS has nothing to do
> with the generated postscript.

 No, it has everything to do with OS. The fact that PS is an OS independent
standard page description language  does not mean that the way it's gen. 
by application programs under
different OS' is also OS independent.  When it comes to producing
PS, Mozilla-Windows(or most Windows application programs except
for programs like 'dvitops' converters for TeX/LaTeX) has to do very little, if
any. 
Most of the responsiblity of PS (PCL, or whatever format understood by your
printer) falls
 on the printer driver  you installed under MS Windows. (If you tried to use
a printer driver for PS level 2 printer with PS level 1 printer, that wouldn't work
even though nothing changed in Mozilla-Window. )
Appls. like Mozilla don't have to worry about gory details of output devices.(to
them,
rendering on the screen is not much different from generating
output for a printer).  Under Unix/X11,
the situation is very different. Most of works involved in generating PS 
has to be done by application programs like Mozilla and it's
not so easy to limit what one use  to PS level 1 when PS level 3
offers so many new convenient features.  Although I'm not
familiar wtih Xprint, I believe Xprint helps application program developers with
generating PS output by offering some abstraction over PS as an 'output device'. 
(See gfx/src/ps and gfx/src/xprint at http://lxr.mozilla.org/seamonkey/mozilla. 
Both modules are not used at all by Mozilla-Windows. ).


The solution to your problem is either to use Xprint 
or to configure your printer setting so that Mozilla
output goes through 'gs' (to make PS level 1 or 
other format understood by your printer such as PCL 3/4/5.
I believe your printer understands PCL as well as PS level 1) 
as suggested earlier.  The latter you have
to do anyway when Unix 'truetype' printing (with freetype) 
is introduced to Mozilla. Besides, it's very easy to configure
your printer (in recent distributions of Linux) that way.
Summary: [ps] 'print' produces un-printable postscript → [ps] 'print' produces unprintable postscript
Would you kindly print a very simple page to file and attach it to this bug?
This is the first page of a ps file produced by Mozilla 1.3b. This page
displays fine in gv, but won't print on our HP LaserJet 4100. The rest of the
pages of the document printed fine. Also, if I use ps2pdf to convert this page
into a pdf file, when I view it in acroread I get 'Wrong operand type'.
I don't find the function 'CanUseCIDFont' so its not using the embedded font code.

James: in the control panel in the 'Printing' menu there should be an option to
turn on printing a PS error page. Would you turn that on and let us know what error
is reported when printing this PS?

This is basically an RFE to support postscript level 1 on *nix. Print jobs not
printing on HP printers is a separate issue; see bug 192542 for example.
Assignee: dcone → core.printing
Severity: major → enhancement
Summary: [ps] 'print' produces unprintable postscript → [ps] Support Postscript level 1 printers
This bug is the same as 182324.

*** This bug has been marked as a duplicate of 182324 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: