Première version stable pour WeasyPrint

Posté par . Édité par ZeroHeure, Davy Defaud et palm123. Modéré par Pierre Jarillon. Licence CC by-sa.
Tags :
45
9
nov.
2018
Python

WeasyPrint est un générateur de documents : il transforme des pages HTML/CSS en PDF. Il peut être utilisé en ligne de commande ou comme bibliothèque Python. Et son histoire est très intéressante, laisse‐moi donc te la conter…

Un peu d’histoire

WeasyPrint est né il y a environ huit ans. J’avais dans mon entreprise un besoin de générer des rapports, des présentations et des factures automatiquement, avec une mise en page un peu travaillée.

Nous avions alors testé pas mal de solutions basées sur les formats suivants :

Pour diverses raisons (qui sont détaillées dans cette présentation si ça vous intéresse), nous avons finalement opté pour des documents en HTML et CSS. Pourquoi, me diras‐tu donc ? D’abord parce c’est un format très facile à générer, puisque toutes les applis Web créent à la volée des pages en HTML. Ensuite, CSS est un langage que beaucoup de designers connaissent, ce qui est pratique pour faire de jolis documents (étonnamment, ils ont généralement moins de connaissances en LaTeX, va savoir pourquoi). Enfin, on le sait peu, mais c’est un langage qui a des fonctionnalités dédiées à l’impression, avec des spécifications permettant de gérer correctement les coupures de pages, les numéros de pages et tout ce qu’il faut pour avoir des documents pour l’impression un peu sérieux.

Restait un tout petit point de détail : nous avions besoin d’un moteur de rendu qui sache gérer ces fonctionnalités dédiées à l’impression. Et pour être franc, les gens qui développaient Gecko (pour Firefox) et WebKit (pour Safari et Chrome à l’époque) avaient d’autres chats à fouetter que d’intégrer ces fonctionnalités. On a bien essayé également de contribuer à ces projets, mais… Tu sais, c’était bien trop difficile de faire rentrer au burin des fonctionnalités de paginations dans un logiciel suroptimisé pour dessiner des contenus sur une seule page.

Comme nous ne souhaitions pas dépendre d’outils propriétaires (tels que Prince, par exemple), nous nous sommes lancés dans cette idée stupide : créer un moteur de rendu HTML/CSS à partir de rien.

Et nous avons réussi. :)

Huit ans après, une version stable

Huit ans après, il est temps de sortir une version stable. Nous avons au fil des années ajouté la prise en charge de nombreuses fonctionnalités, comme les en‐têtes et pieds de page, pas mal d’options de typographie avancée, les références croisées, la césure automatique de mots, les formats de page différents, l’affichage en colonnes multiples, etc.
N. D. A. : Si les dernières fonctionnalités t’intéressent, le journal des modifications est une bonne source d’information.

Bien sûr, tout n’est pas parfait. WeasyPrint ne mettra pas en page magiquement n’importe quel site pour l’impression. Il reste également des bogues à corriger et des fonctionnalités à ajouter (et il en restera toujours, eh eh eh, tu te doutes bien). Mais nous comptons aujourd’hui pas mal d’utilisateurs plutôt prestigieux (dont la ville de New‐York et le gouvernement du Royaume‐Uni par exemple), et l’outil est largement assez stable pour être utilisé en production.

Pour fêter cela, nous avons créé un site tout beau tout neuf, avec une présentation plus claire de WeasyPrint, une nouvelle charte graphique et quelques exemples de documents pour que tu trouves l’inspiration.

Nous comptons également consacrer de plus en plus de temps au développement de logiciels libres, et connaître au mieux les besoins réels des utilisateurs réels :). Nous bénéficions évidemment nous‐mêmes des améliorations qui sont apportées avec le temps, mais nous aimerions avant tout que les développements futurs bénéficient à un maximum d’utilisateurs.

Si tu es utilisateur ou juste curieux, fais‐nous signe ! N’hésite donc pas à râler à cause des bogues, à demander des fonctionnalités, à améliorer la documentation ou à participer financièrement au développement.

Aller plus loin

  • # Présentations

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

    Félicitations. C'est gros succès, ambitieux.

    Il y a une dizaine d'années, j'avais besoin de vers un PDF de bon de commande et j'avais opté pour un webkit2html maison. J'avais aussi buté sur les manques de l'implémentation des CSS pour l'impression, tout moteurs confondus. Je comprends tout à fait que vous ayez été poussé vers l'écriture d'un moteur.

    Et bravo aussi pour le Python 3.4. Pour un logiciel de 8 ans, je trouve que c'est un signe de qualité !

    Chez Dalibo, on s'intéresse à WeasyPrint, alors attendez-vous à quelques PR ;-)

    Avez-vous des retours pour la génération de présentations PDF à partir de revealjs ? Ça doit pas être facile !!

    • [^] # Re: Présentations

      Posté par . Évalué à 4 (+3/-0). Dernière modification le 10/11/18 à 11:28.

      Félicitations. C'est gros succès, ambitieux.

      Merci !

      Et bravo aussi pour le Python 3.4. Pour un logiciel de 8 ans, je trouve que c'est un signe de qualité !

      À vrai dire, j'en avais un peu marre de continuer à corriger des bugs sur des cas particuliers en Python 2. Et comme Python 3 a 10 ans le mois prochain, on ne peut plus vraiment dire que c'est le futur :)…

      Chez Dalibo, on s'intéresse à WeasyPrint, alors attendez-vous à quelques PR ;-)

      Avec grand plaisir ! Si vous avez besoin de quoi que ce soit, n'hésitez pas à ouvrir des tickets ou à discuter sur IRC.

      Avez-vous des retours pour la génération de présentations PDF à partir de revealjs ? Ça doit pas être facile !!

      C'est marrant, c'est exactement le cas d'usage qui est mis en avant dans la présentation dont je parle dans l'article :). Sincèrement, tant qu'on fait des choses simples ça marche à peu près tout seul, sinon il faut un peu de connaissances en CSS et un peu de chance ;).

      • [^] # Re: Présentations

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

        Félicitations aussi car c'est un projet ambitieux et très intéressant !

        La seule solution que je connaissais jusqu'à présent est https://www.princexml.com et https://docraptor.com/ qui est basé dessus mais je n'ai jamais franchi le pas pour les utiliser. Pour ceux qui ne connaissent que ces deux logiciels, est-il possible d'indiquer brièvement les différences ?

        Bien que n'étant pas habitué à manipuler le CSS ou le HTML je vais essayer votre solution pour générer des rapports à la place d'utiliser Scribus comme je le fais actuellement car le HTML permet certainement de comparer beaucoup plus facilement les différences entre deux versions.

        J'essayerai de vous faire un retour.

        Merci encore d'offrir cette solution

        • [^] # Re: Présentations

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

          J'utilise Prince pour générer des livres qui sont ensuite imprimés et vendus.

          C'est très efficace, léger et rapide, avec un excellent support des propriétés CSS pour l'impression. Je génère un livre de 300-400 pages avec une 50aines d'images haute résolution et beaucoup de texte en quelques dizaines de secondes. Pour moi c'est l'exemple typique de l'excellent logiciel, contenu, léger, très bien documenté, mais proprio…

          Pour info PrinceXML est développé entre autres par l'inventeur de CSS, ça aide ;)

          Je n'ai pas encore trop utilisé WeasyPrint mais découvert récemment et c'est prévu d'essayer :)

          A noter que les développeurs de Ghostscript produisent également l'excellent MuPDF qui dispose d'un moteur de rendu HTML/CSS et d'un moteur JS et permet aussi de convertir du HTML/CSS en PDF, mais le support des propriétés spécifiques à l'impression est plus limité (mais il est très rapide):

          « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

        • [^] # Re: Présentations

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

          Mon retour comme prévu :

          Globalement le projet semble avoir de nombreuses fonctions mais la documentation n’accompagne pas suffisamment les utilisateurs, au moins ceux qui n’ont pas de compétences en CSS comme moi. Il me semble que développer les exemples en donnant des informations sur comment faire des modifications serait vraiment intéressant.

          En détail, l’installation est très simple sur Arch puisque un paquet est fourni. Une fois celui-ci installé, je télécharge l’exemple de rapport sur le site pour l’essayer. Malheureusement pour télécharger l’exemple il faut télécharger 16 fichiers un par un…

          Bref, une fois celui-ci téléchargé, je regarde le tuto qui indique la commande à utiliser. Et hop le PDF est généré ! Super. Malheureusement celui-ci contient des anomalies d’affichages… car le paquet ne correspond pas à la toute dernière version publiée la semaine dernière. Pour utiliser les exemples il faut donc la version 43 ce qui complexifie l’installation mais rien d’impossible.

          Je continue donc de lire la doc pour continuer à être accompagné et là… ben en fait il n’y a pas d’accompagnement dans le tuto ! Argh comment faire des modifications de l’exemple alors !?! Dans la section “features” il y a bien des pistes qui sont donnés, mais de là à savoir comment les utiliser concrètement c’est pas gagné…

          J’ouvre le fichier HTML et le fichier CSS mais c’est pas simple de comprendre ! Je continue de regarder les autres fichiers en espérant tomber sur un fichier d’accompagnement mais rien… ah tiens un fichier.sass qui ressemble beaucoup à du CSS. Après des recherches je comprends qu’il s’agit d’une sorte de modèle permettant de construire un fichier CSS qu’il ne faut donc pas modifier directement ! J’installe donc ruby-sass mais indiquer la manœuvre pour modifier l’exemple ne serait pas superflu.

          Après environ 1 heure 30 de recherches et d’essai empiriques j’ai enfin réussi à déplacer le numéro de page de l’en-tête vers le pied de page, de même que le trait horizontal et j’ai même réussi à positionner les numéros sur l’extérieur de la page à l’aide des sélecteurs left et right. Ouf ! Les infos sur les pages du W3C et de PrinceXML apportent un peu d’aide mais cela reste poussif pour moi étant donné que je ne suis pas développeur.

          Comme mes rapports sont habituellement au format A5, j’essaye de trouver une solution pour changer le format et environ 15 minutes plus tard j’ai un document PDF au format A5. À part les coordonnées de la 1ère page qui n’ont pas aimé de même que les 3 colonnes de textes, le reste du document a bien supporté le changement de format.

          Par contre il me reste tellement de boulot pour refaire mon rapport de 15 pages que je vais continuer à utiliser mon modèle Scribus

          Cela n’est pas précisé sur votre site mais l’équipe est en mesure de créer un modèle à partir d’un rapport existant ?

  • # Incitatif à l'évolution des pratiques en matière de justification optionnelle

    Posté par . Évalué à 4 (+9/-1). Dernière modification le 09/11/18 à 20:05.

    Récemment, je voyais passer — en commentaire sur Linuxfr.org — un lien vers un article titré « Justify text with HTML/CSS? Don't do it! - Design for Hackers ». Je l'ai lu et je me suis convaincu qu'il est généralement préférable, sur le web (et en l'état), de ne pas utiliser la justification.

    Note : en écrivant ce message, j'observe qu'il y a des avis divergents exprimés dans un autre commentaire, avec des sources que je n'ai pas consultées.

    Je suppose qu'un logiciel de génération de PDF (à partir de HTML/CSS) qui gère correctement les césures — voire, pourquoi pas, à terme (si ce n'est pas déjà le cas, je n'ai pas vérifié au-delà de cette dépêche), ajusterait finement l'espacement inter-lettres et la largeur des fontes pour limiter l'apparition d'espacements inter-mots de dimensions variées — pourrait inciter à l'évolution des pratiques en matière de paramétrage de justification sur le web, de manière à la rendre sélectivement active spécifiquement pour l'exportation vers du PDF / l'impression, conformément à une norme de fait qui pourrait émerger, si elle n'existe pas déjà.


    Il y a une petite coquille en tête de la dépêche : le premier paragraphe est répété deux fois.

    • [^] # Re: Incitatif à l'évolution des pratiques en matière de justification optionnelle

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

      Je suppose qu'un logiciel de génération de PDF (à partir de HTML/CSS) qui gère correctement les césures — voire, pourquoi pas, à terme (si ce n'est pas déjà le cas, je n'ai pas vérifié au-delà de cette dépêche), ajusterait finement l'espacement inter-lettres et la largeur des fontes pour limiter l'apparition d'espacements inter-mots de dimensions variées — pourrait inciter à l'évolution des pratiques en matière de paramétrage de justification sur le web, de manière à la rendre sélectivement active spécifiquement pour l'exportation vers du PDF / l'impression, conformément à une norme de fait qui pourrait émerger, si elle n'existe pas déjà.

      Cette norme existe, et elle s'appelle … CSS :). Il y a beaucoup de fonctionnalités qui sont spécifiées, dont des règles de césure complexes et l'espacement inter-mots et inter-lettres. La spécification permet d'appliquer ces règles selon l'envie pour l'affichage sur écrans, pour la génération de documents imprimables ou pour les deux. Il ne manque que des bonnes implémentations de ces fonctionnalités, et des feuilles de style qui les utilisent !

      WeasyPrint gère pas mal de choses concernant la césure, mais reste pauvre sur les règles de justification. Si certains sont intéressés, les contributions sont les bienvenues ;).

      • [^] # Re: Incitatif à l'évolution des pratiques en matière de justification optionnelle

        Posté par . Évalué à -10 (+0/-11). Dernière modification le 10/11/18 à 15:31.

        Ok, liZe ;) Là, tu viens de passer le test dit de super Turing qui consiste à comprendre correctement une de mes phrases de 111 mots (1) et d'y répondre avec pertinence.

        Non seulement ça mérite une ovation (et pour certains une indignation, car je passe pour pestiféré aux yeux opacifiés d'âmes égarées), mais je crois que ça mérite plus que ça, une inspiration d'un hacker-fée bienveillant·e (2), voire d'un troupeau de GNU hackers-fées, inspiration incitative au passage à l'acte du codage. Ce ne sont pas les adeptes de la typographie pleine de grâce qui manquent par ici.

        Je m'y serais bien collé, mais j'ai piscine rédigé un cahier des charges (3) d'un principe logiciel innovant (sans IA), permettant le parcours indexé de la connaissance par la sélection d'un extrait de contenu multimédia sur lequel on veut un approfondissement (accentué, ou moindre), pour accéder à la consultation du passage (plus, ou moins) approfondi correspondant. Pire, je me suis engagé à le coder, comme un nouveau projet en haut d'une pile LIFO qui comprend Zin[o|d] (le nœud qui se dénoue en deux temps, Zino et ZIND) qu'il faut que je commence à dépiler…

        Je t'adresse un gros merci pour ta réponse d'excellence et je reste observateur bienveillant.

        (1) si si, le compte y est, l'essentiel est codé dans mes messages, je m'adapte à la kabbale en cours, private joke wink.
        (2) je m'essaye aussi à la typographie post-moderne à mes heures perdues, héhéhé :b
        (3) si le sujet t'intéresse, tu peux opérer un petit parcours indexé conventionnel en cliquant ici et en considérant ce qui commence à la section titrée « Traduction d'expressions riches », voire en cliquant sur l'un ou l'autre des 3 liens que tu trouveras.

      • [^] # Re: Incitatif à l'évolution des pratiques en matière de justification optionnelle

        Posté par (page perso) . Évalué à 7 (+5/-0). Dernière modification le 11/11/18 à 12:31.

        À ce titre, je trouve que votre exemple de rapport très inesthétique en terme de texte justifié (cela m'a sauté aux yeux quand je suis allé voir votre site) :

        Rivières dans le rapport

        En suivant votre documentation, il suffit de modifier deux lignes pour activer les césures sur la page, et l'on se retrouve avec un texte beaucoup plus esthétique :

        Je pense que le document d'exemple sur votre site mériterait une mise à jour :)

  • # Editeur HTML/CSS recommandé ?

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

    Quel est l'éditeur WYSIWYG HTML/CSS recommandé ?
    Je veux dire un éditeur capable de gérer les particularités d'un document paginé (pagination, marges, positionnement précis relatif à la page, …). Pour les moteurs de rendu à base d'ODT, il y a LibreOffice et pour ceux à base de SVG, il y a Inkscape.

    • [^] # Re: Editeur HTML/CSS recommandé ?

      Posté par . Évalué à 2 (+1/-0). Dernière modification le 10/11/18 à 20:02.

      Je n'ai pas encore trouvé d'éditeur WYSIWYG qui me plait pleinement, je préfère éditer mes fichiers HTML avec mon éditeur favori. Je lance généralement une commande qui génère le PDF à chaque fois que les fichiers HTML ou CSS sont modifiés, et mon lecteur PDF met à jour l'affichage seul.

  • # Alors là...

    Posté par . Évalué à 3 (+2/-0). Dernière modification le 10/11/18 à 15:34.

    Bonjour tous.
    C'est juste extraordinaire ce truc, tant au niveau de la qualité du rendu qu'à la facilité d'utilisation.
    Chapeau bas ! Juste ce qu'il me manquait.

    Petite note (bug):

    weasyprint https://fr.wikipedia.org/wiki/Ahmès-Néfertary ./weasyprint-website.pdf
    

    Top. Alors que :

    weasyprint https://fr.wikipedia.org/wiki/Ahmôsis_Ier ./weasyprint-website.pdf
    Traceback (most recent call last):
    File "/home/main/venv/bin/weasyprint", line 11, in
    sys.exit(main())
    File "/home/main/venv/lib/python3.6/site-packages/weasyprint/main.py", line 173, in main
    getattr(html, 'write_' + format_)(output, **kwargs)
    File "/home/main/venv/lib/python3.6/site-packages/weasyprint/init.py", line 199, in write_pdf
    target, zoom, attachments)
    File "/home/main/venv/lib/python3.6/site-packages/weasyprint/document.py", line 577, in write_pdf
    surface.show_page()
    File "/home/main/venv/lib/python3.6/site-packages/cairocffi/surfaces.py", line 584, in show_page
    self.check_status()
    File "/home/main/venv/lib/python3.6/site-packages/cairocffi/surfaces.py", line 160, in _check_status
    _check_status(cairo.cairo_surface_status(self._pointer))
    File "/home/main/venv/lib/python3.6/site-packages/cairocffi/
    init_.py", line 79, in _check_status
    raise exception(message, status)
    cairocffi.CairoError: cairo returned CAIRO_STATUS_TAG_ERROR: b'invalid tag name, attributes, or nesting'

    • [^] # Re: Alors là...

      Posté par . Évalué à 3 (+2/-0). Dernière modification le 10/11/18 à 15:58.

      un bref regard, il est possible que ce soit un bug concernant les url avec caractères accentués.
      Après un petit regard dans le code.

  • # Bien

    Posté par (page perso) . Évalué à 2 (+1/-0). Dernière modification le 10/11/18 à 18:06.

    Les documents générés sont bien propres. Si je comprend bien: ce logiciel se lance en local, et va générer un pdf à partir d'une page web. Et si cette page web a une feuille CSS bien faite, ça sort un beau document. Je suppose que ça peut aussi servir à générer des documents coté serveur? Auquel cas, ça pourrait être intéressant pour un de mes futurs projets.
    Est ce que ça pourrait tourner chez des hébergeurs proposant le langage python sur leur hébergements mutualisés, comme 1&1?

    PS: Je suis pas fan des sites avec animations… C'est lent

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

    • [^] # Re: Bien

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

      Les documents générés sont bien propres. Si je comprend bien: ce logiciel se lance en local, et va générer un pdf à partir d'une page web. Et si cette page web a une feuille CSS bien faite, ça sort un beau document. Je suppose que ça peut aussi servir à générer des documents coté serveur? Auquel cas, ça pourrait être intéressant pour un de mes futurs projets.

      Oui, le cas d'usage le plus classique est de générer des documents côté serveur (des factures, des rapports, etc.)

      Est ce que ça pourrait tourner chez des hébergeurs proposant le langage python sur leur hébergements mutualisés, comme 1&1?

      Du moment qu'il y a Cairo et Pango installés (ils le sont par défaut sur la majorité des distributions), ça devrait fonctionner sans problème.

      PS: Je suis pas fan des sites avec animations… C'est lent

      Ah, l'un des éternels débats entre développeurs et webdesigners :)…

      • [^] # Re: Bien

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

        Non c'est pas un débat, c'est nul d'attendre 5 secondes pour afficher du texte, point barre. C'est une grave erreur de design. Perso la première fois je croyais que le site avait planté et j'ai fermé l'onglet.

        • [^] # Re: Bien

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

          Je viens d'essayer sur plusieurs machine (dont mon téléphone qui n'est pas un fleuron du marché (et qui ne l'a jamais était) et mon PI2) et plusieurs navigateur sans rencontrer de ralentissement particulier.

          Bref je n'arrive pas à reproduire ton problème.

          Arriver avec des idées toute faites en imaginant que ton expérience est la même que celle de tout le monde et en déduire des affirmations avec tes gros sabots, ça n'ouvre pas à la discussion (mais c'est probablement ce que tu cherche, j'imagine ?).

  • # wkhtmltopdf

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

    On a cité dans un commentaire précédent, l'outil "WKHTMLTOPDF". quelle est la différence de WeasyPrint par rapport à ce outil ?

    • [^] # Re: wkhtmltopdf

      Posté par . Évalué à 7 (+6/-0). Dernière modification le 11/11/18 à 09:53.

      wkhtmltopdf est basé sur WebKit, un moteur de rendu CSS très performant mais qui n'est pas dédié à la génération de documents imprimables.

      WeasyPrint au contraire supporte une bonne partie des propriétés CSS pour l'impression : en-têtes et pieds de pages, références croisées, sommaire PDF, traits de coupe, fonds perdus, formats de pages variables, règles de coupure de pages…

  • # intéressant

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

    j'en cherchait un récemment mais en java, car créér des rapports en PDF c'est long et laborieux.

    itext fait ça
    l'ancienne version de itext opensource le faisait mais est très moyen

    j'ai utilisé avec succès openhtmltopdf, autrement il y a flyingsaucer

    bien heureux qu'il y est des alternatives dans d'autre langage

    www.solutions-norenda.com

  • # VS Browser headless ?

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

    Bonjour et merci pour l'article et l'outil.
    Comme le sujet revient régulièrement, j'y ai déjà été confronté et fut un temps j'avais fait monté un petit POC avec un browser headless (Chrome mais il me semble que Firefox enregistre aussi en PDF headless maintenant).
    On pouvait même interagir avec la page après sa création coté serveur en utilisant phantomjs ou casperjs avant de lancer l'impression PDF.
    Ca marchait comme attendu mais ça n'est resté qu'un POC simple et finalement l'équipe génère toujours ses PDF avec un vieux iText (beuark…). Et fait même parfois 2 versions, une IText et une html (double beauark…).

    Weasyprint offre t'il des avantages par rapport à un browser headless de nos jours ?

    • [^] # Re: VS Browser headless ?

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

      Oui, en particulier la gestion de pas mal de fonctionnalités (dont j'ai parlé au-dessus, je radote) : en-têtes et pieds de pages, références croisées, sommaire PDF, traits de coupe, fonds perdus, formats de pages variables, règles de coupure de pages…

      • [^] # Re: VS Browser headless ?

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

        OK merci, la plupart de ces mots ne veulent rien dire pour moi mais je vais me documenter ! Merci !

      • [^] # Re: VS Browser headless ?

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

        Bravo pour ce beau projet !

        Pour info j'utilise le "headless browser" puppeteer-cli et il gère les page-breaks.

        Il fait très bon ménage en combinaison avec markdown-it et sa tripoté de plugins, pour gérer par exemple un sommaire.

        Pour les traits de coupe, de quoi s'agit-il ?

        Une fonctionnalité bien utile : est-ce que weasyprint supporte le format paysage ?

        • [^] # Re: VS Browser headless ?

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

          Les traits de coupe sont utiles pour l'imprimeur puisque cela permet de couper la page comme souhaité. En effet, pour éviter un cadre blanc non imprimé autour de la page il imprime généralement sur une page avec quelques millimètres supplémentaires et coupe ensuite à bonne taille. D'où le nom de traits de coupe…

          Pour le format paysage c'est possible mais a priori uniquement pour tout le document. Il ne semble pas possible d'alterner paysage et portait dans un même document : https://weasyprint.readthedocs.io/en/stable/features.html

  • # Pourquoi pas l'ODT

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

    Étant un des auteurs de relatorio qui est un générateur d'ODT, je me demande pourquoi l'option ODT n'a pas été retenue ? Je n'ai pas retrouvé les raisons dans la vidéo.

  • # Merci !

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

    Utilisé depuis des années en entreprise, je n'avais même pas conscience qu'il n'était pas considéré comme stable vu le peu de problèmes rencontrés et le résultat impeccable… ça fait toujours son petit effet auprès des responsables quand en un coup de script on remplace des rapports très coûteux par quelque chose de visuellement agréable et de facile à modifier.

  • # Format source de la doc en reStructuredText :-/

    Posté par (page perso) . Évalué à 1 (+0/-0). Dernière modification le 15/11/18 à 14:49.

    Pourquoi la documentation de cette belle solution est-elle en reStructuredText et non en HTML ?

    https://raw.githubusercontent.com/Kozea/WeasyPrint/master/docs/tutorial.rst

    Quelque chose contre la philosophie du "eat your own dogfood" ?

    • [^] # Re: Format source de la doc en reStructuredText :-/

      Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 16/11/18 à 11:02.

      RST est un très bon format, complètement dans l'esprit du produit, puisqu'il permet de séparer la forme du fond. Des convertisseurs sont fournis en standards pour convertir un document rst en html.

      À contrepied de ton commentaire, j'aurai plutôt souhaité une chaine de transformation complète : rst > html > pdf

Envoyer un commentaire

Suivre le flux des commentaires

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