WeasyPrint est un générateur de documents qui transforme du HTML/CSS en PDF. C’est écrit en Python, c’est libre (bah oui, sinon on n’en parlerait pas ici), et nous en avions déjà discuté ici il y a quelques années dans un petit article.
Avec le temps (plus de 11 ans depuis le premier commit, que le temps passe vite ma p’tite dame…), le logiciel a gagné une sacrée ribambelle d’utilisateurs avec plus de 750 000 téléchargements par mois. Parmi tous ces gens qui utilisent WeasyPrint, on a forcément rencontré plein de gens avec plein d’idées pour générer plein de drôles de trucs ! Nous avons croisé entre autres des rapports de sécurité informatique 🖥️, des livres de jeu de rôle 🎮️, des tickets 🎫️, des documents scientifiques 🧮️, des factures de sites de vente en ligne 📄️, des compte-rendus biologiques ⚛️, des modes d’emploi de fours 🧑🍳️, des lettres officielles 💌️, des étiquettes électroniques 🏷️, des affiches promotionnelles en pharmacies ⚕️, des diplômes universitaires 🎓️…
Forts de ce petit succès, Lucie Anglade et moi (Guillaume Ayoub) avons créé depuis deux ans une structure qui s’appelle CourtBouillon (oui, parce que notre autre passion est la bonne nourriture) dédiée au développement de WeasyPrint et de ses dépendances. Nous avons donc pu passer beaucoup de temps à travailler sur le logiciel et apporter plein de nouveautés, tout en nous posant beaucoup de questions pour assurer un modèle économique viable. Voilà ce que l’on aimerait partager avec vous.
Sommaire
Deux ans à toute vitesse
Depuis le début de l’an dernier, nous avons publié 4 versions majeures qui englobent une bonne liste de fonctionnalités dont voici les plus importantes :
- les notes de bas de page,
- les coupures de blocs après un certain nombre de lignes (pour que le texte ne dépasse pas de la page),
- les coupures forcées ou interdites dans les colonnes,
- le respect de la norme PDF/A (pour avoir des documents archivables),
- les coupures de pages dans les cellules d’un tableau, les blocs flottants et les blocs absolus,
- la gestion des polices bitmap (pratique pour faire des étiquettes électroniques parfaites au pixel près),
- l’insertion de points de suite (mais si, vous savez ce que c’est, ce sont les petits points entre le nom d’un chapitre et le numéro de page dans une table des matières),
- la génération reproductible de fichiers PDF,
- le support des principaux sélecteurs CSS de niveau 4 (comme
:is()
,:where()
,:has()
), - sans oublier une génération bien plus rapide et des fichiers générés plus petits.
Nous en avons également profité pour créer pydyf, une bibliothèque bas niveau de génération de PDF, histoire d’avoir les mains libres pour ajouter certaines fonctionnalités. C’était une volonté depuis de longues années (pour supporter le format PDF/A par exemple) mais la spécification PDF a nécessité un peu de temps avant d’être apprivoisée 😉️.
Pour parler de tout cela, nous avons écrit une toute nouvelle documentation que nous espérons mieux organisée et plus claire. Nous avons également rédigé une longue série d’articles avec nos copains de Madcats qui ont créé de très jolis documents dont vous pouvez vous inspirer pour créer les vôtres.
En bref, on n’a pas chômé. Mais où a-t-on trouvé tout ce temps ?
Le temps et l’argent
La raison d’être de CourtBouillon est de créer, développer et maintenir des logiciels libres. Et pour cela, il faut avoir du temps, beaucoup de temps, vraiment beaucoup de temps.
Tout le monde veut toujours plein, plein, plein de fonctionnalités, et nous avons un avantage de ce côté-là : CSS en voit fleurir de nombreuses à un rythme soutenu. Comme nous nous appuyons rigoureusement sur ces spécifications, nous avons donc « juste » à les implémenter. Évidemment, à chaque fois qu’une nouvelle propriété est supportée par les navigateurs, les gens se ruent sur nous pour demander pourquoi WeasyPrint ne la supporte toujours pas alors que Chrome et Firefox la gèrent très bien depuis au moins 2 semaines (j’éxagère à peine 😁️). Pour la faire court : ça prend du temps.
Au-delà du code et de ses fonctionnalités, nous passons des jours entiers à trier les tickets, répondre aux questions, tweeter, écrire des articles, corriger des bugs et peaufiner la documentation. Ce travail est peu visible mais il prend bien plus de temps que ce que la plupart des utilisatrices et des utilisateurs imaginent. C’est pourtant un travail de fond nécessaire pour garder nos projets en bonne santé et ne pas crouler rapidement sous les demandes insatisfaites.
Encore au-delà ce travail peu valorisé se cache tout le travail de l’ombre que l’on ne voit pas du tout. Lire des spécifications, que ce soit pour CSS ou PDF, est devenu une seconde nature pour nous, et nous nous sommes habitués au langage étrange que l’on trouve dans ces documents. Certaines rumeurs disent même que nous en rêvons la nuit… Nous devons également faire particulièrement attention à la qualité du code. Nous sommes une toute petite équipe et nous avons, mine de rien, à maintenir un moteur de rendu HTML/CSS… Il est par conséquent très important de s’assurer au quotidien que la dette technique ne s’accumule pas et que l’architecture globale est toujours bien solide, sous peine de se retrouver sous l’eau dans le futur à l’ajout de la moindre fonctionnalité. Au-delà de l’interminable suite de tests (car oui, dans WeasyPrint nous avons plus de lignes de Python pour les tests que pour le code), il est nécessaire de retoucher l’architecture de nos bibliothèques de temps en temps, tout comme nous devons supporter les dernières versions de Python et des diverses dépendances que nous avons.
Pour avoir tout ce temps et en même temps gagner quelque argent pour manger (parce qu’on aime beaucoup ça, je vous le rappelle), nous fournissons divers services à des clients utilisateurs un peu partout dans le monde. Certaines fonctionnalités sont ainsi payées par des entreprises qui ont des besoins spécifiques et sont ensuite ravies d’avoir une belle version toute neuve qui répond parfaitement à leurs besoins. D’autres nous contactent pour avoir de l’aide à la création de documents, nous nous occupons alors de créer du HTML et du CSS aux petits oignons (miam) en accord avec leurs maquettes et leur charte graphique. Nous avons enfin un système de sponsoring et de dons qui ouvre droit à afficher un beau logo sur notre site et à avoir un support prioritaire par mail pour les questions techniques.
Et pour l’instant, ça marche.
Le futur
Même si CourtBouillon est jeune, nous arrivons actuellement à vivre en passant la grande majorité de notre temps de travail sur le libre.
Bien sûr, c’est une situation extrêmement grisante et souvent très épanouissante : qui n’a jamais rêvé de vivre du libre dans ce bon vieux repaire de libristes extrémistes qu’est LinuxFR 😍️ ? Nous avons travaillé notre communication pour toucher des personnes qui partagent nos valeurs, ce qui nous a amenés à rencontrer des gens absolument formidables. Nous avons pu croiser la route de clients disséminés un peu partout dans le monde, nous ouvrir à des problématiques que nous ne connaissions pas et apporter notre aide à des personnes pour lesquelles nous avons beaucoup d’estime et de sympathie…
Il y a bien sûr des contreparties à tout ce bonheur. Au niveau financier, si l’activité actuelle nous permet de nous rémunérer (et c’est déjà appréciable au bout de deux ans), nous sommes loin des standards auxquels nous pourrions postuler en tant qu’ingénieurs en informatique. Nos sponsors et nos clients nous apportent aujourd’hui la majorité de nos revenus, nous sommes donc évidemment soumis aux aléas de la demande avec une alternance de semaines chargées lorsque nous avons beaucoup de clients et des semaines plus creuses où nous pouvons nous atteler au travail invisible. Nous essayons donc au maximum de développer les dons et les sponsors récurrents pour assurer autant que possible la stabilité de notre modèle.
Au niveau des fonctionnalités qui arrivent (parce que c’est ça qui intéresse les gens, hein !), nous avons ouvert un sondage pour mieux connaître les besoins attendus. Celui de l’an dernier nous avait éclairés sur les points à traiter en priorité, nous avons donc pu mettre notre énergie au service des attentes les plus grandes… et bien sûr des clients qui ont gracieusement financé certains de ces développements ! Plusieurs fonctionnalités toutes fraîches sont déjà bien avancées : nous proposerons par exemple dans les prochains mois la possibilité de générer des fichiers PDF plus accessibles (avec le support partiel de PDF/UA) et le support des polices variables.
Et un jour, peut-être, nous pourrons enfin nous lancer à corps perdu dans le support de CSS Grid… si le temps nous le permet 😀️.
En attendant la suite
En attendant la suite des aventures, n’hésitez pas à nous suivre, à jeter un coup d’œil à WeasyPrint si vous ne l’avez jamais essayé, à ouvrir des tickets pour râler si vous rencontrez des problèmes, à nous soutenir si vous aimez ce que l’on fait, et à nous solliciter si vous avez des envies particulières.
Pour celles et ceux qui sont moins intéressés par le côté technique, nous sommes également ouverts pour discuter de gestion de projets libres, du lien à la communauté, de modèles économiques, et de tout ce qui pourrait vous intéresser sur le sujet !
Aller plus loin
- Le site de WeasyPrint (906 clics)
- Le site de CourtBouillon (395 clics)
- Le dépôt de WeasyPrint (220 clics)
- Le sondage en cours (206 clics)
# Super !
Posté par François GUÉRIN (Mastodon) . Évalué à 7.
Salut,
J'utilise WeasyPrint au quotidien pour générer des PDF divers et variés (carte pro, rapports, documents divers…) et c'est un super outil, qui s'intègre bien dans l'écosystème django !
J'avais remarqué le changement de domaine de la doc et la nouvelle charte graphique des documentations… elle est très chouette d'ailleurs ! (je veux bien la piquer pour les docs techniques)
Merci pour tout le travaille que vous faîtes, on devrai se croiser d'ici quelques mois !
Courage !
[^] # Re: Super !
Posté par flan (site web personnel) . Évalué à 5.
Je m'étais servi de WeasyPrint, mais malheureusement pour pas mal de cas l'absence de notes de bas de page a été rédhibitoire et j'avais dû générer du LaTeX.
C'est bien dommage, WeasyPrint été mieux sur tous les autres points et avec cette version actuelle, ça aurait parfaitement fait le boulot.
En tout cas, sacré travail !
[^] # Re: Super !
Posté par liZe . Évalué à 6.
Oui, il a fallu beaucoup de temps avant d’avoir les notes de bas de page, mais elles sont enfin disponibles. Nous avons développé la fonctionnalité pour un de nos clients, grâce à eux tout le monde peut en profiter maintenant !
[^] # Re: Super !
Posté par liZe . Évalué à 2. Dernière modification le 23 septembre 2022 à 10:50.
Content de voir que WeasyPrint est utile 😊️.
Pour la documentation, nous avons appris pas mal de choses en lisant cet article qui donne de bonnes idées concernant la structuration globale.
Au plaisir de se croiser d’ici quelques mois !
# Un faute ou bien une spécification que je ne connaissais pas ?
Posté par tisaac (Mastodon) . Évalué à 3.
Il n'y aurait pas un nous de trop dans cette partie de phrase ?
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Un faute ou bien une spécification que je ne connaissais pas ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
ip route delete nous
faut pas croiser la route, c'est mal. Corrigé, merci.# Sauter le pas
Posté par wapiti . Évalué à 5.
Merci pour cet article.
Une question : à quel moment vous-êtes vous dit « c’est bon, on démissionne et on se met à temps plein sur ce projet ». Vous aviez réussi à anticiper que vous aurez suffisamment de revenus pour vivre ?
[^] # Re: Sauter le pas
Posté par liZe . Évalué à 10.
On ne s’est pas lancés en pensant que ce serait économiquement viable à court terme, on avait plutôt prévu de travailler avec des clients plus près de chez nous. Mais le Covid est passé par là, et on a dû changer un peu les plans parce qu’on ne pouvait plus participer aux salons et aux événements locaux sur lesquels nous comptions. On a profité des confinements pour travailler notre communication sur internet et on a eu nos premiers clients assez rapidement.
Et finalement, ce qui devait être une activité secondaire à développer à long terme est devenu une activité principale au bout d’un an 😁️. C’était possible parce que WeasyPrint avait déjà près de 10 ans d’existence et une bonne base d’utilisateurs qui n’attendaient qu’une offre de services claire et visible pour se transformer en clients.
# La suite
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Bravo. Très beau projet. J'ai hâte de lire la prochaine dépêche avec les exemples de premières thèses mises en page par WeasyPrint. À vous lire on a l'impression que ce n'est pas bien loin ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: La suite
Posté par liZe . Évalué à 8.
Merci ! Je ne sais pas si des thèses ont déjà été réalisées avec WeasyPrint, mais on a eu la joie d’apprendre que le projet était bien utilisé dans la recherche, en particulier par OpenEdition.
# Ça a l'air chouette
Posté par Faelian . Évalué à 4.
Super intéressant comme projet.
J'écris des rapports d'audit de sécurité. En général je rédige en Markdown et j'utilise pandoc + latex (https://github.com/enhuiz/eisvogel).
Mais ça fait longtemps que je me disais que ce serait plus simple à modifier d'avoir quelque chose qui fasse Markdown -> HTML -> PDF, et un style en CSS.
Hâte de tester ça !
[^] # Re: Ça a l'air chouette
Posté par liZe . Évalué à 6.
Bonne nouvelle : Pandoc supporte déjà WeasyPrint comme moteur de rendu des PDFs !
[^] # Re: Ça a l'air chouette
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
J'utilise encore LaTeX pour beaucoup de choses (mini livres, lettres, cv, etc.) mais de plus en plus (essentiellement ces deux dernières années) Markdown pour des rapports de sécurité aussi (audit, suivi de reco, etc.) et des comptes-rendu simples. C'est vrai que les sorties PDF des solutions que j'ai pu tester sont limités et surtout rigides (car j'aime bien pouvoir reprendre, en grande partie, la charte graphique et typographique du client pour lequel je rédige.) Puis j'ai découvert MarkText qui permet d'avoir des thèmes d'impression… et donc de la souplesse sur le PDF généré en utilisant du CSS : royal pour moi (plus besoin de passer par l'export HTML pour ajouter manuellement une feuille de style puis imprimer la page dans un fichier PDF.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Badges?
Posté par Benjamin Henrion (site web personnel) . Évalué à 1.
J'avais reutilisé un exemple fait par Pinky pour faire des badges d'une HackerSpaceFestival:
http://hsf.wikidot.com/badges
https://pypi.org/project/trml2pdf/
Avez-vous un exemple similaire?
[^] # Re: Badges?
Posté par liZe . Évalué à 1.
Il y a des exemples de documents sur le site de WeasyPrint, dont un ticket qui pourrait être utile comme source d’inspiration pour des badges.
# Merci !
Posté par Slaan . Évalué à 3. Dernière modification le 23 septembre 2022 à 17:42.
Merci beaucoup beaucoup !
D'une part pour votre lib que l'on utilise par chez nous pour générer des billets et des reçu d'adhésion :)
Mais surtout grand merci aussi pour ce fabuleux encouragement et l'exemple que vous donnez.
Chez https://tibillet.co/ , on espère beaucoup aussi vivre du logiciel libre bientôt :)
[^] # Re: Merci !
Posté par liZe . Évalué à 3.
Très content de voir que c’est utile pour vous 😁️, bonne chance dans votre quête de vivre du libre !
# Superbe aventure
Posté par xandercagexxx . Évalué à 3.
Félicitations pour votre réussite.
C'est intéressant le retour sur la participation via les dons. C'est quelque chose qui manque globalement pour aider les projets.
Faire des issues ou autre c'est bien (mais encore faut il avoir des choses à remonter 😇 ), mais l'idée de pouvoir rémunérer (même très très peu) les dev des différents projets que l'on utilise/ intègre dans un projet plus gros, je trouve cela intéressant.
Bonne continuation.
[^] # Re: Superbe aventure
Posté par liZe . Évalué à 4.
Merci !
Lorsque l’on commence à avoir un certain nombre d’utilisateurs, les petites rémunérations commencent à apporter des sommes non négligeables. Prises séparément, chacune des sources de revenus (dons, développement, services…) est trop modeste pour se rémunérer, mais mises ensemble elles nous permettent d’atteindre un niveau suffisant. C’est pour cela que les dons, mêmes minimes, peuvent vraiment aider.
On espère donner des idées à d’autres qui auraient envie de se lancer !
# Merci
Posté par yanal . Évalué à 5.
Je trouve l'idée d'écrire de l'HTML pour générer des PDFs simplement géniale. L'HTML est une compétence relativement facile à acquérir et assez commune. Le support des fonctionnalités du CSS spécifiques à l’impression est la deuxième force de WeasyPrint selon moi.
Les solutions propriétaires que j'ai vues et qui permettent de générer des PDFs sont trop chers pour mes moyens et avec un niveau de fonctionnalités insuffisantes pour mes besoins.
Je vous souhaite de continuer à vous épanouir avec WeasyPrint et que ce soit plus intéressant financièrement pour vous. Je vous remercie pour WeasyPrint et j'espère que vous arriverez à continuer à le faire vivre sur le long terme.
Je pense que le monde des développeurs a besoin d'une solution libre complète pour générer des PDFs à partir d'HTML !
A tous les utilisateurs de WeasyPrint : si vous ne contribuez pas au code, contribuez financièrement (même modestement) !
[^] # Re: Merci
Posté par liZe . Évalué à 3.
Merci beaucoup pour le soutien 💜️.
(Et pour l’idée de faire des documents pour l’impression, merci aux créateurs de CSS, les propriétés de base sont déjà dans CSS 2 il y a plus de 15 ans.)
# Par rapport à PrinceXML ?
Posté par Amaury Bouchard (site web personnel) . Évalué à 2.
Merci pour ce témoignage intéressant.
De manière générale, les outils "HTML to PDF" sous licence libre sont assez limités (librairies comme TCPDF, etc.), ou pénibles à installer et gourmands en mémoire (basés sur Chrome headless). Pour cette raison, mon entreprise utilise PrinceXML (via DocRaptor, qui fournit Prince en SaaS), qui est un logiciel propriétaire offrant beaucoup de fonctionnalités.
Comment vous situez-vous par rapport à Prince ?
[^] # Re: Par rapport à PrinceXML ?
Posté par liZe . Évalué à 9.
C’est toujours dur de comparer des logiciels, mais je vais essayer quand même :).
Tout d’abord, il y a une grande différence entre WeasyPrint et d’autres logiciels basés sur Chrome : WeasyPrint a son propre moteur de rendu véritablement dédié à la pagination. L’avantage, c’est que les fonctionnalités pour le contenu paginé (comme les marges de pages, la gestion des en-têtes et pieds de pages, les règles de coupures de pages, les notes de bas de page…) sont généralement bien mieux supportées. Le désavantage, c’est que certaines fonctionnalités de Chrome (dont JavaScript, CSS grid…) ne sont pas supportées.
En ce sens, WeasyPrint est assez proche de Prince, qui a également son propre moteur.
Concernant le support des fonctionnalités de CSS, WeasyPrint n’a pas à rougir par rapport à la concurrence, même si Prince a une petite longueur d’avance à mon avis. Il n’y a pas de liste exhaustive, mais ce comparateur peut donner une bonne idée, même si tout n’est pas à jour (WeasyPrint supporte depuis peu PDF/A et PDF/UA par exemple, et quelques bugs ont déjà été corrigés).
Un point sur lequel WeasyPrint ne pourra sans doute pas rivaliser avec Prince avant un moment est la vitesse de rendu. La différence vient des choix techniques et philosophiques derrière WeasyPrint, et malgré des améliorations constantes il est dur de rivaliser.
Bref : le mieux est de tester et de comparer !
[^] # Re: Par rapport à PrinceXML ?
Posté par ff9097 . Évalué à 2.
Sur quoi te base tu pour dire que Prince serait nettement plus rapide ?
[^] # Re: Par rapport à PrinceXML ?
Posté par liZe . Évalué à 2.
Il suffit de lancer WeasyPrint et Prince sur le même document pour voir que la différence est assez flagrante…
[^] # Re: Par rapport à PrinceXML ?
Posté par ff9097 . Évalué à 2.
Et python serait la seule cause ?
[^] # Re: Par rapport à PrinceXML ?
Posté par liZe . Évalué à 4.
Non, Python n’est pas la seule cause, même si ça joue. On explique un peu cela dans la doc : dans les grandes lignes, on favorise très souvent la simplicité du code à son efficacité, histoire de garder un code maintenable et accessible.
Le même code « simple » écrit dans un autre langage plus bas niveau serait sans doute plus rapide, mais aussi plus verbeux et plus complexe.
# Header/Footer
Posté par Strash . Évalué à 3.
J'avais regardé Weasyprint il y a quelques années pour une application pro mais je m'étais confronté à l'impossibilité de générer un rapport avec un Header complexe (contenant un tableau). Il me semble me rappeler qu'à l'époque le standard HTML n'étais pas au point à ce sujet.
Cela a-t-il évolué ? Sûrement vu le travail accompli. Je vais me plonger dans la doc et faire quelques tests.
[^] # Re: Header/Footer
Posté par liZe . Évalué à 6.
Oui, on peut désormais utiliser
running
pour mettre des éléments complexes dans les marges. Tous les cas ne peuvent pas être gérés avec cela (en particulier parce que la taille des marges de pages est fixe en CSS), mais c’est très utile dans beaucoup de situations.# Merci pour le témoignage
Posté par Andréas Livet . Évalué à 2.
Merci, c'est toujours très enrichissant d'avoir des retours d'aventure humaine et économique autour du logiciel libre.
J'avoue que j'aimerai aussi pouvoir un jour vivre d'un projet libre auquel je participe, pour l'instant c'est pas du tout le cas :D.
Bonne continuation !
[^] # Re: Merci pour le témoignage
Posté par liZe . Évalué à 2.
Il faut souvent du temps (et de la chance), mais essayer est le meilleur moyen d’y arriver 😁️.
Plein de bonnes choses pour la suite !
[^] # Re: Merci pour le témoignage
Posté par Andréas Livet . Évalué à 2.
Merci pour le commentaire, oui c'est claire qu'il faut du temps, je le vois pour d'autre activités. Souvent quand un projet communautaire prend une tournure plus sérieuse et pro (avec possibilité d'en tirer un revenu) c'est qu'il y a déjà beaucoup d'énergie de mise au départ pendant un certain temps. Et ce sans forcément attendre quelque chose en retour. Ça me fait penser à une chanson de Pagny, mais je vais m'arrêter là :p.
[^] # Re: Merci pour le témoignage
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1.
T'arrête pas, personne ici ne veut t'ôte ta liberté de penser…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# similaire à...
Posté par collinm (site web personnel) . Évalué à 2.
cela utilise pas le même langage de programmation, mais ça me semble similaire à ce que propose
Open HTML to PDF
www.solutions-norenda.com
[^] # Re: similaire à...
Posté par liZe . Évalué à 3.
Oui, il existe beaucoup de projets qui ont la même finalité.
print-css.rocks
offre un bon état des principales solutions existantes, propriétaires ou libres, pour celles et ceux que ça intéresse.# Bravo, fpdf2 & liste d'usages de WeasyPrint
Posté par Lucas-C (site web personnel) . Évalué à 4. Dernière modification le 04 octobre 2022 à 14:37.
Merci pour ce journal et un grand bravo pour avoir conçu WeasyPrint et pour le maintenir !
Je consacre un peu de temps à maintenir une bibliothèque Python pour générer des PDFs, bien plus modeste : https://github.com/PyFPDF/fpdf2/
Même si les usages diffèrent un peu, WeasyPrint me semble clairement plus complet et professionnel ! Nous le recommandons même dans notre documentation :
- https://pyfpdf.github.io/fpdf2/index.html#related
- https://pyfpdf.github.io/fpdf2/HTML.html
Par curiosité, avez-vous une liste publique de projets / ebooks employant WeayPrint ?
J'avoue être curieux quant aux JdRs conçus avec WeasyPrint ^
J'ai trouvé Hakai Kousen mais il y en a peut-être d'autres ?
[^] # Re: Bravo, fpdf2 & liste d'usages de WeasyPrint
Posté par liZe . Évalué à 4.
C’est gentil de parler de nous dans la doc ! En effet, les cas d’usage sont sans doute différents pour WeasyPrint et fpdf2, c’est toujours sympa d’avoir différents outils vraiment adaptés aux besoins. Longue vie à fpdf2 !
On n’a pas de liste publique de projets utilisant WeasyPrint, mais il est assez facile d’en trouver quelques uns sur GitHub dont certains venant de dépôts plutôt sympas comme le gouvernement anglais, MetLife, la ville d’Amsterdam, l’observatoire de Las Cumbres… En privé, d’autres structures plus ou moins prestigieuses nous ont dit qu’elles utilisaient WeasyPrint, mais on n’a pas encore pris le temps de recueillir le consentement de tout le monde pour faire une liste officielle.
Concernant les jeux de rôle, certains ont parlé de nous, comme @PaulStefko ou @Epidiah. On avait aussi eu un ticket ouvert pour un générateur de documents (qui n’existe plus a priori). Il y en a sans doute d’autres (on n’avait pas vu Hakai Kousen), mais on n’est pas du tout connaisseurs du milieu 😁️.
[^] # Re: Bravo, fpdf2 & liste d'usages de WeasyPrint
Posté par Lucas-C (site web personnel) . Évalué à 3.
Merci pour cette réponse détaillé et le soutien sur fpdf2 😊
Ah oui j'ai retrouvés les tweets de ces deux auteurs de JdR :
- https://nitter.lacontrevoie.fr/PaulStefko/search?q=weasyprint
- https://nitter.lacontrevoie.fr/Epidiah/status/1375177944096763909#m
Le générateur de documents de JdR me semblait assez similaire à https://homebrewery.naturalcrit.com dans l'idée.
Je compte bien tester WeasyPrint pour mes protos ( https://github.com/Lucas-C/jdr#comment-%C3%A7a-marche- ), pour l'instant j'emploie NodeJS & markdown-it pour la conversion Markdown -> HTML, et Puppeteer pour la conversion en PDF, mais niveau accessibilité c'est pas top.
Bonne continuation à WeasyPrint, et chapeau à vous pour avoir monté une structure coopérative autour du projet, c'est super inspirant pour la communauté !
# Par rapport à Docmosis
Posté par Nonolapéro . Évalué à 3.
Dans ma boîte, il a été choisi Docmosis (on a une appli Java), c’est quoi les différences entre les deux produits ?
[^] # Re: Par rapport à Docmosis
Posté par liZe . Évalué à 3.
Docmosis a l’air d’être basé sur des modèles faits avec Word ou LibreOffice, alors que WeasyPrint utilise du HTML/CSS.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.