Discussion :

[olibara]

Bonjour

J'ai une reflexion de fond sur la meilleure maniere de permetre le stockage dynamique et l'exploitation de petit picto dans une application.

Je m'explique !

J'ai une application qui permet la creation de document.
L'utilisateur peut ajouter du texte ou des picto windings ou webdings
Je sauve le document en serialisation XML on conservent les taille police couler, position etc de chaque elements.

Mais les *dings ne sufisent pas toujours

Donc j'aimerais offrir la possibilité d'importer un petit picto jpg, bitmap, png wmf etc (les formats connus de .NET)

A ce stade apres import je pense qu'il faut centraliser et normaliser pour l'application les elements importés dans un container

C'est la que je fais appel aux idées de l'equipe
- Un repertoire dedié et tout en bmp ?
- Tout dans un fichier ressource dynamique (comment faire dans ce cas)
- Autre suggestions ?

Il faut savoir que je peux limiter a maximum 20 élements distinct (en tout cas pas enorme)

- Je pense aussi que je devrais pouvoir encoder les images utilisées dans le document XML.

Voila quelques questions dans un domaine que je ne maitrise pas encore bien ...

[Kaidan]

Tu peux stocker les pictos directement dans le XML en passant par un encodage base64 avec Convert.ToBase64String qui prend comme paramètre d'entrée un tableau de bytes lors de la sauvegarde du document. Lors de la lecture, il suffit d'utiliser Convert.FromBase64String pour effectuer l'opération inverse. En passant par les Stream, il n'est pas très compliqué d'obtenir un tableau de byte à partir d'une image et de créer une image à partir d'un tableau de byte. Cette méthode fonctionne bien entendu avec tout type de fichier et pas seulement des images.

[olibara]

Merci Kaidan !

Cette solution me donne deja une bonne piste pour l'exploitation des picto dans le document

En effet afin de rendre le document portable, il est préférable d'y inclure les picto et d'éviter de les référencer sur une source extérieure

Par contre si le meme picto se retrouve dix fois dans le document je vais essayer de garder dans le document la liste des picto distinct en un seul bloc et de faire des reference a cette liste.

Reste maintenant a trouver la solution la plus souple pour la conservation de la liste des picto dans l'application Sachant qu'un nouveau document pourait apporter aussi sa contribution de nouveaux picto !

[olibara]

Bon

Je pense que stoquer les picto sous forme de bmp dans un repertoire de l'app donne l'avantage de ne pas charger inutilement les ressources
Mais ca nécessite evidement toute la gestion du chemin et du contenu de ce repertoire

Pour le reste le stockage des picto necessaire dans un document via Convert.ToBase64String me semble parfait

Si pas d'autres idées suggestions cette semaine, je mets résolu

[ctxnop]

Salut,
Voila ce que je te propose comme solution :

1 - Les images "communes" (c'est à dire les images que ton soft proposent de base) :
Tu les stock dans un répertoire à toi. Le CommonApplicationData semble tout indiqué.
Ensuite, tes documents XML sauvegardés utilisent un DTD, ou au moins devraient. Ce DTD, tu peux l'écrire toi-même afin d'y déclarer tes propres entités XML. Par exemple : &pict0001;
Et via le DTD ils seront transformés afin de correspondre à ce que tu veux.

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
<!ENTITY pict0001 "[system_picture:smile.gif]">
<monxml>
    <un_noeud>Salut les gens &pict0001;</un_noeud>
</monxml>

Le XmlNode.InnerText de un_noeud donnera "Salut les gens [system_picture:smile.gif]".
Mais surtout, tu pourra obtenir un XmlEntity "pict0001" qui te permettra le remplacement de ton image.

Ainsi, tous les pictos fournits de base dans ton logiciels ne seront pas dupliqués, mais le problème c'est que si demain tu fait une nouvelle version en changeant des pictos, alors ils ne seront pas identiques d'une version à l'autre. Et donc, une option d'exportation visant à considérer ces images comme des images utilisateurs serait un plus.

2 - Les images utilisateur :
Tu as deux grandes solutions. Soit tu les inclus codé en base64 dans ton Xml. Soit tu les inclus séparément, auquel cas, il pourrait être très interessant de faire un truc à la OXML.
Le problème de les inclure directement c'est que ca alourdit violemment le poids du XML. en effet, une image codée en base64 pèse au moins deux fois plus lourd que l'image d'origine (puisqu'on code chacun de ses octets en une chaine de 2 caractères et donc octets).

Dans cette solution, il est impératif de mettre en place une sorte de header dans ton xml définissant les pictos codés en base64 et leurs attribuant un identifiant qui sera alors utilisé dans le "document" en lui même (sinon, si l'utilisateur inclut 15 fois le même picto, tu le stock 15 fois en en base64 et donc 30 fois plus lourd que l'utilisation de l'image stocké sur le dur).

Si tu met les pictos en dehors du xml et que tu stock les chemins, deux problèmes se posent. Les pictos peuvent avoir été viré par l'utilisateur, ou un programme ou un crash du disque, ou que sais-je. Le second problème c'est que si tu veux filer le document a ton pote a l'autre bout du monde, faut pas que tu oublie de fichier, que tu lui envoie le tout.
Et donc la solution dans ce cas serait un format proche du OXML à savoir une archive ZIP (u autre format de compression) contenant le fichier xml et toutes les ressources de celui-ci. Et dans le fichier XML on fait référence aux ressources par un identifiant ou un chemin relatif.
L'avantage est que tu n'a qu'un fichier a transférer, toutes les ressources sont disponibles, tu n'a pas de surpplus de poids à cause du codage en base64, et tu en gagne même car tu compresses le XML.

[olibara]

Bravo a toi pour l'effort de cette magnifique explication et ta compréhension parfaite de la problèmatique.

L'idée OXML est tres intéressant en effet je trouve que pouvoir "transporter" les images dans le document est un choix qu'il faut maintenir, si un document doit etre utilisé sur plusieurs installation de l'application, il aura toujours ses propres ressources "sous la main" et il peut lui meme contribuer a enrichir la base d'image installée.