Journal NextCloud et le format ODF : des gros nuages orageux

Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 25 mars 2026 à 16:07. Licence CC By‐SA.

Étiquettes :

mar.

2026

Salut les gens et les autres,

Ce qu’il y a de bien avec NextCloud, c’est que la suite bureautique en ligne adoptée est Collabora Online, un avatar de LibreOffice et donc une suite bureautique dont le format natif est le format ODF.

Sauf que... on peut configurer le format d’enregistrement par défaut des suites bureautiques. Et là les gros nuages s’accumulent. Les personnes qui s’occupent de Collabora Online dans NextCloud ont décidé, malgré tous les arguments qui leur ont été fournis, que le format d’enregistrement proposé par défaut devait être OOXML. Ce qui n’est guère malin et qui peut, d’ailleurs, perdre des utilisateurs et des utilisatrices.

Le commit qui a été déposé pour changer ça s’est fait recadrer par un « non » au motif que « les utilisateurs et utilisatrices pourraient se plaindre que ça ne soit pas au format OOXML ». On peut imaginer que la voix de celles et ceux qui se plaignent de cette bizarre configuration et réclament la configuration d’origine (format ODF par défaut), aurait moins de valeur que celles des personnes qui réclameraient absolument de l’OOXML. C’est d’ailleurs intéressant de voir que cette décision va à contre-courant de certaines tendances.

Pour en savoir plus, l’information vient de ce pouet sur Mastodon. Le fil est en anglais et en français et il y a les liens vers les dépôts.

Il appelle à faire circuler l’information, voire plus (et là je ne sais pas trop que faire de plus).

PS : si vous voulez que votre fichier soit au format ODF, quand vous le créez, remplacer l’extension OOXML par une extension ODF (ODT, ODS, ODP ou ODG). Sinon, vous pouvez aussi l’Enregistrer sous et choisir le format ODF. On notera que, assez bizarrement, Collabora Online propose d’enregistrer aussi aux formats RTF et DOC (ne faites pas ça).

# Faire plus

Posté par nojhan (site web personnel, Mastodon) le 25 mars 2026 à 16:28. Évalué à 10.

Faire « plus », c’est répondre avec un commentaire et un pouce en bas sur l’ issue et la PR, partager l’info (ça, c’est fait), refaire une autre PR, exiger une réaction de Open Document, etc.
- [^] # Re: Faire plus
  
  Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 25 mars 2026 à 16:49. Évalué à 10.
  
  Là je vois qu’Italo Vignoli, l’un des co-fondateurs de LibreOffice, a réagi (en). Et son argumentaire est très intéressant car il ajoute une pierre à l’édifice, je traduis (enfin si je puis dire, j’ai délégué) :
  
  Le choix de privilégier par défaut des formats de documents propriétaires est une erreur en soi, mais à la lumière de la récente publication du Deutschland-Stack, qui impose par défaut le format ODF – sans même mentionner OOXML –, c’est encore pire. Une entreprise basée en Allemagne qui va à l’encontre d’une décision du gouvernement allemand et soutient ouvertement la stratégie de verrouillage de Microsoft n’est pas une amie de l’open source, mais une amie de Microsoft et une partisane des grandes entreprises technologiques américaines, au détriment des intérêts des citoyens européens. Félicitations !!!
  
  Je n’ai aucun avis sur systemd
  - [^] # Re: Faire plus
    
    Posté par Ant le 26 mars 2026 à 20:50. Évalué à 1. Dernière modification le 26 mars 2026 à 20:52.
    
    Message supprimé
- [^] # Re: Faire plus
  
  Posté par Maclag le 25 mars 2026 à 16:55. Évalué à 10.
  
  Moi je ferais un rapport de bug aussi: "Je croyais que j'utilisait Collabora, mais le format par défaut n'est pas celui de Collabora. Je suppose que c'est une erreur?"
# Réglage dans l’administration de Nextcloud

Posté par Voltairine le 25 mars 2026 à 17:03. Évalué à 10. Dernière modification le 25 mars 2026 à 17:05.
C'est une très mauvaise décision et j'ai beaucoup de mal à croire les arguments avancés dans le signalement demandant le OOXML par défaut.

Sinon, pour celles et ceux qui administrent leur Nextcloud¹ le réglage se fait dans :
Paramètres d'administration > Office > décocher « Utiliser par défaut Office Open XML (OOXML) au lieu de OpenDocument Format (ODF) pour les nouveaux fichiers »
1. sinon demandez à votre prestataire de le faire (et au passage de faire remonter l'info aux mainteneurs de Nextcloud) ↩
# mouaif

Posté par Krunch (courriel, site web personnel) le 25 mars 2026 à 17:04. Évalué à 6. Dernière modification le 25 mars 2026 à 17:05.

Je pense que les commentaires sur la PR et le bug sont clairs et que c'est pas en ajoutant des emojis ou des commentaires là que l'avis de qui que ce soit va changer.

Je sais pas comment Collabora fonctionne mais de mon expérience, les devs ils font ce que leur (product) management décide. Les commentaires de bug/PR ça fait un peu de bruit facile à ignorer pour les devs mais pas tellement pour le (product) management qui a d'autre signaux pour prendre ses décisions.

L'argumentaire semble être que si Madame Michu n'a pas des docx par défaut, elle va faire perdre plus de temps au support que si Kévin Hacker n'a pas des odf par défaut. Et Kévin va plus vite trouver comment changer cette option de configuration (avec ou sans l'aide du support).

Si on veut faire changer quelque chose, il faut utiliser des canaux que le (product) management va avoir plus de mal à ignorer que des commentaires github.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
- [^] # Re: mouaif
  
  Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 25 mars 2026 à 17:16. Évalué à 5. Dernière modification le 25 mars 2026 à 17:16.
  
  Je doute qu'Italo Vignoli s'en tienne à un simple commentaire sur un dépôt :-) Et j'attends de voir la suite au niveau de TDF.
  
  Je n’ai aucun avis sur systemd
- [^] # Re: mouaif
  
  Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 25 mars 2026 à 18:05. Évalué à 4.
  
  « Je sais pas comment Collabora fonctionne mais de mon expérience, les devs ils font ce que leur (product) management décide. Les commentaires de bug/PR ça fait un peu de bruit facile à ignorer pour les devs mais pas tellement pour le (product) management qui a d'autre signaux pour prendre ses décisions. »
  
  Un des signaux reçu par le management pourrait être une somme rondelette et une collaboration proposées par Redmond : « On vous aide à faire une belle intégration de notre cheval de Troie dans votre produit. Kévina Barbue râlera, mais comme l'essentiel des messieurs Michu Numincompetence réclameront à corps et à cris des docx, cela vous aidera à éliminer la concurrence libre (en aparté pour le spectateurs lassés qui ont déjà vu la manœuvre maintes fois répétées :) et ensuite couic... » N'est ce pas ce que laissait entendre le lien récent sur ce sujet dans la revue de presse de l'April ?
  
  « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
  - [^] # Re: mouaif
    
    Posté par thoasm le 25 mars 2026 à 19:58. Évalué à 9.
    
    Il y a plein de liens dans cette revue de presse, donc si tu veux vraiment être pris au sérieux pointe directement le passage qui te laisse penser ça. Je sais bien que Microsoft a eu et a sans doute toujours des pratiques peu recommandables mais bon là il n'y en a pas besoin pour imaginer un truc pareil, et c'est peut être même pas sur leurs radars ils doivent avoir d'autres chats à fouetter.
    - [^] # Re: mouaif
      
      Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 25 mars 2026 à 19:59. Évalué à -2.
      
      Nous n’avons pas tout à fait la même définition de plein...
      
      « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
      - [^] # Re: mouaif
        
        Posté par thoasm le 25 mars 2026 à 20:19. Évalué à 6.
        
        Je conclus de cette réponse que c'est juste un troll, quoi.
        
        [^] # Re: mouaif
        
        Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 25 mars 2026 à 20:37. Évalué à -2.
        
        Il y a cinq thèmes dans la revue de presse en question, dont un décrit par quatre à cinq mots dont LibreOffice et Ooxml ???
        
        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
        
        [^] # Re: mouaif
        
        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 25 mars 2026 à 22:04. Évalué à 9.
        
        Pourquoi ne, tout simplement, pas donner le lien qui fait penser qu'il pourrait y avoir un genre de graissage de patte au lieu de polémiquer ?
        
        Je n’ai aucun avis sur systemd
        
        [^] # Re: mouaif
        
        Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 26 mars 2026 à 07:52. Évalué à 0.
        
        Je polémique ?
        Initialement, parce que je préférais citer la revue de presse. Il ne me semblait pas inintéressant de rappeler que l'information avait été signalée ici. J'aurais certainement pu choisir de citer directement la cible du lien. Les goûts et les couleurs...
        Ensuite, je l'aurais bien fait, mais l'objet que j'avais entre les mains (écrans tactiles) me permettait difficilement ce genre de manipulation.
        Désormais il me semble percevoir qu'il s'agisse plutôt d'une sorte d'injonction arbitraire dénuée d'intérêt sur le fond. Une sorte d'expérience sociale : est-ce que je peux pousser quelqu'un à agir selon mon désir. Bizarre.
        
        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
        
        [^] # Re: mouaif
        
        Posté par thoasm le 26 mars 2026 à 09:09. Évalué à 4.
        
        Je ne suis toujours pas quels sont tes éléments que tu as pour étayer ton FUD, car c'en est un en l'état. Et ce n' est certainement pas une expérience sociale quoi que tu entendes par là. C'est à toi de prouver ton point. On est assaillis de fake news et de saloperies de toutes part, tu en rajoutes une, en l'état. Et ça va au delà de trouver le bon lien, même en zieutant l'article vite fait je ne sais pas à quoi tu fais référence.
        
        [^] # Re: mouaif
        
        Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 26 mars 2026 à 10:33. Évalué à 1.
        
        Dans ce cas, bienvenue au club des nullissimes en communication. Donc, vous me dites que vous ne trouvez pas le lien que j'indique parmi cinq, puis vous m'accusez de troller, pour enfin parvenir à laisser entendre que toutes ces interventions signifiaient que vous avez classé mon questionnement relatif à ce qui se passe en coulisse dans cette affaire relève d'une technique commerciale. Sachez que je n'ai rien à vendre, si ça peut vous rassurer.
        
        Peut-être avez vous manqué le conditionnel qui introduit ma proposition, et le point d'interrogation qui la conclue ? et partant m'avez-vous très mal lu ? Ou bien, comme de coutume, mon charabia était-il outrageusement sibyllin ? Alors au cas où, voici une reformulation. J'espère que vous conviendrez avec moi qu'il ne s'agit pas de FUD.
        
        J'ai un peu du mal à croire que des dirigeants d'entreprises basées sur le libre choisissent sans de très bonnes raisons de promouvoir des formats qui servent depuis plus de trente ans de chevaux de Troie à leur principal concurrent. Donc je cherche à interpréter les événements rapportés. Pour moi l'hypothèse la plus plausible est une collusion ; ou au moins une stratégie anti Libre et anti ouverture de la part de Collabora. Dans ces colonnes nous avons déjà eu l'exemple de nombreuses entreprises exploitant du Libre en tant qu'éphémère argument et stratégie commerciaux ; le temps de capter une clientèle, et avant de tenter de la capturer. Collabora ne serait donc pas la première à essayer. Cette hypothèse, que je souhaitais discuter, paraît loin d'être farfelue ; du moins de loin : je n'ai aucune connaissance sur cette entreprise. Mais peut-être disposez-vous d'éléments probant le contraire ? Le cas échéant mon objectif n'était pas d'être vilipendé mais de vous pousser à les partager. Pas vous uniquement, mais quiconque en saurait plus. Évidemment, je préférerais infiniment que tous les acteurs du Libre soient de féroces partisans de cette idéologie politique. Et j'apprécierais infiniment que quelqu'un puisse balayer définitivement mes doutes sur le sujet qui nous occupe ici. En attendant, mon opinion est faites.
        
        NB : et faites moi la grâce d'accepter que je sache encore distinguer opinion et savoir. La première n'étant pas nécessairement très informée.
        
        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
        
        [^] # Re: mouaif
        
        Posté par thoasm le 26 mars 2026 à 11:43. Évalué à 2.
        
        Je ne connais non plus personne d'impliqué et ne suis impliqué dans rien, je tiens à le préciser.
        
        Mais ... c'est moi ou tu es à la limite d'accuser des gens d'être corrompus publiquement sur la base de ta seule opinion ? On dépasse un poil le stade de la liberté d'opinion dans ce cadre tu ne trouves pas ?
        
        "On peut plus rien dire, j'ai bien le droit de penser ce que je pense" c'est pas du tout une réponse à mes messages.
        
        [^] # Re: mouaif
        
        Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 26 mars 2026 à 14:07. Évalué à 3.
        
        À mon sens moral extrêmement personnel, voire complètement idiosyncratique, il s'agirait bien de corruption. Mais du point de vue du droit, je ne vois pas du tout où serait le mal. Les entreprises sont libres de leur stratégie. Vous pouvez préciser où serait l'accusation (au sens juridique) dans mon propos ?
        
        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
        
        [^] # Re: mouaif
        
        Posté par thoasm le 26 mars 2026 à 14:29. Évalué à 1.
        
        Je trouvais effectivement que le terme de corruption, après réflexion, était trop fort (mais trop tard pour éditer mon message). Mais en cherchant ... ben une entente commerciale de cette nature est peut être de nature à fausser la concurrence : https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000006231970
        
        [^] # Re: mouaif
        
        Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 26 mars 2026 à 14:41. Évalué à 5.
        
        Apparemment les pouvoirs publics (excepté la gendarmerie, et en particulier l'éducation nationale en France) s’accommodent parfaitement de cette absence totale et clairement librement consentie de concurrence. Si d'autres entreprises trouvaient à s'y associer, il faudrait être un peu partial pour s'attaquer au petit Poucet parce qu'il laisse traîner de la mie de pain qui risque de nuire aux écosystèmes en nourrissant des oiseaux, alors que le chemin de l'ogre est entièrement cramoisie des tombereaux du sang de ses victimes.
        
        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
        
        [^] # Re: mouaif
        
        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 26 mars 2026 à 12:18. Évalué à 5.
        
        Quel est le rapport avec Collabora ? C'est une décision de NextCloud.
        
        PS : le conditionnel n'exonère pas de tout. Un propos à la limite de la diffamation reste potentiellement diffamatoire.
        
        Je n’ai aucun avis sur systemd
        
        [^] # Re: mouaif
        
        Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 26 mars 2026 à 14:46. Évalué à 3.
        
        Au temps pour moi. Et il ne faudrait pas pour autant me charger du poids de tous les ~~(削除) malheurs (削除ここまで)~~ ooxml du monde. Mon propos consiste juste à souligner que quiconque choisi ce format — dont nul n'ignore la charge délétère tant économiquement qu'historiquement et symboliquement — est nécessairement (moralement) suspect (pour moi au moins).
        
        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
        
        [^] # Re: mouaif
        
        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 26 mars 2026 à 14:58. Évalué à 5.
        
        C'est surtout, lire avant de commenter serait une bonne idée, et le journal, à commencer par son titre, porte clairement sur NextCloud.
        
        Je n’ai aucun avis sur systemd
        
        [^] # Re: mouaif
        
        Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 26 mars 2026 à 16:22. Évalué à 3. Dernière modification le 26 mars 2026 à 16:22.
        
        Tout ce qui a trait aux nuages est nébuleux pour moi. Désolé pour la méprise. J'ai pourtant lu l'article. L'évidence des uns n'est pas celle des autres. La discussion qui précède en est d'ailleurs une belle démonstration.
        
        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
        
        [^] # Re: mouaif
        
        Posté par thoasm le 26 mars 2026 à 16:27. Évalué à 3.
        
        Surtout si tu prends evidence dans sa forme anglaise dans le sens de « preuve » pour faire encore plus écho à la discussion :)
    - [^] # Re: mouaif
      
      Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 25 mars 2026 à 22:06. Évalué à 6.
      
      Je pense surtout que NextCloud prend un assez gros risque si, ce que je ne sais pas, l'entreprise perçoit, d'une façon ou d'une autre, des fonds publics allemands, voire, européens.
      
      Je n’ai aucun avis sur systemd
- [^] # Re: mouaif
  
  Posté par Maclag le 25 mars 2026 à 19:05. Évalué à 10.
  
  On peut poser une question un peu plus large: qui utilise Nextcloud Office et à qui sont destinés les documents produits?
  
  Parce que honnêtement, je pense que Mme Michu s'en carre l'oignon que son document soit enregistré en ODF. C'est uniquement si le destinataire n'arrive pas à l'ouvrir qu'elle va rapporter un problème (et quand je dis rapporter: je doute que les madames Michu du monde écrivent des rapports de bug).
  
  Et l'inverse pourrait devenir vrai rapidement: Fraulein Mischü pourrait commencer à se plaindre que l'administration rejette ses documents Nexctloud Office.
- [^] # Re: mouaif
  
  Posté par Jean-Baptiste Faure le 25 mars 2026 à 20:25. Évalué à 10.
  
  De ce que je comprends le problème est chez Nextcloud, pas chez Collabora. Il s'agit d'une modification par Nextcloud de la configuration par défaut de Collabora Office dans Nextcloud. Donc Collabora me semble pour rien dans ce choix.
- [^] # Re: mouaif
  
  Posté par Voltairine le 25 mars 2026 à 20:42. Évalué à 9.
  
  Collabora a toujours soutenu ODT et c'est bien le format d’enregistrement par défaut.
  
  L'argumentaire semble être que si Madame Michu n'a pas des docx par défaut, elle va faire perdre plus de temps au support que si Kévin Hacker n'a pas des odf par défaut.
  
  Ce n'est pas l'argument donné (gras ajouté) :
  
  We agree with the sentiment, and prefer ODF. But reality for most of our customers is that the use of ODF causes challenges for their users and harms the perception of Nextcloud Office. The users end up thinking it is a bad product because it creates "weird" documents that people they send them to can’t open or understand.
  
  Le souci serait que les clients de leur clients ne savent pas se débrouiller avec le format ODT. Le clients de Nextcloud GmbH sont des prestataires professionnels qui fournissent le service à des clients. Si cela pose un problème il leur suffit de changer le format par défaut comme je l'ai indiqué dans mon autre commentaire. Donc pour moi l'argument ne tient pas du tout.
  
  Le problème de base c'est peut-être que Nextcloud dans sa communication prétend être ce qu'il n'est pas : « The better Microsoft 365 for private clouds » (Comme Microsoft 365 – en mieux sur la VF)
  Nextcloud est un outil formidable mais non ce n'est pas comme ou mieux que Microsoft 365. C'est différent et heureusement.
  - [^] # Re: mouaif
    
    Posté par floriang le 29 mars 2026 à 13:24. Évalué à 3.
    
    Je réagis sur ce point de l'argument donné :
    
    The users end up thinking it is a bad product because it creates "weird" documents that people they send them to can’t open or understand.
    
    Le problème est le même avec la bureautique Apple MacOS : le traitement de texte et le tableur créent des fichiers bizarres que les autres gens ne peuvent pas ouvrir. ;-)
- [^] # Re: mouaif
  
  Posté par jp.louvel le 26 mars 2026 à 10:44. Évalué à 6.
  
  Petit update : juliusknorr, Director Office & Productivity chez Nextcloud, vient d'indiquer sur l'issue que le sujet est en discussion interne. À suivre.
- [^] # Re: mouaif
  
  Posté par fearan le 30 mars 2026 à 09:51. Évalué à 2.
  
  L'argumentaire semble être que si Madame Michu n'a pas des docx
  
  Madame Michu ne voit pas le .odf ou .docx.
  
  Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# « nuage » de l'éduc' nat

Posté par cévhé le 25 mars 2026 à 22:30. Évalué à 10.

L'éducnat propose à ses agents un Nextcloud (francisé en nuage, paskon cause pas l'engliche)

Curieux de voir si le format par défaut restera ou pas ODF. J'ai posé la question sur le tchap dédié, si j'ai une info je la transmettrai.
- [^] # Re: « nuage » de l'éduc' nat
  
  Posté par cévhé le 25 mars 2026 à 23:56. Évalué à 10.
  
  Réponse super rapide, claire et comme on aime :
  
  Nous restons sous format libre, conformément à nos valeurs.
  - [^] # Re: « nuage » de l'éduc' nat
    
    Posté par jadfa le 27 mars 2026 à 10:37. Évalué à 1.
    
    Quelles valeurs?
    Celles qui permettent de poursuivre ses contrats avec Microsoft ?
    - [^] # Re: « nuage » de l'éduc' nat
      
      Posté par lolop (site web personnel) le 27 mars 2026 à 10:50. Évalué à 8.
      
      Tu penses que l’educ. nat. est un gros bloc monolytique ?
      
      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
      - [^] # Re: « nuage » de l'éduc' nat
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 27 mars 2026 à 11:01. Évalué à 6.
        
        J'aime bien dire que les troubles dissociatifs, s'ils constituent des maladies pour des individus humains, sont un état normal des organisations humaines.
    - [^] # Re: « nuage » de l'éduc' nat
      
      Posté par cévhé le 27 mars 2026 à 11:47. Évalué à 8.
      
      Celles des personnes qui sont derrière le déploiement de ces outils libres.
      
      https://projet.apps.education.fr/
      
      Je crois que c'est quand meêm un beau projet et dans la mesure où c'est à la fois utilisé et utilisable, c'est aussi une belle réussite.
# "Microsoft was making OOXML deliberately more complicated than it needed to be"

Posté par oliverpool (site web personnel) le 26 mars 2026 à 08:23. Évalué à 3.

Un article de blog paru il y a 2 jour, évoque OOXML:

https://matduggan.com/markdown-ate-the-world/#:~:text=OOXML%20deliberately%20more%20complicated%20than%20it%20needed%20to%20be

There was an accusation at the time that Microsoft was making OOXML deliberately more complicated than it needed to be — that the goal was to claim it was an "open standard" while making the standard so incomprehensibly vast that it would take a heroic effort for anyone else to implement it. I think this is unquestionably true. LibreOffice has a great blog post on it

Traduction assistée par LLM:

À l’époque, on accusait Microsoft de rendre l’OOXML délibérément plus complexe qu’il ne devait l’être — l’objectif étant de revendiquer le titre de "standard ouvert" tout en rendant la norme si incroyablement vaste qu’il aurait fallu un effort héroïque pour que quiconque d’autre puisse l’implémenter. Je pense que c'est indiscutablement vrai. LibreOffice a d'ailleurs publié un excellent article de blog à ce sujet.
- [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
  
  Posté par devnewton 🍺 (site web personnel) le 26 mars 2026 à 10:45. Évalué à 2.
  
  Il est difficile de dire si Microsoft est mal faisant ou malfaisant (probablement beaucoup des deux?), mais l'argument de la surcomplexité peut aussi s'appliquer aux formats de Libreoffice.
  
  Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
  - [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
    
    Posté par jyes le 26 mars 2026 à 13:18. Évalué à 7. Dernière modification le 26 mars 2026 à 13:18.
    
    Si tu t’es déjà amusé à dézipper un ODT et un OOXML pour les triturer depuis ton vim, tu as dû constater que le niveau de surcomplexité n’est pas du tout le même pour l’un et pour l’autre. Je ne prétends pas pouvoir créer un ODT avec juste vim et zip sans mal de crâne, mais c’est un format qui se comprend plutôt pas trop mal et s’édite assez bien.
    - [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
      
      Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 26 mars 2026 à 13:43. Évalué à 3. Dernière modification le 26 mars 2026 à 13:43.
      
      Je doute que devnewton connaisse vraiment le format et il a une dent contre LibreOffice (contre Unicode aussi qu'il trouve trop compliqué...). C'est plus un troll.
      
      Je n’ai aucun avis sur systemd
      - [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par devnewton 🍺 (site web personnel) le 26 mars 2026 à 15:19. Évalué à 3. Dernière modification le 26 mars 2026 à 15:20.
        
        Non ce n'est pas un troll.
        
        On reproche à Microsoft d'utiliser un format qui demande des années / Hommes de travail pour être géré correctement. C'est vrai.
        
        Je reproche à Libreoffice d'utiliser un format qui demande des années / Hommes pour être géré correctement. C'est vrai aussi.
        
        Ce n'est pas le même nombre d'années / Homme pour chaque solution, mais dans les deux cas, c'est un frein à l'existence d'implémentations alternatives.
        
        Oui, c'est pareil pour Unicode, pour les standards du web, pour les formats d'images...
        
        La complexité a un coût et ce coût est un facteur d'exclusion.
        
        Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 26 mars 2026 à 15:43. Évalué à 3.
        
        Le truc est de savoir si cette complexité est justifiée. Tu peux comparer à fonctionnalité équivalente, et c'est là que tu peux parler de "sur" complexité sans doute.
        
        Mais si c'est assumé d'avoir un certain ensemble de fonctionnalités, il y a une complexité inhérente et irréductible (ou très difficile à réduire) à les implémenter.
        
        Tu peux ensuite vouloir critiquer l'ensemble de fonctionnalité en question ... mais c'est une question de jugement de valeur. Comparer Markdown à libre office, par exemple, a relativement peu de sens parce que peu d'utilisateurs de libreoffice voudront utiliser markdown, de fait.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par devnewton 🍺 (site web personnel) le 26 mars 2026 à 15:54. Évalué à 3.
        
        C'est compliqué de faire simple !
        
        Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 26 mars 2026 à 16:02. Évalué à 3.
        
        It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.
        
        https://quoteinvestigator.com/2011/05/13/einstein-simple/
        
        En théorie aussi, contrairement à la croyance répandue en pratique !
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Voltairine le 26 mars 2026 à 16:50. Évalué à 8.
        
        « Ce qui est simple est toujours faux. Ce qui ne l’est pas est inutilisable. »
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 26 mars 2026 à 15:57. Évalué à 6.
        
        La complexité a un coût et ce coût est un facteur d'exclusion.
        
        La relative complexité d'Unicode est un énorme facteur d'inclusion, celle du format ODF aussi.
        
        Je n’ai aucun avis sur systemd
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 26 mars 2026 à 16:04. Évalué à 2.
        
        Oui ! Par exemple, les égyptiens antiques auraient bien du mal à utiliser un ordinateur sans Unicode ! https://www.compart.com/en/unicode/block/U+13000 /o\
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 26 mars 2026 à 17:50. Évalué à 5. Dernière modification le 26 mars 2026 à 18:07.
        
        Je pensais surtout au Braille et à tous les systèmes d'écriture plus ou moins complexes qui ont leurs blocs Unicode. Ce que doit aussi prendre en charge l'ODF.
        
        Je n’ai aucun avis sur systemd
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par nizan666 le 27 mars 2026 à 16:55. Évalué à 3. Dernière modification le 27 mars 2026 à 16:56.
        
        Je ne pense pas que l'existence d'un bloc unicode pour le braille soit un facteur d'inclusion des braillistes.
        
        L'écriture du braille six points, en informatique, repose bien plus souvent sur un codage se superposant à des caractères ascii (pour les états-unis) ou l'équivalent ISO 859-1 (ou son pendant windows, CP 1252).
        
        https://www.insei.fr/sites/default/files/www/sites/default/files/medias/Table_Braille_Informatique_TBFR2007.pdf
        
        Les plages braille et les embosseuses utilisent ces codages sur 8 bits plutôt qu'unicode. De même le format "texte braille" BRF
        
        https://www.loc.gov/preservation/digital/formats/fdd/fdd000551.shtml
        
        Cela s'explique par des raisons historiques (utilisation du braille en informatique avant que l'usage d'unicode ne soit généralisé) mais aussi par des raisons pratiques: ainsi, le caractère braille utilisé pour la lettre "a" peut être représenté par le caractère "a", ce qui rend le texte lisible directement par tout le monde, voyant ou brailliste, au contraire du braille unicode, facilitant par exemple le travail des personnes voyantes transcrivant des textes en braille.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 27 mars 2026 à 18:52. Évalué à 3.
        
        Possible. J'avoue ne pas être très au point sur la question. J'imagine toutefois que le fait que le Braille soit inclus dans Unicode a des raisons qui peuvent servir aux braillistes.
        
        Je n’ai aucun avis sur systemd
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par jyes le 27 mars 2026 à 09:13. Évalué à 6.
        
        Il est évident que ton commentaire est ironique, n’empêche que c’est une vraie simplification d’avoir une table de caractère unique pour à peu près tous les systèmes d’écriture (et qui continue de grossir pour inclure ceux qui manquent). L’époque des ISO-8859-1, et de ses surcomplexités induites pour être capable d’insérer un simple « α » dans un texte, ne me manque vraiment pas.
        
        Une fois qu’on a une table unique pour plusieurs systèmes, autant mettre en place un standard qui couvre tous les systèmes (ou à défaut, un maximum), de la même manière, avec un jeu de règle (un peu plus long) qui permet de de travailler de la même manière pour tout le monde. C’est ça la simplification.
        
        Parce-que si les égyptiens antiques sont morts avant de pouvoir utiliser Unicode pour s’adresser à leur agent IA, il reste des gens sur terre qui ont besoin de représenter les hiéroglyphes, et ce n’est pas plus mal pour elles et eux de ne pas avoir à implémenter leur propre éditeur de texte. L’informatique ne s‘arrête pas au tri de graphes.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 27 mars 2026 à 11:08. Évalué à 3. Dernière modification le 27 mars 2026 à 11:12.
        
        Oui bien sûr je vois la valeur, c'était simplement pour blaguer sur l'accessibilité. Les mamies utilisent unicode, tel monsieur Jourdain souvent, mais aussi les mommies !
        
        Plus sérieusement, on peut voir que les sites web qui parlent de hiéroglyphes pré-unicode utilisent souvent des images : http://web.archive.org/web/20070627202145/http://www.omniglot.com/writing/egyptian donc c'est laborieux de faire des copier/coller. La position relative est juste encodée dans l'image (qui est au dessous de quoi) ... les sites utilisent souvent des générateurs d'images ou de svg ad-hoc pour faire tout ça. Tu prends un site, même vieillot comme https://projetrosette.info/ les caractères unicode sont utilisés et c'est plus agréable que des images pixellisées.
        
        Cela dit il suffit pas que ça existe dans Unicode pour que ce soit implémenté partout. Pour les hiéroglyphes il y a tout un bloc pour le formatage :en:Egyptian_Hieroglyph_Format_Controls mais tout n'est certainement pas implémenté si tu sors l'éditeur de texte de ton environnement de bureau préféré ou ton navigateur. D'ailleurs si sur le site "projet rosette" que j'ai lié plus haut, si les caractères sont bien en unicode, les compositions sont encore faites avec des images et sur leur page principale un exemple de composition c'est un png qui est utilisé.
        
        Une séquence complexe avec des joiners unicode par exemple, copiée ici bêtement donne
        
        𓀀𓐰𓂧𓐱𓅓𓐲𓇳𓐰𓏏𓐱𓏭𓐲𓏭𓐱𓏭
        
        En 2026 sous FF on voit les caractères spéciaux comme des caractères ordinaires entourés par des pointillés chez moi.
        
        Donc l'implémentation peut être effectivement complexe, lente et surtout non prioritaire probablement pour les gros acteurs. Il y a des logiciels spécialisés comme Jsesh qui Jsesh qui génèrent des images, par contre. Qui gèrent des langages ascii comme le :en:Manuel_de_Codage je crois. On imagine que c'est pas demain la veille que ce soit intégré dans une appli de clavier de téléphone standard.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par BAud (site web personnel) le 27 mars 2026 à 20:18. Évalué à 2.
        
        gèrent des langages ascii comme le :en:Manuel_de_Codage
        
        la notation [[en:Manuel de Codage]] qui donne Manuel de Codage est plus jolie ;-)
        
        cf. notre aide-édition :D
        
        Une séquence complexe avec des joiners unicode par exemple, copiée ici bêtement donne
        
        𓀀𓐰𓂧𓐱𓅓𓐲𓇳𓐰𓏏𓐱𓏭𓐲𓏭𓐱𓏭
        
        En 2026 sous FF on voit les caractères spéciaux comme des caractères ordinaires entourés par des pointillés chez moi.
        
        comme d'hab' il me manque la police idoine, ce qui me fait voir des carrés avec le n° unicode dedans :/ avec Firefox 140.9.0 ESR
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 27 mars 2026 à 20:42. Évalué à 3.
        
        Ah ? J'ai l'habitude de pas être radin sur l'installation des polices sur mes machines, ça évite ce genre de souci (ou plutôt, quand je vois qu'il en manque une j'installe le paquet "toutes les polices" ou stratégie du style)
        
        Mais sinon ça ne semble pas plus compliqué que l'installation d'un paquet, ce fil cite fonts-noto sous la famille debian : https://forums.linuxmint.com/viewtopic.php?t=405278
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par BAud (site web personnel) le 27 mars 2026 à 21:08. Évalué à 3. Dernière modification le 27 mars 2026 à 21:13.
        
        comme quoi, il n'y a pas que Unicode comme partie de la solution...
        
        quelle fonte précisément ? j'en ai 163 proposées :/
        
        et sur https://github.com/orgs/notofonts/repositories?type=all il y a 396 dépôts...
        
        et j'ai déjà d'installé :
        
        google-noto-fonts-common-20180905-4.mga10
        google-noto-sans-fonts-20180905-4.mga10
        fonts-ttf-google-noto-emoji-color-20231130-3.mga10
        
        qui ne semble pas tout contenir donc :/
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 27 mars 2026 à 21:16. Évalué à 3.
        
        Au hasard, https://notofonts.github.io/egyptian-hieroglyphs/ ?
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par BAud (site web personnel) le 27 mars 2026 à 21:22. Évalué à 3.
        
        tant qu'à faire, une qui couvrirait l'ensemble des glyphes (ou plusieurs fontes s'il le faut vraiment — mais pas toutes sans discernement), ça m'arrangerait ;-)
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 27 mars 2026 à 21:43. Évalué à 3. Dernière modification le 27 mars 2026 à 21:44.
        
        Apparemment il y a une limite au nombre de glyphe dans une police ... par exemple pour ttf c'est 65 535 : https://graphicdesign.stackexchange.com/questions/154478/what-is-the-maximum-number-of-glyphs-a-truetype-font-can-hold
        
        C'est pas assez pour couvrir tout unicode. Il y a GNU Unifont chez GNU qui a cet objectif, mais c'est exactement ce nombre de glyphes. Ce qui se rapproche le plus de couvrir tout unicode c'est d'installer tous les paquets noto.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par BAud (site web personnel) le 27 mars 2026 à 22:01. Évalué à 3.
        
        d'après https://savannah.gnu.org/projects/unifont
        
        Initially Unicode was a 16-bit encoding, allowing 2¹⁶ = 65,536 code points. Today Unicode has grown beyond that early limitation. Its initial 16-bit range is now known as the Basic Multilingual Plane (BMP), or Plane 0. The BMP contains most of the world's scripts that are in current use. The Unicode encoding space now covers 17 such planes of 65,536 code points each.
        
        c'est faisable avec 17 fontes donc, reste à les trouver :p
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 27 mars 2026 à 22:14. Évalué à 3. Dernière modification le 27 mars 2026 à 22:14.
        
        https://packages.debian.org/sid/fonts/fonts-noto
        
        Noto est une collection de familles de fontes, chacune étant harmonisée visuellement entre les écritures.
        
        Ce paquet est à utiliser pour obtenir toutes les fontes Noto.
        
        Le nom « Noto » est une abréviation de « No Tofu », décrivant l’objectif de couvrir toutes les écritures Unicode employées (actuellement, 65 sont couvertes, au moins partiellement).
        
        Tofu (豆腐) est un jargon japonais pour remplacer les caractères Unicode « � » (U+FFFD), souvent affichés pour remplacer les caractères non assignés ou inconnus.
        
        C'est bien le but des fonts-noto, même si il y a un peu plus de fichier (c'est divisé par écriture on dirait en zieutant les paquets, il y a un paquet pour les caractères arabiques par exemple)
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 28 mars 2026 à 09:26. Évalué à 3.
        
        https://en.wikipedia.org/wiki/OpenType#Collections
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Krunch (courriel, site web personnel) le 27 mars 2026 à 13:03. Évalué à 4.
        
        Merci de nous rappeler l'existence de cet emoji sous employé : 𓂺
        
        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par BAud (site web personnel) le 27 mars 2026 à 23:35. Évalué à 2.
        
        c'est quoi l'équivalent en art ASCII même si ASCII art est plus joli ? :D
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Krunch (courriel, site web personnel) le 28 mars 2026 à 17:21. Évalué à 2. Dernière modification le 28 mars 2026 à 17:23.
        
        Malheureusement le support de l'art ASCII dans les commentaires DLFP étant relativement bancal, je n'essaierai pas de le reproduire ici. Mais tu peux facilement répondre à cette question avec une combinaison de ton fournisseur d'imagerie pornographique préféré (possiblement l'appareil photo de ton téléphone ou woob/yt-dlp) et libcaca (possiblement via mpv).
        
        Dans tous les cas, ça sera plus approprié que l'emoji de cette pauvre aubergine qui est trop souvent mésutilisé.
        
        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par BAud (site web personnel) le 28 mars 2026 à 20:56. Évalué à 6.
        
        l'art ASCII dans les commentaires DLFP étant relativement bancal
        
        boah la balise de code ``` fonctionne à peu près bien
        
        # # # # ## ### ## # ## ## # # # # ## # # # ##### # # # # # # # # # # # ### ### # #
        
        avec ascii-design
        
        __ _ ___ ___(_|_) __| | ___ ___(_) __ _ _ __ / _` / __|/ __| | |_____ / _` |/ _ \/ __| |/ _` | '_ \ | (_| \__ \ (__| | |_____| (_| | __/\__ \ | (_| | | | | \__,_|___/\___|_|_| \__,_|\___||___/_|\__, |_| |_| |___/
        
        ou un figlet hein
        
        _ _ | |__ ___(_)_ __ | '_ \ / _ \ | '_ \ | | | | __/ | | | | |_| |_|\___|_|_| |_|
        
        alors, oui effectivement faut pas que ce soit trop large et ya un interligne un peu trop grand, mais bon...
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par devnewton 🍺 (site web personnel) le 26 mars 2026 à 18:52. Évalué à 2.
        
        Tu peux te permettre de relativiser cette complexité parce que tu comptes sur d'autres pour la gérer à ta place :-)
        
        Quand seule une ou deux grandes sociétés privées seront capables d'implémenter une gestion complète Unicode, ça sera vachement inclusif...
        
        Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 26 mars 2026 à 19:04. Évalué à 2. Dernière modification le 26 mars 2026 à 19:06.
        
        Enfin il y a deux choses dans Unicode, d'une part le code qui implémente Unicode, et qui ne bouge plus beaucoup sauf pour s'adapter, le cas échéant, aux nouveaux systèmes d'écriture, et les blocs de code que sont les bibliothèques de glyphes. Ces derniers sont en fait fabriqués en dehors d'Unicode, et assez souvent du fait de petites structures.
        
        Mais si tu considères que l'informatique doit laisser des côté les personnes sourdes, celles qui ont de grandes déficiences visuelles ou encore celles qui ont un système d'écriture différent du tiens, effectivement, ton discours se tient à peu près.
        
        Je n’ai aucun avis sur systemd
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par devnewton 🍺 (site web personnel) le 26 mars 2026 à 19:27. Évalué à 1.
        
        Tu confonds besoin, spec et implémentation. Un peu comme les gens qui disent "Word" pour "traitement de texte" 😀.
        
        Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Faya le 26 mars 2026 à 23:17. Évalué à 4.
        
        Mais du coup quelle serait la solution pour supporter plusieurs alphabets non-ASCII ? Garder des codages séparés genre ISO 8859-1 ?
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 27 mars 2026 à 13:10. Évalué à 2.
        
        Et implémenter quarante-douze-mille codages pour gérer ces systèmes d'écriture. C'est une solution tellement plus simple et facile à gérer.
        
        Je n’ai aucun avis sur systemd
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Faya le 27 mars 2026 à 13:40. Évalué à 2.
        
        Mais j'aurais vraiment bien aimé comprendre ce que veut devnewton<
        Si l'implémentation n'est pas la bonne (possible, je n'en sais rien), c'est quoi la bonne solution ?
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par devnewton 🍺 (site web personnel) le 27 mars 2026 à 15:15. Évalué à -1.
        
        Je ne veux rien, je constate que c'est un gros merdier et que personne n'a pris en compte la difficulté d'implémentation.
        
        Cette tendance on fait n'importe quoi et si quelqu'un critique, on lui demande de trouver une solution parfaite fait partie du problème :-)
        
        Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Renault (site web personnel) le 27 mars 2026 à 15:26. Évalué à 7.
        
        je constate que c'est un gros merdier et personne n'a pris en compte la difficulté d'implémentation.
        
        Ou alors :
        
        Le problème est de fait un gros merdier et la solution ne peut en être qu'une
        
        Peut être qu'ils ont réfléchi à ces aspects mais n'ont pas trouvé mieux
        
        Peut être qu'il n'y a pas vraiment mieux à faire pour respecter les différentes contraintes
        
        Cette tendance on fait n'importe quoi et si quelqu'un critique, on lui demande de trouver une solution parfaite fait partie du problème :-)
        
        Le soucis c'est que quand tu critiques sans même esquisser un début de solution, ça fait très "YAKAFOCON" alors qu'il n'y a pas forcément mieux à faire en pratique. Car oui, des solutions simples pour tout problème ça n'existe pas.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par devnewton 🍺 (site web personnel) le 27 mars 2026 à 15:37. Évalué à 0.
        
        Le soucis c'est que quand tu critiques sans même esquisser un début de solution
        
        Si j'esquisse un début de solution, le débat va partir sur la critique de cette solution pour enterrer la critique de l'existant.
        
        Tout comme quand on veut éviter de parler des problèmes des pesticides, on te demande de résoudre le problème de la faim dans le monde.
        
        Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Renault (site web personnel) le 27 mars 2026 à 15:47. Évalué à 4.
        
        Si j'esquisse un début de solution, le débat va partir sur la critique de cette solution pour enterrer la critique de l'existant.
        
        De toute façon si tu ne proposes rien, le sujet n'avancera pas plus.
        
        Par ailleurs proposer des solutions sans évaluer à minima les conséquences de ces solutions c'est un peu facile et revient à mon commentaire précédent. La complexité de l’internationalisation vient aussi de la complexité du sujet et de la quantité de contraintes qui tournent autour.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 27 mars 2026 à 15:48. Évalué à 5.
        
        Le truc c'est qu'avec notre minable et simplissime alphabet latin (trop compliqué déjà pour tenir dans la norme ASCII en entier), on ne se rend absolument pas compte de la complexité et de la diversité des autres systèmes systèmes d'écriture. Même si on s'en tient aux seules écritures alphabétiques, avec l'alphabet arabe par exemple, on a une écriture qui est très différente, sur le plan du comportement, de l'alphabet latin.
        
        Donc trouver une solution simple pour une question aussi complexe est carrément mission impossible. Plus précisément, la question se pose pour qui cela doit être simple. La réponse est évidente : la simplicité doit être du côté des utilisateurs et utilisatrices finaux, et on l'a complètement avec Unicode. Je ne vois pas trop quel autre type de solution pourrait donner le même résultat. Peut-être que le code d'Unicode est perfectible, sûrement sans doute. Mais comment ?
        
        Je n’ai aucun avis sur systemd
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par devnewton 🍺 (site web personnel) le 27 mars 2026 à 16:01. Évalué à 3.
        
        La réponse est évidente : la simplicité doit être du côté des utilisateurs et utilisatrices finaux, et on l'a complètement avec Unicode.
        
        Ce raisonnement ignore complètement les coûts et les externalités négatives de la complexité d'implémentation.
        
        On le conçoit mieux dans d'autres secteurs : je suis content d'avoir de l'électricité 24h/24 sans interruption grâce au nucléaire, mais si demain les ingénieurs du secteur alertent qu'ils ont du mal à assurer la sécurité des centrales à cause de la complexité, je pense qu'il faut les écouter.
        
        Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 27 mars 2026 à 16:16. Évalué à 1.
        
        Donc il vaudrait mieux que les personnes qui écrivent en Braille ne puissent pas communiquer facilement de même que toutes les autres qui utilisent d'autres systèmes d'écriture que l'alphabet latin parce que ça t'ennuie d'implémenter Unicode.
        
        Au moins c'est clair.
        
        Je n’ai aucun avis sur systemd
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 27 mars 2026 à 16:21. Évalué à 2.
        
        Ben si tu veux piloter une centrale nucléaire avec unicode, tu te restreint à un sous-ensemble d'unicode facile à gérer et tu gère les trucs compliqués dans les échanges aux interfaces et en mettant des exigences de nettoyage sur les specs des formats d'échanges avec l'extérieur ?
        
        Ou alors ton pb c'est qu'on accepte les noms de domaine en unicode ou ce genre de choses ?
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 27 mars 2026 à 15:35. Évalué à 3.
        
        Personne n'a pris en compte la difficulté d'implémentation
        
        C'est probablement pas la réalité, cf. :
        
        https://blog.unicode.org/2016/05/icu-joins-unicode-consortium.html
        
        There has long been a close working relationship between the various Unicode Consortium committees and the ICU team, with many people working on Unicode projects as well as ICU. That has ensured that Unicode data and algorithms can be effectively and quickly implemented.
        
        De fait ICU semble être devenue l'implémentation de référence et a fini par être intégrée dans Unicode.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par devnewton 🍺 (site web personnel) le 27 mars 2026 à 15:46. Évalué à 3.
        
        Un peu vieux, mais utile pour se rendre compte de la complexité : https://mcilloni.ovh/2023/07/23/unicode-is-hard/
        
        Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 27 mars 2026 à 16:04. Évalué à 5.
        
        On est beaucoup à avoir conscience de ça ici je pense. Mais si tu prends la section caveat, ben le problème de la sensibilité à la casse qui dépend de la locale, par exemple ... il est là avec ou sans unicode. Le problème de détection de la locale, aussi. Le problème de normalisation, pareil, on a tous croisé des fois ou on voyait ́e dans emacs ou truc du style pour mettre un accent ...
        
        Cette complexité est pour une large part juste due au fait qu'on veut coder du texte en langue naturelle avec, et en partie à l'historique, la rétrocompatibilité, et au fait qu'on doit bien tenir compte du fait qu'il y a plusieurs codes qui coexistent.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Faya le 27 mars 2026 à 16:05. Évalué à 5.
        
        Moui bon donc en gros tu dis "c'est difficile, mieux vaut rester sur de l'ASCII" et OSEF des autres systèmes d'écritures. Un peu comme si on mettait tout le monde sur UTC parce que la gestion du temps est très compliquée (sûrement plus que Unicode d'ailleurs). Mais la solution est la même que pour la gestion des timezone et ton article la donne clairement :
        
        When handling text that may contain non-English characters, it’s always best to stick to UTF-8 when possible and use Unicode-aware libraries for text processing.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Maclag le 27 mars 2026 à 16:52. Évalué à 6.
        
        Ça serait drôle qu'on se mette tous à l'UTC. Moi je dis ça se tente!
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 27 mars 2026 à 16:54. Évalué à 4.
        
        On garde l'heure d'hiver et l'heure d'été. En mars, on rechange tous les horaires d'ouverture de tous les commerces et les horaires de sortie des écoliers !
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par fearan le 30 mars 2026 à 10:24. Évalué à 3.
        
        Je comprends ton soucis de la complexité, mais tu mélange un peu tout;
        
        Pour prendre un exemple si je fais du c++, je vais utiliser les std::vector, std::set, std::vector, et une chiée d'autre outils de la stl, de façon simple.
        
        Si par contre je dois faire mon propre template, gérer les différent cas (recherche, valeur qui tiens sur 1 bit...) y'a une complexité d'écriture non négligeable.
        
        Bref y'a plusieurs cas
        
        utilisateur vois un produit fini unifié, simple,
        
        un dev qui prends la bibliothèque vois un truc simple (bon y'a quand mêmes des truc a gérer comme le sens d'écriture il me semble),
        
        celui qui développe la bibliothèque qui permet aux autres de pas s'emmerder;
        
        Y'a pas de solution simple, l'historique (iso-8859-1 / iso-8859-15) est déjà un sacré merdier en Europe, le recollement (assemblage) des réseau électrique des différent GRT (gestionnaire de réseau électrique) avec l'un des format historique utilisé est un merdier sans nom, avoir un réseau avec les grec et les pays nordique sur ce format ne peut se faire qu'avec de grosse bidouilles; heureusement pour le nouveau format (xml, :(, rdfid ) on est a plus de problème de noms, (et de toutes façons recolle via des uuid, mais c'est bien d'avoir le nom des postes / lignes dans le bon alphabet)
        
        Quant au parallèle avec la faim dans le monde... c'est fallacieux, y'a pas mort d'homme, pas de destruction environnemental, bref y'a pas de mal à continuer en attendant de trouver mieux, donc propose.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 27 mars 2026 à 13:45. Évalué à 5.
        
        Et le bonheur des gui associées :)
        
        Une interface de choix de charset dans une gui d'un logiciel
        
        (source du screenshot sur un site au hasard qui n'a rien demandé : https://www.ibexpert.net/ibe/index.php?n=Doc.Charset )
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 28 mars 2026 à 11:38. Évalué à 3.
        
        Solution créative, créer une académie mondiale de normalisation des systèmes d'écriture et de communication destinée en particulier à la simplification de l'implémentation des systèmes d'information. Trop de créativité humaine en la matière pose beaucoup trop de risques de sécurité et coûte beaucoup trop cher en implémentation.
        
        Une seule norme pour bénéficier à tous, on en profiterait pour créer une langue mondiale qui permettrait de penser correctement !
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 26 mars 2026 à 19:38. Évalué à 6.
        
        Et puis fort heureusement on a pas à réinventer toute l'informatique tout seul dans son coin tous les quatre matins. On a inventé quelques trucs pour partager du code et le réutiliser, comme les "bibliothèques" ou le "logiciel libre". C'est pas encore très connu mais promis à un très grand avenir !
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par devnewton 🍺 (site web personnel) le 26 mars 2026 à 20:50. Évalué à 2.
        
        Bien sûr, grâce aux bibliothèques et aux logiciels libres, une complexité qui tends vers l'infini ne pose aucun souci. Exemple: les navigateurs web !
        
        Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par thoasm le 26 mars 2026 à 20:59. Évalué à 1.
        
        Alternative avec une complexité bien entendue parfaitement maîtrisée, les applications mobiles et leurs stores, ou les distributions Linux !
        
        Après il y a aussi les systèmes avec des pico systèmes genre les consoles virtuelles 3,5 bits. Mais 3,5 geeks fans de jeux en gros pixels en utilisateurices.
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par jch le 27 mars 2026 à 18:20. Évalué à 5.
        
        La relative complexité d'Unicode
        
        Unicode simplifie énormément les choses. Avoir une seule table de caractères pour toutes les langues au monde évite de prendre en compte l'état du système quand on traite le texte. Certes, il faut gérer la sémantique d'Unicode, mais c'est beaucoup plus simple que ça se fasse sans état, et c'est normalement géré par des bibliothèques externes.
        
        (Ce qui se faisait avant, c'est des sous-ensembles plus ou moins ad hoc de ISO 2022. J'en sais quelque chose, j'ai été obligé d'implémenter ISO 2022 lorsqu'on travaillait à la transition de Linux à Unicode.)
        
        [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
        
        Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 27 mars 2026 à 18:55. Évalué à 2.
        
        C'est très exactement mon discours qui s'oppose à celui de devnewton.
        
        Je n’ai aucun avis sur systemd
- [^] # Re: "Microsoft was making OOXML deliberately more complicated than it needed to be"
  
  Posté par BAud (site web personnel) le 26 mars 2026 à 13:23. Évalué à 3.
  Traduction assistée par LLM:
  
  mouais, ça passe...
  j'aurais changé par s/héroïque/surhumain/ mais la nuance doit échapper à une IA, la notion sûrement en tout cas ;-)
  
  « quiconque d'autre » est un peu redondant, « quiconque » aurait suffit àmha.
  
  Par respect pour tes interlocuteurs, tu peux ajouter « Traduction assistée par LLM relue par mes soins » — en le faisant effectivement, pour éviter les contresens — ici il n'y en a pas, même si cela reste courant (j'ai un peu trop d'exemples pour que ça tienne dans la marge :p)
  
  pour rester dans le sujet, oui :
  - les parties binaires « normalisées » étaient inacceptable, cela avait le mérite de les pointer du doigt
  - les extensions possibles sont une erreur dans laquelle Microsoft s'est engouffré avec Office, le rendant non conforme OOXML et faisant perdurer une situation de non-interopérabilité
  - de l'ordre de 6000 pages, ça n'aide pas à la concision (d'autant si ça ne contribue pas à la précision)
# ODF pose problème ?

Posté par 🚲 Tanguy Ortolo (site web personnel) le 26 mars 2026 à 14:34. Évalué à 9. Dernière modification le 26 mars 2026 à 14:34.

La justification officielle de ce changement est que d'hypothétiques utilisateurs pourraient hypothétiquement se plaindre ou de détourner de NextCloud parce que le format OpenDocument leur pose d'hypothétiques problèmes. Soit.

Mais est-ce qu'aujourd'hui le format ODF est réellement problématique pour des gens ? C'est vrai qu'il y a dix ans, lorsque j'avais un document à partager, je l'envoyais en plusieurs formats pour m'assurer que même des utilisateurs de Microsoft Office 95 puissent le lire. Mais j'ai arrêté de faire cela depuis quelques années. Aujourd'hui, j'envoie de l'ODF est c'est tout. Et personne ne s'en plaint. Parfois je reçois une modification en OOXML, mais personne ne me dit qu'il ne peut pas lire mes documents.

Donc, je m'interroge : est-ce qu'il existe encore des suites bureautiques qui ne prennent pas en charge l'OpenDocument, au moins de façon basique ?
- [^] # Re: ODF pose problème ?
  
  Posté par jyes le 26 mars 2026 à 15:00. Évalué à 3.
  
  Donc, je m'interroge : est-ce qu'il existe encore des suites bureautiques qui ne prennent pas en charge l'OpenDocument, au moins de façon basique ?
  
  Il y au moins MS Office, pour les présentations. J’ai plusieurs cas récemment de personnes qui disent voir des présentations vides quand elles ouvrent des ODP avec PowerPoint.
  - [^] # Re: ODF pose problème ?
    
    Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 26 mars 2026 à 15:04. Évalué à 3.
    
    Quelles versions de logiciels ?
    
    Accessoirement, il faudrait voir aussi comment ça a été fabriqué au départ.
    
    Je n’ai aucun avis sur systemd
  - [^] # Re: ODF pose problème ?
    
    Posté par BAud (site web personnel) le 26 mars 2026 à 15:47. Évalué à 3.
    
    PôvrePoint est le parent pauvre de la suite Microsoft, dont les incohérences dans la (non-)gestion des styles est un cas courant de tétracapillectromie : envoie des fichiers convertis en PDF ;-) (un avec uniquement la préz, un avec les notes pour ceux en ayant besoin)
    - [^] # Re: ODF pose problème ?
      
      Posté par 🚲 Tanguy Ortolo (site web personnel) le 26 mars 2026 à 16:28. Évalué à 5. Dernière modification le 26 mars 2026 à 16:28.
      Ah, c'est bien possible. S'il y a un truc que je ne fais jamais avec des logiciels graphiques, c'est bien les présentations. Les logiciels comme PowerPoint ou LibreOffice Impress sont trop déficients en fonctionnalités qui me semblent incontournables si on veut faire autre chose que du bricolage.
      
      S'il faut les lister :
      
      plan, ou hiérarchie titres, ou sections et sous-sections, appelez ça comme vous voudrez ;
      
      superpositions, ou apparition ou remplacement progressif d'éléments : oui, je sais, ça peut se faire avec des outils graphiques mais c'est infernal, parce que fondamentalement, travailler de façon visuelle sur un truc qui est censé évoluer dans le temps, c'est foireux ;
      
      styles : heureusement, ça existe avec LibreOffice Impress, mais je n'ai jamais compris comment ça s'articulait avec des concepts concurrents comme la notion de diapositive maîtresse ou ce genre de chose.
      
      Bref, quand je parle d'échange de fichiers bureautique, c'est plutôt du texte mis en forme. Les présentations, pour moi, c'est LaTeX Beamer, en attendant de pouvoir vraiment faire la même chose avec Typst.
    - [^] # Re: ODF pose problème ?
      
      Posté par jyes le 27 mars 2026 à 09:20. Évalué à 3.
      Je donnais juste un exemple de « suites bureautiques qui ne prennent pas en charge l'OpenDocument ». À l’inverse LibreOffice s’en sort plutôt très bien avec les formats moisis OOXML¹, si j’enregistre au format .pptx les correspondants en question peuvent visualiser la présentation avec leur suite bureautique défaillante.
      
      surtout qu’en face MS Office s’en sort mieux, mais pas parfaitement avec OOXML non plus. ↩

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.