Journal À propos de LibreOffice 6.3

Posté par . Licence CC by-sa.
44
8
août
2019

The Document Foundation a annoncé ce jeudi 8 août la mise à disposition de LibreOffice 6.3.0, première version de la nouvelle branche 6.3.
L'objet de ce journal n'est pas de faire la liste de toutes les nouveautés de cette livraison. Cette liste est déjà disponible ici en anglais et ici en français et je ne ferais pas mieux. Je souhaite plutôt signaler les quelques nouveautés et changements qui ont ma préférence.

Références

Release Notes : https://wiki.documentfoundation.org/ReleaseNotes/6.3
Release Notes traduites en français : https://wiki.documentfoundation.org/ReleaseNotes/6.3/fr (traduction en cours)
Annonce de TDF : https://blog.documentfoundation.org/blog/2019/08/08/tdf-announces-libreoffice-63/

Mes changements préférés

  • Les fonds de page (couleur, dégradé et bitmaps en mosaïque) couvrent désormais la page entière et non plus seulement l'espace entre les marges. Correctif du bug 33041 par László Németh.
  • Plusieurs améliorations de performances pour Writer ; la liste complète ici
  • La copie de données Calc filtrées vers un tableau Writer n'importe que les données visibles ; bug 124646
  • Plusieurs améliorations de performances pour Calc ; la liste complète ici
  • Suppression des Persona Firefox : cette fonctionnalité dépendait d'une API de Mozilla et de ses serveurs pour télécharger les Persona. Selon les changements d'API et d'url chez Mozilla, ça marchait ou ne marchait plus. C'était une véritable plaie, en particulier pour la QA. La fonctionnalité sera refaite complètement en interne.
  • Suppression des builds Linux 32 bits ; la compatibilité 32 bits demeure mais TDF ne produira plus de paquets Linux 32 bits.

Mes nouveautés préférées

  • Caviardage : il s'agit de pouvoir produire un PDF expurgé des données sensibles en les écrasant par de gros pavés noirs. Le fichier PDF produit ne contient pas les données expurgées et le texte restant n'est pas sélectionnable (c'est une image).
  • L'astuce du jour qui affiche des informations utiles une fois par jour au démarrage.
  • La barre d'information qui s'affiche quand une nouvelle version démarre pour la première fois ; elle propose de consulter les notes de version pour découvrir les nouveautés.
  • Possibilité de choisir dans une palette les couleurs par défaut des diagrammes : Menu Outils > Options > Diagrammes > Couleurs par défaut

Autres changements

Il y a plein d'autres changements dont je ne parlerais pas mieux que les notes de version ; consultez les pour en savoir plus, en particulier si vous êtes adepte de la métabarre (notebookbar / ruban). Il y a aussi un long chapitre sur LibreOffice Online, mais comme je préfère travailler en local, je n'ai pas vraiment cherché à essayer la version en ligne.
Cette version inclut aussi bien sûr les derniers correctifs de sécurité.

Mon ressenti : j'utilise cette version sous Ubuntu 18.04 avec Gnome et GTK3 depuis le début de son développement. Je la compile moi-même. Je trouve que cette version est plus robuste et plus réactive que la précédente et sans doute moins que la suivante.

  • # Intéressant... en particulier des améliorations sur Libreoffice Online

    Posté par (page perso) . Évalué à 10 (+9/-0).

    Pourquoi en particulier sur libreoffice online ?

    Le 3 juillet dernier, nous avons sorti tracim 2.3.0, puis durant le mois de juillet les versions correctives 2.3.1 et 2.3.2.

    Tracim 2.3.2 c'est notamment :

    • l'intégration du moteur de recherche simple ou intelligent (via elastic search)
    • le déplacement de contenu par glisser-déposer.

    Quel rapport avec Libreoffice, me direz-vous ? Et bien nous sommes en cours de finalisation de la version 2.4 de tracim qui apportera 3 fonctionnalités majeures :

    • le partage public de fichiers,
    • le téléversement public de fichiers,
    • l'édition en ligne de fichiers bureautique via l'intégration avec Libreoffice Online / Collabora Online.

    Si vous voulez beta-tester tracim 2.4, contactez-moi via le site web de tracim. (note : vous pouvez aussi tester la version courante via la démo tracim 2.3.2 )

  • # bof

    Posté par . Évalué à -1 (+4/-7).

    Suppression des builds Linux 32 bits ; la compatibilité 32 bits demeure mais TDF ne produira plus de paquets Linux 32 bits.

    Moi je ne trouve pas ça cool pour les raspberry pi.

    • [^] # Re: bof

      Posté par . Évalué à 5 (+4/-1).

      TDF ne produit déjà pas de build du tout pour raspberry pi. Je ne sais pas si quelqu'un assure la production de builds pour cette plateforme. Je sais juste que ça compile.

      • [^] # Re: bof

        Posté par . Évalué à 4 (+2/-0).

        Il devrait pas y avoir de problèmes avec Raspbian vu que Debian propose les paquets binaires pour les plate-formes armel et armhf (ainsi que "i386").

      • [^] # Re: bof

        Posté par . Évalué à 2 (+1/-1).

        Le problème c'est que du coup les tests pour 32 bits ça va être compliqué et donc les bugs ne seront visibles que par les utilisateurs.

        • [^] # Re: bof

          Posté par . Évalué à 2 (+1/-1).

          Qu'est-ce que ça change par rapport à l'état actuel ? Je ne vois aucune machine virtuelle ARM / Linux dans le système d'intégration continue de LibreOffice : https://tinderbox.libreoffice.org/MASTER/status.html

          S'il y a des utilisateurs de LibreOffice sur Raspberry Pi il faut qu'ils compilent et fassent les tests automatiques eux-mêmes. Ce n'est clairement pas une plateforme que TDF a décidé de supporter actuellement . C'est pareil pour BSD d'ailleurs. Cela ne signifie pas que des correctifs spécifiques à ces plateformes ne seraient pas acceptés. Je crois me souvenir qu'il y a déjà eu des correctifs pour permettre de compiler sous ARM / Linux et sur BSD.

          • [^] # Re: bof

            Posté par . Évalué à -5 (+0/-7).

            Ah ok moi je suis pas très fort et je croyais que les tests automatique permettaient d'éviter certains bugs. Tu me rassures tout va bien donc et il n'y aura aucun problème introduit par des spécificités d'être en 32 bits.

            • [^] # Re: bof

              Posté par . Évalué à 4 (+2/-0). Dernière modification le 10/08/19 à 08:02.

              […] il n'y aura aucun problème introduit par des spécificités d'être en 32 bits.

              Je n'ai pas dit ça.

              • [^] # Re: bof

                Posté par . Évalué à -1 (+0/-3). Dernière modification le 10/08/19 à 11:49.

                Tu as dis la même chose que moi. Que les tests vont retomber sur les utilisateurs.
                Je ne vois pas en quoi cela puisse être une avancé 'preferé' dans le journal que le build 'linux 32 bits' soit retiré mais bon chacun ses choix.

                • [^] # Re: bof

                  Posté par . Évalué à 3 (+3/-1).

                  Il y a 2 sortes de tests :

                  1/ les tests automatiques qui sont exécutés à la suite de la compilation ; ces tests comprennent en particulier des tests de non-régression (en principe chaque fois qu'un bug est corrigé, le correctif devrait être accompagné d'un test de non-régression pour détecter dés le compilation la réapparition du bug), des tests de validation des filtres d'import/export basés sur la collection des fichiers à problème publiés avec les rapports de bug et des tests associés à chaque nouvelle fonctionnalité ;

                  2/ les tests manuels faits par les utilisateurs ;

                  Il y a aussi des tests avec des outils de fuzzing ainsi que des scans du code source par Coverity. Je ne sais pas si le fuzzing est utilisé de façon régulière mais les scan coverity le sont si j'en crois les rapports automatiques publiés sur la liste développeurs.

                  Les tests automatiques sont bien sûr exécutés à chaque compilation du système d'intégration continue. La seule VM pour processeur ARM que je vois est celle du viewer Android, il n'y en a point pour Raspberry Pi. Il n'y a donc rien de changé pour cette plateforme et les tests ne vont pas retomber sur les utilisateurs, ils y sont déjà.

                  Je ne vois pas en quoi cela puisse être une avancé 'preferé' dans le journal que le build 'linux 32 bits' soit retiré mais bon chacun ses choix.

                  Tous les processeurs modernes animant des ordinateurs de bureau sont des 64 bits. Cela devient du gaspillage de ressources de produire des builds pour des plateformes obsolètes.

                  • [^] # Re: bof

                    Posté par . Évalué à -9 (+0/-11).

                    Les tests automatiques sont bien sûr exécutés à chaque compilation du système d'intégration continue. La seule VM pour processeur ARM que je vois est celle du viewer Android, il n'y en a point pour Raspberry Pi.

                    Donc tu dis qu'il n'y a jamais de bug specifique au fait d'etre en 32 bits et non pas en 64 bits.

                    Interessant.

                    • [^] # Re: bof

                      Posté par . Évalué à 8 (+7/-1).

                      Mais comment fais-tu pour lire ça dans ce que j'ai écrit ?

                      • [^] # Re: bof

                        Posté par . Évalué à 1 (+1/-1).

                        C'est exactement la question que je me suis posé moi aussi !

                        • [^] # Re: bof

                          Posté par . Évalué à -1 (+0/-3). Dernière modification le 11/08/19 à 19:52.

                          S'il y a des utilisateurs de LibreOffice sur Raspberry Pi il faut qu'ils compilent et fassent les tests automatiques eux-mêmes.

                          • [^] # Re: bof

                            Posté par . Évalué à 3 (+2/-1).

                            Et comment déduis-tu de là que :

                            Donc tu dis qu'il n'y a jamais de bug specifique au fait d'etre en 32 bits et non pas en 64 bits.

                            ???????????

                            • [^] # Re: bof

                              Posté par . Évalué à -1 (+0/-3).

                              Tous les processeurs modernes animant des ordinateurs de bureau sont des 64 bits. Cela devient du gaspillage de ressources de produire des builds pour des plateformes obsolètes.

                              Tu ne dis pas cela, tu dis que cela ne sert juste a rien car personne n'utilise plus de 32 bits et vu la popularité des raspberry c'est clairement faux ce que tu racontes. Par la suite tu tentes de justifier l'abandon en disant que c'est aux utilisateurs de rapporter les bugs et c'est exactement ce que je critique. Retirer les builds automatique de la seule archi 32 bits n'est pas une de mes évolutions préférés comme c'est le cas pour l'auteur du journal.

                              • [^] # Re: bof

                                Posté par (page perso) . Évalué à 9 (+7/-1). Dernière modification le 12/08/19 à 09:12.

                                Sauf que depuis le début tu ne comprends pas ce qu'on te dit.

                                L'image qui a été retirée c'est du i386. C'est-à-dire du Intel ou AMD 32 bits, ce qui est devenu plutôt rare de nos jours. Or toi tu parles depuis le début de Raspberry Pi donc de l'ARM 32 bits pour lequel il n'y a jamais eu d'image et de tests officiels.

                                Donc pour les possesseurs de Raspberry Pi, cela ne changera rien car ils n'ont jamais eu un tel support.

                                Et ce n'est pas parce que les deux plateformes sont en 32 bits que cela a un sens en terme de tests et de bogues. Les architectures étant radicalement différentes, c'est peu probable qu'un bogue spécifique pour l'un le soit pour l'autre.

                                Et générer une nouvelle image officielle + maintenir une système de test pour ces plateformes a un coût en matériel mais aussi en temps. Maintenir officiellement le support pour des plateformes peu utilisées n'est pas forcément intéressant.

                                • [^] # Re: bof

                                  Posté par . Évalué à -7 (+0/-9).

                                • [^] # Re: bof

                                  Posté par . Évalué à 4 (+2/-0).

                                  toi tu parles depuis le début de Raspberry Pi donc de l'ARM 32 bits

                                  Ce qui n'est même plus vrai. Comme je le laissais sous-entendre dans mon message précédent, le premier Pi et le zero sont en jeu d'instruction ARMv6 (le vénérable port armel dans Debian) le deuxième en ARMv7 (32bits avec FPU : port armhf) et depuis le troisième c'est du ARMv8 (64bits : port ARM64).

                                  Mais comme tu le dis, peu importe vu que LibreOffice ne maintient pas les processeurs ARM, même les actuels en 64bits.
                                  Et vu l'arrivée des chromebooks et autres Pinebook en ARMv8 avec une taille de RAM désormais confortable pour de la bureautique, ils cherchent peut-être à viser cette architecture-ci en libérant les ressources utilisées par le maintient des x86 32bits.

                                  • [^] # Re: bof

                                    Posté par (page perso) . Évalué à 2 (+1/-0).

                                    Quelques précisions, n'hésitez pas à me corriger si je me trompe:

                                    Même si le cpu du Raspberry est en 64 bits, Raspbian est encore en 32 bits il me semble (en tout cas pour le pi3). Je ne sais pas si d'autres projets sont compilés en 64bits…

                                    Concernant Android (et Chrome OS?), les applications sont écrites en java et compilés pour une machine virtuelle. On ne se soucie donc pas de l'architecture de l'hôte, ça tourne là où la machine virtuelle tourne.

                                    Un LUG en Lorraine : https://enunclic-cappel.fr

                                    • [^] # Re: bof

                                      Posté par . Évalué à 3 (+1/-0). Dernière modification le 14/08/19 à 10:50.

                                      Raspbian est encore en 32 bits il me semble

                                      Pire que ça : Raspbian est uniquement basé sur armel, le port Debian pour le jeu d'instruction ARMv4t qui gère les flottants de façon logicielle, donc c'est très suboptimal.

                                      Je ne sais pas si d'autres projets sont compilés en 64bits…

                                      On peut construire une Debian pour chaque portage ARM, d'ailleurs des images précompilées existent pour chaque RaspberryPi.
                                      Ubuntu et Archlinux proposent la même chose.

                                    • [^] # Re: bof

                                      Posté par (page perso) . Évalué à 4 (+1/-0).

                                      les applications sont écrites en java et compilés pour une machine virtuelle. On ne se soucie donc pas de l'architecture de l'hôte, ça tourne là où la machine virtuelle tourne.

                                      Beaucoup d'application Android utilise du code compilé pour le CPU (C/C++/…) pour des questions de performance ou de mutualisation du code avec d'autres applications. Du coup, ça dépend. Pour ChromeOS, c'est soit du JS, soit une application Android.

                                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: bof

      Posté par (page perso) . Évalué à 10 (+11/-0).

      Quand quelqu’un dit « Linux 32 bits » on s’attend à ce qu’il signifie « Linux x86 32 bit », donc le Raspberry Pi qui n’a pas un processeur x86 mais ARM n’était déjà pas la destination de ces « builds Linux 32 bits » et ne peut être affecté d’aucune manière par cette décision : les builds arrêtés ne tournaient déjà pas sur la machine…

      ce commentaire est sous licence cc by 4 et précédentes

  • # style par défaut

    Posté par . Évalué à 7 (+6/-1).

    À quand des styles par défaut de titre, chapitre et sous chapitre qui claquent ? C'est triste comparé à MS Word et ça peut être un frein pour ceux qui jugent du premier coup d'œil.

  • # PDF

    Posté par (page perso) . Évalué à 5 (+3/-0).

    Caviardage : il s'agit de pouvoir produire un PDF expurgé des données sensibles en les écrasant par de gros pavés noirs. Le fichier PDF produit ne contient pas les données expurgées et le texte restant n'est pas sélectionnable (c'est une image).

    Il y avait eu une histoire, il y a un certain temps déjà, d'un document officiel qui avait été caviardé avec un fond noir, mais le texte était toujours visible via sélection…

  • # Faut une dépêche pour annoncer cette sortie

    Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 09/08/19 à 14:08.

    Après tout LibreOffice est un logiciel majeur du monde du logiciel libre, même si ça n'est pas le seule suite bureautique libre existante.

    OS préféré Mageia 6 et Mageia 7, CMS préféré SPIP, suite bureautique préférée LibreOffice, logiciel de dessin préféré Inkscape.

    • [^] # Re: Faut une dépêche pour annoncer cette sortie

      Posté par . Évalué à 2 (+0/-0).

      J'y ai pensé mais que mettre dans une dépêche qui ne soit pas un copier-coller de la note de version ? Comme il me semblait nécessaire de faire une sélection, donc forcément subjective, j'ai préféré un journal.

      • [^] # Re: Faut une dépêche pour annoncer cette sortie

        Posté par (page perso) . Évalué à 2 (+0/-0).

        Ah ah petit scarabée, c'est une question d'angle et de rédaction et on peut tout à fait éviter de faire des copier-coller. Je reconnais que ce n'est pas forcément facile. Et on n'est pas obligé de reprendre tout le contenu des notes de version.

        Si tu veux, on peut la faire dans l'espace collaboratif. Comme ça plusieurs têtes (incluant la mienne) donneront un avis ou, surtout, une fonctionnalité ou une amélioration quoi lui paraît importante.

        Par exemple, on peut aussi ajouter que l'intégration à KDE s'est nettement améliorée (ce qui n'est pas du luxe).

        OS préféré Mageia 6 et Mageia 7, CMS préféré SPIP, suite bureautique préférée LibreOffice, logiciel de dessin préféré Inkscape.

    • [^] # Re: Faut une dépêche pour annoncer cette sortie

      Posté par . Évalué à 6 (+5/-1).

      même si ça n'est pas le seule suite bureautique libre existante.

      Justement cette nouvelle version tombe à point nommé et une telle dépêche que ce soit sur LibreOffice, Calligra ou une autre suite permettra de contre-balancer le récent forcing de Onlyoffice (quatre dépêches en quelques mois, perso je trouve ça trop).

Envoyer un commentaire

Suivre le flux des commentaires

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