Contemplate how to allow for specification of character mapping

[twolfson]

There are a few different principles of how to handle which unicode characters to use for web fonts:

• Start with ASCII and work up (e.g. A, B, C)
• Use unicode with a far offset (e.g. u5000, u5001). I believe GitHub chooses this.

This is effectively the equivalent of layout from spritesmith. Unfortunately, the engines are written by third parties in this case and don't always allow for custom specification of characters.

As a result, this is a two-fold issue:

• Provide a set of algorithms in a separate module (a la layout)
  • Also, need to code in support for this (will go inside addSvg(file, val, cb))
  • I am still on the fence whether values should be numeric or strings. Probably numeric since strings can have many forms (e.g. js, css, html)
  • Also, requires support in icomoon-phantomjs
• Handle engines that force a specific character set and those that are open to being explicit

[srohde]

Just to move the content over from the other issue. It would be great that characters and even multiple characters would be supported to use ligatures. Either addSvg(file, val, cb) like you proposed or a richer JSON config like:

var files = [
  {path:'test_files/eye.svg', unicode:'eye'}
]

How is the \e000-\e00n currently determined? Is this how Iconmoon sets the default values and if yes are there ways around it? Would like to contribute if you could point me into the right direction.

[twolfson]

While IcoMoon is currently the only engine in fontsmith, the end goal is to support multiple ones (I would love no external node depedencies). It is not guaranteed that we will be allowed to be explicit with all future engines.

That being said, the character values \e000-\e00n are currently automatically generated by IcoMoon (and the default set). If you select a character within their app, then navigate to the next screen, you can specify which character has what value:

http://icomoon.io/app/#browse

From my brief research ligatures are single characters in unicode. Can you confirm that Wikipedia is accurate and/or englighten me with more info? I am kind of a font noob =(

http://en.wikipedia.org/wiki/Typographic_ligature#Ligatures_in_Unicode_.28Latin-derived_alphabets.29

[srohde]

Ligatures can have multiple characters. It's a way/trick to make icons accessible for screen readers and search engines.

Have a look at these articles and then it should be clearer: http://alistapart.com/article/the-era-of-symbol-fonts http://demosthenes.info/blog/620/Why-You-Should-Consider-A-Ligature-Icon-Font-For-Your-Next-Project

So just by typing let's say eye it gets replaced with the corresponding icon matching the ligature.

The CSS looks like this:

@font-face {
  font-family: 'iconfont';
  src:url('fonts/iconfont.eot');
  src:url('fonts/iconfont.eot?#iefix') format('embedded-opentype'),
    url('fonts/iconfont.woff') format('woff'),
    url('fonts/iconfont.ttf') format('truetype'),
    url('fonts/iconfont.svg#iconfont') format('svg');
  font-weight: normal;
  font-style: normal;
}

.icon-link {
  font-family: 'iconfont';
  speak: none;
  /* Enable Ligatures */
  -webkit-font-feature-settings:"liga","dlig";-moz-font-feature-settings:"liga=1, dlig=1";-moz-font-feature-settings:"liga","dlig";-ms-font-feature-settings:"liga","dlig";-o-font-feature-settings:"liga","dlig";
  font-feature-settings:"liga","dlig";
  text-rendering:optimizeLegibility;
    font-style: normal;
  font-weight: normal;
  font-variant: normal;
  text-transform: none;
  line-height: 1;
  -webkit-font-smoothing: antialiased;
  text-decoration: none;
  color: #999;
  font-size: 2rem;
}

And the markup like this:

<a href="#" class="icon-link">search</a>

So if there is a ligature matching search like for instance a magnifying glass icon it gets replaced with the icon. However, a screenreader or search engine just sees the text link which is great.

The unicode in for instance the svg font file for search looks like this:

<glyph unicode="&#x73;&#x65;&#x61;&#x72;&#x63;&#x68;" d="..."/>

73, 65, 61, 72, 63, 68 being the hex codes for search

Does that make sense?

[twolfson]

My mind has been blown. Thank you, that was very informative. I have done a little more research and found the following:

• What we thought were ligatures are actually glyph names
  • The glyphs still use and retain unicode values

• I don't believe IcoMoon currently supports glyph naming currently (or at least nothing in their interface appears as such)

Unrelated but good to know:

• The second article uses a unicode value rather than so I am not sure the SVG linking you mentioned will work

http://viewsource.in/http://demosthenes.info/assets/fonts/ss-standard.svg#L198

<glyph unicode="&#x1f464;" horiz-adv-x="864" d="M864 54v-36q0 -8 -5 -13t-13 -5h-828q-8 0 -13 5t-5 13v36q0 50 33.5 84.5t81 54t95 37t81 45.5t33.5 67q-4 4 -11.5 12.5t-26 38t-33 62.5t-26 85.5t-11.5 107.5q0 89 63.5 152.5t152.5 63.5t152.5 -63.5t63.5 -152.5q0 -55 -11 -107t-27 -86.5t-32 -61t-27 -39.5
l-11 -12q0 -39 33.5 -67t81 -45.5t95 -37t81 -54t33.5 -84.5z" />

• Less modern browsers (e.g. IE8) don't support the ligature expansion =(

http://www.browserstack.com/screenshots/ab5e763f120f30e11147ee9ee4b5bb2311d976d2

All of this said, I think we should steer ahead with character values and in the back of our minds think about supporting additional parameters per-glyph (e.g. names).

Also, it would be wise to open an issue with IcoMoon about adding support for glyph naming.

[srohde]

Awesome, thanks for clarifying. I think Icomoon already supports it. When you go to the screen to generate the font, go to the Preferences and select Enable Ligatures (encoding with more than one character). After you've done that you can enter the ligature/glyph name in between the x and the up and down arrows for each icon.

[twolfson]

Wow, nice find. I guess you already knew about it since the SVG they generate uses the same unicode business that you initially posted with.

<glyph unicode="&#x73;&#x65;&#x61;&#x72;&#x63;&#x68;" d="..."/>

I think this should be acheivable but I might not get to it for a bit. There are also a few more wrinkles to iron out since technically a single font value should serve as the default and then ligatures/names act as secondary information. This is important because I want to create another module which does all of the CSS generation and that can be re-used in any case (e.g. with fonts generated via FontForge). I think the conclusion here would be for that module to take a string and create CSS with that. This would leave the logic encapsulated within grunt-fontsmith which will always know the state.

</devnotes>

Fun fact: SVG fonts are not supported in any IE/Firefox http://caniuse.com/#feat=svg-fonts

[srohde]

Yeah, sorry for not making this clear from the beginning. My understanding is that the same works for all font files and not only the SVG font. The SVG font is just the easiest to look into since it's XML and that's why I used it as an example. The same ligature support should work with the TTF and other fonts.

[twolfson]

No worries, that was clear. I think I was confused from the implementation in demosthenese.info which lacked the proper unicode values.