La digitalización y la edición de contenidos
En estos tiempos pandémicos, hay pocos conceptos más socorridos que el de “digitalización”. Para muchos, es la oportunidad de consumar una serie de transformaciones que se prometían desde el advenimiento de internet y todos los desarrollos que supuso su universalización (la colaboración en tiempo real, el trabajo en la nube, la web semántica, la geolocalización, la inteligencia artificial, por nombrar sólo algunos), para otros se trata poco más que de una molestia infinita, que supone abandonar hábitos internalizados y reemplazarlos por otros que a su vez no tardarán en quedar obsoletos. Como sea, en este enjambre de novedades que nos atraviesa, la famosa digitalización sigue siendo en muchas disciplinas y aspectos un concepto oscuro. El propósito de estas páginas es explorar qué significa y cuáles son sus consecuencias en el ámbito de la edición de contenidos.
Y el primer punto sería determinar de qué hablamos cuando hablamos de “edición digital”. Según la RAE, digitalizar es o bien “registrar datos en forma digital”, o bien “convertir o codificar en números dígitos datos o informaciones de carácter continuo, como una imagen fotográfica, un documento o un libro”. Aquí, lo que nos interesa es la segunda acepción: porque expresa con exactitud el malentendido base que late en la discusión sobre la digitalización en el ámbito de la edición de libros.
Me explico. Si seguimos esta definición, no tenemos ninguna dificultad en identificar un archivo PDF como un archivo digital. Y no cabe duda de que lo es, un formato de archivo digital creado y mantenido como estándar (ISO 32000) con una función principal: representar con fidelidad el formato y las características de un documento físico. Lo cual, por otra parte, supone que un PDF es un formato estupendo para enviar a imprenta y también para imprimir los formularios de impuestos y los posters para hallar gatitos desaparecidos, pero es algo menos útil para presentar contenidos en pantalla. Pantalla que puede ser de distintos tipos y dimensiones. El PDF está diseñado para representar la manera en que diversos elementos se organizan en el papel y no para determinar cómo se organizan en una pantalla cualquiera. Y lo cierto es que ya sea que hablemos de la edición de contenidos en un sentido restringido (cuyo destino primario sea ser distribuidos en forma de libros), o en un sentido más amplio (artículos académicos, entradas de blog, hilos de Twitter, catálogos, etc…), tarde o temprano ese contenido (o partes de él) será leído en una pantalla. Un PDF es un formato donde los objetos que representa son inamovibles (y esa es su gracia), una pantalla en cambio es un medio que exige un formato donde los objetos representados puedan reacomodarse según sus características sin que eso suponga desestructurarlo. O de otra manera: significa que el formato del texto debe estar separado de su estructura y el PDF, en tanto fue diseñado para emular el papel impreso, no distingue entre uno y otro a menos que se le diga que lo haga. Pero también ocurre que por muy bien diseñado que esté ese PDF, es probable que sea leído en una multitud de dispositivos (ereaders, tablets, computadoras, smarts TVs, lectores de braille, hasta relojes) cada cual con sus especificaciones y propiedades. Y eso es algo que definitivamente no hace bien. Por que no fue diseñado para eso. Un buen ejemplo de esto son los portales memorialisticos o patrimoniales que se presentan como archivos “digitalizados” de libros y documentos. Como esfuerzo archivistico es encomiable, que duda cabe. Pero en términos editoriales, representan un fracaso. La lectura de un PDF escaneado (con más precisión: una imagen incrustada dentro de un archivo PDF) pocas veces es una experiencia amable.
Editar en digital
El problema radica en que la edición digital no significa necesariamente trabajar con herramientas digitales sino trabajar con herramientas orientadas a formatos de salida digitales (o lo que es equivalente: a múltiples formatos de salida). Un ejemplo de los problemas que plantea esto es el venerable M.S Word. Por razones que van desde su facilidad de uso hasta su omnipresencia en las computadoras, se ha transformado en una especie de estándar de facto en la industria de la publicación de contenidos, aunque lo cierto es que también se trata de un residuo de una época en que el papel era el único formato de salida posible y de que su objetivo específico era servir a la redacción de documentos de oficina. Es una herramienta digital, pero aunque a lo largo de los años y las versiones se le hallan ido agregando cada vez más funcionalidades, no es capaz de hacer las cosas básicas que se le piden a una herramienta destinada a entornos de producción de contenidos multidispositivos: no puede exportar un HTML útil (para colgarlo en la web), ni generar archivos usables para construir un EPUB (para leerlo en un E-Reader), no puede ser convertido en otro formato de texto sin que eso lleve a innumerables dolores de cabeza, su exportación a otras aplicaciones es siempre problemática, y sus posibilidades de trabajo colaborativo son, de nuevo, muy limitadas. Discutiré esto en otra entrada, pero de momento hay que tener en cuenta que editar en estos tiempos digitales significa entre otras cosas que tu contenido será colgado en la web, convertido a ebook, atomizado en post de distinto tipo, alimentara catálogos, requerirá metadata, será leído o transformado en Braille por dispositivos de asistencia, querrá transformarse y fluir. Por tanto, necesitaremos herramientas que puedan conectarse con otras, que generen archivos livianos, que no estén prisioneras de códigos incomprensibles, que puedan someterse a control de versiones y que dispongan de posibilidades de trabajo colaborativo. O sea: lo que necesitamos son archivos de texto plano.
Editar en texto plano
Los que son lo suficientemente viejos, alguna vez habrán tipeado un trabajo escolar en una maquina de escribir. Las venerables máquinas de escribir hacían básicamente eso: escribir texto. No podían incluir ilustraciones, declarar cursivas, cambiar de tipografía… En realidad no podían hacer casi nada que no fuera escribir texto. Si necesitábamos poner una foto o bien, poníamos un espacio para pegarla después, o bien, escribíamos “aquí va la ilustración x” en caso de que después eso fuera a imprenta y alguien se ocupara de componer el documento. Esa persona interpretaba el texto y decidía qué hacer con él: donde poner cursivas, negritas, qué fuente utilizar, etc, etc… O sea, lo ya dicho, había una separación natural (natural en relación al alcance de las herramientas) entre el contenido y el aspecto que este contenido adquiriera una vez editado, aunque tal vez nadie se lo planteara de esta manera. Para establecer instrucciones acerca del significado semántico de cada porción de texto, se utilizaban anotaciones, muchas veces manuales (este texto subrayado va en cursivas, este otro texto es una lista, el pie de foto va aquí, esto es un subtitulo en negritas, etc…). Con el tiempo y la aparición de las primeras computadoras, se idearon los lenguajes de marcado (primero el GML, luego el SGML, más tarde el HTML) y su intención es básicamente la misma que tenían aquellas anotaciones: indicar qué función tiene cada porción de texto dentro de la estructura general. Esto permite que la computadora formatee el texto siguiendo las instrucciones y, al mismo tiempo, que la computadora entienda esa función.
Los lenguajes de marcado o etiquetado
Los lenguajes de marcado comparten una sintaxis a base de etiquetas y todos, más o menos funcionan igual:
<h1> Esto es un título</h1>
<p> Este es un párrafo de texto, donde hay <em>un texto etiquetado como itálicas</em></p>
Esto es HTML, pero podría ser cualquier otro lenguaje de etiquetado. Lo importante es que las etiquetas definen la función del texto que está entre ellas (h1 singifica heading 1, o título principal, y p es paragraph o párrafo). También los procesadores de texto funcionan de esta manera, pero al ser lo que se conoce como WYSIWYG (what you see is what you get, “lo que ves es que consigues”), el código (las etiquetas) están ocultas, dejándonos sin ninguna posibilidad de ver qué pasa tras bambalinas. Un editor de texto plano opera de la manera opuesta: es casi una maquina de escribir, aunque infinitamente más sofisticada. Supone sencillamente escribir caracteres y espacios en una pantalla.
Dado que no tenemos controles visuales para trasformar palabras o conjuntos de palabras en cursivas, marcamos el texto a través de etiquetas (como en el ejemplo anterior, en html): <em>este texto va en cursivas</em>. Pero escribir código HTML (o cualquier otro lenguaje de etiquetas: xml, docbook, etc…) es laborioso, por mucho que existan herramientas que lo facilitan. Es por eso que fueron ideados los lenguajes de marcado ligero, de los cuales Markdown es el más conocido. En este caso solo tenemos que preocuparnos de aprender una serie de marcas, que funcionan en entornos tan distintos y cotidianos como wordpress y whatsapp, y que pueden formatear documentos, convertirlos en otros formatos, y manipularlos casi instantaneamente. (si quieren probar, basta que abran un chat en whatsapp y escriban: *esto es un texto en negritas* y _esto es un texto en itálicas_ y verán como whatsapp los obedece). ¿Por qué ocurre esto? Por que cualquier lenguaje de etiquetado consistente (que tiene un conjunto de etiquetas que se escriben de una manera determinada y hacen lo mismo siempre) puede ser transformado en cualquier otro lenguaje de etiquetas por un parser (un programa que trasforma unas etiquetas en otras). Esto se puede hacer en el caso de markdown y whatsapp, que es un caso sencillo, pero también puede ser que queramos convertir un libro entero formateado en markdown e importarlo en indesign: utilizando pandoc (un programa de manipulación y conversión de texto) y una sencilla orden, lo podemos hacer instantáneamente. Lo más importante: un archivo de texto plano formateado en markdown nos permite convertirlo en un PDF para imprenta (vía pandoc e indesign), en una página web (vía pandoc), en un epub (idem) y renderizarlo por un lector de Braille sin problemas y casi instantaneamente.
Separar contenido de su presentación.
La principal ventaja de trabajar en texto plano es la separación de contenido y apariencia, lo que equivale a decir que la estructura semántica del texto y su diseño van aparte. En lugar de utilizar una fuente extraña y en cuerpo más grande para señalar un título, lo que hacemos es etiquetar el texto como título y luego, en una hoja de estilo aparte (panel de estilos en InDesign, CSS en HTML y EPUB, un template en Latex) podemos personalizar la manera en que ese contenido se presentará según el formato de salida o el dispositivo que vaya a renderizarlo. Esto permite que un mismo texto, estructurado de la misma manera, pueda, asociandolo a unas instrucciones determinadas, ser una página web, un ebook, una aplicación móvil, y un PDF para imprenta, sin tocar el documento en si mismo. Naturalmente, es necesario escribir (o adaptar) estas hojas de estilo, pero si tenemos una editorial y vamos a producir muchos libros que se parecen (usan la misma tipografía, o comparten un diseño base) esto será trabajo de una vez. Esto también permitirá (si el archivo está bien estructurado) que nuestro contenido sea accesible de origen.
Control de versiones
Otra de las ventajas de los archivos de texto plano es que nos permiten utilizar sofisticadísimos sistemas de control de versiones. El más conocido, pero no el único, es GIT. GIT es un software de control de versiones distribuido, lo que significa que cada copia de un archivo sometido a control de versiones se encuentra simultaneamente en todos los computadores de quienes trabajan en ese archivo. Y Git puede recordar cada uno de los cambios que los usuarios han hecho en el archivo. De manera que no hay manera que un azar desafortunado se lleve tu trabajo. Git sabe donde está. Pero no sólo puede hacer esto: controlar versiones para GIT no sólo significa que puede llevar un registro de cada cosa que hallas hecho sino también que te da la posibilidad de crear ramas alternativas de tu trabajo para que ensayes y experimentes sin tocar la parte ya definitiva de tu trabajo. Esto permite también que puedas crear versiones distintas de tu contenido (por ejemplo, para diferentes formatos o diferentes audiencias, imaginate la traducción de un libro con una versión española y otra neutra y otra en chileno profundo) dentro del mismo archivo. Y esto, que se dice rápido, significa librarse de esas carpetas infinitas llenas de words (version_final.docx, version_final_corregida.docx, version_final_correccion_03-05-2022.docx, etc…) GIT fue diseñado por el creador de Linux, Linus Torvald, como sistema de control de versiones para los desarrolladores de software. pero el software y los libros comparten muchas cosas. La principal: son texto.
Pero no todo acaba aquí. Existen numerosas plataformas en la nube creadas con Git como base. La más conocida (no la única) es GitHub. Y entre sus caracteristicas están darte un espacio (libre y gratuito) para que mantengas tus archivos organizados en repositorios, manejes lo que quieres compartir de ellos, y hasta puedas crearte una página web. Los archivos de texto plano también te dan la posibilidad de montarte tu propia nube.
Sostenibilidad
Mi primer computador fue un 286 que me vendió un amigo. No tenía Windows, de manera que la forma de trabajar con él a través de la línea de comandos. Cuando lo encendía, sonaba como un refrigerador. Y tenía una pantalla deliciosa, con unas muy coquetas letras verdes. Lo usaba mayormente para escribir mis trabajos de la universidad y algún que otro cuento. Después de ese computador, vinieron otros. Apareció Windows. Cambién los floppy disks por CDs y luego estos por Pendrives. Cómo todo el mundo, terminé mudandome muy rápidamente a Word. Principalmente, por que estaba en todas partes. Y por que Wordperfect, que era el programa que yo utilizaba para escribir, desapareció en algún momento durante el cambio de milenio. Y fui acumulando decenas, cientos y luego miles de cds, dvds, pendrives y discos duros. Después de haber migrado entre sistemas operativos y haber trasladado archivos de textos de un dispositivo a otro y luego a la nube, y haber intentado leerlos una y otra vez a lo largo de los años, puedo decir que que la cantidad de tiempo que he perdido intentando descifrar documentos de word en otros programas o en una versión distinta de word, me habría dado tiempo para escribir un par de novelas y hasta una opera. Porque word o cualquier otro procesador de texto que sea software propietario y esté protegido por una licencia comercial puede desaparecer mañana o cambiar o enloquecer completamente y ahi quedarán tus documentos: extraviados en la tierra de nadie de los archivos huerfanos. Como pasó con mis documentos de Wordperfect o mis viejos words, que si ahora intentara abrir probablemente haría que mi laptop estallara en pedazos. Esto puede parecer un imposible, pero cosas más extrañas han pasado. Lycos, Geocities, MySpace, WordPerfect, OpenOffice… la lista de software o plataformas que en algun momento parecían sólidas y dignas de toda confianza que han desaparecido es interminable. Si de lo que se trata es de mantener archivos domésticos o tus trabajos de universidad, tal vez pueda moderarse la preocupación. pero si estamos hablando de construir un catálogo, mantener un archivo de documentos, o almacenar todos los números de una revista, tal vez habría que pensar en la sostenibilidad del formato que escogemos. Sobretodo si se trata de contenidos que queremos reciclar o tener a mano. Tal vez la mejor opción sea buscar un formato que no tenga capas ocultas y que cualquier máquina, ahora o en el siglo XXX pueda abrir. Y que sea ligero y que minimize el error y pueda someterse a control de versiones. Y que pese poco y pueda ser almacenado sin que la cuestión del espacio sea una preocupación (alguién alguna vez pensó que iba a llenar el mailbox de Google…? ).
O sea: un archivo de texto plano.
