A todos nos ha pasado: un documento de Word perfectamente maquetado puede descuadrarse por completo nada más abrirlo en otro programa. Un currículum que ocupaba dos páginas exactas pasa a tres en Google Docs, o una fotografía se superpone sobre el texto equivocado en LibreOffice. El motivo no es un fallo puntual: el formato DOCX, pese a ser un estándar abierto, no obliga a todos los editores a maquetar el texto de la misma manera.
La explicación tiene más capas de las que parece a primera vista, y para entenderla tenemos que fijarnos en cómo interpreta cada aplicación las instrucciones que guarda un archivo .docx. Aunque Office Open XML (OOXML) es un estándar publicado que cualquier desarrollador puede implementar, no impone un motor de diseño común: cada programa decide por su cuenta dónde cortar una línea, cuánto espacio dejar entre párrafos y dónde empieza la página siguiente.
El mismo DOCX se ve distinto en Google Docs o LibreOffice
El estándar OOXML da a todos los editores una forma compartida de describir un documento, pero no les impone el mismo motor de diseño. Por eso Word, LibreOffice Writer y Google Docs calculan cada uno por su cuenta dónde termina una línea, cuánto espacio hay entre los distintos elementos y dónde acaba cada página, algo que el estándar no define de forma obligatoria. Esa diferencia de motor afecta tanto a documentos cortos como largos, aunque es en los textos de varias páginas donde el desajuste se vuelve más visible.
En una sola hoja esas diferencias de cálculo apenas se notan, pero se acumulan línea tras línea y página tras página a medida que avanza el documento. Por eso un informe largo que se veía perfecto en Word puede terminar, tras varias páginas, con secciones enteras desplazadas de sitio nada más abrirlo en otro editor, sin que hayamos tocado una sola palabra del contenido.
Una fuente que falta puede desplazar páginas enteras
El problema se agrava cuando el archivo utiliza una tipografía que el destinatario no tiene instalada. En ese caso, el programa busca automáticamente una fuente sustituta, y hasta el reemplazo más parecido puede tener anchos de letra y espaciados ligeramente distintos, lo que hace que las líneas se corten antes y los párrafos crezcan. Esa sustitución no es neutra: cambia el ancho de cada carácter y, con él, el punto exacto en el que el texto salta de línea. Esa cadena de sustituciones de fuente es uno de los motivos más comunes por los que un documento cambia de aspecto nada más cruzar de un programa a otro.
Ese efecto dominó explica por qué, al cabo de varias páginas, secciones completas cambian de sitio sin que haya cambiado ni una palabra del texto. Los desarrolladores de los editores alternativos trabajan en reducir ese desajuste: The Document Foundation lanzó LibreOffice 26.8.1 una actualización de mantenimiento reciente que forma parte del ciclo de desarrollo habitual del programa.
Las tablas, imágenes y cuadros de texto multiplican el riesgo
Una tabla es, en sí misma, un pequeño quebradero de cabeza de formato: el ancho de las columnas, el relleno de las celdas, la altura de las filas y la forma en que se divide al cambiar de página afectan a cómo se ve el resultado final. Cuanto más elaborada es una tabla en Word, más fácil es que otro programa la desmonte al abrirla.
Añadir cuadros de texto flotantes, imágenes o los diagramas de flujo propios de Word eleva todavía más el riesgo. Estos objetos suelen estar anclados a un párrafo concreto, alineados con un margen o configurados con un ajuste de texto específico, de modo que si el texto que los rodea se mueve aunque sea una sola línea, la imagen o el cuadro de texto puede acabar superpuesto sobre el párrafo equivocado.
Esto explica por qué, cuando compartimos un documento con varias tablas o imágenes incrustadas, el riesgo de que algo se mueva de sitio es mayor que en un texto corrido sin elementos gráficos. Cuantos más objetos anclados incluya el archivo, más puntos de fricción tendrá que resolver el programa que lo abra después.
Qué guarda un archivo .docx de Word por dentro
Basta con cambiar la extensión de un archivo a .zip y descomprimirlo para descubrir que, en realidad, es una carpeta con decenas de instrucciones repartidas en varios ficheros. La Library of Congress detalla ese reparto en su desglose del formato DOCX, donde queda claro cuánta información necesita procesar un programa solo para mostrar una página con texto e imágenes.
- El archivo document.xml, que guarda el texto principal del documento.
- Archivos XML independientes que definen los estilos y el formato de cada párrafo.
- Una carpeta media con las imágenes y los gráficos incrustados.
- Referencias a las fuentes utilizadas, que el programa debe localizar o sustituir si no las tiene instaladas.
Cada editor tiene que leer todas esas instrucciones y traducirlas en páginas visibles, y cualquier pequeña discrepancia en esa lectura del XML se traduce directamente en una diferencia de formato que podemos comprobar en la pantalla de quien recibe el archivo, por pequeña que parezca la instrucción original.
Décadas de legado de Word condicionan el DOCX actual
Antes de Office 2007, Word guardaba los documentos en el formato .doc, de estructura binaria y propietaria. Microsoft lo sustituyó por .docx, basado en Office Open XML, un proceso de estandarización que pasó por Ecma-376 en 2006 y por ISO/IEC 29500 en 2008, según recoge la historia del formato OOXML publicada por la Library of Congress.
El problema de fondo es que Microsoft no podía abandonar de golpe décadas de documentos que dependían del comportamiento del Word más antiguo. Por eso el estándar incluye dos variantes: Strict, que excluye funciones heredadas, y Transitional, que permite marcado adicional pensado para mantener la compatibilidad con los documentos más antiguos de Office. Un .docx guardado hoy mismo puede seguir arrastrando, por tanto, reglas de maquetación de hace más de una década.
Algunos documentos incluyen además ajustes de compatibilidad internos que le indican a Word qué comportamiento de una versión anterior debe conservar. Un archivo puede así llevar instrucciones ligadas a una generación anterior del software mucho después de haberse guardado con una extensión .docx moderna. Cuando ocurre esto, cualquier editor alternativo tiene que decidir hasta qué punto es capaz de reproducir ese comportamiento obsoleto, y ahí suelen aparecer las discrepancias más llamativas entre programas.
Qué podemos hacer para que el documento no se rompa
No existe una garantía absoluta de que un DOCX se vea igual en todos los programas, pero sí hay precauciones que podemos tomar para reducir el riesgo de forma notable. La documentación de LibreOffice señala que los elementos que más problemas generan al importar un archivo de Word son las autoformas, los objetos OLE y los marcos de texto complejos.
Antes de enviar un documento con un límite estricto de páginas, conviene:
- Usar fuentes estándar que el destinatario probablemente tenga instaladas en su sistema.
- Mantener las imágenes ancladas en línea con el texto, evitando los anclajes flotantes complejos.
- Abrir el archivo en la aplicación de destino antes de enviarlo, si sabemos cuál va a usar quien lo recibe.
- Exportar a PDF cuando el diseño final importe más que la posibilidad de seguir editando el documento después.
Word incluye la opción de exportar a PDF directamente desde el menú de guardado, y ese formato sí está pensado para mantener una presentación idéntica sin importar el programa con el que lo abramos después. Mientras el motor de diseño de cada editor de texto siga siendo distinto, esa sigue siendo la forma más fiable de garantizar que lo que enviamos es exactamente lo que recibe la otra persona.