Hey there,
Our company has been trying to use this package within the Ruby on Rails framework (through its 'Asset Pipeline', which is powered by Sprockets). We've found that, at the moment, the way the font files in this package are sourced with the relative path in src: url()
causes Sprockets to be unable to trace the font files properly as dependencies, so they don't get included in the asset precompilation process (and consequently don't show up when we deploy on our production servers).
I wasn't able to find an easy way to update this webfont package itself to fix the issue without refactoring the whole way the files are stored (see the 'Long-term solution' section) . However I did find a temporary workaround:
Rails temporary workaround
- writing a custom Rails-centric copy of
_path.scss
(see below)
- using a custom index file that imports everything except
_path
from mdi
like in the scss/materialdesignicons.scss
, and then our custom _path
file instead.
Here's whats in that custom _path.scss
file. asset_path()
is the Sprockets helper method for locating an asset file.
// This file has been copied from mdi and modified as outlined below. Using the
// package default version of this _path.scss file causes path resolution
// issues, especially in Production.
//
// Modifications:
//
// * "?v=" query string has been removed from the paths in url() directives, as
// Sprockets handles versioning itself with asset fingerprinting
// * url() directives have also been updated to use sprocket's asset_helper
// with an explicit basename for reaching into the mdi package. This makes
// sure that Sprockets can find and work with all the font files properly,
// and that it will pick up the font files as dependencies when precompiling
// assets
@font-face {
font-family: '#{$mdi-font-name}';
src: url(asset_path('mdi/fonts/#{$mdi-filename}-webfont.eot'));
src: url(asset_path('mdi/fonts/#{$mdi-filename}-webfont.eot?#iefix')) format('embedded-opentype'),
url(asset_path('mdi/fonts/#{$mdi-filename}-webfont.woff2')) format('woff2'),
url(asset_path('mdi/fonts/#{$mdi-filename}-webfont.woff')) format('woff'),
url(asset_path('mdi/fonts/#{$mdi-filename}-webfont.ttf')) format('truetype'),
url(asset_path('mdi/fonts/#{$mdi-filename}-webfont.svg##{$mdi-filename}#{$mdi-font-weight}')) format('svg');
font-weight: normal;
font-style: normal;
}
Long-term solution
I did also look into modifying this webfont package to support Sprockets - you can see a WIP approach to it here: master...captur3d:sprockets-port . The main problem is that I couldn't get it to work without refactoring the whole folder tree to follow a more Sprockets-friendly layout.
My reference for implementing Sprockets support was the bootstrap-sass package. If you look in bootstrap-sass/assets/stylesheets/_bootstrap-sprockets.scss, you can see that they define a boolean flag variable and two path-finder functions that wrap calling the corresponding helpers in Sprockets. Then in bootstrap-sass/assets/stylesheets/bootstrap/_glyphicons.scss, there's an if check for the boolean flag that determines whether to use the asset helper methods, or whether to just use url()
directly.
As alluded to earlier, the final problem I hit was that to make it to work properly entirely inside this webfont package (i.e. so we wouldn't need any custom code inside our Rails project), we'd need to add some kind of base mdi
or materialdesignicons
folder that everything else would live under, and probably also introduce the assets/stylesheets
-style directory layout that would wrap that folder as well. Whilst adding the mdi/
prefix (like we did in our custom _path.scss
file) works within Rails, it relies on that being the name of the package/the name of the folder that package is copied/checked out into, which is a bit flimsy. This package/repo itself will probably need its own mdi
folder to make everything work properly.
Making this directory structure change seemed somewhat of a breaking change for non-Sprockets users, so I figured it would be better to just write all this up in case anyone else comes along to use this package in Rails, and mention it to the package author to see if it was worth taking any further. You may want to at least link to this issue from the README for Rails users? Similar to the Apache Cordova exception I spotted there already.