Closed bersace closed 4 years ago
I wasn't the one who selected the range; the Mfizz authors did. The tooling they use generates randomised code-points, resulting in new versions of the font having completely different code-points. A user once tried to upgrade Mfizz, and it broke everybody's stylesheets. Hence the reason I've emphasised code-point stability at the top of each font's character map:
These codepoints are locked in stone: once set, they're guaranteed never to change.
This isn't an isolated case, either; there's overlap with other icon-fonts, which is actually natural and expected. It only becomes problematic when they're merged into a single super-font (such as for use in the terminal). In those cases, the only solution is to remap the icons to unallocated code-points. But for the vast majority of users who have CSS-controlled font-selection, altering the codepoint choices simply isn't an option. I'm sorry.
The complete list of icon styles can be seen here, BTW.
Yes, CSS is easy to manage this. Do you have some feedback on using icons fonts in terminal ?
I actually don't use icons in mine, but I do recommend checking out sebastiencs/icons-in-terminal
(of which file-icons
is a part of). It should be an easy matter of forking and remapping various code-points at your leisure.
Great, thanks.
Hi,
MFixx uses 0xF000 range which is known to be used by FontAwesome.
I suggest to use another range.
For compatibility, MFixx can ship both range. fontconfig allows to prefer FontAwesome. This way, one can mix FontAwesome and MFixx.
I don't know how much bigger would be the font with double code-point.