DuoTone support

[CosmicPangolin]

v6 Duotone icons don't seem to show up properly - regardless of background color I only see one of the two colors painted.

[michaelspiss]

v6 duotone icons are not supported yet. I'll have a look at them again knowing about their api push, as last time the problem was the outdated icons.json.

[brianegan]

@michaelspiss thanks again for taking care of the this repo! Really nice job :)

Controversial opinion, but I actually think this project should drop support for Duotone / any commercial or "pro" feature of FontAwesome. The FontAwesome business themselves should manage and support any pro features -- not open source maintainers.

I purposely excluded pro features from this library for a long time, but due to popular demand they were added in. It's taken a reasonable amount of effort to support them over the years, but it still doesn't feel like "right" that the community should be responsible for those paid features.

[CosmicPangolin]

For the fun of debate -

Err lets not jump the gun and remove highly requested features that some of us now rely on...that serves a constellation of beliefs at the immediate expense of users 🥲

I think there's a reasonable argument that a pro purchase is more a transaction on asset usage rights than services and features. And while I agree in theory (and generally find the slow adoption of Dart/Flutter support frustrating), I feel like any reasonable first-party implementation would render this entire library obsolete anyway.

A fine story is FontAwesome creates icons, people who like them implement them into their preferred ecosystems, FontAwesome earns a larger market of users and money to make more icons. Not terribly perverse 🤷‍♂️

[michaelspiss]

Hey @brianegan! Thanks - I hope you are doing well!

I agree with you. It doesn't feel right that the community has to support paid features of a business. Much less regarding how often said business changes their API and breaks these implementations, requiring more work from the maintainers. This repo would probably need much less time and care would font awesome just stick to one format for once.

On the other hand: The community and pro icons are pretty much the same and it only requires minimal adaptation of this package to support them. Changes to pro icons require changes for free icons as well (as with this new API). It just wasn't logical for me to see developers reimplementing the exact same thing over and over, most of the time breaking icon tree shaking or something else unintentionally. That's why I initially created the pull request which enabled pro icons. People who bought the icons want to use them, even though they might not be experienced flutter/dart developers. I see this more as a service to the flutter community than to font awesome.

An entirely different point are duotone icons. They require much more separate code. Apart from their completely different structure, they also need an extra build step in the configurator (former updater). If I had to guess, they are responsible for 40% of this tool's code alone (and 99% of its complexity).
Should font awesome decide to start shipping duotone icons as TrueType SVGs instead of two separate glyphs, I will be the first to drop them from this package's featureset. I am not even sure flutter supports this part of the TrueType specification at all.

All in all: I see more good than harm in supporting pro icons with this package, especially since the work would need to be done for free icons anyway. I would however wish for some more support from font awesome, especially when it comes to maintaining a stable API which does not change with every second update.

[brianegan]

I think you summed up my perspective fairly: "It doesn't feel right that the community has to support the paid features of a business." With respect to @CosmicPangolin, Open Source consumers ask for a lot of time from open source maintainers. This is understandable, but I don't think many consumers have a good understanding of how much time they ask of maintainers.

Therefore, I mostly wanted to check in with @michaelspiss to make sure he still felt positively about his experience maintaining this library, because a lot of issues relate to supporting pro features. Since it sounds like you're good with it, I certainly don't want to discourage that!

[michaelspiss]

Thanks Brian, that's very thoughtful. And you are absolutely correct, it takes up a huge amount of time. I think the one thing you have to keep in mind as an open source maintainer is that issues don't have to be resolved asap. When people really need something, they can always create a pull request.

[CosmicPangolin]

I'm also in favor of tabling DuoTone support if their current implementation is a PIA...especially given the icons are beta and implementation is likely to change. Like...I'm curious to try them out but not at all convinced I'd choose them over the lightPro styles that I already think look fantastic in my apps. It sounds like the marginal gain vs marginal cost doesn't make any sense at all. And I do think some serious onus is on the FontAwesome team to natively support this ecosystem.

[michaelspiss]

We've come to that point where I am shelving duotone support. As there are probably going to be questions by people using them, I'll go into the reasons a bit further.

Duotone icons are not flutter-compatible at the moment

Font awesome switched from the original "we use two different codes for the primary and secondary part" to a ligature-based approach. This new approach requires the Icon to consist of not only one, but two characters - which flutter's IconData does not support. IconData seems to be responsible for icon tree shaking - the part which keeps your app sizes as small as possible by removing unused icons from the font file. Because ligatures are composites of multiple characters, they cannot be addressed directly and will always be removed (flutter/flutter#100325).

We could of course build a custom class that circumvents these limitations, but then icon tree shaking could not work (at least for duotone). Not only that, but it would also require a lot of constant work to adjust the code and keep it up to date with changes made to the original flutter counterpart. This leads us to the next - even more important - point.

Maintenance cost

Duotone icons have been a hassle for quite some time now. They required additional imports, classes, tests, example code,... All of which needed to be generated automatically should the user require it. Now with the new duotone font layout, this workload would pretty much quadruple - for a feature only used by a very small group of users.

Maintaining an open source project takes up a huge amount of time. As there is no compensation, I have to be very selective with the features I support. Duotone icons no longer make the cut in terms of value/time invested.

[ghenry]

Will try to help when I'm back on my project.

[brianegan]

Thanks, @michaelspiss. I know some users who find this thread will be disappointed, but I'd ask pro users to please follow up with the Font Awesome team via official support channels and let them know you'd like to see this feature! Perhaps they can contribute a solution & maintenance time to this library, or offer an official solution for DuoTone icons themselves.

[michaelspiss]

I am completely with @brianegan on this one.

I am going to lock this issue to avoid people finding this getting lost in a discussion. If there are further questions or a need for clarification, please open a new issue.