npm@ would you be able to take a look and see what's happening?

In the PDF, the fonts mentioned are not embedded, so it's up to the PDF viewer to do best effort font substitution. Thus there is no guarantee the PDF will display correctly. e.g. What happens if the OS does not have Japanese fonts? The software that generated the PDF should embed those fonts. That said, it looks like we have room for improvement with font substitution on Windows.

- On Windows, I see this problem even though I have several fonts with "Gothic" in the name.
- On Mac, the PDF displays, though the font used is different from the one Preview.app picked.
- On Linux machine, the PDF displays correctly. (I have Japanese fonts installed.)
- On ChromeOS it displays correctly.

I got a fix (although I need to check it doesn't break other stuff). Question for bug reporter: is it OK to add that PDF to our (open-source) testing/corpus directory?

@thestig I've advised the customer to use PDF/A-1a (ISO 19005-1)
@npm I've asked the customer the authorization

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium/+/979e916fde750e47f262c59dc75f4ca2dc19ed39

commit 979e916fde750e47f262c59dc75f4ca2dc19ed39
Author: Nicolas Pena <npm@chromium.org>
Date: Tue Nov 07 16:32:20 2017

Remove m_bFlagExact from CFX_SubstFont

This CL removes the single use case from |m_bFlagExact|. This flag
allows the PDF viewer to treat a substitute font with a matching name as
if it was actually an embedded font, which is wrong. For all substitute
fonts, it is important to follow the longer process of first obtaining
the unicode from the charcode to then obtain the glyph in the substitute
font that corresponds to that unicode.

Bug:  chromium:781785 
Change-Id: Ie5958b43914e0e46334b89b7c2c55c02d0da0c11
Reviewed-on: https://pdfium-review.googlesource.com/17859
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Nicolás Peña Moreno <npm@chromium.org>

[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/xfa/fgas/font/cfgas_fontmgr.cpp
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fxge/cfx_substfont.h
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fxge/cfx_font.cpp
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fxge/cfx_folderfontinfo.cpp
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fxge/apple/fx_mac_imp.cpp
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fxge/ifx_systemfontinfo.h
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/public/fpdf_sysfontinfo.h
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fxge/fx_ge_linux.cpp
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fxge/win32/fx_win32_device.cpp
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fxge/cfx_fontmapper.cpp
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fxge/android/cfx_androidfontinfo.cpp
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fpdfapi/font/cpdf_cidfont.cpp
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fxge/cfx_folderfontinfo.h
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/fpdfsdk/fpdf_sysfontinfo.cpp
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fxge/android/cfx_androidfontinfo.h
[modify] https://crrev.com/979e916fde750e47f262c59dc75f4ca2dc19ed39/core/fxge/cfx_substfont.cpp

Looks fixed to me in Canary. Test pending

marcore: Did we ever get authorization from the customer, per comment 5?

@thestig no sorry, as far as I can understand using google translate from Japanese, Tier1 never asked :-(
so we can't use the file.

OK. I'll try to handcraft a test case then.