compatibility with fontawesome v5

[aviau]

Hello!

It would be great if fork-awesome aimed for compatibility with fontawesome v5.

For example, font-awesome v5 has renamed a large number of icons. It does not matter that the icons are exactly the same, just that fork-awesome provide icons with similar meanings under the same names so that it is easy to migrate from one to the other.

Ideally, I would want to be able to use fork-awesome in place of font-awesome v5 with no changes to the code and get reasonable results.

For example, fork-awesome could support the fas, fab and far prefixes alongside with the classic v4 prefixes.

Let me add some context so that you understand where I am coming from.

Fontawesome is a very popular Debian package (tens of thousands of installs). As Debian Developers, we are faced with the issue that fontawesome v5 has a non-free build system and is therefore not fit for inclusion in Debian. This is unfortunate because there are a bunch of great Debian apps that are migrating to Fontawesome v5. We are left with no fonts for these apps.

If fork-awesome was compatible with fontawesome v5, we could use fork-awesome in these apps. We would probably also try to convince fontawesome users to switch to fork-awesome in the longer term.

See the relevant Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902981

Our discussion with upstream: FortAwesome/Font-Awesome#13467

fork-awesome could be the saviour we have been hoping for ;)

What do you think?

[tessus]

Renaming the icons might solve your problem, but it will break all applications and web pages which use ForkAwesome.

Maybe it is possible to add aliases.

However, what happens, if FontAwesome uses the name icon-x and ForkAwesome already uses a diffeerent icon named icon-x. In this case we can't add an alias. Do you see where I'm going with this?

[aviau]

Maybe it is possible to add aliases.

Yes, this is the main point of my suggestion.

if FontAwesome uses the name icon-x and ForkAwesome already uses a diffeerent icon named icon-x

I doubt it would matter much as icons with the same name would probably convey very similar meanings. Reasonable results would be enough for us to ship fork-awesome in place of font-awesome v5 in Debian. It does not have to be 100% compatible.

For example, font-awesome v5 has renamed cab to taxi. Whatever icon is displayed to the user really does not matter. What matters here is that fork-awesome ship a "taxi" icon so that font-awesome v5 names are supported and that "taxi" is not something completely unreleated like a dinosaur.

[tessus]

@xuv what do you think?

[aviau]

The list of v4 and v5 names can be found here:

• https://fontawesome.com/how-to-use/on-the-web/setup/upgrading-from-version-4

It could be use to create a list of aliases to create:

cog -> gear
cogs -> gears
address-book -> address-book-o
[...]

[xuv]

This is a tricky question and for now, I think it needs further analysis.

I understand @aviau's motivation and I'm definitely willing to find a solution. But this is also why we forked Font Awesome, because V5 completely removed the possibility of building the font ourselves and accessing the sources. The forking also intentionally moved this project in a direction that would break compatibility with Font Awesome.

The problems I see further down the road are if developers don't use the CSS and directly call the icons using their unicode reference. And that is where compatibility can never be met. We broke it as soon as we added an new icon to this set.

Maybe, to help us understand better the scope of the problem, could you tell us what you mean by "Fontawesome is a very popular Debian package". How many packages are depending on it?

Thx

[aviau]

And that is where compatibility can never be met.

Sure, but best effort compatibility is still fine. It also helps fontawesome v5 users migrate to a free alternative with low effort.

How many packages are depending on it?

font-awesome has 32k installs on our volountary popularity contest counter. We don't really know how many real install it has, as it is volountary, but this puts it high on the list of most installed Debian packages.

I am the maintainer for Syncthing which is affected by this. Currently, we ship Syncthing with no icons as a result of this. It does not look as good but it still works.

I tried to quickly find the reverse dependencies for font-awesome and found the following:

cacti: cacti
cantata: cantata
civicrm: civicrm-common
coz-profiler: coz-profile
debci: debci
freeipa: freeipa-server
gitea/contrib: gitea-common
glances: glances-doc
glbinding: glbinding-doc
glewlwyd: fonts-glewlwyd
globjects: globjects-doc
grafana: grafana-data
grr: grr-server
janus/contrib: janus-demos
jscommunicator: libjs-jscommunicator
julia: julia-doc
jupyter-notebook: python-notebook
                  python3-notebook
mitmproxy: mitmproxy
mkdocs-bootstrap: mkdocs-bootstrap
mkdocs-bootswatch: mkdocs-bootswatch
netdata: netdata-data
ntopng: ntopng-data
opennebula: opennebula-sunstone
otrs2/non-free: otrs2
plasma-applet-redshift-control: plasma-applet-redshift-control
prewikka: prewikka
publican: publican
python-ase: python-ase
            python3-ase
python-mkdocs: mkdocs
               mkdocs-doc
python-qtawesome: python-qtawesome-common
python-xstatic-font-awesome: python3-xstatic-font-awesome
r-cran-rmarkdown: r-cran-rmarkdown
r-cran-shiny: r-cran-shiny
ruby-font-awesome-rails: ruby-font-awesome-rails
rustc: rust-doc
sphinx-rtd-theme: sphinx-rtd-theme-common
sympa: sympa
texlive-extra: texlive-fonts-extra-links
tulip: tulip [amd64 arm64 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel ppc64el s390x]
ublock-origin: webext-ublock-origin
webdeveloper: xul-ext-webdeveloper
witty: libwt-common
syncthing: syncthing

[xuv]

Thanks for putting up the list.

Now, for me to understand this correctly, so far, only one package is reported "broken": Syncthing.

If, as @tessus suggest, we offer some form of compatibility by adding more aliases to some of the icons, you will patch Syncthing to use Fork Awesome instead of Font Awesome? And you plan to patch it only for the missing icons or for all icons? Because I could see some visual discrepancies coming up if one icon is from one pack and another is from another pack.

Or do you plan to make a PR in Syncthing code base to use Fork Awesome instead of Font Awesome and return to an "older" look of the icons?

In any case, could you provide us with the missing icons in Syncthing at the moment?

[aviau]

Now, for me to understand this correctly, so far, only one package is reported "broken": Syncthing.

Yes. Just to be clear, we still ship fontawesome v4 in Debian and we will probably keep shipping it until there are no Debian packages that need it. The problem arises when upstream updates to fontawesome v5. When this happens, we have to chose between not updating that package or updating that package and provide a workaround: ship it without icons or patch the program so that it uses fontawesome v4.

Patching the program to use v4 is not practical because the patches can be quite large and we would have to maintain these patches for a large number of packages.

If, as @tessus suggest, we offer some form of compatibility by adding more aliases to some of the icons, you will patch Syncthing to use Fork Awesome instead of Font Awesome?

Exactly, this will be the first thing I would do, so that we can immediately provide Debian users with a version of Syncthing that looks nice, with icons.

Or do you plan to make a PR in Syncthing code base to use Fork Awesome instead of Font Awesome and return to an "older" look of the icons?

That would be the second thing that I do, because Debian wants to have the minimal diff with upstream.

We would probably contact every user of font-awesome v5 and try to convince them to migrate to fork-awesome with pull requests and issues. However there is no guarantee that this will be merged upstream.

I want to add that the best scenario is that projects don't even migrate to font-awesome v5. They should instead migrate from fontawesome v4 to fork-awesome, which is probably the better supported migration path.

I am sure that there are many font-awesome v5 users that use it thinking that it is free software (Syncthing probably didn't know font-awesome v5 was non-free when they upgraded to it). My wish would be to smooth the transition for these projects, as they might chose to keep using fontawesome v5 if the migration to fork-awesome is too cumbersome.

In any case, could you provide us with the missing icons in Syncthing at the moment?

You can have an idea of the missing icons by looking at the migration commit.

Things have changed since then, but you can notice the following:

• they now use the fas class, which can probably be backported as an alias of fa in fork-awesome
• it looks like icons now always have a fa prefix? exclamation-circle -> fa-exclamation-circle
• they use some new names like flash -> bolt here.
• pencil -> pencil-alt here
• etc...

[xuv]

@aviau Ok, understood. Thanks for the explanations.

I've started to look at how to do this. For now, I'm creating a special CSS file that will handle the V5 compatibility. It will act in a similar fashion as the v4-shim.css that Font Awesome proposes for a quick upgrade to their v5, but for doing the opposite. The idea is to have a quick drop in CSS that helps fix the compatibility issues, but still keeping it separate, so it does not mess with the original code and also stands as a temporary fix until a more longer term decision is made by the development team. Would that sound good to you?

As for you concerns regarding the name of certain icons, I wonder why they were named like that in the Syncthing code. They've always had the fa- prefix on all of them. See fa-exclamation-circle for example.

The only thing I have not figured out yet is how to test this to see I'm doing all these things correctly.

[aviau]

Would that sound good to you?

Yes, that would be perfect. I agree that this is the clean way to do it.

Just to be clear, that file would be distributed as part of fork-awesome right?

The only thing I have not figured out yet is how to test this to see I'm doing all these things correctly.

The way to test this would be to open up some awesome v5 apps and try to migrate them to fork-awesome, maybe I can help with that by providing some Syncthing pages as examples.

Thank you for working on this ❤️

[xuv]

Just to be clear, that file would be distributed as part of fork-awesome right?

Yes.

I'll probably push a branch once I have something working so you could test it against Syncthing... and once we are confident this is working, I'll make a new release.

[xuv]

@aviau ok, it's not fully tested, but it seems to work. I've pushed a branch called v5-compat that has a v5-compat.css file that you should import in your project along the normal fork-awesome.css file in order to make a Font Awesome v5 installation somewhat compatible with Fork Awesome.

Of course, big disclaimer, if the original code uses any icon that were added in the V5 and did not exist in v4.7, this patch will not work. But for the rest, it should be ok.

Writing a test file at the moment to test all v5 icons... Will publish this later. But in the meantime, this should help you test it with Syncthing.

[xuv]

Ok, just added a test file. Most things seem correct.
Here are 2 screenshots. First one is with Font Awesome v5 (which has a lot more icons) and second one is using latest Fork Awesome along the v5-compat.css patch file.

Once @aviau has done the test with Syncthing, I'll merge this and release a new version.

[aviau]

I will try this out as soon as I can and report back!

Cheers,

[aviau]

Yay!

It worked for the bolt icon at the top:

• fas fa-bolt

There are some missing icons:

• fas fa-fw fa-cloud-download-alt
• fas fa-fw fa-cloud-upload-alt
• fas fa-fw fa-tachometer-alt
• far fa-fw fa-clock

[xuv]

Nice! I can fix the missing icons. We have all those. Give me a sec.

[aviau]

hmm, it looks like bolt is not even a backport and it is a name that is available by default in Fok-Awesome.

I have just appended the compat file to fork-awesome.css. That would be fine right?

[xuv]

Yes. Where there there was no need for backward compatibility, I did not touch anything.

Though now that I look at my files, I see that there should be an icon for cloud-download-alt and cloud-upload-alt. I'm not sure why they are not showing up. I explicitely defined them:

Fork-Awesome/less/v5-compat.less

Lines 27 to 28 in e2a131e

	&.cloud-download-alt:before { content: "\f0ed"; } // cloud-download
	&.cloud-upload-alt:before { content: "\f0ee"; } // cloud-upload

[aviau]

If you are willing to run a random binary from the internet, I can send you my build of syncthing so that you can debug (they include the web ui inside the binary).

Otherwise, I can also send you the result of the "saved page" from chrome.

[xuv]

A saved page would be nice. :)
I'm also running Syncthing locally and don't know how that would interact with your binary.

[aviau]

None of the icons from the saved page work for me.

Maybe I am doing it wrong, let me know.

sy.tar.gz

[aviau]

Replacing
fas fa-fw fa-cloud-download-alt with
fas fa-fw cloud-download-alt works.

So the compat layer is just missing support for the fa- prefix here.

[xuv]

Yes... That's the error. My bad, the v5-compat.css file should have fa- in front of all the icon names. And it's missing... Let me change that.

[xuv]

Pushed a change to correct that in the v5-compat branch.

(Now I wonder how that passed without me noticing with my test file)

[xuv]

Actually, tests passed the same way that it passed for Syncthing the first time. We only see the icons that have not changed from v4 to v5. :) Just for the record, here is a screenshot of a test that passed with all the icons :)

[aviau]

My eyes are poorly trained. Even now, I don't see the difference in the test file haha.

[aviau]

Here is a picture of Syncthing rocking Fork-Awesome 🎉:

[xuv]

@aviau 😆 One way to see the difference is to look only at the "regular" icons. In the latest test, they look more coherent and have a consistent lighter look. But it does not really matter.

If this is now working for you, I'm going to closes this issue.

[xuv]

@aviau Awesome!!!!

Closing then.

[aviau]

Pending a release of Fork-Awesome including the compat layer, I will open a pull request to Syncthing, switching to Fork-Awesome.

They have already shown interest: syncthing/syncthing#5236.

Then, I'll move ahead with uploading Fork-Awesome in Debian ❤️

[aviau]

Closing then.

But it will still be merged in master, right?

[xuv]

@aviau Yes. It is now. Added also the license from #113 and releasing under a new version 1.1.2. Hope that works for you.

[antenore]

Thanks so much for this compatibility layer!!! And sorry to comment on a closed issue :-P

[aviau]

Hah I am happy to hear that syncthing isn't the only user of this!