jsPDF sobresale en exportaciones ligeras desde el navegador
jsPDF es popular porque resuelve un problema real de producto: crear un PDF dentro del navegador sin operar un servicio del servidor. Un desarrollador puede dibujar texto, líneas, imágenes y tablas simples, y disparar la descarga desde la misma página. Para prototipos, pantallas de administración pequeñas, recibos locales y PWA sin conexión, encaja bien.
La pregunta de producto es dónde deja de ser correcta esa frontera del navegador. Cuando el PDF pasa a ser un documento empresarial que los clientes escanean, archivan, envían por correo o suben a otro sistema, el trabajo ya no es solo “dibujar un archivo”. Pasa a ser gestión de fuentes, precisión de códigos de barras, estabilidad móvil, salida determinista y, a veces, PDF/A o paquete de factura electrónica.
Mismo PDF, frontera de producto distinta
Con jsPDF, su aplicación de navegador es el generador. Cada pestaña del navegador debe mantener la biblioteca, cualquier fuente personalizada, imágenes intermedias, salida de códigos de barras y los bytes finales del PDF. La factura de la biblioteca queda en cero, pero la responsabilidad de producción pasa a cada dispositivo de usuario.
Con gPdf, el navegador o el servidor envía una solicitud estructurada DocumentRequest o template_id + data. gPdf se encarga del entorno de generación, las fuentes integradas, la geometría de códigos de barras y la generación binaria del PDF en el edge. La aplicación conserva la responsabilidad de datos y lógica de plantilla, no del motor PDF.
Encaje de producto: exportación sin conexión vs documentos operativos
Elija jsPDF cuando el PDF sea una comodidad local: un pequeño botón de exportación, un recibo sencillo solo con texto latino, una captura de un panel o una PWA que debe seguir funcionando sin conexión.
Elija gPdf cuando el PDF forme parte de un flujo operativo: etiquetas de envío, etiquetas de almacén, facturas, tickets, extractos, formularios aduaneros y recibos transfronterizos. Esos documentos necesitan la misma salida en todos los dispositivos, no lo que la pestaña actual pueda ensamblar con seguridad.
Modelo de coste: biblioteca gratuita vs superficie de producción asumida
La biblioteca jsPDF tiene la ventaja obvia de precio: es de código abierto, y la CPU del navegador no aparece como partida en su factura de nube. Para una función interna pequeña, puede ser el camino más barato.
El coste de producción aparece alrededor de la biblioteca:
- Archivos de fuentes compatibles con CJK o módulos base64 generados.
- Bibliotecas de codificación y conversión de códigos de barras.
- Errores de memoria y descarga específicos de cada navegador.
- Control de calidad de impresión para escáneres e impresoras térmicas.
- Pruebas de regresión en escritorio, iOS Safari, Android WebView y navegadores embebidos.
gPdf convierte eso en una factura de uso. El plan público Basic empieza en 5 USD/mes por 100.000 páginas; el uso adicional estándar empieza en 0,00005 USD por página. Es un coste de proveedor, pero elimina la necesidad de tratar cada paquete de interfaz web y cada dispositivo de usuario como si fuera un servicio PDF de producción.
El coste CJK no es solo tamaño de archivo
El primer límite duro es el texto CJK: chino, japonés y coreano.
Las fuentes PDF estándar integradas en jsPDF sirven para salidas simples con texto latino, pero no cubren todos los glifos Unicode. Si el documento contiene CJK, la aplicación necesita una fuente que realmente incluya esos glifos. En implementaciones de navegador, esto suele implicar empaquetar un archivo TTF, convertirlo en un módulo JavaScript base64 o cargar datos de fuente antes de generar el PDF.
Ese coste se paga dos veces: primero como mayor peso del paquete web, y después como memoria de navegador durante la generación PDF. En móvil, la misma pestaña puede mantener a la vez la aplicación web, la fuente, búferes de códigos de barras, imágenes y los bytes finales del PDF.
gPdf mantiene ese trabajo del lado del servidor. El navegador envía JSON estructurado; el generador elige entre fuentes integradas para latín, griego, cirílico, CJK, árabe, devanagari, bengalí, tailandés y texto monoespaciado. Un pedido de 2 KB no necesita convertirse en una entrega de fuentes de 12 MB.
Coste de códigos de barras: codificar es fácil, imprimir fiable es más difícil
En logística, comercio electrónico, fabricación, salud, venta de entradas y venta minorista, el código de barras puede ser más importante que el texto visible. Una persona lee el número de pedido; la operación lee Code 128, GS1-128, QR, DataMatrix o PDF417.
Con jsPDF, la generación del código de barras suele ser una decisión de producto separada. Los equipos combinan jsPDF con otro codificador, renderizan el código a SVG, Canvas o imagen, y colocan ese resultado dentro del PDF. Para un QR de cupón o una prueba de concepto, funciona.
Se vuelve frágil cuando el código impreso es crítico para la operación:
- Un código en Canvas puede rasterizarse con resolución incorrecta.
- Una imagen escalada puede emborronar barras, módulos o zonas de silencio.
- Navegador, transformación CSS o ruta de exportación pueden cambiar el tamaño físico final.
- Distintos formatos de código pueden requerir bibliotecas o rutas de conversión distintas.
- Las impresoras térmicas de 203 DPI exponen rápido pequeños errores de tamaño.
gPdf trata los códigos de barras como elementos de documento. La solicitud declara type: "barcode", format, contenido y tamaño físico en milímetros. El generador escribe geometría vectorial de códigos de barras para formatos 1D y 2D soportados directamente dentro del PDF, de modo que texto, formas, tablas, imágenes y códigos de barras permanecen en el mismo sistema de coordenadas.
Studio e iteración de plantillas
jsPDF está orientado al código. Un cambio de diseño suele significar editar comandos de dibujo, posiciones, registro de fuentes, conversión de imágenes y ubicación de códigos de barras en JavaScript.
gPdf mantiene un flujo centrado en la API, pero añade gPdf Studio como diseñador visual gratuito del diseño PDF. Los equipos pueden añadir y arrastrar texto, imágenes, tablas, formas, encabezados, pies de página y códigos de barras, y después conectar el diseño a generación con template_id + data. Eso importa cuando cambian a menudo formatos de etiqueta, factura o recibo, y personas que no son especialistas en PDF necesitan participar en el diseño.
Los navegadores móviles no son buen lugar para trabajo PDF pesado
La generación PDF en cliente parece barata porque la factura de servidor es cero. El coste se mueve al dispositivo del usuario.
En escritorio, eso puede ser aceptable. En navegadores móviles, un documento de producción puede presionar fuerte la pestaña: datos de fuentes CJK, imágenes base64, búferes de Canvas, imágenes de códigos de barras, bytes PDF generados y la aplicación en ejecución compiten por memoria al mismo tiempo. iOS Safari y Android con poca memoria son menos generosos que el portátil de un desarrollador.
Mover la generación a gPdf cambia la forma del problema. El navegador construye una pequeña solicitud JSON, espera una respuesta binaria y descarga el PDF terminado. La pestaña del usuario ya no tiene que ser gestor de fuentes, generador de códigos de barras, motor de diseño y escritor binario de PDF a la vez.
Cuándo jsPDF sigue siendo la elección correcta
Hay buenas razones para quedarse con jsPDF.
Si el usuario debe exportar sin conexión, jsPDF es mejor. Si los datos no pueden salir del dispositivo en absoluto, la generación en navegador es la frontera de privacidad más limpia. Si el documento es pequeño, solo tiene texto latino y se usa ocasionalmente, quizá no compense introducir la complejidad operativa de una API. Para prototipos y herramientas internas, jsPDF suele ser el camino más rápido.
La decisión cambia cuando la salida forma parte de un flujo operativo: una etiqueta de envío que debe escanear, una factura que debe archivarse, un ticket que debe verificarse o un documento de pedido transfronterizo que debe mostrar correctamente nombres CJK. En ese punto, “generar un PDF en el navegador” importa menos que “generar de forma fiable el mismo PDF de producción”.
Forma de migración
La migración no es “reemplazar una llamada de función”. Es pasar de dibujo imperativo en navegador a una solicitud documental estructurada.
- // 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();El cambio importante es la responsabilidad. Con jsPDF, su aplicación web asume la ruta de fuentes CJK, la generación de códigos de barras, el perfil de memoria del navegador y el comportamiento de exportación. Con gPdf, su aplicación conserva los datos y la plantilla; el generador en el edge se encarga de la mecánica documental.
Escenarios relacionados de generación PDF
Los equipos que comparan jsPDF y gPdf suelen empezar por decidir si la generación PDF debe quedarse dentro del navegador o pasar a una API controlada. Para documentos estructurados, las siguientes páginas naturales son API de JSON a PDF, API de PDF de factura, API de etiquetas de envío, API de códigos de barras GS1 y API de plantillas PDF. Si importan el archivado o la factura electrónica, lea también API PDF/A y API Factur-X.
FAQ
¿jsPDF es gratis?
La biblioteca en sí es de código abierto. El coste de producción está alrededor: fuentes CJK, bibliotecas de códigos de barras, control de calidad en navegadores, control de calidad de impresión y soporte para dispositivos que se quedan sin memoria.
¿gPdf reemplaza todos los casos de jsPDF?
No. La exportación sin conexión desde navegador y los documentos locales siguen siendo territorio natural de jsPDF. gPdf está pensado para documentos de producción donde un generador controlado justifica la llamada API.
¿Por qué mencionar el coste de códigos de barras aparte?
Porque un código de barras puede verse bien en pantalla y fallar después de escalarse, rasterizarse o imprimirse en térmica. Los documentos operativos necesitan fiabilidad de escáner, no solo un patrón visible.
Ver también
- Referencia de la API de gPdf - DocumentRequest, elementos de código de barras, sustitución de fuentes y puntos de generación.
- Códigos de barras vectoriales vs rasterizados en PDF - por qué la geometría del código importa después de imprimir.
- Códigos GS1-128 a 0,1 mm de precisión en JSON - detalles de tamaño orientados a etiquetas.
- PDF/A y Factur-X explicados para ingenieros - cuándo archivo y factura electrónica entran en el flujo PDF.