UIFont support

[joseprl89]

It would be great if we could have something similar to the UIColor functionality, but for UIFont.

[AliSoftware]

I think it would be even better if the command could parse a directory to look for .ttf and .otf fonts, then automatically detect their postscript name (probably using CTFontManagerCreateFontDescriptorsFromURL from swiftgen-cli to load the font and analyse it).

[joseprl89]

@AliSoftware makes sense, but in some cases you don't provide the ttf files in the bundle since they are already supported by iOS (e.g. Helvetica Neue and so on). The use case I had in mind was setting something like:

body-text : Helvetica Neue ; 17 ; Bold

Or a similar format. Would that make sense?

[AliSoftware]

Ah, good point, that actually makes total sense (and would be way easier to do, BTW, you could even make a PR for that, using the ColorsParser as inspiration 😉). Will tag as "easy" then.

[joseprl89]

Created a pull request for this. The tests at the moment are failing due to encoding (unless I'm missing something).

I'm afraid I won't be able to spend more time on it for a few days, so if someone can pick it up it would be much appreciated.

I'll paste the pull request, because I assume travis CI will reject it?

#53

[bill350]

I think the font approach can be more simple.
Here how we construct font extension without specific sizes :

extension UIFont {
    enum AppFont : String {
        case Regular    = "MarkPro"
        case Heavy      = "MarkPro-Heavy"
        case Light      = "MarkPro-Light"
        case ExtraLight = "MarkPro-ExtraLight"
        case Medium     = "MarkPro-Medium"
        case Bold       = "MarkPro-Bold"
    }

    convenience init(named name: AppFont, size:CGFloat) {
        self.init(name:name.rawValue, size:size)!
    }
}

So, with a Fonts.txt file and a structure like Colors.txt, it could be simple to generate extension based on the example above.

File structure :

Regular = MarkPro
Light = MarkPro-Light

[AliSoftware]

I think it really depends on how people use their fonts.

• Some people use constants only for font names/families without size, like you do @bill350 , and so you'll provide the size at call site and use UIFont(named: Regular, size: 16) because at this specific point in code you know you want to use this font at this size
• Others prefer naming their font constants by the role they play. Like ArticleTitleFont, ArticleFootNoteFont, ScreenTitleFont etc. Those will probably prefer to include the font size in the constant.

So depending on your usage we might even want to propose both templates to fit everyone's needs 😉

[dostrander]

@AliSoftware @bill350 @joseprl89 I'm working on this for multiple files types:

• Typeface files (OTF, TTF) in a directory that will just make enums and convenience like what @bill350 said.

extension UIFont {
    struct Font {
      enum MarkPro : String {
          case Regular    = "MarkPro"
          case Heavy      = "MarkPro-Heavy"
          case Light      = "MarkPro-Light"
          case ExtraLight = "MarkPro-ExtraLight"
          case Medium     = "MarkPro-Medium"
          case Bold       = "MarkPro-Bold"

          func font(size: Float) { return UIFont(name:self.rawValue, size:size)}
      }

      enum HelveticaNeue : String {
          case Regular    = "HelveticaNeue"
          case Heavy      = "HelveticaNeue-Heavy"
          case Light      = "HelveticaNeue-Light"
          case ExtraLight = "HelveticaNeue-ExtraLight"
          case Medium     = "HelveticaNeue-Medium"
          case Bold       = "HelveticaNeue-Bold"

          func font(size: Float) { return UIFont(name:self.rawValue, size:size)}
      }
    }
}

• JSON, YAML, that will be more of a "named fonts list" that will have the interface:

extension UIFont {
    struct Font {
      enum MarkPro : String {
          case Regular    = "MarkPro"
          case Heavy      = "MarkPro-Heavy"
          case Light      = "MarkPro-Light"
          case ExtraLight = "MarkPro-ExtraLight"
          case Medium     = "MarkPro-Medium"
          case Bold       = "MarkPro-Bold"

          func font(size: Float) { return UIFont(name:self.rawValue, size:size)}
      }

      enum HelveticaNeue : String {
          case Regular    = "HelveticaNeue"
          case Heavy      = "HelveticaNeue-Heavy"
          case Light      = "HelveticaNeue-Light"
          case ExtraLight = "HelveticaNeue-ExtraLight"
          case Medium     = "HelveticaNeue-Medium"
          case Bold       = "HelveticaNeue-Bold"

          func font(size: Float) { return UIFont(name:self.rawValue, size:size)}
      }
    }
}


extension UIFont {
  static public func BigHeadingFont() -> UIFont { return UIFont.MarkPro.Bold.font(90) }
  static public func TinyParagraphFont() -> UIFont { return UIFont.HelveticaNeue.font(8) }
}

Welcome to all feedback on the interface

[AliSoftware]

I like that approach @dostrander 👍 Would love to see it done this way, allowing both enums only carrying font names without sizes, and static font carrying the font enum+size.

I would just replace your static public func with static let instead:

extension UIFont {
  public static let BigHeadingFont = UIFont.MarkPro.Bold.font(90)
  public static let TInyParagraphFont = UIFont.HelveticaNeue.font(8)
}

Note that I wonder if it's worth making SwiftGen generate that last extension for "named font lists" (or if the user would rather prefer create it manually, SwiftGen only generating the struct Font with one enum per font and one case per font variant)?

[dostrander]

That's a good question and would love other people to weigh in on that. But I can get started on the first case either way.

[AliSoftware]

Cool thx 👍

[ZevEisenberg]

Definitely a fan of both the pure fonts and the sized fonts, since I can think of cases where either would be useful. Curious to see if the SwiftGen generator could validate the font file against both bundle fonts and iOS standard fonts, to minimize the risk of typos? Or just make a failing UIFont method throw an error so that it's immediately obvious if it's wrong.

[AliSoftware]

I think having some validation of the font file against the bundled fonts and the iOS standard fonts would be a nice feature to have, but not the first priority.
I mean, I'm all for it, but I don't want this to slow down the implementation of UIFont support or scare/slow any potential contributor into doing a PR 😉
So maybe let's start with just generating the font file from OTF/TTF files and/or from a JSON, merge that, and add validation against iOS standard fonts later in another PR, to avoid reporting that feature later 😉