<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
<title></title>
</head>
<body>
 <br />
<div style="margin: 5px 0px 5px 0px; font-family: monospace;">
> I still think that having to commit 10 source files per icon is not<br />
> acceptable, even with subdirectories.
</div><br />
I agree it is a lot of source files, but I don't see that that's a problem if they're stored neatly within a resources subdirectory. user32.dll has a lot of images, but that's not a problem for this reason. In fact by creating resources subdirectories surely I'm tidying? because it unclutters the mix of resources and source code in many dlls.<br />
<br />
The issue is that the 9 images are never going to go away - a full XP icon has at least 9 independant hand crafted images to go into it. Vista and 7 icons have even more.<br />
<br />
Now the question is what to do about it?<br />
<br />
The two approaches I can see are to keep them independant and stored neatly, or to package them somehow.<br />
<br />
Keeping them independant is ideal from the artist's point of view because the SVGs and PNGs can be viewed and editied in their native format.<br />
<br />
I could package them together into an archive of some sort e.g. an icon.tar.gz file. That would make the build rules easier, but it would mean the individual images could not be individually versioned, and make them slightly harder to edit.<br />
<br />
An alternative we discused was to use a .ico rather than a .tar.gz as an image repository. However this has several problems:<br />
<br />
1. Ugly blurring of the line between source binary and compiled binary: The build rule becomes 1x.ico + 4x.svg -> .ico. Kinda circular.<br />
<br />
2. .ico files are a real pain to work with from the artist's point of view. It's a very unusual image format.<br />
<br />
3. It's so easy to screw up the icon's internal structure, or change the format of a sub-image without meaning to. Many image editor apps will not generate a byte for byte identical file in an open->edit->save process, and many image editors would subdly change the ico format, and git version history would not make that kind of change clear.<br />
<br />
4. Even then you're still left with 4 images - 1x .ico and 3x .svg, so the problem is still pretty bad.<br />
<br />
I favour the individual images approach, or I could do a package approach if you like, but I can't see how a .ico package could work. Do you see my problem?<br />
<br />
Joel<br />
<br />
</body>
</html>