Japanese PDF rendered as Latin and Arabic |
|||||
Issue descriptionChrome Version: 59.0.3049.0 OS: Win10 What steps will reproduce the problem? (1) Open attached PDF (2) Japanese text rendered as Latin and Arabic What is the expected result? Japanese text rendered. Other PDF viewers are fine. Note, this is a manual PDF downloaded from SONY http://www.sony.jp/ServiceArea/impdf/sc-smc-mc-8652.html
,
Mar 27 2017
It does work on 56.0.2924.87 and 57.0.2987.110, sorry for the lack of the information.
,
Mar 27 2017
Thanks. I will bisect.
,
Mar 27 2017
,
Mar 27 2017
,
Mar 27 2017
BTW, this doesn't repro on Linux at all.
,
Mar 29 2017
I can't repro on Win 7 or Linux with pdfium_test. I'm building Chromium on each to see if I can repro there. If anyone has access to a Win 10 machine, could you see if pdfium_test built against skiapaths renders this PDF correctly?
,
Mar 29 2017
Same result as #1 on Linux -- w/ and w/o skiapaths, chrome print preview works fine.
,
Mar 29 2017
Issue 706410 has been merged into this issue.
,
Mar 29 2017
Confirmed 59.0.3055.0 is fine on the same PC. Thank you for the fix.
,
Mar 31 2017
Chrome is building pdfium using chrome's skia BUILD.gn, which does not include some files in pdfium's BUILD.gn, notably SkFontMgr_custom.cpp. PDFium talks directly to FreeType to get the font glyphs from the character code points, but then calls Skia to draw the text. When Skia is built for Chrome, it uses Windows instead of FreeType; the Windows font manager interface is unable to map the font. When PDFium is built natively, Skia uses FreeType everywhere to match PDFium's use of FreeType. Either: - PDFium on Chrome needs to use a different Skia library, or - Skia needs a runtime switch to choose the correct Font Manager, or - PDFium needs to use Windows instead of FreeType to generate fonts and metrics Investigating.
,
Apr 3 2017
Note that SkFontMgr_custom.cpp was just recently added to Chromium's Windows build.
,
Apr 3 2017
Re #12: Great! What needs to be done to PDFium within Chromium to fix this?
,
Apr 3 2017
I think all you need is for PDFium to use SkFontMgr_New_Custom_Empty to create the font manager and then use that to create the SkTypeface. Note that such SkTypefaces will actually be drawn by FreeType. I'm not sure what will happen to these fonts when we actually go to print; if Windows doesn't support the font format for some reason it seems the font may need to be printed as outlines or bitmaps. So if we fix the display side we should also check the actual print side.
,
Apr 5 2017
,
Apr 17 2017
Fixed in https://pdfium-review.googlesource.com/4058 and https://pdfium-review.googlesource.com/3771 |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by thestig@chromium.org
, Mar 27 2017