Qué formato aguanta el parser y qué se rompe

Los extractores de texto reconstruyen el orden de lectura a partir de dónde está dibujada cada palabra en la página, no de ninguna estructura interna del documento. Ese es el mecanismo. De ahí sale la línea divisoria que conviene memorizar.

Una técnica es gratis si cambia cómo se ve el texto (color, grosor, tamaño, interlineado, sangría, espaciado entre letras). Es peligrosa si cambia dónde se sienta. Columnas, alineación a la derecha, elementos flotantes, tablas.

Eso no es una intuición. Juntamos toda la decoración del primer grupo (líneas de sección, un color de acento, encabezados con espaciado, viñetas con sangría francesa, más interlineado y control de saltos de página) y medimos el resultado contra un control sin estilo alguno.

La primera fila después del control es la buena noticia. La decoración tipográfica no cuesta nada, y de hecho bajó la fragmentación del extractor de 23 bloques a 20, así que el documento salió más ordenado que el control. Un CV puede verse bien sin pagar por ello.

Las otras dos filas son el hallazgo que más nos costó aceptar. Poner el puesto a la izquierda y las fechas alineadas a la derecha en la misma línea es lo que hace casi cualquier plantilla de las que se ven bonitas, y es la razón por la que nuestro CV se ve más plano que las de ellos.

Con la primera implementación, la que posiciona las fechas como su propio bloque, la fidelidad cayó a 96,41% en pdfminer y el contenido se reordenó. «Software Engineer — VMware» salió emitido después de su bloque de fechas, y los años de estudio se desprendieron de la institución. Eso es exactamente la falla de «las fechas pegadas al empleador equivocado» que describe la investigación sobre parseo, reproducida en nuestro propio documento.

La segunda implementación, rellenando con espacios para no reposicionar nada, evita casi todo el reordenamiento y fragmenta peor: 29 bloques contra los 20 de la versión decorada de la que parte.

El mecanismo es la parte que importa, porque explica por qué no es cuestión de implementarlo mejor. Una fecha alineada a la derecha es un diseño de dos columnas de una línea de alto. Los extractores detectan columnas buscando espacios verticales en blanco, que es la misma heurística que convierte los CVs de dos columnas en el fallo de parseo número uno. El hueco es la señal, y da lo mismo si está hecho de posicionamiento o de espacios.

Por eso las fechas van debajo del puesto, en su propia línea. Se ve peor. Se extrae bien. Ese es el trato.

El caso más limpio de la regla general apareció con las viñetas. La forma obvia de hacer una sangría francesa es dibujar el «•» en el margen y el texto en un bloque al lado.

Eso desprende cada marcador de su texto. El extractor agrupa los marcadores por posición y los emite juntos, «• • • • •», seguidos del texto de las viñetas como párrafos sueltos. El contenido sobrevive. La estructura de lista no.

La versión que usamos consigue la misma imagen con un solo bloque de texto tirado hacia la izquierda por una sangría negativa de primera línea, y midió idéntico al control. Las dos son indistinguibles en pantalla y completamente distintas en la capa de texto. Si tuviéramos que dejar una sola cosa de esta guía, sería esa frase.

La palanca estética más grande que queda es usar una tipografía de verdad, y es justo la que hay que dejar quieta. Helvetica viene incorporada en el formato PDF: no se incrusta y no necesita una tabla ToUnicode, así que la extracción no puede fallar por ella.

Una fuente incrustada depende de que esa tabla esté completa para que el texto sea recuperable. Donde está incompleta, los extractores devuelven basura o no devuelven nada, y eso está documentado en los rastreadores de errores de pdfminer, PyMuPDF y veraPDF. El lado bueno es una página más linda. El lado malo es un CV ilegible para la máquina. No está cerca.

El espaciado entre letras tiene un límite parecido y más fino. Lo tenemos en 0,9 puntos sobre los encabezados de sección, un valor deliberadamente conservador. Con espaciado más ancho los extractores empiezan a meter espacios entre las letras, el encabezado deja de coincidir con los nombres de sección que los parsers buscan, y una decisión puramente estética termina rompiendo el reconocimiento de secciones. No medimos dónde está exactamente ese umbral; elegimos quedarnos lejos de él.

Acá se acaban nuestras mediciones y empieza el consenso de terceros, así que vale marcar el cambio de piso. Las fuentes no se ponen de acuerdo, y el desacuerdo es real y no un caso de un lado equivocado.

A favor del DOCX: es XML estructurado, con metadatos explícitos por elemento, mientras que el PDF obliga a reconstruir el texto. Dos vendedores de herramientas de CV publicaron pruebas propias: uno pone el DOCX en 97% de precisión de parseo contra 76% de los PDF de texto, el otro en 96,7% contra 91,3%. Ninguno publica metodología verificable, . Que difieran quince puntos sobre la misma cantidad dice bastante. Los sistemas viejos, sobre todo Taleo, sí lo prefieren claramente. Con los portales de gobierno el consejo circula mucho y no se sostiene igual: USAJOBS, el más grande, recomienda PDF.

A favor del PDF: los parsers modernos manejan bien un PDF de texto, y el PDF incrusta las fuentes, así que la persona que abre el archivo en la cuarta etapa ve lo que vos diseñaste. Un DOCX puede sufrir sustitución de fuentes en otra máquina.

La regla práctica que sale de eso tiene cuatro casos. Si el anuncio dice cuál formato quiere, ese, siempre. Si es un portal desconocido, o sabés que es Taleo o una empresa muy grande con sistemas viejos, DOCX. Si le estás escribiendo directamente a una persona, PDF. Y nunca, en ningún caso, un PDF hecho de imágenes.

Ese último es el único error de esta guía que es fatal en lugar de costoso. Un CV escaneado, exportado desde una herramienta que rasteriza, o impreso a PDF desde una foto, no tiene capa de texto. Una fuente le midió alrededor de 4% de éxito de extracción. La comprobación toma tres segundos. Abrí el PDF y tratá de seleccionar el texto con el cursor. Si no podés, tampoco puede el parser.

Hay una asimetría que explica por qué el consejo sobre fechas cambia según el formato. En un DOCX, un tabulador derecho de verdad sí es seguro, porque un run guarda su cadena completa sin importar dónde se parta visualmente la línea, y la guía habitual para ATS hasta lo recomienda. En PDF no existe equivalente: ahí el mismo efecto obliga a mover texto.

El consenso práctico es una página hasta los diez años de experiencia, dos de ahí en adelante, y tres o más solo en academia y medicina. El gobierno estadounidense iba en esa lista hasta septiembre de 2025, cuando USAJOBS empezó a rechazar en la subida cualquier currículum de más de dos páginas. Conviene saber que la evidencia detrás de eso es débil.

El dato de que los reclutadores son «2,9 veces más propensos» a elegir un CV de dos páginas sale de una simulación de 2018 de ResumeGo, que vende servicios de redacción, y ese número es solo para puestos de jefatura: el general es 2,3 veces. Zety y otros lo repiten sin decir de dónde viene, que es de donde sacamos nosotros la atribución equivocada hasta agosto de 2026.

Eso sugiere un encuadre mejor que contar páginas. Cada línea tiene que ganarse el espacio. Un CV de dos páginas relleno pierde contra uno de una página denso, y uno de dos páginas genuinamente rico le gana a uno comprimido a la fuerza. Y si estás aplicando a Reino Unido o Europa continental, la norma local son dos páginas, no una.

Toda la tipografía vive en el renderizador y el modelo nunca la ve. El color y el espaciado entre letras están en un archivo compartido que los dos adaptadores leen. El resto, la fuente y los tamaños, está escrito una vez por adaptador: Helvetica en el PDF y Arial en el DOCX, con los tamaños espejeados a mano.

El PDF y el DOCX se arman con el mismo contenido y el mismo orden a propósito, y eso cuesta algo. En DOCX podríamos usar tabuladores derechos para las fechas sin riesgo, y no lo hacemos. «El PDF y el Word parecen CVs distintos» es un problema peor que unas fechas alineadas a la izquierda.

Lo más útil que podemos decir acá es que correr el extractor sobre nuestra propia salida encontró dos defectos reales que nadie había visto. El primero: la línea de contacto se le entregaba al motor de maquetado como una sola cadena, así que se partía a mitad de campo y la capa de texto contenía «linkedin.com/in/» y el nombre de usuario como dos tokens separados. Se arregló eligiendo nosotros los saltos, solo entre campos y nunca dentro de uno. El segundo: Poppler vuelve a unir una palabra que encuentra partida entre dos líneas, así que «knowledge-base» se extraía como «knowledgebase». Eso es una palabra clave que deja de coincidir, no una corrupción, y está solo parcialmente bajo nuestro control, porque dónde se parte una línea depende del contenido. La prueba lo reporta como advertencia y no como fallo.

El primero es el más instructivo. Fue invisible mientras nadie corrió un extractor sobre nuestra propia salida, y degradaba justo el campo que los parsers llenan primero.