SmartSprites

Duplicate fragments in sprite images

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 0.2.4
  • Component/s: None
  • Description:
    Hide

    Motivation

    Currently, if an image has more than one reference in the original CSS, SmartSprites will include it multiple times in the sprite image. Ideally, if one individual image is added many times to one sprite image, it should appear in it only once.

    Implementation

    Within each sprite image, there should be exactly one individual image per one sprite reference. Equal sprite references collected across different locations in a CSS file or different CSS files should point to the same sprite and individual image within the sprite. Sprite references should be considered equal if they refer to the same sprite (equal sprite-ref) and have equal bitmap renderings. In particular, equal bitmaps will be produced for equal sprite-alignment and sprite-margin-* properties, but when further sprite reference properties are added, the same rendering may be achieved by different sets of properties.

    Discussion

    The reason I've not stumbled upon this limitation in my previous SmartSprites-based designs is that I'd usually remove the duplication on the CSS code level, i.e. collapse many rules that used the same image like this:

    div#id1,
    div.logo,
    ul > li > div.x {
      background-image: url("../img/logo.png"); /** sprite-ref: sprite */
    }

    Until this duplicate removal is implemented, the above should work as a workaround.

    Show

    Motivation

    Currently, if an image has more than one reference in the original CSS, SmartSprites will include it multiple times in the sprite image. Ideally, if one individual image is added many times to one sprite image, it should appear in it only once.

    Implementation

    Within each sprite image, there should be exactly one individual image per one sprite reference. Equal sprite references collected across different locations in a CSS file or different CSS files should point to the same sprite and individual image within the sprite. Sprite references should be considered equal if they refer to the same sprite (equal sprite-ref) and have equal bitmap renderings. In particular, equal bitmaps will be produced for equal sprite-alignment and sprite-margin-* properties, but when further sprite reference properties are added, the same rendering may be achieved by different sets of properties.

    Discussion

    The reason I've not stumbled upon this limitation in my previous SmartSprites-based designs is that I'd usually remove the duplication on the CSS code level, i.e. collapse many rules that used the same image like this:
    div#id1,
    div.logo,
    ul > li > div.x {
      background-image: url("../img/logo.png"); /** sprite-ref: sprite */
    }
    Until this duplicate removal is implemented, the above should work as a workaround.
  1. smartsprites.zip
    (3.59 MB)
    Kanu Dialani
    03/Sep/09 11:00 PM

Activity

Hide
Kevin Vanderbeken added a comment - 03/Sep/09 05:01 PM

I just thought i'd raise why this is still a very valid and important feature request.

The problem here arises because for organisational purposes on large or multi-part sites such as ours, we have separated files for different application components... such as our movie news and our tv guides sections of the site.

These are kept in separate files for easy compartmental workflow of the team as well as reducing file size of all css when minified on the fly by the server. If image references are shared between css files (h3 or h4 decorations, gradients, etc) because of common styling, then the above way of writing code isn't applicable, because of the split files.

eg:
Movies css:
.movies-header { background-image: url("../img/deco.png"); /** sprite-ref: sprite */ }

TV css:
.tv-header { background-image: url("../img/deco.png"); /** sprite-ref: sprite */ }

An inconvenient work around could be forced with an additional css file which overrides selectors with the applicable background image of all the separate css files and defines all the backgrounds there. Like "backgrounds-all-over-the-site.css". This is however, highly impractical and a nightmare to manage!

Show
Kevin Vanderbeken added a comment - 03/Sep/09 05:01 PM I just thought i'd raise why this is still a very valid and important feature request. The problem here arises because for organisational purposes on large or multi-part sites such as ours, we have separated files for different application components... such as our movie news and our tv guides sections of the site. These are kept in separate files for easy compartmental workflow of the team as well as reducing file size of all css when minified on the fly by the server. If image references are shared between css files (h3 or h4 decorations, gradients, etc) because of common styling, then the above way of writing code isn't applicable, because of the split files. eg: Movies css: .movies-header { background-image: url("../img/deco.png"); /** sprite-ref: sprite */ } TV css: .tv-header { background-image: url("../img/deco.png"); /** sprite-ref: sprite */ } An inconvenient work around could be forced with an additional css file which overrides selectors with the applicable background image of all the separate css files and defines all the backgrounds there. Like "backgrounds-all-over-the-site.css". This is however, highly impractical and a nightmare to manage!
Hide
Stanisław Osiński added a comment - 03/Sep/09 07:30 PM

Hi Kevin,

The same point has been made on the discussion group, moving to 0.2.4 release and increasing priority.

S.

Show
Stanisław Osiński added a comment - 03/Sep/09 07:30 PM Hi Kevin, The same point has been made on the discussion group, moving to 0.2.4 release and increasing priority. S.
Hide
Stanisław Osiński added a comment - 05/Sep/09 05:59 PM

Implemented in trunk, binaries available from:

http://download.csssprites.org/smartsprites-0.2.4-dev.zip

Show
Stanisław Osiński added a comment - 05/Sep/09 05:59 PM Implemented in trunk, binaries available from: http://download.csssprites.org/smartsprites-0.2.4-dev.zip
Hide
Stanisław Osiński added a comment - 05/Sep/09 06:08 PM

Hi Kanu,

Just for your reference, I implemented the duplicate removal in a slightly different way than suggested in your patch. Instead of comparing individual image paths, I'm comparing the bitmaps individual sprite references produce. This way, even if the same image has two different file names, it will be included in the sprite only once. More importantly, this method correctly takes into account the individual image's margins and other properties I'll be introducing e.g. in: SMARTSPRITES-39. Therefore, beware with your original version: if you have two references to the same image differing only by margins (sprite-margin-*), these will be incorrectly linked to the same image within sprite, though in fact they should produce two different images within the sprite.

S.

Show
Stanisław Osiński added a comment - 05/Sep/09 06:08 PM Hi Kanu, Just for your reference, I implemented the duplicate removal in a slightly different way than suggested in your patch. Instead of comparing individual image paths, I'm comparing the bitmaps individual sprite references produce. This way, even if the same image has two different file names, it will be included in the sprite only once. More importantly, this method correctly takes into account the individual image's margins and other properties I'll be introducing e.g. in: SMARTSPRITES-39. Therefore, beware with your original version: if you have two references to the same image differing only by margins (sprite-margin-*), these will be incorrectly linked to the same image within sprite, though in fact they should produce two different images within the sprite. S.
Hide
Stanisław Osiński added a comment - 05/Sep/09 08:00 PM

Hi Kanu,

1) removes duplicate images. creates background-position with the same co-ordinates for same images
2) added parameter to copy non annotated CSS files.
3) added parameter to process/ignore smartsprite annotations.

I've implemented point 1) in a slightly different way, but I have a question about the use case for 2) and 3). I'm assuming that you're using a combination of these two options (copy non-annotated CSS files + ignore annotations) to simply copy your design files from the source location to the output dir? If so, maybe a simple Ant copy task, possibly with some mappers (http://ant.apache.org/manual/CoreTypes/mapper.html) would do instead?

Thanks,

S.

Show
Stanisław Osiński added a comment - 05/Sep/09 08:00 PM Hi Kanu,
1) removes duplicate images. creates background-position with the same co-ordinates for same images 2) added parameter to copy non annotated CSS files. 3) added parameter to process/ignore smartsprite annotations.
I've implemented point 1) in a slightly different way, but I have a question about the use case for 2) and 3). I'm assuming that you're using a combination of these two options (copy non-annotated CSS files + ignore annotations) to simply copy your design files from the source location to the output dir? If so, maybe a simple Ant copy task, possibly with some mappers (http://ant.apache.org/manual/CoreTypes/mapper.html) would do instead? Thanks, S.
Hide
Kanu Dialani added a comment - 05/Sep/09 09:25 PM

That sounds like a great idea and it will save a lot of unnecessary processing. Great

Show
Kanu Dialani added a comment - 05/Sep/09 09:25 PM That sounds like a great idea and it will save a lot of unnecessary processing. Great
Hide
Stanisław Osiński added a comment - 06/Sep/09 07:56 PM

Closing for the 0.2.4 release.

Show
Stanisław Osiński added a comment - 06/Sep/09 07:56 PM Closing for the 0.2.4 release.
Hide
Stanisław Osiński added a comment - 16/Feb/10 06:26 PM

Reopening to delete a comment.

Show
Stanisław Osiński added a comment - 16/Feb/10 06:26 PM Reopening to delete a comment.

People

Dates

  • Created:
    18/Jul/08 09:06 AM
    Updated:
    16/Feb/10 06:26 PM
    Resolved:
    16/Feb/10 06:26 PM

Time Tracking

Estimated:
6h
Original Estimate - 6h Original Estimate - 6h
Remaining:
0h
Remaining Estimate - 0h
Logged:
6h 5m
Time Spent - 6h 5m