Well, if you know the sprite sheet is gridded at a particular size you could use imagemagick to split it like:
convert sprite.png -crop 32x32 tile.png Which will dump out the images named like tile-0.png Then you don't really have to pull back the old deleted images. On the other hand, you can just undelete the old images without resetting your whole repo to before they were deleted by doing something like: git checkout abcxyz^ image.png where abcxyz is the commit sha for the commit where the image was deleted. But then you have to somehow verify that it's the same image that's in the current sprite. You should be able to do something like 'git log sprite.png' though to see if the sprite has changed since it was created. On Mon, Jun 18, 2012 at 02:50:48PM -0400, Dean wrote: > Hey everyone, > > I'm currently working on a performance experiment using CSSEmbed[1]. As > stated in the comments of the JIRA, this one is a bit tricky. At this > point, it's mostly down to changing the background images referenced in > the CSS from a sprite to the appropriate individual images. > > I'm interested in automating this process as much as I can (since there > are tons of backgrounds that need to be changed), but there are some > barriers to that: > > 1. The codebase at the point before significant sprite work was done is > very different from the way it is now. Many widgets don't exist, CSS > selectors are different, and I can't reliably use matching selectors > to change sprite references to images. (ie. The selector is exactly > the same, and the older version references an individual image while > the newer version references a sprite: I presumably can just change > the background image reference) > > 2. I have to make sure that the section of the sprite that's being used > hasn't changed from the original image (most of these original images > where removed from the repo well over a year ago) > > Does anyone know of any useful tools for automating a process like this? > It doesn't seem like undoing extensive sprite work from a point relatively > far into the past is a path well-traveled. > > Thanks, > > - Dean > > [1] [1]https://jira.sakaiproject.org/browse/SAKIII-5627 > > References > > Visible links > 1. https://jira.sakaiproject.org/browse/SAKIII-5627 > _______________________________________________ > oae-dev mailing list > [email protected] > http://collab.sakaiproject.org/mailman/listinfo/oae-dev -- D. Stuart Freeman Georgia Institute of Technology
signature.asc
Description: Digital signature
_______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
