Skip to content
This repository was archived by the owner on Aug 8, 2023. It is now read-only.
This repository was archived by the owner on Aug 8, 2023. It is now read-only.

PingFang font isn’t available on iOS 8 #10675

Closed

Description

@friedbunny

After #10522 and #10662, we hard-code the PingFang font and suggest its use — this will fail on iOS 8, because it wasn’t introduced until iOS 9 (alongside the SF system font).

For Chinese system fonts on iOS, Heiti SC/TC were the predecessors to PingFang SC/TC/HK.

/cc @ChrisLoer @akitchen

Activity

  1. ChrisLoer commented on Dec 12, 2017

    @ChrisLoer
    Contributor

    Happy to change the example in the comments to whatever we think is best, but I'm not sure Heiti is obviously better? In the case iOS can't load what you requested, it has font fallback behavior (full disclosure: I don't know how the fallback behavior works, I've just seen it while testing). So for instance I tried changing the "PingFang" test to the definitely-not-installed-on-my-system "HurgleBurgle" and it still renders a reasonable-looking result:

    actual

    There's no place other than that unit test where "PingFang" is hard coded.

    /cc @1ec5

  2. akitchen commented on Dec 12, 2017

    @akitchen
    Contributor

    I set breakpoints inside the core classes to spot-check the data flowing thru while working on the ObjC wrapper and saw iOS decide to use Helvetica when a bogus or non-existent font was specified. It could be worth doing this again for iOS 8 if we're worried about it, but I suspect it might just work ™

  3. 1ec5 commented on Dec 12, 2017

    @1ec5
    Contributor

    iOS does implement font fallback. I also wondered in #10522 (comment) whether PingFang also fell back to SF Text on newer systems, because the PostScript font names are actually PingFangHK, PingFangSC, and PingFangTC, not simply PingFang.

  4. friedbunny commented on Dec 12, 2017

    @friedbunny
    ContributorAuthor

    Hrm, so it sounds like it would be useful to better understand and then document the fallback behavior. This all makes me wonder if not specifying any font and allowing the system to choose wouldn’t produce a better result on iOS.

    For instance, if the developer specifies PingFang and we use it to render the entire CJK range, but the user is looking at Japanese text, this would result in a worse visual experience (because iOS has the Hiragino fonts for Japanese and PingFang does a poor job with non-Chinese characters).

    To @1ec5’s point, this is also a concern with simply PingFang — is it rendering Simplified, Traditional, or Hong Kong Chinese glyphs? I’m deeply unfamiliar with the Chinese unicode range(s), but it would be good to (re-)confirm that we’re showing the correct characters with the best typeface in each situation. This article indicates that some characters share the same code point but should be rendered differently at the font-level.

  5. akitchen commented on Dec 14, 2017

    @akitchen
    Contributor

    Where would be the most appropriate place to document this? In the Info.plist key documentation?

  6. friedbunny commented on Dec 15, 2017

    @friedbunny
    ContributorAuthor

    @akitchen Yeah, I suppose that’d be the only place iOS developers would end up seeing it.

  7. added 2 commits that reference this issue on Dec 16, 2017
    5be40de
    605c3d0
  8. added a commit that references this issue on Jan 2, 2018
    f207675
  9. added a commit that references this issue on Jan 2, 2018
    54c4b83
  10. added 2 commits that reference this issue on Jan 3, 2018
    80f40c5
    760ef23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugiOSMapbox Maps SDK for iOS

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions