jsPDF est excellent pour les exports légers dans le navigateur
jsPDF est populaire parce qu’il résout un vrai problème produit : créer un PDF dans le navigateur sans exploiter de service serveur. Un développeur peut dessiner du texte, des lignes, des images et des tableaux simples, puis déclencher le téléchargement depuis la même page. Pour des prototypes, petits écrans d’administration, reçus locaux et PWA hors ligne, c’est un bon choix.
La question produit est de savoir où cette frontière navigateur cesse d’être la bonne. Une fois que le PDF devient un document métier que des clients scannent, conservent, envoient par e-mail ou soumettent à un autre système, le travail n’est plus seulement “dessiner un fichier”. Il devient gestion des polices, précision des codes-barres, stabilité mobile, sortie déterministe et parfois PDF/A ou empaquetage de facture électronique.
Même sortie PDF, périmètre produit différent
Avec jsPDF, votre application web dans le navigateur est le générateur. Chaque onglet doit contenir la bibliothèque, les polices personnalisées éventuelles, les images intermédiaires, la sortie des codes-barres et les octets PDF finaux. La facture de bibliothèque reste à zéro, mais la responsabilité de production passe à chaque appareil utilisateur.
Avec gPdf, le navigateur ou le serveur envoie une requête structurée DocumentRequest ou template_id + data. gPdf possède l’environnement de génération, les polices intégrées, la géométrie des codes-barres et la génération binaire du PDF à l’edge. L’application reste responsable des données et de la logique de modèle, pas du moteur PDF.
Cas d’usage produit : export hors ligne vs documents opérationnels
Choisissez jsPDF quand le PDF est une commodité locale : un petit bouton d’export, un reçu simple en alphabet latin, une capture de tableau de bord ou une PWA qui doit continuer sans réseau.
Choisissez gPdf quand le PDF fait partie d’un parcours opérationnel : étiquettes d’expédition, étiquettes d’entrepôt, factures, tickets, relevés, formulaires douaniers et reçus transfrontaliers. Ces documents ont besoin de la même sortie sur tous les appareils, pas de ce que l’onglet courant peut assembler sans risque.
Modèle de coût : bibliothèque gratuite vs surface de production assumée
La bibliothèque jsPDF a l’avantage de prix évident : elle est open source, et le CPU du navigateur n’apparaît pas comme ligne dans votre facture cloud. Pour une petite fonction interne, cela peut être le chemin le moins cher.
Le coût de production apparaît autour de la bibliothèque :
- Fichiers de polices compatibles CJK ou modules de polices base64 générés.
- Bibliothèques d’encodage et de conversion de codes-barres.
- Bugs mémoire et téléchargement propres à chaque navigateur.
- QA d’impression pour scanners et imprimantes thermiques.
- Tests de régression sur desktop, iOS Safari, Android WebView et navigateurs embarqués.
gPdf transforme cela en facture d’usage. Le plan public Basic démarre à 5 USD/mois pour 100 000 pages, avec dépassement standard à partir de 0,00005 USD par page. C’est un coût fournisseur, mais il évite de traiter chaque bundle web et chaque appareil utilisateur comme un service PDF de production.
Le coût CJK n’est pas seulement la taille du fichier
La première limite dure est le texte CJK : chinois, japonais et coréen.
Les polices PDF standard intégrées à jsPDF sont utiles pour des sorties simples en alphabet latin, mais elles ne couvrent pas tous les glyphes Unicode. Si le document contient du texte CJK, l’application doit disposer d’une police qui contient réellement ces glyphes. En pratique, dans le navigateur, cela implique souvent d’empaqueter un fichier TTF, de le convertir en module JavaScript base64 ou de charger des données de police avant de générer le PDF.
Ce coût se paie deux fois : d’abord comme charge de bundle plus lourde, puis comme mémoire dans le navigateur pendant la génération PDF. Sur mobile, le même onglet peut contenir en même temps l’app web, la police, les tampons de codes-barres, les images et les octets PDF finaux.
gPdf garde ce travail côté serveur. Le navigateur envoie du JSON structuré ; le générateur choisit parmi des polices intégrées couvrant latin, grec, cyrillique, CJK, arabe, devanagari, bengali, thaï et texte à chasse fixe. Une charge de commande de 2 Ko n’a pas besoin de devenir un chemin de livraison de police de 12 Mo.
Coût des codes-barres : encoder est simple, imprimer de façon fiable l’est moins
En logistique, e-commerce, fabrication, santé, billetterie et commerce de détail, le code-barres peut être plus important que le texte visible. Une personne lit le numéro de commande ; l’opération lit Code 128, GS1-128, QR, DataMatrix ou PDF417.
Avec jsPDF, la génération du code-barres est généralement une décision produit séparée. Les équipes combinent jsPDF avec un autre encodeur, génèrent le code en SVG, Canvas ou image, puis placent ce résultat dans le PDF. Pour un QR de coupon ou une preuve de concept, cela fonctionne.
Cela devient fragile quand le code-barres imprimé est critique pour l’opération :
- Un code-barres en Canvas peut être rastérisé à la mauvaise résolution.
- Une image redimensionnée peut flouter les barres, modules ou zones silencieuses.
- Un navigateur, une transformation CSS ou un chemin d’export peut changer la taille physique finale.
- Des formats de codes-barres différents peuvent exiger des bibliothèques ou conversions différentes.
- Les imprimantes thermiques à 203 DPI exposent vite les petites erreurs de taille.
gPdf traite les codes-barres comme des éléments de document. La requête déclare type: "barcode", le format, le contenu et la taille physique en millimètres. Le générateur écrit la géométrie vectorielle des codes-barres directement dans le PDF pour les formats 1D et 2D pris en charge, afin que texte, formes, tableaux, images et codes-barres restent dans le même système de coordonnées.
Studio et itération de modèles
jsPDF est orienté code. Un changement de mise en page signifie généralement modifier commandes de dessin, positions, enregistrement de polices, conversion d’images et placement des codes-barres en JavaScript.
gPdf conserve une approche centrée API, mais ajoute gPdf Studio comme concepteur visuel gratuit de mise en page PDF. Les équipes peuvent ajouter et déplacer texte, images, tableaux, formes, en-têtes, pieds de page et codes-barres, puis connecter la conception à la génération template_id + data. Cela compte quand un format d’étiquette, de facture ou de reçu change souvent et que des personnes non spécialistes PDF doivent participer à la mise en page.
Les navigateurs mobiles ne sont pas le bon endroit pour un gros travail PDF
La génération PDF côté client semble bon marché parce que la facture serveur est nulle. Le coût se déplace vers l’appareil utilisateur.
Sur ordinateur de bureau, cela peut être acceptable. Sur navigateurs mobiles, un document de production peut mettre l’onglet sous forte pression : données de police CJK, images Base64, tampons Canvas, images de codes-barres, octets PDF générés et application en cours se disputent la mémoire. iOS Safari et les appareils Android avec peu de mémoire sont moins généreux que l’ordinateur portable d’un développeur.
Déplacer la génération vers gPdf change la forme du problème. Le navigateur construit une petite requête JSON, attend une réponse binaire et télécharge le PDF fini. L’onglet utilisateur n’a plus à être gestionnaire de polices, générateur de codes-barres, moteur de mise en page et générateur binaire PDF à la fois.
Quand jsPDF reste le bon choix
Il y a de bonnes raisons de rester avec jsPDF.
Si l’utilisateur doit exporter hors ligne, jsPDF est le meilleur choix. Si les données ne peuvent absolument pas quitter l’appareil, la génération dans le navigateur est la frontière de confidentialité la plus claire. Si le document est petit, uniquement en alphabet latin et utilisé occasionnellement, la complexité opérationnelle d’une API ne vaut peut-être pas le coût. Pour prototypes et outils internes, jsPDF est souvent le chemin le plus rapide.
La décision change quand la sortie fait partie d’un parcours opérationnel : étiquette d’expédition qui doit scanner, facture qui doit être archivée, ticket qui doit être vérifié ou document transfrontalier qui doit afficher correctement des noms CJK. À ce moment-là, “générer un PDF dans le navigateur” compte moins que “générer le même PDF de production de façon fiable”.
Forme de migration
La migration n’est pas “remplacer un appel de fonction”. C’est passer du dessin impératif dans le navigateur à une requête documentaire structurée.
- // Before: browser-side drawing with jsPDF plus extra font/barcode setup.
- import { jsPDF } from "jspdf";
- import JsBarcode from "jsbarcode";
-
- const doc = new jsPDF({ unit: "mm", format: [100, 150] });
- // Load a CJK-capable TTF and register it before drawing CJK text.
- doc.addFileToVFS("NotoSansCJK-Regular.ttf", base64Font);
- doc.addFont("NotoSansCJK-Regular.ttf", "NotoSansCJK", "normal");
- doc.setFont("NotoSansCJK");
- doc.text("跨境订单 / Cross-border order", 6, 10);
-
- // Generate a barcode separately, then place it into the PDF.
- JsBarcode(canvas, "PDN0003507278", { format: "CODE128" });
- doc.addImage(canvas.toDataURL("image/png"), "PNG", 6, 72, 72, 20);
- doc.save("label.pdf");
+
+ // After: send one structured DocumentRequest to gPdf.
+ const res = await fetch("https://api.gpdf.com/api/v1/pdf/render", {
+ method: "POST",
+ headers: {
+ Authorization: `Bearer ${KEY}`,
+ "Content-Type": "application/json"
+ },
+ body: JSON.stringify({
+ settings: {
+ defaults: {
+ text: {
+ font_family: "NotoSans-Regular",
+ font_mode: "prefer",
+ font_size: 9,
+ color: "#111827"
+ }
+ }
+ },
+ pages: [{
+ width: 100,
+ height: 150,
+ elements: [
+ {
+ type: "text",
+ x: 6,
+ y: 8,
+ content: "跨境订单 / Cross-border order",
+ style: { width: 88, font_size: 12, font_weight: "bold" }
+ },
+ {
+ type: "barcode",
+ x: 6,
+ y: 70,
+ width: 72,
+ height: 18,
+ format: "code128",
+ content: "PDN0003507278",
+ barcode_text: { enabled: true, position: "bottom", offset: 1 }
+ },
+ {
+ type: "barcode",
+ x: 80,
+ y: 8,
+ width: 14,
+ height: 14,
+ format: "qrcode",
+ content: "https://track.example/PDN0003507278",
+ barcode_text: { enabled: false, position: "bottom" }
+ }
+ ]
+ }]
+ })
+ });
+ const pdf = await res.arrayBuffer();
Le changement important est la responsabilité. Avec jsPDF, votre application web possède le chemin des polices CJK, la génération des codes-barres, le profil mémoire du navigateur et le comportement d’export. Avec gPdf, votre application possède les données et le modèle ; le générateur à l’edge possède la mécanique documentaire.
Scénarios liés de génération PDF
Les équipes qui comparent jsPDF et gPdf commencent souvent par décider si la génération PDF doit rester dans le navigateur ou passer à une API contrôlée. Pour les documents structurés, les pages naturelles sont API JSON-to-PDF, API de PDF de facture, API d’étiquettes d’expédition, API de codes-barres GS1 et API de modèles PDF. Si la conservation longue durée ou la facture électronique comptent, lisez aussi API PDF/A et API Factur-X.
FAQ
jsPDF est-il gratuit ?
La bibliothèque elle-même est open source. Le coût de production se trouve autour : polices CJK, bibliothèques de codes-barres, QA navigateur, QA d’impression et prise en charge des appareils qui manquent de mémoire.
gPdf remplace-t-il tous les cas jsPDF ?
Non. L’export hors ligne depuis le navigateur et les documents purement locaux restent le territoire naturel de jsPDF. gPdf est pensé pour les documents de production où un générateur contrôlé justifie l’appel API.
Pourquoi parler du coût des codes-barres séparément ?
Parce qu’un code-barres peut sembler correct à l’écran et échouer après redimensionnement, rastérisation ou impression thermique. Les documents opérationnels exigent une fiabilité scanner, pas seulement un motif visible.
Voir aussi
- Référence API gPdf - DocumentRequest, éléments de codes-barres, secours de polices et points de terminaison de génération.
- Codes-barres vectoriels ou raster dans les PDF : le chargeback que vous ne voyez pas venir - pourquoi la géométrie compte après impression.
- Codes-barres GS1-128 à 0,1 mm de précision en JSON : guide pratique - détails de dimensionnement orientés étiquettes.
- PDF/A et Factur-X expliqués aux ingénieurs (sans le jargon juridique) - quand archivage et facture électronique entrent dans le parcours PDF.