Invoice PDF drops non-western characters

[fumikito]

Describe the bug

WordCamp tickets provides invoice features, but the characters input in form fields disappear in Invoice PDF

To reproduce

Steps to reproduce the behavior:

1. Buy ticket in WordCamp.
2. Click on 'I need an invoice'
3. Enter name and address in form fields with Japanese characters.
4. The PDF attached to email has no Japanese characters.

Expected behavior

• Japanese(and maybe non-western characters) will display.
• Or else, display instructions that indicates available characters.

In my opinion, this is because of fonts installed in OS of the web server(FPDF way) or client(Node & headless chrome way).
This is a typical "the abyss of internationalization", so latter approach is reasonable.
Installing bunch of fonts is not reasonable. Only single Japanese font file is more than 5MB, it may be bigger than all western fonts. There are also Chinese, Korean, and so on.

Screenshots / Screencasts

Attached above.

WordCamp

Maybe all WordCamp sites.

System (please complete the following information)

This doesn't depend on client side.

Security Issues

To report a security issue, please visit the WordPress HackerOne program: https://hackerone.com/wordpress.

[fumikito]

For copy and paste. here are east-asian address which may be disappear.

Japanese

東京都新宿区西新宿2丁目8-1
タワーハイツ203号室

Chinese(simplified)

北京市朝阳区光华路1号
国际大厦A座808室

Chinese(Traditional)

臺北市信義區松智路100號
世界大樓10樓1003室

Korean

서울특별시 강남구 테헤란로 123
강남타워 15층 1502호

[dd32]

At present we're loading Open Sans webfont, however, that doesn't support all languages, to quote Google AI:

Supported
Latin: English, French, German, Spanish, Italian, Portuguese, Dutch, and other Latin-based languages with standard characters.
Greek: All Greek alphabets.
Cyrillic: All Cyrillic alphabets.
Hebrew: Supports Hebrew characters.

Unsupported: Chinese, Japanese, Korean, and other languages:

Noto Sans SC is suggested as a solution for those character sets. That doesn't seem to support Korean though, so Noto Sans KR is also needed.

Since these are webfonts, they should only be loaded when needed and there's a matching character, so I think just adding them as done in #1552 will resolve this.