Closed jsheffers closed 8 years ago
In our opinion, it's probably best to always push back for retina images from the client (instead of swallowing the pill of compromising quality).
Internal monologue:
That being said, I think this is an interesting edge case to explore. The current API is built to support:
gulp.spritesmith
(e.g. SVG -> PNG, probably due to lack of SVG sprite support for a browser)
gulp.src('*.svg').pipe(svg2png() /* might not be a plugin */).pipe(spritesmith())...
We could restructure options in different fashions (e.g. pass in 2 streams via spritesmith
invocation) but at the end of the day, we will still have the problem of needing to pair up non-retina/retina images.
We could go to an opinionated name structure (e.g. a.png
must have a retina a@2x.png
), this would allow us to state images a.png
, b.png
, and c.png
have retina matches but d.png
doesn't. But I would prefer to keep filenames/folder structures unopinionated to allow for flexibility.
To solve your problem, we can use our retina solution before everything was integrated; generate 2 spritesheets via separate tasks and stitch them together in a CSS pre-processor:
https://github.com/Ensighten/spritesmith/issues/19#issuecomment-24843826
The notes are for grunt-spritesmith
+ LESS but they should work the same. Let me know if you have any more questions
This is a great plugin! Thanks for your hard work.
I've been using this plugin and just decided to implement the retina portion. The issue I see is that I don't always get retina assets for every image I want to put in the sprite sheet (images from clients etc). As far as I can tell when you enable the retina sprite sheet it forces you to have a 1 to 1 relationship which means I can't add anything to the sprite sheet that doesn't have both standard and retina image.
I know this is really an issue of not be provided the correct assets, but it could be beneficial. Is there a way around this?