Cómo convertir un PDF escaneado en un documento con búsqueda: OCR y ajustes de escaneo
Cómo lee una página el OCR (análisis de maquetación y reconocimiento de líneas), qué cambió el LSTM de Tesseract 4, de dónde sale la regla de los 300 DPI, PDF de imagen frente a PDF con búsqueda, y por qué la escritura a mano sigue siendo difícil.
Escaneas en la fotocopiadora de la oficina un contrato de alquiler firmado, abres el PDF, pulsas Ctrl+F, escribes «fianza»… y nada. El archivo parece texto, pero lo que contiene es una fotografía de texto. Para el ordenador es una cuadrícula de píxeles claros y oscuros, con tanto significado como una foto de las vacaciones. El reconocimiento óptico de caracteres (OCR) es la forma de recuperar las palabras.
PDF de imagen, PDF de texto y PDF con búsqueda
Las páginas PDF son de tres tipos básicos:
| Tipo | Suele salir de | Buscar y copiar |
|---|---|---|
| PDF de texto | «Guardar como PDF» en Word, Google Docs, LibreOffice | Sí: los caracteres van con sus fuentes |
| PDF de imagen | Escáneres, apps de escaneo del móvil | No: cada página es una imagen |
| PDF con búsqueda | Un PDF de imagen con capa de OCR | Sí: hay texto invisible encima de la imagen |
El tercer tipo se apoya en un detalle de la especificación PDF: el modo de renderizado de texto 3, que dibuja los glifos sin relleno ni trazo. El resultado del OCR se coloca en ese modo exactamente encima de las palabras del escaneo. Tú ves la imagen original; el visor usa las palabras ocultas para buscar, seleccionar, copiar y para los lectores de pantalla. Si al arrastrar sobre una página escaneada el resaltado azul nunca coincide del todo con las letras, esta es la razón.
El diseño tiene una ventaja: la página visible nunca se modifica, así que un error de OCR no estropea lo que ves, solo lo que buscas y copias. La otra cara es que una frase copiada de un PDF con búsqueda merece una segunda mirada. Lo que copias no tiene por qué ser lo que ves.
Cómo lee una página un motor de OCR
Los motores modernos trabajan en dos fases.
Primera fase: análisis de maquetación. El motor localiza las zonas con texto y las divide en columnas, párrafos y líneas, descartando por el camino imágenes, filetes de tablas y manchas. Si se equivoca en una página a dos columnas, el resultado alterna línea a línea entre la columna izquierda y la derecha.
Segunda fase: reconocimiento de líneas. Cada imagen de línea recortada se convierte en una cadena de caracteres. Aquí es donde más ha cambiado la tecnología.
Tesseract, el motor libre más conocido, se desarrolló en Hewlett-Packard entre 1985 y 1994; HP lo publicó como código abierto en 2005 y Google dirigió su desarrollo de 2006 a 2017. El motor que describe el artículo de Ray Smith de 2007 cortaba primero cada línea en caracteres candidatos y después clasificaba cada uno por los rasgos de su contorno. Ese enfoque necesita saber dónde acaba una letra antes de decidir cuál es, y de ahí vienen los errores clásicos: leer «rn» pegadas como «m» o «cl» como «d».
Tesseract 4.0 convirtió en reconocedor por defecto una red neuronal LSTM (memoria a corto y largo plazo), en palabras de su documentación un motor «centrado en el reconocimiento de líneas». Recorre toda la imagen de la línea arrastrando el contexto y emite la cadena de una vez, sin fijar antes los límites de cada carácter. Eso lo hace mucho más tolerante con letras que se tocan o impresiones irregulares. El precio, según la misma documentación, es del orden de diez veces más CPU que el motor antiguo.
Los sistemas de OCR con aprendizaje profundo, como PaddleOCR, comparten el esqueleto. Una red de detección produce un mapa con la probabilidad de que cada píxel sea texto y lo convierte en recuadros de línea; una red de reconocimiento lee cada línea. El reconocimiento suele usar decodificación CTC: la línea se trata como una secuencia de franjas verticales estrechas, la red elige para cada franja el carácter más probable (o un «vacío») y las repeticiones se funden en la cadena final. La herramienta de OCR para PDF de este sitio usa por defecto modelos de PaddleOCR; para español emplea un modelo de escritura latina que conoce tildes, eñes y diéresis.
De dónde sale la regla de los 300 DPI
La documentación de Tesseract dice que «funciona mejor con imágenes de al menos 300 DPI». La cifra no tiene nada de mágico: es una forma indirecta de medir cuántos píxeles recibe cada carácter.
Un punto tipográfico es 1/72 de pulgada, así que un texto de 10 puntos mide 10 × 300 ÷ 72 ≈ 42 píxeles de alto a 300 DPI, unos 28 a 200 DPI y unos 21 a 150 DPI. Con 21 píxeles una letra latina limpia suele sobrevivir, pero las marcas pequeñas caen primero: la tilde, la diéresis, la virgulilla de la ñ, la coma frente al punto, el 8 frente a la B cuando la tinta se corre un poco. En español esos detalles no son decorativos: «año» y «ano», «público» y «publico», o «está» y «esta» son palabras distintas. En chino, japonés o coreano, donde un solo carácter puede tener una docena de trazos en un cuadrado, los huecos entre trazos se reducen a uno o dos píxeles y los caracteres parecidos se intercambian.
Una guía práctica:
- Texto normal (10–12 pt): 300 DPI
- Notas al pie, condiciones generales, tiques de compra (8 pt o menos): 400 DPI o más
- Carteles y titulares grandes: con 200 DPI basta
Hay una trampa en la que cae mucha gente: no se puede añadir resolución a posteriori. Un PDF escaneado a 150 DPI y renderizado a 400 DPI para el OCR solo obtiene píxeles más grandes. El detalle perdido al escanear no vuelve, así que la resolución se decide en el escáner.
Ajustes del escáner que cambian el resultado
Después de la resolución, importan sobre todo cuatro ajustes.
Modo de color. El modo «blanco y negro» (1 bit) del escáner produce los archivos más pequeños, pero aplica un único umbral a toda la página. El lápiz tenue, la impresión gris clara y el texto junto a un lomo en sombra pueden desaparecer en ese momento, para siempre. Si escaneas en escala de grises, más tarde podrás aplicar umbrales adaptativos: métodos como el de Sauvola eligen el umbral de cada píxel según el brillo de su entorno. La documentación de Tesseract advierte que su binarización interna (Otsu) «puede no ser óptima, sobre todo si el fondo de la página tiene una oscuridad desigual».
Compresión. Un JPEG de baja calidad deja halos (ringing) alrededor de los bordes de las letras, y el OCR los interpreta como trazos. Elige la calidad alta del escáner o una compresión más ligera.
Inclinación. Bastan unos grados para que el final de una línea larga invada la siguiente. La recomendación de la documentación de Tesseract es simple: girar la página hasta que las líneas queden horizontales. Los alimentadores automáticos de hojas son los culpables habituales. Enderezar antes del OCR con el modo de corrección de inclinación de la herramienta de mejora de escaneos estabiliza el reconocimiento, y como solo gira las coordenadas de la página en lugar de volver a renderizarla, no cuesta calidad de imagen.
Bordes y sombras. Los libros escaneados boca abajo recogen una sombra oscura en el lomo y bandas negras en los bordes; la documentación de Tesseract avisa de que esos bordes oscuros pueden reconocerse como caracteres de más. Los agujeros de la perforadora se leen como «o» o como puntos con sorprendente frecuencia. Quitarlos antes del reconocimiento es la solución fiable.
Las fotos con el móvil añaden distorsión de perspectiva (la página se vuelve un trapecio) y luz desigual. Usa el modo documento de tu app de escaneo para que cuadre la página, y fotografía con luz uniforme, sin tu propia sombra encima del papel.
Idiomas, alfabetos y el modelo correcto
Un modelo de OCR solo reconoce los caracteres con los que se entrenó. Un modelo entrenado solo con inglés no tiene clase para «ñ», así que la fuerza a la letra más parecida y «España» sale como «Espana». Lo mismo vale para francés, alemán o portugués. Elige siempre un modelo que conozca tu alfabeto; los modelos «latinos» que cubren varias lenguas europeas a la vez funcionan bien para documentos con nombres y términos mezclados.
El salto es mucho mayor en otros sistemas de escritura. El inglés necesita alrededor de un centenar de símbolos contando mayúsculas, minúsculas, cifras y puntuación. Unicode tiene 11.172 sílabas coreanas precompuestas, y la lista oficial japonesa de kanji de uso general tiene 2.136 caracteres antes de sumar los dos silabarios. Más clases significa más pares de caracteres casi idénticos, y el japonés y el chino ni siquiera usan espacios entre palabras, así que cualquier espacio que añada el OCR sobra. La documentación de Tesseract 4 dice que admite y detecta automáticamente el texto vertical en chino, japonés y coreano, pero no todas las herramientas lo hacen.
Por qué la escritura a mano sigue siendo difícil
El OCR de texto impreso se basa en una suposición: la misma letra en la misma fuente se ve casi igual cada vez. La escritura a mano la rompe. Las formas cambian de una persona a otra y de una línea a otra, las letras se enlazan, la línea base se tuerce y las palabras se salen de las casillas del formulario. Leer manuscritos exige un modelo entrenado específicamente para ello, y aun así la precisión rara vez iguala a la del texto impreso.
PaddleOCR afirma que su versión PP-OCRv5 mejoró el reconocimiento de escritura a mano en chino e inglés. No hemos encontrado una afirmación publicada equivalente para el español. En la práctica, cuando un formulario mezcla impreso y manuscrito, conviene dejar al OCR la parte impresa y que una persona transcriba los campos escritos a mano.
Cómo saber si puedes fiarte del resultado
Los motores dan una puntuación de confianza por palabra. Una media del 90 % significa que una palabra de cada diez puede ser dudosa, y esa puede ser un importe, un IBAN o un NIF. Una revisión sensata:
- Empieza por las palabras marcadas con baja confianza y compáralas con el escaneo.
- Repasa aparte cifras, fechas y nombres propios. La corrección con diccionario no ayuda ahí y los errores sobreviven.
- Busca en el PDF terminado algunos términos clave y comprueba que aparecen.
No todos los PDF necesitan OCR. Prueba antes la extracción de texto de PDF. Si el resultado sale vacío, es un PDF de imagen. Si hay texto pero con símbolos sin sentido en lugar de palabras, lo habitual es que el PDF no tenga un mapa ToUnicode correcto, la tabla que traduce los glifos de la fuente a caracteres. La extracción no puede arreglarlo, y la respuesta práctica es, paradójicamente, pasar por OCR un PDF que técnicamente ya contiene texto.
Un flujo de trabajo que funciona
- Escanea a 300 DPI en escala de grises, o a 400 DPI si la letra es pequeña.
- Corrige orientación e inclinación; elimina bordes, sombras y motas.
- Pasa el OCR con el idioma correcto y revisa las palabras de baja confianza y todas las cifras.
- Comprueba que la búsqueda funciona y guarda el escaneo original junto a la copia con búsqueda.
Ese último paso compensa el espacio en disco. El OCR sigue mejorando, y un buen escaneo original podrá leerse de nuevo con un motor mejor dentro de unos años; uno malo, no.
Fuentes
- Tesseract OCR — repositorio en GitHub (historia, motor LSTM)
- Tesseract documentation — Improving the quality of the output
- Tesseract documentation — Neural nets in Tesseract 4.00
- Ray Smith — An Overview of the Tesseract OCR Engine (ICDAR 2007)
- PaddleOCR — PP-OCRv5
- ISO 32000-1:2008 (PDF 1.7) — modo de renderizado de texto, ToUnicode