Skip to content

iOS 13 - Setting the font property of a style always results in Times New Roman being used #84

Closed
Closed
iOS 13 - Setting the font property of a style always results in Times New Roman being used#84
Assignees
malcommac
Labels
bug
Milestone
3.0.2

Description

@LisaGonaus
LisaGonaus
opened on Aug 8, 2019

Environment

  • Xcode 11 Beta 5
  • iPhone XS (iOS 13 Beta)

Example

When the following code is compiled with Xcode 11 and run on iOS 13 any styles that contain fonts stop working correctly.

let text = "No issues here, <b>but this text is Times New Roman instead of the heavy system font</b>"

            
let baseStyle = Style { $0.color = UIColor.green }
let heavyFontStyle = Style { $0.font = UIFont.systemFont(ofSize: 14, weight: .heavy) }
            
let styleGroup = StyleGroup(base: baseStyle, [ "b": heavyFontStyle ])
            
let attributedText = text.set(style: styleGroup)

Screenshot 2019-08-08 at 13 33 09

Activity

  1. wberger commented on Aug 14, 2019

    @wberger
    wberger
    on Aug 14, 2019
    Contributor

    I have debugged into this, and I think I know why this happens. Let's assume, we have set the style to SystemFont, Size 14.

    SwiftRichString Font Instantiation on iOS 12 SDK:

    FontData.swift, Line 155, attributes(currentFont:, size:) -> [NSAttributedString.Key:Any]
FontConvertible.swift, Line 65, font(size:) -> Font
(lldb) po self
<UICTFont: 0x7fb74dd77f30> font-family: ".SFUIText"; font-weight: normal; font-style: normal; font-size: 14.00pt
(lldb) po self.fontName
".SFUIText"

FontData.swift, Line 159, attributes(currentFont:, size:) -> [NSAttributedString.Key:Any]
po finalFont
<UICTFont: 0x7fb74dc1ced0> font-family: ".SFUIText"; font-weight: normal; font-style: normal; font-size: 14.00pt

    --> the font name is reported as ".SFUIText" and SwiftRichString is able to instantiate the matching UIFont from this name via Font(name: self.fontName, size: (size ?? Font.systemFontSize))!

    SwiftRichString Font Instantiation on iOS 13 SDK:

    FontData.swift, Line 155, attributes(currentFont:, size:) -> [NSAttributedString.Key:Any]
FontConvertible.swift, Line 65, font(size:) -> Font
(lldb) po self
<UICTFont: 0x7fa576769f90> font-family: ".SFUI-Regular"; font-weight: normal; font-style: normal; font-size: 14.00pt
(lldb) po self.fontName
".SFUI-Regular"

FontData.swift, Line 159, attributes(currentFont:, size:) -> [NSAttributedString.Key:Any]
po finalFont
<UICTFont: 0x7fa576400020> font-family: "Times New Roman"; font-weight: normal; font-style: normal; font-size: 14.00pt

    --> the font name is reported as ".SFUI-Regular" and SwiftRichString is NOT able to instantiate a matching UIFont from this name via Font(name: self.fontName, size: (size ?? Font.systemFontSize))!. Instead UIFont(name:, size:) seems to fall back to Times New Roman.

  2. wberger commented on Aug 14, 2019

    @wberger
    wberger
    on Aug 14, 2019
    Contributor

    Here is the according rdar bug report:
    https://openradar.appspot.com/6153065

    One could avoid this issue by changing the instantiation in FontConvertible.swift, Line 65 from

    return Font(name: self.fontName, size: (size ?? Font.systemFontSize))!

    to

    return Font(descriptor: self.fontDescriptor, size: (size ?? Font.systemFontSize))

    However, I don't know whether this should only apply to this single line, or other parts/system flavors as well.

    But actually I hope that this gets fixed on Apple's side.

  3. wberger commented on Aug 14, 2019

    @wberger
    wberger
    on Aug 14, 2019
    Contributor

    I created a pull request containing the workaround: #85

  4. malcommac commented on Aug 24, 2019

    @malcommac
    malcommac
    on Aug 24, 2019
    Owner

    Merged and on track for 3.0.2. Thanks for PR.

  5. malcommac
    self-assigned this
    on Aug 24, 2019
  6. malcommac
    added
    bug
    on Aug 24, 2019

  7. danqing commented on Sep 20, 2019

    @danqing
    danqing
    on Sep 20, 2019
    Contributor

    Now that iOS 13 has been released, can this PR land in master (and have 3.0.2)?

  8. 0xacdc commented on Sep 24, 2019

    @0xacdc
    0xacdc
    on Sep 24, 2019

    Any progress with solving this issue in the Master ? Thx

  9. malcommac
    added this to the 3.0.2 milestone on Sep 24, 2019

  10. malcommac commented on Sep 24, 2019

    @malcommac
    malcommac
    on Sep 24, 2019
    Owner

    released

  11. malcommac
    closed this as completedon Sep 24, 2019

  12. danqing commented on Sep 26, 2019

    @danqing
    danqing
    on Sep 26, 2019
    Contributor

    Somehow I'm still experiencing the issue with 3.0.2. Am I alone?

  13. jdanthinne commented on Sep 26, 2019

    @jdanthinne
    jdanthinne
    on Sep 26, 2019

    @danqing Not alone, experiencing this issue as well with 3.0.2. (But it was working fine in the develop branch)

  14. falaix commented on Sep 26, 2019

    @falaix
    falaix
    on Sep 26, 2019

    @danqing Same here. Release 3.0.2 didn't fix the issue on iOS 13 for me.

  15. 0xacdc commented on Sep 26, 2019

    @0xacdc
    0xacdc
    on Sep 26, 2019

    @danqing Same here for 3.0.2 on iOS 13

  16. wberger commented on Sep 26, 2019

    @wberger
    wberger
    on Sep 26, 2019
    Contributor

    Commit e5c147f seems to have introduced the issue as there seems to be a mixup with the platform checks. As far as I can see the workaround is now applied to macOS instead of iOS

  17. danqing commented on Sep 26, 2019

    @danqing
    danqing
    on Sep 26, 2019
    Contributor

    Good catch @wberger. That seems to be the issue. Sending in a PR now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bug

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions