536282 - Text over a transparent image gets lost in image fallbacks when printed to postscript

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Ilja Sekler]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091221 Firefox/3.7a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091221 Firefox/3.7a1pre

Currently, printing images with alpha triggers usage of image fallbacks in PostScript output. If text (partially) overlays such an image, the text information which happens to be over the image gets lost. Please note, that this doesn't happen when image overlays text, despite image fallbacks.

Ideally there should be no need for fallbacks, but at least there should be no loss of text information, when printed to PostScript. Can't test whether this bug affects other platforms than Linux, presumably not.

Printing to PDF directly as offered by the GTK print dialog on Ubuntu 9.10 works fine (but lacks image resampling).

A testcase follows.

Reproducible: Always

Steps to Reproduce:
1. Print the testcase to a PostScript file, note a big fallback image in the file
2. Convert it with Ghostscript to PDF and open it with a PDF viewer
3. Select all text (mostly Ctrl+A).
Actual Results:  
The part of text which happens to overlay the transparent PNG image is not selectable, this information is lost. The entire area of the PNG image gets rendered as fallback image.

Expected Results:  
At least the complete text can be selected. Preferably, image fallbacks are not triggered when printing images with transparency at all.


As far as deleting the fallback image from the PostScript file doesn't help the lost text to reappear when converted to PDF, I think that it is not a Ghostscript bug.

Tested on Ubuntu 9.10; Firefox built with --enable-system-cairo; SourceStamp=641a22b4100a

The official 2009-12-21 m-c nightly with internal Cairo exposes the same issue.

Comment 1

[Ilja Sekler]

Attachment: Testcase: text over a partially transparent PNG image

Comment 2

[Ilja Sekler]

Attachment: PostScript output printing the testcase

Comment 3

[u285178]

As far as cairo is concerned this is a WONTFIX. The cairo PostScript output is only intended for printing, not conversion to PDF. The cairo PDF output is the recommended method of saving to PDF as it can use PDF features that are not available in PostScript such as transparency. Saving your testcase as PDF produces a PDF with selectable text.

I have previously looked into improving the fallbacks in the PostScript output and came to the conclusion it was not worth the effort required. It would significantly complicate the code to handle all the corner cases. As PostScript has been obsoleted by PDF it is not worth taking time away from improving the PDF output to optimize the PostScript output.

Comment 4

[Ilja Sekler]

(In reply to comment #3)

> As far as cairo is concerned this is a WONTFIX. The cairo PostScript output is
> only intended for printing, not conversion to PDF.

I can't judge whether anything can be done on Thebes' side to prevent cairo from getting input it doesn't understand. If not, please mark this bug WONTFIX.

The PostScript output from the testcase prints wrong on my HP inkjet printer anyway (the text in the left "column" overlays the image on paper), but I suspect a gs, hplip or CUPS bug here, because the display in evince is correct in this particular point. For now, using cairo PDF output and printing the resulting PDF file is the only way to get correct printout.

The other issue is the resolution of image fallbacks which doesn't get set to the printer resolution. The difference between "text" in image fallback areas and the normal text is clearly visible on paper with a good inkjet at 600dpi default printer resolution. Couldn't find an existing bug report for this issue though, except of your comment <https://bugzilla.mozilla.org/show_bug.cgi?id=422556#c5>.

Comment 5

[u285178]

(In reply to comment #4)
> The other issue is the resolution of image fallbacks which doesn't get set to
> the printer resolution. The difference between "text" in image fallback areas
> and the normal text is clearly visible on paper with a good inkjet at 600dpi
> default printer resolution.

Does printing the PDF have the same problem? As PDF is now the preferred print job format I am more interested in ensuring that the PDF output prints correctly. See also Bug 462872.

Comment 6

[Ilja Sekler]

(In reply to comment #5)

> (In reply to comment #4)
> 
>> The other issue is the resolution of image fallbacks which doesn't get set
>> to the printer resolution. [...]
> 
> Does printing the PDF have the same problem?

To check this a testcase which triggers image fallbacks for PDF would be required, hard job since the fix for Bug 435313 landed. Do you have any?

A test from a slightly modified <https://bugzilla.mozilla.org/attachment.cgi?id=335346> with a stock Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.5.6, which generates PDF files with fallback images, using evince to print the PDF ends in a disaster: the printer needs several minutes to complete the job, the text is pale and blurred. It seems as if filtering in evince/poppler would result in full-page raster images, masking any difference between the original fallback areas and the rest of the page.

> As PDF is now the preferred print job format I am more interested
> in ensuring that the PDF output prints correctly. See also
> Bug 462872.

Thank you for pointing me to Bug 462872. Unbitrotting and reverting the patch <https://bug415425.bugzilla.mozilla.org/attachment.cgi?id=301609> and thus making Firefox send PDF instead of PostScript to CUPS prints the testcase on Ubuntu 9.10 perfectly. Shouldn't it be a pref for this?

Anyway, if rectifying oddities with PostScript printing is considered not worth the effort, a clear declaration of PostScript output as deprecated from the Mozilla side would help IMVHO to direct effort of testers like the reporter of this bug away from obsolete routines.

Comment 7

[u285178]

(In reply to comment #6)
> > Does printing the PDF have the same problem?
> 
> To check this a testcase which triggers image fallbacks for PDF would be
> required, hard job since the fix for Bug 435313 landed. Do you have any?
> 
> A test from a slightly modified
> <https://bugzilla.mozilla.org/attachment.cgi?id=335346> with a stock
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6) Gecko/20091215 Ubuntu/9.10
> (karmic) Firefox/3.5.6, which generates PDF files with fallback images, using
> evince to print the PDF ends in a disaster: the printer needs several minutes
> to complete the job, the text is pale and blurred. It seems as if filtering in
> evince/poppler would result in full-page raster images, masking any difference
> between the original fallback areas and the rest of the page.

That would be the chain of bugs:

http://cworth.org/cairo/a_chain_of_bugs/

That bug won't occur if Firefox prints to CUPS in PDF format as CUPS does not use cairo. Try printing with lpr as this will pass the PDF directly to CUPS for printing.

Comment 8

[Ilja Sekler]

Attachment: lpr printout of a PDF with image fallbacks, scanned at 600dpi

> Try printing with lpr as this will pass the PDF directly to CUPS for
> printing.

Thank you, the scanned printout (printer resolution = scanner resolution = 600dpi) shows no perceptible difference in printout of text in image fallback areas from a PDF source mentioned in comment #5, though the positioning of the image fallback is slightly wrong (see the letter "i" cut vertically in half in "print"). For now, saving as PDF is sort of perfect on trunk, because image fallbacks are mostly avoided since the landing of Bug 435313.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Resolving as WONTFIX as it doesn't seem like there's much that will be done here. Reopen if this is still causing you pain.