[ios, macos] Updates documentation to describe font fallback on iOS 8

[akitchen]

Also updates the font to use for rendering CJK ideographs in our sample
apps to PingFang TC, as simply specifying PingFang was always
triggering iOS's font fallback behavior.

[Fixes #10675]

[friedbunny]

A couple questions:

• Can we further clarify the fallback behavior for CJK, being that Helvetica doesn’t contain those glyphs?
• What happens when a Traditional Chinese font is explicitly specified (e.g., PingFang TC) but Simplified Chinese or Japanese kanji or Korean hanja glyphs should be rendered?

[akitchen]

Can we further clarify the fallback behavior for CJK, being that Helvetica doesn’t contain those glyphs?

It's a good point... Helvetica contains a small subset of the glyphs, but its total glyph count is somewhere near 1/50 that of PingFang (and Heiti has another ~5k on top of that). For now I can amend this text to be more clear in calling out this shortfall.

I did a spot-check of a handful of POIs in China, and the fallback choice of Helvetica did result in successful rendering of place names for the cases I checked. However, I'm not literate in the language and therefore can't comment on whether Helvetica is good enough for the purposes of rendering a comprehensive map with client-side drawing of CJK glyphs. It's reasonable to assume it might not be.

We could also consider implementing our own fallback mechanism, for example if the font isn't found then fall back to using Heiti (and attempt to divine the appropriate specialization of TC, SC or HK). Further research & work might be needed in order to ensure this potential "gold plating" is actually worth it. We should work with someone with reasonable literacy in these languages in order to make an informed decision. (cc @lilykaiser )

What happens when a Traditional Chinese font is explicitly specified (e.g., PingFang TC) but Simplified Chinese or Japanese kanji or Korean hanja glyphs should be rendered?

Of course I could be wrong, but I think about this as a design and localization issue to be handled by the app developer. I think you're pointing out that we might not have enough configurability to cover all possible uses in one place at this point in time; of course we're looking to improve that iteratively following the initial release of this feature. For now, this is another potential limitation which we would want to vet by interviewing native speakers or people who are literate in the languages in question in order to better evaluate the pros & cons of these approaches.

[1ec5]

It's a good point... Helvetica contains a small subset of the glyphs, but its total glyph count is somewhere near 1/50 that of PingFang

Unless the version of Helvetica on iOS differs significantly from the version on macOS, this font doesn’t contain any CJK glyphs, only Latin, Cyrillic, and Greek, as seen in Font Book.

[akitchen]

Unless the version of Helvetica on iOS differs significantly from the version on macOS, this font doesn’t contain any CJK glyphs, only Latin, Cyrillic, and Greek, as seen in Font Book.

You're right, it doesn't. Font fallback was previous resolving to Helvetica, but I didn't trace the data flow far enough to see its final rendering decision.

I pushed a change which I think does a better job of clarifying the configuration option in the Info.plist documentation. Developers will still want to choose the most appropriate font for their application, depending on their target market (source)

[friedbunny]

Looks like this needs to be rebased so it can run linux-clang-3.8-libcxx-debug on CI.