Deja de parsear PDFs en tiempo de renderizado
La mayoría de las herramientas de extracción de PDF en el frontend fallan.
Los desarrolladores intentan adivinar la estructura del documento a partir de la salida visual. Observan los píxeles renderizados para encontrar columnas, tablas o listas. Utilizan visión artificial o la proximidad de los píxeles para decidir dónde comienza un cuadro.
Esta es la forma incorrecta de construir.
Un PDF ya contiene datos estructurales explícitos en su flujo de operadores (operator stream). Una tabla no es solo un grupo de píxeles cercanos. Se dibuja con comandos específicos como moveTo, lineTo o rectangle. Los límites que quieres encontrar ya están codificados en el origen.
Si tu extractor te devuelve columnas diferentes con un zoom del 100% frente a uno del 150%, no estás extrayendo la estructura. Estás haciendo un reconocimiento de patrones de artefactos visuales.
Deja de usar heurísticas visuales. Empieza a parsear el flujo de operadores.
Por qué el flujo de operadores es mejor:
- Es determinista. Funciona de la misma manera independientemente de la escala o del font hinting.
- Utiliza datos reales. Usas las rutas y coordenadas reales definidas por el creador.
- Evita errores matemáticos. Por ejemplo, usar puntos medios entre los centros del texto para encontrar zonas provoca errores de redondeo. Usar el borde superior real de un cuadro delimitador (bounding box) es la única forma correcta.
El camino difícil es el camino correcto.
Debes entender la pila CTM (CTM stack). Debes rastrear los estados de la matriz y clasificar los subpaths. Tienes que leer la especificación de PDF y el código fuente para dominarlo.
Esto requiere más esfuerzo inicial. Pero funciona para cada PDF que un usuario sube. Las herramientas basadas en píxeles solo funcionan para los pocos archivos de tu suite de pruebas.
Construye un extractor real, no una demo.