Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Auto-Generating Favicons #599
I've been spending some time trying to get the auto-generating favicon task into WSK and hitting a number of issues.
I've committed a few patched to gulp-favicon just to have some better error messages, but there are some fundamental oddities it that would require some more of my time to dig in a figure out the issues.
One concern I have is that this uses a third party API to generate the content
At the moment I would suggest we stick with what we have and either work on the library with less time pressure or wait for it to mature and include at a later date.
What are peoples thoughts?
referenced this issue
Jan 14, 2015
Are we talking about RealFaviconGenerator's API? I'm the author of the service. If there are concerns about it, like "does it work?" or "will it still be available in a month?", I'd be happy to discuss them :)
As an aside, the API does all the image processing. When it is used, there is no need for ImageMagick locally.
It's not concern over whether it works, but it's unclear where problems lie at the moment between gulp-favicons, favicons and real-favicons modules.
Then there is the online requirement and I don't how hard it would be to propose changes should something new come out.
For me, it's essentially an unknown is all.
Generating a multi-platform favicon is more than scaling a picture to various resolutions. Each platform comes with its own guidelines and it is important to follow them.
For example, the desktop favicon often uses transparency. But iOS does not support transparency for the Touch icon. When the Touch icon is transparent and the user adds the web site to home screen, iOS fills the transparent regions with black. Clearly not the expected outcome.
Another issue, often combined with the previous one, is the need of margins. The original picture content sometimes "touches" the edges of the picture, as it is the case with Github favicon. Such picture can be used as desktop favicon as is. But on iOS, this generates poor results. Margins must be added around the original picture.
Yet another issue, iOS crops the corners of the Touch icon to create an icon with rounded corners. For some pictures, this leads to poor results, too. For example, in the favicon of the Ruby web site, the tip of the ruby matches the bottom right corner of the picture. Use this picture as is as the Touch icon and the tip is gone once added to homescreen.
This is just for iOS. Each platform comes with its constraints and guidelines. This is what RFG tries to address, by providing limited but sensible settings for each platform.
So there are three issues about RFG:
Obviously, there is nothing to do about the "online" issue. RFG won't help if you're in a plane.
Regarding the availability of the service, I'm willing to make it last. I really want it to be part of every web dev and web designer toolkit (alright, a small part) Yet I'm just a guy and my willingness may not be the kind of guarantee you are looking for :-)
About the various modules, I guess @haydenbleasel and I should talk about it to figure out what should be done.
Of course, I completely understand that each of these issues can be blocking. If so, maybe RFG could be offered as a "plan B"? Just let me know.
Basically what Philippe said.
@gauntface I'll have a look into supporting multiple HTML files. Also, I'll talk to Philippe about moving Apple Startup Images into the API call so we don't need any local dependencies (IM and GM) anymore.
@sindresorhus Favicons used to produce all icons using just ImageMagick because I couldn't find a pure JS library for resizing images (easyimage, sharp, etc. all require IM or GM). The main reason I switched to RFG though is Philippe does a stellar job keeping everything up to date. I've seen all the guidelines and docs he has to go through for each favicon platform - pretty stringent stuff.
I did toss up a lot before switching to RFG but it just made more sense: outdated icons with little options that doesn't require an internet connection, or bleeding-edge icons with full support that's handled for us but does require an internet connection.
I know RFG is an awesome source for getting the right icons and up to date icons - please don't think I'm knocking your service, I've used it in the past.
It's just right now it's not a good fit. Tbh I hadn't even considered the offline case until Sindre mentioned it.
I'm also struggling to see how we could handle resizing images without a native binary......
At the moment we've done ok with just the favicons being pre-generated and using sketch it's insanely easy to pump out various sizes and versions, it may be a case we recommend either Sketch with a set-up file or RFG for people wanting to change, which quite a few people aren't doing at the moment.
Philippe just implemented Apple Startup Images as an option on the API, so Favicons 2.1.0 doesn't need any native dependencies, has more options and it's like less than half the size. Internet connection is probably the only pressing issue still remaining so we'll look into that.
Was that the right place? Sorry for repeating what I've just posted on #470 (comment) , I just wanted to let you know that RealFaviconGenerator now has an option for GWSK: it generates the steps to configure the icons you've just designed in a GWSK project.
Once Favicons integration in GWSK is final, I could update the steps and offer users a great experience to setup their icons, while preserving Favicons advantages.
Hayden, I'm up for a chat :)