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 LeBouquetin (site web personnel, Mastodon) . Évalué à 10.
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 :
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 :
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 )
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Intéressant... en particulier des améliorations sur Libreoffice Online
Posté par Jean-Baptiste Faure . Évalué à 5.
Excellent !
Je suis preneur de retours d'expérience sur l'utilisation de LibreOffice Online.
# bof
Posté par Albert_ . Évalué à -2.
Moi je ne trouve pas ça cool pour les raspberry pi.
[^] # Re: bof
Posté par Jean-Baptiste Faure . Évalué à 5.
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 Anonyme . Évalué à 4.
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 Albert_ . Évalué à 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 Jean-Baptiste Faure . Évalué à 2.
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 Albert_ . Évalué à -6.
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 Jean-Baptiste Faure . Évalué à 4. Dernière modification le 10 août 2019 à 08:02.
Je n'ai pas dit ça.
[^] # Re: bof
Posté par Albert_ . Évalué à -2. Dernière modification le 10 août 2019 à 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 Jean-Baptiste Faure . Évalué à 3.
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à.
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 Albert_ . Évalué à -10.
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 Jean-Baptiste Faure . Évalué à 8.
Mais comment fais-tu pour lire ça dans ce que j'ai écrit ?
[^] # Re: bof
Posté par mahikeulbody . Évalué à 1.
C'est exactement la question que je me suis posé moi aussi !
[^] # Re: bof
Posté par Albert_ . Évalué à -1. Dernière modification le 11 août 2019 à 19:52.
[^] # Re: bof
Posté par Jean-Baptiste Faure . Évalué à 3.
Et comment déduis-tu de là que :
???????????
[^] # Re: bof
Posté par Albert_ . Évalué à -1.
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 Renault (site web personnel) . Évalué à 9. Dernière modification le 12 août 2019 à 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 Albert_ . Évalué à -7.
https://linuxfr.org/users/jbf/journaux/a-propos-de-libreoffice-6-3#comment-1779368
[^] # Re: bof
Posté par Anonyme . Évalué à 4.
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 ted (site web personnel) . Évalué à 2.
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 Anonyme . Évalué à 3. Dernière modification le 14 août 2019 à 10:50.
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.
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 claudex . Évalué à 4.
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 Thomas Debesse (site web personnel) . Évalué à 10.
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 Joalland . Évalué à 7.
À 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.
[^] # Re: style par défaut
Posté par Jean-Baptiste Faure . Évalué à 10.
Sans proposition détaillée il est difficile d'avancer.
J'ai trouvé 2 rapports de bug (enhancement) à ce sujet, déposés il y a longtemps, mais ils ont été fermés parce que les plaignants n'ont jamais répondu aux demandes de précisions / détails / explications.
https://bugs.documentfoundation.org/show_bug.cgi?id=32955
https://bugs.documentfoundation.org/show_bug.cgi?id=42469
Depuis la police par défaut a été changée de Times New Roman pour le texte et Arial pour les titres à Liberation Serif et Liberation Sans.
Voir cependant la discussion ici : https://bugs.documentfoundation.org/show_bug.cgi?id=113941 et comment elle se termine avec le résultat d'un sondage (https://mobile.twitter.com/liboDesign/status/932556988571181057)
Une alternative est de proposer des modèles qui peuvent être choisis comme modèle par défaut par les utilisateurs.
# PDF
Posté par Bruce Le Nain (site web personnel) . Évalué à 5.
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…
[^] # Re: PDF
Posté par Benoît Sibaud (site web personnel) . Évalué à 8. Dernière modification le 09 août 2019 à 13:31.
Pas une, plusieurs… cf https://linuxfr.org/news/rapport-pdf-de-l%E2%80%99hadopi-ou-comment-ne-pas-masquer-une-adresse-ip
[^] # Re: PDF
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
[^] # Re: PDF
Posté par Jean-Baptiste Faure . Évalué à 4.
Oui, je me souviens d'une histoire comme ça. Mais là ça marche.
En cherchant avec les mots clés "caviardage raté", j'ai trouvé celui de l'affaire Giroud en Suisse (un des articles) et celui de l'armée étatusienne analysé ici et toujours accessible.
# Faut une dépêche pour annoncer cette sortie
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 09 août 2019 à 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.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Faut une dépêche pour annoncer cette sortie
Posté par Jean-Baptiste Faure . Évalué à 2.
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 Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 2.
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).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Faut une dépêche pour annoncer cette sortie
Posté par Anonyme . Évalué à 6.
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).
[^] # Re: Faut une dépêche pour annoncer cette sortie
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 2.
Il va y en avoir une de toute façon. Pas s'inquiéter.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.