When trying to print certain PDF documents (an example is [1]) I get completely broken print output. This can already be seen in the print preview [2]. Downgrading to cairo 1.10 fixes the problem. [1] http://www.comdirect.de/pbl/ePdfTracker.do?ePageId=cori2444 [2] http://people.debian.org/~biebl/evince.png
I can't reproduce the bug. What version of cairo and poppler are you using? Evince prints in pdf format. Can you print to a pdf file and attach the output. Or alternatively use pdftocairo to generate the pdf output.
(In reply to comment #1) > I can't reproduce the bug. What version of cairo and poppler are you using? evince: 3.4.0 poppler: 0.18.4 cairo: 1.12.2 > Evince prints in pdf format. Can you print to a pdf file and attach the output. > Or alternatively use pdftocairo to generate the pdf output. original pdf document attached and the one generated by evince using print-to-pdf
Created attachment 63485 [details] original PDF
Created attachment 63486 [details] print-to-file PDF
(In reply to comment #4) > Created attachment 63486 [details] > print-to-file PDF (In reply to comment #2) > (In reply to comment #1) > > I can't reproduce the bug. What version of cairo and poppler are you using? > > evince: 3.4.0 > poppler: 0.18.4 > cairo: 1.12.2 Just tested current head of the 1.12 branch (f228769) but still no luck. Downgrading to cairo 1.10 though fixes the problem reliably.
I have tested the pdf file with cairo 1.12.2 and poppler 0.18.4 on both 64-bit Ubuntu 12.04 and Debian Testing and still can not reproduce the bug. The only other option I can think of is to provide you with a patch containing some printfs that you can use to obtain some debug information that may help me find the cause.
(In reply to comment #6) > I have tested the pdf file with cairo 1.12.2 and poppler 0.18.4 on both 64-bit > Ubuntu 12.04 and Debian Testing and still can not reproduce the bug. Might be hardware/driver related, dunno. I'm using a Sandybridge laptop with xserver-xorg-video-intel 2.19.0 > The only other option I can think of is to provide you with a patch containing > some printfs that you can use to obtain some debug information that may help me > find the cause. Sure, I'm happy to test such a patch.
(In reply to comment #7) > (In reply to comment #6) > > I have tested the pdf file with cairo 1.12.2 and poppler 0.18.4 on both 64-bit > > Ubuntu 12.04 and Debian Testing and still can not reproduce the bug. > > Might be hardware/driver related, dunno. > > I'm using a Sandybridge laptop with > xserver-xorg-video-intel 2.19.0 > Hm, I can trivially reproduce the bug in a qemu VM with debian testing.
I can reproduce this (debian testing amd64). Here's what git bisect says: 6ed0c6224b763e9cbcfb0d46f188883d8425bab5 is the first bad commit commit 6ed0c6224b763e9cbcfb0d46f188883d8425bab5 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jul 29 13:03:59 2011 +0100 pdf: Remove redundant clip regions If the extents of the operation is wholly contained within the clip region, then we can safely not invoke any clipping. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> :040000 040000 42e4cbdf15d9d1a7a92da02d2fa291c68c6ea6b7 8bef42b00d2da3b1a14e895bb51a598335ba3972 M src I checked twice and it really does work before this commit. However, trying to revert this changes ontop of current master (by hand) didn't make this work again. Now someone please tell me how ignoring a clip can cause misplaced glyphs... In case it turns out that this wasn't the faulty commit: $ git bisect log git bisect start # bad: [9f52261dd7941ec7b338b050479da25c2571f9ac] xcb: Correctly handle a recording surface's extents git bisect bad 9f52261dd7941ec7b338b050479da25c2571f9ac # good: [4938e11ffe11781e4e294092807ebc67f362eac6] version: Bump for 1.10.2 release git bisect good 4938e11ffe11781e4e294092807ebc67f362eac6 # skip: [6b3d53646eb7aa3f13a0a6d133ec2ffcd1df8fdd] image: peek through a snapshot to the recording surface behind git bisect skip 6b3d53646eb7aa3f13a0a6d133ec2ffcd1df8fdd # good: [c0dc933efda7672b07e188a1195821340f911a66] xcb: Remove CAIRO_XCB_RENDER_HAS_COMPOSITE_SPANS git bisect good c0dc933efda7672b07e188a1195821340f911a66 # bad: [2209ec5a15f535b1fae19c84b796f3d11a12de00] test: Make cairo_test_suite depend upon the any2ppm exectuable on all platforms git bisect bad 2209ec5a15f535b1fae19c84b796f3d11a12de00 # bad: [6155348966b89a216d2e5ee0b4784507a0226a9f] default-context: Do not allow restoring pushed gstates git bisect bad 6155348966b89a216d2e5ee0b4784507a0226a9f # good: [e775db35d9306b74867f981a08d253562b15cffd] xcb: Move cairo_xcb_picture_t to cairo-xcb-private.h git bisect good e775db35d9306b74867f981a08d253562b15cffd # good: [04ef07ee3bdeab9b2b3d74547214c6735ebb27b3] clip: Embed a single box to avoid a common allocation git bisect good 04ef07ee3bdeab9b2b3d74547214c6735ebb27b3 # good: [aad2c3dd0f7a512e6d3db087bf94ab53e30e92ed] gl: Use cairo_rectangle_int_t git bisect good aad2c3dd0f7a512e6d3db087bf94ab53e30e92ed # skip: [74a86a76a9c32a74d63712b718c90669889820e6] clipper: Detect a incremental change in the general clip-path git bisect skip 74a86a76a9c32a74d63712b718c90669889820e6 # good: [89cb071d14f02f062d6960b9c49bced8212d032b] script: Initialize recording extents git bisect good 89cb071d14f02f062d6960b9c49bced8212d032b # skip: [7c6e1b8db89420fa69ebd8d2ba12dde1aeb47ea8] xcb: Short-circuit multiplying the alpha mask by 1.0 git bisect skip 7c6e1b8db89420fa69ebd8d2ba12dde1aeb47ea8 # bad: [d2ea8bd070f3bff87ec952af490093375cbc1f05] build: Respect CFLAGS and LIBS env settings git bisect bad d2ea8bd070f3bff87ec952af490093375cbc1f05 # skip: [4032c86127a5f1658c2bddbf1c642fb62e21a208] fallback: Prevent recursion when combining with the clip git bisect skip 4032c86127a5f1658c2bddbf1c642fb62e21a208 # bad: [0660f62fe5ffdd86eedf8262f3ac50fb039491c1] gl: Rectilinear fast path git bisect bad 0660f62fe5ffdd86eedf8262f3ac50fb039491c1 # skip: [2787ef4e73fe668edbb938aa82ab569789a39116] pattern: Complete the list of possible pattern errors git bisect skip 2787ef4e73fe668edbb938aa82ab569789a39116 # bad: [488c94220d46f10a0fa8fa4dfb1beda88d80988e] ps: Apply the clip reduction techniques from pdf git bisect bad 488c94220d46f10a0fa8fa4dfb1beda88d80988e # skip: [6ec24760b32da5ca1f0a67f6ff344b91f8bc020c] device: Flush on a finished device is a no-op git bisect skip 6ec24760b32da5ca1f0a67f6ff344b91f8bc020c # good: [29a302cc4bc7734129bca8fe242dc7ecb626895d] clipper: Also need to guard against the incoming clip being NULL git bisect good 29a302cc4bc7734129bca8fe242dc7ecb626895d # bad: [6ed0c6224b763e9cbcfb0d46f188883d8425bab5] pdf: Remove redundant clip regions git bisect bad 6ed0c6224b763e9cbcfb0d46f188883d8425bab5
Created attachment 63699 [details] [review] patch1 Here's a patch to print some debug information.
Created attachment 63710 [details] Output for Adrian's patch I applied the patch to current git master (64d65f72e), compiled cairo, downloaded girokonto_einzelantrag.pdf, opened the file in evince and did a print preview (Result: Broken output in the preview). The output from evince is attached.
Created attachment 63756 [details] [review] debug patch 2 The glyph widths are correctly extracted from the font. But for some reason the widths written to the broken pdf file are all zero as shown below. This patch prints some more debug info. 5 0 obj << /Type /Font /Subtype /Type1 /BaseFont /GQIBIR+Dax-Medium /FirstChar 32 /LastChar 252 /FontDescriptor 56 0 R /Encoding /WinAnsiEncoding /Widths [ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ] /ToUnicode 54 0 R >> endobj
Created attachment 63780 [details] Output of debug patch v2 (lots of 0 here and some (uint64_t)INT32_MAX)
Created attachment 63781 [details] Debug 3 patch Now that I had something to look for, I could do some debugging myself. fonts->units_per_em is set to this "evil value" in cairo-cff-subset.c:1142. See next attachment. @Adrian: What can we do to figure out what happened to the operand?
Created attachment 63782 [details] Output from debug 3 patch (wow, what a bad name...)
Created attachment 63787 [details] [review] patch4 The operand is in binary. I suspect the problem is in decode_real. This patch prints some info from decode_real.
Created attachment 63788 [details] Output from patch 4
The problem is in decode_real it converts a BCD string to ASCII than uses sscanf to convert to a double. The value it is trying to decode is "0.001". In locales where the decimal separator is not '.' this fails. I'll work on a patch to fix this.
Created attachment 63789 [details] [review] fix This patch should fix the bug.
Hi Adrian, (In reply to comment #19) > Created attachment 63789 [details] [review] [review] > fix > > This patch should fix the bug. I can confirm that this patch fixes the print output for this particular PDF. I do have other PDFs thought which still do not produce proper print output. Attached as original PDF 2 / print-to-file PDF 2. Note the broken DKB header (missing letters) in print-to-file PDF 2. Basically the same issue. Works perfectly with cairo 1.10 and regresses with 1.12. I'm not sure if you want to track this as a se
Sorry, hit send too early. (In reply to comment #20) > > I'm not sure if you want to track this as a se I'm not sure if you want to track this as a separate bug report or not.
Created attachment 63790 [details] original PDF 2
Created attachment 63791 [details] print-to-file PDF 2
The file at http://people.debian.org/~biebl/cairo/orig3.pdf crashes evince when trying to use the print preview or print-to-file. Again, works fine with cairo 1.10. This file exceeds the 3MB limit, so I didn't directly attach it to this bug report.
Created attachment 63792 [details] backtrace for evince crash when trying to pring orig3.pdf
(In reply to comment #25) > Created attachment 63792 [details] > backtrace for evince crash when trying to pring orig3.pdf This bug has already been fixed in master.
Fixes for orig.pdf and orig2.pdf have been committed.
*** Bug 51747 has been marked as a duplicate of this bug. ***
(In reply to comment #26) > (In reply to comment #25) > > Created attachment 63792 [details] > > backtrace for evince crash when trying to pring orig3.pdf > > This bug has already been fixed in master. Great. Can you point me to the relevant commit?
(In reply to comment #29) > (In reply to comment #26) > > (In reply to comment #25) > > > Created attachment 63792 [details] > > > backtrace for evince crash when trying to pring orig3.pdf > > > > This bug has already been fixed in master. > > Great. Can you point me to the relevant commit? btw, would it be possible to cherry-pick those fixes for the 1.12 branch and release a 1.12.4?
(In reply to comment #29) > (In reply to comment #26) > > (In reply to comment #25) > > > Created attachment 63792 [details] > > > backtrace for evince crash when trying to pring orig3.pdf > > > > This bug has already been fixed in master. > > Great. Can you point me to the relevant commit? http://cgit.freedesktop.org/cairo/commit/?id=2f1d6b27e8b78c77346a5b603114b54400e57d83
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.