Closed Bug 378307 Opened 17 years ago Closed 17 years ago

Printing shouldn't be using image fallbacks when scaling

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9alpha8

People

(Reporter: RyanVM, Unassigned)

Details

Attachments

(2 files)

a testcase for elements which trigger usage of image fallbacks
2.73 KB, text/html
Details
this table still gets printed using image fallbacks
452 bytes, text/html
Details 
As was noted in bug 370631 comments #25 and #26, the current use of image fallbacks when scaling in print preview is sub-optimal for a few reasons.

1.) It's a slow path
2.) It leads to bloated PDFs when printing to PDF, not to mention unselectable text. As I noted in comment #26 of bug 370631, the difference in PDF size between a PDF printed from IE7 vs. the same page printed from the trunk is roughly 350KB to 12KB and the text is worthless in the trunk PDF.
Flags: blocking1.9?
Assignee: general → nobody
Component: GFX → GFX: Thebes
QA Contact: ian → thebes
This is going to need some pretty serious investigation; this is specifically talking about using fallbacks for -text- when scaling?
Flags: blocking1.9? → blocking1.9+
Correct, as I understand things anyway :)
The issue here is specifically with text and a scale factor less than 100% (scale factors >= 100% don't have this issue.)
Target Milestone: --- → mozilla1.9beta1
For me, increasing the scale factor over 100% doesn't change anything. All trunk builds starting with 2007-05-01-04 use image fallbacks for printing in allmost all cases if a web page contains anything more than a pure text. Some possible triggers are horizontal lines (<hr> and borders) and PNG images with transparency. The testcase should be printed fine if the "border-bottom" property for .problem is set to 0px instead of 1px unless one uncomments the minefield-icon.png.
This might be caused by setting the cairo operator to OPERATOR_ADD in the new CSS border code. The PDF backend doesn't support OPERATOR_ADD.
Seems to be fixed by cairo upgrade from bug 395449 at least for Windows and Linux.

However, there is an issue with PDF files generated by Ghostscript (both on Linux and Windows) from postscript output of Firefox on Linux. Opening such a file in Adobe Reader, selecting text, copying and pasting it into a text editor pastes only garbage.

In Evince 0.8.1 on Ubuntu 7.04 not all letters are selectable, c&p produces also garbage.

The postscript output of Firefox on Windows is totally fine, it doesn't make a difference on which system PDF is then generated.

Tested with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007092111 Minefield/3.0a8pre (checkout start: Fr 21. Sep 10:34:05 CEST 2007) and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007092105 Minefield/3.0a8pre.

Is it something to be treated here? Presumably not. In this case I'll file a new bug if this problem hasn't been reported earlier.
(In reply to comment #6)

> However, there is an issue with PDF files generated by Ghostscript (both on
> Linux and Windows) from postscript output of Firefox on Linux. Opening such a
> file in Adobe Reader, selecting text, copying and pasting it into a text editor
> pastes only garbage.

https://bugzilla.mozilla.org/show_bug.cgi?id=329886#c11

I'm going to mark this as fixed based on the updated win32 and linux code that went in with the latest cairo upgrade; for Mac, we talk directly to CG, so I don't know how much better we can be there.

Please file more specific (and platform-specific) bugs for any remaining issues.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
When I print to PDF, the text is very much being saved as images still, as mentioned in comment #0. To me, that indicates that this bug isn't fixed. Am I wrong, vlad?
Same here, in some cases the updated cairo doesn't help. Depending on values for "cellspacing" and "cellpadding" in this testcase the content of the table is printed either using image fallbacks or "normally" (which is itself of a very limited use until Bug 329886 is not fixed an we lose the text).
Wait, how are you printing to PDF?  If using the normal print as PDF stuff on the Mac, we can't do anything about that -- like I said, we use straight CG here, so if anyone is doing image fallbacks, it's CG.  If on another platform, how are you doing the PDF saving?
On my part, I print to a PostScript file, then make a PDF out of it using Ghostscript.

On Linux: Ctrl+P in Firefox -> [x] Print to file -> Print.
Then: ps2pdf $FIREFOX_GENERATED_POSTSCRIPT_FILE.ps
(Ghostscript version: 8.15.4.dfsg.1-0ubuntu1)

On Windows: printing to a virtual PostScript printer (Apple Color LW 12/660 PS) with a "FILE" connection, then invoking pdfwrite of gs8.51 from gsview to generate a PDF file.

I don't have a Mac to test on my own, I asked a colleague on behalf of Bug 329886 to print http://www.golem.de/print.php?a=54889 to PDF on his Mac, the file he send me on 2007-09-24 was fine - no image fallbacks, no text loss.
On Windows, I've used both PDFCreator and Acrobat Professional 8.1.0, both with the same results.
so the Windows and Linux issues are two very different things; stuart may know more though, so i'll poke him.  I don't see why we would ever do image fallbacks on windows, especially now.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: