Meant to say "I bisected *it* to r572930."

I noticed the existence of FontServiceApp::MatchFontWithFallback(), which looks like it exists for PPAPI to call into. Except it does not seem to have any callers. This may be related to the next thing below.

As noted in [1], PDFium will squish "Arial Unicode MS" down to "ArialUnicodeMS" before calling MapFont(). The old code that existed in content/browser/renderer_host/font_utils_linux.cc handled that just fine, but FontServiceApp::MatchFamilyName() does not.

[1] https://pdfium-review.googlesource.com/c/pdfium/+/33130#message-50a27cda413de58b979483f7bc4726943f5efcfc

I have a work in progress fix in 
https://chromium-review.googlesource.com/c/chromium/src/+/1131936

r572930 moved the crucial content::MatchFontWithFallback to using Skia font matching. Skia font matching does not perform font fallback, if for example SimSun is not found and for this PDF, it seems its needed to find a font to display the Chinese characters. I thought this was okay, since on Windows the code in PepperFlashFontFileHost does not perform fallback at all.

Moving it to just calling font_service::MatchFontFaceWithFallback does not work, as this would call FontConfig inside the Sandbox. So, if we still want to invoke the fallback code, we need to call the out-of-process FontLoader::MatchFontWithFallback code.

I still need to figure out whether we need our own FontLoader object here or whether we can cast from the global SkFontMgr.

thestig@, could you test with this simpler CL?
https://chromium-review.googlesource.com/c/chromium/src/+/1131938

Is there a way we could unit test this issue?

The CL in comment 5 works for me.

Maybe we can try writing a test that calls pp::PDF::GetFontFileWithFallback() and pp::PDF::GetFontTableForPrivateFontFile(). Not sure how much work that is. We would also need to ask for a font that bots already have.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0dc678ffc0f0ab6ec43df45217c9d2b233ae8e3a

commit 0dc678ffc0f0ab6ec43df45217c9d2b233ae8e3a
Author: Dominik Röttsches <drott@chromium.org>
Date: Wed Jul 11 10:04:58 2018

Fix Mimehandler out-of-process FontConfig access

r572930 moved FontConfig out of process access from a global file
descriptor to Mojo messages. In one instance, PepperFlashFontFileHost,
an IPC performing FontConfig method was replaced with one that tries to
access FontConfig inside the sandboxed process, which fails. The
mimehandler process needs access to FontConfig as well for providing
fonts matching to PDFium.

This CL fixes mimehandler out of process font access and moves back to
using the MatchFontWithFallback FontConfig logic which was previously
used in this file, before it was moved to using Skia font matching like
on Windows. This implies that on Linux additional font fallback logic is
used again, which finds replacements for non-existing fonts such as
SimSun.

Bug:  862051 
Change-Id: I67136d51b45f72db0ae74201353369e34885f2ef
Reviewed-on: https://chromium-review.googlesource.com/1131938
Commit-Queue: Dominik Röttsches <drott@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574119}
[modify] https://crrev.com/0dc678ffc0f0ab6ec43df45217c9d2b233ae8e3a/chrome/renderer/BUILD.gn
[modify] https://crrev.com/0dc678ffc0f0ab6ec43df45217c9d2b233ae8e3a/chrome/renderer/pepper/DEPS
[modify] https://crrev.com/0dc678ffc0f0ab6ec43df45217c9d2b233ae8e3a/chrome/renderer/pepper/pepper_flash_font_file_host.cc
[modify] https://crrev.com/0dc678ffc0f0ab6ec43df45217c9d2b233ae8e3a/chrome/renderer/pepper/pepper_flash_font_file_host.h

Able to reproduce the issue on Ubuntu 17.10 on reported version 69.0.3484.0.

Verified the fix on Ubuntu 17.10, as per comment#0 on latest chrome version #69.0.3489.0.
Attaching screen shot for reference.
Observed that the PDF got displayed containing many Chinese characters. The title line on the top of the first page, above "Visa Application Form ..."  have 12 characters. 
Hence, the fix is working as expected.
Adding the verified labels.

Thanks...!!

Deleted: 862051.png 257 KB

	862051.png 257 KB View Download