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
- Journal à l’origine de la dépêche (218 clics)
- Le site tout beau tout neuf de WeasyPrint (754 clics)
- Code source sur GitHub (329 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Présentations
Posté par liZe . Évalué à 4. Dernière modification le 10 novembre 2018 à 11:28.
Merci !
À 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 :)…
Avec grand plaisir ! Si vous avez besoin de quoi que ce soit, n'hésitez pas à ouvrir des tickets ou à discuter sur IRC.
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 dark_moule . Évalué à 3.
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 BohwaZ (site web personnel, Mastodon) . Évalué à 7.
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 dark_moule . Évalué à 6.
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 ?
[^] # Re: Présentations
Posté par liZe . Évalué à 2.
Oui, ce serait vraiment utile d'avoir des tutoriels pour accompagner les gens qui ont peu de compétences en CSS. Mais ça demanderait beaucoup de temps :).
Pour l'instant, nous avons plutôt ciblé les gens qui ont l'habitude du développement web (en particulier HTML et CSS) mais qui ne connaissent pas les fonctionnalités spécifiques pour l'impression. Dans les exemples, ils peuvent trouver ces nouvelles propriétés CSS et les utiliser dans leurs propres documents.
Oui, ce serait bien mieux avec des explications. En particulier, le fichier Sass est juste là pour les gens qui préfèrent ce langage à CSS (il sont nombreux parmi les web designers), mais on peut totalement s'en passer et modifier le CSS directement.
:)
Nous avons les compétences pour le faire, mais ce n'est pas particulièrement un service que nous avons pensé à proposer. Par contre, plusieurs retours comme celui-là nous ont déjà fait réfléchir à proposer des formations sur HTML/CSS pour l'impression…
En tout cas, merci beaucoup pour ces informations !
# Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 09 novembre 2018 à 20:05.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Incitatif à l'évolution des pratiques en matière de justification optionnelle
Posté par liZe . Évalué à 8.
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 ;).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 10 novembre 2018 à 15:31.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Incitatif à l'évolution des pratiques en matière de justification optionnelle
Posté par chimrod (site web personnel) . Évalué à 9. Dernière modification le 11 novembre 2018 à 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) :
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 :)
[^] # Re: Incitatif à l'évolution des pratiques en matière de justification optionnelle
Posté par Kerro . Évalué à 3.
C'est à cause du fait que l'espace entre caractères est constant.
Une « bonne » justification se fait entre autre en jouant sur les espaces entre les mots ET l'écart entre les caractères.
[^] # Re: Incitatif à l'évolution des pratiques en matière de justification optionnelle
Posté par liZe . Évalué à 3.
Oui, comme je le disais dans un commentaire du journal, on va maintenant pouvoir se pencher en détail sur les documents donnés en exemple !
# Editeur HTML/CSS recommandé ?
Posté par PhE . Évalué à 2.
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 liZe . Évalué à 3. Dernière modification le 10 novembre 2018 à 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.
[^] # Commentaire supprimé
Posté par Cynthia934 . Évalué à 0. Dernière modification le 29 novembre 2018 à 07:48.
Ce commentaire a été supprimé par l’équipe de modération.
# Alors là...
Posté par tipic . Évalué à 3. Dernière modification le 10 novembre 2018 à 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):
Top. Alors que :
weasyprint https://fr.wikipedia.org/wiki/Ahmôsis_Ier ./weasyprint-website.pdf
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 tipic . Évalué à 3. Dernière modification le 10 novembre 2018 à 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 ted (site web personnel) . Évalué à 2. Dernière modification le 10 novembre 2018 à 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 liZe . Évalué à 2.
Oui, le cas d'usage le plus classique est de générer des documents côté serveur (des factures, des rapports, etc.)
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.
Ah, l'un des éternels débats entre développeurs et webdesigners :)…
[^] # Re: Bien
Posté par AnthonyRabine (site web personnel) . Évalué à 2.
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 barmic . Évalué à 7.
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 jemore . Évalué à 3.
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 liZe . Évalué à 8. Dernière modification le 11 novembre 2018 à 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 collinm (site web personnel) . Évalué à 2.
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
[^] # Re: intéressant
Posté par norbs . Évalué à 2.
itext est toujours opensource (AGPL)…
[^] # Re: intéressant
Posté par collinm (site web personnel) . Évalué à 1.
mon erreur ce que je voulais dire c'est que itext n'est plus disponible sans acheter une licence si on fait du proprio
www.solutions-norenda.com
# VS Browser headless ?
Posté par fraaargh . Évalué à 2.
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 liZe . Évalué à 3.
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 fraaargh . Évalué à 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 Lucas-C (site web personnel) . Évalué à 2.
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 dark_moule . Évalué à 1.
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
[^] # Re: VS Browser headless ?
Posté par liZe . Évalué à 1.
C'est possible d'alterner les formats au sein d'un document en utilisant les pages nommées (la spécification n'est pas très intéressante, mais le premier exemple est assez explicite).
# Pourquoi pas l'ODT
Posté par Cédric Krier (site web personnel, Mastodon) . Évalué à 4.
É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.
[^] # Re: Pourquoi pas l'ODT
Posté par liZe . Évalué à 2.
On avait testé cette option au début, mais on avait été rebutés par quelques points.
Le point principal est qu'il est plus facile de trouver des gens capables de faire des beaux documents en HTML et des belles feuilles de style en CSS. Pas mal de gens ont l'habitude de créer du HTML et du CSS, et on ne compte plus tous les outils mis à leur disposition pour leur faciliter la vie (que ce soit pour les éditeurs de texte, les linters, les langages de templating, les préprocesseurs, etc). LibreOffice peut être un peu rebutant à la fois pour les développeurs et pour les designers.
(Bien sûr, mon point de vue est largement biaisé par le fait qu'on fait du web là où je bosse :).)
Sinon, on avait d'autres trucs qui nous dérangeaient sans être insurmontables, en particulier l'installation de LibreOffice sur des serveurs (sans version headless à l'époque), le manque de flexibilité des modèles LibreOffice par rapport aux langages de templating HTML, la gestion de versions et le travail collaboratif, etc.
Par contre, relatorio a l'air vraiment adapté pour faire rapidement des documents simples. C'est par exemple mille fois plus léger d'utiliser LibreOffice + relatorio pour générer des factures que de sortir l'artillerie lourde du HTML + CSS.
[^] # Re: Pourquoi pas l'ODT
Posté par Cédric Krier (site web personnel, Mastodon) . Évalué à 2.
OK, je comprends. Ça dépend vraiment de qui va créer les "templates". Dans notre cas, on cherchait à avoir un outil plus ou moins WYSIWG.
Par contre, il n'y a pas besoin d'avoir LibreOffice pour générer des ODT avec relatorio. C'est seulement si on veut convertir dans un autre format. Du point de vue "templating", relatorio est basé sur Genshi et donc il y a vraiment toutes les fonctionnalités des moteurs de templating.
# Merci !
Posté par ocebe . Évalué à 2.
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.
[^] # Re: Merci !
Posté par liZe . Évalué à 1.
:D
# Format source de la doc en reStructuredText :-/
Posté par Gohar . Évalué à 0. Dernière modification le 15 novembre 2018 à 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 chimrod (site web personnel) . Évalué à 4. Dernière modification le 16 novembre 2018 à 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
[^] # Re: Format source de la doc en reStructuredText :-/
Posté par liZe . Évalué à 1.
C'est par exemple ce que fait Pandoc en utilisant plein d'outils dont WeasyPrint.
[^] # Re: Format source de la doc en reStructuredText :-/
Posté par chimrod (site web personnel) . Évalué à 2.
Tu es sûr de toi ? Pandoc est écrit en Haskell, et je ne crois qu'il ait de dépendance vers python.
La seule dépendance externe est pour générer du pdf, mais je crois que c'est la seule…
[^] # Re: Format source de la doc en reStructuredText :-/
Posté par claudex . Évalué à 5.
Vu que c'est le but de weasyprint…
https://pandoc.org/MANUAL.html
« 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: Format source de la doc en reStructuredText :-/
Posté par liZe . Évalué à 3. Dernière modification le 26 novembre 2018 à 17:32.
Pas vraiment. Mon but n'est pas de pousser le monde entier à écrire du HTML à la main !
L'avantage de HTML est justement qu'il existe des tonnes de façons d'en générer. Qu'on soit fan de langages de templating, de PHP, de langages légers comme ReST ou Markdown, peu importe : on arrive souvent à sortir du HTML.
En particulier, pour des longs documents textuels où la mise en page est répétitive (comme la documentation), autant utiliser un langage de balisage léger. En plus, Sphinx (très largement utilisé pour la documentation des modules Python et sur ReadTheDocs en général) propose ReST par défaut.
Dans tous les cas, l'important est d'avoir du HTML en sortie :).
[^] # Re: Format source de la doc en reStructuredText :-/
Posté par Gohar . Évalué à 1. Dernière modification le 28 novembre 2018 à 12:23.
Merci pour ta réponse, qui m'aide à mieux cerner cette solution !
Je suis en effet confronté à des demandes de rédacteurs occasionnels qui voudraient faire du single-sourcing sans rien changer à leurs habitudes de travail. Forcément, l'exercice a ses limites, difficiles à faire percevoir…
# Bien joué
Posté par dodger (site web personnel) . Évalué à 0.
Je dois sortir des factures à longueur de mois et je pensais avoir un peu fait le tour de la question. A partir d'un site sous Laravel, j'ai essayyé watrouzemille outils ou libs pour sortir mes PDF, mais je confirme que les formats d'impression sont généralement assez mal gérés. Bref, je vais me jeter sur votre projet et l'essayer de ce pas. Merci pour ce beau boulot !
[^] # Re: Bien joué
Posté par liZe . Évalué à 1.
N'hésitez pas à nous faire signe si vous rencontrez des problèmes !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.