182324 - [ps] mozilla generates level 3 postscript that will not print on a level 1 printer

Status: RESOLVED FIXED

(Core :: Printing: Output, defect, P3)

Description

[Joe Buehler]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126

Mozilla is generating level 2 grayscale postscript, which
my level 1 printer discards (and therefore prints nothing).

The problem is the document preamble.

The << >> in the following are level 2 constructs that are
illegal in level 1:

/UniDict    <<
16#0020    /space
16#0021    /exclam
16#0022    /quotedbl
16#0023    /numbersign

% lots of stuff omitted

16#FB2A    /afii57694
16#FB2B    /afii57695
16#FB35    /afii57723
16#FB4B    /afii57700
>>    def

Here is a suggested equivalent in level 1 code
(check this, I am not an expert, but it printed
OK with this change):

/UniDict 
1100 dict dup begin
/space 16#0020 def
/exclam 16#0021 def
/quotedbl 16#0022 def

% lots of similar stuff deleted

/afii57694 16#FB2A def
/afii57695 16#FB2B def
/afii57723 16#FB35 def
/afii57700 16#FB4B def
end
def

The offending postscript is hard-coded into libgfxps.so on my
linux box.

Reproducible: Always

Steps to Reproduce:
Print something in grayscale to a file and note that
the << >> syntax is present.  This is illegal in Postscript
level 1.

Actual Results:  
My printer discards the input document and prints nothing.


Expected Results:  
Everything should print OK -- level 1 Postscript is all
you need here.


Sorry if this is a dup -- I reported this but cannot find it in the search,
so must not have submitted it correctly.

Comment 1

[Roland Mainz]

AFAIK (rods may be correct me if I am wrong :) only PostScript Level3 printers
are supported by Mozilla's PostScript module (we have complaints about missing
PS Level2-compatibility in Mozilla's PS module, too) ...

There are two solutions:
- Use GhostScript to for PostScript---->PostScript filtering (yeah, that's ugly)
- Use the Xprint

Comment 2

[kill this account]

I have reqularly printed to a HP 5 printer with a level 2 (2014) postscript
interperter.

Could someone point out the level 3 postscript that is output?

Otherwise perhaps we should change the title to "RFE: Make Moz print on a 
Postscript level 1 (pre-1990 spec) printer".

Comment 3

[kill this account]

Interesting, the code that puts the '<<' was put in in Jan 2002 which is
11 months before the report.

http://lxr.mozilla.org/seamonkey/source/gfx/src/ps/nsPostScriptObj.cpp#735
735   fprintf(f, "/UniDict    <<\n");

Comment 4

[Carl Ponder]

I wrote a filter in Perl that performs the substitution described in the
original note, and am able to print to an IBM 4029 printer that (I believe) is
limited to Level 1 PostScript. I don't know if the filter can convert arbitrary
Level 2 files, but so far I haven't had any problems printing from Mozilla
(Firebird, actually) with it, indicating that Mozilla probably generates files
that are Level 1 compliant in every respect but this.

I put the entry

       pref("print.print_command", "convert_ps1 | lpr -P${MOZ_PRINTER_NAME}");

in the file

       MozillaFirebird_0.7/defaults/pref/unix.js

This forces the conversion even when I send files to a Level 2- or 3- compatible
printer and haven't had any problems. I use AIX (IBM Unix) so I don't know if
you can use this approach with Apple or other environments.

I couldn't figure out what you meant about using GhostScript or Xprint. BTW,
this looks like it ought to be a systematic, localized change to the Mozilla
source, though I haven't seen it to know for sure. I assume you only commit to
supporting Level 3 PostScript just in case you decide you need other features later.

Here's the text of my "convert_ps1" filter, you're welcome to give it out as a
fix or rewrite it as you see fit:

local ( $CONTEXT ) = 0;                                 # "Ground" state


while ( <> ) {

        if ( $CONTEXT == 0 ) {                          # "Ground" state:
                if ( /^\/UniDict\s*<<\s*$/ ) {          # look for "UniDIct";
                        print "/UniDict\n";
                        print "1100 dict dup begin\n";
                        $CONTEXT = 1;
                }
                else {                                # pass anything prior.
                        print;
                }
                next;
        }

        if ( $CONTEXT == 1 ) {
                if ( /^>>\s+def$/ ) {
                        print "end\n";
                        print "def\n";
                        $CONTEXT = 2;                  # Done converting.
                }
                elsif ( /^(\S+)\s+(\S+)$/ ) {
                        print "$2 $1 def\n";
                }
                else {
                        print STDERR "ERROR: didn't recognize $_";
                }
                next;
        }

        if ( $CONTEXT == 2 ) {
                print;
                next;
        }
}

Comment 5

[Carl Ponder]

I've used this filter with Mozilla & FireBird for months now, and never had a
problem print to my PostScript 1 printer.

However, I can't print *anything* from FireFox, with or without the filter. No
clue where to go from there. Anyone else have an idea??

Comment 6

[Carl Ponder]

Okay, here's something new:

      /rowdata where { /rowdata undef } if

These can occur in multiple places in the file. From a few tests, it looks like
commenting-out these forms will allow the files to print. Do any of you know
what this is, and more improtantly, what the equivalent PostScript-1 form would be?

BTW, bug #154027 includes some soapbox comments about how great "Mozilla's
Xprint module" is, but it really looks like PostScript-1 incompatibilities are
being added for no real reason, since there are equivalent compatible forms.

Comment 7

[Andrew Schultz]

Attachment: patch implementing comment 0

this implements the changes Joe described in comment 0, except that there
appear to be 1051 definitions now.

Comment 8

[Andrew Schultz]

Roland: is this patch ok?  The PS files it makes load in ggv, but that's about
all I can check.

Comment 9

[Roland Mainz]

Andrew Schultz wrote:
> Roland: is this patch ok?  The PS files it makes load in ggv, but that's about
> all I can check.

I can't comment on that since I don't know all the side-effects (and I've ran
enougth tests this and last month for the "Ancalagon" engine in Xprint... I am
weary of running PS printout tests in six different buildings).
The problem is that we are operating in a minefield. GhostScript/GV/KGV/GGV will
work but that does not mean it will work with real printers (due problems like
firmware bugs (one reason why kherron's reversal of the coordinate space will
bite back... ;-() and limited amount of memory).
dcone did a good job in testing all this things over and over again... but dcone
is gone now... ;-((( - please be carefull what you are doing.

Comment 10

[Andrew Schultz]

kenneth: do you have something less gloomy to say about the patch here?

(In reply to comment #9)
> The problem is that we are operating in a minefield. GhostScript/GV/KGV/GGV will
> work but that does not mean it will work with real printers (due problems like

well, we already know that the current behavior does NOT work with (some) real
printers.

Comment 11

[Andrew Schultz]

Comment on attachment 141935 [details] [diff] [review]
patch implementing comment 0

>+    "/afii57700            16#FB4B def\n"
>+    "def\n"
>+    "end\n"

comment 0 actually said:

end
def

but the "def" there appears incorrect anyway.  shouldn't it just be "end"

Comment 12

[Kenneth Herron]

Note I'm not a reviewer. These are just my two cents.

First of all, the original poster seems to have the keys and values reversed in
his suggested replacement. The numbers are the keys and they should still come
first, just as in the original. You won't see a problem printing pages
containing latin1 text because those bypass the unidict logic, but try printing
something like <http://moo.pl/ogonki/main.html> and you should see some breakage.

Second of all, the code should end in
  end
  def
just like the original reporter's example. The "UniDict" and a copy of the
dictionary are still on the stack, waiting to be def'ed.

Third, it would be useful to separate the keys and values with tabs instead of
spaces. Over the entire list this saves almost 3k, which is not insignificant.

Fourth, we have a bug (bug 223213) about compiling this code on windows. The
UniDict setup code is part of a 1300-or so line string constant, which is
apparently more than the MSVC compiler can handle. It's not an important bug--we
don't support this module on windows--but as long as we're modifying the code in
question, it wouldn't hurt to break the text into two or three separate
fprintf() calls.

This isn't the only level 2+ construct in the basic postscript module's output.
For example, characters outside of Latin1 are normally printed using the level 2
"glyphshow" operator, so any page containing these characters will probably fail
on a level 1 printer. However, it's apparently enough to make some pages work.
Further, the existing code for building UniDict stuffs all 2104 keys and values
on the stack before creating the dictionary, which may create memory pressure
even on level 2 printers. Overall this seems to be a worthwhile change.

I hadn't addressed this bug myself because I was hoping to develop a more
sophisticated change. Ideally this whole unidict/unicodeshow system should be
replaced, but within the current design we could make some changes. For example,
we could examine the strings being printed through "unicodeshow" for latin1
text, and print those using plain "show" commands. We could also keep track of
the unicode text actually contained in the document, and generate a UniDict
containing only the needed glyphs. This would let us support additional glyph
names--there are over 4000 "standard" names--while shrinking unidict and saving
printer memory for most documents.

Comment 13

[Andrew Schultz]

Attachment: not-broken patch

thanks, Kenneth.
this patch
1. fixes the key and end/def order
2. splits the fprintf string in thirds
3. 3 spaces -> tab

http://moo.pl/ogonki/main.html prints ok with this patch.

Comment 14

[Philip K. Warren]

(In reply to comment #13)
> Created an attachment (id=142010)
> not-broken patch
> 
> thanks, Kenneth.
> this patch
> 1. fixes the key and end/def order
> 2. splits the fprintf string in thirds
> 3. 3 spaces -> tab
> 
> http://moo.pl/ogonki/main.html prints ok with this patch.

Should we be looking for reviewers for this patch? Mozilla 1.7b freezes tomorrow
evening.

Comment 15

[Kenneth Herron]

Comment on attachment 142010 [details] [diff] [review]
not-broken patch

I verified that the actual list of glyphs is the same, and that the printout
for http://moo.pl/ogonki/main.html displays correctly. Everything looks good to
me.

Comment 16

[Andrew Schultz]

==> me

Comment 17

[Andrew Schultz]

patch checked in by timeless

resolving as FIXED.

Comment 18

[Philip K. Warren]

*** Bug 154027 has been marked as a duplicate of this bug. ***

Comment 19

[Carl Ponder]

I'm running FireFox version 1.0 Preview Release, and it still won't print to my
PostScript 1 printer. I see the "UniDict" has been rearranged to be consistent
with the comments #12-14, but I believe there is still something that is not
Level-1 compliant in the generated PostScript.

Also, I tried rearranging the UniDict so the character comes before the code, as
was described in the original defect, and successfully used with FireBird in
comments #4-5, but this didn't help either with FireFox.

Does anyone have any suggestions about other constructs that might cause the
incompatibilities with IBM 4029 printer? I'd wondered about these "rowdata"
entries, for example.

Comment 20

[Carl Ponder]

Ok, after some more testing: (1) the "unidict" looks fine with FireFox version
1.0 Preview Release. I don't have to mess with this. (2), I'm able to print some
pages by automatically commenting-out the "/rowdata where { /rowdata undef } if"
statements using a simple Perl filter. Here's the body:

    while ( <> ) {
 
        if ( m#^/rowdata where { /rowdata undef } if\n$# ) {
            print "%$_";
            next;
        }
        print;
 
    }

Again, you're welcome to suggest this as a workaround or modify it as you see
fit. I *suspect* that this problem is not an issue of Mozilla PostScript
Level-1 compliance, it's probably an idiosyncracy with the IBM 4029 driver.
I doubt this model of printer is supported any more, so it's unlikely that
any fix will happen.

In the meantime, can any of you offer any alternative forms to the statement
"/rowdata where { /rowdata undef } if", in case it really has to be there?
I'll keep digging through the PostScript documentation to see is there is
any way I can bulletproof the conversion.

Comment 21

[Kenneth Herron]

Carl, could you open a new bug about your issue? "undef" is a PS level 2
operator. The intent of that line is to remove a temporary string buffer used
while printing images, in order to save printer memory. The line could be
modified to avoid breakage on level 1 printers, and if it's the only thing
keeping a latin1 page from printing on a level 1 printer then we should probably
fix it.

Comment 22

[Carl Ponder]

So far I'm able to print web-pages using the above filter (note #20) but I can't
print messages from the http://ncmail.netscape.com (Netscape Mail) website. (This
is using their mail-webpage with Mozilla Firefox, not using Netscape/Mozilla/
Thunderibird mail).

I'll creata a new defect regarding Level 2 PostScript issues. Thanks for working
these issues!

Comment 23

[Carl Ponder]

Ok, I logged an analogous bug #263177 regarding Level-2 constructs.

I also noted that if I had a filter that worked in all cases, like my
Level 3 ("unidict") filter did, it would be enough, since it looks like
there is a good reason to be using the "undef" statements.