Organisé autour de trois volets d'interopérabilité (technique, organisationnelle et sémantique), le RGI aborde 16 thèmes (format de documents, gestionnaire d'identités, etc.) et 4 initiatives. Ce site est accompagné d'un wiki public dont voici certaines règles :
- Règle 0025 Interopérabilité technique
Il est RECOMMANDÉ d'utiliser le format Open Document pour les échanges de documents bureautiques semi-structurés (traitement de texte, tableur, présentation). - Règle 0026 Interopérabilité technique
Il est OBLIGATOIRE d'accepter tout document au format Open Document pour les échanges de documents bureautiques semi-structurés (traitement de texte, tableur, présentation). - Règle 0027 Interopérabilité technique
Il est INTERDIT de faire une migration depuis le format bureautique couramment utilisé par une organisation vers un format autre que le format ouvert Open Document. - Règle 0044 Interopérabilité technique
Il est INTERDIT d'utiliser des composants logiciels type ActiveX ou toute autre extension de navigateur (Flash hors animation, VML, etc.) au niveau des IHM Web.
Frank Mordacq, directeur de la DGME, rappelait les objectifs de la modernisation à savoir une démarche de qualité de service auprès des usagers et proposait une nouvelle logique de travail aux agents.
Aller plus loin
- L'appel sur le site du SDAE (9 clics)
- Wiki (9 clics)
- Règlement de l'appel à commentaires (7 clics)
- Interview de Frank Mordacq (5 clics)
# Codage des caractères ?
Posté par Marc Poiroud (site web personnel) . Évalué à 1.
Il me semblait que l'UTF8 était l'avenir ?
Pourquoi un tel choix alors ?
Sinon, il est clair que c'est un grand pas pour l'administration ouverte et accessible à tous.
[^] # Re: Codage des caractères ?
Posté par vrm (site web personnel) . Évalué à 10.
[^] # Re: Codage des caractères ?
Posté par MrLapinot (site web personnel) . Évalué à 9.
Donc elle évite de proner des options éventuellement non supportées par de vieux clients (je suppose) et préfère un encodage national bien adapté aux besoin décrits (l'administration française ne communiquant que rarement en tchèque ou en japonais, je suppose).
[^] # Re: Codage des caractères ?
Posté par Sisyphe Plâtrier . Évalué à 10.
Hth.
[^] # Re: Codage des caractères ?
Posté par Marc Poiroud (site web personnel) . Évalué à 1.
[^] # Re: Codage des caractères ?
Posté par Ben . Évalué à 9.
[^] # Re: Codage des caractères ?
Posté par Flink . Évalué à 3.
Après google/wikipedia est ton ami.
[^] # Re: Codage des caractères ?
Posté par Flink . Évalué à 8.
UTF8 peut être codé sur plus que 2 octets.
Désolé /o\
[^] # Re: Codage des caractères ?
Posté par François B. . Évalué à 5.
http://fr.wikipedia.org/wiki/Utf-8
Pour le français, les lettres non accentuées sont sur un octet et les lettres accentuées sont sur deux.
[^] # Re: Codage des caractères ?
Posté par Zenitram (site web personnel) . Évalué à 10.
ne pas confondre :
- ISO xxx sur un octet
- UTF-8 Multi-octet mais basé sur un octet (un logiciel prévu pour un octet peut le traiter sans probleme, juste l'affichage qui est bizarre)
- Unicode codés sur 4 octets (Windows utilise UTF-16, sur 2 octets)
On considère donc UTF-8 comme un "charset" sur un octet, au meme titre que ISO xxx, mais on le traite a l'afficahge comme du 4 octets.
donc maintenant, la spécification n'est pas claire, car ne fait pas cette difference : comment stocker Unicode? UTF-8? UTF-16? UTF-32? Big Endian ou Little Endian?
Donc faudrait préciser Unicode, par contre je comprend pour avoir de l'inter-operabilité maximum on utilise ISO Latin 9.
(en fait, je l'ai fait maintenant :) )
[^] # Re: Codage des caractères ?
Posté par Sébastien Koechlin . Évalué à 6.
Unicode n'est pas un mécanisme de codage des caractères, c'est juste une norme qui attribue une valeur numérique (non bornée) à un symbole.
L'UTF-8, UTF-16 dont des mécanismes qui utilisent un codage des caractères unicode de taille variable comme cela a été dit.
Pour un programme, avoir une taille variable n'est vraiment pas pratique, il faut parcourir la chaine depuis le début pour interpréter les octets et retrouver les caractères. Les logiciels utilisent plutot une représentation en taille fixe.
La représentation en taille fixe la plus connue est ASCII, dont est dérivée toute la série des iso-8859-x célèbre, mais qui limitent toujours à 2^7 (127) les caractères en dehors de l'ASCII.
Pour représenter plus de caractère, les deux normes les plus utilisées sont
* UCS2 qui code les caractères sur 2 octets, cette norme ne permet d'utiliser que les caractères unicode dont le code est inférieur à 2^16
* UCS4 qui code les caractères sur 4 octets, limitant cette fois-ci les symboles aux 2^32 premiers. Comme il n'y a pour l'instant aucun caractères unicode au dela, cette norme est pour l'instant exhaustive.
UCS2 est la norme qui dont être utilisée en interne par Java.
[^] # Re: Codage des caractères ?
Posté par renoo . Évalué à 1.
[^] # Re: Codage des caractères ?
Posté par Zenitram (site web personnel) . Évalué à 5.
Sous Java (et Windows aussi), comment sont gérés les caractères Unicode>=65536? Impossible à gérer?
(sous Linux, c'est soit UTF-8, soit UCS4, donc pas de pb ;-) )
[^] # Re: Codage des caractères ?
Posté par François B. . Évalué à 5.
Il y est dit qu'à l'origine seuls 16 bits étaient utilisés pas Unicode, donc c'est ce qu'ils ont choisi comme représentation interne. Mais maintenant Unicode accepte des codes plus grands, donc ils ont dû adapter.
[^] # Re: Codage des caractères ?
Posté par Sébastien Koechlin . Évalué à 4.
* On ne fait rien, et une couche supplémentaire vient faire le travail. C'est ce qui est fait par exemple en XML/HTML: une entité permet de représenté un caractère unicode quelconque alors que le document est dans un codage qui ne permet pas de le représenter directement.
* On change tout pour augmenter la taille allouée à un caractère, en espérant que cette fois ci, on aura suffisement de place.
* On bricole pour rester compatible. UTF-8 est de ce coté un mécanisme très bien conçu: les programmes qui pensent qu'un caractère est un octet doivent continuer à fonctionner, mais un mécanisme doit permettre aux programme "aware" de placer des caractères supplémentaires. Au passage, il ne faut pas qu'un caractère codé sur plusieurs octets génère des octets qui seraient interprété comme un caractère de controle par un programme d'ancienne génération.
Pour le problème de Windows et de Java, on peut faire exactement la même extension, mais sur 16 bits. Ca s'appelle UTF-16. Un programme qui est purement UCS-2 verra des caractères, plusieurs caractères étrange à la place de ceux qui dépassent U+0FFFF, mais cela ne lui posera pas de problème. Un programme travaillant en UTF-16 sera capable de reconnaitre certaines séquences de caractères de 16 bits et de produire le caractère étendu correspondant.
[^] # Re: Codage des caractères ?
Posté par Sébastien Koechlin . Évalué à 4.
UTF-8 permet de représenter le code d'un caractère jusqu'à 21 bits, ces 21 bits sont répartis dans 4 octets.
Il serait possible d'étendre UTF-8 pour coder jusqu'à 31 bits, mais la norme d'aujourd'hui l'interdit (cela ferai 6 octets pour les caractères de code élevé).
En UTF-16, c'est plus compliqué, parce qu'on fait l'extension sur une plage de non-caractères (qui deviennent alors non-représentable, mais les utilise-t'on si ce sont des non-caractères), il est possible de représenter 20 bits, auquels viennent s'ajouter les 16 bits des caractères ordinaire (à l'exception de la plage des non-caractères).
En UCS-2, on peut représenter 16 bits
En UCS-4 on peut représenter 32 bits
En UTF-32, qui est un sous-ensemble de UCS-4, on peut représenter un peu moins de 21 bits, (de U+0 à U+10FFFF), parce que la norme interdit d'aller plus loin.
Finalement nous n'avons aucun mécanisme qui permettent de représenter un caractère de code arbitraire, quelque soit les extensions que nous feront à la norme Unicode si elle évolue encore.
[^] # Re: Codage des caractères ?
Posté par aedrin . Évalué à 4.
Faux. cf http://www.uzine.net/article1785.html (vers la fin de l'article) :
Par contre c'est vrai que c'est pas pratique, mais pour d'autres raisons (par exemple, tout simplement obtenir la taille d'une séquence de caractères).
[^] # Re: Codage des caractères ?
Posté par ccomb (site web personnel) . Évalué à 1.
[^] # Re: Codage des caractères ?
Posté par Maillequeule . Évalué à 10.
[^] # Re: Codage des caractères ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Combien de fichiers as-tu en UTF-8?
Pas beaucoup...
Meme tes fichiers de config sous pas mal de distrib Linux, on des encodage en latin9 dès qu'il y a des accents...
[^] # Re: Codage des caractères ?
Posté par Aldoo . Évalué à 5.
J'ai toujours qques problèmes avec des pages de man pas mises à jour, mais globalement mon système est UTF-8. J'ai aussi des fichiers en ISO-8859, mais le système se débrouille pour passer de l'un à l'autre, la plupart du temps sans qu'on ne se rende compte de rien.
La plupart des problèmes proviennent plutôt des mails, pages web, et autres données d'origine externe, qui soit oublient de préciser le charset et que je lis donc par défaut en UTF-8 alors qu'ils étaient codés en ISO, soit signalent un charset mais en utilisent un autre.
[^] # Re: Codage des caractères ?
Posté par Zakath (site web personnel) . Évalué à 2.
[^] # Re: Codage des caractères ?
Posté par Jonathan Schemoul (site web personnel) . Évalué à 1.
[^] # Re: Codage des caractères ?
Posté par herodiade . Évalué à 10.
* Il est OBLIGATOIRE d'utiliser la norme ISO 8859-15 Latin 9, pour l'encodage sur un octet des caractères. Règle 0001 Interopérabilité technique
* Il est OBLIGATOIRE d'utiliser UNICODE v4.1.0, pour l'encodage multi-octet des caractères. Règle 0002 Interopérabilité technique
Autrement dit : pour des caractères latins, il faut utiliser soit ISO 8859-15, soit UNICODE (qui est un surensemble d'UTF-8).
Bref, UTF-8 est ok. Formellement: sauf si on l'utilise pour encoder de l'ASCII pur (dans ce cas, UTF-8 n'utilise qu'un seul octet) ; mais dans ce cas il n'y a pas de différence d'encodage avec Latin9 donc on peut dire que le document est encodé en ISO 8859-15 autant qu'il est UNICODE/UTF-8, et on reste dans les prescriptions.
Si on voulais chipoter un peu, on pourrai plutôt noter que la spécification ne précise pas OBLIGATOIRE ... "pour les documents destiné à l'échange", ou n'indique pas que ASCII est OK, mais je pense que c'est implicite (vu que le document parle d'intéropérabilité).
Car de nombreux logiciels, libres ou pas, (en particulier les logiciels serveurs etc.) utilisent ASCII pour le traitement de certaines chaines, en interne (eg. envoi/reception d'une requette HTTP, negociation SMTP ou DNS, fichiers de confs, fichiers de code source pour certains languages interprétés, traitement des arguments en ligne de commande ...). Certes, générer du ASCII c'est aussi générer du ISO 8859-15 (qui est un surrensemble d'ASCII), mais en retour ces logiciels ne peuvent accépter n'importe quelle chaine ISO 8859-15 (et ne sont donc pas pleinement compatibles avec la spec).
# Interdit d'interdire
Posté par renoo . Évalué à -10.
Je pense que ces interdictions montrent une image sectaire et absolument pas pragmatique de cette initiative. La règle 27 est un exmple typique, si le document doit etre diffusé à quelqu'un qui n'utilise pas oo pourquoi le lui imposer ?
Je pense qu'il faudrait d'abord convaincre du bien fondé de ces règles, qui seraient alors très largement suivi.
D'autre part, l'emploi de ces termes "interdiction" est incompatible avec l'interview de Mr Mordacq qui déclare "notre rôle n’est pas coercitif".. et une interdiction sans coercition ce n'est pas une interdiction mais une recommandation.
[^] # Re: Interdit d'interdire
Posté par atlexx . Évalué à 10.
La formulation est un peu abrupte, mais est sans equivoque. on sait pertinament que lorsque l'on ouvre la voi pour un exception, elle devient souvent la règle.
[^] # Re: Interdit d'interdire
Posté par Zenitram (site web personnel) . Évalué à 3.
OK, ou habites-tu?
Comme tu n'aime pas les interdictions, tu ne verras aucun inconvénient que je vienne chez toi et te voles tout, en plus de te tuer.
comme tu veux rien d'interdit, ca ne me serait pas interdit, donc je ne me génerai pas.
Tout ca pour dire que pour faire respecter une démocratie, il y a des choses à interdire...
Et que vient faire OpenOffice dans l'histoire???
OpenDocument est une norme, que meme MS peut implémenter dans MS office, ce n'est pas limité a Oo, donc si tu ne peux lire le format, c'est uniquement par la volonté de l'éditeur de ton traitement de texte
Ils n'imposent aucun logiciels, et toutes les normes obligatoires sont libre de droits, n'importe qui peut les implémenter dans 100% des logiciels sans aucun cout financier en royalties...
[^] # Re: Interdit d'interdire
Posté par renoo . Évalué à -10.
Bon alors la question qui lit correctement OpenDocument ? puisque cela n'impose pas de logiciel.
[^] # Re: Interdit d'interdire
Posté par psychoslave__ (site web personnel) . Évalué à 7.
Voila, tiens d'ailleurs je vois que scribus fait de l'import! Ça existe l'équivalent genre importer du word dans adobe chez-pas-quoi?
[^] # Re: Interdit d'interdire
Posté par Colin Leroy (site web personnel) . Évalué à 10.
Les specs de standards doivent être très directives si leur(s) auteur(s) veut bien se faire comprendre, et que les développeurs d'applications implémentant lesdits standards n'aient pas de latitude pour interpréter comme ils le sentent...
[^] # Re: Interdit d'interdire
Posté par desertpingouin . Évalué à 8.
Par ailleurs, c'est un style typique de documents venant de l'administration publique, c'est leur marque de fabrique.
[^] # Re: Interdit d'interdire
Posté par herodiade . Évalué à 10.
Je crois que tu es mal renseigné et que tu a mal lu.
OpenDocument est une spécification ouverte et qu'on peut librement implémenter (Microsoft et Corel peuvent le faire, s'ils souhaitent que leurs suites bureautiques répondent aux spécifications).
Par ailleur OpenDocument n'impose nullement l'utilisation du logiciel OpenOffice.org, les applications compatibles (libres ou propriétaires) sont maintenant très nombreuses, cf. une liste de ces applications ici: http://en.wikipedia.org/wiki/List_of_applications_supporting(...)
Au passage, c'est assez fascinant, pour un standard normalisé il y a moins d'un an (Mai 2005): on a déjà 8 traitements de texte, 6 tableurs, ... compatibles !
Et c'est justement là un avantage, en terme d'interopérabilité, d'utiliser un format ouvert et libre: celà contribue à nous (et nos correspondants) rendre plus indépendants, moins liés à un éditeur de logiciel précis (bref, l'inverse de ce que tu dit).
[^] # Re: Interdit d'interdire
Posté par renoo . Évalué à -7.
Je partage tout à fait le soucis d'interopérabilité ; je conteste les moyens (interdiction bureaucratique ?) de les obtenir. Encourager l'usage des formats ouverts d'accord ; interdire tout ce qui n'est pas opendocument pas d'accord. L'interdiction va radicaliser les positions et je ne suis pas sur que cela favorisera in-fine l'usage des formats ouverts et libres.
Sur les très nombreuses applications qui lisent le opendocument, il manque des applications importantes AppleWorks, WordPerfect, Office, FrameMaker... si on raisonne en part d'usage, je pense que 90% des utilisateurs ne peuvent pas lire l'opendocument avec les logiciels qu'ils utilisent courrament. Penses tu que cela va réelement favoriser les échanges avec les usagers des services publics ? Pourquoi interdire -regle 27- les échanges vers les vieux formats ouverts et libres (.txt, .rtf...) ?
[^] # Re: Interdit d'interdire
Posté par Donk . Évalué à 6.
Je ne vois pas où la règle 27 interdit celà
[^] # Re: Interdit d'interdire
Posté par Pierre Tramonson . Évalué à 4.
[^] # Re: Interdit d'interdire
Posté par Serge2 . Évalué à 5.
[^] # Re: Interdit d'interdire
Posté par herodiade . Évalué à 9.
Oh et j'oubliai, dans ma réponse précédente (s/oo/OpenDocument/):
- La spécification n'impose pas OD dans ce cas (diffusion) : il est seulement recommandé (pas obligatoire) d'envoyer ses documents en OD. Elle impose seulement d'accepter les docs OD. Celà permet de dire: "on n'exige de nos correspondant l'utilisation de Microsoft Word/Excel/..." ou encore: "les correspondants de l'administration peuvent utiliser des logiciels libres et gratuits pour nous envoyer des docs, s'ils le souhaitent", ce qui est la moindre des choses.
- Dans le cas (probablement fréquent) où un l'on ne sait pas quel logiciel ou quelle version du logiciel utilise le(s) destinataire(s), recommander la diffusion des documents au format OpenDocument laisse, à l'inverse de ce que tu dit, un grand choix au destinataire (actuellement, moins d'un an après qu'OASIS ai validé le format, pas moins de 8 traitements de textes et 6 tableurs différents etc.). À l'inverse, le nouveau format (OpenXML) des documents générés par MS Office n'est a ma connaissance pleinement supporté que par les versions récentes de la suite bureautique de Microsoft.
- Les documents générés par nos administrations ne sont pas forcément toujours seulement destinés à un utilisateur précis ; en particulier il peut y avoir des contraintes d'archivage, traitements automatisés (indexation/recherche etc.) au delà de ce qu'à prévu l'éditeur du traitement de texte/tableur/..., et celà n'est vraiment pleinement possible qu'avec un format dont les specs sont ouvertes et librement implémentables (vs. contraintes fonctionnels imposées par les choix d'un éditeur de logiciels).
- Dans une optique de reduction des dépenses, certaines administrations pourraient choisir d'utiliser des logiciels libres et gratuits pour la bureautique (les suites bureautiques propriétaires sont souvent très chères !). En fait, la gendarmerie à déjà fait ce choix. Il est absolument légitime sinon de faciliter, du moins de rendre possible les échanges avec les institutions ayant pris une telle initiative.
- La DGME a certainement pensé à la perenité de ses archives, que seul un format ouvert et libre peut assurer. Un format fermé (ou non documenté) vérouillé (brevets) par un éditeur peut n'être plus supporté dans quelques années ou décennies (cout de la maintenance du logiciel, stratégie pour forcer les utilisateurs à mettre à jour, disparition de l'éditeur ou de son produit, changement des plateformes supportés ...). En utilisant un format ouvert et libre, l'administration se réserve la possibilité de développer ou maintenir des logiciels compatibles avec ses archives et ses choix du moment (plateformes, besoins fonctionnels etc.).
- Dans tout les cas, il y va de la souveraineté de l'État concernant la maîtrise de ses documents et de son SI. Un format propriétaire et fermé laisse le SI / l'acces aux documents sous le contrôle d'un éditeur précis et de ses décisions, stratégies ... (et de celles de l'État où cet éditeur est basé).
[^] # Re: Interdit d'interdire
Posté par renoo . Évalué à -3.
Je pense que le .txt/.rtf ou meme le .pdf est beaucoup plus lisible par tous que le open-document. Prendre un format qui est normalisé depuis un an et prétendre que les usagers doivent pouvoir le lire parceque 8 traitements de texte le lisent ne me semble pas aller dans le sens d'un meilleur service aux usagers... maintenant ici il ne s'agit que de recommandations donc elles sont transgressables avec des bonnes raisons et peut etre qu'en interne si les différents services se mettent d'accord l'opendocument est interessant.
[^] # Re: Interdit d'interdire
Posté par Yth (Mastodon) . Évalué à 3.
Rien n'est imposé en interne, rien n'est imposé concernant ce qu'on envoie aux autres.
N'est imposé que le fait que si quelqu'un t'envoie un document au format OpenDocument, le destinataire DOIT l'accepter et se démerder pour le lire, ce qui est aisé sachant que nombre de logiciels libres (ou pas) savent le faire.
C'est pas plus compliqué que de lire du pdf...
Yth.
[^] # Re: Interdit d'interdire
Posté par Barnabé . Évalué à 2.
Les utiliser pour transmettre un document éditable fait perdre une part essentielle de l'information.
[^] # Re: Interdit d'interdire
Posté par Tom D . Évalué à 4.
J'imagine ta colère lorsque ton système te donne des messages du genre:
rm: cannot remove `clientlog.txt': Permission denied
"Permission denied"? De quel droit? Il devrait plutôt dire:
rm: cannot remove `clientlog.txt': this file is a bit owned by an other user (not that he paid for it, but he kind of write it, so, you understand...), it would be nice of you not to erase it. But since you are a good person, I trust that if you want to remove it, you have a good reason to do so and I will allow you, but please don't do that too often.
;-)
Tom
# Formats son et video : MP3 ?! et le Ogg ??
Posté par Nicolas Deveaud . Évalué à 7.
Je ne suis pas spécialiste de la question, mais ne serait-il pas préférable de conseiller le Ogg ?
Si oui, il serait interessant de le signaler sur le wiki, mais n'étant aps sur de moi je ne l'ai pas fait.
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par briaeros007 . Évalué à 6.
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par herodiade . Évalué à 6.
- "Il est RECOMMANDÉ d'utiliser le format " GIF animé " pour les animations graphiques simples et/ou de courte durée". Pourquoi pas PNG (qui est par ailleur recommandé pour les images "statiques", et surtout qui n'est pas breveté) ?
- "Il est RECOMMANDÉ d'utiliser Flash v7.2 ou Flash v8 pour les animations graphiques complexes et/ou de plus longue durée". Pourquoi pas SVG ?
En plus cette règle me semble incompatible avec la règle d'IHM: "Il est INTERDIT d'utiliser des composants logiciels type ActiveX ou toute autre extension de navigateur (Flash hors animation, VML, etc.) au niveau des IHM Web. Règle 0044 Interopérabilité technique". Bizzare, j'ai du mal comprendre un truc.
- MPEG-2 / MPEG-4 pour les conataineurs vidéo (et codec, dans le cas de MPEG-2): pourquoi pas Théora, Matroska ou Vorbis (qui sont plus performants et libres/ouverts si je ne m'abuse) ?
- MPEG-4 pour les "séquences vidéo haute définition.": à quel moment est-on "haute définition" ? et pourquoi aucun codec n'est préconisé ? (eg. MPEG-4 avec DivX ? ou XviD ? ou H.323 ? AAC ? MP3 ? ...)
- Pourquoi ne rien indiquer (eg. XHTML v1.1 + CSSv2) pour la "présentation en ligne de documents semi-structurés" ? D'ailleur, leur wiki est "XHTML 1 Transitional" (et pas HTML 4.01, comme ils le recommandent pour le web: ils devraient être plus souples sur ce point je trouve, et recommander au choix HTML 4.01 ou XHTML v1 ou v1.1).
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par geh . Évalué à 10.
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par Sébastien Koechlin . Évalué à 6.
Concernant SVG, j'espère bien que l'on va y venir; mais aujourd'hui, les implémentations ne permettent pas vraiment de l'utiliser.
Les deux grandes implémentations à ma connaissance sont Mozilla Firefox sur des versions franchement récentes, et un plugin pour Internet Explorer. Qu'en est-il des autres navigateur. De plus, on parle ici d'animation, l'animation se fait par l'utilisation de javascript sur l'arbre XML du SVG, les résultats sont franchement déconcernants et les deux implémentations sont très divergentes.
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par Mithfindel (site web personnel) . Évalué à 2.
Je ne suis peut être pas très au courant mais je connais peu (voire pas, à part le Gimp) de logiciels qui sache interpréter le MNG.
Parce que c'est "facile" de produire une "video" en Flash (même avec des outils libres) alors que très peu (voire pas, encore une fois) d'implémentations libres de SVG supportent l'animation (à mon grand dam). S'il faut passer par le plugin SVG Adobe et son API DOM non standard...
Et puis s'il y a consultation et appel à commentaires, c'est sans doute pour permettre à tout le monde de s'exprimer et donner des raisons pour l'adoption de telle ou telle technologie :)
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par Nicolas Deveaud . Évalué à 1.
Je parlais du MP3/Ogg car le Ogg est quand même assez largement diffusé (on trouve des balladeurs qui lisent du Ogg etc....
Donc le MP3 n'a pas de raison d'être préféré au Ogg.
Concernant le GIF/MNG ou le Flash/SVG, la problèmatique n'est pas la même étant donné que les formats "libre" ne sont pas très diffusés.
Evidemment il serait mieux pour tout le monde que le SVG soit préféré aux Flash, et évidement le MNG devrait être utilisé de préférence au GIF. Mais actuellement en recommendant des format de ce genre, on peut être sur que personne ne suivra ces recommendations (ce qui n'est pas le cas avec le Ogg qui peut être assez facilement lu). Donc je trouve qu'il est normal dans ce cas de se tourner plutôt vers la solution la "moins pire" en attendant qu'une vraie solution arrive.
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par Brice Carpentier . Évalué à 7.
Oui, tu n'as sans doute pas compris que les bouts de phrase suivant "pour les animations graphiques complexes et/ou de plus longue durée" et "au niveau des IHM Web" ne sont pas identiques.
En gros, ce que je comprends de la règle, c'est que si tu veux faire une animation, il t'est recommandé d'utiliser Flash. Si on parle d'une application web avec une ihm complexe, tu ne dois pas utiliser Flash. Il s'agit de deux champs d'action différent.
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par Zenitram (site web personnel) . Évalué à 1.
Qui connait OGG : 100 fois moins de personnes que le MP3.
Donc je les comprend d'avoir choisi MP3 dans ce cas, comme ils choisissent MPEG-4 pour la vidéo (et pour la vidéo, tu proposes quoi? Pas Theora car pas encore très stable, bref... il y a rien, donc voila, faut bien payer au groupe MPEG dans tous les cas... En attendant dans quelques années que tout ca se déquante.)
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par Nicolas Deveaud . Évalué à 3.
Donc effectivement comme je le disais un peu plus haut, il est compréhensible de favoriser le Gif animé au MNG, ou le flash au SVG. Mais pour le Ogg, c'est moins compréhenssible car le Ogg est très facilement utilisable il me semble.
(enfin en tout cas le débat à été lancé sur le wiki en question.... on verra ce que ça donne)
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par rewind (Mastodon) . Évalué à 6.
[^] # Re: Formats son et video : MP3 ?! et le Ogg ??
Posté par atlexx . Évalué à 1.
cela dit, il est vrai que le ratio d'utilisation de ogg/mp3 ne doit pas être moins bon que celui OpenDocument/MSOffice . Le premier pas OpenDocument aurai pu être suivi ...
# Discuter des règles, c'est bien mais sur le Wiki, c'est mieux
Posté par Aurélien Croc (site web personnel) . Évalué à 10.
J'ai déjà débattu des questions relatives à l'OGG, MNG, Flash etc. À vous de rajouter vos idées / de compléter :)
# L'administration, ça avance vraiment à un rhythme de sénateurs...
Posté par Christophe Merlet (site web personnel) . Évalué à 6.
http://www.senat.fr/Vforum/cgi-bin/Vforum-1.6.cgi?action=lir(...)
Au moins, cette ordonnance a été mise à jour, on est passé de l'iso-8859-1 à iso-8859-15 ;o)
RDV dans 7 ans... a ce moment là l'UTF-8 aura le vent en poupe...
# Wiki est mort...
Posté par qdm . Évalué à 1.
[^] # Re: Wiki est mort...
Posté par Maillequeule . Évalué à 5.
[^] # Re: Wiki est mort...
Posté par psychoslave__ (site web personnel) . Évalué à 5.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.