Bug 689595

Created attachment 3609 [details]
Sample file which makes "mj..." drivers hang

This file is the sample input file for the command line shown above. It is the
output of Adobe Reader 8.1.1 printing an encrypted PDF into a file.

We cannot support this. Please contact the author.

We will pay a bounty for a fix.

Cockpit error marked this as FIXED. Reopening.

Upstream authors of the driver informed by e-mail.

Contacting the authors and giving them the chance to collect the bounty did not
help. Both e-mail addresses from the driver's source code do not exist any more.

Does the driver work with other files at all?

My guess is the dither algorithm is buggy for some range of intemediate colours.

Hin-Tak, I think I did also mass testing with the CUPS test page. Please try
with black text, perhaps the driver works in that case.

These 3 are fast:
1) b/w shapes (epl_test.ps from epsonepl) 
2) color shapes (tiger.ps from ghostscript)
3) general color + text (cups's test page)

but ghostscript is indeed stuck with the included ps file.
The driver seems to be stuck somewhere on page one.

I tried every device with fedora's shipped gs - and another device, photoex,
also seems to be stuck, but most others are fine except two segfaults (filed
separately as bug 690051 and bug 690052).

Would be interesting to have a look what's in common with the photoex device.


 

Seems to be a problem with color encoding. I think I have a good chance of
fixing this.

Created attachment 4357 [details]
a patch that fixes the hang but very likely print with wrong colors

This is a prototype patch which fixes the hang (but very likely have
undesirable color changes) - the hang is simply due to bit-rot - the driver is
missing encode_color/decode_color routines which is needed for postscript files
with rendering intent. The API enhancement was introduced in 2002, and this
driver simply has never picked up the API addition as it was always out-of-tree
until recently. The corresponding change in the parent driver cdj (on which mjc
was based) is svn r3320 in Nov 2002.

Till: do you actually have this printer? Most likely this change will invert or
swap colorants... it is easier just to print something to see which direction
it needs to be modified than to try to look at the color mapping code :-).

Also, the photoex driver needs a similar change, as it is also a decendant of
cdj and been out-of-tree until recently, and had suffered similiar bit-rot.

I do not have these printers. All changes I did were simply to keep the
unmaintained driver building with all new Ghostscript versions coming up and
having to be packaged for Mandriva and Ubuntu during the years.

Hin-Tak, I think we should wait for the Ghostscript developers to review your
patch, they probably see immediately whether you have done the color stuff the
right way.

I am quite sure the patch prints with wrong colors - possibly inverted or with
colorants swapped. svn 3320, the corresponding change in the parent driver in
2002, renames the routines also inverts the color components. I haven't invert
the color components yet (it is a bit more complicated than it sounds), but I
have tested the change and it changes the file size of tests quite dramatically,
e.g. from 0.5MB to 1MB and the opposite direction. 

In the absence of an actual printer, I guess the correct approach would be to
try to invert the components and play with the code until there is no
regression. It seems that adding the new routine hooks also changes behavior of
the driver regarding to ps files not having rendering intent instructions.

Assigning to Michael to review Hin-Tak's patch, but without testing on the
printer, it's hard to verify without a printer.

Hin-Tak may be able to verify the correct colors by using a debugger and
setting a breakpoint in the 'get_bits' call from the driver and check the
colors that way.

Yes, the tips about get_bits is useful. I'll give it a try when I find the time.

According to OpenPrinting database MJ series includes Japanese versions
of Epson Stylus printers. Common analogs are known for some of the printers
supported by the Ghostscript driver. Perhaps, one of them can be used to test
colors.

MJ 8000C  =  Epson Stylus Color 3000.
MJ-6000C  =  Epson Stylus Color 1520.
MJ-930C   =  Epson Stylus Color 800.

Thanks for the tips - I'll have a look soon.

Created attachment 4710 [details]
new patch

new patch with more correct colour mapping.

Created attachment 4711 [details]
a bunch of test files,t ar,gz'ed

a bunch of test files, tar gz'ed. Some are plain solid colors (including white)
, some are mods of the first page of the original sample with a different solid
colour.

I am afraid I have some bad news - I think even with a postscript file without
rendering intent, the driver code is just completely wrong and non-functional.
This is shown by the fact that if you use the solid white/red/black colour pages
in my attached bundle, the output is identical. Surely the printer data for
whole red/white/black pages should not be the same.

With my new patch, at least white pages (and pages which are mostly white)
results in much smaller spool files than the other solid colors, and that has
got to be more correct than the current driver code.

The other driver, photoex, which hangs with the sample file mentioned in comment
8, also have the problem of identical spool files with the 4 pages of solid
colors. i.e. it is also completely non-functional as is.

So my suggestion would be:
1) if somebody has the Epson Stylus Color 3000/Epson Stylus Color 1520/Epson
Stylus Color 800 that Alex mentioned in comment 17; give the new patch a try.
At least the new patch shouldn't waste ink, unlike the current code, which
possibly prints a mostly white page with a solid color of some sort.
2) I have also e-mail the author of the photoex driver, and see if I get a reply.

It is not hopeful - the Machjet code is a derivative of the cdj driver in gs
2.61 15 years ago; and the photoex driver is likewise of gs 5.10 vintage from
1999-2001. Both sets of drivers have alternative drivers. So one is 15 years old
and the other is 8 years old.

3) if Till or nobody has the Epson Stylus 800/1520/300 or the photoex printers
(Epson Stylus Photo EX, Photo 700, etc), I think it would be advisable to remove
both the drivers or disable them in default builds, since they are superceded by
gutenprint. (in fact, the Photo Ex was apparently one of the printers which
spawned the gimp-print project).

I think obsoleting the driver in the OpenPrinting database (in favor of
Gutenprint) and removing it from Ghostscript would be generally a good idea. I
only need to know about the following printers whether they work with Gutenprint
and which model has to be selected under Gutenprint:

1. Epson MachJet (listed as supported by only "mj700v2c")
2. Epson Stylus (listed as supported by only "mj700v2c")
3. Epson Stylus Color 200 (listed as supported by only "mj500c")

The printers are old, all only 360x360 dpi and the first two only BW.

The driver entries "mj6000c" and "mj8000c" I can already mark obsolete as all
printers there work with Gutenprint and have Gutenprint already as recommended
driver.

There is no "photoex" driver entry at all in the OpenPrinting database, probably
as this driver was obsolete already as I started maintaining OpenPrinting. The
Epson Stylus Photo EX was the printer with which the Gutenprint project was started.

Don't know if its any use, but I have an Epson Stylus Photo 870 here. I have no
idea if its related to the problem though.

Hmm, the photo 870 might be useful for testing equivalent change in the photoex
driver. (if we go that route). I'll wait a few days to see if the author of the
photoex driver still reachable by e-mail though.

In terms of long-term maintenance, I think both the mjc* and the photoex drivers
are clearly non-functional at the moment because it is wrong that two solid
colours should render to the same data steam. (please give it a try to
double-check). The required change is I think what Dan Cosby did in r3320-ish
for a bunch of drivers in 2002; my 2nd patch is roughly in the right direction,
I think; since there seems to be better alternatives, there are various ways to
go about this:
1) keep it in tree (as a sample of old/broken driver code?) and just document
that it no longer works and not recommended in documentation and elsewhere.
2) make it optional, disable building either of them in the default config. e.g.
make a new category of optional drivers which are known not-quite working,
pending somebody interested enough and have the hardware to come along to fix it.
3) removing the code itself.

OTOH, I hope the gimp-print/japanese people come up with some hardware, as an
alternative to doing something is occasionally interesting to keep it around.

I have an Epson Stylus Color 200 printer and have been using this with the black
print head with fedora 5 (mj500c) until a couple of weeks ago when I clean
installed Fedora 11. This driver now gives a solid black image. Using the epson
stylus color (not 200) stcolor driver allows correct printing of documents etc.
Colour printing is still not correct. I posted a bug with red hat - please see 
https://bugzilla.redhat.com/show_bug.cgi?id=513676
for the details.
I'm not sure if this issue is related to this bug
If you need a printer for a test I'm happy to give it a try but please be
reasonably explicit with any instruction.

Andrew: it is probably related... I'd probably like your to try my patch (or a
test file generated from it), but before that, I'd want to see the result of
"Colour printing is still not correct" from the stcolor driver first. Can you
either scan or just take a digital picture of the result and attach it here? It
doesn't need to be too high-res. Failing that, seeing as you have a uk adress
you can probably spend 15p and an envelope, and post the result to me the
old-fashioned way.

Created attachment 5278 [details]
printer_test_mj500c

Created attachment 5279 [details]
printer_test_stcolor

see comment 18 bugzilla redhat 513676.
Attachments
printer_test_mj500c test one image was
raw file mj500c cups v1.1.x interpreter version 3010 (81501)

printer_test_mj500c test two image was
raw file mj500c cupsv1.2.x interpreter version 3010 (81502)

printer_test_stcolor was
stcolor.ppd driver version 1.1 cups 1.4rc1. Printer 'print test page' via
system config printer properties

Closing due to lack of activity.