prepend website url to the font name

[jpfluger]

Hello. Very convenient bash script that you wrote here. Thank you.

My project required self-hosting of fonts for multiple subdomains. I added the website parameter to prepend the url to the font name so it gets saved to font.css as url('https://example.com/fonts/FONT-NAME.woff2').

Just a simple convenience parameter. If you don't want to include it, that's okay and I'll delete the pull request. But if you do, great.

[neverpanic]

Interesting idea, but I'm wondering why you're not just putting the CSS on example.com as well, which would make this unnecessary?

[jpfluger]

Good point. Could be done that way. It's a larger federated project, so we used a subdomain to host common resources.

I thought of different use case that might have more value.... I concatenate all core .css files into a single file which is stored in a different folder than the fonts. Since the default is relative-pathing, the fonts would not be found. This is fixed by using an absolute url. In this case I would use website="/fonts/ to create /fonts/FONT-NAME.woff2. For reference, see W3, Section 6.4, which says: "Partial URLs are interpreted relative to the source of the style sheet, not relative to the document."

[neverpanic]

OK, I see that use case and am willing to accept this patch, but I'm not convinced --website is a good parameter name for this. Let's maybe use --base-path instead?

However, I don't like that the generated output CSS file would then not work in-place, i.e. if you were to generate a CSS file with this parameter and attempted to use it without modifications in a web page, it would not work. So I'm thinking maybe the better approach would be to support putting the fonts into a subfolder, i.e. making this parameter also affect the path where the fonts would be stored and call it --font-subdir? What do you think?

[jpfluger]

I like your idea of --base-path - it is a better and more correct name than --website.

The --font-subdir parameter is a good idea and I understand what you say about modifications to the CSS. For many simple websites, this is a good thing. I think you should include it.

I actually already mimic --font-subdir in my setup script. This script creates a directory per font and then calls google-font-download to download that font to that folder and create the css inside of it.

And this is perfect I think for simple websites. But once concatenation of css files occurs, then --base-path might need to still be used. Maybe my use case is more complex than other developers? Or maybe my /css folder hierarchy needs to be tweaked? I am not certain. What I know is that --font-subdir would be useful but I would still need to use --base-path with it.

I will try to explain by using one of my websites as an example. For tigsus.com, there are font dependencies on...

• google
• font-awesome

And then for site-layout, third party assets are isolated from local assets or sub-sections.

• Third party fonts: _fonts
• Third party libraries: _third
• css, including concatenated css from third-party libs and _fonts: /css
• css that's in a sub-section: /users/css

For example, during development, I may use combined-font-local.css but then in production I use a concatenated/combined file in combined-local.css.

Then in my setup scripts for fonts, I declare various types of css types.

URL_FONTS_LOCAL="/public/_fonts"
URL_FONTS_DEV="//dev.public-url.com:8401/public/_fonts"
URL_FONTS_PROTO="//proto.public-url.com/public/_fonts"
URL_FONTS_PROD="//public-url.com/public/_fonts"
URL_FONTS_AWS="//cdn-public/_fonts"

The script automatically creates font/css directories and google-font-download greatly assists in this process. Then css is combined for all third party libraries and internal resources into a single file for publishing. I could use @import but I don't see an advantage to it right now.

So.... if --font-subdir would get me a better development paradigm, then great! Do you see it? Right now I don't see it. I would still need --base-path as well. I wish there was a simpler paradigm because it would also simplify my setup script. Maybe I'm missing something but I don't think so.

But also my example is most likely in the minority. Adding --base-path is sufficient for my needs and I wouldn't need to keep a fork open.

[jpfluger]

With some retooling for my complex example, what might work is using a combination of --base-path and --font-subdir and --output. The assumption is that font.css is not automatically created inside the font directory inside --font-subdir.

For example, run google-font-download with the following inputs:

• --base-path=../_fonts
• --font-subdir=_fonts
• --output=css/_fonts.css
• Multple urls might need to be supported, if not already:
  1. "https://fonts.googleapis.com/css?family=Roboto+Slab:400,100,300,700"
  2. "https://fonts.googleapis.com/css?family=Kaushan+Script"
  3. "https://fonts.googleapis.com/css?family=Montserrat:400,700"

This is created:

• _fonts/Roboto
• _fonts/Kaushan-Script
• _fonts/Montserrat
• css/_fonts.css ( --base-path for each font would be ../_fonts/ and the --font-subdir would have been _fonts)
• css/combined-css-all.css (concats _fonts.css or uses @import plus all other referenced css)

Then the font urls inside the generated output CSS file should work in place without resorting to multiple specialized url prefixes (eg URL_FONTS_LOCAL or URL_FONTS_DEV). But like I said, my use case is most likely in the minority. I'm perfectly happy getting --base-path included.

[sjpbeale]

@neverpanic Will this be merged? We also have the case of locally hosting but on an independent subdomain. Another case is if we want to combine / minify the font css, relative paths will lose the font file location.