Journal 723, +5736, -5696… un mois de travail de résurrection d'un projet libre…

Posté par Pinaraf le 17 mars 2021 à 22:13. Licence CC By‑SA.

Étiquettes :

129

mar.

2021

Sommaire

Bonjour à tous

Le 10 février dernier, pris de nostalgie et d'ennui, je me suis lancé dans un projet un peu fou, probablement inutile et vain (donc indispensable) : faire revivre un projet auquel j'ai beaucoup contribué à une époque mais que j'ai perdu de vue ces dernières années. Le projet en question est complexe et volumineux puisqu'il s'agit de Calligra, la suite bureautique du projet KDE. Ayant été co-mainteneur de Calligra Words, je me focaliserai surtout sur ce dernier.

Histoire du projet

Calligra est né en 2010 d'un fork de KOffice par la majorité de l'équipe suite à un désaccord interne. Défaut usuel de gouvernance d'un projet libre : difficile d'éjecter une ou deux personnes, donc tout le monde est parti avec un clone du code voir ailleurs si l'herbe y était plus verte, et elle y était. À l'époque, beaucoup de gens contribuaient à Calligra, et pas mal de gens rémunérés par notamment Nokia (par l'intermédiaire de Ko Gmbh) qui voulait une suite bureautique pour afficher des documents sur sa nouvelle plateforme Meego… Si la communication avait été meilleure des deux côtés, j'eus même pu avoir en premier emploi de ma carrière un poste de développeur chez Ko…
Puis vint 2011 et l'Elopcalypse : un gradé de Microsoft prend le contrôle de Nokia, annonce que «même si le N9 rencontre un succès, on ne fera pas de suite» et décide que l'avenir de Nokia est le Windows Phone… C'est dans une ambiance morose que nous faisons fin 2011 le dernier sprint Calligra de la grande époque, invités dans les locaux d'un Nokia à la dérive, avec nos interlocuteurs en mode, je cite, «distribuons l'argent tant qu'on en a encore»…
Les années suivantes sont délicates : pour ma part, pour des raisons personnelles (santé) et professionnelles (travail chronophage), je m'éloigne du projet… les développeurs salariés ne le sont plus, les contributions chutent très vite : de 8000 à 9000 commits par an, on chute à 3000 commits. Seuls deux projets intégrés à la suite vivent encore, Krita et Kexi.
En 2015, ces deux logiciels décident d'aller vivre leurs aventures de leur côté : leurs objectifs sont différents de ceux du reste du projet, et ils ne peuvent se ralentir en ayant à maintenir tout le reste de la suite bureautique. Le passage à Qt5/KF5 est à l'horizon (KF 5.0 est sorti en 2014), ils ne peuvent en assumer le poids à eux seuls.
En 2017, c'est une équipe restreinte qui sort Calligra 3.0, première version Qt5/KF5, privée de certains outils par manque de mainteneurs et de temps, mais qui reste fonctionnelle. Il n'y a plus que 400 commits par an, et la chute continue : 238 en 2019, 194 en 2020…

Bref, le projet est dans le coma, alors essayons de lui donner un choc, on verra si ça reprend.

Résurrection

Environnement de travail

Bon, Calligra est un projet à base de technologies KDE… donc j'utilise l'environnement de développement KDevelop, qui s'est bien bonifié avec sa version 5. Je clone le projet depuis mon bon vieil alias git kde://calligra et… ha… non, ils sont passés à gitlab… dans un sens je préfère, les anciens outils étaient pas intégrés et ça posait franchement des soucis.

Donc je clone le projet, je l'ouvre dans KDevelop, je demande une compilation et… non, ça marche pas, ninja râle…

Premier patch…

Pourquoi ninja ? Et pourquoi râle-t-il ? Alors moi je dis pourquoi pas pour ninja, je m'en fous à vrai dire, mais c'est supposé marcher, donc qu'il ne marche pas n'est pas acceptable. Il se plaint d'avoir deux cibles avec le même nom sur le projet. Allons bon…
Ce sera donc le premier patch, très simple : https://invent.kde.org/office/calligra/-/commit/5866cef575c92803ff6970eaeb608602b9bec5b6

Première compilation

Ouch… l'arbre de noël… ça fait des warnings dans tous les sens ! Mais méchamment… D'où ça vient ?
Le port à Qt5/KF5 a été fait, oui. Il est fonctionnel, oui. Mais Qt 5 a gardé des éléments de compatibilité avec Qt 4, et au fil des années des méthodes ont été dépréciées en faveur d'autres. De plus, le langage C++ a évolué, avec C++11 et C++14 des constructions ont été largement simplifiées, des éléments sont recommandés pour fiabiliser le code (le mot clef override par exemple).

Où en est Calligra dans ses pré-requis, pour savoir quoi éliminer ?
set(REQUIRED_KF5_VERSION "5.7.0") set(REQUIRED_QT_VERSION "5.3.0")Heu… aïe, comme on dit. Et aucun paramètre passé pour interdire dans le nouveau code l'appel à des méthodes obsolètes…
Qt 5.3 c'est 2014, KF 5.7 c'est 2015… Je doute que quiconque teste le projet sur ces antiquités, et je vois mal comment me restreindre à ce point (il manque au projet une CI actuellement).
Je lance donc la discussion sur la mailing list pour passer à Qt 5.9 ou 5.12 minimum, avec l'équivalent en terme de chronologie pour KF5… et dans la discussion, il apparait que ce choix «peinerait» l'un de nos clients extérieurs. Car Calligra ce n'est pas qu'un ensemble de composants finis, c'est également des briques intégrables, qui peuvent servir à construire un afficheur de documents, notamment sur mobile, comme c'est le cas sur les téléphones Jolla… qui reste en Qt 5.6 par peur de la licence (L)GPLv3…
Bon.
Pour leur faire plaisir, passons, on va se limiter à Qt 5.6 et le KF5 de la même époque, ça devrait éliminer une partie des endroits où les bactéries se déposent, mais ce sera difficile de se limiter à ça très longtemps avec l'approche de Qt 6, qui implique au moins de passer à Qt 5.15 pour limiter la taille du saut derrière.

Du coup, nouveaux patchs, pas trop compliqués…
https://invent.kde.org/office/calligra/-/commit/a48d9611b77c3d67855f0febec2891def2576c78
https://invent.kde.org/office/calligra/-/commit/afb2049d785e7db374d574e675e8ceaad1b1d606
https://invent.kde.org/office/calligra/-/commit/8a6faa4c6e23f5da197a0249a4122afdb81ae597

Ok, mais ça ne calme pas tant que ça l'arbre de Noël.
Il n'y a pas une source de warning, hélas. Pire, des choses dans le code m'inquiètent qui ne font pas de warning, notamment l'utilisation de l'ancienne syntaxe de connexion de Qt, à savoir :

connect(source, SIGNAL(mySignal()), target, SLOT(mySlot()));

Alors que la syntaxe moderne permet de faire contrôler les paramètres par le compilateur, et non pas à l'exécution :

connect(source, &Source::mySignal, target, &Target::mySlot);

Du coup, pour cela, j'ai sorti Clazy : https://github.com/KDE/clazy/
Un outil qui va automatiquement corriger tout un ensemble de bugs, en signaler d'autres que le compilateur ne va pas lever… Parce que j'avais pas encore assez d'avertissements.

Je ne vous liste pas les commits, mais Clazy a généré des milliers de correctifs sur connect, des correctifs de perfs mineurs, signalé des syntaxes obsolètes…

Corrigeons des bugs

Bon, rendre le projet plus maintenable, c'est une chose, mais il faut aussi s'occuper un peu des bugs qui trainent…

Cas #1 : https://bugs.kde.org/show_bug.cgi?id=239200

Un bug sur un filtre, pourquoi pas, c'est simple, isolé…
L'analyse a été l'occasion de remettre le pied à l'étrier, et même d'explorer un code que je n'avais pas regardé (à savoir les filtres ms office). Le fichier de test est très simple et permet rapidement de voir le problème (c'est à l'origine un rapport de bug des testeurs de Nokia d'ailleurs).
Bon… je pourrais dire que le correctif était à la hauteur de l'analyse, mais perdu… Avec gdb, je me suis rendu compte que le code dans la fonction read_background ne lisait pas l'arrière plan à cause d'un paramètre displayBackgroundShape qui n'était pas valorisé comme il faut…
Du coup, le correctif…
https://invent.kde.org/office/calligra/-/merge_requests/11/diffs

Cas #2 : https://bugs.kde.org/show_bug.cgi?id=406014

Un bug sur un autre filtre, cas simple à nouveau, mais avec un peu de windowseries, et la difficulté du format binaire historique de Word…
Donc on reproduit le fonctionnement : trouver le code incriminé, le lire… et en déduire que c'est juste des encodages non gérés… Facile à nouveau…
https://invent.kde.org/office/calligra/-/commit/be82faae699790e8b5d4f68a2e9e2663ff40477e

Cas #3 : https://bugs.kde.org/show_bug.cgi?id=391223

En 2014, un plugin Okular a été ajouté dans Calligra pour donner à Okular un affichage bien plus complet pour les fichiers OpenDocument. Manque de bol, une fuite mémoire assassine les performances.
Je m'apprête à une recherche compliquée, sortir valgrind… Je teste le plugin Okular, et effectivement, ça fuit. Enfin. Non. Ça explose façon challenger.
J'ouvre le code pour une première imprégnation, et j'en déduis que ce code n'a jamais été relu ni testé sur plus que «ça affiche = ça marche»…

https://invent.kde.org/office/calligra/-/commit/3e3b602aff077e189d2d38826f38fcc8a9e1e486

Et la suite…

J'ai pas fait que ça ces dernières semaines sur Calligra. J'ai aussi travaillé sur des trucs qui m'ont concerné, comme https://invent.kde.org/office/calligra/-/commit/94c7e8fdc7fec0a51cfb2ebe88595712fc7e67e5 qui corrige un vieil ennemi personnel qui est revenu me hanter lorsque j'ai essayé un document Word que je n'arrivais pas à lire dans LibreOffice et qui marche parfaitement dans Calligra, na. Également, un peu de refactoring, l'introduction de nouveaux tests unitaires qui remplacent des fichiers de test perdus il y a plus de 15 ans…
J'espère continuer comme ça les prochaines semaines. Déjà parce que ça m'amuse, mais aussi parce que j'espère qu'en forçant de l'activité sur le projet je pourrai redonner à des gens envie de venir contribuer. C'est loin d'être difficile. Le code est bien découpé, assez bien organisé, avec plein de choses à faire qui ne sont pas nécessairement compliquées.
Il faut que j'arrive à faire marcher une CI digne de ce nom, pour m'assurer que les prochains commits n'introduisent pas de régression et pour faciliter l'arrivée de nouveaux développeurs.
Puis ça reste une suite bureautique largement moins lourde que LibreOffice. Sur mobile, notamment Plasma Mobile, ça me semble bien adapté… Et je me dis qu'on pourrait aussi en faire quelque chose couplé à Nextcloud notamment…

# Merci !

Posté par Maclag le 17 mars 2021 à 22:26. Évalué à 10.

J'utilise presque exclusivement KDE sur mon ordi personnel maintenant, et je préfère largement lancer les outils de Calligra que LibreOffice pour des petite tâches.

Je me disais toujours que je devrais m'y mettre de plus en plus parce que effectivement, c'est plus léger, mais tout en me demandant si ça valait le coup de s'y mettre parce que le projet avait l'air au ralenti.

Donc là je suis ravi de voir que le projet n'est pas mort.

Du coup: merci pour ce que t'as fait avant, et merci de reprendre (ou au moins essayer) le développement maintenant.
# Merci et on croise les doigts

Posté par lerat91 le 17 mars 2021 à 23:09. Évalué à 10.

Je salue cette initiative, en espérant que la sauce prenne et que le projet Calligra revive.
J'espère que tu ne perdras pas courage.
# Top article

Posté par Xavier Verne (site web personnel) le 18 mars 2021 à 07:29. Évalué à 10.

qui donne bien à voir la dynamique des projets libres pas toujours linéaire…

avec ton niveau technique as-tu imaginé un jour contribuer à libreoffice pour l'aider à devenir maître du monde bureautique ?
- [^] # Re: Top article
  
  Posté par Pinaraf le 18 mars 2021 à 12:30. Évalué à 10.
  
  avec ton niveau technique as-tu imaginé un jour contribuer à libreoffice pour l'aider à devenir maître du monde bureautique ?
  
  Oui je l'ai imaginé. Mais LibreOffice est un projet plus difficile à «valoriser», les compétences qu'on va y acquérir sont plus spécifiques.
  
  L'architecture de Calligra est résolument basée sur les technologies KDE et Qt. Quand tu contribues, tu apprends ces technologies. Je pourrais aisément lister des tonnes de projets utilisant également ces briques, et donc auxquels tu peux plus facilement contribuer une fois que tu les as découvertes et que tu les maîtrises. Par exemple sur un projet pro, en Qt, j'ai eu à faire de la mise en forme de texte… les compétences acquises avec Calligra ont été très utiles.
  
  L'architecture de LibreOffice trouve son origine dans StarOffice. Elle est très «années 90», le modèle de composant UNO (Universal Network Objects) par exemple. LibreOffice a également sa propre abstraction pour l'ensemble des plateformes (la VCL). Mais à ma connaissance personne d'autre n'utilise ces technologies. Donc quand tu vas contribuer à LibreOffice, tu vas vite apprendre à connaître puis maîtriser ces dernières, mais jamais tu ne pourras les réutiliser…
  
  Je ne dis pas que je ne contribuerais pas à LibreOffice si on me le proposait comme boulot (si vous lisez ces lignes et êtes en mesure de me le proposer, n'hésitez pas) ou si j'en ressentais le besoin ou l'envie… Mais là, présentement, la balance penche plus en faveur de Calligra.
# Memory leak et warnings

Posté par moi1392 le 18 mars 2021 à 10:52. Évalué à 10.

Je prêche certainement des convaincus ici, mais en allant jeter un oeil à ton commit sur le mémory leak (cas 3), je me rends compte que c'est un code signalé par le compilateur par un warning.
Et là, je retombe dans les travers de discussions avec des collègues qui me donnent envie de ~~m'arracher~~ leur arracher les cheveux, à savoir, éliminer les warning OUI, c'est IMPORTANT et pas que pour le style, la beauté du geste et du code, car quand on en a 469356 (valeur non contractuelle) pendant la compilation complète du logiciel, on rate ceux qui sont vraiment important et cachent de vrais bugs.
Sur une très grosse suite logicielle ça arrive, pas forcément très souvent, mais à la (grosse) louche je dirais qu'une ou deux fois par an je fixe un bug CLIENT et me rends compte qu'il y avait un warning du compilateur me montrant un problème à cet endroit.
Sans compter ceux que je ne fixe pas moi et qui étaient aussi signalés par un warning, sans compter ceux que je fixe et donc je ne remarque même pas le warning vaguement associé, sans compter…
- [^] # Re: Memory leak et warnings
  
  Posté par barmic 🦦 le 18 mars 2021 à 11:12. Évalué à 5.
  
  J'ai dû mal à retrouver le lien, mais il me semble que php avait eu un problème du genre. Ils ont corrigé un bug 2 fois alors que ça réintroduction avait levé un warning et ce serait à la suite de ça qu'ils auraient fait un effort pour supprimer tous les warnings.
  
  Et là, je retombe dans les travers de discussions avec des collègues qui me donnent envie de m'arracher leur arracher les cheveux, à savoir, éliminer les warning OUI, c'est IMPORTANT et pas que pour le style, la beauté du geste et du code, car quand on en a 469356 (valeur non contractuelle) pendant la compilation complète du logiciel, on rate ceux qui sont vraiment important et cachent de vrais bugs.
  
  Il faut retirer ceux qui ne sont pas considérés comme important. C'est généralement configurable.
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: Memory leak et warnings
    
    Posté par claudex le 18 mars 2021 à 12:57. Évalué à 7.
    
    Il faut retirer ceux qui ne sont pas considérés comme important. C'est généralement configurable.
    
    Ça prend aussi du temps, de faire la liste et d'évaluer l'importance de chaque warning, ça peut être plus rapide de corriger les existants.
    
    « 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: Memory leak et warnings
      
      Posté par moi1392 le 18 mars 2021 à 13:49. Évalué à 10.
      
      Par expérience je marche plutot dans l'autre sens, les warning dont je suis sur qu'ils sont la manifestation quasi tout le temps d'un vrai problème, je les passe en WError, et j'utilise sur ma machine perso un compilateur plus récent que sur les machines de production pour en avoir le plus possible.
      C'est souvent de nouveaux warnings obscurs, mais ils sont assez utiles quand j'en chope un.
      Et comme il y en a très peu, je peux me permettre de passer une heure ou deux à tous les fixer et commiter le résultat.
      
      De l'autre coté, pour les warnings TRES nombreux (je pense en particulier au signed/unsigned mismatch), le soucis c'est qu'il sont à 99,99% inoffensifs, et que si je les coupe, je risque de rater LE vrai positif le jour ou je bosse sur un fichier spécifique et que du coup, en ne compilant que lui, je m'attarde un peu sur les warnings que j'ai.
      
      Voila, c'est juste ma life de dev (:
      - [^] # Re: Memory leak et warnings
        
        Posté par barmic 🦦 le 18 mars 2021 à 15:56. Évalué à 7.
        
        De l'autre coté, pour les warnings TRES nombreux (je pense en particulier au signed/unsigned mismatch), le soucis c'est qu'il sont à 99,99% inoffensifs, et que si je les coupe, je risque de rater LE vrai positif le jour ou je bosse sur un fichier spécifique et que du coup, en ne compilant que lui, je m'attarde un peu sur les warnings que j'ai.
        
        Ce qui marche bien pour ça, c'est d'avoir des outils comme sonar qui vont permettre de définir une "gate", c'est à dire un ensemble de propriétés que doit remplir ton code (pas de warning sur le nouveau code, un certains niveau de test, un certain nombre de revues,…).
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
      - [^] # Re: Memory leak et warnings
        
        Posté par Tonton Th (site web personnel, Mastodon) le 18 mars 2021 à 19:45. Évalué à 6.
        
        (je pense en particulier au signed/unsigned mismatch), le soucis c'est qu'il sont à 99,99% inoffensifs,
        
        Et le 0.01%, c'est ceux qui vont te ruiner ta journée.
      - [^] # Re: Memory leak et warnings
        
        Posté par freem le 19 mars 2021 à 11:15. Évalué à 5.
        
        les warning dont je suis sur qu'ils sont la manifestation quasi tout le temps d'un vrai problème, je les passe en WError
        
        Hum… ça m'intéresse, ça. Tu peux passer une seule catégorie de warnings en -Werror? Avec quel compilo?
        Parce que je sais comment changer tous les warnings en erreurs (mais c'est pas vraiment viable, certains warnings type -Wpadded étant parfois obligatoires) ou alors aucun (et on rate tous les warnings importants habituellement, parce que noyés dans la masse de ceux potentiellement utiles)…
        
        pour les warnings TRES nombreux (je pense en particulier au signed/unsigned mismatch), le soucis c'est qu'il sont à 99,99% inoffensifs
        
        C'est pour ça que j'essaie de les corriger tous, y compris ceux-la, sur mes projets perso et mes patchs. À condition que je ne sois pas obligé de désactiver le warning pour y voir clair dans les logs, bien sûr…
        
        [^] # Re: Memory leak et warnings
        
        Posté par pulkomandy (site web personnel, Mastodon) le 27 mars 2021 à 19:57. Évalué à 4.
        
        C'est dans la doc de gcc: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
        
        Voir l'option -Werror= (avec le = suivi du nom du warning)
        
        [^] # Re: Memory leak et warnings
        
        Posté par freem le 28 mars 2021 à 15:54. Évalué à 3.
        
        Merci bien. Le fait que gcc (et clang, d'ailleurs) n'ait pas de man-pages est bien pénible, et je n'arrive jamais à utiliser info.
        
        [^] # Re: Memory leak et warnings
        
        Posté par Tonton Th (site web personnel, Mastodon) le 28 mars 2021 à 20:43. Évalué à 4. Dernière modification le 28 mars 2021 à 20:43.
        
        et je n'arrive jamais à utiliser info.
        
        NAME pinfo - is user-friendly, console-based viewer for Info documents
        
        Un navigateur « à la lynx » pour les pages info, vraiment efficace.
        
        [^] # Re: Memory leak et warnings
        
        Posté par freem le 31 mars 2021 à 11:02. Évalué à 2. Dernière modification le 31 mars 2021 à 11:07.
        
        Je note, ça pourra me servir!
        
        Même si juste améliorer le visualiseur risque fort d'être très loin du confort des man-pages:
        
        une man-page par logiciel, parfois plusieurs dans quelques rares cas (zsh),
        
        dont le nom est même auto-complété (avec zsh, du moins),
        
        mémoire musculaire :)
- [^] # Re: Memory leak et warnings
  
  Posté par Pinaraf le 18 mars 2021 à 11:50. Évalué à 9.
  Je prêche certainement des convaincus ici, mais en allant jeter un oeil à ton commit sur le mémory leak (cas 3), je me rends compte que c'est un code signalé par le compilateur par un warning.
  
  Alors oui mais non :(
  Ni GCC 10, ni Clang 11, ni clang-analyzer, ni clazy n'ont signalé cette fuite.
```
        KWPage page = pageManager->page(request->pageNumber()+1);

        pix = new QPixmap(request->width(), request->height());
        QPainter painter(pix);

        QSize rSize(request->width(), request->height());

        pix = new QPixmap();
```
  L'objet alloué inutilement ligne 3 est donné à un objet sur la pile ligne 4. Ce second objet n'est pas utilisé et est détruit ultérieurement.
  Mais le compilateur n'a aucune information sur les effets de bord possibles de la ligne 4. Ce serait une mauvaise conception, mais l'objet créé sur la pile pourrait prendre «possession» du pointeur et le détruire à sa libération. Ce pourrait être l'équivalent d'un std::unique_ptr…
  
  Mais je suis parfaitement d'accord, moins de warning est souvent synonyme de moins de bugs. J'ai par exemple trouvé dans Calligra un code qui fonctionnait en 32 bits mais pas en 64 bits grâce à un warning…
  - [^] # Re: Memory leak et warnings
    
    Posté par moi1392 le 18 mars 2021 à 12:43. Évalué à 4.
    
    Effectivement, je me suis emballé un peu vite, la ligne 4 n'est pas signalée comme variable non utilisée par un compilateur, ce qui est normal.
  - [^] # Re: Memory leak et warnings
    
    Posté par fearan le 19 mars 2021 à 17:46. Évalué à 2.
    
    ça me conforte dans mon idée qu'on ne devrait plus écrire new dans du c++, ou alors exceptionnellement, et dans ce cas commenter le pourquoi. Les pointeurs intelligent sont là pour ça.
    
    Il ne faut pas décorner les boeufs avant d'avoir semé le vent
    - [^] # Re: Memory leak et warnings
      
      Posté par Pinaraf le 19 mars 2021 à 17:52. Évalué à 4.
      
      Tout à fait, par contre dans le cas de Calligra il va d'abord falloir que l'on modernise nos dépendances, pour le moment on reste sur des vieilles versions ce qui pose problème… Là on est encore en C++11, donc on n'a pas par exemple std::make_unique<T>(…), on doit faire unique_ptr(new T(…)).
      - [^] # Re: Memory leak et warnings
        
        Posté par fearan le 19 mars 2021 à 19:51. Évalué à 3.
        
        oui c'est du c++14 donc pour bientôt :P
        
        https://en.cppreference.com/w/cpp/memory/unique_ptr/make_unique
        
        Je ne pensais pas que des projets était passé à c++11 sans passer au 14, la différence est vraiment minime.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Génial

Posté par épitre le 18 mars 2021 à 14:00. Évalué à 10.

Ça vaut peut-être le coup d'en parler à Nate Graham, pour apparaître dans son résumé hebdo, non ?

https://pointieststick.com/category/this-week-in-kde/
- [^] # Re: Génial
  
  Posté par Pinaraf le 18 mars 2021 à 16:04. Évalué à 8.
  
  Effectivement, bonne idée. Je l'ai contacté, merci à toi
# Rendu de docx dans Calligra, pas mal

Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) le 24 mars 2021 à 19:58. Évalué à 3.

Merci pour Calligra. Je m'en sers assez peu, essentiellement pour dire qu'il existe autre chose que LibreOffice et MsOffice et pour tester des documents, notamment des docx.

Là on vient de m'envoyer des docx à problème, essentiellement des histoires de zones de texte et d'orientation du texte.

Et bien Calligra s'en sort plutôt mieux que LibreOffice et rend bien les orientations : verticales et en biais des zones et donc des texte associés. Par contre la déco (une ligne en biais et un petit rectangle) ont disparu. Je pense que ces histoires de zones de texte c'est vraiment quelque chose de lié à la différence des formats odt et docx, les deux normes appréhendent ça de façon totalement différente. Chapeau.

« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
- [^] # Re: Rendu de docx dans Calligra, pas mal
  
  Posté par Pinaraf le 25 mars 2021 à 09:24. Évalué à 3.
  
  Merci bien. C'est en bonne partie grâce à Nokia qu'on a cette qualité dans le support des formats microsoft.
  N'hésite pas à faire un rapport de bug si les documents sont partageables…

Suivre le flux des commentaires

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