feat(example): example for building @font-face rules

[jbarreiros]

Issue #, if available: NA

Description of changes:

Hello, I am submitting an example demonstrating a way to generate @font-face rules. I've been using something almost identical for many months now and it has served my team well. Sharing it in case someone else finds it useful.

Full disclosure, this code is heavily inspired by @radium-v's comment in #266.

Lastly, when running the build, Style Dictionary will emit a couple of warnings. It would be nice to not have them, but I'm not entirely sure how to resolve them.

Example warning

⚠️ build/css/fonts.css
While building fonts.css, token collisions were found; output may be unexpected.
    Output name normal was generated by:
        asset.font.Roboto.400.normal   fonts/roboto-V20-latin-regular
        asset.font.Roboto.700.normal   fonts/roboto-V20-latin-700
    Output name italic was generated by:
        asset.font.Roboto.400.italic   fonts/roboto-V20-latin-italic
        asset.font.Roboto.700.italic   fonts/roboto-V20-latin-700italic
This many-to-one issue is usually caused by some combination of:
    * conflicting or similar paths/names in property definitions
    * platform transforms/transformGroups affecting names, especially when removing specificity
    * overly inclusive file filters

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[jbarreiros]

After submitting this, I had an idea for representing the fonts in a way that would get rid of the warnings, and no longer require a custom transformer.

tokens.json

{
  "asset": {
    "font": {
      "roboto": {
        "value": "Roboto",
        "formats": [
          "woff2",
          "woff"
        ],
        "display": "fallback",
        "styles": [
          {
            "file": "roboto-V20-latin-regular",
            "weight": "{font.weight.normal}",
            "style": "{font.style.normal}"
          },
          {
            "file": "roboto-V20-latin-italic",
            "weight": "{font.weight.normal}",
            "style": "{font.style.italic}"
          },
          {
            "file": "roboto-V20-latin-700",
            "weight": "{font.weight.bold}",
            "style": "{font.style.normal}"
          },
          {
            "file": "roboto-V20-latin-700italic",
            "weight": "{font.weight.bold}",
            "style": "{font.style.italic}"
          }
        ]
      }
    }
  }
}

Wrapping a formatter around that structure is easy enough (I have a working example I can post), but I am wondering if it completely moves away from the spirit of design tokens?

What I mean is that only the font name is a token. Everything else is metadata on the token.

In my experience (which is limited), I've never had to use font attributes like file name and formats (woff2, ttf, etc.) outside of @font-face rules, so maybe that is totally acceptable. How are fonts wired up in Android and iOS apps?

[JamesIves]

This is an excellent example and exactly what I was looking for. Would be great to see something like this added to the advanced examples section of the Style Dictionary site.

[chazzmoney]

Thanks so much for your example here, @jbarreiros

I know its been a bit, and I wanted to let you know we will be taking a deep look at this on Tuesday next week (April 12th).

Thank you for your patience!

[dbanksdesign]

LGTM!