printer ERROR: invalidaccess OFFENDING COMMAND: filter

Chris, it seems that nearly every PostScript printer needs a workaround so that it works with Ghostscript's ps2write output. What is actually the difference between the output of Ghostscript and Poppler? Why do all printers just work with Poppler's output?

I can't answer that.

I can say that Ghostscript's ps2write output is valid Level 2 Postscript - in other words, it is compliant with the language defined in the Adobe Postscript Language Reference Manual Edition 2. And not especially challenging Postscript, either.

Let me ask this: if gcc fails to compile C code that is demonstrably compliant with the C89 spec (for example), is that the fault of the coder who wrote the failing code, or a bug in gcc?

None of the issues that have arisen so far have highlighted any problem with our Postscript output.

And did poppler's output always "just work", or did they go through similar issues, possibly over a longer period?

I guess from this conversation that the upgrade to 12.04 involved changing from Poppler to Ghostscript. Is there any way for me to reconfigure 12.04 back to using Poppler so I don't have to reboot into 11.10 every time I want to print a document? Sorry, but I don't know much at all about the way cups does its magic.

Steve,

Yes, Ghostscript has replaced poppler, mainly due to the color management now available in GS, which currently only applies to printer drivers which use raster output - rather than ones like yours that use Postscript. Ultimately, the improved color management will apply to Postscript (and PDF) output from Ghostscript.

I seem to remember that there is a comment in the ps2write code to the effect that some filters on HP printers erroneously always close their underlying data source (closing it should be optional). I can't think of any other way for a call to create a decode filter to produce an invalidaccess error.

Steve,

Till is looking into the possibility of providing an option to use the poppler tool as a workaround, I'll leave it to him to update on that when/if he has news.

Obviously, in the long term, we'd like to resolve these issues that various printers have with the Postscript output from Ghostscript - note that Adobe CPSI consumes the GS output just fine, as does Adobe's Distiller, and several other Postscript interpreters.

If I could ask you to attach a Postscript file here on which your printer gives this error - hopefully, Till can post the instructions on how to do that.

After that, if you are willing, I'd like to give you some (possibly many!) Postscript files to send to your printer, to see if we can establish for sure what the problem is - if we can.

Chris

The problem is most probably caused by switching the pdftops CUPS filter from Poppler to Ghostscript and allowing higher image rendering resolutions when the pdftops filter has to turn graphical structures of the PDF input file into bitmaps when converting to PostScript and PostScript does not support these structures.

I have uploaded a cups-filters package to precise-proposed now which switches back to Poppler and limits the image rendering resolution to 360 dpi. Please test the package as soon as it gets available for download and give feedback here. This is required to make the new package an official update for Precise. Another comment with testing instructions will get posted here.

With the new package you can also test the behavior when switching between use of Poppler and Ghostscript and changing the resolution limit. Run the following commands in a terminal window for switching between Ghostscript and Poppler:

lpadmin -p <printer> -o pdftops-renderer-default=gs
lpadmin -p <printer> -o pdftops-renderer-default=pdftops

and

lpadmin -p printer -R pdftops-renderer-default

to remove the setting. To change the resolution limit run a command like

lpadmin -p <printer> -o pdftops-max-image-resolution-default=1440

and set unlimited resolution via

lpadmin -p <printer> -o pdftops-max-image-resolution-default=0

or remove your setting with

lpadmin -p <printer> -R pdftops-max-image-resolution-default

Always replace "<printer>" by your printer's queue name (enter "lpstat -v" to find your printer's queue name).

See also

/usr/share/doc/cups-filters/README.txt.gz

See and tell us in this bug report which works best for you.

A debdiff of the changes is attached.

To the SRU team: The relevant changes for the fix are in the file filter/pdftops.c. The file in the debdiff looks very cluttered as there are many lines where only white space (indentation) changed. Attached to this comment is a cleaner diff for this file with white space changes ignored (diff -b), here one especially sees how the conditional compiling for Ghostscript/Poppler is replaced by "if"s so that the Ghostscript/Poppler decision can be made at run time.

Chris,

Thanks for looking at this for me.
I'll do what I can to help, but will probably need leading by the nose.

Till has sent me info on a proposed change to allow switching between
Poppler and GhostScript. I'll have a stab at that, but I guess you want
your sample postscript file before I start messing things up.

I'm not sure how to capture a failing .ps file for you. My first guess
was to do a print-to-file from and editor called geany. I edited a small
text file, then chose File, Print, Print to File, Postscript and saved
to my desktop. This file looks fine in Evince, and prints perfectly when
I do use netcat to send it directly to the printer. What's more, it says
"Creator: cairo 1.10.2" so I guess it's not what you're looking for.

Then I captured the TCP conversation with wireshark. This one says
"Creator: GPL Ghostscript 905 (ps2write)" so I guess it's what you're
after. I attach two files. The first one is what the PC sent to the
printer, and the second is the reply the printer sent back. The printer
did not reply until all the print was sent - there was no overlap.

Please let me know if this is OK, and I'll start messing around with
Till's update.

Steve

On 16/05/12 12:47, cliddell wrote:
> Steve,
>
> Till is looking into the possibility of providing an option to use the
> poppler tool as a workaround, I'll leave it to him to update on that
> when/if he has news.
>
> Obviously, in the long term, we'd like to resolve these issues that
> various printers have with the Postscript output from Ghostscript - note
> that Adobe CPSI consumes the GS output just fine, as does Adobe's
> Distiller, and several other Postscript interpreters.
>
> If I could ask you to attach a Postscript file here on which your
> printer gives this error - hopefully, Till can post the instructions on
> how to do that.
>
> After that, if you are willing, I'd like to give you some (possibly
> many!) Postscript files to send to your printer, to see if we can
> establish for sure what the problem is - if we can.
>
> Chris
>

Steve, in addition to doing the test of the proposed package for the Precise update, please do also additional tests to investigate the root cause of the bug, so that we can work on a real fix. To do so, install the proposed package as oon as it gets available or ruun Quantal as live CD or in a virtual machine, create a second print queue for your printer, named "test" and run the commands

lpadmin -p test -o pdftops-renderer-default=gs
lpadmin -p test -o pdftops-max-image-resolution-default=0

Then print into this queue following the instructions of the sections "CUPS error_log" and "Capturing print job data" on https://wiki.ubuntu.com/DebuggingPrintingProblems. Thanks.

Steve,

Could I ask you to send this file (stream1-uc.ps) to your printer, please? It is the same content as your original, but with the compression removed.

You need to use:

lpr -P <printer name> -o raw stream1-uc.ps

If the HP in question is your only only, or your CUPS default printer, you can probably leave out the "-P <printer name>" option. The most important thing to note is the "-o raw" option, as this will cause the test to be streamed to the printer exactly as it stands - we don't want it going through the normal CUPS workflow (and thus changing the Postscript), in this case.

If you can let me know the result.

Thanks,

Chris

Hello.

I also work with the HP LaserJet 4050 (Ubuntu 12.04, 64 Bit, CUPS, printer is integrated via smb in a network) and when trying to print a pdf (LaTeX pdf file created from Lyx) from the Document Viewer, the printer prints some text on some pages and stopps at some point with the message on a white page:

ERROR:
typecheck
OFFENDING COMMAND:
known

Hmm, I have seen the bug reported here and though that you might be interested. Thanks a lot.

PS: As above, printing with the HP LaserJet 4050 was not an issue before (Ubuntu 10.10, 64 Bit)

BTW: Can you help me? - I would try to print some test pages ... but tell me again precisely what I shall do. Thanks in advance.

Hello steve.horsley, or anyone else affected,

Accepted cups-filters into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Alex, by changing status you probably want to say that you suffered the bug reported here and by following the instructions of comment #13, installing the proposed package with the fix, you got the problem solved. In such a case do not set the bug status to "Fix Released" as the package is not yet available as official update which gets installed by the automatic system updates. Instead, post a comment and replace the "verification-needed" tag by "verification-done". Thanks.

Another test you should try:

After having tested the proposed package without changing any default settings, run the following commands in a terminal window

lpadmin -p <printer> -o pdftops-renderer-default=gs
lpadmin -p <printer> -o pdftops-max-image-resolution-default=1440
lpadmin -p <printer> -o psdebug=true

with <printer> being the name of your print queue (You can find the name by ruuning the "lpstat -v" command).

After that try to print again. Does it work? If it works and if it is too slow, run

lpadmin -p <printer> -o pdftops-max-image-resolution-default=720

and try again. If it is still too slow, run

lpadmin -p <printer> -o pdftops-max-image-resolution-default=360

and try again.

Please report all your results here.

To get back to the default settings of the proposed package run the commands

lpadmin -p <printer> -R pdftops-renderer-default
lpadmin -p <printer> -R pdftops-max-image-resolution-default
lpadmin -p <printer> -R psdebug

Gents,
Sorry for the delay in responding, but we had something rather pressing demanding all our time.
I just sent the stream1-uc.ps mentioned in post #10 with identical results:

ERROR:
invalidaccess
OFFENDING COMMAND:
filter
STACK:
/SubFileDecode
endstream
0
--nostringval--
--nostringval--
11
false

I will have another look for the proposed update now.
Steve

Steve,

Thanks for trying that, it's eliminated the compression filters as being the problem.

Before I resort to "instrumenting" the Postscript, which will use up paper, can you try this file, please?

Again, like this:
lpr -P <printer name> -o raw stream1-uc2.ps

This changes the how the font data is encoded (note, for any Postscript afficianados reading this: it doesn't change the font's Encoding array).

Again, please post your result.

I can't get it to go wrong now. I installed the proposed cups-filters package as per post #6.

lpadmin -p <printer> -o pdftops-renderer-default=gs
lpadmin -p <printer> -o pdftops-renderer-default=pdftops
lpadmin -p printer -R pdftops-renderer-default
lpadmin -p <printer> -o pdftops-max-image-resolution-default=1440
lpadmin -p <printer> -o pdftops-max-image-resolution-default=0
lpadmin -p <printer> -R pdftops-max-image-resolution-default

All the above printed perfectly.

If you want, I can try reverting to the normal (not proposed) cups-filters and try again. At the moment, the only thing I've got that doesn't print correctly is the stream1-uc.ps from post #10.

What can I do from here to help?

Steve, thank you for testing. Marking the bug as verified.

Steve, did you test the proposed package once without configuration changes and then after each single "lpadmin" command? Did all printouts come out in a reasonable time? Or were there configurations with unreasonably slow output?

For the tests which Cris is asking for you do not need to change or revert anything. he asks you to print with the "-o raw" option which makes all filters not being used, so it does not matter which pdftops filter is installed and how it is configured.

Till,

I made one change before installing the proposed package, and that was enabling the debugging: "lpoptions -p <printer> -o psdebug" which didn't seem to make any difference.

Then I installed the proposed update. Sadly, I don't think I did a test print before running all the commands in post #18. I did run a test print after each command, and every one came out perfectly. o my impression so that having installed the update I cannot generate a bad print however I try, which is odd since I thought the update simply allows me to switch between PS generators.

I am happy to run speed tests. It will have to wait until Monday though. When I did the prints above, I was more interested in whether they would print properly and wasn't paying attention to the time it took to print. Ithink there may have been one print where I wondered for a while if it had worked, but I forget which one.

The "psdebug" change makes Ghostscript not compressing its PostScript output and this option already existed in the old package. Some printers may have problems with the compressed PostScript. Your printer's problem seems not to be incompatibility with compression. The old version was hard-coded to Ghostscript as renderer and now resolution limit. As this combination seems to work for you, print quality versus speed is the base for choosing the best configuration for you. So one of the other fixes in cups-filters 1.0.18 has solved your problem.

Sorry for the delay.
Speed tests:
I used each of these commands in turn, and printed a (small) page from geany after each command.
    lpadmin -p <printer> -o pdftops-renderer-default=gs
    lpadmin -p <printer> -o pdftops-renderer-default=pdftops
    lpadmin -p <printer> -R pdftops-renderer-default
    lpadmin -p <printer> -o pdftops-max-image-resolution-default=1440
    lpadmin -p <printer> -o pdftops-max-image-resolution-default=0
    lpadmin -p <printer> -R pdftops-max-image-resolution-default
and as close as I could time it, each print took the same time (3 seconds) before the printer began printing.

So no speed issues that I can detect.

Perhaps your printer is powerful enough also for rather awkward PostScript. For me it looks like that the error printout is not caused by Ghostscript sending bad PostScript but by crash bug 982675. It seems that for some people this bug causes a crash and for others it messes up the output.

This bug was fixed in the package cups-filters - 1.0.18-0ubuntu0.1

---------------
cups-filters (1.0.18-0ubuntu0.1) precise-proposed; urgency=low

  [ Till Kamppeter ]
  * New upstream release
     - pdftops: Allow selection whether Ghostscript or Poppler is used
       at runtime, setting the "pdftops-renderer" option to "gs" or
       "pdftops". This way one can switch to Poppler per-queue if there
       are incompatibilities with certain PostScript printers.
     - pdftops: Allow setting an upper limit for the image rendering
       resolution, also at runtime, setting the option
       "pdftops-max-image-resolution-default" to the desired limit in dpi.
       "0" means no limit.
     - pdftops: Fixed crash by wrong usage of sizeof() function when adding
       "Collate" to the fifth command line argument for the "pstops" CUPS
       filter call (LP: #982675).
     - pdftops: Removed newline from copies value when reading it from
       the "%%PDFTOPDFNumCopies" entry of the incoming PDF file.
     - pdftops: Silenced compiler warning about ignoring the return
       value of the write() function.
     - pdftops: Added a crash guard.
     - pdftops: Start determining the printing resolution with
       cupsRasterInterpretPPD(), this is the most reliable as often
       the choice names of the "Resolution" option are marketing names
       with higher numerical values than the actual resolution. Also
       ignore error exit values of cupsRasterInterpretPPD() as the
       function can error out after having found the resolution
       (LP: #984082).
     - pdftops: If printing resolution is determined by
       cupsRasterInterpretPPD() do not stick on 100 dpi if the
       resolution cannot be determined (LP: #984082).
  * debian/rules: Set default renderer for the pdftops filter to Poppler
    due to many printer's buggy interpreters having problems with GhostScript's
    PostScript and set image rendering resolution limit of the pdftops filter
    to 360 dpi to prevents slow processing by the printer if very high
    resolutions are used or if the printing resolution is mis-detected by the
    pdftops filter (LP: #668800, LP #951627 (comment #30), LP: #998087,
    LP: #992982 (comments #26, #27, #30, #31), LP: #997728, LP: #994477,
    LP: #998087, LP: #978120, LP: #862167).

  [ Didier Raboud ]
  * Drop libtiff5-dev, just use libtiff-dev, this fixes the FTBFS due to
    incompatibility with cups.
 -- Till Kamppeter <email address hidden> Wed, 16 May 2012 11:25:03 +0200

I newly installed 12.10 on one of 6 hosts here. The rest still use 12.04, and they work fine. The new install apparently has exactly the same problem that was reported here as fixed. I attempt to print an envelope using my HP 4050 printer, using Postcript/English (recommended). Instead of printing the envelope, it prints 2 ordinary pages, 1 blank and one that says only:

ERROR:
invalidaccess
OFFENDING COMMAND:
filter
STACK:
/SubFileDecode
endstream
0
--nostringval--
--nostringval--
11
false

Excuse me, I have the same problem printing to my HP LaserJet 1320. The problem appears when using Evince and lpr command from console. I have seen that someone has dealt with the problem

http://ubuntudriver.blogspot.com.es/

using Adobe Reader. I say this for what it is helps you to find the reason of the problem.

Thank you for your efforts and help.

I'm confused: my understanding was that this bug was resolved.

Besides, the thread seems to have become rather convoluted and confused.

If a problem is still occurring, could you open a new bug (subscribe me so I see it), and we'll take things from there, please?

I have checked my system is and it is updated but unfortunately, unfortunately, the problem persists. I tried to print with my HP LaserJet 1320 a simple pdf on Ubuntu 12.04 and everything went well. However when trying to print the same file under Ubuntu 13.10 (64 bit) in the same printer, I have obtained a blank and one with the message:

ERROR:
invalidaccess
OFENDING COMMAND:
filter
STACK:
/SubFileDecode
endstream
0
--nostringval--
--nostringval--
65
false

La prueba con la orden lpr ha fracasado también. Nevertheless Adobe Reader print the document according to the above blog.

What should I do?

My thanks in advance

Please, another thing: version of my file "cups-filter" is 1.0.40-0ubuntu1

For the time being you can switch to Poppler again as described in comment #6.

In the current cups-filters I have implented support for using Poppler for selected make/models and using Ghostscript otherwise. I could add HP to the manufacturers for which we use Poppler.

Chris, or should we generally use Poppler for PostScript printers?

Till, you know I can't answer that. For the issues we're looked at *not one* has actually highlighted any issue with Ghostscript's Postscript output, the Postscript has *always* been valid and correct.

There's simply no way I can guess at what bugs other interpreters may or may not have.

One more try! I have tried to print a page from a lightweight pdf (69.9 kB) file of 7 pages from evince. The result of the test was successful. It has been with Ubuntu 13.10 64-bits and Ubuntu 13.10 32-bits.

The problem is related to the weight / resolution of the file? The above tests I make were with files compiled with LaTeX for standard resolution.

I apologize for the repeated messages.

PDFs are vector format (with the option embed raster graphics "images" in them) so they don't have an inherent resolution.

It's more likely that a "light" PDF doesn't have images, or other "advanced" PDF features, that need converted into something else (PDF supports features that Postscript does not). Or possibly the "lighter" PDF doesn't embed fonts, or doesn't embed as many or as large fonts.

It's *really* impossible to guess without an awful lot of work from someone like me, and an awful of help from you to narrow down the printer's bug, and assess if there is a workaround.

Oh, and no need to apologize - we all want to get this stuff working.

Same error here. Runnning a newly installed trust tahr, 14.04, beta. Fully updated.

Using a Toshiba eStudio 2050c.
Install works fine in Ubuntu (choosing a slightly different printer model, or using file from Toshiba).
When printing I get the error pages described above. Both printing PDF or printer test page (i.e. no printing works).

Switching to poppler with:
lpadmin -p TOSHIBA-TEC-TOSHIBA-e-STUDIO-Series -o pdftops-renderer-default=pdftops
makes printing work.
Removing the setting with:
lpadmin -p TOSHIBA-TEC-TOSHIBA-e-STUDIO-Series -R pdftops-renderer-default
reverts to non working.

If someone proivide me instructions how to get the PS output I can run commands with the two different settings and send them over. I am not fluent in cups at all so I need some help to help debug it.

Tomas,

As this bug was reported as a problem with a HP LaserJet 4050, for which a fix has been released, I would ask you, please, to open a new bug, and subscribe me (cliddell) to the new bug, and we'll work forward from there.

The instructions of what to do are here:
https://wiki.ubuntu.com/DebuggingPrintingProblems#Getting_the_data_which_would_go_to_the_printer

But there is no point in attaching the two sets of output since the Postscript from Poppler is totally different to the Postscript from Ghostscript, and thus there's no chance of using a comparison to help. Just attach the failing Postscript - but note the next paragraph....

I'm happy to work through the issue and track down the source of the problem, but it will mean a lot of hand editing of Postscript files by me, and having to rely on you to send them to the printer and report the results back to me (and possibly mean burning through paper, too). We can probably find a workaround for the problem *if* we can narrow it down.

Hi, I found 978120 that seems to be the same for Toshiba eStudio. Do you want me to open a new issue, or perhaps continue in that one?

Tomas, thanks for reporting. Please work on a fix with cliddell.

To work around the problem for all users I have changed cups-filters (version 1.0.49, uploaded to Trusty/14.04) to use Poppler for Toshiba printers by default.

Tomas,

if you're getting the same "invalidfont" error as reported in #978120, then we can continue with that bug, if your error is different, I'd prefer a new bug.

I am getting 100% identical error as #978120, so continuing on that one. Thanks a lot!

Well or atleast 99% :-) I am assuming the VUEKTG is something that differs between installations...

Yes, that's probably the "subset prefix" - it's six random letters that differentiate a complete font from a subset font.

I have now release cups-filters 1.0.50 and uploaded it into Trusty (14.04 LTS). This version uses Ghostscript again with Toshiba's PostScript printers but with Chris' command-line-option-based workaround.

Thanks Tomas and Chris for the report and the great work to find the workaround.

Confirmed that it is working with our Toshiba eStudio. Awesome works from you guys. Glad to be able to help make Trusty a tiny bit better.

I had this problem with an HP LaserJet 4050. I'm running Ubuntu 14.04 with cups-filters 1.0.52-0ubuntu1. It was printing a page with:

ERROR:
invalidaccess
OFFENDING COMMAND:
filter
STACK:
/SubFileDecode
endstream
0
--nostringval--
--nostringval--
12
false

As in comment #35, I did:

lpadmin -p Hewlett-Packard-HP-LaserJet-4050-Series -o pdftops-renderer-default=pdftops

and after that it printed successfully.

Does that command need to be issued once per boot, once per user? Does it help to do it sudo?

The command only needs to be executed once. The change gets saved in /etc/cups/printers.conf.

Can you please do the following test:

First, remove your workaround using the command

lpadmin -p Hewlett-Packard-HP-LaserJet-4050-Series -R pdftops-renderer-default

The set CUPS debug logging as shown in "CUPS error_log" on https://wiki.ubuntu.com/DebuggingPrintingProblems, print one job and when you get the error page again, attach your error_log here.

After that, to be able to print, get back to your workaround via

lpadmin -p Hewlett-Packard-HP-LaserJet-4050-Series -o pdftops-renderer-default=pdftops

Hello everybody,

sorry for this late comment, this bug is really old and in this case or in many cases all ready fixed (i hope).
In my case i have the same problem with a printer from HP manufacture. Why i write this comment? I hope some people have the same problem still available and can fix it, too.

The bug/problem is: After 2 or 3 sites are printed the printer print out: "ERROR: Offending command: put" and nothing more. The printout will only crashed if we have more than one copy from the same print.
Keyword "Collate".

In the first situation the bug can be fixed with the cups option:
"-o pdftops-renderer-default=pdftops", but have anybody see after this option is set, the printout data will grow up for ten times. That was not really a good deal.

So i have used debug options from cups equals "cupsctl --debug-logging" to show me, how does cups will be convert the data stream from pdf (thats the first data stream after click in print) to postscript.
I found following processes:
"gs, pstops and hpps" (but the last one is not really important for this problem)

The first process will execute:
gs: gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=3 -r600 -dCompressFonts=false -dNoT3CCITT -dNOINTERPOLATE -c 'save pop' -f /var/spool/cups/d00721-001

after this:
pstops: /usr/lib/cups/filter/pstops 721 christian 'Some Title' 5 'job-originating-user-name=christian InputSlot=Tray3 noHPEdgeToEdge Duplex=DuplexTumble HPColorAsGray MediaType=Plain PageSize=A4 Collate job-priority=50 HPPJLOutputMode=GeneralOffice job-sheets=none,none number-up=1 job-uuid=urn:uuid:d69b588f-6144-314d-4578-5fe599927876 job-originating-host-name=localhost time-at-creation=1522310875 time-at-processing=1522310875'

and then hpps...
but this converting with hpps is not really interessting.

but if i read the postscript data with ghostscript after the first ghostscript process will done, i became the same error message how does the printer will printout:
"%%[ Error handled by opdfread.ps : typecheck; OffendingCommand: put ]%%". I stopped the printer queue and read the file with gs /var/spool/cups/d000723-001
Oh, thats really cool, but where is the problem?
Before than the ghostscript will convert to postscript or it comes with ghostscript?
Ok, i will change my ghostscript version from 9.10 to 9.23, never changed, same problem still available!
I reduce the options in the pstops statement because, the reduce from gs statements was no good idea ;-).
So after i reduce the option "Collate" the print out was complete printed. Ok the sorting of paper was not possible, but i have a idea :-D!
I have really do many changes with the ppd to become an answer.

The last step i have changed was: This option to "False" from ppd file: *cupsManualCopies: False
And my problem was done.

Now, can please tell me anybody, how does this option will bring up this error: "%%[ Error handled by opdfread.ps : typecheck; OffendingCommand: put ]%%".

thanks for all to support this bug.

Hi Christian,

So, my impression, from what you've described is that this isn't the same issue as the others in this bug (not least because the Postscript error is different: "typecheck" rather than "invalidaccess".

It *looks* to me like this is an problem with pstops, or an incompatibility between the way pstops manipulates its input and how the Ghostscript/ps2write output works.

Can I suggest you open a new bug? And (if you can) make sure I'm subscribed to it (or post a link to the new bug here).

On the new bug, if you could attach (ideally) three files: the input to Ghostscript, the output from Ghostscript and the output from pstops. Also, include the command lines you have listed above.

bug #978120 duplicate found again Now[,](https://play.google.com/store/apps/details?id=com.CRE8.LudoChat) can please tell me, anybody, how to avoid it?