Richard Bair's Blog

JIC -- Java Icon File Format

Tired of "dealing with a dozen png representations of a single (logical) icon as separated files"? Tired of writing/debugging the code to treat multiple files as a single logical unit? Well, Daniel Leuck, SwingLabs, and Ikayzo bring you JIC : the simple multi-resolution cross-platform icon format for Java!

Ok, ok, a little dramatic I know. But hey, it's cool technology and cool technology is what SwingLabs is all about. Daniel Leuck from Ikayzo recently contributed some code to the SwingLabs/JDNC Incubator Project for Java(tm) Icons. Read through the source (it's a quick read), as well as this SwingLabs forums posting.

Essentially, JIC is a zip file that contains a series of png or jpg images. All images are named in a standard manner. From the JavaDoc for JIconFile:

Each image has the name "image_(size).(png|jpg)" where (size) is the image size. All images have square dimensions (same width and height.) Variants such as icons with drop shadows are stored within the archive in a folder named after the variant. For example, an icon variant having a drop shadow with a size of 24 should be stored as "shadow/image_24.png". Variant names are all lowercase by convention.

Bam, that's it. As you can imagine, a lot of cool things can be done with this basic structure. Since JIconFile represents the logical icon rather than the physical icon, we can imagine cool utilities for getting grayscaled images (for disabled icons, of course), accessible (large) images, images with badges, etc.

Oh, and by the way, I can't help but plug the awesome icons over at IconExperience. I'm sure these icons (with all their wonderful variations) motivated JIconFile in the first place.

Cool stuff, keep it comin'

Richard

Comments

• What if this idea was expanded to support things like Kirill's truly multi-resolution Java 2D icons? Or SVG?

  Posted by: jessewilson on October 03, 2005 at 07:22 PM

• Please note that this format is very very incomplete.

  (1) One of the biggest problems with dealing with icons is support for i18n! But with this format there's no way to tie an icon to a country code!

  (2) Icons are usually grouped into icon sets.

  (3) The use of standard file naming and folders is just... wrong. Come on.

  Why can't we have an XML file where we can specify a single logical Icon file and then add hints? For example: (1) Here's my logical icon 'Image' with a default URL (2) If you want a 'big' version of Image use this URL (3) If you want a 'little' version of Image use this URL (4) If you want a big and French version of Image use this URL ... and so on. The fundamental problem here is specifying a logical image, a series of hints, and then resolving the criteria (imageName, hints) to a URL.

  Ironically, I implemented this a long while back. The code is long gone.

  Posted by: ocean on October 03, 2005 at 11:42 PM

• Hi,

  Please. If you (ok, someone) are going to create a new IconBunch format please make it a little more flexible. There should be support for an XML specification of course but I think a simple, but way more flexible, naming convention is also good for us that don't want to fiddle with XML.

  Resource bundle naming is another mandatory thing. As is support for animations for mouseover, pressed and such. Also a good definition on how to create "other" sizes from the ones supplied.

  If this format caches on it will not be changed in five years given Sun's current track record for these things and thus we need to have something that works from day 1.

  Why not post something somewhere so a lot of feedback can be given. Almost like a mini-JSR but without the overhead.

  Cheers,
  Mikael Grev

  Posted by: mgrev on October 04, 2005 at 01:49 AM

• Jesse: I think it would be reasonable to be able to do that. As a general point, I think that the 90%+ case is going to be using PNG files (not lossy like JPG, and designers at least here at Sun and at Icon Experience seem to prefer them).
  Ocean: great point about i18n! As for "The use of standard file naming and folders is just... wrong", I don't know about that. What is wrong with it? We do things that way for resource bundles. Is there really a limitation?
  First off, I like the idea of wrapping multiple images/classes/ whatever defining the icons in a single zipped up file. It helps to keep that logical icon, logical. Second, I could totally see the place for a manifest.xml file in the archive describing what icons should be used for what locals, what sizes, etc. Third, having a consistent naming system in case the xml file is missing sounds reasonable. Fourth, I see your point about the URLs: what if the image isn't local but is remote or in another jar file etc? In the totally degenerate case where the images are all on a webserver, the .jic file could contain a single manifest.xml file
  All good feedback. If you haven't already, visit the SwingLabs forums and let Daniel know your gripes!
  Mikael: "If this format caches on it will not be changed in five years given Sun's current track record for these things and thus we need to have something that works from day 1." absolutely. If/when it makes it into the JDK (probably not soon, in case you're wondering) it won't change incompatibly, so it is very important to get the API right. We haven't devoted a whole lot of design time to it yet (it's still just a part of the incubator), so don't worry if the present incarnation isn't perfect.
  Why not post something somewhere so a lot of feedback can be given. Any good pointers? JavaLobby is always an option.
  

  Posted by: rbair on October 04, 2005 at 08:37 AM

• Hi Guys,

  Richard - Thank you for writing about JIC. You are correct in assuming JIC was inspired by the IconExperience collections.
  Everyone - Thank you for your comments.

  I am currently adding the option of adding an XML or SDL (simple declarative language) manifest and vector icon support. I am looking at SVG support but I am worried about it not being very compact. If any of you have opinions on this feel free to educate me.

  A few clarifications:

  There should be support for an XML specification
  Agreed. I am adding this.

  As is support for animations for mouseover, pressed and such
  This already exists. You create a JIC variant named "pressed" or "mouseover"

  Also a good definition on how to create "other" sizes from the ones supplied.
  JIC already supports this. Its as easy as:
  Icon icon = jic.getIcon("pressed", 24);

  Any size can be specified. If no physical icon matches the size it will be created by searching for the first larger neighbor, and then the first smaller neighbor. Resizes are high quality - they use bicubic interpolation. I may eventually replace this with an even higher quality resize algorithm I came up with recently.

  One of the biggest problems with dealing with icons is support for i18n!
  Locale specific variants can be created (as JIC variants), but if your icons require locales, you may want to consider rethinking them. At Ikayzo (which is partially a localization company), we generally advise people to use locale neutral icons. This is one of the advantages of using icons in the first place ;-)

  Icons are usually grouped into icon sets.
  Good point. Perhaps a library format is also in order, but I think this would only be useful as a distribution format by icon providers and organization tool by developers. Most applications will want to bundle only the icons they use.

  The use of standard file naming and folders is just... wrong
  If you think of icons as physical entities with one name, the naming convention for the physical "tiles" makes sense. They are an implementation detail. There is no reason to give them different names. Doing so would unnecessarily complicate things.

  The IconUtils class in the JIC package includes a few useful filters including the ability to colorize icons. The demos show this in use. This eliminates the need to bundle color variants as IconExperience currently does. Other filters will be added.

  The package already includes classes for certain vector based icons such as circles, arrows, etc.

  Cheers,
  Dan

  Posted by: dleuck on October 04, 2005 at 10:55 AM

• Nice work! It'd be cool to integrate this with the SwingLabs action project - allowing for declaration of enabled/disabled icons and whatnot.

  Posted by: wsnyder6 on October 06, 2005 at 06:56 AM

• Hello, I have been working on something rather similar for a while, but haven't had enough time to give it a proper release.

  The code is currently in a java.net project at

  
  https://dsh-lib.dev.java.net/source/browse/dsh-lib/iconbundle/
  https://dsh-lib.dev.java.net/source/browse/dsh-lib/iconbundle-tools/
  https://dsh-lib.dev.java.net/source/browse/dsh-lib/identify/
  https://dsh-lib.dev.java.net/source/browse/dsh-lib/identify-tools/

  
  but is in the process of moving to a project on sourceforge at

  
  http://www.dishevelled.org/iconbundle
  ...and so on

  Posted by: heuermh on October 17, 2005 at 03:41 PM

This work is licensed under a Creative Commons License.