liZe a écrit 72 commentaires

Docmosis a l’air d’être basé sur des modèles faits avec Word ou LibreOffice, alors que WeasyPrint utilise du HTML/CSS.

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 😁️.

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.

Il suffit de lancer WeasyPrint et Prince sur le même document pour voir que la différence est assez flagrante…

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.

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 !

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.

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 !

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 !

Très content de voir que c’est utile pour vous 😁️, bonne chance dans votre quête de vivre du libre !

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.)

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.

Bonne nouvelle : Pandoc supporte déjà WeasyPrint comme moteur de rendu des PDFs !

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.

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.

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 !

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 !

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.

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.

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é…

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.

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 ?

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 !

N'hésitez pas à nous faire signe si vous rencontrez des problèmes !

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

C'est par exemple ce que fait Pandoc en utilisant plein d'outils dont WeasyPrint.

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

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 :).

ç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.

:D

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.

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

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).

Merci !