jsPDF é excelente para exportações leves no navegador
jsPDF é popular porque resolve um problema real de produto: criar um PDF dentro do navegador sem operar um serviço no servidor. Um desenvolvedor pode desenhar texto, linhas, imagens e tabelas simples, depois disparar o download na mesma página. Para protótipos, pequenas telas administrativas, recibos locais e PWAs offline, é um bom encaixe.
A pergunta de produto é onde essa fronteira do navegador deixa de ser a correta. Quando o PDF vira documento de negócio que clientes escaneiam, arquivam, enviam por e-mail ou submetem a outro sistema, o trabalho deixa de ser apenas “desenhar um arquivo”. Passa a envolver gestão de fontes, precisão de códigos de barras, estabilidade em dispositivos móveis, saída determinística e, às vezes, PDF/A ou empacotamento de fatura eletrônica.
Mesmo PDF final, fronteira de produto diferente
Com jsPDF, sua aplicação de interface é o gerador. Cada aba do navegador precisa manter a biblioteca, quaisquer fontes personalizadas, imagens intermediárias, saída de códigos de barras e bytes finais do PDF. A conta da biblioteca fica em zero, mas a responsabilidade de produção passa para cada dispositivo do usuário.
Com gPdf, o navegador ou servidor envia uma requisição estruturada DocumentRequest ou template_id + data. gPdf possui o ambiente de geração, as fontes integradas, a geometria de códigos de barras e a geração binária do PDF no edge. A aplicação continua responsável pelos dados e pela lógica de modelo, não pelo motor PDF.
Encaixe de produto: exportação offline vs documentos operacionais
Escolha jsPDF quando o PDF é uma conveniência local: um pequeno botão de exportação, um recibo simples apenas em alfabeto latino, um snapshot de painel ou uma PWA que precisa continuar funcionando sem rede.
Escolha gPdf quando o PDF faz parte de um fluxo operacional: etiquetas de envio, etiquetas de armazém, faturas, ingressos, extratos, formulários alfandegários e recibos cross-border. Esses documentos precisam da mesma saída em todos os dispositivos, não do que a aba atual do navegador consegue montar com segurança.
Modelo de custo: biblioteca grátis vs superfície produtiva própria
A biblioteca jsPDF tem a vantagem de preço óbvia: ela é open source, e CPU de navegador não aparece como linha na conta de nuvem. Para uma pequena funcionalidade interna, esse pode ser o caminho mais barato.
O custo de produção aparece no trabalho ao redor da biblioteca:
- Arquivos de fonte compatíveis com CJK ou módulos Base64 gerados.
- Bibliotecas de codificação e conversão de códigos de barras.
- Bugs de memória e download específicos de navegador.
- QA de impressão para leitores e impressoras térmicas.
- Testes de regressão em computadores, iOS Safari, Android WebView e navegadores embarcados.
gPdf transforma isso em uma conta de uso. O plano Basic público começa em 5 USD/mês para 100.000 páginas, com excedente padrão a partir de 0,00005 USD por página. É custo de fornecedor, mas remove a necessidade de fazer cada pacote de interface e cada dispositivo do usuário se comportarem como um serviço PDF de produção.
O custo CJK não é só tamanho de arquivo
A primeira fronteira dura é texto CJK: chinês, japonês e coreano.
As fontes PDF padrão integradas ao jsPDF são úteis para saída latina simples, mas não cobrem todos os glifos Unicode. Quando o documento contém texto CJK, a aplicação precisa de uma fonte que realmente contenha esses glifos. Na prática, implementações no navegador frequentemente empacotam um arquivo TTF, convertem a fonte em um módulo JavaScript Base64 ou buscam dados de fonte antes de gerar o PDF.
Esse custo é pago duas vezes: primeiro como carga maior da interface, depois como memória do navegador durante a geração. Em dispositivos móveis, a mesma aba pode manter a aplicação web, a fonte, buffers de códigos de barras, imagens e bytes finais do PDF ao mesmo tempo.
gPdf mantém esse trabalho no servidor. O navegador envia JSON estruturado; o gerador escolhe entre fontes integradas que cobrem latino, grego, cirílico, CJK, árabe, devanágari, bengali, tailandês e monoespaçado. Uma carga de pedido de 2 KB não precisa virar um caminho de entrega de fonte de 12 MB.
Custo de códigos de barras: codificar é fácil, imprimir com confiança é mais difícil
Em logística, e-commerce, manufatura, saúde, bilheteria e varejo, o código de barras pode importar mais que o texto visível. Um humano lê o número do pedido; a operação lê Code 128, GS1-128, QR, DataMatrix ou PDF417.
Com jsPDF, a geração de códigos de barras costuma ser uma decisão de produto separada. Equipes combinam jsPDF com outro codificador, geram o código em SVG, Canvas ou imagem, e então colocam esse resultado no PDF. Isso funciona para um QR de cupom ou uma prova de conceito.
Fica frágil quando o código impresso é operacionalmente crítico:
- Um código de barras em Canvas pode ser rasterizado na resolução errada.
- Uma imagem escalada pode desfocar barras, módulos ou zonas silenciosas.
- Um navegador, transformação CSS ou caminho de exportação pode mudar o tamanho físico final.
- Formatos diferentes podem exigir bibliotecas ou caminhos de conversão diferentes.
- Impressoras térmicas a 203 DPI expõem rapidamente pequenos erros de tamanho.
gPdf trata códigos de barras como elementos de documento. A requisição declara type: "barcode", format, conteúdo e tamanho físico em milímetros. O gerador emite a geometria vetorial do código de barras dentro do PDF para formatos 1D e 2D suportados, de modo que texto, formas, tabelas, imagens e códigos de barras permaneçam no mesmo sistema de coordenadas.
Studio e iteração de modelos
jsPDF é centrado em código. Uma mudança de diagramação geralmente significa editar comandos de desenho, posições, registro de fonte, conversão de imagem e posicionamento de código de barras em JavaScript.
gPdf mantém um fluxo centrado em API, mas adiciona gPdf Studio como editor visual gratuito para a diagramação do PDF. Equipes podem adicionar e arrastar textos, imagens, tabelas, formas, cabeçalhos, rodapés e códigos de barras, depois conectar a concepção à geração por template_id + data. Isso importa quando um formato de etiqueta, fatura ou recibo muda com frequência e pessoas não especialistas em PDF precisam participar da diagramação.
Navegadores móveis não são o lugar certo para PDF pesado
Geração PDF no cliente parece barata porque a conta do servidor é zero. O custo vai para o dispositivo do usuário.
Em computadores, isso pode ser aceitável. Em navegadores móveis, um documento de produção pode pressionar muito a aba: dados de fonte CJK, imagens Base64, buffers de Canvas, imagens de códigos de barras, bytes PDF gerados e a aplicação em execução competem por memória ao mesmo tempo. iOS Safari e dispositivos Android com pouca memória perdoam menos que o laptop de um desenvolvedor.
Mover a geração para gPdf muda o formato do problema. O navegador monta uma pequena requisição JSON, aguarda uma resposta binária e baixa o PDF finalizado. A aba do usuário deixa de ser gerente de fontes, gerador de códigos de barras, motor de diagramação e escritor binário de PDF.
Quando jsPDF ainda é a escolha certa
Existem bons motivos para manter jsPDF.
Se o usuário precisa exportar offline, jsPDF é o melhor encaixe. Se os dados não podem sair do dispositivo de forma alguma, a geração no navegador é a fronteira de privacidade mais limpa. Se o documento é pequeno, apenas latino e ocasional, o custo operacional de introduzir uma API pode não valer a pena. Para protótipos e ferramentas internas, jsPDF muitas vezes é exatamente o caminho mais rápido.
A decisão muda quando a saída faz parte de um fluxo operacional: uma etiqueta de envio que precisa escanear, uma fatura que precisa ser arquivada, um ingresso que precisa ser validado ou um documento cross-border que precisa renderizar nomes CJK corretamente. Nesse ponto, “gerar PDF no navegador” importa menos que “gerar o mesmo PDF de produção com confiabilidade”.
Formato da migração
A migração não é “trocar uma chamada de função”. É sair do desenho imperativo no navegador para uma requisição estruturada de documento.
- // 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();A mudança importante é propriedade. Com jsPDF, sua aplicação web possui o caminho de fontes CJK, o caminho de geração de códigos de barras, o perfil de memória do navegador e o comportamento de exportação. Com gPdf, a aplicação possui os dados e o modelo; o gerador no edge possui a mecânica do documento.
Cenários relacionados de geração de PDF
Equipes que comparam jsPDF e gPdf começam normalmente decidindo se a geração PDF deve permanecer no navegador ou passar para uma API controlada. Para documentos estruturados, as páginas naturais são API de JSON para PDF, API de PDF de fatura, API de etiquetas de envio, API de códigos de barras GS1 e API de modelos PDF. Se arquivamento ou fatura eletrônica importam, leia também API PDF/A e API Factur-X.
FAQ
jsPDF é gratuito?
A biblioteca em si é open source. O custo de produção está no trabalho ao redor: fontes CJK, bibliotecas de códigos de barras, QA de navegador, QA de impressão e compatibilidade com dispositivos com pouca memória.
gPdf substitui todos os casos de uso do jsPDF?
Não. Exportação offline no navegador e documentos estritamente locais ainda são território natural do jsPDF. gPdf é para documentos de produção em que um gerador controlado vale a chamada de API.
Por que mencionar custo de código de barras separadamente?
Porque um código de barras que parece correto na tela ainda pode falhar após escala, rasterização ou impressão térmica. Documentos operacionais precisam de confiabilidade no leitor, não só de um padrão visível.
Veja também
- Referência da API gPdf —
DocumentRequest, elementosbarcode, substituição de fontes e endpoints de geração. - Códigos de barras vetoriais vs raster em PDF — por que a geometria importa depois da impressão.
- Códigos de barras GS1-128 a 0,1 mm de precisão em JSON — detalhes de dimensionamento para etiquetas.
- PDF/A e Factur-X explicados para engenheiros — quando arquivamento e fatura eletrônica entram no fluxo PDF.