De Word a Writer: la batalla del software de oficina
Imagen generada con Playground AI de acuerdo sus condiciones
Hace varios años, mientras utilizaba Microsoft Windows, en su versión 7, como mi sistema operativo y, Microsoft Word, como procesador de texto avanzado, comencé a escribir una tesis de maestría en historia. En medio de esa labor, se me ocurrió la brillante idea de complicarme más la vida y realizar un cambio de editor de texto, en favor de LibreOffice Writer y, poco tiempo después, me sentí aún más intrépido y me atreví a dar el siguiente salto, que es, migrar de Windows a Linux.
En ese mismo instante, negros nubarrones arribaron por el horizonte, dejando claro que lo establecido había sido desafiado ⛈️. Esos malos augurios, anticipaban bucles infinitos de instrucciones incomprensibles para el ordenador, frustrantes bloqueos y tiempo perdido.
Si bien, la experiencia no fue así de agitada, evidentemente, algo de drama hubo. Como toda transición, cambiar de herramientas de trabajo no es fácil, pero si la migración es necesaria y sirve para mejorar la labor, pues vale la pena el sacrificio y, creo que en este caso, las adversidades fueron provechosas. Mientras sucedía aquello, rondaban en mi mente ciertas reflexiones, primero, sobre las curiosas diferencias entre programas y, luego, respecto a las dificultades de compatibilidad entre formatos, que se me presentaban. Una vez concluida la elaboración de mi tesis, decidí reunir esos pensamientos en este lugar 🙂️.
El escrito explora brevemente la historia de la rivalidad entre los programas de oficina de Microsoft y sus variantes de código abierto, lideradas inicialmente por OpenOffice.org; luego, describe las consecuencias concretas de esa disputa, expresadas, de cara al usuario, en los problemas de compatibilidad de formatos entre programas editores de texto; a continuación, revisa problemas concretos a los que me enfrenté durante el proceso de migración de Microsoft Word (a partir de ahora, se lo nombrará, simplemente, como Word) a LibreOffice Writer (en adelante, Writer); e incluso, respecto a las herramientas bibliográficas de estos programas, evaluando mi decisión final de utilizar Zotero, en vez de esas extensiones nativas.
¿Es la suite ofimática de Microsoft la mejor del mercado?
Esta es, claramente, una pregunta que solo puede ser respondida a partir de las necesidades y percepciones de cada individuo y, tal es la manera mediante la cual yo aquí reacciono ante este tema. Sin embargo, es importante dejar claro que esta no es solo una cuestión de las características técnicas de un programa respecto a otro o, su costo, sino que hay mucho de marketing de por medio, además de un contexto histórico por detrás.
Estamos en una época en la que, debido al nivel de especialización requerido en diferentes profesiones y actividades, necesitamos minimizar costos y esfuerzos para que los procedimientos que realizamos nos permitan alcanzar más rápido y fácilmente nuestros objetivos. Y en el caso de la suite ofimática, entiéndase programas básicos de oficina, como un editor de textos complejos, administrador de hojas de cálculo, creación de diapositivas, etc., no hay excepción. Ante esta situación, es conocido que Microsoft hizo un excelente trabajo posicionando en el mercado su paquetería de oficina y su sistema operativo, a tal punto que el Gobierno norteamericano se vio en la obligación de plantearle una demanda antimonopólio a finales de la década de 1990; pero esa es otra historia. Es importante constatar que, en ese sentido, estamos acostumbrados a nombrar, por ejemplo, a Word, casi como sinónimo de programa manejador de texto; en realidad, incluso hay personas que no saben que existen otras opciones.
El tema es que, existe una fuerte tradición alrededor de Word, es decir, las personas ya están acostumbradas a su funcionalidad y, por otro lado, su interfaz es, evidentemente, atractiva y moderna en comparación al resto de las opciones. Entonces, era de esperarse que, Microsoft, fiel a su estilo, saque ventaja de esto y, en gran medida, a expensas de sus usuarios. Primero, está el hecho de que Microsoft Office no es gratuito, sino que requiere una poco barata licencia de funcionamiento, que sumada a la del sistema operativo en sí, representa un presupuesto no accesible para todos. Por otro lado, a partir de finales de la década de 2000, el software de Microsoft comenzó a crecer respecto al espacio ocupado en disco, además, requiriendo más recursos de hardware, los cuales, si bien, se justificaban de cierta manera por el desarrollo de los nuevos equipos en cuanto a potencia, en contraste, dichos cambios estaban más relacionados con el nuevo auge de la economía de datos, es decir, el tráfico de la información personal de los usuarios, que con mejoras meramente técnicas. En ese sentido, si nos concentramos solamente en Word, como un editor de texto, si bien, atractivo y familiar, en otro sentido, comienza a generar dudas respecto a si está sobrevalorado, tomando en cuenta su precio, requerimiento de recursos y poca transparencia respecto a su política de privacidad en cuanto a los datos de los usuarios.
A esta valoración debe sumarse que las alternativas al software de oficina de Microsoft son varias y, muy buenas, a decir verdad. Por tema de prioridades, me concentraré solamente en tres opciones, que a mi criterio actualmente son las más destacadas del mercado, como alternativa a Microsoft Office. Me refiero a la paquetería de oficina de LibreOffice, a cargo de The Document Foundation; OnlyOffice de Ascensio System SIA y; finalmente, la suite ofimática en línea de Google, asociada a su espacio de almacenamiento Drive, entorno antes llamado Docs, pero que cuya denominación ahora solo hace referencia al procesador de texto de Google. Una transición de nombres algo confusa a decir verdad, porque al final, no se sabe como nombrar a estas herramientas de oficina; aquí en adelante se le dará el nombre de suite ofimática de Google. El orden en el que dispongo estas herramientas al citarlas, representa para mí, también, la valoración que les doy en mi uso personal.
LibreOffice, es la heredera mejorada de la mítica OpenOffice.org, que probablemente fue el primer intento histórico serio de presentar, desde el ámbito del código abierto, una alternativa a las herramientas de oficina de Microsoft. De las opciones nombradas anteriormente, es la más completa en términos de funciones y además la más consolidada, al contar con casi 40 años de desarrollo, si se toma en cuenta las bifurcaciones anteriores sobre las que se sostiene el proyecto, cuya etapa propia tiene poco más de una década. En comparación y, posiblemente como desventaja, se adapta de manera más lenta a los cambios del mercado; además que, en muchos casos, no es tan intuitiva y requiere de mayor esfuerzo del usuario encontrar la manera de utilizar sus herramientas. Actualmente, esta herramienta es gratuita, aunque tiene una versión de pago, denominada LibreOffice Enterprise y, está disponible para instalarla en Windows, macOS y Linux.
La ventaja de OnlyOffice sobre LibreOffice, en general, es que permite hacer ediciones en línea, además de tener un programa de escritorio muy calificado, presentando asimismo una opción de pago que la convierte en un rival muy competente, incluso, ante la suite ofimática de Microsoft, que también opta por ello desde su versión Office 365, además de su tradicional instalación local. Sin embargo, sus funciones no son tan completas como las de LibreOffice y Microsoft. El software de oficina en línea de Google Drive también es básico, pero tiene la ventaja de que puede usarse desde un navegador en todos los sistemas operativos, mientras que en ChromeOS y Android, que al ser sistemas operativos propios de Google, presenta la opción exclusiva de trabajar sin conexión y sincronizarse con la cuenta del usuario, al retomarse el vínculo con la red. Vale apuntar aquí que las herramientas de Google, mayormente, no son de código abierto, aunque son gratuitas y cuentan con una accesibilidad insuperable.
Finalmente, otra importante ventaja de OnlyOffice y Google Drive sobre LibreOffice, es la mejor compatibilidad con documentos DOCX, que son los documentos de texto nativos sobre los que trabaja oficialmente Microsoft Word. Característica muy importante si se toma en cuenta que este es el formato hegemónico en el mercado de documentos de texto avanzado. Sin embargo, considerando que hace ya bastante tiempo estas herramientas representaron una buena competencia para LibreOffice, este programa buscó, de manera deliberada, una mejoría y, en ese sentido, actualmente la compatibilidad de Writer con este formato es también buena, como mostraré a continuación.
Microsoft y su búsqueda del dominio sobre la interoperatividad de formatos
Al hacerse con el mercado de procesadores de texto, Microsoft, de manera extremadamente astuta, eligió, como formato propio de archivo, el denominado DOC, que trabaja bajo la extensión del mismo nombre, es decir, .doc. No es necesario aclarar que esta implementación es cerrada o privativa, en el entendido de que se desarrolla en el marco del secreto institucional de Microsoft y, su documentación, no fue publicada hasta hace poco tiempo, además de ejecutarse en formato binario, por lo tanto, los otros procesadores de texto no podían trabajar de forma interoperativa con este formato. Después de la creación del formato Open Document Text (ODT), que está representado con la extensión .odt, inicialmente bajo el procesador de texto de OpenOffice.org (proyecto ahora bifurcado entre LibreOffice y Apache OpenOffice), se percibió una mejora drástica de la compatibilidad entre los distintos programas ofimáticos del mercado, así que, en la primera década del 2000, el Comité de Telemática entre Administradores (TAC en sus siglas en inglés), con el apoyo de la Unión Europea y gobiernos de distintos países, que habían establecido en sus normativas la necesidad de trabajar con formatos de texto abiertos, presionaron a Microsoft para que se adhiera a los estándares abiertos o, al menos, publique los detalles técnicos que permitan trabajar con sus formatos propietarios, esto tomando en cuenta su posición casi monopólica en el mercado. Microsoft, aparentemente, cedió en este frente, primero, publicando documentación técnica que permita a otros procesadores de texto trabajar con su formato DOC (y el resto de extensiones de su suite ofimática: .xls, .ppt, principalmente). Luego, sorprendentemente, aplicaría una versión propia del estándar abierto Office Open XML (OOXML), a un nuevo formato denominado DOCX, bajo la extensión .docx, pero por supuesto, no de una manera estricta y transparente, como se esperaría, sino adaptado con extensiones privativas, que siguen impidiendo actualmente una conectividad fluida con otros procesadores de texto.
Bueno, pero, en términos prácticos ¿cuáles son las consecuencias técnicas de toda esta historia de versiones y licencias y la reciente postura del Microsoft?, es decir, al momento que se intenta exportar un documento de texto del formato ODT a DOCX, por ejemplo o, viceversa. Recientemente, me hice una idea muy clara del problema. Obviamente, los procesadores de texto trabajan mejor en su formato nativo, ODT, en el caso de LibreOffice; curiosamente, OnlyOffice trabaja con DOCX, de forma predeterminada, de una manera mucho más fiel al estándar abierto OOXML y; finalmente, Google Office maneja su propio renderizado en línea que puede exportarse a varios formatos. El problema es que ninguno de estos procesadores, al exportar un trabajo al formato DOCX, de Microsoft, logra generar un documento que, al abrirse con Word, sea exacto en cuanto a diagramación, sobre todo si el documento es extenso y con características complejas, ni siquiera OnlyOffice, que, como se mencionó, trabaja con este formato también de manera nativa. Esto significa que no puede lograrse una similitud, caracter a caracter, es decir, en la ubicación de las letras asignadas en el espacio de papel virtual del programa.
Entonces, ¿existe alguna solución para exportar de manera fiable un documento DOCX generado en otro procesador de texto, tomando en cuenta la posición hegemónica de Microsoft en el mercado y que, como consecuencia de aquello, varias instituciones exigen documentación oficial en ese formato? De acuerdo a lo que pude explorar, existen soluciones bastante cercanas a la equivalencia, aunque claro, no llegan a ser perfectas y además requieren cierto esfuerzo adicional del usuario. Claramente, Microsoft "jugó bien sus cartas" en su búsqueda del monopolio y, de manera demostrable, trata de hacerle la vida imposible, desde su posición influyente en el mercado, a aquella ilusa persona que no quiere o, no puede, usar sus productos.
La primera solución, creo que es la más adecuada y, consiste en cambiar de enfoque en la búsqueda de la compatibilidad inter-formato. ¿A qué me refiero con esto?, a que, en vez de buscar una equivalencia de caracteres y espacios, entre extensiones, es mejor configurar, adecuada y detalladamente, los estilos de párrafo y caracteres predeterminados del documento, es decir, definir bien su función (nivel de titulación, tipo de párrafo, tipo de interlineado, medidas y especificaciones de salto de párrafo y salto de página, etc.). Si esto se configura correctamente, por un lado, la correspondencia de caracteres y espacios entre el formato de origen y de conversión, no necesariamente será equivalente, sin embargo, la disposición del texto no se verá de forma incorrecta o mal acomodada, que al final de cuentas es lo más importante.
Voy a dar un ejemplo para explicarme mejor. Las normas APA, concretamente, establecen que cada capítulo del escrito debe hacerse al inicio de una nueva página. Entonces, en Writer, se configura que el título de Nivel 1 tenga este comportamiento automático o, en otras palabras, se dispone un salto de página antes del título de cada capítulo. Se selecciona el estilo correspondiente al título de primer nivel o, se crea uno, se da clic derecho, se presiona en Nuevo o Editar estilo ▸ Flujo de texto ▸ Saltos y, ahí se activa Insertar, Tipo: Página; Posición: Antes. Luego, el título de Nivel 2 puede configurarse para que se mantenga unido al párrafo posterior inmediato, en este caso, en estilo Cuerpo de texto. Esto se logra ingresando a Nuevo o Editar estilo ▸ Flujo de texto ▸ Opciones de división y, se activa la función Mantener junto al párrafo siguiente.
De esta manera, cuando la cantidad de líneas de la hoja queden dispuestas de manera tal que, en el caso del título de Nivel 2, esté localizado en la última línea de la hoja, lo cual es incorrecto para la diagramación deseada, el programa automáticamente establezca que se pase a la siguiente hoja y, se mantenga junto a su párrafo de desarrollo. En el caso del título de Nivel 1, esto incluso es más radical, ya que sin importar la posición de párrafo en el que se lo invoque, siempre iniciará en una nueva hoja. Esta determinación es extremadamente útil para la compatibilidad entre formatos, porque si se establece esta regla en el formato ODT, por ejemplo, cuando se lo exporte a DOCX, si bien, como ya se mencionó, los párrafos no se verán idénticos en cuanto a disposición, sin embargo, el nuevo documento no presentará incongruencias de diagramación como las mencionadas. Usualmente, al encontrarse esta mala disposición de títulos, la mayoría de los usuarios realiza saltos de línea manuales y justamente son esos los que tienden a no exportarse bien de un formato a otro. Además de esto, existe buena compatibilidad de características complejas como índices, comentarios e incluso control de cambios.
A continuación, a modo de ilustración, muestro una captura de pantalla de la misma hoja, primero, renderizada por Writer en formato ODT y, segundo, renderizada por Word en formato DOCX, exportado desde ODT:
Captura de pantalla de documento ODT
Captura de pantalla de documento DOCX, importado de ODT
Como puede apreciarse, la ubicación de caracteres no es exacta, en este caso, Word decide trasladar la nota número 3 a la siguiente página, por ejemplo, mientras que Writer la mantiene en la primera; sin embargo, debido a las configuraciones de estilos realizadas, de ninguna manera habrá incongruencias de diagramación como las mencionadas anteriormente.
El segundo enfoque, teóricamente, apuntaría a buscar la exactitud del diagramado, pero, creo que no se debe esperar demasiados avances en esa dirección, ya que, como se expuso anteriormente, Microsoft, de manera deliberada, quiere boicotear los intentos de interoperatividad fluida con su formato privativo. Un primer esfuerzo para lograr esto lo constituye la creación del formato Rich Text Format o formato RTF. Este tipo de documento fue creado por la misma Microsoft en la década de 1980 y, precisamente, estaba destinado a la compatibilidad de los sistemas. En mis pruebas personales constaté que al exportar en este formato, concretamente, desde un documento ODT, la equivalencia de los caracteres puede llegar a ser bastante buena; sin embargo, al hacerse el documento más grande y tener características más complejas, como notas al pie y varios niveles de titulación, el resultado puede llegar a ser peor que el anterior. Esto se debe, probablemente, a que a partir del año 2008, de manera previsible, Microsoft dejó de mantener este formato, siendo la consecuencia directa que varias de las características implementadas a partir de 2010, en los documentos DOCX, ya no eran compatibles en RTF. En otras palabras, este es un formato que si bien, todavía constituye la forma más cercana de mantener una equivalencia en la disposición de un documento de texto exportado a Word, sin embargo, tiene los días contados al ya no poseer soporte oficial. Recomiendo además, encarecidamente, no trabajar sobre documentos RTF y solo utilizarlos para exportar documentos creados con el formato nativo del procesador de texto utilizado. Tuve experiencias desastrosas experimentando con este formato, que a fin de cuentas, solo es un soporte de exportación.
Una segunda forma de buscar la equivalencia total sería trabajar con el formato ODT, directamente en todos los procesadores de texto, el cual es aceptado tanto por Word, como por Google Docs y OnlyOffice; sin embargo, la interoperatividad de este tipo de documento, es, irónicamente y, a pesar de ser una extensión abierta, no tan buena.
Actualmente, creo que lo mejor que se puede hacer es simplemente utilizar la herramienta nativa de exportación de LibreOffice, de ODT a DOCX. Además de aquello, no es mala idea tener a la mano una cuenta de OneDrive, donde Microsoft permite acceder, de manera gratuita, a una versión básica de Word, lo cual es excelente, para revisar detalles de compatibilidad. Antes de redactar el documento, se puede elaborar uno, como el que mostré de ejemplo, que sirva para probar la compatibilidad del estilo. Una vez demostrada la interoperatividad, no habría razones para preocuparse.
Manejo de citas bibliográficas
El manejo de citas bibliográficas en los procesadores de texto avanzando, merece su propio apartado. A diferencia del tema de la interoperatividad de formatos, el de las citas, presenta problemas más comunes entre estos programas, incluido Microsoft Word. A nivel general, creo que la función de citas bibliográficas es más potente en Writer que en Word, además, más ambiciosa, sin embargo, es mucho menos amigable, el usuario debe profundizar en el manual de instrucciones para manejarla, por otro lado, su soporte no parece tan frecuente, ya que comprobé que no corrigen una falla importante desde hace años, la cual se describirá posteriormente.
Tanto Word y Writer permiten introducir citas en el documento, que luego se pueden vincular automáticamente con una lista bibliográfica final; este es el comportamiento básico esperado de esta función y, ambos procesadores la cumplen a cabalidad. El problema, sin embargo, inicia cuando se buscan funciones más complejas, por ejemplo, la posibilidad de trabajar de forma automática con estilos concretos de citas e índices bibliográficos y, la posibilidad de exportar estos listados a otros formatos. En ese sentido, ambos procesadores tienen sus ventajas y desventajas.
La ventaja de Word es que viene con un puñado de normas bibliográficas preconfiguradas, populares internacionalmente (APA, Chicago, IEEE, etc.). El problema surge cuando se requieren otros formatos, como Vancouver, por ejemplo. Hace unos años era posible encontrarlos en una base datos externa denominada BibWord, la cual, actualmente, al parecer ya no existe (su página ya no carga y su sitio de GitHub no es mantenido hace años); parece que la única solución es codificar uno mismo el tema, en formato XLS.
Creo que en este sentido, Writer resuelve mejor el problema ya que, si bien, no presenta la posibilidad de instalar temas, permite personalizarlos en su propia interfaz, así como también añadir campos confeccionados por el usuario, tanto en citas, como en listas bibliográficas; algo que Word no permite. Además y, esto suena genial, presenta la posibilidad de manejar la lista bibliográfica, que se almacena en formato ODB, desde el potente administrador de bases de datos de la suite ofimática, llamado LibreOffice Base (simplemente Base, en adelante). Esto a mí, personalmente, me voló la mente cuando lo descubrí, porque Word, por ejemplo, a duras penas permite exportar la lista bibliográfica en un archivo XML, que si bien, con cierta manipulación, puede convertirse en otros formatos, esto requiere esfuerzo, mientras que una base de datos, manejada por un gestor gráfico, fácilmente se puede convertir en una hoja de cálculo, por ejemplo o, manipular de forma compleja desde la interfaz. Sin embargo, hubo algo que me decepcionó profundamente respecto a esta función, porque tiene un gran bug o, error de software.
Si bien, la función permite vincular esa base de datos con las citas del documento, la actualización automática, en caso de cambiarse algún campo en la base de datos externa, no surte efecto en el documento una vez insertado en él y, a la inversa, alguna modificación hecha en el campo insertado en el documento, tampoco se verá reflejada en la base de datos externa. Es necesario aclarar que esto solo sucede cuando se usa la base de datos externa, es decir, la que permitiría trabajar desde múltiples documentos; las citas de un documento individual funcionan correctamente. Este problema, no solo es decepcionante por lo descrito, sino que, además, el equipo de desarrolladores de LibreOffice decidió no resolverlo desde hace más de una década, al parecer, porque la falla se origina en algún servicio usado por el programa, pero que no es mantenido por el mismo. Algunos especulan que la deficiencia se encuentra en Apache, un servicio del que se vale el programa. Lo que me llamó la atención, fue el comentario de, al parecer, uno de los contribuidores al proyecto, de nombre Heiko Tietze, en la página de manejo de problemas del programa, que ante los cuestionamientos, respecto a la tardanza de la solución de este error, por parte de otro usuario, de nombre o, seudónimo, Mieszko, respondía lo siguiente:
(In reply to Mieszko from comment #10)
6 years later bug still remains It would be better to drop all the bibliography features, than live with that. I wouldn't spend so many hours to manually inserting over 40 of bibliography entries if I new that I cannot update it :(
If you are a heavy bibliography user you may give Zotero or Mendeley a try. See also https://design.blog.documentfoundation.org/2018/12/19/save-the-bibliography/
Pienso que Miesko tiene razón, incluso tomando en cuenta las dificultades por las que atraviesa un proyecto de código abierto en comparación con uno privativo y, además, de gran envergadura, como Microsoft, debería haber mucha más claridad de cara al usuario respecto a los alcances de esa función y no crear falsas expectativas. Por otro lado, es muy curioso que miembros del equipo que desarrolla el software recomienden un programa externo, ante los desperfectos de su propio diseño. Independientemente de lo irónico de esta situación, en contraste, me parece que la respuesta de Heiko Tietze es acertada, porque, evidentemente, si se quiere obtener un software altamente especializado en manejo bibliográfico, automatizado, en un documento profesional de texto, pues, Zotero es una excelente opción, además que es código abierto y su versión gratuita es fenomenal.
En ese entendido, si se quiere trabajar con una herramienta bibliográfica automatizada y, además, compleja, recomiendo evitar trabajar con las prestaciones nativas de Word y Writer e instalarse, directamente Zotero, que es compatible con ambos procesadores de texto. Parece que así lo entendió OnlyOffice, que no tiene una funcionalidad nativa de citas y bibliografía y, más bien, viene con la extensión de Zotero preinstalada; sin embargo, solo se la puede usar con la cuenta en línea de Zotero, que permite crear copias de seguridad de la base de datos e, incluso, documentos digitales guardados en el ordenador, con opciones de pago, que ofrecen incrementar ese espacio de almacenamiento en línea. Me parece una imposición, ya que yo no almaceno mis copias de seguridad en línea, en ese caso, prefiero la manera de Word y Writer, que permiten trabajar de manera local con la extensión de Zotero, además de la versión en línea, por supuesto.
De todas maneras, Zotero es un programa muy potente, muy bien mantenido y con actualizaciones constantes, que no solo permite manejar las citas y listas bibliográficas, con base a una inmensa cantidad de formatos, sino que también, automatiza el proceso de recolección de los metadatos, ya sea de páginas web, PDF's y otros formatos de libros electónicos e, incluso, de libros en formato físico, conectando con catálogos bibliográficos en línea. Por si fuera poco, permite organizar la bibliografía digital almacenada en el ordenador. En suma, son realmente impresionantes las funcionalidades con las que este programa cuenta.
Superación de obstáculos técnicos presentados por LibreOffice Writer
Finalmente, no puedo evitar narrar aquí algunos problemas técnicos que surgieron con Writer al realizar alguna tarea y la forma en la que los resolví desde Debian, que es la distribución Linux con la que trabajo.
Instalación de LibreOffice en Linux
Es importante mantener la versión de LibreOffice actualizada, no solo en términos de seguridad y aprovechamiento de nuevas características, sino también por el uso de mejoras en la compatibilidad con DOCX, porque es bastante frecuente que Microsoft se saque de la manga modificaciones unilaterales a su formato privativo y deteriore la compatibilidad con otros procesadores de texto. Por ejemplo, al lanzar su versión Office 365, realizó transformaciones a su formato; LibreOffice se puso al día rápidamente y ahora diferencia la versión DOCX de 2007 de la 365.
En Linux, a diferencia de Windows, existen múltiples posibilidades de instalación, además de ser bastante seguras todas. La más recomendada, siempre, es la nativa de la distribución utilizada; luego, está la versión Flatpak, que es un sistema de instalación agnóstico para Linux, es decir, un formato de instalación común, más allá de la distribución; luego, está el instalador que a veces proporciona la institución creadora del programa, unas veces en forma de ejecutable agnóstico, otras en forma de repositorios propios para los principales tipos de paquetes de las distribuciones más importantes, usualmente DEB y RPM; finalmente, se puede instalar la versión de una distribución distinta dentro de otra, a partir de un sistema de contenedores, como Podman o Docker; y posiblemente, otras formas de instalación más.
Como mencioné, utilizo Debian, en su versión estable, debido a que requiero de un entorno productivo y sin muchos cambios en el tiempo, sin embargo, no me es conveniente instalarme la versión de LibreOffice del sistema, porque, si bien, tiene mantenimiento de seguridad por parte de Debian, está demasiado desactualizada en términos de funciones. Existen otros programas en los que la relativa antigüedad de versión no me representa un problema, en términos de función, pero este no es el caso. En esta circunstancia, la mejor opción es la que proporciona el propio sistema, pero a partir del repositorio Backports, que es una lista de programas con versiones actualizadas, adaptados para la versión estable. Si no existiera LibreOffice en Debian Backports, la segunda mejor opción es la versión de Flatpak, que es mantenida por los propios desarrolladores del programa. Sin embargo, al existir la versión de Backports y comparar ambas, preferí la de Debian por dos motivos: uno, ocupa menos memoria RAM, debido a que está optimizada para el sistema anfitrión; y otra, se integra mejor con Zotero, aunque a decir verdad, no sé si este último es un problema de la versión Flatpak de LibreOffice o de Zotero.
Para instalar la versión de los Backports, de LibreOffice, hay que seguir un procedimiento que no es muy intuitivo y no está narrado en las instrucciones convencionales de instalación de programas, a partir del repositorio Backports. En la mayoría de los programas, simplemente se fuerza, mediante un comando o, el programa Synaptic, la versión de los Backports, en vez de la estable; sin embargo, al ser LibreOffice un programa bastante complejo y, con múltiples dependencias, hay que instalar, primero, la versión estable del programa y, luego, ejecutar el comando de llamado a paquetes de la versión Backports. Este comando seleccionará paquetes de la versión estable de LibreOffice que deben ser actualizados, ya que en este caso, la actualización aprovecha paquetes antiguos que no necesitan cambiar de versión para funcionar, probablemente en procura de no interferir la estabilidad del sistema.
Entonces, en concreto, primero hay que tener el repositorio Backports configurado adecuadamente, de acuerdo a las instrucciones que se otorgan en su página y, luego, ejecutar los siguientes comandos:
- Instalación convencional de LibreOffice
- Instalación de la versión Backports de LibreOffice
A continuación, hay que ingresar al gestor de software Synaptic y revisar si están instalados los archivos libreoffice-gtk3 y libreoffice-gtk4. Si no lo están, hay que instalarlos y forzarlos a su versión de Backports, entrando a la opción Paquete ▸ Forzar versión, seleccionar la versión de Backports y luego darle al botón Forzar versión. Finalmente, en caso de que se esté migrando de una versión LibreOffice de Flatpak, hay que copiar los archivos que se alojan dentro de la siguiente carpeta: /home/[carpeta de usuario]/.var/app/org.libreoffice.LibreOffice/config/libreoffice/4/user, y pegarlos en : /home/[carpeta de usuario]/.config/libreoffice/4/user
Para la instalación de Flatpak, igualmente, hay que tener correctamente instalado el paquete Flatpak y el repositorio de Flathub, de acuerdo a las instrucciones de su página. Luego, ejecutar los siguientes comandos:
$ flatpak install flathub org.libreoffice.LibreOffice # (1)
$ flatpak run org.libreoffice.LibreOffice # (2)
- Instalación del programa
- Ejecución del programa
Migración entre gestores bibliográficos
Durante la elaboración de mi tesis, que duró años, realicé dos migraciones de bases de datos bibliográficas: la primera, cuando me cambié de Word a Writer y; la segunda, cuando abandoné la herramienta para gestionar citas y bibliografía de Writer y, me pasé a Zotero. En el primer caso, esto se debió, tanto a una motivación técnica, como de principios, que narro en la primera publicación de este blog y, coincide con la migración que realicé del sistema operativo Windows hacia Linux. La segunda migración, obedeció a motivos pragmáticos, aunque también, respetando mis principios relacionados con el código abierto. La Universidad donde estudié el posgrado realizó una re-estandarización hacia las normas APA; yo, había iniciado el trabajo con otras normas de diagramación y citas bibliográficas y, ahora debía readecuarlo a las normas APA. En ese sentido, migrar a Zotero me vino bien, porque no solo la tarea de migrar era más fácil, sino que hacía tiempo ya quería probar esa herramienta y, finalmente, todo salió bien 😅️.
De XML a ODB
Exportar la lista bibliográfica de Word a Writer implica exportar la información de un fichero eXtensible Markup Language (XML), a una hoja de cálculo, que, a su vez, se exportará a una base de datos Open Document Base (ODB). Seguramente, se puede hacer este mismo proceso, en menos pasos, desde la creación de un script de Bash, Python o, no lo sé; sin embargo, esta forma tiene la ventaja de trabajar con herramientas ya construidas para ese fin y, además, más comprensibles para usuarios no informáticos como yo 🙂️.
En el documento de Word donde se haya insertado citas bibliográficas, se debe acudir a la pestaña de Referencias ▸ administrar fuentes, esto abrirá una ventana. Arriba de la sección que dice Lista general, hay que darle al botón Examinar, esto abrirá la siguiente ubicación: C:\Users\[Carpeta de usuario]\AppData\Roaming\Microsoft\Bibliography, donde se encontrará un archivo llamado Sources.xml, ahí es donde está almacenada la base de datos de las fuentes bibliográficas. Este archivo puede trasladarse a una nueva ubicación y debe ser abierto por un gestor de hojas de cálculo. Tanto Microsoft Excel como LibreOffice Calc (en adelante Calc), tienen un importador nativo de archivo XML, para manejar su contenido desde una hoja de cálculo. Aquí se mostrará como hacer esta operación desde Calc. A modo de ejemplo, creé 5 referencias bibliográficas en Microsoft Word, las cuales, al abrirse el archivo XML, desde un editor de texto simple, lucirán de la siguiente forma:
<?xml version="1.0"?>
<b:Sources SelectedStyle="" xmlns:b="http://schemas.openxmlformats.org/officeDocument/2006/bibliography" xmlns="http://schemas.openxmlformats.org/officeDocument/2006/bibliography"><b:Source><b:Tag>Dur79</b:Tag><b:SourceType>ArticleInAPeriodical</b:SourceType><b:Guid>{6AEBBFCA-9DF6-41BF-B180-1BC622C6C865}</b:Guid><b:Title>A la opinión pública</b:Title><b:PeriodicalTitle>El Mundo</b:PeriodicalTitle><b:Year>1979</b:Year><b:Month>Septiembre</b:Month><b:Day>18</b:Day><b:Pages>11</b:Pages><b:Author><b:Author><b:NameList><b:Person><b:Last>Durán</b:Last><b:First>Javier</b:First></b:Person></b:NameList></b:Author></b:Author></b:Source><b:Source><b:Tag>Pre79</b:Tag><b:SourceType>ArticleInAPeriodical</b:SourceType><b:Guid>{425B64D4-4E1B-422A-8DB6-61CAABBEDEB7}</b:Guid><b:Author><b:Author><b:Corporate>Presencia</b:Corporate></b:Author></b:Author><b:Title>Actos vandálicos se repiten en Santa Cruz</b:Title><b:PeriodicalTitle>Presencia</b:PeriodicalTitle><b:Year>1979</b:Year><b:Month>Diciembre</b:Month><b:Day>6</b:Day><b:Pages>2</b:Pages></b:Source><b:Source><b:Tag>ElD78</b:Tag><b:SourceType>ArticleInAPeriodical</b:SourceType><b:Guid>{8767ED84-3D6D-46C9-B0BF-F95E2199F62B}</b:Guid><b:Title>134 millones de US $. costo de los proyectos de hilandería y cemento</b:Title><b:Year>1978</b:Year><b:PeriodicalTitle>El Deber</b:PeriodicalTitle><b:Month>Junio</b:Month><b:Day>20</b:Day><b:Author><b:Author><b:Corporate>El Deber</b:Corporate></b:Author></b:Author><b:Pages>s.p.</b:Pages></b:Source><b:Source><b:Tag>ElM80</b:Tag><b:SourceType>ArticleInAPeriodical</b:SourceType><b:Guid>{E8F8AE9C-88AB-4563-A2DE-8704680501CA}</b:Guid><b:Author><b:Author><b:Corporate>El Mundo</b:Corporate></b:Author></b:Author><b:Title>Acuerdo de autoridades con dirigentes de la Chiquitania: Fábrica de cemento se levantará en Yacuses</b:Title><b:PeriodicalTitle>El Mundo</b:PeriodicalTitle><b:Year>1980</b:Year><b:Month>Febrero</b:Month><b:Day>23</b:Day><b:Pages>7</b:Pages></b:Source><b:Source><b:Tag>Jus80</b:Tag><b:SourceType>ArticleInAPeriodical</b:SourceType><b:Guid>{A168B653-6750-4686-96D8-7C64C79DDEA1}</b:Guid><b:Title>A la presidente Gueiler. A los políticos nacionales. A CORDECRUZ. Al Comité Pro Santa Cruz. Al Comité de la Gran Chiquitania y para que el pueblo cruceño juzgue</b:Title><b:PeriodicalTitle>El Mundo</b:PeriodicalTitle><b:Year>1980</b:Year><b:Month>Marzo</b:Month><b:Day>12</b:Day><b:Pages>6</b:Pages><b:Author><b:Author><b:NameList><b:Person><b:Last>Justinano</b:Last><b:First>Jenikov</b:First></b:Person></b:NameList></b:Author></b:Author></b:Source></b:Sources>
En Calc hay que dirigirse a Datos ▸ Fuente XML ▸ Archivo de origen y dar clic al ícono que muestra una carpeta, esta opción abrirá un administrador de archivos desde el cual hay que dirigirse a la ubicación donde está almacenado el archivo Sources.xml y darle en Abrir. En la ventana hay una sección que dice Asignar al documento, allí hay que reconocer la primera columna de la base de datos, en este caso, abajo de la etiqueta con "@", luego, el programa identifica automáticamente la base de datos. En la sección Celda asignada se escribe A1, luego se aprieta el botón de Importar. Entonces, automáticamente, se tienen importados todos campos de la base de datos bibliográfica y sus datos en una hoja de cálculo, la cual puede guardarse en el formato nativo de LibreOffice, que es Open Document Spreadsheet (ODS). La tabla ahora luce así (nótese que todavía conserva los encabezados XML):
| ns0:Tag | ns0:SourceType | ns0:Guid | ns0:Title | ns0:PeriodicalTitle | ns0:Year | ns0:Month | ns0:Day | ns0:Pages | ns0:Last | ns0:First | ns0:Corporate |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Dur79 | ArticleInAPeriodical | {6AEBBFCA-9DF6-41BF-B180-1BC622C6C865} | A la opinión pública | El Mundo | 1979 | Septiembre | 18 | 11 | Durán | Javier | |
| Pre79 | ArticleInAPeriodical | {425B64D4-4E1B-422A-8DB6-61CAABBEDEB7} | Actos vandálicos se repiten en Santa Cruz | Presencia | 1979 | Diciembre | 6 | 2 | Presencia | ||
| ElD78 | ArticleInAPeriodical | {8767ED84-3D6D-46C9-B0BF-F95E2199F62B} | 134 millones de US $. costo de los proyectos de hilandería y cemento | El Deber | 1978 | Junio | 20 | s.p. | El Deber | ||
| ElM80 | ArticleInAPeriodical | {E8F8AE9C-88AB-4563-A2DE-8704680501CA} | Acuerdo de autoridades con dirigentes de la Chiquitania: Fábrica de cemento se levantará en Yacuses | El Mundo | 1980 | Febrero | 23 | 7 | El Mundo | ||
| Jus80 | ArticleInAPeriodical | {A168B653-6750-4686-96D8-7C64C79DDEA1} | A la presidente Gueiler. A los políticos nacionales. A CORDECRUZ. Al Comité Pro Santa Cruz. Al Comité de la Gran Chiquitania y para que el pueblo cruceño juzgue | El Mundo | 1980 | Marzo | 12 | 6 | Justinano | Jenikov |
Por si eso fuera poco, lo que viene a continuación es todavía más tedioso, pero no imposible de lograr. Hay que tomar una decisión. Writer permite trabajar, no solo con la base de datos bibliográfica predeterminada, sino que también deja agregar otras, creadas de forma separada. En mi caso, por ejemplo, cuando hice la migración de Word, quería tener la bibliografía que iba a formar parte de mi tesis, de forma separada, es decir, en una base de datos distinta a la predeterminada. Entonces, si se quiere trasladar los datos bibliográficos a la base de datos predeterminada, el procedimiento cuenta con menos pasos, debido a que la base de datos ya está creada; la otra opción requiere de más pasos y de cierta sensibilidad, como se apreciará. La base de datos bibliográfica con la que trabaja Writer funciona con el formato nativo de su suite ofimática, que es Open Document Base (ODB), el cual utiliza HSQLDB como motor de base de datos por defecto, pero en este caso, no se usará esa conexión predeterninada, sino que se conectará el archivo ODB a otra base de datos, esta vez, en formato dBASE. Esta pequeña complicación se debe a que tales son las especificaciones bajo las cuales funciona la base de datos bibliográfica de LibreOffice Writer.
En concreto, hay que abrir el archivo /home/[carpeta de usuario]/.config/libreoffice/4/user/database/biblio/biblio.dbf, con Calc y, proceder de la siguiente manera: si se quiere utilizar la base de datos predeterminada, se deben copiar los datos que se obtuvieron del archivo Sources.xml de Word, ahora almacenados en un archivo ODS y, pegarlos donde correspondan, en este caso y, siguiendo con el ejemplo de las 5 referencias bibliográficas exportadas anteriormente desde Word, se las dispone de la siguiente manera:
| Identifier,C,254 | Type,C,254 | Author,M | Journal,M | Month,C,254 | Pages,C,254 | Title,M | Year,C,254 | Custom1,M |
|---|---|---|---|---|---|---|---|---|
| Dur79 | 17 | Durán, Javier | El Mundo | Septiembre | 11 | A la opinión pública | 1979 | 18 |
| Pre79 | 17 | Presencia | Presencia | Diciembre | 2 | Actos vandálicos se repiten en Santa Cruz | 1979 | 6 |
| ElD78 | 17 | El Deber | El Deber | Junio | s.p | 134 millones de US $. costo de los proyectos de hilandería y cemento | 1978 | 20 |
| ElM80 | 17 | El Mundo | El Mundo | Febrero | 7 | Acuerdo de autoridades con dirigentes de la Chiquitania: Fábrica de cemento se levantará en Yacuses | 1980 | 23 |
| Jus80 | 17 | Justinan, Jenikov | El Mundo | Marzo | 6 | A la presidente Gueiler. A los políticos nacionales. A CORDECRUZ. Al Comité Pro Santa Cruz. Al Comité de la Gran Chiquitania y para que el pueblo cruceño juzgue | 1980 | 12 |
En ese ejemplo, por tema del espacio demasiado grande de la tabla, no se muestran todos los campos que contiene la tabla dBASE, sino solo los campos equivalentes a los creados en Word. Como puede apreciarse, en el campo Identifier, concretamente en los datos, se aprovechan los identificadores creados para cada documento, de forma automática, por la herramienta de Word, sin embargo, acá pueden cambiarse de acuerdo a determinaciones propias, debido a que Writer establece que este campo debe rellenarse de forma manual. Por otro lado, en el campo Type, que equivale a "Tipo de documento", se utiliza los números correspondientes a la opción de "Personalizado 1", ya que Writer no posee "Artículo de periódico" en su tipología, que en el caso de las Normas APA tiene su forma específica de referenciado. Esto se configurará en la inserción de la bibliografía al final del trabajo. Writer permite introducir hasta 5 tipos de documento personalizado, además de su lista preconfigurada. Finalmente, se opta por introducir el campo correspondiente a "día", de la fecha de creación del documento, al campo Custom1, ya que Writer, nuevamente, solo tiene las opciones Year y Month, sin embargo, igual que antes, permite introducir hasta 5 campos personalizados.
Si se quiere trabajar con una nueva base de datos, primero hay que crear la carpeta donde se desea que se almacenen los datos bibliográficos, en un archivo bajo la extensión .dbf, que luego se gestionarán a partir de otro archivo, bajo la extensión .odb. Si bien, no es obligatorio, se sugiere que la estructura de almacenado sea la siguiente: en una carpeta, que podría denominarse Base, se generará el archivo ODB, mientras que se crea otra carpeta al interior de la carpeta madre, que podríamos denominarla dBASE, donde se almacenará el archivo en ese formato. De todos modos, si se quiere ver un ejemplo de esta disposición, se lo encuentra en el enlace proporcionado a la carpeta donde se almacena la base de datos predeterminada de Writer. A continuación, se abre Calc y se crea un archivo en formato dBASE, almacenado en la carpeta elegida para ese fin, necesariamente, bajo el sistema de caracteres "Europa occidental (DOS/OS2-850/internacional)", cuando el programa solicite la selección de esta característica. Ahora, para ahorrar tiempo y esfuerzo, se puede aprovechar los títulos de las columnas de la tabla dBASE predeterminada, cuya ubicación se indicó anteriormente y, copiar y pegar esa primera fila en el nuevo archivo dBASE. Luego, se introducen los datos de acuerdo a la disposición mostrada en la anterior tabla. A modo de ejemplo, en esta explicación, se denominará a este archivo ensayo.dbf.
Debe continuarse abriendo LibreOffice Base. Se lanzará un asistente que titula Seleccionar base de datos, bajo la interrogante de ¿qué quiere hacer?, se opta por la opción Conectar con una base de datos existente, de cuya lista desplegable se selecciona dBASE y se presiona en Siguiente. A continuación, mediante el botón Examinar, hay que dirigirse a la ubicación de la carpeta donde está almacenado el archivo dBASE, creado anteriormente. Luego, el programa preguntará si se quiere registrar la base de datos, es necesario que sea así, de lo contrario Writer no la reconocerá y habrá que hacer el procedimiento posteriormente, de manera manual, mediante las opciones generales de LibreOffice. Al apretar el botón Finalizar, el proceso culminará con la creación de un archivo ODB, cuya ubicación debe situarse, preferentemente, de acuerdo a los detalles brindados anteriormente. Como ejemplo, en esta explicación se denomiará a este archivo Ensayo.odb. Entonces, tenemos la carpeta Base en cuyo interior están el archivo Ensayo.odb y la carpeta dBASE, en cuyo interior, a su vez, está el archivo ensayo.dbf.
Ahora y, esto es algo que, lamentablemente, no puede evitarse, probablemente debido a una deficiencia en el desarrollo de Base. Al modificar los datos directamente en el archivo .dbf, desde Calc y, no a través del archivo .odb , manejado por Base o, a través del gestor bibliográfico de Writer, los nombres de los campos de la base de datos modifican todos los caracteres a mayúsculas. Por tanto, lo que se indicará a continuación debe realizarse, ya sea que se haya optado por trabajar con la base bibliográfica predeterminada de Writer o, se haya decidido crear una nueva. Es importante que se abra con Base el archivo .odb, (en este ejemplo, denominado Ensayo.odb, pero de trabajarse con el archivo predeterminado se llama biblio.odb), luego, dirigirse a la sección de Tablas, donde se encontrará la tabla de nombre "ensayo" (o "biblio" en la versión predeterminada), la cual está asociada al archivo .dbf; debe hacerse clic derecho en el nombre y luego en Editar. Allí se encontrará que los nombres de todos los campos están en mayúsculas. Lo que hay que hacer es volver a acomodarlos manualmente a como estaban, de acuerdo a lo que se muestra en la siguiente imagen, como nombres correctos de cada columna. Luego, se abre el gestor bibliográfico de Writer, en la pestaña Herramientas ▸ Base de datos bibliográfica. Una vez hecho esto y, desde el gestor bibliográfico de Writer, se entra a la opción Origen de datos y se selecciona la base de datos bibliográfica, que, si se hizo todo lo anterior correctamente, estará entre las opciones. Aquí, necesariamente, habrá que asociar los campos del gestor bibliográfico con los campos de la base de datos de forma manual, al modo que se muestra en la siguiente imagen. Como se mencionó, esa captura de pantalla también sirve para revisar la forma correcta de nombrar a los campos de la base de datos o nombres de columnas. Eso es todo, se puede comenzar a trabajar con la base de datos.
Entiendo que el anterior procedimiento se muestra pesado, sin embargo, la otra opción es introducir los campos de forma manual en el gestor bibliográfico de Writer, lo cual, en caso de ser demasiadas las entradas, puede resultar aún más molesto y cansador.
De ODB a BibLaTeX y luego a Zotero
El procedimiento para exportar la base de datos bibliográfica de Writer a Zotero, también tiene sus quehaceres. Zotero permite la importación de varios formatos, entre ellos, el menos complejo de obtener, al no haber una herramienta nativa de exportación, es el formato BibLaTeX, el cual, forma parte del fantástico tipo de archivo de texto LaTeX, que posee dos características que son difíciles de encontrarlas juntas en los otros formatos: es al mismo tiempo un archivo de texto plano y, a su vez, permite diagramación compleja. Tomando en cuenta esto, el procedimiento consiste en exportar la base de datos ODB a una hoja de cálculo ODS y, allí, se formatearán los datos mediante las funciones del programa, de acuerdo a los requerimientos de BibLaTeX, para, finalmente, exportar esos datos, a través de un editor de texto simple, a un archivo con extensión .bib, donde se le añadirá una última característica, que no puede incorporarse mediante Calc, como se apreciará más adelante.
Exportar una tabla de ODB a Calc es bastante simple. Se abre Base, en la sección Tablas se busca la tabla bibliográfica, en este caso, ensayo, se le da clic derecho, se elije Copiar, luego, se abre una hoja de Calc y en la celda A1 se pega el contenido del portapapeles, el cual se acomodará automáticamente a la hoja de cálculo. Entonces, siguiendo con el ejemplo de las cinco entradas bibliográficas que se crearon al principio de este tutorial, ahora se observan los siguientes campos y sus datos (nuevamente, no se visualizan todos los campos de la base de datos bibliográfica de Writer, por falta de espacio):
| A | B | C | D | E | F | G | H | I | |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Identifier | Type | Author | Journal | Month | Pages | Title | Year | Custom |
| 2 | Dur79 | 17 | Durán, Javier | El Mundo | Septiembre | 11 | A la opinión pública | 1979 | 18 |
| 3 | Pre79 | 17 | Presencia | Presencia | Diciembre | 2 | Actos vandálicos se repiten en Santa Cruz | 1979 | 6 |
| 4 | ElD78 | 17 | El Deber | El Deber | Junio | s.p | 134 millones de US $. costo de los proyectos de hilandería y cemento | 1978 | 20 |
| 5 | ElM80 | 17 | El Mundo | El Mundo | Febrero | 7 | Acuerdo de autoridades con dirigentes de la Chiquitania: Fábrica de cemento se levantará en Yacuses | 1980 | 23 |
| 6 | Jus80 | 17 | Justinan, Jenikov | El Mundo | Marzo | 6 | A la presidente Gueiler. A los políticos nacionales. A CORDECRUZ. Al Comité Pro Santa Cruz. Al Comité de la Gran Chiquitania y para que el pueblo cruceño juzgue | 1980 | 12 |
Ahora, hay que transformar el formato de fecha, en este caso, separado en tres campos correspondientes a año, mes y día, de acuerdo al formato ISO 8601. Esto se puede realizar, primero, reemplazando la forma manuscrita de mes por el formato de dos dígitos, utilizando, por ejemplo, la función de buscar y reemplazar de Calc y manteniendo, de ser necesario, de forma manual, el formato de celda en modo texto, porque de lo contrario no permitirá introducir números con cero a la izquierda, sin mediación de una coma. Luego, tomando en cuenta la disposición de la anterior tabla, en una columna creada al final de la tabla, se puede ejecutar la siguiente función:
Luego de eliminar las columnas innecesarias, la tabla quedaría con la siguiente disposición:
| A | B | C | D | E | F | G | |
|---|---|---|---|---|---|---|---|
| 1 | Identifier | Type | Author | Journal | Pages | Title | Date |
| 2 | Dur79 | 17 | Durán, Javier | El Mundo | 11 | A la opinión pública | 1979-09-18 |
| 3 | Pre79 | 17 | Presencia | Presencia | 2 | Actos vandálicos se repiten en Santa Cruz | 1979-12-06 |
| 4 | ElD78 | 17 | El Deber | El Deber | s.p | 134 millones de US $. costo de los proyectos de hilandería y cemento | 1978-06-20 |
| 5 | ElM80 | 17 | El Mundo | El Mundo | 7 | Acuerdo de autoridades con dirigentes de la Chiquitania: Fábrica de cemento se levantará en Yacuses | 1980-02-23 |
| 6 | Jus80 | 17 | Justinan, Jenikov | El Mundo | 6 | A la presidente Gueiler. A los políticos nacionales. A CORDECRUZ. Al Comité Pro Santa Cruz. Al Comité de la Gran Chiquitania y para que el pueblo cruceño juzgue | 1980-03-12 |
Continuando, hay que crear una nueva columna al final de la tabla, en este caso, a la derecha inmediata del campo Date y, allí, se realiza el formateo de los datos de acuerdo a BibLaTeX, a partir de la siguiente función:
=CONCATENAR("@article{";A2;",title = {";F2;"},pages = {";E2;"},journaltitle = {";D2;"},author = {{";C2;"}},date = {";G2;"},}")
El contenido de esa última columna debe pegarse, mediante un editor de texto plano, en un archivo con extensión .bib. En este ejemplo, se lo denominará Ensayo.bib. El resultado se verá así:
@article{Dur79,title = {A la opinión pública},pages = {11},journaltitle = {El Mundo},author = {{Durán, Javier }},date = {1979-09-18},}
@article{Pre79,title = {Actos vandálicos se repiten en Santa Cruz},pages = {2},journaltitle = {Presencia},author = {{Presencia}},date = {1979-12-06},}
@article{ElD78,title = {134 millones de US $. costo de los proyectos de hilandería y cemento},pages = {s.p},journaltitle = {El Deber},author = {{El Deber}},date = {1978-06-20},}
@article{ElM80,title = {Acuerdo de autoridades con dirigentes de la Chiquitania: Fábrica de cemento se levantará en Yacuses},pages = {7},journaltitle = {El Mundo},author = {{El Mundo}},date = {1980-02-23},}
@article{Jus80,title = {A la presidente Gueiler. A los políticos nacionales. A CORDECRUZ. Al Comité Pro Santa Cruz. Al Comité de la Gran Chiquitania y para que el pueblo cruceño juzgue},pages = {6},journaltitle = {El Mundo},author = {{Justinan, Jenikov }},date = {1980-03-12},}
Si bien, la información de ese archivo está dispuesta tal cual las exigencias de BibLaTeX, todavía hay una carencia que provocará que Zotero no reconozca los datos. El formato BibLaTeX determina que luego de cada coma, que es precisamente el separador de los campos, también debe haber un salto de línea. Entonces, en el editor de texto, necesariamente, debe usarse la herramienta de buscar y reemplazar y, a su vez, activar el uso de expresiones regulares. En ese entendido, en la sección de búsqueda, se escribe una coma: "," y, en la sección de reemplazo, se establece la siguiente expresión: ",\n", la cual, indica una coma seguida de un salto de línea. Luego de reemplazar todas las coincidencias, el contenido del archivo tendría que quedar así:
@article{Dur79,
title = {A la opinión pública},
pages = {11},
journaltitle = {El Mundo},
author = {{Durán,
Javier }},
date = {1979-09-18},
}
@article{Pre79,
title = {Actos vandálicos se repiten en Santa Cruz},
pages = {2},
journaltitle = {Presencia},
author = {{Presencia}},
date = {1979-12-06},
}
@article{ElD78,
title = {134 millones de US $. costo de los proyectos de hilandería y cemento},
pages = {s.p},
journaltitle = {El Deber},
author = {{El Deber}},
date = {1978-06-20},
}
@article{ElM80,
title = {Acuerdo de autoridades con dirigentes de la Chiquitania: Fábrica de cemento se levantará en Yacuses},
pages = {7},
journaltitle = {El Mundo},
author = {{El Mundo}},
date = {1980-02-23},
}
@article{Jus80,
title = {A la presidente Gueiler. A los políticos nacionales. A CORDECRUZ. Al Comité Pro Santa Cruz. Al Comité de la Gran Chiquitania y para que el pueblo cruceño juzgue},
pages = {6},
journaltitle = {El Mundo},
author = {{Justinan,
Jenikov }},
date = {1980-03-12},
}
Ahora, se abre Zotero y, se ingresa a Archivo ▸ Importar ▸ Un archivo (BibTeX, RIS, Zotero RDF, etc.), donde se abre un explorador de archivos, se elije Ensayo.bib, en este caso y, se le da al botón Abrir. Zotero preguntará si se colocará las entradas importadas en una nueva colección, si se desea eso, se deja activada esa opción, si no, Zotero insertará las entradas a la carpeta que estaba seleccionada previamente, al iniciarse el procedimiento de importación. Se le da Siguiente ▸ Finalizar. Y, listo, puede observarse que Zotero importó correctamente las 5 referencias bibliográficas que se construyeron, a modo de ejemplo, en este tutorial.
Instalación de Zotero en Linux e integración con Writer
Ya que aquí se escribe de Zotero, quiero aprovechar de hacer ciertas recomendaciones, en orden de lograr su adecuada intergración con Writer en Linux. Primero, es muy importante instalarse la versión original de Zotero. Para Linux, Zotero proporciona dos opciones, la primera, el ejecutable agnóstico y, para el caso de Debian y derivadas, un repositorio propio. En mi equipo, yo opté por la segunda opción, ya que, además que está especializada para mi distribución, se integra a las actualizaciones del sistema. Por otro lado, recomiendo, muy enfáticamente, no usar la versión de Flatpak para este caso específico, ya que al no estar mantenida por los desarrolladores oficiales del proyecto, no está configurada adecuadamente para integrarse al sistema y, sobre todo, a Writer.
La extensión de integración de Zotero no viene preinstalada en Writer y, algo que me llamó mucho la atención, es que no solo no se halla en el repositorio de extensiones de LibreOffice, para su descarga, sino que ni siquiera está en la página web del propio Zotero para ese fin 🤨️. Zotero distribuye su extensión para Writer, en un archivo localizado junto a la instalación del propio programa. En el caso de mi instalación, por vía el repositorio DEB, encontré la extensión en: /usr/lib/zotero/integration/libreoffice/Zotero_LibreOffice_Integration.oxt. Al usarse el instalador agnóstico, la extensión seguramente está situada en la carpeta home del usuario. Para instalarla, simplemente hay que ejecutar el archivo Zotero_LibreOffice_Integration.oxt y LibreOffice procederá a instalarla. Para realizar una actualización de la versión de la extensión hay que realizar este mismo procedimiento.
Entonces...
El propósito de esta entrada no es villanizar a Microsoft, aunque exista buen material en sus antecedentes para lograr esa tarea; de hecho, creo que, a pesar de aquello, esa empresa cumple un papel muy importante en el mundo de la ofimática, sobre todo respecto a la innovación y, las variantes del mercado suelen ser más reactivas en este ámbito. En realidad, un momento en el que este rol de Microsoft estuvo amenazado, fue cuando Google lanzó su kit ofimático en línea, ante ese riesgo, Office logró presentar batalla, a través de la imitación, entiéndase, Office 365. En el mundo privado, las acciones de cara a vencer a la competencia, que lleva a cabo Microsoft con sus formatos, están permitidas, siempre y cuando su crecimiento no sea perjudicial para el usuario, en términos de impedir, de manera total, la existencia de otras opciones; aunque esto último haya estado cercano a lograrse y, su reversión, estuvo condicionada a que el Estado presione a esta empresa mediante los juzgados.
En ese sentido, agradezco que haya alternativas, sobre todo de código abierto, frente a la hegemonía de Microsoft, ya que, encuentro que su opción de software de oficina, en este caso, su procesador avanzado de textos, no vale su precio, ni su instalación, tomando en cuenta sus requerimientos excesivos de hardware y su falta de transparencia hacia el usuario, en lo que se refiere al uso de sus datos y potencia del ordenador. Por otro lado, las opciones de código abierto son cada vez más versátiles e, incluso, logran superar eficientemente las barreras de compatibilidad que impone Microsoft, en orden de procurar posicionar su formato como estándar.
Finalmente, entre las soluciones alternativas de código abierto, aquí mencionadas: LibreOffice y OnlyOffice, así como la suite de Google, que no es código abierto, pero es gratuita y fácilmente accesible, considero que Writer satisface mejor mis necesidades, en torno a funciones, confianza y seguridad, por ello la uso como la base de mis operaciones, sin prescindir, sin embargo, de las otras dos e, incluso, de forma marginal, la de Microsoft, (pero esto último solo es debido al uso extendido de su formato privativo).
Espero de alguna manera haber contribuido con este escrito a aquellas personas que atraviesen por problemáticas similares en el uso de procesadores de texto o, tengan dudas sobre cuál escoger para sus quehaceres cotidianos. Saludos.