Font-awesome: Support public Unicode codepoints where possible

[eevee]

It would be fantastic if I could use codepoints for which appropriate icons already exist, e.g., "★" for the solid star.

A hypothetical screenreader could even then announce the name of the glyph.

[Boldewyn]

I was about to ask for the same feature. It also comes in handy, when for one or the other reason the font can't be loaded.

Some interesting mappings:

• U+2190 LEFTWARDS ARROW -> arrow-left
• U+2191 UPWARDS ARROW -> arrow-up
• U+2192 RIGHTWARDS ARROW -> arrow-right
• U+2193 DOWNWARDS ARROW -> arrow-down
• U+261C WHITE LEFT POINTING INDEX -> hand-left
• U+261D WHITE UP POINTING INDEX -> hand-up
• U+261E WHITE RIGHT POINTING INDEX -> hand-right
• U+261E WHITE DOWN POINTING INDEX -> hand-down
• Dingbats block: http://www.decodeunicode.org/de/dingbats
• Miscellaneous Symbols block: http://www.decodeunicode.org/de/miscellaneous_symbols
• Miscellaneous Symbols and Pictographs block: http://www.fileformat.info/info/unicode/block/miscellaneous_symbols_and_pictographs/index.htm
• from the later: U+1F30E EARTH GLOBE AMERICAS -> globe
• U+1F34B LEMON -> lemon
• U+1F3A7 HEADPHONE -> headphones
• U+1F464 BUST IN SILHOUETTE -> user
• U+1F4B5 BANKNOTE WITH DOLLAR SIGN -> money
• U+1F4BE FLOPPY DISK -> save
• U+1F4C4 PAGE FACING UP -> file

and so on. I guess, far more than 80% of the icons can be mapped reasonably to existing Unicode codepoints. As far as I know, the font file sizes should not increase much, since the codepoints can be simply mapped in TTF and Woff. (In SVG, too, if the converter supports it.)

[wollmers]

Found this project, because I also like the idea of using symbol-characters. Many symbols are still assigned in Unicode, but some are not. See the free font http://users.teilar.gr/~g1951d/Symbola706.zip (but this font is very large).
Using official Unicode code points (as much as possible) has a lot of advantages like full support by other programs, e.g. your favorite editor, support of character properties in Perl.

[Boldewyn]

There is a small problem with using Emoji codepoints exclusively in FontAwesome. On mobile devices the icon is replaced with a multi-colored image. Therefore I suggest (as above) to have both codepoints, the current Private Use and the "semantically correct" Emoji, mapped to the glyph icon. This way the author can decide.

[lpar]

Proposed remappings to standard Unicode symbol code points. Lines starting with
hash are comment lines for symbols where I was unable to find a matching
Unicode symbol.

  'f000' => '1f378',
  'f001' => '266b',
  'f002' => '1f50d',
  'f003' => '2709',
  'f004' => '2764',
  'f005' => '2b51',
  'f006' => '2b50',
  'f007' => '1f464',
# 'f008' => icon-film,
# 'f009' => icon-th-large,
# 'f00a' => icon-th,
# 'f00b' => icon-th-list,
  'f00c' => '2713',
  'f00d' => '274c',
# 'f00e' => icon-zoom-in 
# 'f010' => icon-zoom-out 
# 'f011' => icon-off 
# 'f012' => icon-signal 
  'f013' => '2699',
# 'f014' => icon-trash 
  'f015' => '1f3e0',
  'f016' => '1f4c4',
  'f017' => '1f552',
# 'f018' => icon-road 
# 'f019' => icon-download-alt 
# 'f01a' => icon-download 
# 'f01b' => icon-upload 
  'f01c' => '1F4e5',
# 'f01d' => icon-play-circle 
  'f01e' => '21bb',
  'f021' => '1f501',
# 'f022' => icon-list-alt 
  'f023' => '1f512',
  'f024' => '2691',
  'f025' => '1f3a7',
  'f026' => '1f508',
  'f027' => '1f509',
  'f028' => '1f50a',
# 'f029' => icon-qrcode 
# 'f02a' => icon-barcode 
# 'f02b' => icon-tag 
# 'f02c' => icon-tags 
  'f02d' => '1f4d5',
  'f02e' => '1f516',
  'f02f' => '2399',
  'f030' => '1f4f7',
  'f031' => '1d400',
  'f032' => '1d401',
  'f033' => '1d470',
# 'f034' => icon-text-height 
# 'f035' => icon-text-width 
# 'f036' => icon-align-left 
# 'f037' => icon-align-center 
# 'f038' => icon-align-right 
# 'f039' => icon-align-justify 
# 'f03a' => icon-list 
# 'f03b' => icon-indent-left 
# 'f03c' => icon-indent-right 
  'f03d' => '1f4f9',
# 'f03e' => icon-picture 
  'f040' => '270f',
  'f041' => '1f4cd',
  'f042' => '25d1',
  'f043' => '1f4a7',
  'f044' => '1f4dd',
# 'f045' => icon-share 
  'f046' => '2611',
# 'f047' => icon-move 
# 'f048' => icon-step-backward 
  'f049' => '23ee',
  'f04a' => '23ea',
  'f04b' => '25b6',
  'f04c' => '2016',
  'f04d' => '25a0',
  'f04e' => '23e9',
  'f050' => '23ed',
# 'f051' => icon-step-forward 
  'f052' => '23cf',
# 'f053' => icon-chevron-left 
# 'f054' => icon-chevron-right 
# 'f055' => icon-plus-sign 
  'f056' => '8722',
# 'f057' => icon-remove-sign 
# 'f058' => icon-ok-sign 
# 'f059' => icon-question-sign 
  'f05a' => '2139',
# 'f05b' => icon-screenshot 
# 'f05c' => icon-remove-circle 
# 'f05d' => icon-ok-circle 
# 'f05e' => icon-ban-circle 
  'f060' => '2190',
  'f061' => '2192',
  'f062' => '2191',
  'f063' => '2193',
  'f064' => '21b1',
  'f067' => '2795',
  'f068' => '2796',
  'f069' => '273b',
  'f06a' => '26a0',
  'f06b' => '1f381',
  'f06c' => '1f342',
  'f06d' => '1f525',
# 'f06e' => icon-eye-open 
# 'f070' => icon-eye-close 
  'f071' => '26a0',
  'f072' => '2708',
  'f073' => '1f4c5',
  'f074' => '1f500',
  'f075' => '1f4ac',
# 'f076' => icon-magnet 
# 'f077' => icon-chevron-up 
# 'f078' => icon-chevron-down 
# 'f079' => icon-retweet 
# 'f07a' => icon-shopping-cart 
  'f07b' => '1f4c1',
  'f07c' => '1f4c2',
# 'f07d' => icon-resize-vertical 
# 'f07e' => icon-resize-horizontal 
  'f080' => '1f4ca',
# 'f081' => icon-twitter-sign 
# 'f082' => icon-facebook-sign 
# 'f083' => icon-camera-retro 
  'f084' => '1f511',
# 'f085' => icon-cogs 
  'f086' => '1f4ac',
  'f087' => '1f44d',
  'f088' => '1f44e',
# 'f089' => icon-star-half 
  'f08a' => '2661',
# 'f08b' => icon-signout 
# 'f08c' => icon-linkedin-sign 
  'f08d' => '1f4cc',
# 'f08e' => icon-external-link 
# 'f090' => icon-signin 
  'f091' => '1f3c6',
# 'f092' => icon-github-sign 
# 'f093' => icon-upload-alt 
  'f094' => '1f34b',
  'f095' => '1f4de',
# 'f096' => icon-check-empty 
# 'f097' => icon-bookmark-empty 
  'f098' => '2706',
# 'f099' => icon-twitter 
# 'f09a' => icon-facebook 
# 'f09b' => icon-github 
  'f09c' => '1f513',
  'f09d' => '1f4b3',
# 'f09e' => icon-rss 
# 'f0a0' => icon-hdd 
  'f0a1' => '1f4e3',
  'f0a2' => '1f514',
# 'f0a3' => icon-certificate 
  'f0a4' => '1f449',
  'f0a5' => '1f448',
  'f0a6' => '1f446',
  'f0a7' => '1f447',
# 'f0a8' => icon-circle-arrow-left 
# 'f0a9' => icon-circle-arrow-right 
# 'f0aa' => icon-circle-arrow-up 
# 'f0ab' => icon-circle-arrow-down 
  'f0ac' => '1f30e',
  'f0ad' => '1f527',
# 'f0ae' => icon-tasks 
# 'f0b0' => icon-filter 
  'f0b1' => '1f4bc',
# 'f0b2' => icon-fullscreen 
  'f0c0' => '1f465',
  'f0c1' => '1f517',
  'f0c2' => '2601',
# 'f0c3' => icon-beaker 
  'f0c4' => '2702',
# 'f0c5' => icon-copy 
  'f0c6' => '1f4ce',
  'f0c7' => '1f4be',
# 'f0c8' => icon-sign-blank 
# 'f0c9' => icon-reorder 
# 'f0ca' => icon-list-ul 
# 'f0cb' => icon-list-ol 
# 'f0cc' => icon-strikethrough 
# 'f0cd' => icon-underline 
# 'f0ce' => icon-table 
# 'f0d0' => icon-magic 
  'f0d1' => '1f69a',
# 'f0d2' => icon-pinterest 
# 'f0d3' => icon-pinterest-sign 
# 'f0d4' => icon-google-plus-sign 
# 'f0d5' => icon-google-plus 
  'f0d6' => '1f4b5',
  'f0d7' => '25bc',
  'f0d8' => '25b2',
  'f0d9' => '25c0',
  'f0da' => '25b6',
# 'f0db' => icon-columns 
# 'f0dc' => icon-sort 
# 'f0dd' => icon-sort-down 
# 'f0de' => icon-sort-up 
  'f0e0' => '2709',
# 'f0e1' => icon-linkedin 
  'f0e2' => '238c',
# 'f0e3' => icon-legal 
# 'f0e4' => icon-dashboard 
# 'f0e5' => icon-comment-alt 
# 'f0e6' => icon-comments-alt 
  'f0e7' => '2301',
# 'f0e8' => icon-sitemap 
  'f0e9' => '2602',
# 'f0ea' => icon-paste 
  'f0eb' => '1f4a1',
  'f0ec' => '21c4',
# 'f0ed' => icon-cloud-download 
# 'f0ee' => icon-cloud-upload 
# 'f0f0' => icon-user-md 
# 'f0f1' => icon-stethoscope 
# 'f0f2' => icon-suitcase 
# 'f0f3' => icon-bell-alt 
  'f0f4' => '2615',
  'f0f5' => '1f372',
# 'f0f6' => icon-file-alt 
  'f0f7' => '1f3e2',
  'f0f8' => '1f3e5',
  'f0f9' => '1f691',
# 'f0fa' => icon-medkit 
# 'f0fb' => icon-fighter-jet 
  'f0fc' => '1f37a',
# 'f0fd' => icon-h-sign 
# 'f0fe' => icon-plus-sign-alt 
  'f100' => '00ab',
  'f101' => '00bb',
# 'f102' => icon-double-angle-up 
# 'f103' => icon-double-angle-down 
  'f104' => '02c2',
  'f105' => '02c3',
  'f106' => '02c4',
  'f107' => '02c5',
  'f108' => '1f4bb',
# 'f109' => icon-laptop 
# 'f10a' => icon-tablet 
  'f10b' => '1f4f1',
# 'f10c' => icon-circle-blank 
  'f10d' => '275d',
  'f10e' => '275e',
# 'f110' => icon-spinner 
# 'f111' => icon-circle 
  'f112' => '21b0',

[lpar]

...and an attempt at a patch is at
https://github.com/lpar/Font-Awesome/commit/b0cfe521d3d1f544b6c0c52a3779fc9c5dfb0265
if someone wishes to try it. I don't know how the other font formats are created from the SVG, or what minifier to use for the .min files, so those will need fixing up to match.

[tagliala]

@davegandy take a look at this before: https://github.com/twbs/bootstrap/issues/10106

[Boldewyn]

@tagliala hence my comment above! It adds virtually nothing to Font Awesome's file size, if the icons are mapped to both positions but gives authors the option to choose.

[tagliala]

@Boldewyn as you can see in the issue above, glyphicons map some icons to public unicode codepoints - e.g.: calendar, mapped to 1f4c5 (as also suggested above by @lpar ) - and they are experiencing issues with old versions of webkit for android.

[Boldewyn]

Yep. They're experiencing exactly what I predicted above:

There is a small problem with using Emoji codepoints exclusively in FontAwesome. On mobile devices the icon is replaced with a multi-colored image. Therefore I suggest (as above) to have both codepoints, the current Private Use and the "semantically correct" Emoji, mapped to the glyph icon. This way the author can decide.

Again, mapping _both_ codepoints, the current Private Use and the canonical Symbol, to a glyph would give the best of both worlds to the author.

[tagliala]

@Boldewyn what is the best practice to map both codepoints to one glyph? I understand that Dave should map them in font files. What about the stylesheet? We need to mantain 2 versions of fontawesome?

[Boldewyn]

The mapping can appear in just one font file, the one that gets distributed. Basically, in the definition of the font you say, that both codepoints should point to the same glyph. An extreme case is how BLOKK does it: They point almost _every_ codepoint to a rectangular shape.

In the CSS nothing has to change: Still use the private codepoints as always. _But_ if you happen to have Emojis or Symbols already in the markup or care to mark up the icons as text in the HTML, FontAwesome would Just Work™, those characters would be displayed not as the “glyph not found” placeholders but as FontAwesome icons.

Another benefit would be interoperability. When all icon providers, who have a lemon icon, provide it at Unicode position U+1F34B LEMON, you could swap icon fonts any way you like.

[tagliala]

Sorry but I would like to properly understand.

Let's say the new syntax for icon-music will be

<span class="fa-icon fa-music"></span>

So... css is the same but if you provide

<span class="fa-icon">♫</span>

you will obtain the same result as above

Am I right?

[Boldewyn]

Basically, yes. That would be the beauty of this solution. Another great advantage: If the client has _any_ font installed to display these codepoints, she will see the icons (the gist of them, that is), even if FontAwesome doesn’t load for whatever reason (or until it loads, e.g. on slow connections). So for a lemon icon, a lemon will be displayed, just not the FontAwesome-shaped one.

[tagliala]

@Boldewyn ok now I got it, thanks. In this case, the issue with glyphicons is not a problem at all.

[eevee]

Yeah, that was my intention. I use noscript and it's pretty jarring (and ugly) to visit a new site with an icon font and see a vast sprinkling of little missing-glyph legos for all the private use glyphs, even though most of them are for characters that already have public assignments. :) Much easier to read source at a glance when it uses public glyphs, too.

[eevee]

It occurs to me that if the font _only_ contains PUA and decorative glyphs, and you stick font-family: "Font Awesome", sans-serif; in a stylesheet somewhere, then the markup becomes even simpler:

♫

[Boldewyn]

+1 for that comment. That'd be equal to the “Ampersand Font” solution.

[davegandy]

I'm digging into this in full force tonight. This is a big one I want to get in 4.0.

[tagliala]

@davegandy please remember to map _both_ codepoints and leave the codes in the css untouched because otherwise we will experience issues in some mobile browsers

[eevee]

I came up with some more mappings to approved-but-not-yet-released Unicode glyphs (that also exist in Symbola), but apparently I can't include astral plane glyphs in GitHub comments, so here's a gist instead.

[davegandy]

Dug into this quite a bit tonight, and it is a rats nest. I'm going to push this out to the next version, sadly. I won't consider this to be breaking backwards compatibility for that version, as these should be essentially transparent to the end user.

[davegandy]

Kicking this out to version 5. Browsers would override with their own unicode for these codepoints ignoring my font-face declaration.

[ChristTrekker]

Don't understand why this has taken so long. It sounds like something that people agree with. Isn't it just a matter of copying/moving the glyphs to a new codepoint, and updating CSS correspondingly?

[tagliala]

@ChristTrekker please read the above comments

Kicking this out to version 5. Browsers would override with their own unicode for these codepoints ignoring my font-face declaration.

And...

https://github.com/twbs/bootstrap/issues/10106

https://github.com/twbs/bootstrap/pull/10778

It's ok to support public unicode but if it break things we should think about it.

Glyphicons switched back to PUA

[joewreschnig]

That bug doesn't seem to apply here - Glyphicons placed certain things only at their astral glyph locations, which failed in browsers with bad astral plane support. (I think -- they're sometimes loose with terminology in the comments.)

This issue is about making FontAwesome use an existing glyph, which is already in the PUA (& in the BMP), _also_ in the standard location, astral or otherwise.

[ChristTrekker]

Ah ... I'd read the comments but didn't understand their import. I don't use any of those browsers that force their own rendering/choice-of-font (I believe it's most commonly handhelds, as many of these symbols originated in cell phone emoji, correct?), but I have heard about it. Too bad this is held back by a browser "misfeature".

I don't even particularly care (at the moment) about CSS class mapping. I'd just love to see more nice fonts with good symbol/pictograph support. There more there are, the better chance people will see something reasonable for, e.g., U+1F3C6 rather than tofu.

[tagliala]

@joewreschnig so... the stylesheet will keep using the PUA codes but the font should provide an "option" to use standard location?

[joewreschnig]

@tagliala Yes, exactly as described by @Boldewyn two years ago. I don't know why this issue has been delayed for so long and is now going in circles.

At this point I would've offered to fix it myself (in fact I've been using a fork that has codepoints in both locations for a couple months now) but whatever machinery generates the web font files (from the OTF, I assume?) does not appear to be in the build scripts, so it's impossible to submit a useful patch.

[tagliala]

@joewreschnig Dave uses fontsquirrel: http://www.fontsquirrel.com/tools/webfont-generator

About the PR: because of the binary nature of the .otf file, it is very important that Dave is using the very same version of the file on this repository, otherwise all his changes will be lost. Moreover, he will not be able to check all the changes in the file...

This feature was planned for 4.0.0 and then shifted to 5.0.0. In these days, Dave should be busy with Fontawesome Black Tie. I won't suggest you to submit a PR without having his acknowledgment first, there are high chances to waste your time.

Of course, feel free to make a fork and share with everybody interested in this feature.

edit: about my concerns, as far as stylesheet uses PUA it should be ok

[StanleyMlha]

+1 : map to Unicode possible code-points

[karlhorky]

+1 Would love to have this too

What's the status of this? Is this still planned for version 5? I took a look and didn't find a pull request for this yet - I'm assuming there isn't one yet due to difficulty of a clean solution.

Is this is the only tracking page for version 5?

Thanks for the project!

[joewreschnig]

There is absolutely a clean solution: Put the glyphs at both the public and private codepoints.

There is no pull request because the fonts are checked in as binary files and it is impossible to submit patches for them.

[dwt]

I was directed here to re-report my problem, so here goes:

My main point is that we have found that windows has a 'feature' that allows admins to disable all webfont downloads for all their users. This leads to apps that use font awesome to suddenly loose all icons from the application (in all versions of IE!), usually rendering the app completely unusable. See https://github.com/FortAwesome/Font-Awesome/issues/10046 for the original bug report.

I also think that together with support for content-editable and screen readers reading out the correct characters, it makes _a lot of sense_ to switch to semantic code points, and I'd like to add my voice here.

[Crissov]

Will this finally be fixed in Font Awesome 5?

[Crissov]

Has it been fixed in v5.0.0, the milestone this issue is tagged with? I only see PUA codes in the documentation.