Feature Request: Ability to specify unicode position for each glyph

[kpeatt]

It would be awesome if, instead of building the icons from 001 up, we could specify which glyph belongs at which position. I'd like to be able to place home icons in the ⌂ space and so on.

[mezzoblue]

I see that this issue has previously been dismissed as irrelevant -- https://github.com/FontCustom/fontcustom/issues/20

However, if I expect to continually work on a font over the course of a project, I don't see how the lack of control over character assignment is sustainable. Say I deploy a font with a few dozen icons. A month later I add 10 more and remove 7 from the previous set. Now my previous assignments have been blown out of the water because the font is re-ordered alphabetically.

Hacking the alphabetical ordering of the files is the only way around this issue currently, but it would make me feel a lot better if I could just drop in a JSON/CSV file with more manual control over the character assignments.

[endtwist]

@mezzoblue The thing is, it shouldn't ultimately matter to what codepoints the icons are assigned because they're intended to be used by class name, not codepoint.

So, I'm not sure I see the advantage in being able to manually assign what glyph goes to what codepoint, unless I'm missing something?

[felixfischer]

It would better support other use cases than HTML/CSS, like DTP.

[mezzoblue]

Supporting other workflows is what I'm getting at here. I don't necessarily want to use the generated CSS file.

Say I prefer applying icon fonts with data-* attributes, or maybe I want to group my icons in different logical sections with my own CSS file. Or as Kyle suggests, I want to map specific glyphs to similar fallback characters so a site makes some sense if the icon font fails to load. Or as Felix suggests, desktop publishing. Re-doing all the character assignments every time I build an icon font isn't really an option in many of these cases.

(For the record I'd far rather use FontCustom than IcoMoon for my icon font generation, but this is basically the main issue stopping me right now)

[kaizau]

Gents, thanks for all the feedback. Been working on an overhaul of the gem that will include the ability to arbitrarily pass in any template, opening the door for custom solutions to this and other issues. Aiming for a RC by next week.

[kpeatt]

The other thing that this would allow would be to swap in different icon sets and rely on the same mappings so they still render. We do this for professional services builds all the time — four icon sets supplied in the initial build process and then a designer will choose or swap between iconsets as necessary. Having glyphs mapped to standard spaces would make this way more useful in this workflow.

Using class names to specify icons isn't sustainable in our workflow so, like @mezzoblue, FontCustom isn't usable for us without this feature.

[ghost]

To add my :+1:, I mock up photoshop comps of pages before they're developed using the generated TTF, so having the unicode positions change when adding new icons is not ideal.

[misprintt]

I second this last comment - regenerating the unicode positions every time the font is created causes major repercussions for any 3rd party software using the TTF directly (photoshop,illustrator, etc). Just adding one icon starting with 'aa' would displace every existing icon reference in a document.

One solution would be to generate a simple cache file of the svg to unicode mappings when a font is first created, and then using the cache when rebuilding to ensure existing icons keep their existing unicode positions, and then assign new ones accordingly.

[bodaniel]

Could the use of stable ligatures help put out in any way? Using classnames works fine for web but if you use the font in Illustrator, Photoshop, Indesign etc. you currently need to copy and paste unicode characters to get the correct glyph. Isn’t stable ligatures an even better solution than stable unicode positions?

As misprintt mentions, a unicode cache seems like a simple and really nice solution to stable unicode mappings.

[bodaniel]

I have updated my version of Fontcustom to handle fixed unicode characters. If you want you can have a look at https://github.com/bodaniel/fontcustom.

I have updated lib/fontcustom/scripts/generate.py to read glyph settings from glyphs.json – if it is available. The order of the glyphs and each glyphs unicode character are controlled by glyphs.json. Glyphs.json could probably include more glyph specific settings – eg. ligatures.

Generate.py writes the character codes to .fontcustom-data which is then read by lib/fontcustom/generator/template.rb. I have updated all templates to use the character codes read from .fontcustom-data.

I have added two test icon fonts. Try "fontcustom compile ." for each.

1. testicon – Custom templates, fixed unicode characters read from glyphs.json
2. testicon-default – Default templates and settings, no fixed unicode characters

Note: I would like to replace json with yaml but it seems like you need some extra package to handle yaml files in Python.

I am thinking of making a pull request. Do I need to do anything more before doing that? Should I include the two test icon fonts? Sorry, I haven’t made any pull requests before.

[endtwist]

Feel free to just make a pull request! No need to include the test icon fonts in the repository, though if you'd like to upload them elsewhere and link to them in the pull request, it would be handy as a test reference.

[whatisjasongoldstein]

+1. I don't necessarily care if I can specify the characters used, but I want the existing ones to stay in place when I compile and add new icons.

I've switched to using the classes everywhere to skirt the problem for now, but I'd like to have the option to set the before :content directly in CSS. (This is especially convenient for open/close buttons, where I'd rather switch the icon using CSS than switching the class via javascript).

[musterknabe]

@whatisjasongoldstein If you are using a css preprocessor like less oder sass this is could be workaround. You define the utf-8 codepoint only once. It's a little more DRY and flexible. Combined with filenames prefixed with incrementing numbers (001-upload.svg etc.) it's pretty maintainable.

//LESS example

//These classes are not meant to be used in HTML. Use these as content: '\f123' replacements. 
.content-icon-upload { content: "\f100"; } //less variables might work as well

//Change the generated icon classes like this
.icon-upload:before { .content-icon-upload; }

//Custom class example using .content-icon-upload
.my-special-case-upload:after {
  .content-icon-upload() //better than 'content: "\f100";' all over the place
}

[kaizau]

Thanks for weighing in folks. I'll have a RC of this by the end of the weekend.

[kaizau]

Fixed glyph codepoints have been added to the latest beta! (changelog)

Let me know what y'all think. You'll need to delete your existing .fontcustom-manifest.json beforehand, as this version introduces a few breaking changes.

gem install fontcustom --pre

[sen-zo]

Thanks for adding this!

[jasmussen]

Thanks for adding codepoints. As a very recent adopter, it took me a little while to figure out that the decimal codepoints corresponded to private unicode addresses, but this fun conversion tool was useful.

It would have been helpful if those codepoints were hexadecimal from the start instead of decimal. Any chance of this happening?

My use-case is converting an existing icon font made manually in Glyphs, to use FontCustom instead. We rely on the already pre-set unicode addresses, so being able to assign them was important for us.