Information printed onto a PDF isn't rendered in chrome
Reported by
cmcgo...@safeschools.com,
Feb 9 2018
|
||||||
Issue description
Chrome Version : 63.0.3239.132
OS Version: 10.0
URLs (if applicable) :
Other browsers tested: Firefox, IE/Edge
Add OK or FAIL after other browsers where you have tested this issue:
Firefox: OK
IE/Edge: OK
What steps will reproduce the problem?
1. Open attached files in Chrome
2. Observe that the forms are blank with no information printed on them.
3. Open the attached files in another browser or pdf viewer (I've tested Firefox, IE, Edge and Adobe Reader)
4. Observe that the information printed on to the pdfs does appear.
What is the expected result?
The pdfs should display correctly with the information that was printed on to the pdf itself appearing as it does with other browsers/pdf viewers.
What happens instead of that?
While the pdfs themselves render, the information that was printed on to them does not, leaving the forms to appear to be blank.
Please provide any additional information below. Attach a screenshot if
possible.
I'm not sure if this is the correct category for this bug but I couldn't seem to find a better one.
NOTE: the example1 pdf attached actually has a blank (as in just white) page for the second page, this isn't part of this bug (at least as far as I know), this is just a quirk of the underlying pdf.
The pdfs attached are generated by our application which uses the PDF::API2 perl package (link here: https://metacpan.org/pod/PDF::API2) to add text elements to a PDF provided by our customers. It then returns the pdf to the customer with the information printed onto the original pdf to act as an automatic paper form export for them. If they view the form in their browser (Chrome-only,) they're greeted with a blank form instead of the filled out one, but if they download and view the pdf in a pdf viewer (such as Adobe Reader) the information appears correctly.
Since the real pdf exports can (and do) contain sensitive information, I've made a couple of dummy exports with fake data in them. These should be identical to the regular exports with the exception of the sensitive information.
UserAgentString: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
,
Feb 13 2018
,
Mar 6 2018
Hmm, nobody has triaged the bug. :\ The attached examples is a bit complicated with many objects inside. Is there a simpler PDF that you can run through the PDF::API2 perl code that still results in output that hits this bug? e.g. If you start with a blank PDF, what happens? One interesting thing - I tried uncompressing example1.pdf with pdftk. The uncompressed output is actually readable in the Chrome PDF Viewer.
,
Mar 6 2018
Able to reproduce locally on Linux.
,
Mar 6 2018
An update to this from our end. We were able to sidestep this problem by running the source pdf through ghostscript's ps2pdf engine (version 9.10 Ubuntu 14.04). That leads me to believe that the issue may have been related to a malformed PDF rather than a true bug in Chrome's PDF viewer. Hope that helps
,
Mar 6 2018
Well, other PDF viewers can display the text, so I feel like Chrome's PDF viewer should too. Would you be able to come up with a simpler test case, as suggested in comment 3. You'll need to temporarily undo the workaround.
,
Mar 7 2018
Tested 6 months back and it was already broken. Considering this a non-regression.
,
Jul 3
Need to go back further. Bisecting says https://chromium.googlesource.com/chromium/src/+log/0295776a..acc35690, so something in r365200 broke this. See https://pdfium.googlesource.com/pdfium.git/+log/ebc7695..1407c97 for the PDFium changelog.
,
Jul 3
This is due to https://pdfium.googlesource.com/pdfium.git/+/4ea4459e
,
Jul 11
,
Jul 11
The following revision refers to this bug: https://pdfium.googlesource.com/pdfium/+/e7e454da8e382513b9e271bb3e0be3bd901bfbd9 commit e7e454da8e382513b9e271bb3e0be3bd901bfbd9 Author: Artem Strygin <art-snake@yandex-team.ru> Date: Wed Jul 11 13:43:52 2018 Do not store cross ref v5 obj within document. Currently, not necessary to store the cross ref v5 obj within CPDF_IndirectObjectHolder(CPDF_Document), because all necessary data from the cross ref are parsed or cloned, and owned by CPDF_Parser seperately from CPDF_IndirectObjectHolder. Also this fix regression from commit 4ea4459e. BUG= chromium:810768 Change-Id: I0d1a11ff027210f4f15804a69d12416838ec9815 Reviewed-on: https://pdfium-review.googlesource.com/37110 Reviewed-by: Lei Zhang <thestig@chromium.org> Commit-Queue: Art Snake <art-snake@yandex-team.ru> [modify] https://crrev.com/e7e454da8e382513b9e271bb3e0be3bd901bfbd9/core/fpdfapi/parser/cpdf_parser.cpp
,
Jul 11
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/46629048c53ced6353eb92800761deb10a20ffbc commit 46629048c53ced6353eb92800761deb10a20ffbc Author: pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Date: Wed Jul 11 16:40:58 2018 Roll src/third_party/pdfium b1a4db5551ca..e7e454da8e38 (3 commits) https://pdfium.googlesource.com/pdfium.git/+log/b1a4db5551ca..e7e454da8e38 git log b1a4db5551ca..e7e454da8e38 --date=short --no-merges --format='%ad %ae %s' 2018-07-11 art-snake@yandex-team.ru Do not store cross ref v5 obj within document. 2018-07-11 vmiklos@collabora.co.uk Add FPDFFormObj_CountObjects() API 2018-07-11 thestig@chromium.org Check GetObjDefnID() in various JS functions. Created with: gclient setdep -r src/third_party/pdfium@e7e454da8e38 The AutoRoll server is located here: https://pdfium-roll.skia.org Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, please contact the current sheriff, who should be CC'd on the roll, and stop the roller if necessary. BUG= chromium:810768 , chromium:862059 TBR=dsinclair@chromium.org Change-Id: I5cdecfe75e8069f179eca07f9eb873cfa875c756 Reviewed-on: https://chromium-review.googlesource.com/1133338 Reviewed-by: pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Commit-Queue: pdfium-chromium-autoroll <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#574190} [modify] https://crrev.com/46629048c53ced6353eb92800761deb10a20ffbc/DEPS
,
Jul 11
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by krajshree@chromium.org
, Feb 11 2018Labels: Needs-Triage-M63