Created attachment 321520 [details]
This bug report was sent to Apple Bug Reporter (#33333584) on on July 15, 2017 and was informed on July 24 that "Engineering has determined that your bug report is a duplicate of another issue and will be closed." However, this issue, till now, is still left unresolved and affects all applications on macOS and iOS that relies on the Safari 11 Webkit API when "-apple-system" is used in CSS font fallback.
These are new regressions found in macOS 10.13 and iOS 11 since Developer Beta 3 till GM Builds regarding how webkit handles the font weights of PingFang typeface. See "Steps to Reproduce" below.
The reason is that a virtually bolded CJK font looks extremely terrible, definitely disobeying what the font designers really want to see. I posted some attachments here for your reference.
Steps to Reproduce:
1. In occasions that the Safari (or any app that relies on the system built-in webkit) reads a western font with Bold weight, when the font falls back to PingFang, it shows virtually bolded font in lieu of what previously done (i.e. PingFang Semibold).
2. To cope with what I described above, I extracted all six PingFang Semibold files and made a doppelgänger set of them (renamed as PingFang bold) and tested this issue again. Now I found that only the wildcard font-fallback token "-apple-system" triggers this issue.
Either use PingFang Semibold (like what iOS and macOS previously did), OR ask DynaComware to make the real Bold (and possibly Heavy) weight(s) of this font family.
The virtually bolded PingFang family looks extremely terrible, definitely disobeying what the font designers really want to see. I posted some attachments here for your reference.
Safari 11.0-13604.1.28.2 and 11.0 (13604.1.38.1.6)
I feel that no one in Webkit team wants to solve this issue quickly, but I still have to post it here.
macOS 10.13 Developer Beta 3 * GM Build and iOS 11 Developer Beta 3 & GM Build, running on MacBook Late 2016 TouchBar model (13 inch) and iPhone 6s.
Created attachment 321521 [details]
(In reply to Alexey Proskuryakov from comment #2)
So someone reported this earlier than what I did, proving that there may be a reason why this issue is not wanted to be solved on time.
Created attachment 323618 [details]
Attachment 323618 [details] did not pass style-queue:
ERROR: Source/WebCore/ChangeLog:8: You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible. [changelog/nonewtests] 
Total errors found: 1 in 2 files
If any of these errors are false positives, please file a bug against check-webkit-style.
*** Bug 177683 has been marked as a duplicate of this bug. ***
Created attachment 323740 [details]
Comment on attachment 323740 [details]
Clearing flags on attachment: 323740
Committed r223589: <https://trac.webkit.org/changeset/223589>
All reviewed patches have been landed. Closing bug.
I see the Safari Developer Preview Release 42 (Safari 11.1, WebKit 13605.1.10) does not have this bug fixed. Will this be fixed in macOS 10.12.1 and the next major iOS release?
(In reply to Shiki Suen from comment #10)
> I see the Safari Developer Preview Release 42 (Safari 11.1, WebKit
> 13605.1.10) does not have this bug fixed.
I believe this fix landed after we branched for STP 42. You can check the revision range in the STP 42 release notes.
> Will this be fixed in macOS
> 10.12.1 and the next major iOS release?
Sorry, we can’t talk about the specifics of upcoming releases.
I think the test was checked into the wrong directory. Instead of putting it in LayoutTests/fast/text/system-ui-chinese-bold-fallback.html it was checked into fast/text/system-ui-chinese-bold-fallback.html
(In reply to Alex Christensen from comment #12)
> I think the test was checked into the wrong directory. Instead of putting
> it in LayoutTests/fast/text/system-ui-chinese-bold-fallback.html it was
> checked into fast/text/system-ui-chinese-bold-fallback.html
Fixed in r223901: <https://trac.webkit.org/changeset/223901>