search

actum / gulp-dev-stack

Actum dev stack based on gulp
MIT License
11 stars 7 forks source link

Self-hosted fonts #50

Open kettanaito opened 8 years ago

kettanaito commented 8 years ago

I have been working on one project recently, and it turned out our gulp dev stack does not provide support to easily include self-hosted fonts. While the most options may be imported via Google Fonts or Typekit, sometimes clients use their own fonts.

Suggestion: We can add something similar that I have implemented on one of the projects:

  1. Create a folder named "fonts" in the development root.
  2. Create respective folders for the required fonts inside "fonts" folder.
  3. Each folder of a single font will contain some defined CSS file (i.e. "font-face.css"). That file creates a proper font-face declarations for the fonts, which are in the same folder.
  4. Create a single CSS in the "fonts" folder, which will be a result of concating/including all the "font-face.css" files in subfolders (i.e. "bundle.css").

Overall example structure looks like this:

With a respective tasks it makes adding new fonts pretty easy:

  1. Create "fonts/myfont/font-face.css", and declare proper font-faces.
  2. Gulp reacts to the changes in "fonts/**" and contacts them into "fonts/bundle.css".
  3. "font/bundle.css" is one-time included somewhere in our main SCSS to import the fonts.

What do you think of that?

santa4u89 commented 8 years ago

I think that with webfont loader you can use also custom fonts, we use webfont loader on Zindulka website I think

kettanaito commented 8 years ago

Of course. I am talking here more about folder structure. Where and how to store the fonts, concating them, etc. Later they may be loaded via WebFont or other loader.

It would be good to make some gulp automatization for type conversion too, but I don't know if it's possible (like fontsquirrel does), to translate one font format into all required (ttf => otf, woff, etc.)

janpanschab commented 8 years ago

đź‘Ť to including fonts into dev-stack. Take a look into this article. As a first step we could implement FOUT with class solution.

kettanaito commented 8 years ago

After talking with @ronaldruzicka, it is a good point for us to discuss which font loader to use. We can do that on Front-end meetings :)

janpanschab commented 8 years ago

Just discuss it here. Please prepare some pros and cons. Thanks

kettanaito commented 8 years ago

A much bigger question is independent script including.

What I mean I mean that for a proper work, both FaceObserver and WebFront should be included the following way:

<head>
    ...
    <script src="js/webfontloader.js" async></script>
</head>

I have, actually, implemented a similar vendor javascript usage on eContracting, where we have 3 separate JS files, which we need to reference separately. We may use that approach, and then include font loader in the head directly.

Solution

Regarding the aforementioned question, I have implemented a solution to take each JS file in /app/vendor/ folder, run it through babel and browserify, exporting a single bundle for each file. This allows us to use those on-demand files separately when needed, while still keeping comfort during development with ECMAScript and all the other great features.

vbulant commented 7 years ago

@kettanaito Is this one still relevant?

kettanaito commented 7 years ago

@vbulant I haven't got much time to finish this. I know @janpanschab has provided the solution, so maybe try asking him if this issue may be covered by it. Thanks.

janpanschab commented 7 years ago

Implemented solution is basically for fonts from CDN - google fonts, etc.

vbulant commented 7 years ago

OK so to move into some direction…

This issue is about self-hosted fonts. Regarding FOUT/FOIT/whatever – let’s open a separate issue for that once needed.

Back to @kettanaito’s proposal (the original on the very top): It looks neat but do we really need that? What is the benefit? Usually we define fonts once and then use them so I think having a pipeline is quite extraneous.