Jean-Baptiste Faure a écrit 1724 commentaires

C'est LibreOffice qui est plus lent (ça veut dire quoi précisément ?) ou c'est Antidote qui est mal intégré à LibreOffice ?
Pour en savoir plus il faudrait tester AOO et LO sans Antidote.
Cela dit, quel format de fichier as-tu utilisé pour ta thèse, odt ou docx ?

J'ajouterais que LO 6.2.6 (comme 6.3.0 bien sûr) corrige plusieurs failles de sécurité :

CVE-2019-9850 : Insufficient url validation allowing LibreLogo script execution
CVE-2019-9851 : LibreLogo global-event script execution
CVE-2019-9852 : Insufficient URL encoding flaw in allowed script location check

Référence : https://www.libreoffice.org/about-us/security/advisories/

Il est donc important, quelque soit l'OS, de mettre à jour sa version de LibreOffice si on a LibreOffice 6.2.5 ou une version antérieure.
Si j'en crois l'avis de sécurité d'Ubuntu, Ubuntu a rétro-porté ces correctifs sur la version 6.0.7 pour Ubuntu 18.04 LTS et sur la version 5.1.6 pour Ubuntu 16.04 LTS.

--> vous avez un lien vers un truc potable ?

Un collègue hydroclimatologue utilise http://colorbrewer2.org pour choisir les palettes de couleurs qu'il utilise pour ses cartes.

Quand nous nous sommes renseignés pour acheter un aspirateur robot, un des vendeurs a fini par nous poser la question du type de plafond que nous avions chez nous. En effet les robots qui cartographient la pièce ont besoin d'un plafond plat sinon ça ne marche pas. Chez nous les plafonds sont en poutres et chevrons donc exit l'aspirateur robot.
Et puis en fait non. Ce que le vendeur s'était bien gardé de dire, c'est qu'il y a des aspirateurs robots bien moins chers (3 fois moins) qui ne cartographient rien du tout. Ils se contentent de faire une marche au hasard dans la pièce et cela fonctionne très bien. Ils passent plusieurs fois au même endroit et ça prend plus de temps, mais en fait ça n'a aucune importance.

Et au moins avec un aspirateur robot comme cela, connecté à rien, tu n'envoies pas les plans de ta maison au fabricant et à ses partenaires.

Oui mais ça ne fait pas les deux en même temps et pour l'écologiquement responsable tu n'as pas pris en compte la quantité de CO2 supplémentaire rejeté par l'opérateur.

Le fait qu'il soit payant n'est pas la réponse (rien n'empêche Huawei de payer).

Ben si : si c'est payant le vendeur peut répondre, "désolé je n'ai pas le droit de vous le vendre". Il ne suffit pas de pouvoir payer pour pouvoir acheter.

C'est le cas pour Google, car ce n'est pas lui qui interdit à Huawei d'utiliser Android, c'est l'état étasunien qui interdit à Google de vendre une technologie à Huawei.

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.

???????????

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

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.

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

Je n'ai pas dit ça.

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.

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.

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.

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.

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.

Excellent !
Je suis preneur de retours d'expérience sur l'utilisation de LibreOffice Online.

Sinon, le style père pour la titraille c'est "Titre", pas "Titre principal".

En effet c'est ce que me dit mon modèle par défaut. Je ne sais pas pourquoi sur le document où j'ai vérifié le style père était "Titre principal" ; sans doute une scorie de vieilles modifications plus ou moins bien maîtrisées.

Concernant le remplacement de la police, si c'est décompressé, un bête rechercher-remplacer à partir d'un éditeur de texte dans le dossier et sur le filtre *.xml devrait faire l'affaire comme avec le svg je pense. C'est la décompression de tous les fichiers du dossier que je ne saurais faire en une seule fois.

Pour moi ça c'est faire les choses à la main ; dans ce cas autant le faire dans LibreOffice

Je confirme, je me suis heurté à ce problème il y a quelques jours. J'ai remplacé la version graphite par la version Opentype. Je n'ai pas encore pris la peine de chercher si le bug a déjà été rapporté.

C'est quoi le problème avec Linux Biolinum G ?

La première chose que je ferais serait de vérifier s'il suffit de modifier les polices des 2 styles de base, "style par défaut" et "Titre principal" dont les styles corps de texte et ceux des niveaux de titre héritent. Si ce n'est pas le cas il y a peut-être des choses à corriger.
Ensuite si la modification des ces 2 styles et si le nombre de modèles ne se compte pas par centaines, il est sans doute plus rapide de faire le changement à la main plutôt que de mettre au point une procédure automatique.

Cela dit on doit pouvoir automatiser avec un script shell :
1/ décompresser dans un dossier temporaire
2/ remplacer toutes les occurrences de "Linux Biolinum G" par "Linux Biolinum O" dans le fichier styles.xml ; il me semble qu'on peut faire ça avec sed
3/ recompresser le contenu du dossier temporaire
4/ supprimer le contenu du dossier temporaire
5/ boucler sur la liste des fichiers ODF à modifier

Si la modification du fichier styles.xml ne suffit pas c'est, il me semble, qu'il y a de la mise en forme manuelle c'est à dire des styles automatiques dans content.xml mais ce serait surprenant pour des modèles de ta conception.

Il ne suffit pas de pomper le code d'OnlyOffice pour avoir un aussi bon support de OOXML que lui. Cela ne résoudrait pas la difficulté à faire correspondre la représentation interne d'un document propre à un logiciel avec la représentation imposée par OOXML.
Dans le cas de LibreOffice, la représentation interne est ODF qui est différente sur bien des points de OOXML. Le support de OOXML par LibreOffice requiert donc un délicat et complexe travail de traduction entre ODF et OOXML, qui comme toute traduction ne peut rendre l'intégralité du sens et dépend des choix plus ou moins arbitraires du traducteur. Cela est vrai aussi bien pour l'import d'un document OOXML que pour l'export d'un document ODF.
Le problème est le même pour OnlyOffice pour le support de ODF si, comme je le suppose, il utilise OOXML comme représentation interne.

Quelques exemples :
- il n'y a pas de marque de fin de paragraphe dans ODF ;
- la section dans ODF n'a pas grand-chose à voir avec la section dans OOXML
- il n'y a pas de style de page dans OOXML

Il y en a plein d'autres certainement et un développeur du filtre d'import OOXML pourrait détailler le casse-tête que c'est.

Comme d'habitude quand il y a une mauvaise nouvelle, on accuse le messager. C'est tellement plus facile que de sortir du déni.

Bref, pendant qu'on nous explique un truc qu'on a déjà plus ou moins compris, en attendant on ne fait rien.

Correction :
- chaque fois qu'on propose un moyen d'action plein de beaux esprits nous expliquent que ce n'est pas comme ça qu'il faut faire ;
- chaque fois qu'une mesure est décidée, des groupes d'intérêt sont prêts à aller jusqu'à la violence pour en empêcher la mise en œuvre.

à en avoir ras le bol ?

Je ne sais pas, mais je l'espère.

Non pas que la thématique du réchauffement climatique ne m'intéresse pas, au contraire, mais Faceapp, comme Earthapp se permettent une extrapolation qui sera de toute manière erronée.

Je pense que l'extrapolation de Earthapp a hélas bien plus de chance d'être correcte que celle de Faceapp.

Quand on lit les commentaires ici ou dans les journaux d'information générale, quand on voit comment le mouvement des gilets jaunes a commencé, il est clair que notre société est globalement dans le déni. Les campagnes comme celle-ci sont nécessaires pour convaincre notre société de regarder la réalité en face.

Combien de papillons avez-vous vu aujourd'hui ?

Ton commentaire indique juste que tu estimes que mon estimation à la louche est mauvaise, mais tu ne fais que balancer des liens.

Oui, elle est mauvaise parce que tu utilises une estimation de base (4T CO2/an) que tu ne sources pas alors que tu as une estimation sourcée (Ademe) mais moins optimiste (12T CO2/an). Ça aussi c'est un argument d'autorité.