Lanzamiento HN: Onedoc (YC W24) – Una mejor manera de crear PDFs

Artículo original ↗ Discusión en Hacker News ↗

Precios y modelo de negocio

  • Muchos comentaristas consideran que el precio inicial es “caro”, especialmente la facturación por documento para casos de uso de alto volumen o bajo margen (p. ej., facturas, documentos hipotecarios largos).
  • Se hacen comparaciones con ConvertAPI, api2pdf, DocRaptor, Urlbox, htmldocs, etc., que pueden ser significativamente más baratos por documento.
  • El equipo aclara que los precios ya se han revisado a la baja (hasta ~0,005 USD/doc a escala) y que aún están evolucionando; varias veces aparece la confusión entre precio por página y por documento.
  • Varios argumentan que, más allá de cierta escala, es más barato construirlo internamente; se sugieren licencias de precio fijo / on‑prem, fijadas en una fracción del salario de un desarrollador.

Alternativas y ecosistema existente

  • Se mencionan numerosas alternativas: headless Chrome/Puppeteer/Playwright, PrinceXML, DocRaptor, WeasyPrint, Paged.js, Gotenberg, wrappers de jsPDF/gofpdf, Typst, LaTeX/ConTeXt, Pandoc, xsl‑fo, pdf-lib, DocSpring, Platoforms, PDFlib, etc.
  • Algunos dicen que el stack FOSS (Playwright + Paged.js) es “state of the art” y que es difícil justificar pagar por él salvo que se añada valor en torno a la fiabilidad, las garantías de maquetación o el cumplimiento normativo.
  • Otros reportan problemas con las herramientas existentes, especialmente en maquetación, saltos de página, formularios y accesibilidad, y están abiertos a una solución mejor integrada.

Tecnología y funciones

  • La API de Onedoc actualmente envuelve PrinceXML/DocRaptor; el objetivo es reemplazar esto con un motor propio para tener mejor control, más funciones y menores costes.
  • Usa HTML/CSS con un fuerte soporte para PrintCSS/Paged Media, no un navegador headless, para mejorar la tipografía y la maquetación (viudas/huérfanas, cajas de página, encabezados/pies, regiones de página).
  • La librería de código abierto basada en React se centra en hacer que la maquetación de PDF se sienta como el trabajo frontend habitual; admite Tailwind, Chakra UI, Markdown, LaTeX y SVG.
  • Admite PDFs etiquetados y apunta a la accesibilidad PDF/UA‑1 basada en la semántica de HTML; tiene como objetivo PDF 1.7 con perfiles de color ICC y diversas cajas de página, aunque no todas las funciones de impresión (por ejemplo, ArtBox) están completas.
  • La hoja de ruta incluye llenado de formularios, firmas programáticas, metadatos más ricos, analíticas, integraciones con S3 y, eventualmente, self‑hosted/on‑prem.

Rendimiento, seguridad y encaje en el mercado

  • Los tiempos de renderizado actuales son de “segundos”, más lentos que configuraciones de headless Chrome ajustadas; las mejoras de rendimiento están en curso.
  • Algunos destacan la seguridad (especialmente SSRF y PII) e insisten en SOC2/ISO27001 y on‑prem para una adopción seria. Se reconoce el trabajo hacia SOC2 y la futura autohospedaje.
  • Hay interés desde sectores con documentos complejos, largos o regulados (gobierno, legal, salud, finanzas), especialmente si los PDFs accesibles/etiquetados y el cumplimiento normativo son robustos.
  • Debate subyacente: los PDFs son omnipresentes pero desagradables; algunos desearían alternativas, mientras que otros sostienen que construir sobre el ecosistema PDF ya consolidado es la única vía práctica.