Euh... si le format RTF supporte les images, les objets OLE, les ce qu'on veut... et en fait c'est ça le problème, petite explication:
Le RTF était conçu comme le format "idéal" pour les documents, extensible et tout et tout... pratiquement il fonctionnait en permettant à n'importe qui d'inclure de nouveau tag, mais on alors obligé de proposer un alternatif "du standard", par exemple, les liste numéroté ne sont pas (n'étaient pas en fait) supportés, on peut y ajouter un tag adéquat, mais on y ajoute l'information alternative permettant à un logiciel ne connaissant pas ce tag d'afficher la liste (l'alternative est alors un décalage vers la gauche suivi de 1, 2, 3, etc...). Super idée non?... bah euh vi mais dans la pratique ça ne marche pas si bien...
C'est exactement le même problème que le presse-papier: fournir un format minimaliste de substitution fait perdre des informations.
Dans le cas des images, cependant, il peut s'agir d'un autre problème: le WMF/EMF est "standard" sous windows... ce format est même documenté, mais ça fait une belle jambe aux autres OS... pq? parce que ce n'est qu'un espèce de "script" reprenant la liste des appels GDI (GDI est la couche graphique de windows) effectué pour dessiner l'image! Donc pour lire le format, c'est trivial, pour l'afficher... il "suffit" d'implémenter une bonne partie de GDI... ce qui vu sa richesse est loin d'être trivial. Je ne sais pas comment fait OO.org mais les seuls readers "non windows" que j'ai trouvé... produisait un bitmap en résultat, on passe donc d'un format vectoriel à un bitmap, et là de nouveau perte d'informations (et moche si on ne fait pas un bitmap "assez grand", encore plus moche si on le réduit ou l'agrandit après, etc...).
La question que je me pose, c'est si le mauvais résultat est également présent à l'impression? Je me le demande parce qu'il faut reconnaitre que c'est un truc bien foutu avec GDI: peu importe la destination (écran, imprimante, bitmap en mémoire, etc...) le code d'affichage reste le même et le résultat est relativement beau. (on pourrait faire le parallèle avec les problèmes de rendus de police en petite taille qu'on avait sous linux).
Et finalement, la différence entre Office 2000 et XP n'est pas forcément du à une volonté de microsoft de rendre cela illisible, Office XP utilise GDI+ (et pas Office 2000 il me semble), qui permet beaucoup de chose (alpha blending, antialiasing, etc...) mais qui du coup apporte une nouvelle version de l'EMF, l'EMF+ (sont fort dans leur nom marketing chez ms, enfin au moins c'est pas EMF.NET ;), ce qui est assez logique vu la nature des EMF: on ajoute de nouvelles API, le format "change".
Enfin le débat sur les format ouvert reste toujours le même: amha un format documenté ne sert pas à grand chose... il faut surtout que ce format soit destiné à être utilisable dans plusieurs applications, et ce n'est pas une tache facile... on a toujours une tendance naturelle quand on crée son propre format à la mapper sur la structure interne de l'application. Par exemple, imaginons un tableur basique ne contenant que 10 case sur 10... soit l'application maintient un tableau de 100 case et utilise la 11ème comme la première de la seconde ligne, elle peut aussi maintenir 10 tableaux de 10 cases, etc... (les possibilités sont infinies!) dans tous les cas c'est un tableau, mais le format de fichier sera probablement différent! Et peu importe le choix qu'on fera, on privilegiera l'une ou l'autre implémentation!
[^] # Re: Le nouveau format de fichiers de Microsoft Office empêche les concurents de lire les documents !
Posté par tene . En réponse à la dépêche Le nouveau format de fichiers de Microsoft Office empêche les concurents de lire les documents !. Évalué à 4.
Le RTF était conçu comme le format "idéal" pour les documents, extensible et tout et tout... pratiquement il fonctionnait en permettant à n'importe qui d'inclure de nouveau tag, mais on alors obligé de proposer un alternatif "du standard", par exemple, les liste numéroté ne sont pas (n'étaient pas en fait) supportés, on peut y ajouter un tag adéquat, mais on y ajoute l'information alternative permettant à un logiciel ne connaissant pas ce tag d'afficher la liste (l'alternative est alors un décalage vers la gauche suivi de 1, 2, 3, etc...). Super idée non?... bah euh vi mais dans la pratique ça ne marche pas si bien...
C'est exactement le même problème que le presse-papier: fournir un format minimaliste de substitution fait perdre des informations.
Dans le cas des images, cependant, il peut s'agir d'un autre problème: le WMF/EMF est "standard" sous windows... ce format est même documenté, mais ça fait une belle jambe aux autres OS... pq? parce que ce n'est qu'un espèce de "script" reprenant la liste des appels GDI (GDI est la couche graphique de windows) effectué pour dessiner l'image! Donc pour lire le format, c'est trivial, pour l'afficher... il "suffit" d'implémenter une bonne partie de GDI... ce qui vu sa richesse est loin d'être trivial. Je ne sais pas comment fait OO.org mais les seuls readers "non windows" que j'ai trouvé... produisait un bitmap en résultat, on passe donc d'un format vectoriel à un bitmap, et là de nouveau perte d'informations (et moche si on ne fait pas un bitmap "assez grand", encore plus moche si on le réduit ou l'agrandit après, etc...).
La question que je me pose, c'est si le mauvais résultat est également présent à l'impression? Je me le demande parce qu'il faut reconnaitre que c'est un truc bien foutu avec GDI: peu importe la destination (écran, imprimante, bitmap en mémoire, etc...) le code d'affichage reste le même et le résultat est relativement beau. (on pourrait faire le parallèle avec les problèmes de rendus de police en petite taille qu'on avait sous linux).
Et finalement, la différence entre Office 2000 et XP n'est pas forcément du à une volonté de microsoft de rendre cela illisible, Office XP utilise GDI+ (et pas Office 2000 il me semble), qui permet beaucoup de chose (alpha blending, antialiasing, etc...) mais qui du coup apporte une nouvelle version de l'EMF, l'EMF+ (sont fort dans leur nom marketing chez ms, enfin au moins c'est pas EMF.NET ;), ce qui est assez logique vu la nature des EMF: on ajoute de nouvelles API, le format "change".
Enfin le débat sur les format ouvert reste toujours le même: amha un format documenté ne sert pas à grand chose... il faut surtout que ce format soit destiné à être utilisable dans plusieurs applications, et ce n'est pas une tache facile... on a toujours une tendance naturelle quand on crée son propre format à la mapper sur la structure interne de l'application. Par exemple, imaginons un tableur basique ne contenant que 10 case sur 10... soit l'application maintient un tableau de 100 case et utilise la 11ème comme la première de la seconde ligne, elle peut aussi maintenir 10 tableaux de 10 cases, etc... (les possibilités sont infinies!) dans tous les cas c'est un tableau, mais le format de fichier sera probablement différent! Et peu importe le choix qu'on fera, on privilegiera l'une ou l'autre implémentation!