Request: support configurable url paths (like FontAwesome does it)

[lonix1]

The index.css references fonts in the ./files/ directory, so the declaration has this for example:

url('./files/open-sans-latin-400.woff2') format('woff2')

But what if our assets aren't structured that way, so the fonts aren't in ./files/?

It is easy to solve this using the same approach as Font Awesome. For each package add two new files: _variables.scss and index.scss.

_variables.scss has one line:

$font-path: "./files";        // this is the default, but we can override it

index.scss file:

@import "_variables.scss";
@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-display: swap;
  font-weight: 400;
  src:
    local('Open Sans'),
    url('#{$font-path}/open-sans-latin-400.woff2') format('woff2')
    // etc...
}

So our build scripts can redefine $font-path and include all the index.scss files. Very easy.

And this would be alongside the existing index.css so it wouldn't break anything for existing users.

SUMMARY
Just add two new files with the stuff above. Nothing else changes.

[KyleAMathews]

You suggesting we add scss support?

[lonix1]

@KyleAMathews Just those two very simple files.

And that doesn't interfere with the index.css that is already in place - so it's a non-breaking change.

[KyleAMathews]

I still don't understand what you want — you can't use the css files as they are in your projects?

[lonix1]

@KyleAMathews Nope. The existing index.css assumes fonts are in ./files/. But not everyone uses the same build system. So not everyone keeps fonts there. For example our fonts are in /assets/fonts.

So we edit each index.css and replace ./files/ with ./assets/fonts/ i.e. string replacement - ugly and liable to break in the future.

By parameterising the path (like Font Awesome does it), it is simple to manage this automatically during the build process.

I'm not sure how to better explain, maybe someone else with the same use case could jump in on this.

[KyleAMathews]

We control where files are for the typeface packages and they're always in the same place. You don't edit the CSS file. You just use it. Perhaps try out a typeface packages in a sample project?

[lonix1]

Our fonts and files don't end up in the same place as you, I guess. You obviously built the packages around you use case, which is fair. A complex system though won't follow this approach.

Thanks anyway.

(I'm still using these npm packages though, but the build scripts are just a little more complex. If anyone else does it the way I've described let me know and I'll share my approach - using npm scripts rather than gulp/grunt/etc).

[gintsmurans]

Same issue here. I am not exposing node_modules to web path, but instead I am compiling css from scss to another directory. I am using successfully font-awesome this way, but unfortunately it won't work with fonts from typefaces project. So for now I am manually copying them over to another directory and editing the css file. Which is not great for updates.

[danderozier]

Why was this closed? This is a pretty common problem, and the solution @lonix1 suggested is a good one -- both FontAwesome and IBM's Plex typeface use scss variables in the way they describe.

[davidjb]

This would fantastic if it were supported. I'm building standalone SCSS-based theme and having to use sed to find and replace the hard-coded paths to the font files in the resultant CSS.

The approach @lonix1 suggests is good (and what some other font packages do). The only thing is that to ensure there's a !default after the path variable so the default gets used but only if not already set by someone customising it:

$font-path: "./files" !default;        // this is the default, but we can override it

@KyleAMathews Could this be re-considered? Thanks!