Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Art direction #99

Closed
strarsis opened this issue Jan 2, 2016 · 5 comments
Closed

Art direction #99

strarsis opened this issue Jan 2, 2016 · 5 comments

Comments

@strarsis
Copy link

strarsis commented Jan 2, 2016

It may be the designer's intention to use a different image
for higher resolutions than for lower resolutions.
For example, a 16x16 favicon could be completely differently designed
than a much larger apple touch icon.

The designer could pipe multiple image files into favicons,
favicons will then use these image files by their resolution.
One could argue that providing input image files of multiple resolutions
would be duplicating the output of favicons,
but this is not the case, because favicons preoptimizes for many different resolution steps,
which would rarely reflect the designer art direction intentions,
also it converts into different formats.

@daviestar
Copy link

Hey, thought I'd throw my 2 cents in here.. after reading the docs and some closed issues it seems the package is aiming for a totally automated favicon process - just give it a logo .png and it does the rest.

From a designers point of view, I'd suggest a more manual approach. Of course, design process is a bit of an open-ended subject, but perhaps a good starting point may be something like 4 images:

  • iOS icon style - 192x192 png - ios.png
  • Android icon style - 192x192 png - android.png
  • Windows - 310x310 png - windows.png
  • Silhouette - silhouette.svg (probably original version of windows.png)

Then Material Design, iOS and Windows mobile design guidelines can be addressed for home screen icons.

Then additional file naming conventions could be something like ios.above100px.png. or android.below50px.png.

Why try to trace out (probably nasty) vectors from a bitmap image, when the logo has likely been lovingly crafted as a vector/.svg to begin with, then only saved as a .png for the favicon process.

@strarsis
Copy link
Author

+1 for support of SVG input files.

Art directions should also (still) be possible with SVG files:
16x16-32x32.svg (use for all output files in 16x16 px up to 32x32 px range)
"Resolution gaps" of provided input images can be filled by using the next larger available step.

Example:
16x16-32x32.svg - used for 16x16 px up to 32x32 px output image
256x256.svg - used exclusively for a 256x256 px output image
480x480.svg - is also used for the "resolution gap" between 256x256px up to 480x480px (or higher when nothing comes afterwards).

Further features:
When no resolution has been specified by input file name - use the resolution in SVG file (if any), (maybe even a special attribute?) or the native resolution of a raster (PNG) file.

@haydenbleasel
Copy link

@daviestar @strarsis Regarding SVG, see #53, it's a large issue and your thoughts there would be appreciated. Keeping this issue for size-oriented configuration, having a source config like this would be optimal:

{
  16: 'logo-16.png',
  32: 'logo-64.png',
  64: 'logo-64.png',
  ...
}

@haydenbleasel
Copy link

Will look into this again for later version.

@strarsis
Copy link
Author

@haydenbleasel: Any plans adding this feature in near future? Would this also be added to realfavicongenerator website (which seems to be closely related to this project)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants