Closed Bug 638764 Opened 9 years ago Closed 9 years ago
result of print to pdf printer has text which is not selectable
25.26 KB, application/pdf
29.39 KB, application/pdf
35.90 KB, image/png
206.95 KB, application/pdf
10.95 KB, patch
|Details | Diff | Splinter Review|
3.02 MB, application/pdf
79.05 KB, application/pdf
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12 Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12 After printing page to PDF printer: Acrobat Distiller 9.4.2 (Windows) / PScript5.dll Version 5.2.2 the text in pdf is not selectable also the file is quite big for a few paragraphs of text (over 1MB for printed version of this page - https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&format=guided ) compared to 57kB when the same page is printed from FF3.6 Looks like it's printed like graphics instead of text with fonts. This support issue seems to have additional info: http://support.mozilla.com/en-US/questions/760923 - suggesting it has connection to hardware accelaration of rendering. IMHO if FF4.0 is shipped with this bug a lot of people would find it disappointing. Maybe has connection to Bug 625852 ?? Reproducible: Always Steps to Reproduce: 1. open a page in FF4.0b12 2. select print from file menu 3. in print dialog select Adobe PDF as writer and send to print Actual Results: Good looking PDF file with everything fine except the text is not selectable and the file is quite big. Expected Results: The text in PDF should be selectable and the resulting file should be much smaller.
I forgot to mention that I have fully accelerated rendering switched on: Adapter NVIDIA GeForce 8600M GT Id manufacturer 10de Id device 0407 RAM 256 Drivers nvd3dum nvwgf2um,nvwgf2um Driver version 126.96.36.19999 Driver date 10-16-2010 Direct2D enabled true DirectWrite enabled true (6.1.7600.16699, font cache n/a) WebGL Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541) Windows graphic acceleration 2/2 Direct3D 10
It's possible that the patch is using graphical effects that can't be represented with just text...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Not in this case. A Feb 12 Linux build with acceleration disabled works fine for me --- https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&format=guided prints to a 70K file and I can select the text. Tomáš, if you disable acceleration on Windows, does your build work? This is likely to be an issue in the font subsystem or possibly cairo.
Assignee: nobody → jfkthame
Duplicate of this bug: 638763
When acceleration disabled: Popis adaptéru NVIDIA GeForce 8600M GT Direct2D enabled false DirectWrite enabled false (6.1.7600.16699, font cache n/a) WebGL Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541) Windows graphic acceleration 0/1 at this setting the outcome of print varies. Sometimes page is printed absolutely weird and sometimes the outcome is looking right and the text is selectable. Also the file size of PDF is appropriate to printed text. I'm sending samples of printed PDF files which are printed wrong. It looks like it's not dependant on any particular page, just some occasional bug. It's not regularly reproducible.
(In reply to comment #5) > When acceleration disabled: > > Popis adaptéru NVIDIA GeForce 8600M GT > Direct2D enabled false > DirectWrite enabled false (6.1.7600.16699, font cache n/a) > WebGL Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541) > Windows graphic acceleration 0/1 > > > at this setting the outcome of print varies. Sometimes page is printed > absolutely weird and sometimes the outcome is looking right and the text is > selectable. Also the file size of PDF is appropriate to printed text. > > I'm sending samples of printed PDF files which are printed wrong. > > It looks like it's not dependant on any particular page, just some occasional > bug. It's not regularly reproducible. That's bug 635768, which was fixed since beta12 was built - you need to update to the latest nightly (or RC, when it comes out). That is unrelated to any problems when accelerated rendering is enabled.
So with nightly minefield: 4.0b13pre buildID 20110305030406 Direct2D Enabled true DirectWrite Enabled true (6.1.7600.16699, font cache n/a) WebGL Renderer Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541) GPU Accelerated Windows 1/1 Direct3D 10 resulted in PDF with text not selectable and big file size. Minefield with HW accel. off and Adobe PDF printer produces PDF file with selectable text and appropriate size.
When D2D is not enabled, so we just use GDI rendering, the PDF is correctly generated with text and fonts, so that the text remains selectable and renders properly as the PDF is scaled. When D2D is enabled, it looks like all the glyphs in the text are being converted to outline graphics, so the textual nature of the data is lost; moreover, the conversion is lousy, as can be seen in the screenshot here which shows magnified views (in Acrobat) of the same glyph in a PDF generated via the GDI path (left) and one generated with D2D (right). Note how the glyph in the D2D-generated PDF has a very irregular, ugly outline.
Actually, the issue is not GDI vs D2D rendering backends, but GDI vs DWrite fonts. If DWrite is enabled, even with D2D disabled, we get the bad PDF.
So, the problem begins in _cairo_win32_printing_surface_show_glyphs, which handles CAIRO_FONT_TYPE_WIN32 via a "proper" text-rendering path, but doesn't know about CAIRO_FONT_TYPE_DWRITE and therefore falls back on getting glyph outlines as paths and filling them. This results in all the symptoms here: huge PDFs, no selectable or searchable text, and lousy glyph shapes. It's trivial to make _cairo_win32_printing_surface_show_glyphs know about dwrite fonts as well as win32 fonts, and it will then call _cairo_win32_surface_show_glyphs instead of using its glyph-path fallback. HOWEVER, this doesn't actually help us, because with dwrite fonts, _cairo_win32_surface_show_glyphs will call the helper _cairo_dwrite_show_glyphs_on_surface. And how does that work? It generates and blits bitmaps into the device context. So at "best", the end result would be to replace the path-based glyph shapes with bitmaps rasterized at 300dpi. They'd still look rough, they'd still not be selectable or searchable as text, and the files would still be huge. :( (An added issue is that something goes wrong with this path anyway, when rendering to a printer DC: I'm seeing the background filled with black, so the text ends up invisible unless it happens to be a non-black color. But given that painting all the text as bitmaps wouldn't really be an improvement anyway, I'm not going to try figuring out what's wrong here.)
This feels like a rather ugly hack, but it resolves the problem, and I don't see how else we can do it. The DW/GDI interop stuff worries me because it does not guarantee to give us the same physical font for use in GDI as DW was using. But we're already relying on this for font table access in some cases, so I guess it's no worse to use it here. As a precaution, the patch checks whether the resulting GDI font turned out to be a Type1 or bitmap font, and bails if that happens because DW can't have been using those. (This shouldn't happen, based on the lfOutPrecision value set in the LOGFONT, but I don't know how far we can trust the font mapping algorithms.)
There's a tryserver build at http://email@example.com if you'd like to test printing with this patch and confirm whether it works as expected.
At my configuration the tryserver build works fine for paragraph (maybe also some other text), but headers are still not selectable - confirmed on multiple sites. Eg: http://edition.cnn.com/2011/TECH/innovation/03/10/why.sxsw.matters/index.html HW acceleration ON
(In reply to comment #15) > At my configuration the tryserver build works fine for paragraph (maybe also > some other text), but headers are still not selectable - confirmed on multiple > sites. Eg: > http://edition.cnn.com/2011/TECH/innovation/03/10/why.sxsw.matters/index.html > > HW acceleration ON Could you post an example of such a PDF, please?
OS: Windows 7 → Windows XP
I tried other sites with the same result, the h1 tag cannot be selected in printed PDF (with tryserver build) - didn't tested other headers - H2 etc.
I don't know why this happens. I tried printing a similar page from the same site, and all the text (including the <h1> title) can be selected in the resulting PDF. I notice that you're using Adobe Distiller, whereas I was using the PDF995 driver; perhaps that creates the PDF in a slightly different way.
Yes maybe it could be on Adobe distiller's side.. Thanks for making most of the text selectable..
Updated to use RefPtr<IDWriteGdiInterop> to avoid leaking the interop object. Untested until I get home, but ought to be fine. :)
Comment on attachment 524562 [details] [diff] [review] patch, fix dwrite printing to use real fonts - updated to use RefPtr<> for gdi interop object >diff --git a/gfx/cairo/cairo/src/cairo-dwrite-font.cpp b/gfx/cairo/cairo/src/cairo-dwrite-font.cpp >--- a/gfx/cairo/cairo/src/cairo-dwrite-font.cpp >+++ b/gfx/cairo/cairo/src/cairo-dwrite-font.cpp >@@ -1364,8 +1364,70 @@ _cairo_dwrite_show_glyphs_on_surface(voi >+ LOGFONTW logfont; >+ gdiInterop->ConvertFontFaceToLOGFONT (dwface->dwriteface, &logfont); We should probably check the return value here. >diff --git a/gfx/cairo/cairo/src/cairo-platform.h b/gfx/cairo/cairo/src/cairo-platform.h >--- a/gfx/cairo/cairo/src/cairo-platform.h >+++ b/gfx/cairo/cairo/src/cairo-platform.h >@@ -34,16 +34,19 @@ > * Stuart Parmenter <firstname.lastname@example.org> > */ > > #ifndef CAIRO_PLATFORM_H > #define CAIRO_PLATFORM_H > > #include "prcpucfg.h" > >+/* we're replacing any definition from cairoint.h etc */ >+#undef cairo_public >+ This is good but should probably go in a separate patch.
Attachment #524562 - Flags: review?(bas.schouten) → review+
(In reply to comment #23) > We should probably check the return value here. Added check and pushed to cedar: http://hg.mozilla.org/projects/cedar/rev/6cfaf3ab8b96 > This is good but should probably go in a separate patch. Pushed followup to cedar as a separate changeset: http://hg.mozilla.org/projects/cedar/rev/364b5727594a
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.2
My bug was one of the duplicates. Problem still exists even though my FF4 just updated itself. See the attached printout of this page. This means I have to use IE to print -- aaahhhgh!!
This is the one I meant to attach. Could you delete the previous attachment. I am attaching the printout of this page in FF4 Win7; my FF updated and the problem still exists.
Attachment #529087 - Attachment is obsolete: true
My bug was one of the duplicates. Problem still exists even though my FF4 just updated itself. See the attached printout of this page. This means I have to use IE to print.
Attachment #529088 - Attachment is obsolete: true
This fix did not land for Fx4. Does the problem persist in Aurora builds?
Just tested with Aurora build 5.0a2 (2011-04-29) and most of text is selectable but as I mentioned in one of my previous comments some headers are not selectable. My guess is it could have something to do with custom fonts used with headers. I'm attaching sample of PDF with headers not selectable. Still on: WIN 7, Acrobat Distiller 9.4.2 (Windows) / PScript5.dll Version 5.2.2 Aurora build 5.0a2 (2011-04-29) Direct2D enabled DirectWrite enabled
Aurora 5.0a2 URL of printed page: https://wiki.mozilla.org/Firefox/Aurora/2011-04-28
(In reply to comment #32) > Created attachment 529274 [details] > Sample of PDF with headers not selectable > > Aurora 5.0a2 > > URL of printed page: > https://wiki.mozilla.org/Firefox/Aurora/2011-04-28 I can not reproduce. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110413 Firefox/5.0a2 ID:20110429042003 Tested Printers: PDF Creator 1.2.0 and Bullzip PDF Printer 188.8.131.52.18 Graphics: Adapter Description: ATI Radeon HD 4300/4500 Series Vendor ID: 1002 Device ID: 954f Adapter RAM: 512 Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64 Driver Version: 8.841.0.0 Driver Date: 4-5-2011 Direct2D Enabled: true DirectWrite Enabled: true (6.1.7601.17563, font cache n/a) WebGL Renderer: Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.611) GPU Accelerated Windows: 1/1 Direct3D 10
Now I confirm, inability to select headers seems like problem of Acrobat Distiller. When printing with PDF creator 1.2 (with Aurota 5.0a2)the header are selectable.
You need to log in before you can comment on or make changes to this bug.