Difficile d'utiliser un format commun si les programmes différents, bien que remplissant la même fonction, n'ont pas les mêmes fonctionnalités.
Je prend l'exemple de kword par rapport à d'autres traitements de textes, kword est un traitement de texte basé sur des frames (cf framemaker), il faut donc que son format de fichier soit compatible avec ce design alors que les autres traitements de texte non frame oriented (ex: abiword) auront un format de fichier qui reflètera leur mode de fonctionnement.
Comme le format est ouvert il est possible de créer des filtres d'import/export qui pourront plus ou moins bien convertir les données. Ça ne peut pas être parfait car les fonctionnalités ne sont pas les mêmes, dans mon exemple un filtre kword pour abiword devrait trouver un moyen de simuler les frames de kword pour conserver la mise en page et celà ne donnera probablement pas un résultat qui serait le meilleur choix possible avec les possibilités mise à disposition par abiword.
C'est pour ça que l'import de documents word dans starwriter ne pourrait être parfait que si starwriter était un clone de word, c'est à dire que toutes les fonctionnalités de word se retrouveraient dans starwriter à l'identique (bien sur des fonctions supplémentaires pourraient être présentes) pour qu'il y ait une correspondances stricte entre les fonctions word et les fonctions starwriter.
Ce n'est bien sur pas le cas et le boulot du filtre est de déchifrer les données du format word et trouver quelle est la meilleure façon d'obtenir le même résultat avec les fonctions de starwriter.
Ce que je veut dire c'est qu'un format vraiment unique obligerait les programmes qui l'utiliseraient à ne proposer que les mêmes fonctionnalités, les amélirations de certains devenant des incompatibilités avec le standard et on retombe directement dans le problème de départ.
C'est le cas du html, le format est défini puis les browser et les éditeurs html doivent se conformer à ce format, et puis certains ajoutent leurs propres fonctionnalités (comme MS ou Netscape) et celles-ci ne peuvent être correctement comprises que par leur navigateur, les autres devront essayer d'émuler le fonctionnement de ce dernier s'ils veulent pouvoir arriver au même résultat.
L'idée d'un format commun n'est pas mauvaise en elle-même, mais elle ne s'applique pas à tous les cas. elle est intéressante pour le html (du moins si elle était respectée), pour des applications bureautique j'ai des doutes.
Ou alors il faut un format mixte dont la base est commune mais pouvant contenir des extensions propres à des programmes différents (et donc étant bien définies comme telles).
Ainsi pour l'exemple des traitements de textes le format définirait comment décrire des choses comme la taille du texte, la police de caractère ou les marges, ainsi ces informations sont directement récupérables, puis des fonctionnalités plus complexes seraient spécifiques à certains programmes (et ces parties devraient être filtrées si un filtre est disponible ou ignorées sinon).
Un petit exemple du genre est le format de fichiers .desktop utilisé par KDE (depuis la version 2) et gnome, certains champs comme exec sont standard puis d'autres, préficés kde ou gnome, sont spécifiques à un environnement et simplement ignorés par les autres.
[^] # Format commun
Posté par wismerhill . En réponse à la dépêche Les predictions pour linux en 2003.. Évalué à 10.
Je prend l'exemple de kword par rapport à d'autres traitements de textes, kword est un traitement de texte basé sur des frames (cf framemaker), il faut donc que son format de fichier soit compatible avec ce design alors que les autres traitements de texte non frame oriented (ex: abiword) auront un format de fichier qui reflètera leur mode de fonctionnement.
Comme le format est ouvert il est possible de créer des filtres d'import/export qui pourront plus ou moins bien convertir les données. Ça ne peut pas être parfait car les fonctionnalités ne sont pas les mêmes, dans mon exemple un filtre kword pour abiword devrait trouver un moyen de simuler les frames de kword pour conserver la mise en page et celà ne donnera probablement pas un résultat qui serait le meilleur choix possible avec les possibilités mise à disposition par abiword.
C'est pour ça que l'import de documents word dans starwriter ne pourrait être parfait que si starwriter était un clone de word, c'est à dire que toutes les fonctionnalités de word se retrouveraient dans starwriter à l'identique (bien sur des fonctions supplémentaires pourraient être présentes) pour qu'il y ait une correspondances stricte entre les fonctions word et les fonctions starwriter.
Ce n'est bien sur pas le cas et le boulot du filtre est de déchifrer les données du format word et trouver quelle est la meilleure façon d'obtenir le même résultat avec les fonctions de starwriter.
Ce que je veut dire c'est qu'un format vraiment unique obligerait les programmes qui l'utiliseraient à ne proposer que les mêmes fonctionnalités, les amélirations de certains devenant des incompatibilités avec le standard et on retombe directement dans le problème de départ.
C'est le cas du html, le format est défini puis les browser et les éditeurs html doivent se conformer à ce format, et puis certains ajoutent leurs propres fonctionnalités (comme MS ou Netscape) et celles-ci ne peuvent être correctement comprises que par leur navigateur, les autres devront essayer d'émuler le fonctionnement de ce dernier s'ils veulent pouvoir arriver au même résultat.
L'idée d'un format commun n'est pas mauvaise en elle-même, mais elle ne s'applique pas à tous les cas. elle est intéressante pour le html (du moins si elle était respectée), pour des applications bureautique j'ai des doutes.
Ou alors il faut un format mixte dont la base est commune mais pouvant contenir des extensions propres à des programmes différents (et donc étant bien définies comme telles).
Ainsi pour l'exemple des traitements de textes le format définirait comment décrire des choses comme la taille du texte, la police de caractère ou les marges, ainsi ces informations sont directement récupérables, puis des fonctionnalités plus complexes seraient spécifiques à certains programmes (et ces parties devraient être filtrées si un filtre est disponible ou ignorées sinon).
Un petit exemple du genre est le format de fichiers .desktop utilisé par KDE (depuis la version 2) et gnome, certains champs comme exec sont standard puis d'autres, préficés kde ou gnome, sont spécifiques à un environnement et simplement ignorés par les autres.