feat: more advanced font specification

[auctumnus]

This adds the ability to specify multiple fonts (e.g. for fallback purposes), as well as specifying font features for Google Fonts. The only related issue I could find was #609, which appears to have been closed without any progress?

A resultant config might look like:

theme: {
   // ...
  fonts: {
    "Schibsted Grotesk": {
      features: "ital,wght@0,400;0,700",
    }
  },
  typography: {
    header: "Schibsted Grotesk",
    body: ["Inter", "Noto Sans"],
    code: "IBM Plex Mono",
  },
}

Fonts that do not have features sent in the fonts object inherit the default features for header/body/code fonts that existed before this PR, so this is strictly a backwards-compatible change.

[auctumnus]

will run prettier again in a second, sorry ^_^

[saberzero1]

If you're going to separate the fonts from the features, why not use multiple values for the different options? Like instead of just features, maybe consider mode for italics/bold/default and weight for the font weight.

[auctumnus]

This is reasonable and I thought about it, but

• if Google Fonts changes their API, this code would need to be updated quickly,
• making it as expressive as the string while keeping a good API would be hard,
• specifying the particular weights is something that only people who are already probably heavily editing the theme are going to think about, and those people are probably already familiar with the Google Fonts API

so I decided that keeping it a string would be less of a maintenance burden and less complex in most situations.

(If it seems like most people would prefer this be broken out into multiple options anyways, I can update it to do that / give people both options with features winning out.)

[saberzero1]

This is reasonable and I thought about it, but

• if Google Fonts changes their API, this code would need to be updated quickly,
• making it as expressive as the string while keeping a good API would be hard,
• specifying the particular weights is something that only people who are already probably heavily editing the theme are going to think about, and those people are probably already familiar with the Google Fonts API
  so I decided that keeping it a string would be less of a maintenance burden and less complex in most situations.

(If it seems like most people would prefer this be broken out into multiple options anyways, I can update it to do that / give people both options with features winning out.)

I feel like user that want to heavily customize their fonts would do so in custom.scss anyway.

[auctumnus]

My issue with that is that the current method of specifying fonts outputs a to Google Fonts at the top - I want to be able to modify that in a more advanced way. While I could just put an @import in my custom.scss, if the Google Fonts element is incorrect, that's another request to a resource that might not actually be used / be what I want.

[saberzero1]

My issue with that is that the current method of specifying fonts outputs a to Google Fonts at the top - I want to be able to modify that in a more advanced way. While I could just put an @import in my custom.scss, if the Google Fonts element is incorrect, that's another request to a resource that might not actually be used / be what I want.

In that case, you could just change the font source in your quartz.config.ts to local and set the desired font in your custom.scss through @font-face, be it a Google font or not.

I suppose I'm kinda looking for what problem is solved with the proposed change. The current configuration makes it easy for inexperienced users to configure a Google-font. Advanced users would likely use CSS. I'm unsure what group is better served by the proposed changes.

[aarnphm]

I think for cases like custom fonts, users best to use local and setup @font-face in custom.scss

[aarnphm]

no need to add unnecessary abstraction on top