Japanese PDFs garbled |
|||||
Issue descriptionChrome Version: 68.0.3440.106 (Official Build) (64-bit) OS: Linux (Debian) What steps will reproduce the problem? (1) Open a statement from Shinsei Bank (a Japanese bank). What is the expected result? The PDF is readable. What happens instead? It's not. What has happened is that all of my old statements which opened fine in chrome, no longer open fine. So it's not a change on Shinsei's end. I don't know what version of chrome last worked OK, probably something around May or June 2018. I also don't want to give you one of my bank statements... I will try bisect when I get a chance.
,
Sep 4
,
Sep 4
Do the statements contain multiple pages, where one of the page is (a) affected by this bug and (b) contains little / no personal info? If yes, we can try generating a PDF from the original with only that one page. Then you may be more comfortable sharing that and we can help bisect.
,
Sep 5
I've narrowed it down to 549813 good 549820 bad So I assume that it's commit ff4cbba00a2f6f40c62e3c64526e860d995cd2e1 Author: pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com <pdfium-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com> Date: Wed Apr 11 08:08:14 2018 +0000 Roll src/third_party/pdfium/ 4027887ee..6bebd2e3c (10 commits) https://pdfium.googlesource.com/pdfium.git/+log/4027887ee29a..6bebd2e3cfb7 $ git log 4027887ee..6bebd2e3c --date=short --no-merges --format='%ad %ae %s' 2018-04-11 hnakashima Avoid stack overflow when loading CPDF_Function. 2018-04-10 thestig Add static_asserts for FX_RECT and FX_COLORREF. 2018-04-10 thestig Load CIDToGIDMap stream for CID fonts if it exists. 2018-04-10 rharrison Roll DEPS for Clang and build 2018-04-10 rharrison Add an assert to make sure all code is included in static lib 2018-04-10 thestig Remove CFX_Rect. 2018-04-10 thestig Change CFX_RenderDevice::FillRect() to take FX_RECT by const-ref. 2018-04-10 thestig Change FillRectWithBlend methods to take FX_RECT by const-ref. 2018-04-10 hnakashima Implement CPDFSDK_XFAWidgetHandler::OnKillFocus. 2018-04-10 hnakashima Break down CXFA_FFWidget::On{L|R}ButtonDown() into two steps. I can pull out the first page of the file which I'd be happy to share with 1 or 2 Googlers, please give me usernames. BTW, I expect you will find that this file is out of spec. It doesn't open in anything except chrome. I'm guessing some jp-charset encoding related badness.
,
Sep 5
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 5
Based on the blame list, me and possibly npm if interested. The prior CJK bugs are bug 813705 and bug 781785 .
,
Sep 5
I've shared page 1 with yourself and npm. Thanks.
,
Sep 6
The culprit should be https://pdfium.googlesource.com/pdfium.git/+/cd7b4ab7519c31a27c8d31e0cb694257fea84fd1 but that fixes another broken PDF. The PDFs are broken because CIDToGIDMap should not exist if the font is embedded. From the point of view of the fix I linked, it looks like this PDF wants its stream to be ignored, the one in the other bug wants its stream to be used... That said, Adobe handles both PDFs fine.
,
Sep 6
*The CIDToGIDMap should not exist if the font is NOT embedded.
,
Sep 6
I haven't had time to look yet. I wonder if there are other factors that we have not considered, or if Acrobat somehow figures this out with heuristics. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by hnakashima@chromium.org
, Sep 4Owner: fergal@google.com
Status: Unconfirmed (was: Untriaged)