URL: https://linuxfr.org/news/sous-le-capot-de-la-beta-libreoffice-4-1 Title: Sous le capot de la beta LibreOffice 4.1 Authors: patrick_g 4fages, claudex, Anonyme, Xavier Teyssier, Thomas Debesse, Florent Zara, Sylvhem et Benoît Sibaud Date: 2013年06月14日T17:55:28+02:00 License: CC By-SA Tags: fosdem, libreoffice et coulisses Score: 106 Michael Meeks est un hacker qui travaille sur la suite bureautique LibreOffice pour l'éditeur [SUSE](https://fr.wikipedia.org/wiki/SUSE). ![Logo LibreOffice](https://wiki.documentfoundation.org/images/7/77/LibreOffice_external_logo_300px.png) Il vient de publier sur son blog [une longue introduction](http://people.gnome.org/~michael/blog/2013-06-13-under-the-hood.html) à certaines nouveautés méconnues de la version 4.1 de LibreOffice. Comme ce texte est fort intéressant et qu'il est placé dans le domaine public (et sous licence CC0 quand la législation locale interdit à un auteur d'opter pour le domaine public) il m'a semblé pertinent de traduire son post. Vous trouverez donc dans la suite de la dépêche une traduction du texte de Michael. ---- [Le post original sur le blog de Michael Meeks](http://people.gnome.org/~michael/blog/2013-06-13-under-the-hood.html) [Le site de LibreOffice](http://fr.libreoffice.org/) [Faire un don pour LibreOffice](http://donate.libreoffice.org/fr/) ---- # Sous le capot de la Beta LibreOffice 4.1 Nous allons sortir LibreOffice 4.1 très bientôt - en ce moment nous sommes en phase Beta et nous apprécierions que des gens aident pour les tests. Vous pouvez télécharger les builds depuis [les pré-versions](http://cor4office.blogspot.co.uk/2013/05/libreoffice-becoming-prettier-all-time.html) ou bien, si vous préférez les trucs très frais, depuis les [dev-builds](http://dev-builds.libreoffice.org/daily/libreoffice-4-1/). Nous sommes encore en train de rédiger la liste complète des nouveautés et des remerciements. Bien entendu nous avons déjà un certain nombre de nouveautés [visibles ici](https://wiki.documentfoundation.org/ReleaseNotes/4.1) avec les crédits associés. Cor a écrit une paire d'entrées sur son blog à propos des [améliorations de l'interface](http://cor4office.blogspot.co.uk/2013/05/libreoffice-becoming-prettier-all-time.html) et de la fonction [d'album photo](http://cor4office.blogspot.co.uk/2013/06/photoalbum-new-feature-in-libreoffice.html) qui seront intégrés dans cette 4.1. Cela m'a fait penser aux nombreux développeurs qui ont travaillé extrêmement dur sur des choses qui sont sous le capot, qui ne sont pas vraiment visibles mais qui sont pourtant vraiment importantes. Je voudrais expliquer ici certaines de ces nouveautés (en créditant l'employeur du développeur quand il y en a un). Souvent ce sont des choses assez simples et qui semblent triviales quand on les regarde isolément mais, prises ensembles, elle donnent une base de code qui est bien plus simple à aborder et sur laquelle on peut contribuer plus facilement. ##Build system: configure / make Depuis des années l'une des tâches qui irritent et qui bloquent le plus les nouveaux développeurs voulant travailler sur la base de code est notre système de build. Au démarrage de LibreOffice il y a eu une transition incomplète vers GNU make ce qui nous a obligé à utiliser _à la fois_ l'horrible dmake ainsi que gnumake avec configure utilisant un script Perl pour générer un script shell configurant un ensemble de variables d'environnements qui doivent être utilisées dans votre shell pour que ça compile (ce qui rend impossible la reconfiguration depuis ce shell). Il y a également un script de build en Perl qui fait de la compilation en batch avec deux niveaux de parallélisme. Au final ça ressemble à un truc comme ça: ### Le vieux système bien horrible `autoconf` `./configure --enable-this-and-that` `source LinuxIntelEnv.Set.sh` `./bootstrap` `cd instsetoo_native` `build --all` Grâce aux [efforts enthousiastes](http://cgit.freedesktop.org/libreoffice/core/commit/?id=2b791f1cc51eaad25bd3464f94231fe4b236fae6) de Björn Michaelsen (Canonical), David Tardon (Red Hat), Peter Foley, Norbert Thiebaud, Michael Stahl (Red Hat), Matúš Kukan, Tor Lillqvist (SUSE), Stephan Bergmann (Red Hat), Luboš Luňák (SUSE), Caolán McNamara (Red Hat), Mathias Bauer (Oracle), Jan Holesovsky (SUSE), Andras Timar (SUSE), David Ostrovsky, Hans-Joachim Lankenau (Oracle) et d'autres—([plus de details](http://skyfromme.wordpress.com/2013/02/28/one/)) les 126 000 cibles et les 1 700 makefiles sont maintenant complètement convertis vers GNU make. Cela permet d'utiliser la syntaxe suivante qui est bien plus simple: ### Le configure & make actuel pour LibreOffice `./autogen.sh --enable-this-and-that` `make` Plus de pollution de shell, plus de script de « bootstrap », plus de wrapper Perl, plus de vieux « dmake » sur le chemin. Que des fichiers GNU make classiques —avec un niveau incroyable de parallélisme puisqu'après la génération des headers, nous pouvons utiliser des milliers de processeurs. C'était un boulot bien précis avec un objectif bien spécifié, comme le processus de retrait du code mort que nous avons effectué dans les versions précédentes, et c'est maintenant terminé. Cela libérera les développeurs qui pourront faire des trucs plus intéressants par la suite. ![Graphique de gnumake vs. dmake par version](http://people.gnome.org/~michael/images/2013-06-07-gnu-vs-dmake.png) ## Système de Build: make dev-install LibreOffice, contrairement à beaucoup d'autres logiciels, est entièrement re-localisable : vous le balancez où vous voulez, et l'exécutez à partir de là. Nous utilisons un `make-dev-install` pour créer une installation dans `install/` que vous pouvez exécuter dans l'arbre de compilation. Ce processus était traditionnellement effectué par un script Perl utilisant un ensemble compliqué de règles pré-traitées, pour réaliser ce qui est (essentiellement) une opération de copie. David Tardon a fait le gros travail de bouger ça vers l'utilisation de listes de fichiers qu'on génère automatiquement. Donc, aujourd'hui, nous avons un `instdir/` top-niveau (sur lesquelles opèrent ces listes de fichiers) qui commence à refléter l'install : l'idée étant que la phase `make install` tourne à l'intérieur de l'arbre de compilation. Jusqu'à présent, nous avons plus de 250 listes de fichiers, gérant près de 20k fichiers. Cette initiative facilite grandement l'ajout ou la suppression de fichiers d'installation, et élimine un tas de zip/unzip de jeux de fichiers utilisés pendant la compilation, accélérant le packaging et la compilation : Le packaging du SDK est passé de 90 secondes à environ 30 secondes, en éliminant plein de règles scp2/. L'espoir est que lorsque ce sera fini nous aurons une suite office qui est exécutable _out-of-the-box_ après un make, sans la phase supplémentaire d'installation. ## Nettoyage du code Un énorme boulot a été fait là pour rendre le code-base plus facile à comprendre. Ça rend la lecture du code plus rapide et facile, permet de le vérifier, de comprendre le "flux" pour ajouter des fonctions et réparer des bugs. ### Des includes propres Dans les sombres vieux jours chaque module avait un répertoire `inc/` intégré, où étaient cachés ses fichiers d'include externes. Pendant la compilation de chaque module, ces fichiers étaient copiés vers d'autres répertoires « artifacts » (le « solver ») et le module suivant était compilé à partir de ces copies. Ça posait plein de problèmes avec les débuggeurs qui identifiaient des copies des en-têtes, des débutants éditant les mauvais (solver) en-têtes, des problèmes de performance sous Windows, et plus. Donc merci à Bjoern Michaelsen, Matúš Kukan et Michael Stahl pour avoir migré tous les ent-êtes dans un dossier unique include à la racine, et nettoyer les makefiles pour rendre tout ça plus propre. ### Nettoyage des outils Le module `tools/` était plein de fonctionnalités dupliquées et inutiles ; dans ce cycle nous avons retiré une abstraction complète du système de fichiers en la virant du code, grâce à Tomas Turek, Krisztian Pinter, Thomas Arnhold, Marcos Paulo de Souza & Andras Timar. Il est toujours bon pour la sécurité de retirer encore un énième code redondant et multi-plateforme de création temporaire sécurisée de fichier. ### Nettoyage des chaînes Nous avons continué à faire de bon progrès vers l'objectif consistant à retirer la classe obsolète `UniString` avec des retraits de méthodes effectuées par Jean-Noël Rouvignac & Caolán McNamara. De plus Lubos Lunak a procédé à une suppression de masse des préfixes des espaces de noms `rtl::` pour le code de `OUString` et `OString`. Cela rend ce code plus lisible avec d'autres améliorations sur la propreté et les performances. Un grand nombre d'appels de fonctions ont été changés de `UniString` vers `OUString`, ont vu leur macro inutile `RTL_USTRING_CONSTASCII` retiré et utilisent maintenant des moyens plus rapides pour concaténer les chaînes. Merci à : Olivier Hallot, Christina Rossmanith, Stephan Bergmann, Chris Sherlock, Peter Foley, Marcos Paulo de Souza, José Guilherme Vanz, Jean-Noël Rouvignac, Markus Mohrhard, Ricardo Montania, Donizete Waterkemper, Sean Young, Thomas Arnhold, Rodolfo Ribeiro Gomes, Lionel Elie Mamane, Matteo Casalin, Janit Anjaria, Noel Grandin, Tomaž Vajngerl, Krisztian Pinter, Fridrich Strba (SUSE), Gergő Mocsi, Prashant, Ádám Csaba Király, Kohei Yoshida—et aux autres que j'ai raté dans les logs (envoyez moi un mail). ### Enregistrement des composants Noel Grandin continue sa [ quête indomptable](https://bugs.freedesktop.org/show_bug.cgi?id=46808) pour nettoyer tous les appels créant des composants avec les nouveaux _"service constructors"_, et toutes les améliorations qui vont avec. Cela représente environ deux cents cinquante commits dans cette 4.1 ##Travail sur la qualité du code La moins visible des améliorations est peut-être celle qui retire des **bugs provoquant des plantages**. Il est clair que le but est de ne jamais planter, mais comment y arriver ? Markus Mohrhard a travaillé sur un ensemble de [tests automatisés](http://mmohrhard.wordpress.com/2013/04/19/automated-import-crash-testing-in-libreoffice/) qui chargent plus de vingt-quatre mille fichiers différents —les plus vicieux et mal-formés que nous puissions trouver en écumant les tréfonds du bugzilla. Il y a eu un gros travail de Markus, Fridrich Strba (SUSE), Michael Stahl, Eike Rathke (Red Hat) pour corriger tous les bugs trouvés. Nous espérons que nos utilisateurs apprécierons de voir encore moins souvent la fenêtre moche signalant un crash. Une autre source significative d'améliorations est l'utilisation des **techniques d'analyse statique** pour améliorer la qualité du code, et donc sa fiabilité. Durant ce cycle une équipe a enquêté de façon systématique sur les données générées par l'outil [coverity](http://blog.documentfoundation.org/2013/04/28/libreoffice-happy-to-work-with-coverity-scan-results/). Il en a résulté presque trois cents commits pour lesquels nous devons remercier Markus Mohrhard, Julien Nabet, Norbert Thiebaud, Caolán McNamara, Marc-André Laverdière (TCS), et bien d'autres. Il faut aussi ajouter les plus de soixante-cinq corrections de Julien Nabet et issues de l'outil intégré cppcheck. Enfin nous continuons d'utiliser Clang et les [plugins](http://cgit.freedesktop.org/libreoffice/core/tree/compilerplugins) très utiles de Lubos pour détecter et retirer le mauvais code dès qu'il apparait. Un autre outil qui s'est amélioré est **bibisect** puisqu'il permet d'avoir un dépôt git avec les binaires contenant les dernières dizaines de commits ayant été intégrés. C'est [fort utile](http://skyfromme.wordpress.com/2012/12/12/libreoffice-test-marathon-bibisect-4-0-and-ubuntu-packages/) pour les utilisateurs/testeurs qui peuvent ainsi trouver très précisément à quel moment un bug a été introduit en _bissectant_ de nombreux binaires dans le même dépôt git. Merci à Bjoern Michaelsen et au labo qualité de Canonical pour les serveurs de build. Nous avons aussi ajouté et vérifié de nouveaux **tests unitaires** dans LibreOffice 4.1, afin d'éviter les régressions dans le code. C'est assez difficles à mesurer parce que les gens aiment empiler de nouveaux tests dans les modules de tests unitaires qui existent déjà. En _greppant_ sur la macro d'enregistrement `CPPUNIT_TEST` on peut constater l'ajout d'à peu près une centaine de tests dans la 4.1 —la majorité pour Calc mais aussi pour Writer, Chart2, la connectivité et Impress. Merci à Miklos Vajna (SUSE), Kohei Yoshida (SUSE), Noel Power (SUSE), Markus Mohrhard, Luboš Luňák, Stephan Bergmann, Michael Stahl, Noel Grandin, Eike Rathke, Julien Nabet, Caolán McNamara, Jan Holesovsky, Thomas Arnhold, Tor Lillqvist, David Ostrovsky, Pierre-Eric Pelloux-Prayer (Lanedo), Christina Rossmanith et les autres qui ont travaillé sur ces tests. ##Refonte du cœur de Calc Une des raisons pour lesquelles Calc a eu besoin de tests unitaires systématiques pour le code qui n'était pas couvert, c'est qu'un travail de re-factorisation profond est en cours au cœur du module. Depuis plusieurs années Calc est architecturé autour de l'illusion qu'un tableur est constitué de cellules - ce qui a créé de nombreux problèmes de performances et de passage à l'échelle. Le but final de ce travail de refonte est de se débarrasser définitivement de `ScBaseCell` et de passer à un stockage de données contiguës d'un type uniforme au niveau de la colonne. Les débuts de ce travail sont présents dans la 4.1 mais pour en percevoir les bénéfices il faudra attendre au moins jusqu'à la 4.2 ou même les versions suivantes où nous pourrons faire le travail d'ajustement pour utiliser au mieux cette nouvelle structure de stockage des cellules. Le but dans cette 4.1 est d'éviter toute régression visible en terme de performances, peut-être même de gagner un peu en terme de rapidité et de réduction de l'empreinte mémoire dans certaines zones. Mais le plus important c'est la meilleure maintenabilité du code du fait de la séparation entre le mécanisme d'utilisation des cellules et du système de stockage lui-même. Merci à Kohei Yoshida pour son excellent travail sur ce sujet. ##Traduction des commentaires en allemand C'est toujours encourageant de faire des statistiques à ce sujet. Dans ce cycle nous avons traduit en anglais près de cinq mille commentaires qui étaient en allemand. Cela aide les nouveaux développeurs à débuter sur le code, à le comprendre et à travailler plus rapidement. Le graphique (approximatif puisqu'il peut y avoir quelques faux positifs) ressemble à ça : ![Les lignes de commentaire en allemand qu'il reste à traduire](http://people.gnome.org/~michael/images/2013-06-05-german-comments.png) Avec de nombreux remerciements à Urs Fässler, Christian M. Heller, Philipp Weissenbacher, Luc Castermans, David Verrier, Chris Sherlock, Joren De Cuyper, Thomas Arnhold, Philipp Riemer, et d'autres. De l'aide est attendue de la part des locuteurs allemands pour traduire les derniers seize mille commentaires. C'est juste une question de [télécharger le code](http://www.libreoffice.org/developers/) et de lancer `bin/find-german-comments` sur un module, de traduire quelques lignes et d'envoyer par mail un `git diff` à libreoffice At lists.freedesktop.org (pas besoin de s'inscrire). ## Portage Python des assistants Java demeure un environnement excellent, sans doute la solution privilégiée pour écrire des extensions multi-plateformes. Tout le support et les API de Java restent disponibles comme ils l'étaient avant. Ceci dit Java n'est pas disponible sur certaines plateformes et, en conséquence, l'utilisation de notre runtime Python interne peut se révéler judicieux pour construire de nouvelles fonctions. Cette version 4.1 apporte la conversion en Python des assistants précédemment en Java (qui sont accessibles sous Fichier -> Assistants). Cela devrait apporter des bénéfices tangibles aux utilisateurs Windows qui n'ont pas la chance d'avoir un JRE installé. Merci à Xisco Fauli et Javier Fernandez (Igalia). ## Édition des liens et démarrage Une des fonctions clés nécessaire pour faire tourner les prototypes LibreOffice sous Android et iOS est la possibilité de lier tout notre code au sein d'une unique bibliothèque partagée (Android) ou d'un unique exécutable (iOS). Ce travail est utilisable avec l'option de configuration `--enable-mergelibs` —qui agrège la majorité du code générique de LibreOffice au sein d'une seule bibliothèque partagée. Cela a été fait en collaboration avec Mozilla et c'est de plus en plus le choix par défaut des builds effectués par les distributions Linux puisque cela autorise des gains en terme de démarrage à froid. Du travail reste à réaliser en terme de réorganisation du code et de compilation guidée par des profils (PGO) afin d'améliorer encore plus les performances au démarrage. Merci à Matus Kukan (pour la Raspberry Pi Foundation) et à Tor Lillqvist pour leur travail. Une autre fonctionnalité liée aux performances qui a été financée par la Raspberry Pi foundation est la réduction des données de configuration qui sont analysées sans raison au moment du démarrage. Une des belles avancées dans ce domaine a consisté à retirer de la configuration plus de quatorze mille lignes de données d'impression d'étiquettes. L'analyse de ces lignes se fait maintenant quand quelqu'un a réellement besoin d'imprimer des étiquettes. Merci encore une fois à Matus Kukan pour ça. ##Nouveau format de type L'interface de programmation qui est utilisé dans LibreOffice a besoin d'une information sur le type, en particulier pour tout ce qui est scripting. Dans le passé cette information était stocké dans une base de données binaire au format vraiment antique et inefficace. Grâce à Stephan Bergmann (Red Hat) nous avons maintenant un tout nouveau format binaire plus efficace et compressé ce qui permet à notre `offapi.rdb` de passer de 6,5 Mo à 0,65 Mo. Plus de détails dans cette conférence [FOSDEM](https://wiki.documentfoundation.org/Marketing/Events/Fosdem2013). À l'heure actuelle ce format est seulement utilisé pour des informations internes et privées, nous prévoyons de rester complètement compatibles avec les extensions qui se basent sur l'ancien format. La documentation sur ce format est disponible dans l'arbre des sources. De nos jours nous avons de la documentation détaillée dans le [fichier README](http://cgit.freedesktop.org/libreoffice/core/tree/unoidl/README) de chaque module. ## Divers D'autres endroits du code où il y a eu des améliorations : ### Temps La résolution des types de données liés au temps dans UNO (l'API de LibreOffice) a été portée jusqu'à la nanoseconde alors qu'elle était auparavant limitée au centième et à la milliseconde. C'est surtout utile dans Base puisque LibreOffice ne tronquera plus les timestamps au centième de seconde ni les durées au millième pour les données utilisateur. Merci à Lionel Elie Mamane. ### Base Dans un formulaire, `DatabaseListBox` expose maintenant les valeurs sélectionnées (au lieu des chaînes qui sont affichées) à l'interface de scripting. Là encore des remerciements pour Lionel Elie Mamane. ### Migration de l'interface vers Glade XML La migration de l'interface vers des fichiers XML Glade a continué à un bon rythme avec des contributions de nombreux développeurs. Nous sommes passés de 64 descriptions de type `.ui` dans la version 4.0 à plus de 230 dans cette branche 4.1 (jusqu'à présent). C'est un progrès appréciable vers le but final des cinq cents fichiers. Merci à Caolán McNamara, Krisztian Pinter, Jack Leigh, Alia Almusaireae (KACST), Katarina 'Bubli' Behrens, Abdulaziz A Alayed (KACST), Jan Holesovsky, Faisal M. Al-Otaibi (KACST), Abdulmajeed Ahmed (KACST), Andras Timar, Manal Alhassoun (KACST), Bubli, Albert Thuswaldner, Olivier Hallot, Miklos Vajna, Abdulelah Alarifi (KACST), Gokul Swaminathan (KACST), Rene Engelhard, et d'autres. Il faut également mentionner l'excellent travail réalisé par les traducteurs pour vérifier et mettre à jour les chaînes de caractères. Le gain le plus important de cette migration de l'interface est qu'il est maintenant très facile de changer et améliorer l'interface utilisateur. ### Sorties de déboguage Il y a de nouvelles macro `SAL_INFO` et `SAL_DEBUG` qui facilitent l'ajout de sorties de deboguage filtrées ou temporaires. Nos crochets git vous préviennent aussi si vous laissez des déclaration de `SAL_DEBUG` au moment du commit. ###Construction des galeries LibreOffice a toujours été encombré avec un format assez hideux pour stocker les galeries. Nous mettons généralement à disposition les galeries d'images en tant que fichiers à part, mais nous avons aussi un ensemble de ressources binaires au sein même de LibreOffice et qui contiennent les miniatures de ces images ainsi que des nombres pour désigner les traductions des noms des images. Dans la 4.1 nous construisons la plupart des ces fichiers à la compilation pour chaque plateforme, ce qui les rend plus facile à compléter (et qui évite des binaires incompréhensibles dans git). Pour accompagner cela, nous traduisons les noms de thèmes avec une nouvelle syntaxe .desktop. Cela devrait faciliter la vie des utilisateurs voulant builder leurs propres galeries en tant qu'extensions et les mettre à disposition avec leurs traductions. ### Retrait complet de SDF Bien que nous ayons, dès la version 4.0, retiré SDF de la vue de nos contributeurs s'intéressant à la traduction, il restait des fichiers SDF qui étaient générés dans certaines étapes intermédiaires du build. Merci à Tamás Zolnai pour nous avoir permis de migrer vers une solution se basant purement sur des fichiers `.po`. ## S'impliquer J'espère que vous avez retiré de ce texte l'idée que les développeurs ont continué à se sentir chez eux au sein du projet LibreOffice et ont travaillé ensemble pour amener des améliorations significatives sous le capot...mais aussi sur la carosserie. C'était vraiment amusant de hacker avec eux sur certaines de ces nouveautés. Notre espoir est que, à mesure que le projet trouve son rythme de croisière, de nouveaux contributeurs vont nous rejoindre et découvrir à quel point c'est devenu fun et bien plus facile d'améliorer le code de nos jours. Vous serez en bonne compagnie, que ce soit en terme de contributeurs de **code** avec qui collaborer : ![Le nombre de contributeurs de code par mois](http://people.gnome.org/~michael/images/2013-06-11-committers.png) Mais aussi en terme de diversité d'origine des commits. Nous aimons vraiment voir de nombreux contributeurs bénévoles sans affiliations, même si les quantités et les ratios varient en fonction de la saison, du cycle et du temps disponible pour la supervision : ![Le nombre de commits par mois et par affiliation](http://people.gnome.org/~michael/images/2013-06-11-commits.png) Bien entendu nous maintenons une liste de tâches simples et courtes dans laquelle vous pouvez piocher afin de commencer à contribuer. Allez jeter un coup d'oeil sur notre page [Easy Hacks](https://wiki.documentfoundation.org/Development/Easy_Hacks) et sur les [instructions de build](http://www.libreoffice.org/developers/). Nous avons maintenant un environnement plus propre et plus sûr à partir duquel travailler à l'amélioration du code. Une des choses les plus simples à faire pour aider est de rapporter les bugs et de participer au [tri de ces bugs](https://wiki.documentfoundation.org/BugTriage) (confirmer, corriger et améliorer les rapports de bugs des autres personnes). Avec seulement un peu d'expérience vous pouvez devenir un trieur efficace et les rapports de bugs bien rédigés aident vraiment les développeurs. Il vous suffit d'installer une [pré-version](http://www.libreoffice.org/download/pre-releases/) et vous serez prêt à contribuer aux côtés des autres membre de l'équipe de développement. Encore mieux, vous pouvez participer au très fun [concours de tri des bugs](https://wiki.documentfoundation.org/QA/Projects/Bug_Triage_Contest) et gagner des prix. ## Conclusion LibreOffice 4.1 va être un nouveau jalon et nous espérons également qu'il fixera la barre en terme de qualité de code, d'améliorations du design et de fondations incrémentalement plus solides pour la meilleure suite bureautique du monde. Bien entendu, avec autant de changements, nous aimerions que vous testiez nos bêtas et nos version candidates, qui devraient (nous l'espérons) vous être utiles dans votre travail - pensez quand-même à sauvegarder régulièrement. Si vous n'avez pas le temps de tester nos bêtas et de nos version candidates, notre [plan de sortie](https://wiki.documentfoundation.org/ReleasePlan/4.1) prédit une date pour la version finale à la fin du mois de juillet. Merci de soutenir LibreOffice.

AltStyle によって変換されたページ (->オリジナル) /