12.04 Beta 1: Brother MFC8680DN cannot print text file

I have attached a scan of the bad print output from my MFC8680DN printer and the cups error log.

Please follow also the instructions of the section "Capturing print job data" on https://wiki.ubuntu.com/DebuggingPrintingProblems. Thanks.

Sorry, I missed that. I am attaching the captured print file. I was able to view this correctly under Document Viewer 3.3.90, but when sent to the printer it only prints the page header and the familar faint dots and dashes. The file command shows it to be PDF version 1.5.

Please make a clone of your print queue which prints into a file

cupsctl FileDevice=yes
lpadmin -p test -E -v file:/tmp/printout.ps -P /etc/cups/ppd/MFC-8680DN.ppd

Then print to this printer (test), run

chmod 777 /tmp/printout.ps

and attach /tmp/printout.ps

If you view /tmp/printout.ps on the screen via

gv /tmp/printout.ps

(run "sudo apt-get install gv" if needed) is the text readable?

Send /tmp/printout.ps to the printer unfiltered:

lpr -P MFC-8680DN -oraw /tmp/printout.ps

Does it come out correctly?

Chris, I have attached a file now resulting from printing Bruce's PDF file from comment #5 through a CUPS queue, using a Brother BR-Script PPD on Precise and printing the result into a file, like the "test" queue from comment #6. So this file should contain the exact data which gets sent to the printer.

Bruce, please still follow the instructions of comment #6.

Chris, now I have modified the pdftops CUPS filter to add "-dCompressPages=false -dCompressFonts=false" to the Ghostscript command line and attached the resulting PostScript which would go to the printer under that condition.

Bruce (or anyone else with the problem),

We *think* it might be a problem Type 3 fonts. I'm going to attach five modifed Postscript files to this bug, please use the command mentioned above:

lpr -P MFC-8680DN -oraw printout-uncompress-<number>.ps

to send each directly to the printer.

Please tell us which, if any, work as expected. NOTE: please run them all (even if you hit one that works) - there are several possible sources for this problem (if it's what we think it might be), and knowing which combination of changes works or not *might* help us narrow down where the fix should happen.

Chris

icb410, can you also follow all the instructions (especially test the sample files) which me and Chris (cliddell) have posted here? Thanks.

icb410, we need especially if you do the tests of the attached sample files, as described in comment #10.

None of them worked. #2 and #5 had the header and no text or weird dots/dashes. The others all had the same dots/dashes. All of them printed out 2 pages on my HL5250DN printer using the Brother-HL-5250DN BR-Script3 driver.

Ian

Ian,

Still guessing here (this is possibly going to be *much* harder to track down than the previous one).

This *should* disable the font glyph cache, so please try this file......

Thanks,

Chris

And a second method of disabling the glyph cache......

Please try this one, too.

Ian,

Can we just clarify what you meant when you said:
"All of them printed out 2 pages on my HL5250DN printer using the Brother-HL-5250DN BR-Script3 driver."

There should not be any "driver" involved, these Postscript files should be streamed directly to the printer. I just want to make sure you didn't open them in evince (or similar) and print from there.....

Thanks,

Chris

Neither nocache file worked (got dots and dashes).

I used the following commands to test:
 lpr -P Brother-HL-5250DN-series -oraw Downloads/printout-uncompressed-nocache-02.ps

I guess the -oraw ignores the ppd file and sends it unfiltered... sorry for not really understanding what I was doing.

Ian

Ian,

Thanks. And thanks for the clarification about sending the file - I'm not doubting your testing, I'm just *stunned* by these results!

Can you just confirm that in *all* these tests so far the "header" part ("File: /home/bruce...." etc, and the horizontal rule) has bee present in all of them.

Thanks,
Chris

Yep... the header was present in all of them. I have the same issue printing from Geany, though the only thing not lines and dashes are the header box and side line for the line numbers. I'll attach that printout in case that helps with anything.

Ian

I did the steps in section 6, and am attaching the output from /tmp/printout.ps. The file looked fine using gv. When sent to the printer, I could see the page header and the ususal faint dots and dashes.

Folks,

I ran out of time today, but I will have some more tests to try tomorrow.

Chris

For what it is worth, I just needed to print out an email. I had the mail reader print to a .pdf file, and then sent it to the printer using Document Viewer 3.3.90. The result was one horizontal line and dots and dashes, although it looked fine in Document Viewer. I went back and had the mail reader print to a .ps file. I printed the .ps file, and it came out fine. I am attaching the .pdf file.

I had upgraded my system earlier this morning.

Bruce,

The PDF contains a CIDFont which, when coverted via Ghostscript's ps2write device is converted in one (or more) Type 3 fonts - this is because, as the name suggests, ps2write outputs Level 2 Postscript, and CIDFonts are a Level 3 feature. I would assume that the PS the mail client emitted was Level 3, and thus could safely include CIDFonts, *or* handled the lack CIDFont support in a different manner.

It does *seem* that the Brother printer has a problem the Type 3 font we're generating.

So, here are a couple more test jobs for anyone willing to try:

First is a much more basic Type 3 font test - this is basically to make sure that the Brother printer is handling Type 3 fonts at all (if not, we're in a *lot* of trouble). This should print two numbered lines with an "A", a triangle and square repeated a few times. Please tell us the the results you get with it:
http://www.ghostscript.com/~chrisl/brother-t3font-01.ps

Second is a cut down version of the original test job, with only an upper case "J" character at the bottom left. I expect either a blank file, or a few pixels of the glyph to be visible. Debugging with the smaller file will be easier, but I want to make sure the smaller file still goes wrong before experimenting with it:
http://www.ghostscript.com/~chrisl/printout-uncompressed-01.ps

NOTE: I think I have all the printer specific runes correct, but I may have made a mistake, so if the printer barfs on either, please note the error, and post it here.

Thanks,

Chris

Hi,

Just tried printing the above files(#28), In the first (brother-t3-font-01.ps), I get a mostly empty page with two lines at the bottom (1:) and (2:) and 3 repeats of _ _ triangleglyph squareglyph

The second file gives two pages, the first is blank except for the gedit header. The second does not have the header, but the following text:

ERROR:
undefined
OFFENDING COMMAND:
image
STACK:
--nostringval--
-mark-
-mark-
-mark-
-mark-

Hi,

Thanks! It looks like I uploaded the wrong job, hence the second one giving an error.

But the fact that we can reproduce the problem with my entirely hand-coded Postscript is good - that will be much easier to experiment with.

We've shown the problem is with Type 3 glyphs with image masks in them, so we're narrowing down the problem.

So, here's the second experiment:
http://www.ghostscript.com/~chrisl/brother-t3font-02.ps

Again, we're looking for the numbered lines with "A", trangle glyph and square glyph.

Chris

Looks the same. No A's just _ _ triangle square

That is very odd. I flipped the A glyph bit map upside down, so I would have expected *some* difference to appear.

Two things: has anyone thought to take this up with Brother? *Loads* of other interpreters work just fine with this Postscript, and whilst we're willing accept the problem is with the Postscript, it would probably be much quicker for Brother to track down that problem than for us.

Anyway, second thing is another test - this has the "A" bitmap drawn *outside* the font as well - it should be very obvious.

http://www.ghostscript.com/~chrisl/brother-t3font-03.ps

Chris

Hi Chris,

I get
ERROR NAME;
   undefined
COMMAND;
   image
OPERAND STACK;
   --dicttype--
  --savetype--

on a grey background with #32.

Richard

Please let me know how to queue these files directly to the printer. When I open t3font-03 with Document Viewer and try to print it, I get four pages of faint dots and dashes. I am afraid, however, that the file is being modified by Document Viewer.

Bruce,

See comment #10 from Till.

Chris

Hi Bruce,

I've been using:
nc -w1 ip_address_of_printer 9100 < brother-t3font-03.ps

Doc viewer gives me 3 pages or dots and dashes, nc gives me the output in #33

Richard

I get the same thing as Richard (#33)

Richard,

Can you try this one:
http://www.ghostscript.com/~chrisl/brother-nofont-03.ps

Chris

Chris,

nofont-03 gives me 4 short horizontal lines. 2 about 2/3 way down the page in the centre (8cm apart). Two at bottom of sheet on the left same distance apart.

Richard

Richard (or anyone else interested),

It seems astonishing that these *basic* Postscript capabilities are this buggy on the printer!

Anyway, by way of another elimination:
http://www.ghostscript.com/~chrisl/brother-nofont-04.ps

On a *functional* Postscript interpreter, that prints 3 "A" characters across the centre of the page - these are just bitmaps, they are not contained in a font of any kind. What they have is three different ways of storing the data. I'm trying to eliminate the various data filters available in Postscript as being the source of the problem.

NOTE: there is bare binary data in this file, and that can sometimes cause problems with communication channels, if that proves to be the case and you get an error from the printer, please try this one:
http://www.ghostscript.com/~chrisl/brother-nofont-04-nobin.ps

Chris

Chris, thanks for pointing out the instructions. I should have figured something like that.

When I printed brother-nofont-04.ps, I got a line of characters about half way down the page. The first two characters were large "A's, about 60mm high. The third character was garbled, but appeared to be an attempt at an 'A'. There were no little dots or dashes.

When I printed brother-npfont-04-nobin.ps, I got a similar row half way down the page, but only the first two 'A's showed up. The line was blank where the garbled letter was on the other file.

Bruce

Bruce,

Woohoo! Finally, some progress! The garbled third character in brother-nofont-04.ps was the one with the naked binary, so the binary data probably got mangled en-route to the printer. And brother-npfont-04-nobin.ps only had the two characters in it.

*So*, it looks like the problem is with the CCITT Group4 FAX decode filter on the printer - that's a Postscript compression filter tailored to monochrome image data.

I'm going to ask my coleague to do a quick hack in the ps2write code so we can produce a test case from the original PDF above, but not using that the problem compression code. Hopefully I'll have that test for you tomorrow.

Chris

Hi Guys,

As promised, more tests to try.

This file is made from the original PDF attached above, nothing has been cut out or modified in the *page content*. The Postscript differences as described:

First has the glyph bitmaps uncompressed:
http://www.ghostscript.com/~chrisl/nocompression.ps

Second has the glyph bitmaps RLE compessed:
http://www.ghostscript.com/~chrisl/rle.ps

If you can send those to your printer(s), and post the results please.

Chris

Chris,

I sent both files to my printer, and both printed out just fine.

This seems like progress!

Bruce

Bruce,

That is, indeed, progress.

The good news is that we now know exactly where the problem lies, and what we can do work around it. The less good news is that there is no way to achieve that without patching Ghostscript and the CUPS workflow.

I believe (although it's not my area of responsibility) that the Ghostscript changes are pretty straightforward, so should not take long to implement - once done, we'll let Till know what he needs to do in CUPS to make this work.

Bruce and Richard, thanks again for your patience and help tracking this down!

Chris

Chris, could you provide me the needed Ghostscript patch and the instructions for the CUPS change before Wednesday so that the fix makes it into Ubuntu Precise 12.04 beta2? Thanks.

Till,

Well, it's Ken that's going to have to make the change, so it's dependent on him - I'll pass on the request.

The CUPS (or whatever) change will be adding an extra option to the Ghostscript command line, for these printers only - once again, we don't want to slow down good printers to work around a buggy one.

Chris

I got the needed patch from the Ghostscript upstream developers. The fixed packages for Precise (Ghostscript, cups-filters) are on their way.

The Ghostscript part is done now. I have applied the patch from Ghostscript upstream and uploaded the new Ghostscript package to Precise: ghostscript_9.05~dfsg-0ubuntu3.

This bug was fixed in the package ghostscript - 9.05~dfsg-0ubuntu3

---------------
ghostscript (9.05~dfsg-0ubuntu3) precise; urgency=low

  * debian/patches/020120319-d6f83df-ps2write-not3ccitt-option.patch: Added
    option to let Ghostscript's "ps2write" output device not compress images
    and bitmap glyphs with CCITTFax filter. The CCITTFax decoder in Brother's
    PostScript printers is broken (LP: #955553).
 -- Till Kamppeter <email address hidden> Mon, 19 Mar 2012 11:45:13 +0100

To test the patched Ghostscript, take the printout file from comment #5 and run the following to commands:

pdf2ps printout printout1.ps
pdf2ps -dNoT3CCITT -dEncodeMonoImages=false printout printout2.ps

Send botth resulting PostScript files to the printer, unfiltered. printout1.ps will not print correctly, but printout2.ps should do.

I attach my printout1.ps and printout2.ps, so you can even test before the new Ghostscript hits the mirrors.

Additional Ghostscript command line parameters to let the Ghostscript patch being used are added now in the pcftops filter in the upstream repository of cups-filters.

I verified that after this morning's updates I now have ghostscript 9.05~dfsg-0ubuntu3 installed.

I ran your suggested commands to create a local copy of printout1 and printout2, and also downloaded the posted versions. I sent all four files to the printer using lpr with -oraw. In all cases the printer activity light blinked for around a minute, but no printing was done. Each time I issued the lpr command, I got the following warning :

WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-vNebUc/pkcs11: No such file or directory

Strangely, after about four minutes, the printer printed the following warning:

ERROR:
invalidaccess
OFFENDING COMMAND:
length
STACK:

I tried printing the original text file from gedit, and got the familiar page header and faint dots and dashes.

According to the package manager, I have cups-filters version 1.0.5-1. Is this right?

I tried powering the printer down and up in case it had gotten confused from the printout1.ps, and then sent printout2.ps to it again. The status light blinked for 65 seconds. Again, the error message above was printed after about four minutes from the point the file transfer was complete. I have the feeling that the microcode got lost, and kept going until some resource (stack space?) was exhausted.

Finally, I opened the text file with abiword and printed it. The file transfer took 20 seconds and printed out correctly. I don't know what internal formats were involved.

Let me know if I can try something else.

Bruce

Bruce, if your printer is connected via network, you can also send the jobs via "nc" (package netcat-openbsd):

nc -w1 <IP of your printer> 9100 < file.ps

Please try ehether this works.

Using Abiword for printing the original text file works because Abiword uses a different method to generate print jobs.

Bruce, if your printer is on USB, you should be able to find its device file via

sudo usb_printerid /dev/usb/lp0
sudo usb_printerid /dev/usb/lp1
...

and then print unfiltered with a commands like

sudo -s
cat file.ps > /dev/usb/lp0
exit

My printer is connected through USB, so I used the method from comment #56. Once I bothered to turn the printer on, I found it under /dev/usb/lp0. When I send the files to the printer using cat ..., in both cases it took 65 seconds to transfer. I did not see the keyring warning. Neither file printed anything, until four minutes later, when the ERROR: invalidaccess message came out again. This was just like using the lpr -oraw method.

Bruce

Bruce or Till,

Can you post the Postscript you get when you do:
pdf2ps -dCompressPages=true -dCompressFonts=false -dNoT3CCITT -dEncodeMonoImages=false printout printout2.ps

Thanks,

Chris

I am attaching my result.

Bruce

Chris, here we go ...

Thanks, but I made a mistake, sorry, I meant:

pdf2ps -dCompressPages=false -dCompressFonts=false -dNoT3CCITT -dEncodeMonoImages=false printout printout2.ps

It's been a long day.....

Chris

Ok, this is with CompressPages=false.

Bruce

And here is also my corrected one.

Bruce,

Can you try sending these two tests to your printer, please?

http://www.ghostscript.com/~chrisl/printout2-1-pjl.ps
http://www.ghostscript.com/~chrisl/printout2-2-pjl.ps

Let us know the results.

Thanks,

Chris

Chris,

Both files print correctly, both when sent using lpr -oraw and when piped directly to the usb device. Also, they transfer to the printer in around 12 seconds, rather than the 65 seconds I was seeing before.

Bruce

Bruce, OK, thanks. This means that the fixes done so far (especially also the one in Ghostscript) are correct, but today's fix on cups-filters (1.0.6) is required. I will upload it soon. In addition, you need an original PPD file from Brother (BR-Script). We ship these PPDs for many Brother printers with Ubuntu.

Chris, thank you very much for your work on finding workarounds for Brother's PostScript interpreter bugs. It is all working now.

I have upstream-released cups-filters 1.0.6 now and packaged it for Debian and Ubuntu. It will soon get available (and for sure be part of Precise beta2). This contains the remaining part for the fix of this bug.

Thanks again everyone for the great work on solving this problem.

This bug was fixed in the package cups-filters - 1.0.6-0bzr1

---------------
cups-filters (1.0.6-0bzr1) precise; urgency=low

  * New upstream release
     - cups-filters 1.0.6 release
     - pdftops: Additional workaround for a bug in the PostsSript interpreters
       of Brother printers, calling Ghostscript with special command line
       options (LP: #955553).
     - pdftopdf: Correct handling of PJL output and page_log messages on
       native PDF printers and on printers using a driver after pdftopdf
       (including PostScript printers).
     - texttopdf: Full fontconfig support, several bug fixes and improvements
       to make the output work on more different PDF interpreters, including
       built-in interpreters in printers.
     - Fixed cupsfilters.drv PPD generator and rastertopclx filter to make the
       supported HP DesignJet printers actually work.
     - parallel backend: Use same method as CUPS to overcome infinite loop
       on side channel errors (LP: #936647, CUPS STR #4044).
     - "make clean" and "make distclesn" work also correctly now when called
       repeatedly (Closes: #663564).
 -- Till Kamppeter <email address hidden> Tue, 20 Mar 2012 12:34:56 +0100

I updated my system to cups-filters 1.0.6, and found that I could print a text file from gedit.

However, I found that there appears to be a problem printing a .pdf from Document Viewer 3.3.92. When I attempted to print the first page of the attached file to my DCP-7020, it came out fine. But when I tried the same thing to the MFC-8680DN, it printed the text for the first page, but not the picture. It also printed the following error message:

ERROR:
undefined
OFFENDING COMMAND:
TP.
STACK:
-mark-
-mark-
-mark-

Any ideas?

Thanks!

Bruce

I think your printer is even more broken that we thought!

At some point, someone is going to have to tell Brother their Postscript is broken!

But given that this is clearly a different issue, I think it would be best if you opened a new bug to track this new problem.

Chris

Can everyone who had this bug test the newest cups-filters package on my PPA:

https://launchpad.net/~till-kamppeter/+archive/ppa

Please follow the instructions under the link above and update your system. You should get cups-filters_1.0.15-0bzr1~ppa1, if not, update again some time later.

This package does not change or improve anything concerning your situation, but it is a regression test. We want to make sure that our fix for bug 977912 does not break anything.

Thank you in advance.

FIXED with:
Installation of package: brother-cups-wrapper-laser
Reinstalled Printer
Selected driver "MFC8860DN"
Seems to work fine.