GNOME Bugzilla – Bug 739723
evince print only blank page in landscape / okular work with the same pdf
Last modified: 2015-04-17 05:18:24 UTC
Created attachment 290092 [details] Impossible to print this PDF with Evince evince 3.14.1-1 (Debian Jessie): Attached a PDF which print only a blank page with evince/jessie. Same PDF work fine with okular, the printout is as expected. [work] lp -d PRINTER /tmp/pdf_print_evince_fail.pdf [work] okular [work] qpdfview [fail] evince See also Debian Bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768133
I have the same problem.... Referenced in: https://bbs.archlinux.org/viewtopic.php?pid=1467972 Entire PDF prints blank... Same file prints fine with: lp -d DCP7065DN CrutchfieldMasterSheet-0000120150.pdf Let me know what else you may need. I can send the pdf but do not wish to attached it because crutchfield makes you pay for it. I will email it to someone who wants to test.
Forgot: archlinux rolling x64 updated last week.... pacman -Q evince evince 3.14.1-2
Thanks for confirm this on your system. I hope someone of the gnome/evince people have a eye on this bugreport, since I can not do more to track the issue down.
poppler and cairo versions? Can you print to a pdf and still have the same issues?
You mean print to file -> pdf? Work as expected, the PDF is ok. ii libpoppler-glib8:amd64 0.26.5-2 amd64 PDF rendering library (GLib-based shared library) ii libpoppler-qt5-1:amd64 0.26.5-2 amd64 PDF rendering library (Qt 5 based shared library) ii libpoppler46:amd64 0.26.5-2 amd64 PDF rendering library ii poppler-data 0.4.7-1 all encoding data for the poppler PDF rendering library ii poppler-utils 0.26.5-2 amd64 PDF utilities (based on Poppler) ii libcairo-gobject2:amd64 1.14.0-2.1 amd64 Cairo 2D vector graphics library (GObject library) ii libcairo-perl 1.104-2 amd64 Perl interface to the Cairo graphics library ii libcairo2:amd64 1.14.0-2.1 amd64 Cairo 2D vector graphics library ii libcairomm-1.0-1 1.10.0-1.1 amd64 C++ wrappers for Cairo (shared libraries) ii libgoocanvas3 0.15-1.1 amd64 canvas widget for GTK+ that uses the cairo 2D library ii libmono-cairo4.0-cil 3.2.8+dfsg-7 all Mono Cairo library (for CLI 4.0) ii libpangocairo-1.0-0:amd64 1.36.8-2 amd64 Layout and rendering of internationalized text ii libpixman-1-0:amd64 0.32.6-3 amd64 pixel-manipulation library for X and cairo ii python-cairo 1.8.8-1+b2 amd64 Python bindings for the Cairo vector graphics library ii python3-cairo 1.10.0+dfsg-4+b1 amd64 Python 3 bindings for the Cairo vector graphics library ii python3-gi-cairo 3.14.0-1 amd64 Python 3 Cairo bindings for the GObject library
José can you confirm this issue? If not, what can be the problem? poppler or cairo?
no, i can't confirm the issue. Usually, when a printing problem occurs, it is becaue we regenerate the pdf when printing it (either convert it to ps or to pdf again depending on the printer). Thus, many of the pringint errors are usually bugs in poppler or in cairo when we are regenerating this pdf... but usually they get to be seen when you use the Save to pdf feature (i'ts like you generate the pdf and then instead of sending it to the printing, you send it to the file)... Hope I clarify the workflow of a file when it is being printed... So I actually don't know why is this happening, the only thing is to try to get the same versions as you are having. I haven't tried real pringint of the file. Does it happen on every printer?
José thank you for reply. * Print direct to PDF works fine. * Print to a _real_ printer results in a blank page, no difference which printer I test (Konica Minolta, HP LaserJet, Brother). I work with up-tp-date Debian (Jessie) testing which show this issue.
could you try one more thing: print to a pdf file from Evince, and then print the generated pdf file to a printer using lpd. Normally the pdf file generated should be the same pdf we send to the printer via cups.. So if this fails, means the pdf is good enough to be seen on screen but not good enough for the printer to print it.
Created attachment 290539 [details] [review] centered scaled printing, take 2 This seems to be caused by the fix of #734788. This patch fixes the problem for me.
... no it doesn't. Printing is hard.
:( anyway, thanks for all the testing.
I print from evince to a pdf file and print this new PDF on a real printer, same result, blank page. The file has changed, check it with the md5sum: 2e2a7c73e9a92223e49be78c46a73133 pdf_print_evince_fail.pdf afe2c915424cd1771babdb61ba74f57c pdf_print_evince_fail-Evince-to-PDF-File.pdf
Created attachment 290617 [details] Evince -> File-PDF
To clarify: You should still be able to print landscape documents if "auto rotate and center" (in the third tab of the print dialog) is unchecked.
Yes, confirm, uncheck "auto rotate and center" work. That means this is a evince bug. Unfortunately "auto rotate and center" is checked automatically, no option for my users and the daily work. And now?
Created attachment 290708 [details] [review] centered printing, ignore scaling This should fix centered printing for documents printed at 100%. Centering of scaled documents is still a mess; the dimensions returned by ev_print_operation_print_get_scaled_page_size don't make sense to me.
Created attachment 290722 [details] [review] now with scaling Alright, this should do the right thing for scaling. If autorotate+center is off, the (possibly scaled) document will appear in the to left corner for every paper orientation. If "fit to printable area" is selected, a user-specified scale does nothing; if "shrink to printable area" is selected, shrinking will occur if necessary. I'm sure there are other, nicer ways of achieving this, but hey, at least this works, which can't be said about ae7a5715131613955a37419b5da1d6d9f3c1cb1d.
This patch is against evince 3.14.1? I can patch it against the Debian 8 / Jessie Evince [1] .deb an rebuild it? [1] https://packages.debian.org/jessie/evince
(In reply to comment #19) > I can patch it against the Debian 8 / Jessie Evince [1] .deb an rebuild it? Yup, that should work.
@ José, this is not fixed in Gnome 3.14.2 [1]? [1] https://mail.gnome.org/archives/devel-announce-list/2014-November/msg00001.html
The problem is that GTK+ is giving us a different transformation matrix depending on the print backend. Only when printing to a PDF file with the file backend, we get an unrotated matrix, and the surface has the width and height switched when printing landscape. When using the cups backend, we get a matrix rotated even when the surface type is PDF and the width and height have been switched. So, I wonder if the GTK+ cups backend should set the GtkPrintJob rotate_to_orientation to TRUE/FALSE depending on whether the printer accepts PDF or not, like the file backend does (that would fix this problem, not sure it has other side effects, though). Adrian, Marek, what do you guys think? You can see the differences also with gedit, for example: 1.- Open gedit and write someting 2.- Print to a pdf file in landscape at 50% Text is placed left aligned 3.- Print to a real printer (or CUPS-PDF) with the same settings Text is placed right aligned I'm not sure that's the expected behaviour, I would expect both outputs to be the same.
Created attachment 291300 [details] [review] GTK+ patch This would be the GTK+ patch, I'm not reassigning yet, since I'm still not sure if it's GTK+ issue or not
Same thing for PDF or PS/SVG in the file backend. If manual_number_up > 1 though, both PDF and PS output seem to have the correct origin. (this is done by common_render_page(…) in gtkprintoperation.c, right?) if (priv->manual_orientation) _gtk_print_context_rotate_according_to_orientation (print_context); else _gtk_print_context_reverse_according_to_orientation (print_context); Really should happen on the unscaled context, and not /after/ if (priv->manual_scale != 1.0 && priv->manual_number_up <= 1) cairo_scale (cr, priv->manual_scale, priv->manual_scale);
Created attachment 291307 [details] [review] gtk patch to translate before scaling the context Yup, this patch to gtk/gtkprintoperation.c seems to do the trick.
Created attachment 291310 [details] [review] gtk patch to translate before scaling the context, take 2 Mmm, of course _gtk_print_context_translate_into_margin should happen before cairo_scale as well.
Created attachment 291316 [details] [review] centered scaled printing, take 4 With the above GTK patch, the origin of the print context should be correct in all cases. The context is still scaled though, so manual_scale needs to be taken into account when centering. (→ "cairo_translate (cr, x_offset/manual_scale, y_offset/manual_scale);")
Created attachment 291459 [details] Test landscape PDF (In reply to comment #22) > The problem is that GTK+ is giving us a different transformation matrix > depending on the print backend. Only when printing to a PDF file with the file > backend, we get an unrotated matrix, and the surface has the width and height > switched when printing landscape. When using the cups backend, we get a matrix > rotated even when the surface type is PDF and the width and height have been > switched. So, I wonder if the GTK+ cups backend should set the GtkPrintJob > rotate_to_orientation to TRUE/FALSE depending on whether the printer accepts > PDF or not, like the file backend does (that would fix this problem, not sure > it has other side effects, though). Adrian, Marek, what do you guys think? You > can see the differences also with gedit, for example: > > 1.- Open gedit and write someting > 2.- Print to a pdf file in landscape at 50% > Text is placed left aligned > 3.- Print to a real printer (or CUPS-PDF) with the same settings > Text is placed right aligned > > I'm not sure that's the expected behaviour, I would expect both outputs to be > the same. I'm looking at this problem right now. I've tried to print the attached PDF file to file and the output is corrupted when printing to PostScript with the "print-operation: Fix centering of documents when printing with a manual scale" patch applied.
Yes, with said patch applied, cairo_device_to_user (cr, &x_offset, &y_offset) shifts the pdf outside the paper and switches the x- and y-coordinates. This is not the correct thing to do, because at this point the user coordinates are already scaled, rotated and translated (wrongly, I believe, see my GTK+ patch above).
Hi, I've just performed several tests and I see now that part of the problem is really on Gtk+ side. The scale should be performed after those positional translations. Thank you for pointing me there. The Leo's evince patch fixes the problem on the evince's side for me. I'll perform some other tests tomorrow + will file a bug for it.
I've filed the bug for Gtk+ here: https://bugzilla.gnome.org/show_bug.cgi?id=740742.
This bug report is fixed with patch from https://bugzilla.gnome.org/show_bug.cgi?id=740742 true?
(In reply to comment #32) > This bug report is fixed with patch from > https://bugzilla.gnome.org/show_bug.cgi?id=740742 > true? No, you need the patch from comment #27 applied + the fixed gtk+ to have this bug fixed.
*** Bug 740878 has been marked as a duplicate of this bug. ***
Review of attachment 291316 [details] [review]: Thanks for the patch. My main concern is that this requires the GTK+ changes, so this will break portrait printing (landscape was already broken) with older GTK+ versions. So, we should either add ifdefs to do different things depending on the GTK+ version or bump the GTK+ requirements. ::: libview/ev-print-operation.c @@ -1880,3 @@ cr_width = gtk_print_context_get_width (context); cr_height = gtk_print_context_get_height (context); - ev_print_operation_print_get_scaled_page_size (print, page, &width, &height); Why removing the helper function? if you need the manual_scale, we can return it also as an out parameter. @@ +1878,3 @@ + x_offset = (cr_width - width) / 2; + y_offset = (cr_height - height) / 2; + cairo_translate (cr, x_offset/manual_scale, y_offset/manual_scale); We could do: x_offset = (cr_width - width) / (2 * manual_scale); y_offset = (cr_height - height) / (2 * manual_scale); And then translate to x_offset, y_offset @@ +1895,3 @@ x_offset = (cr_width - scale * width) / 2; y_offset = (cr_height - scale * height) / 2; + cairo_translate (cr, x_offset/manual_scale, y_offset/manual_scale); Ditto. @@ -1922,3 @@ - - if (y_offset < bottom) - cairo_translate (cr, 0, -(bottom - y_offset)); Why did you remove all this? @@ +1898,2 @@ } else { + cairo_translate (cr, left/manual_scale, top/manual_scale); Do we really need to apply the manual scale to the margins?
Created attachment 291795 [details] [review] centered scaled printing, take 5 (In reply to comment #35) > Review of attachment 291316 [details] [review]: > > Thanks for the patch. My main concern is that this requires the GTK+ changes, > so this will break portrait printing (landscape was already broken) with older > GTK+ versions. So, we should either add ifdefs to do different things depending > on the GTK+ version or bump the GTK+ requirements. Portrait isn't affected at all by the GTK+ changes. Only every other orientation (there is no translation in _gtk_print_context_{rotate,reverse}_according_to_orientation in the portrait case). Unscaled landscape documents will also print just fine. This, less invasive, patch keeps the helper function and wraps the whole centering part between cairo_scale (cr, 1/manual_scale, 1/manual_scale); and cairo_scale (cr, manual_scale, manual_scale);. > ::: libview/ev-print-operation.c > @@ -1922,3 @@ > - > - if (y_offset < bottom) > - cairo_translate (cr, 0, -(bottom - y_offset)); > > Why did you remove all this? Oh, I forgot to put that back. But, on that note, wouldn't it make more sense to enforce the centering with something like x_scale = (cr_width - 2 * ((left > right) ? left : right)) / width; ? > @@ +1898,2 @@ > } else { > + cairo_translate (cr, left/manual_scale, top/manual_scale); > > Do we really need to apply the manual scale to the margins? Yes, those are meant to be in "paper-units" as well.
Created attachment 291796 [details] [review] centered scaled printing, take 5 Sorry, that GtkPageSetup *pagesetup wasn't meant to be there.
(In reply to comment #36) > Created an attachment (id=291795) [details] [review] > centered scaled printing, take 5 > > (In reply to comment #35) > > Review of attachment 291316 [details] [review] [details]: > > > > Thanks for the patch. My main concern is that this requires the GTK+ changes, > > so this will break portrait printing (landscape was already broken) with older > > GTK+ versions. So, we should either add ifdefs to do different things depending > > on the GTK+ version or bump the GTK+ requirements. > > Portrait isn't affected at all by the GTK+ changes. Only every other > orientation (there is no translation in > _gtk_print_context_{rotate,reverse}_according_to_orientation in the portrait > case). Unscaled landscape documents will also print just fine. > There's no translation, but there's scale. That's the reason why I added the cairo_device_to_user(), that patch was to fix centering in scaled documents (it was not to break things, even if I ended up breaking landscape printing). > This, less invasive, patch keeps the helper function and wraps the whole > centering part between cairo_scale (cr, 1/manual_scale, 1/manual_scale); and > cairo_scale (cr, manual_scale, manual_scale);. Why? is that better than / (2 * manual_scale) ? > > ::: libview/ev-print-operation.c > > @@ -1922,3 @@ > > - > > - if (y_offset < bottom) > > - cairo_translate (cr, 0, -(bottom - y_offset)); > > > > Why did you remove all this? > > Oh, I forgot to put that back. But, on that note, wouldn't it make more sense > to enforce the centering with something like x_scale = (cr_width - 2 * ((left > > right) ? left : right)) / width; ? > > > @@ +1898,2 @@ > > } else { > > + cairo_translate (cr, left/manual_scale, top/manual_scale); > > > > Do we really need to apply the manual scale to the margins? > > Yes, those are meant to be in "paper-units" as well. Yes, but when not centering, we want to print at the top-left margin, no matter if the document is scaled or not
Well, if I understand the current situation correctly, drawing will instead start at (left*manual_scale,top*manual_scale) for the simple case of portrait, scale to fit, no autorotate¢er. (Because of the cairo_scale() in common_render_page()). > Why? is that better than / (2 * manual_scale) ? Better? Sure, it allows for marginally better notation; but in the end it's all about the same thing: reverting the scale applied by GTK+. And only the scale. Also: gtk_print_context_get_hard_margins() does NOT consider orientation (see e.g. https://bugzilla.gnome.org/show_bug.cgi?id=551356). A proper patch should fix this as well.
(In reply to comment #39) > Also: gtk_print_context_get_hard_margins() does NOT consider orientation (see > e.g. https://bugzilla.gnome.org/show_bug.cgi?id=551356). A proper patch should > fix this as well. We are working on this here: https://bugzilla.gnome.org/show_bug.cgi?id=671895.
(In reply to comment #23) > Created an attachment (id=291300) [details] [review] > GTK+ patch > > This would be the GTK+ patch, I'm not reassigning yet, since I'm still not sure > if it's GTK+ issue or not I agree that landscape pages should not be rotated for pdf output. It would be better if this was handled in printoperation instead of relying on each print backend to do the right thing.
Evince goes on printing blank pages... I have to use Xpdf witch prints but Xpdf cannot print A3 pages.
(In reply to comment #42) > Evince goes on printing blank pages... I have to use Xpdf witch prints but Xpdf > cannot print A3 pages. And Gimp witch uses GTK+ too prints A3 pages.
Downstream Fedora report: https://bugzilla.redhat.com/show_bug.cgi?id=1173832
(In reply to comment #44) > Downstream Fedora report: > https://bugzilla.redhat.com/show_bug.cgi?id=1173832 Evince prints blank pages in all cases not only on landscape pages.
Having a proper fix for this is taking more time than I expected, so I've just reverted the patch that introduced this regression in both branches until we find a proper solution in both Evince and GTK+. This is now fixed, use bug #734788 for new discussions or patches to the centering option when having a manual scale.
*** Bug 748017 has been marked as a duplicate of this bug. ***