Introduction
Cette page est de nature relativement technique. Dans la mesure où j'ai rencontré de sérieuses difficultés à recueillir les informations nécessaires, sur le site d'Apple ainsi que d'autres, j'ai décidé de publier ici les données avérées que j'ai pu noter au fur et à mesure.

Aspects techniques des icônes personnalisées
Le principe technique est relativement simple. Ces icônes personnalisées sont des icônes normales (voir l'aide de WinComposer pour des informations plus techniques), mais qui doivent porter le numéro d'identification « magique » -16455). Le fichier qui les contient doit être caché. Un drapeau d'attribut spécial doit être armé dans la rubrique du dossier dans le catalogue.
Dans le cas d'un fichier, les données graphiques (qui doivent répondre aux mêmes conditions) sont intégrées dans la branche de ressources du fichier. Cette fois, c'est la rubrique du fichier elle-même dont l'attribut doit être correctement armé.
Ces ressources graphiques ne sont pas enregistrées par le Finder dans sa base de données (Desktop).

Icônes personnalisées de dossiers
Le dossier doit contenir un fichier caché appelé 'Icon\r' (avec 0x0D comme dernier caractère) contenant des ressources graphiques voulues de type icône (voir les explications détaillées données dans l'aide de WinComposer). L'atttibut « Icône personnalisée » doit être armé dans la rubrique du dossier.

Icônes personnalisées de volumes
Sous Mac OS 9 et antérieur, la racine du disque est traitée comme un dossier normal et doit contenir le même fichier 'icon\r'.
Sous Mac OS X, le fichier contenant l'icône doit être nommé '.VolumeIcon.icns', il doit être caché et l'icône, contenue dans la branche de données, doit être de type 'icns' (voir l'aide de WinComposer pour des informations techniques complémentaires).
Si vous visez toutes les versions du système d'exploitation Macintosh, vous pouvez inclure les deux fichiers. Mac OS X a repris de ses racines Unix la convention de traiter tous les fichiers commençant par un point comme des fichiers systèmes cachés. Le fichier '.VolumeIcon.icns' ne sera donc jamais affiché sous Mac OS X. Ce n'est pas le cas sous Mac OS 9 et antérieur, qui ne connaît pas cette convention. Il est donc indispensable d'armer l'attribut caché de ce fichier si vous ne voulez pas semer la perplexité parmi les utilisateurs.

Voir aussi notre page d'introduction sur les Icônes personnalisées Macintosh, comment les produire avec WinComposer et comment les intégrer dans les CD-ROM que vous produisez avec MacImage.

Table des différentes ressources utilisées pour les icônes

La ressource icns pour les icônes modernes
La plupart des ressources ci-dessus revêtent un aspect assez historique. La tendance actuelle est à l'emploi pratiquement exclusif de la ressource icns, dont le gros avantage est d'éviter l'éparpillement, puisque toutes les ressources nécessaires sont incluses dans un conteneur unique.
Cette ressource, dont on notera qu'elle n'est pas comprise par l'utilitaire ResEdit, a été introduite avec le Système 8.5.
À titre de précaution, il convient donc toujours de lui ajouter une ressource d'icône monochrome de base, de type ICN#, pour le cas (peu probable aujourd'hui) où la machine de destination tournerait sous une version plus ancienne du système.
De la même manière, compte tenu du renouvellement du parc, il est peu probable qu'il soit nécessaire de fournir des icônes en 4 bits/pixel.
Une ressource icns moderne contiendra donc une ressource ICN# et les ressources 32 bits pour les icônes en 32*32 pixels, 48*48 pixels et éventuellement 128*128 pixels.

Méthode de compression
Les icônes en 32 bits/pixel peuvent être comprimées. À la lecture, il convient donc de vérifier que la longueur annoncée dans l'en-tête de la ressource ne correspond pas à sa taille théorique (largeur * hauteur).
Si tel est le cas, il convient de décomprimer les données. Le principe est d'avoir une compression canal par canal, dans l'ordre rouge, vert puis bleu. Le canal alpha n'est pas inclus dans cette ressource comprimée. Il faut aller le chercher dans la ressource ?8mk correspondant (voir le tableau ci-dessus).

Pseudo-code :
La méthode de compression utilisée n'a pas été documentée par Apple. Elle a cependant été élucidée, probablement par Peter Stuer. J'ai utilisé comme base de travail le code de ResCafé, un utilitaire d'exploration des ressources écrit en Java par G. Brannon Smith.

Pour chacune des couleurs (rouge, vert, bleu) et sur la longueur maximale qui correspond à la taille de l'image, lire un octet.
Si le bit 8 de l'octet est armé :
   C'est une séquence comprimée d'une valeur unique (qui suit immédiatement).
   La longueur est égale à l'octet - 125.
   Placer le tout dans le canal de la couleur en cours.
Sinon :
   C'est une séquence non comprimée, dont les valeurs suivent.
   La longueur est de octet + 1.
   Lire et les placer dans le canal de la couleur en cours.