Journal LibreOffice, altération d'images intégrées :( ?

Posté par (page perso) . Licence CC by-sa.
35
5
fév.
2018

Bonjour à tous, amis journaleux :)

Je suis très embêté par un très vilain bug dans LibreOffice. J’ai passé déjà beaucoup de temps pour comprendre le problème et m’assurer qu’il s’agit bien d’un bug dans LibreOffice (y compris illustrations, échange sur liste de diffusion etc.) Avec mon travail et mon petit garçon de 3 mois, je n’ai malheureusement pas le temps de remplir les formalités prévues pour le signalement d’un bug, d’autant que je ne maîtrise pas l’anglais et que je devrais passer du temps à jongler aussi avec un logiciel (ou service en ligne ) de traduction. Par ailleurs, je considère qu’il s’agit d’un bug plutôt grave car il donne lieu à des fichiers corrompus sans que l’on ne s’en aperçoive et cela pourrait nuire vraiment à l’image de notre précieuse suite bureautique, sans compter que j’ai même pas de solution facile à mettre en œuvre :(

Bref, je compte sur quelqu’un pour prendre le relais et faire cette déclaration de bug en anglais, tout comme il faut.

Voici, ce que j’ai déjà posté sur la liste de diffusion qa@fr.libreoffice.org :

Je suis victime d'un grave bug de régression concernant les images embarquées…

Je maintiens depuis des années un document Draw que vous pouvez trouver à cette adresse : http://www.spaceeman.be/ftl/

Depuis peu, l'impression me donnait des rectangles noirs à l'emplacement de certaines images.

J'ai cherché à comprendre, s'il s'agissait pas exemple d'un format qui n'est plus bien supporté par une lib', etc.

Non, c'est bien LibreOffice (5.4.4~rc2) [PS: confirmé également avec 6.0.1.0+ et le master courant (future 6.1)] qui a un problème, qui tronque la version binaire de certaines images embarquées ! rien que ça…

Le bases
Page 6
l'oiseau, qui se trouve dans un groupe, est l'illustration de ce que peuvent représenter les 380 octets d'un petit fichier (c'est didactique).

 Titre de l'image

S'il l'on regarde l'archive qu'est le fichier .odg, l'on constatera que le fichier est (ici) intègre.

Titre de l'image

Titre de l'image

De même, si l'on exporte la page en bitmap

Titre de l'image

PS: le rendu jouant sur les sous-pixels RBG est-il ici pertinent ? Personnellement je ne pense pas. Mais c'est une autre histoire…

Par contre !

Si l'on imprime…
Si l'on exporte en PDF…

http://www.spaceeman.be/files/bugs/libo-pictures-bintrunc/ftl-bases.pdf

On obtient alors un rectangle noir en lieu et place de l'image

Titre de l'image

Si à partir de Draw on enregistre l'image (menu contextuel…), on obtient un fichier tronqué, non plus de 380 octets mais de 368 octets !

Titre de l'image

↑ en fonction du logiciel utilisé, l'image est correctement affichée (Firefox par exemple) ou un rectangle noir (GIMP par exemple).

Il manque bien des octets,

Titre de l'image

Si l'on modifie le document, en supprimant des pages…, l'image embarquée devient la version tronquée !

http://www.spaceeman.be/files/bugs/libo-pictures-bintrunc/ftl-bases-page6.odg

Titre de l'image

Voila, ma conclusion est que LibreOffice, dans cette version, peut gravement altérer des images embarquée, en supprimant des octets, soit lors de l'impression, export PDF ou suite à certaines manipulations…

Qu'en pensez-vous ?

Le bug est-il déjà connu ?

Confirmation sur la liste de Jean-Baptiste Faure :

À l'export en PDF j'obtiens un rectangle noir avec LO 5.4.4, 6.0.1.0+ et le master courant (future 6.1) mais pas avec 5.3.7.

JB ajoute qu'avec d'autres documents et images PNG il n'a pas de problème (tout comme moi au passage) et pause la question de savoir ce que « ce petit fichier PNG a de particulier ». Il convient finalement :

De toute façon ça semble bien un bug que tu peux rapporter ici :
https://bugs.documentfoundation.org/
Il faudra bien joindre ton fichier de test afin que le bug puisse être
reproduit puis analysé.

Bien à vous les amis :) Je vous tiendrai ici au courant si j'ai d'autre infos…

  • # PNG corrompu / hors norme ?

    Posté par (page perso) . Évalué à 7. Dernière modification le 05/02/18 à 11:59.

    ↑ en fonction du logiciel utilisé, l'image est correctement affichée (Firefox par exemple) ou un rectangle noir (GIMP par exemple).

    Mon GIMP 2.8.16 (sous Linux Mint 18.3 64 bits / noyau 4.13.0-32 / libpng12-0:amd64 1.2.54-1ubuntu1) arrive à l'ouvrir, ce qui n'est pas le cas de divers outils d'optimisation PNG, en ligne ou en CLI :

    $ optipng ftl-bases-oiseau-saved.png
    ** Processing: ftl-bases-oiseau-saved.png
    Warning: Can't read the input file or unexpected end of file
    40x49 pixels, 1 bit/pixel, 2 colors in palette
    Recoverable errors found in input. Rerun OptiPNG with -fix enabled.
    Error: Previous error(s) not fixed
    
    ** Status report
    1 file(s) have been processed.
    1 error(s) have been encountered.

    À noter que si on applique le conseil, on obtient ceci :

    $ optipng ftl-bases-oiseau-saved.png -fix
    ** Processing: ftl-bases-oiseau-saved.png
    Warning: Can't read the input file or unexpected end of file
    40x49 pixels, 1 bit/pixel, 2 colors in palette
    Recoverable errors found in input. Fixing...
    Input IDAT size = 305 bytes
    Input file size = 368 bytes
    
    Trying:
      zc = 9  zm = 8  zs = 0  f = 0     IDAT size = 197
    
    Selecting parameters:
      zc = 9  zm = 8  zs = 0  f = 0     IDAT size = 197
    
    Output IDAT size = 197 bytes (108 bytes decrease)
    Output file size = 272 bytes (96 bytes = 26.09% decrease)
    
    ** Status report
    1 file(s) have been processed.
    1 error(s) have been encountered.

    Et un fichier de 272 octets parfaitement fonctionnel – mais qui du coup ne peut plus servir dans ton cas, puisque compressé.

    Je me demande si le fait d'utiliser un fichier non-compressé, chose inhabituelle en PNG, ne déclenche pas sur les versions de LibreOffice dont tu parles, une optimisation un peu exotique « légale » mais mal comprise par divers lecteurs.

    La connaissance libre : https://zestedesavoir.com

  • # Si j'ai bien compris...

    Posté par . Évalué à -10. Dernière modification le 05/02/18 à 12:06.

    …t'as trouvé un bug, tu as pu prendre le temps de l'analyser, de faire des comparaisons à coups d'éditeur hexadecimal, d'écrire un journal sur linuxfr (et probablement d'y répondre on verra)…mais t'es pas foutu d'ouvrir un bug chez l'upstream parce que t'as un job et un bébé à la maison ?

    Tu veux aussi cent balles et un mars ?

    J'aurais tendance à dire que ça va dans le forum ce genre de joyeusetés soit-dit en passant.

    Au fait, t'as essayé avec libreoffice 6 pour voir si c'est pas déjà corrigé ?

    • [^] # Re: Si j'ai bien compris...

      Posté par . Évalué à 10.

      d’autant que je ne maîtrise pas l’anglais et que je devrais passer du temps à jongler aussi avec un logiciel (ou service en ligne ) de traduction.

      Et c'est plutôt cool de voir l'enquête.

      • [^] # Re: Si j'ai bien compris...

        Posté par . Évalué à 10.

        Et c'est plutôt cool de voir l'enquête.

        tout à fait

        analyse complète avec copies d'écran qui seront difficile à publier/mettre en page dans un bugzilla (en général au format texte),

        de plus, après publication du bug, il sera mis à contribution encore d'avantage pour faire d'autres vérifications/tests etc…

        le travail de diagnostic est fait, c'est intelligent de passer le relais à quelqu'un qui a déjà publié des bugs par exemple

        Envoyé depuis mon Archlinux

        • [^] # Re: Si j'ai bien compris...

          Posté par . Évalué à 10.

          Reporter un bug dans un gros projet, ça peut être vraiment, vraiment galère. Pour avoir déja essayé, je déconseille largement. Ça m'est déja arrivé dans Gnome, par exemple. Tu as un plantage avec un message d'erreur dans le terminal, tu rapportes le plantage, et avant de valider le bug, on te demande de le reproduire avec la version de développement compilée avec des options de débug… Sérieusement, recompiler Gnome, rien que ça?

          Ce genre de choses découragent vraiment de rapporter des bugs. C'est évident que les développeurs ne peuvent rien faire si la seule info qu'ils ont, c'est "parfois, la fenêtre plante". Mais s'ils veulent avoir une politique de chasse de bugs efficace, c'est aussi à eux de donner aux utilisateurs les moyens de reporter les bugs efficacement, ne serait-ce que par des messages explicites quand des exceptions sont levées.

          • [^] # Re: Si j'ai bien compris...

            Posté par . Évalué à 10.

            J'ai rapporte plein de bugs chez KDE, je n'ai jamais eu a recompiler…

            Enfin je dis ca je dis rien. :D

            • [^] # Re: Si j'ai bien compris...

              Posté par . Évalué à 7.

              En même temps, KDE sans les bugs, c'est plus KDE. ;-)

              (note aux moinsseurs : j'ai utilisé KDE 3/4/Plasma pendant des années, hein).

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Si j'ai bien compris...

            Posté par (page perso) . Évalué à 5.

            C'est peut-être une stratégie pour limiter le flot de tickets …

          • [^] # Re: Si j'ai bien compris...

            Posté par (page perso) . Évalué à 2.

            Si tu rapportes un bug sur une vieille version, le bug n'est plus forcément valide. C'est donc mieux si le rapporteur peux reproduire lui même avec une version plus récente pour être sûr que le bug est toujours d'actualité. C'est encore plus nécessaire si le problème est difficile à reproduire ou est dépendant d'un matériel quelconque. Cependant, ce n'est pas obligatoire, et de toute façon les compétences de chacun sont variables. Mais en le faisant tu augmentes les chances que ton bug soit corrigé en faisant toi même une partie de l'investigation, et c'est à mon avis vrai pour tous les projets libres.

            Dans tous les cas, si tu as un bug avec une application, tu as habituellement juste cette application à recompiler, éventuellement quelques dépendances plus récentes, mais pas tout GNOME. Le projet est cependant conscient que cela peut être difficile, c'est pour cela que les runtime de flatpak doivent permettre d'avoir la bonne configuration et avoir le moins dépendances possibles à recompiler, ce qui permet d'abaisser le niveau de connaissances exigé pour contribuer.

            • [^] # Re: Si j'ai bien compris...

              Posté par . Évalué à 3.

              Si tu rapportes un bug sur une vieille version, le bug n'est plus forcément valide.

              Ça dépend de ce que tu appelles «vieille version». Les gros projets ont plusieurs versions en parallèle (stable, développement, etc), et ils peuvent maintenir les vieilles versions.

              C'est donc mieux si le rapporteur peux reproduire lui même avec une version plus récente pour être sûr que le bug est toujours d'actualité

              C'est le point de vue du développeur. Pour l'utilisateur, mettre à jour son bureau pour une version plus récente, c'est un peu n'importe quoi. Ça veut dire qu'il faut renoncer au systèmes de paquets de sa distribution, ou mettre en place deux versions du bureau en parallèle (je ne sais même pas si c'est possible), etc. Du point de vue logistique, c'est le genre de manips envisageables pour un développeur, mais pas pour un utilisateur.

              Mais en le faisant tu augmentes les chances que ton bug soit corrigé en faisant toi même une partie de l'investigation, et c'est à mon avis vrai pour tous les projets libres.

              Je pense que les projets bénéficient beaucoup des rapports de bugs des simples utilisateurs, si le projet est organisé pour les traiter. Par exemple, les utilisateurs vont remonter beaucoup de bugs dupliqués, obsolètes, dûs aux patches de leur distribution, ou à des composants externes (bibliothèques tierces), voire remonter des comportements qui ne sont pas des bugs ou des suggestions irréalistes. Ces infos là, c'est ce qui remonte directement de tes utilisateurs, et pas de la communauté de développeurs. Si tu n'as pas les ressources pour traiter ces bugs, alors il ne faut pas encourager les remontées (typiquement, le cas de la fenêtre qui s'ouvre, «le logiciel a planté, voulez-vous remonter le bug? Oui/Non", tu ne peux pas imaginer avoir d'autres infos utiles que celles que le système te remonte).

              Sur le fond, quelqu'un qui prend du temps pour te remonter un bug ou une suggestion, ça a toujours de la valeur. Ça n'a pas forcément de valeur pour corriger un bug tel qu'on l'imagine quand on est développeur, mais ça donne une idée de si ton programme fonctionne chez les vrais gens et s'il leur donne satisfaction.

              • [^] # Re: Si j'ai bien compris...

                Posté par (page perso) . Évalué à 6.

                Tu oublies que ta distribution préférée a normalement un mainteneur du logiciel en question et que tu dois remonter le bogue upstream à travers lui. Tu postes cela sur le gestionnaire de bogue de ta distribution et lui doit déterminer si c'est intéressant, lié à son travail ou upstream, si cela s'applique sur les versions récentes ou non.

                C'est son boulot de faire ça aussi, si l'utilisateur n'est évidemment pas assez compétent pour le faire lui même simplement.

              • [^] # Re: Si j'ai bien compris...

                Posté par (page perso) . Évalué à 5.

                N'oublie pas que tu as beaucoup plus d'utilisateurs que de développeurs. Il ne faut pas sous-estimer la charge de travail que représente la reproduction de bugs. Je trouve donc normal d'essayer de déléguer un peu de la complexité, maintenir un logiciel, souvent bénévolement, n'est pas de tout repos. Mais les développeurs s'adaptent en général à l'audience, et il n'est pas nécessaire d'être développeur pour ouvrir un bug.

                Sur le fond, quelqu'un qui prend du temps pour te remonter un bug ou une suggestion, ça a toujours de la valeur.

                Tu ne prends pas en compte le temps passé sur chaque bug à les trier, gérer les doublons, et les tester. Tout ça c'est une charge de travail non négligeable, et les projets libres sont peu nombreux à ne pas manquer de main d'œuvre. Un bug ouvert, mais sans une bonne procédure de reproduction, ça ajoute plus de charge que de bénéfice. Le bon bug et le mauvais bug quoi…

              • [^] # Re: Si j'ai bien compris...

                Posté par (page perso) . Évalué à 10.

                Je pense qu'il faut voir les choses des 2 côtés de manière réaliste:

                Oui, te demander de compiler GNOME directement serait idiot et irréaliste (même moi je saurais pas par où commencer pour compiler GNOME). Si quelqu'un t'a demandé cela de manière abrupte et en première réponse à un rapport de bug, alors il n'a pas été très malin.

                Cependant les développeurs sont aussi des humains comme les autres, et surtout ils ne sont pas omniscients. Et des fois, sur certains bugs, on est aussi perdu que n'importe qui d'autre (au début en tous cas). Et ce d'autant plus si on n'arrive pas à reproduire le bug, ni à imaginer/comprendre sa raison. Dans ce cas, on peut espérer que si on le reproduit pas, c'est parce qu'il a été corrigé (exprès ou par chance) entre la version du rapporteur et celle du dépôt. Donc, à tout hasard, on peut se retrouver à demander au rapporteur s'il a l'opportunité de pouvoir tester sur la version du dépôt. Il y a diverses façons où cela peut être possible, et pas forcément en compilant. Par exemple certaines distributions ont des paquets de versions de développement (qui ne seront pas forcément le commit du jour, mais au moins une version plus récente). Et puis aussi le logiciel libre est plein de développeurs et quand quelqu'un rapporte un bug, on ne sait pas forcément à qui on a affaire. On peut espérer que le gars en face se trouve justement être un gars capable de compiler le logiciel, peut-être même l'a-t-il déjà fait. Ça ne coûte rien de demander.

                En gros, si on t'a demandé cela, cela ne signifie pas forcément que le développeur s'attendait vraiment à ce que tu puisses le faire, mais simplement il était peut-être juste perdu lui-même et il a tenté l'improbable en te demandant, juste au cas où… Peut-être aussi ne l'a-t-il pas fait de manière très diplomate (on n'est pas tous bon diplomate, d'autant plus que beaucoup de dévs emploient aussi l'anglais en seconde langue eux-même; donc pas mal de choses peuvent se perdre dans une double traduction lang1 -> anglais -> lang2).

                Ensuite y a le facteur temps: les rapports arrivent plus rapidement qu'ils ne peuvent humainement être corrigés. Donc on espère souvent que le rapporteur peut nous aider. C'est aussi ça une des puissances du logiciel libres, que tout le monde puisse apporter sa pierre. Par exemple pour la reproduction, on pourrait aussi faire l'inverse: le développeur pourrait tester l'ancienne version. Comme tu le notes toi-même, un logiciel a parfois plusieurs versions maintenues et il convient de tester au moins celles-ci. Ainsi pour GIMP, quand on me rapporte un bug sur une 2.8.x (la branche maintenue), je vais toujours d'abord tester master (version de développement), puis si je n'arrive pas à reproduire avec master, la dernière version 2.8.x (si je reproduis, cela indique alors probablement un bug corrigé depuis). Par contre pour raisons temporelles (avec git bisect, on peut tester toutes les versions mais ça prend un temps considérable, surtout pour des projets complexes et compilés, donc c'est rarement le premier choix) ou matérielles (car on n'a pas forcément les sous pour 5 ordis de développement, ou des disques de 10 To pour avoir 20 versions de chaque logiciel), on ne va pas forcément remonter plus loin dans le temps. Donc si je ne reproduis pas un bug dans la dernière version 2.8 (et n'arrive pas à deviner une raison au bug, car bien entendu il est aussi possible qu'un bug puisse exister dans certaines configurations sans pour autant que j'arrive à le reproduire dans la mienne), je conseille à la personne d'essayer de mettre à jour d'abord (seule la dernière 2.8 est maintenue, en l'occurrence la 2.8.22 à ce jour) même si je suis conscient que ce n'est pas forcément possible/aisé (si la personne dépend des paquets de sa distribution qui n'est pas à jour). Ce n'est pas de la mauvaise volonté de ma part, juste un compromis facteur temps/volume de correction, puisque le temps que je ne vais pas passer à essayer de comprendre un bug complexe, dur à reproduire, a priori mineur (surtout s'il arrive à peu de personnes puisqu'il est dur à reproduire), et peut-être même déjà corrigé (ce qui explique qu'on n'arrivait pas à le reproduire, simplement car il n'existait plus), je vais le passer à corriger 10 bugs faciles à reproduire (ce qui veut dire qu'ils arrivent à beaucoup de personnes, voire à tout le monde, donc plus grave du point de vue "volume").
                Soyons clair: idéalement on aimerait que nos logiciels soient sans bugs. Sauf cas particulier de personnes vraiment de mauvaise foi et qui ne veulent pas corriger leurs bugs, si on le pouvait, on les corrigerait tous. Mais tout simplement, on est des humains nous aussi. Les développeurs ne sont pas les hackeurs de la télé qui te disent "tiens je vais hacker la NASA", et en 10 secondes, alors que sur leurs écrans on ne voit que des chiffres qui défilent et des dessins 3D qui bougent dans tous les sens, paf! C'est fait! En vrai, chaque bug mineur peut potentiellement prendre un temps fou. Tiens, j'ai posté hier (en anglais), un article sur un correctif de quelques lignes qui m'a pris 3 mois (pas à temps plein, certes! ;p) et beaucoup de prises de tête pour comprendre où se trouvait le problème, surtout que d'autres gens ne reproduisaient pas le problème!

                Ensuite il existe aussi des développeurs inbuvables, parfois imbus d'eux-même et surtout désagréables. Cela arrive. De même qu'il y a aussi des cas similaires de certains rapporteurs de bugs. Il ne faut ensuite pas en faire des généralités si possible.
                Il y a aussi certains dévs super sympas, mais qui manient parfois l'ironie un peu trop naturellement et cela peut être mal compris malheureusement, surtout à l'écrit. C'est à éviter mais parfois c'est juste le style de la personne. J'en connais qui sont en fait super ouverts aux bugs, vont faire de gros efforts pour tout corriger, mais parfois il arrive que sur certains rapports, ils fassent un commentaire ironique qui peut être mal compris/pris.

                Je pense que les projets bénéficient beaucoup des rapports de bugs des simples utilisateurs

                Sur ce point: effectivement les rapports de bug sont l'une des premières méthodes de contribution, mais ça ne veut pas dire que tous les rapports de bug sont utiles. Certains rapports de bug sont vraiment des pertes de temps, par exemple quand la personne en face est elle-même de mauvaise volonté (comme je le disais, ça peut arriver des développeurs comme des rapporteurs). Ça arrive. On peut se demander parfois pourquoi même avoir rapporté le bug si c'est pour ensuite saboter toute tentative de correction, mais je ne suis pas psy.

                Parfois certaines personnes ne comprennent juste pas ce qu'on leur demande (même si c'est pas de compiler le logiciel! Un truc plus "simple" mais néanmoins technique, par exemple essayer d'avoir des traces sur un crash). On ne peut pas leur en vouloir, et on aimerait pouvoir les aider, mais au bout d'un moment, on voit bien qu'on ne peut pas. Je suis sûr qu'on en connaît tous des comme-cela. Par exemple mes parents, essayer de leur expliquer des trucs super simples (genre appuyer sur des boutons) en informatique par téléphone, c'est souvent la misère et au final, je me retrouve une ou deux semaines après à devoir montrer devant l'écran (pour qu'ils oublient une semaine plus tard encore). J'ose même pas imaginer si on leur demandait des infos de débug.
                Que faire dans ce cas? Essayer indéfiniment de réexpliquer la même chose ou passer ce même temps à corriger 20 bugs majeurs rapportés par des gens qui te donnent directement les bonnes infos?
                Encore une fois, ce n'est pas une critique. Comme on dit souvent ici, chacun ses domaines de compétences, et je ne veux pas insinuer que ces gens qui rapportent des bugs peu "utiles" sont "fautifs" de quelque chose. Déjà s'ils ont essayé de rapporter un bug, c'est un premier grand pas en avant et mieux que beaucoup qui ne font que se plaindre. Malheureusement ce premier pas n'est pas toujours suffisant à lui seul, et il peut arriver qu'il soit aussi même cause de beaucoup de perte de temps si la personne n'arrive pas à effectuer les pas supplémentaires. C'est triste mais c'est un fait. Je ne veux pas décourager les gens de rapporter les bugs, bien au contraire: faites ce premier pas. Au fur et à mesure, on peut espérer que même ceux qui ont eu du mal au début deviennent des rapporteurs experts par la suite. Mais il n'est pas exclus que pour en arriver là, ils aient dû faire 3 rapports de bugs inutiles d'abord.

                si le projet est organisé pour les traiter.

                C'est la grande problématique! Qu'est-ce qu'il faut pour traiter efficacement des bugs?!
                Déjà si on pouvait automatiser la récupération de données de debug, ce serait bien. Justement parce que je me suis beaucoup posé ces questions dernièrement (m'étant rendu compte que beaucoup de bugs sont plus compliqué qu'ils ne le seraient si on avait les bonnes infos directement), j'ai récemment implémenté un système de collecte de données de debug (traces d'appels backtrace, informations de versions, etc.) automatique lors de crashs et d'erreurs critiques dans GIMP, qui encourage les gens à rapporter les bugs en quelques clics.
                Débuggueur GIMP

                Ensuite même avec ça, on espère que les gens sauront toujours expliciter ce qu'ils faisaient quand le bug s'est produit, etc. Et comme je l'expliquais, c'est pas toujours donné.

                Enfin la dernière chose, encore et toujours: le temps humain. On peut avoir tous les systèmes de débuggage qu'on veut, etc. si y a pas assez de développeurs avec du temps derrière, ben — je le disais — les rapports de bug arriveront plus vite qu'on peut les traiter.
                C'est aussi pour cela que j'aimerais professionnaliser mon développement libre à travers le projet ZeMarmot (instant pub, si vous voulez aider, c'est par là! ;p).

                Si tu n'as pas les ressources pour traiter ces bugs, alors il ne faut pas encourager les remontées (typiquement, le cas de la fenêtre qui s'ouvre, «le logiciel a planté, voulez-vous remonter le bug? Oui/Non", tu ne peux pas imaginer avoir d'autres infos utiles que celles que le système te remonte).

                Ben là je ne suis pas d'accord. Comme je viens de le dire, je viens justement d'implémenter une telle fenêtre pour GIMP. Et tu as raison sur le fait qu'on n'a pas forcément les "ressources" pour tout traiter. Je le disais: les rapports de bug arrivent plus vite qu'on ne peut les corriger. Mais pour moi, ce n'est pas une raison pour se masquer les yeux. Un bug est un bug. S'il s'est produit, idéalement on doit le corriger, et on espère donc qu'il sera rapporté. Peut-être ne sera-t-il pas corrigé de manière suffisamment rapide, puisque — je le disais aussi — on fait des compromis en fonction de notre temps disponible. On estime donc des priorités, etc. Et donc ce rapport peut rester dans notre système un temps certain sans obtenir de correction. C'est triste. Mais ce n'est pas une raison suffisante pour ne pas le rapporter. C'est une vision fataliste du développement.
                Ma vision est plus optimiste: certes on a pas le temps, mais peut-être l'aura-t-on un jour. Y a un "espoir". Au moins s'il est dans le système, on pourra peut-être le corriger un jour. S'il a jamais été rapporté sous prétexte "qu'on n'a pas les ressources", ben… il sera juste jamais corrigé.

                On espère aussi que les rapporteurs de bug comprennent cela également et ne prennent pas ombrage si on ne peut pas corriger de suite. Encore une fois, ce n'est pas forcément de la mauvaise volonté. Et il se trouve que beaucoup de rapporteurs de bugs comprennent cela très bien et sont très compréhensifs.

                Le truc, c'est qu'on s'en fout des stats. On n'est pas là pour dire qu'on a peu de bugs juste parce qu'on a peu de rapports. Ça c'est une vision d'entrepreneur qui veut vendre du vent et espère donc avoir le moins de remontée de bugs possible car cela signifie payer plus de gens pour les corriger, et potentiellement une mauvaise image. Nous on s'en fout. On fait un logiciel qu'on veut le meilleur possible et on espère tous les rapports de bug possible. On ne peut pas promettre pouvoir tout corriger, mais on essaiera.

                Au passage:

                les utilisateurs vont remonter beaucoup de bugs dupliqués, obsolètes, dûs aux patches de leur distribution, ou à des composants externes (bibliothèques tierces), voire remonter des comportements qui ne sont pas des bugs ou des suggestions irréalistes.

                En fait ce ne sont pas forcément les rapports qui prennent le plus de temps. Déjà car il existe cette catégorie de contributeur technique non-développeur qui fait pas mal de premier tri de ce type de bugs. On en a plusieurs dans GIMP. Donc ce n'est même pas toujours du temps développeur pris (ou beaucoup moins qu'un nouveau bug réel mais mal rapporté).

                Enfin voilà, globalement, malgré mon long message, je suis plutôt d'accord avec pas mal de choses que tu dis. Mais je voulais tout de même rajouter des précisions en me basant sur mon expérience dans ce que tu appelles un "gros projet" (sur la supposition que tu mets GIMP dans cette catégorie, peut-être pas) parce que je ne suis pas non plus d'accord à 100%. En espérant que mon point de vue soit intéressant tout de même. :-)

                Enfin voilà. Au final, je pense pas qu'il n'y ait vraiment de point de vue du développeur ni de point de vue de l'utilisateur. Il y a simplement des humains de tous les côtés, avec leurs imperfections, et tout cela (le rapport de bug et sa gestion), c'est avant tout de la relation et communication humaine, qui peut avoir ses petits accrocs parfois, ses incompréhensions, etc. Franchement au final, il faut juste beaucoup d'empathie et ne pas voir le mal là où il n'est pas forcément. C'est pas facile, je le sais bien, parfois moi aussi je fais l'erreur! :-)

                Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

                • [^] # Re: Si j'ai bien compris...

                  Posté par . Évalué à 4.

                  a mon avis tu devrais reposté ce post en un jolie journal unique, si si, de préférence un vendredi mais pas lorsqu'il neige, nous ne sommes pas au boulot ;)

          • [^] # Re: Si j'ai bien compris...

            Posté par . Évalué à 3.

            Il n'est pas nécessaire de savoir compiler LibreOffice pour faire un rapport de bug très détaillé :
            https://wiki.documentfoundation.org/QA/BugReport
            On peut facilement installer une version de développement en parallèle de son installation normale pour vérifier si le bug est reproductible sur les version les plus récentes. On peut aussi installer des anciennes versions pour vérifier s'il s'agit d'une régression. Enfin, si on est très impliqué et qu'il s'agit bien d'une régression on peut utiliser l'infrastructure prévue pour ça pour "bibisecter" le bug afin de localiser le commit à l'origine de la régression.
            https://wiki.documentfoundation.org/QA/Bibisect

      • [^] # Re: Si j'ai bien compris...

        Posté par . Évalué à 8.

        cool

        Maintenant qu'on a vu que maîtrisais l'anglais, tu vas devoir t'y coller mec

        splash!

    • [^] # Re: Si j'ai bien compris...

      Posté par . Évalué à 9.

      Si j'ai bien compris, tu n'as aucun respect pour l'auteur du journal (sans raison valable), et tu ne l'as pas lu (car oui, il a essayé avec la v6).

      L'utilisation de son temps libre, c'est son affaire, pas la tienne.

      Je te conseille de retourner 7 fois ton clavier sur ton bureau avant d'écrire ce genre de commentaire inutile, la prochaine fois.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # PNG 1bpp non-transparent

    Posté par (page perso) . Évalué à 10.

    Bonjour,

    D'après ce que hachoir remonte, ce petit fichier est un PNG 1bpp qui utilise une palette et est non transparent, pas forcément très courant.

    Je reproduis le problème chez moi également avec LibreOffice 5.4.4.2 avec la méthode suivante:

    • Ouvrir le fichier
    • Supprimer la dernière page
    • Enregistrer le fichier

    Si on compare les deux .png appelés 100000000000002800000031FB2A5F08.png, on voit que dans la nouvelle version il manque le tag "IEND".

    Au niveau de LibreOffice, ce tag "IEND" a l'air de ne pas être créé dans tous les cas, il y a donc peut-être un format qui passe au travers:
    https://github.com/LibreOffice/core/blob/master/vcl/source/gdi/pngwrite.cxx

    if (mbStatus)
    {
    ImplOpenChunk(PNGCHUNK_IEND); // create an IEND chunk
    }
    Il y a un bug un peu similaire ici, mais ne semble pas être exactement le même problème car le fichier n'est pas corrompu de la même manière:
    https://bugs.documentfoundation.org/show_bug.cgi?id=75285

    Et celui-ci mais c'est seulement depuis la 6.0 et ça semble affecter seulement l'export PDF:
    https://bugs.documentfoundation.org/show_bug.cgi?id=115297

    À mon avis ça vaut le coup de créer un bug avec le fichier d'origine et comment reproduire le problème.

    • [^] # Re: PNG 1bpp non-transparent

      Posté par (page perso) . Évalué à 8.

      Bien vu.

      if (rBmpEx.IsTransparent())
      {
          ...
      }
      else
      {
          mpAccess = Bitmap::ScopedReadAccess(aBmp); // palette + RGB without alphachannel
          if (mpAccess)
          {
              if (ImplWriteHeader())
              {
                  ImplWritepHYs(rBmpEx);
                  if (mpAccess->HasPalette())
                      ImplWritePalette();
      
                  ImplWriteIDAT();
              }
              mpAccess.reset();
          }
          else
          {
              mbStatus = false;
          }
      }
      
      if (mbStatus)
      {
          ImplOpenChunk(PNGCHUNK_IEND); // create an IEND chunk
      }
      

      mbStatus est initialisé à true, donc pour passer à false c'est que vraisemblablement mpAccess = Bitmap::ScopedReadAccess(aBmp); // palette + RGB without alphachannel renvoie NULL. Est-ce le RGB qui pose problème sachant qu'on est à 1 bit par pixel ?

      • [^] # Re: PNG 1bpp non-transparent

        Posté par (page perso) . Évalué à 9.

        En même temps, je comprends pas pourquoi mon fichier PNG devrait être réécrit (si je comprends bien) et non pas gardé tel-quel, octet-à-octet, … ?

        Je suis par ailleurs fort aise de savoir que LibreOffice est sensé pouvoir générer un tel fichier, fusse-t-il à partir des données récupérées à partir de mon fichier d'origine. Mais bon, s'il fait ça à la moindre occasion, et pour tous mes fichiers PNG (il y en a de gros), je comprend pourquoi l'enregistrement de mon document prends parfois d'aussi longues secondes et je me demande s'il ne serait pas possible d'optimiser ça en gardant les fichiers images d'origine… :/

        • [^] # Re: PNG 1bpp non-transparent

          Posté par . Évalué à 4.

          Peut etre que c'est une question d'optimisation? Souvent tu n'as pas besoin d'une qualite enorme pour juste un document office puis comme le png est non destructeur, LO peut refaire la compression pour gagner de la place et avoir des fichiers plus petits.

          Recemment j'ai du aider un copain pour des presentations qu'il faisait avec Office365, apres edition avec LO le fichier OpenDocument etait juste 10 fois plus petit que celui Microsoft OXML (je soupconne que dans ce dernier il y avais plein d'historique de changement de la presentation).

          • [^] # Re: PNG 1bpp non-transparent

            Posté par (page perso) . Évalué à 2.

            Je me souviens d'une copine il y a 15 ans qui m'avait donné un .doc énorme. En fait elle avait collé une image bitmap non compressée dans le document, et Word avait conservé l'image telle quelle. Compresser au mieux les images de manière automatique évite ce genre de cas de figure, et contribue au fait d'avoir un document le plus petit possible. Bon, après faut pas se louper et altérer les images :p

            • [^] # Re: PNG 1bpp non-transparent

              Posté par . Évalué à -1. Dernière modification le 06/02/18 à 13:04.

              Bon, après faut pas se louper et altérer les images :p

              D'ou l'utilisation du PNG sans-perte. Ton image est autant pourri a la sortie qu'a l'entree :)

              Ne pas confondre avec le jpeg qui lui degrade les images.

        • [^] # Re: PNG 1bpp non-transparent

          Posté par (page perso) . Évalué à 1.

          Effectivement, tu sembles avoir un mauvais flux de travail. Si tu ne veux pas que LO enregistre tes fichiers à chaque fois, il faut les incorporer en tant que fichier liés.

          Ceci n'enlève rien au bug ici présent, mais va te faire gagner un temps fou à chaque enregistrement.

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

          • [^] # Re: PNG 1bpp non-transparent

            Posté par (page perso) . Évalué à 3.

            Avec des fichiers liés, il se retrouve lui même à gérer l'emplacement sur le système de fichier de ses images. S'il les déplace, les liens seront cassés. Pour redistribuer, il faut donner le fichier odg + les ressources. Pour des fichiers de 380 octets, on s'amuse pas à ça. Les fichiers liés sont utiles quand tu as des insertions d'éléments très lourds, pas dans ce cas précis (ou alors juste comme solution de contournement).

            • [^] # Re: PNG 1bpp non-transparent

              Posté par (page perso) . Évalué à 2.

              il fait ça à la moindre occasion, et pour tous mes fichiers PNG (il y en a de gros)

              …. il a visiblement autre chose que des fichiers de 3040 bits ;-)

              ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Rapport de bug créé

    Posté par . Évalué à 10.

    Le rapport de bug a été créé par Julien Nabet : https://bugs.documentfoundation.org/show_bug.cgi?id=115471
    et il a été confirmé.

    • [^] # Re: Rapport de bug créé

      Posté par (page perso) . Évalué à 8.

      Je reproduis sur LibreOffice 4.2.8.2 sur Ubuntu 14.04. Donc c'est un vieux vieux bug. J'ai extrait l'image fautive du odg d'origine en décompressant le document avec file-roller. Si je crée un nouveau document odg, que j'insère cette image, et que je sauve, l'image est tronquée. Étrangement, eye of gnome arrive à la lire, et si j'ouvre le fichier odg qui contient cette image tronquée, elle apparaît normalement. Le vrai bug est donc ancien, mais juste mis en évidence par des versions plus récentes de LibreOffice parce que l'image corrompue est remplacée par un rectangle noir.

  • # ben voila !

    Posté par . Évalué à 5.

    une vrai salle de réunion linuxfr, mais en plus efficace \o/, 15 personnes ont participé à cette réunion, probablement une centaine on ouvert la porte pour voir ce qu'il se passait, merci a Albert_ pour sa blagounette astucieusement placé, et a jehan d'avoir battu le record du poste le plus long depuis 5 ans.
    Personnes pour dire meuh non c'est le résultat attendu, il n'y a pas de problème, t'y connais rien.

    au final le bug a été bien identifié et sera probablement corrigé.

    j'aimerais tant que cela se passe comme cela dans ma boite, simple, efficace, convivial.

    • [^] # Re: ben voila !

      Posté par . Évalué à 4. Dernière modification le 08/02/18 à 23:11.

      j'aimerais tant que cela se passe comme cela dans ma boite, simple, efficace, convivial.

      Tu imagines les réunions à la cafétéria?
      Et pour chaque bug il faudrait 15 personnes dessus et une centaine de visiteurs?

Suivre le flux des commentaires

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