7studio / bichoco-font-faces Goto Github PK

• CSS Fonts Module Level 3
• Font Variation Description
• Web Font Loader

I think these files below are unavoidable in a repository nowadays:

• bower.json
• .gitignore
• .editorconfig

Now, I don't know if it's important to add also the .travis.yml file or not.

Your feedbacks are welcome.

Currently, the BICHOCO Font Faces module does not support the SVG Font but it is not a bug it is rather a will.

In fact, in order to use an SVG font in the @font-face rule, its path needs an extra info (e.g.: url('../fonts/asap/bold.svg#idFontName) format('svg')).
This extra info is embodied by a hash after the file name which relates to the value of id attribute on the <font> element in your SVG file (e.g.: <font id="AsapBold" horiz-adv-x="1095">).
The reason for this is that multiple fonts can be embedded in a SVG document and therefore an unique identifier is required.

Finaly, even if there is only one font declared in the document, if we don't include this hash, the required SVG Font will not work.

The problem is simple: without generating our font files, we cannot define this hash as we would like. Unfortunately the SVG ID is not necessarily (in fact, never) the same than the font name or file name with the common font generators.
Here is an example with the webfont generator of Font Squirrel and the Asap font:

• Asap Italic -> asap-italic.svg -> <font id="asapitalic" ... >
• Asap Bold -> asap-bold.svg -> <font id="asapbold" ... >
• Asap Bold Italic -> asap-bolditalic.svg -> <font id="asapbold_italic" ... >

I found two solutions to use SVG font format with the module:

1. Rewrite ID in SVG file

Pros:

• Nothing has to be changed in @include directives
• This value is arbitrarily chosen by the generator so it can be rewritten for the module (like file names)

Cons:

• Sass is not a programing language. The hash could be difficult to build with the arguments, depending on the applied convention (e.g.: <FamilyName><Weight><Style>)
• Not really easy to test and debug
• Modifying the content of the file is not really a good idea (you could change the encoding or something else)

2. Be able to pass a list as the $family-name parameter in the font-face mixin

// Built @font-face rule
// @mixin: font-face
// @arg {string|list} $family-name The font-family descriptor value and optionally an SVG ID to use
// ...

// Basic usage
@include font-face('Asap', 'asap', normal, 700);

// With SVG font format support
@include font-face(('Asap', '#asapbold'), 'asap', normal, 700);

Pros:

• Don't handle the SVG document except to take the value of id attribute on the <font> element
• Easy to set up with Sass

Cons:

• Cannot be implemented on font-faces mixin in an understandable way. IMHO, it is too complex and would not make sense if the SVG ID was attached to variants/styles