Índice

• Agradecimientos
• Introducción
• Metodología SSP
• Instalación de herramientas libres
  • Instalación de Zettlr
    • Instalación en Windows
    • Instalación en MacOS
    • Instalación en GNU/Linux
  • Instalación de Scribus
    • Instalación en Windows
    • Instalación en MacOS
    • Instalación en GNU/Linux
• Preparación del proyecto
  • Descarga del dummy
  • Configuración de Zettlr
    • Modificación de las opciones de exportación
    • Modificación de las opciones del proyecto
  • Configuración de Scribus
    • Adición de la plantilla
• Edición del YAML y los Markdown
  • Edición de los metadatos
  • Edición del contenido
• Exportación del HTML y el EPUB
  • Exportación en Zettlr
  • Exportación en la terminal
• Maquetación del PDF
• Apéndice 1. Actualización del proyecto
• Apéndice 2. Control de versiones
• Apéndice 3. Software de uso libre
• Apéndice 4. Estilos de Adjetiva Editorial
  • Encabezado 2
    • Encabezado 3
• Apéndice 5. Elementos adicionales
  • Cite
  • DefinitionList
  • DoubleQuoted
  • HorizontalRule
  • LineBlock
  • LineBreak
  • SingleQuoted
  • Strikeout
  • Subscript
  • Superscript
• Índice analítico
• Colofón

Agradecimientos

Este tutorial no hubiera sido posible sin el financiamiento de Adjetiva Editorial, gracias por apostar por el software libre para la producción de sus libros. Por orden cronológico, agradezco a Mel Bayardo de Programando LIBREros por sus opiniones respecto a la accesibilidad de este tutorial. También doy gracias a libsys de cuatrolibertades por sus comentarios y correcciones al apéndice 3 que trata sobre el software libre.

Introducción

Esta publicación es un tutorial para producir un libro en formato HTML, EPUB y PDF a partir de un archivo Markdown según la metodología de publicación desde una sola fuente y con herramientas que son software libre o de código abierto. El flujo de trabajo es el siguiente:

El tutorial es relevante para las personas interesadas en esta metodología de producción o para quienes desean aprender a hacer libros con software libre pero que no cuentan con un sistema operativo GNU/Linux o no quieren recurrir al uso de una terminal. Si cuentas con experiencia, este tutorial también puede hacerse con tu editor favorito y tu terminal de preferencia sin necesidad de modificar el árbol de directorios o los archivos de configuración.

Este tutorial también es un muestra de las capacidades de este tipo de publicación, por lo que está para consulta en su repositorio o para su evaluación en tres formatos:

• En línea
• En EPUB
• En PDF

Para poder realizar este tutorial necesitas:

1. Una computadora sin importar su sistema operativo
2. Conexión a internet para la descarga del proyecto base y del software necesario

Metodología SSP

Según la entrada de la Wikipedia en español:

La publicación desde una sola fuente (del inglés single-source publishing) o SSP (su acrónimo en inglés) es un método de administración de contenido que permite la publicación ilimitada de un documento en diferentes soportes de medios.

Con la SSP es posible hacer un libro en diversos formatos —como HTML para web, EPUB para ereaders y PDF para impresión— utilizando los mismos archivos y a través de una producción que puede ser automatizada de manera parcial o total. Esta metodología está pensada para hacer más eficiente la administración de contenidos y de los recursos disponibles, ya que pretende publicar un conjunto de formatos que en una metodología convencional de publicación puede llevar a un mayor uso de recursos técnicos o a una pérdida de calidad editorial.

Entonces, quizá una manera de entender qué es la SSP sea a partir de las dificultades que existen en la publicación contemporánea de libros.

1. Redacción
2. Edición
3. Diseño
4. Revisión
5. Impresión
6. Distribución

Antes de la implementación de recursos computacionales en la edición, la reversibilidad en estos procesos tendía a ser costosa o a requerir de cierto ingenio para enmendar errores. Por ejemplo, si en el momento de la impresión se encontraban erratas… alguien podría perder su trabajo o terminar en bancarrota, así como es probable que el editor incorporaría una fe de erratas.

Una de las principales ventajas en esta adopción tecnológica es la capacidad de concentrar varios procesos en una máquina —la computadora— que permite mayor reversibilidad. Por ejemplo, con el uso del desktop publishing es posible concentrar los procesos de redacción, edición, diseño y revisión en un solo programa que, con el cuidado adecuado, permite revertir procesos.

Sin embargo, esta concentración de los procesos implicó un trade-off. Mientras el uso de software en la edición empezó a establecerse como el modelo de producción por defecto, surgió la necesidad de ofrecerle al público otro soporte distinto al impreso: el «libro electrónico».

Con esta necesidad, las personas dedicadas a la producción de publicaciones al menos han tenido que redoblar esfuerzos para la producción de un formato adicional. Para ello, por lo general se lleva a cabo un primer ciclo de producción en el cual se obtiene un PDF para impresión. Después se inicia un nuevo bucle para la producción de un soporte electrónico, como puede ser un archivo en formato EPUB, XML o HTML.

En esta metodología cíclica, cada bucle recicla el documento de un formato anterior. Por ejemplo, varias editoriales reusan el archivo INDD con el que produjeron el PDF de impresión para convertirlo en EPUB.

Esta metodología de publicación ayuda a salvar costos de producción, pero poco o nada contribuye para preservar la calidad técnica y editorial de cada nuevo formato producido. Además, es común que el control técnico disminuya y la calidad editorial sea inferior en cada nuevo bucle porque cada formato tiene especificaciones distintas que en su reuso heredan elementos que pueden producir formatos inválidos o incluso ser perceptibles al lector como erratas.

Por ejemplo, en el INDD para un PDF de impresión de manera rutinaria se añaden saltos de línea forzados para mejorar la estética de algún párrafo. Sin embargo, para un EPUB hecho a partir del INDD estos saltos pueden producir vistas indeseadas ya que su «página» no es un espacio fijo, sino que varía según el tamaño del dispositivo.

Aunque es posible realizar procesos para el control de calidad en cada bucle —como la eliminación de saltos de línea forzados—, por lo general se carece de certeza sobre la calidad final del formato. Por ello es que en Programando LIBREros hemos desistido en este modelo de producción multiformato.

El requisito de una periodicidad semanal o mensual para la publicación multiformato llevó a la industria del software a elaborar metodologías de publicación. Estos flujos de trabajo partieron de sus conocimientos en el manejo de recursos para la compilación de un programa en varios destinos (targets).

Por ejemplo, los programas que utilizaremos en este tutorial (Zettlr, Pandoc y Scribus) son multiplataforma porque están disponibles para Windows, MacOS y GNU/Linux. Sin embargo, esto no quiere decir que tengan una base de código distinta para cada uno de los sistemas operativos donde puede ser utilizado. Al contrario, cada software tiene una sola fuente de código que se compila para diferentes plataformas cada vez que se publica una nueva versión.

De manera análoga a partir de una sola fuente se «compila» el texto en distintos formatos para su impresión, su lectura en un ereader o su disponibilidad en un sitio web. En este flujo de trabajo para la publicación multiformato no hay bucles que reutilicen el contenido de un formato previo para la producción de uno nuevo. En su lugar, la publicación desde una sola fuente (SSP) consiste en un proceso ramificado de producción donde el archivo empleado para la redacción o edición se procesa para distintas salidas.

Las salidas del archivo fuente pueden ser formatos intermedios para la producción de otras salidas o pueden ser un formato para el usuario final. Por ejemplo, una fuente en Markdown puede procesarse para tener un XML que se aloja en un repositorio académico o para la obtención de un HTML, un EPUB o un PDF. Existe más de una posibilidad para pasar de una sola fuente a múltiples formatos, así que el camino a recorrer depende de las necesidades de cada proyecto editorial o de las capacidades de quienes lo realizan.

A esta fuente se le pueden agregar archivos de medios —como imágenes, videos o audios— o fragmentos de texto reutilizables (snippets) —ideales en los paratextos—. Además, mediante identificadores es posible vincular las entradas de una base de datos bibliográfica, lo que evita el uso hard-coded para las referencias y la bibliografía, una fuente común de dificultades por su habitual carencia de uniformidad. Para la estética de los formatos finales es posible emplear plantillas y la especificación del estilo de citas —Citation Style Language (CSL)—. Con el CSL es posible indicar o cambiar el modelo de citación a partir del reemplazo o modificación de un archivo. Por ejemplo, sin la manipulación del contenido el uso de CSL permite que un documento tenga un modelo de citación APA para alguna salida, mientras que para otra puede tener un modelo personalizado de citación.

La metodología para la publicación desde una sola fuente evita el proceso de degradación de un texto en cada bucle, como ocurre en la publicación multiformato convencional, al mismo tiempo que permite la producción automatizada o semiautomatizada de soportes. Sin embargo, en comparación a un proceso de producción de publicaciones afinado durante siglos, la corta edad de la SSP evidencia que aún hay un vasto trabajo por realizar para que este modelo de producción satisfaga la exigencia de la mayoría de las personas que se dedican a la edición o a la autopublicación.

Al menos existen cuatro áreas en donde la SSP requiere de maduración:

1. Experiencia de usuario. Las aplicaciones más robustas de la SSP por lo general carecen de interfaces gráficas, exigen un dominio en el manejo de formatos o implican el conocimiento de varios lenguajes de programación o de marcado. Aún no hay un editor que con un clic produzca los formatos con las expectativas deseadas.
2. Diseño. Por sus orígenes, el diseño para las publicaciones desde una sola fuente se especifica de manera programática. La consecuencia de esto es que las plantillas deben producirse a partir de la estructuración de datos, en lugar de elaborarse según las conveciones de diseño gráfico. Todavía no se cuenta con una capa de abstracción que permita el diseño de plantillas mediante una interfaz gráfica.
3. Adopción de convenciones. Como la SSP implica el manejo de múltiples formatos con uno o más programas de cómputo, no existe una metodología única para la publicación desde una sola fuente. La falta de convenciones en parte se debe a las técnicas disponibles para el desarrollo de software porque posibilitan la bifurcación o la producción de nuevos «estándares» sin que sean adoptados. No hay en la SSP una idea fija sobre la metodología, los programas o los lenguajes aptos para la publicación desde una sola fuente.
4. Manejo de excepciones. De manera inevitable cada formato tiene características que no están presentes en otro, o un usuario puede tener necesidades que no están soportadas en el lenguaje que utiliza para escribir el documento. La solución convencional de estas dificultades se inclina a la adición de preprocesamientos o posprocesamientos de la fuente que hacen más compleja la experiencia del usuario. Se requieren más propuestas que permitan el manejo de excepciones desde la misma fuente.

Este tutorial pretende ofrecerte una solución a las dificultades presentes en la publicación desde una sola fuente. De manera específica, en este documento te ofrecemos una propuesta de aplicación de esta metodología mediante interfaces gráficas y sin la necesidad de contar con un sistema operativo en específico. En Programando LIBREros sabemos que este tutorial no es la respuesta definitiva a las dificultades actuales de la SSP, pero esperamos que satisfaga tus necesidades editoriales o que sirva para que encuentres tus propias soluciones.

Instalación de herramientas libres

Para este tutorial vamos a requerir la instalación de dos herramientas libres:

1. Zettlr
2. Scribus

Zettlr es un editor de Markdown multiplataforma que incluye la navaja suiza para la conversión de documentos: Pandoc. Con Zettlr trabajaremos el tutorial con Markdown para después convertirlo a HTML, EPUB y SLA con Pandoc.

Scribus es un programa de desktop publishing que nos permitirá maquetar el tutorial para tener una salida PDF para impresión. Con Pandoc y Zettlr de manera automatizada podríamos tener una salida PDF mediante TeX, un sistema de composición de textos célebre entre las comunidades de software libre o de código abierto. Sin embargo, para este tutorial optamos por el camino manual que nos ofrece Scribus.

El objetivo de este tutorial es el uso de la metodología SSP con la experiencia de usuario más amena disponible. TeX nos ofrece más posibilidades que Scribus, además de estar respaldado por una amplia comunidad que nos facilita encontrar soporte. No obstante, la metodología para la composición de documentos con TeX dista mucho de la manera habitual en la que se forman documentos para impresión según las pautas del diseño gráfico. Por otro lado, TeX cuenta con una curva de aprendizaje escarpada que no lo hace apto para un primer encuentro con la metodología SSP.

Por estos motivos hemos escogido Scribus. Pese a sus limitaciones, Scribus nos ofrece una interfaz gráfica que rápidamente nos permitirá obtener un ritmo de trabajo afín a los objetivos de este tutorial.

Cabe resaltar que el uso de Scribus no compite con el empleo de TeX. Con Zettlr te darás cuenta que puedes compilar la fuente a PDF/TeX e incluso a IDML para su maquetación con Adobe InDesign. Aunque en este tutorial no cubrimos cómo trabajar la exportación a PDF/TeX o IDML, sí tendrás los elementos necesarios para experimentar y ajustar la exportación por tu propia cuenta.

Instalación de Zettlr

La instalación de Zettlr es muy sencilla, solo tienes que ir a su página de descarga. Aunque si tienes alguna duda, puedes consultar las siguientes secciones.

Instalación en Windows

Para instalar Zettlr en Windows realiza los siguientes pasos:

1. Descarga el archivo EXE WINDOWS (X86_64).
2. Instala el archivo.

Instalación en MacOS

Para instalar Zettlr en MacOS realiza los siguientes pasos:

1. Descarga el archivo DMG INTEL (X86_64).
2. Instala el archivo.

brew install --cask Zettlr

Instalación en GNU/Linux

Debido a que la instalación de Zettlr en GNU/Linux depende del tipo de distribución, aquí solo explicamos el método que funciona para cualquier distribución:

1. Descarga el archivo AppImage APPIMAGE (X86_64).
2. Ve al directorio donde está el archivo desde tu terminal.
3. Da permiso de ejecución al archivo con chmod a+x Zettlr*.AppImage.
4. Ejecuta con ./Zettlr*.AppImage.

Instalación de Scribus

La instalación de Scribus 1.5.x es muy sencilla, solo tienes que ir a su página de descarga. Aunque si tienes alguna duda, puedes consultar las siguientes secciones.

Instalación en Windows

Para instalar Scribus en Windows realiza los siguientes pasos:

1. Ve a su repositorio.
2. Descarga el archivo EXE que termina con windows-x64.exe.
3. Instala el archivo.

Instalación en MacOS

Para instalar Scribus en MacOS realiza los siguientes pasos:

1. Ve a su repositorio.
2. Descarga el archivo DMG que termina con .dmg.
3. Instala el archivo.

Instalación en GNU/Linux

Aunque en su repositorio esta disponible el código para su compilación. Las maneras más sencillas para instalar Scribus son las siguientes.

sudo apt install scribus

Si cuentas con Arch Linux, en tu terminal ejecuta:

sudo pacman install scribus

scribus --never-splash

Preparación del proyecto

Para la producción de los formatos HTML, EPUB y PDF de este tutorial necesitaremos descargar el dummy, así como configurar Zettlr y Scribus. Este es el proceso más delicado que haremos: de su correcta ejecución depende que nuestros formatos tengan las características deseadas. Por fortuna es un procedimiento que solo requiere clics.

Descarga del dummy

El dummy es un proyecto base que nos permite trabajar este tutorial o cualquier otra publicación que quieras hacer con este flujo de trabajo. Para su descarga haz lo siguiente:

1. Descarga este tutorial en ZIP.
2. Descomprime el archivo tutorial-ssp-no-masters.zip.
3. Entra a la carpeta tutorial-ssp-no-masters.
4. Copia la carpeta dummy.
5. Pega la carpeta dummy en donde desees alojar tu proyecto.
6. Renombra la carpeta dummy; por convención le llamaremos librito en este tutorial.

git clone --depth 1 https://gitlab.com/prolibreros/docs/tutorial-ssp.git

El dummy cuenta con esta estructura:

dummy
├── metadata.yaml
├── sec01.md
└── static
    ├── css
    ├── defaults
    ├── filters
    ├── fonts
    ├── img
    │   └── portada.jpg
    ├── scripts
    └── templates

Los archivos que trabajaremos son metadata.yaml y los Markdown, como la sección de ejemplo llamada sec01.md. En el directorio static se encuentran los archivos adicionales de nuestro proyecto. En la carpeta static/img se coloca cualquier imagen que incluyas en tu publicación, como la portada.

El resto de las carpetas dentro de static solo son relevantes para el funcionamiento de Zettlr, Pandoc o Scribus, así que no es necesario que las conozcas a detalle. No obstante, si por algún motivo deseas experimentar con la producción del HTML, EPUB o PDF, siente la libertad de jugar con los archivos dentro de static. Cualquier cambio puede ser revertido.

Configuración de Zettlr

La configuración de Zettlr consiste en dos tareas:

1. Modificación de las opciones de exportación. Esto nos permite producir el HTML, el EPUB y el proyecto de Scribus a partir de nuestro proyecto escrito con Markdown.
2. Modificación de las opciones del proyecto. Esto nos sirve para especificar particularidades del proyecto como el título de la publicación y las salidas de exportación.

Modificación de las opciones de exportación

Para las expotaciones, Zettlr utiliza archivos de configuración de Pandoc que se conocen como defaults. Los defaults son los valores por defecto para la exportación de Pandoc. Para este tutorial los modificaremos para obtener las tres salidas deseadas (el HTML, el EPUB y el proyecto de Scribus).

Para comenzar, en Zettlr:

1. Ve a Archivo > Preferencias > Gestor de recursos.
2. Selecciona la pestaña Exportar de la ventana flotante.

En la ventana abierta modificaremos las opciones de exportación para HTML, Plain Text y RTF. Por defecto Zettlr no cuenta con opciones de exportación para EPUB o proyectos de Scribus. Por este motivo haremos dos pequeños hacks:

1. La exportación RTF se usa para la exportación del EPUB.
2. La exportación Plain Text se usa para la exportación del proyecto de Scribus.

Las nuevas opciones de exportación están en la carpeta static/defaults de nuestro librito y son las siguientes:

• default.html para la exportación del HTML
• default.epub para la exportación del EPUB
• default.sla para la exportación del proyecto de Scribus

Para añadirlas a Zettlr hacemos lo siguiente:

1. Copia el contenido de default.html en HTML y da clic en Guardar.
2. Copia el contenido de default.epub en RTF y da clic en Guardar.
3. Copia el contenido de default.sla en Plain Text y da clic en Guardar.

Ahora puedes cerrar la ventana flotante del gestor de recursos. Con esto terminamos las modificaciones de las opciones de exportación de Zettlr y pasamos a configurar el proyecto del librito.

Modificación de las opciones del proyecto

Para hacer las modificaciones del proyecto en Zettlr abriremos el librito como un área de trabajo. Para ello en Zettlr:

1. Ve a Archivo > Abrir área de trabajo….
2. Selecciona la carpeta librito.

A continuación abrimos las propiedades del área de trabajo de librito con:

1. Da clic derecho en librito.
2. Da clic en la opción Propiedades.

Con las propiedades abiertas, configuramos el área de trabajo del librito con:

1. Da clic en Configuración del proyecto….
2. Nombra tu publicación en la opción Project Title de la ventana flotante.
3. Selecciona los formatos HTML, Plain Text y RichText Format.
4. Cierra la ventana flotante.

Con esto terminamos las configuraciones de Zettlr y pasamos a configurar Scribus.

Configuración de Scribus

La configuración de Scribus consiste en una tarea:

1. Adición de la plantilla. Esto nos permite maquetar el PDF con estilos similares a los que se usan en el HTML y el EPUB.

Adición de la plantilla

Para la maquetación, Scribus permite el uso de plantillas que simplifican el trabajo de diseño. Por defecto Scribus cuenta con varias plantillas disponibles. Sin embargo, para este caso vamos a añadir una nueva plantilla que corresponde con el estilo de los otros formatos de salida.

Para comenzar, en Scribus:

1. Ve a Archivo > Preferencias.
2. Selecciona la pestaña Rutas de la ventana flotante.

En la ventana abierta veremos la ruta que Scribus utiliza para guardar las plantillas. Si no tiene ninguna seleccionada, escoge una.

~/.local/share/scribus/templates

Ahora en tu explorador de archivos:

1. Copia la carpeta static/templates/scribus de tu librito.
2. Pega esta carpeta en tu ruta a las plantillas de Scribus.
3. Renombra la carpeta scribus a adjetiva.

Para corroborar que la plantilla fue añadida, reinicia Scribus y después:

1. Ve a Archivo > Nuevo desde plantilla.

Si fue añadida, deberías ver la plantilla de Adjetiva Editorial como una de las opciones.

Con esto terminamos la preparación del proyecto y pasamos a editar nuestro librito.

Edición del YAML y los Markdown

Edición de los metadatos

Los metadatos de un libro describen la información sobre la obra como su título, colaboradores, fecha de publicación o cantidad de ediciones. Los metadatos son relevantes para la identificación del archivo y son útiles para localizar la publicación cuando está indexada en una biblioteca, base de datos o motor de búsqueda.

Para nuestro librito escribiremos sus metadatos en formato YAML en el archivo metadata.yaml. YAML es un lenguaje para la notación de objetos que Pandoc y Zettlr usan para la escritura de los metadatos de una publicación. Para comenzar en Zettlr:

1. Ve a Archivo > Abrir área de trabajo….
2. Selecciona la carpeta librito.
3. Da clic sobre el nombre librito ubicado en el panel izquierdo.
4. Da clic sobre el archivo metadata.yaml.

En general un archivo YAML se compone de la declaración de uno o más objetos, también conocidos como registros. Cada objeto es un par clave-valor, en donde

• la clave (key) identifica al registro y
• el valor (value) es la información del registro.

En YAML un par clave-valor se registra con la siguiente sintaxis:

clave: valor

Por ejemplo, en metadata.yaml el título del librito se registra en:

title: Un título

En la mayoría de los casos los metadatos del librito se declaran con esa sintaxis. Sin embargo, hay registros que requieren un conjunto de información. Para esos casos la sintaxis es:

clave:
- ítem 1
- ítem 2
- ítem 3

Por ejemplo, en metadata.yaml las palabras clave del librito se registran en:

keywords:
- palabra clave 1
- otra palabra clave

En otros casos la información del registro puede a su vez contener más pares clave-valor. Para estos casos, la sintaxis es:

clave:
  una_clave: valor 1
  otra_clave: valor 2

Por ejemplo, en metadata.yaml los ISBN del librito se registran en:

isbn:
  web: 978-607-99-8760-2
  ebook: 978-607-99-8760-2
  print: 978-607-99-8760-2

Para evitar errores de procesamiento, cuando el valor de un registro contiene dos puntos (:) o HTML, la sintaxis de este valor se escapa con comillas simples ('):

clave: 'valor con dos puntos: y <b>HTML</b>'

Por ejemplo, en metadata.yaml los datos de producción y del directorio del librito se registran en:

made-in: 'Hecho en México · <i>Made in Mexico</i>'
directory:
- 'Autor: Juan Pérez'
- 'Editora: Juana Pérez'
- 'Diseño de portada: Paco'

Por último, el caso más complejo de registro en metadata.yaml es para el metadato del EPUB que se usa para registrar a los creadores. Este registro es un conjunto en donde cada ítem está compuesto por las claves role y text que se usan para indicar el rol y nombre de cada creador. Su sintaxis es:

creator:
- role: author
  text: Juan Pérez
- role: editor
  text: Juana Pérez
- role: cover-designer
  text: Paco

Por fortuna, no tienes que adentrarte mucho en la sintaxis del formato YAML. Solo requieres modificar los registros con tu información, eliminar los que no necesites, o copiar y pegar más ítems para los registros que son conjuntos. Si todos tienen sintaxis correcta, los registros van a ser utilizados como metadatos para nuestro librito.

La modificación de metadatos puedes hacerla en cualquier momento durante el proceso de edición, solo recuerda exportar el proyecto para implementar los cambios. Ahora podemos seguir con la edición de los contenidos.

Edición del contenido

Para la fuente de nuestro libro vamos a utilizar Markdown, un lenguaje de marcado ligero cuya filosofía es:

• Fácil de leer
• Fácil de escribir
• Fácil de procesar

Markdown es un formato de archivo abierto, por lo que puede trabajarse en cualquier editor de texto o de código.

Sin embargo, por conveniencia vamos a utlizar Zettlr, un programa libre para la edición de Markdown.

Para comenzar en Zettlr:

1. Ve a Archivo > Abrir área de trabajo….
2. Selecciona la carpeta librito.
3. Da clic sobre el nombre librito ubicado en el panel izquierdo.
4. Da clic sobre el archivo sec01.

Exportación del HTML y el EPUB

La exportación del librito puede hacerse en Zettlr o en la terminal de tu preferencia. En esta sección se describe cómo llevarlo acabo en ambas interfaces.

Exportación en Zettlr

En la interfaz de Zettlr la exportación es posible porque bajo el capote tiene Pandoc, un programa libre para la conversión de documentos.

El EPUB puede subirse a las tiendas de Google, Apple y Amazon, así como puede convertirse para Kindle —a través de Kindle Previewer— si se quiere ofrecer el librito afuera de Amazon. El HTML es para cotejo rápido y, si se desea, para tener el librito en un micrositio web, como este tutorial. El SLA es para hacer la maquetación del PDF en el siguiente apartado.

Para exportar los formatos en Zettlr:

1. Ve a Archivo > Abrir área de trabajo….
2. Selecciona la carpeta librito.
3. Da clic derecho sobre el nombre librito ubicado en el panel izquierdo.
4. Selecciona Exportar proyecto.

Después de unos segundos, en el explorador de archivos y dentro de la carpeta de tu librito verás 6 archivos nuevos:

librito
├── librito.html
├── librito.rtf
├── librito.txt
├── log.epub
├── log.html
├── log.sla
...

Los archivos log.* son las bitácoras de exportación de cada formato. Estos archivos son útiles para depurar errores en la exportación así que vale la pena conservarlos.

Los archivos en formato HTML, RTF y TXT corresponden a la publicación en HTML, EPUB y SLA —proyecto de Scribus—. Para mi caso estos archivos tienen por nombre librito.*. Para tu caso sus nombres corresponden al título de tu publicación.

Si recuerdas, en la configuración de Zettlr utilizamos la exportación RTF para colocar la configuración de exportación para el EPUB, así como la exportación Plain Text se usó para la configuración de exportación del proyecto de Scribus. Por estos hacks, en tu explorador de archivos:

1. Renombra la extensión .rtf de tu librito a .epub.
2. Renombra la extensión .txt de tu librito a .sla.

Con estos cambios ya puedes ver tu librito en tu explorador web de preferencia si desde ahí abres el archivo HTML. También puedes ver el EPUB en tu ereader.

Este proceso puedes repetirlo cuantas veces sean necesarias. Cuando la edición haya terminado y los resultados de la exportación sean los esperados, es momento de continuar con la maquetación de nuestro librito.

Exportación en la terminal

Si has trabajado el librito en tu editor de preferencia en lugar de Zettlr, puedes exportar la fuente en tu terminal. Para este proceso es necesario que tengas instalado Pandoc.

Para exportar, en tu terminal:

1. Escribe cd (con el espacio al final).
2. Arrastra la carpeta del librito a la terminal y da Enter.
3. Ejecuta ./static/scripts/make.sh.

El archivo que se ejecuta, make.sh, es un script que realiza las operaciones necesarias con Pandoc para producir las salidas. Las exportaciones solo requieren la ejecución de ese script, por lo que su producción en la terminal es lo más ameno posible.

Después de unos segundos, en tu terminal verás 6 archivos nuevos si haces ls:

librito
├── log.epub
├── log.html
├── log.sla
...
├── pub.html
├── pub.rtf
├── pub.txt
...

Los archivos log.* son las bitácoras de exportación de cada formato. Estos archivos son útiles para depurar errores en la exportación así que vale la pena conservarlos.

Los archivos en formato HTML, EPUB y SLA —proyecto de Scribus— son las salidas de tu librito. Por defecto todos tienen por nombre pub.*.

El script make.sh ofrece algunas opciones —como asignar un nombre de salida distinto a pub.*— que puedes leerlas si ejecutas con la opción -h:

./static/scripts/make.sh -h

Si los resultados no te satisfacen, siente la libertad de modificar el uso de Pandoc en el script. Cualquier cambio puede ser revertido.

Maquetación del PDF

La última salida de este tutorial es un PDF hecho con Scribus, un programa libre de maquetación.

Apéndice 1. Actualización del proyecto

Cada proyecto hecho con este tutorial empieza con un proyecto base llamado «dummy». El dummy cuenta con una carpeta static en el que hay archivos necesarios para la producción de nuestros formatos.

Estos archivos están en continua mejora, para poder incorporarlos se tiene que actualizar el proyecto. La actualización también funciona en caso de que se necesiten revertir los cambios realizados a los archivos dentro de static.

Para actualizar el proyecto haz lo siguiente:

1. Entra a la carpeta de tu proyecto.
2. Respalda la carpeta static/img afuera de la carpeta static.
3. Elimina la carpeta static.
4. Descarga este tutorial en ZIP.
5. Descomprime el archivo tutorial-ssp-no-masters.zip.
6. Entra a la carpeta tutorial-ssp-no-masters/dummy.
7. Copia la carpeta static.
8. Pega esta carpeta dentro de tu proyecto.
9. Mueve la carpeta img respaldada dentro de static.

git clone --depth 1 https://gitlab.com/prolibreros/docs/tutorial-ssp.git

El resultado final debe ser una nueva carpeta static en tu proyecto que adentro tiene la carpeta img con tus imágenes.

Con esto terminamos la actualización y ahora puedes exportar tu proyecto para implementar los cambios.

Apéndice 2. Control de versiones

Aquí se explica el uso básico de Git.

Apéndice 3. Software de uso libre

Las herramientas que usamos en este tutorial (Zettlr, Pandoc y Scribus) son software libre. Si eres una persona que de manera profesional se dedica a la edición de libros, podría causarte interés o sospecha la posibilidad de hacer libros con calidad editorial sin Adobe ni Microsoft Office. Algunas de las preguntas que podrías tener son:

• ¿Qué es el software libre?
• ¿Cuáles son las posibilidades y los límites del software libre?
• ¿Cuál es la conveniencia de usar herramientas que son software libre?

La libertad en el uso de software se entiende de distintas maneras. La primera de ellas es comprender al software libre como un programa que permite la distribución de forma gratuita (freeware).

Si bien es usual que el software libre sea distribuído gratuitamente, es relevante hacer la distinción respecto al freeware. Las licencias de software libre exigen tener el código fuente disponible, mientras que en el freeware es suficiente con tener disponible el programa ejecutable (código máquina).

La diferencia entre el código fuente y el código máquina es que en la gran mayoría de los casos el código fuente está escrito en algún lenguaje de programación. Estos lenguajes están pensados para ser inteligibles por humanos. Antes de los lenguajes de programación, el software se programaba con ceros y unos, una representación que era difícil de escribir, entender, mantener y arreglar.

El freeware solo tiene disponible el código máquina para su ejecución, por lo que es difícil de modificar o auditar. Por lo general esto es conveniente para el desarrollador de freeware, ya que le permite implementar características indeseables para el usuario, como el uso de publicidad, el monitero de su actividad o la instalación de software malicioso (malware). Cuando un programa gratuito es además software libre, estas características indeseables son fáciles de detectar y corregir porque su código fuente permite el escrutinio.

Aunque el software libre suele estar disponible de manera gratuita por internet, su gratuidad no es requisito para considerarse libre. El software libre puede ser gratuito o de pago, pero su usuario siempre debe contar con el derecho de compartirlo libremente, además de otras libertades que se describen más adelante.

En el ejercicio habitual de desarrollo y uso de software son poco perceptibles las diferencias entre el código abierto y el software libre. En ambos tipos de programas se cuenta con el código fuente disponible y con licencias de uso que permiten su estudio, modificación, reutilización o distribución sin costo adicional y sin la anuencia por escrito del titular de los derechos.

Sin embargo, existe una diferencia filosófica en su definición que tiene repercusiones económicas, políticas y sociales. Para el movimiento comunitario del software libre la libertad de los usuarios respecto al software es un imperativo ético. Mientras tanto, la iniciativa del código abierto tiene el objetivo de atraer a las empresas al software libre, por lo que su énfasis está en su sentido práctico —disponibilidad del código fuente— y no en la libertad —sustento a un ecosistema de tecnologías libres—.

Las licencias de software libre y de código abierto suelen ser las mismas. No obstante, el énfasis comercial de la iniciativa del código abierto provoca que las empresas mezclen el código fuente con software no libre, en desmedro de la libertad de los usuarios.

Un ejemplo permite aclarar esta diferencia. Android es quizá el programa de código abierto más popular en la actualidad. La disponibilidad de su código fuente permite que los operadores de telecomunicaciones o los fabricantes de teléfonos ofrezcan sistemas operativos Android con modificaciones. Este es el motivo por el que los teléfonos Android comparten muchas características entre sí al mismo tiempo que tienen sus especificidades como las apps preinstaladas o la estética del sistema.

La gran mayoría de estos operadores o fabricantes no tienen disponible el código fuente de las modificaciones que le han hecho al sistema base de Android porque su licencia le permite reservarlo para distribución propietaria. Aunque esto se justifica como modelo de negocio o competitividad empresarial, la consecuencia es que vuelve muy difícil la auditoría de estos sistemas. Esta falta de certeza provoca la sospecha del daño potencial que se podría ocasionar al usuario de Android, principalmente en lo que se refiere al monitoreo de su actividad.

Para poder garantizar que el software libre continúe siéndolo después de ser modificado, el movimiento del software libre usa un mecanismo llamado copyleft, que implica la herencia de la licencia en cualquier obra derivada. Este mecanismo se usa para contrarrestar estas consecuencias que atentan al ecosistema de tecnologías libres. Aunque en un primer momento es paradójico —el copyleft no te da la libertad de publicar tus programas derivados con la licencia que te venga en gana—, la lógica es la siguiente: para garantizar la libertad de todos los usuarios de software, y así fomentar un ecosistema, es necesario asegurar que las libertades no sean removidas en su reutilización; por lo tanto, las licencias de software libre con copyleft exigen que sus programas derivados sean publicados con la misma licencia.

En la actualidad existen una gran cantidad de licencias con copyleft. Algunas están diseñadas para el software, otras para base de datos u obras artísticas. Zettlr está licenciado con GPL versión 3, mientras que Pandoc y Scribus se encuentran licenciados con GPL versión 2, ambas versiones son licencias copyleft y los tres programas que se utilizan en este tutorial son software libre.

El software propietario son los programas que no tienen disponible su código fuente y que prohíben cualquier modificación o redistribución de sus ejecutables. Para la comercialización del código máquina al usuario se le ofrece:

• pago único como Affinity Publisher;
• modelo de suscripción como Adobe InDesign, o
• modelo freemium como Canva —el usuario tiene acceso gratuito pero limitado al menos que pague por ser premium—.

Aunque la distinción es funcional, un matiz es necesario. Una gran cantidad de software propietario depende del software libre para su ejecución. Esto se debe a que los programas de software libre en varias ocasiones son usados como bibliotecas para los programas propietarios. Con esto se busca la reducción en la carga de trabajo al delegar ciertas funciones del programa a sus bibliotecas. Por ello, la contraposición entre software propietario y software libre tiene sentido desde el punto de vista del usuario, pero se matiza desde la perspectiva del desarrollador que usa las bibliotecas para su programa propietario.

1. Libertad de uso
2. Libertad de estudio
3. Libertad de distribución
4. Libertad de mejora

Estas 4 libertades es lo que garantiza que un programa sea software libre ya que para su ejercicio pleno se requiere del acceso a su código fuente y a las licencias que permitan la modificación o distribución del programa, unas normas distintas al freeware y al software propietario. El énfasis ético en torno a las libertades del usuario sobre el código fuente es lo que distingue al software libre del código abierto.

De manera personal prefiero simplificar las 4 libertades a la primera. Por un lado, el estudio, distribución y mejora de un programa son ejercicios que se dan en el uso del software. Por el otro, esto permite hacer patente que la noción de «libertad» en el software es muy concreta: la libertad es en relación con el uso del software. Esto permite aclarar por qué, aunque la filosofía del software libre aspira a un entendimiento de la libertad como «sociedades libres», en la práctica y en lo legal la libertad queda delimitada a los usos del software. Quizá para evitar mayores ambigüedades en la intelección de la libertad en el contexto del software sea más puntual hablar de «software libre de uso» o «software de uso libre» que de «software libre».

Para que un programa sea considerado software libre —o para que un producto cultural sea libre— se requiere la adición de una licencia que garantice su uso según las 4 libertades. Esta licencia no se opone al derecho de autor, sino que lo flexibiliza. En un ejercicio ordinario del derecho de autor la persona autora tiene todos los derechos reservados sobre su obra. Cuando esta publica con una licencia libre no pierde los derechos sobre su obra, sino que se reserva algunos derechos —por lo general son el derecho de atribución y otros derechos morales—.

Los demás derechos, como el de uso, copia, modificación o distribución son permitidos para cualquier persona. Este traslado de «todos los derechos reservados» a «algunos derechos reservados» permite que el usuario pueda usar libremente una obra sin que peligre el patrimonio del autor.

En el movimiento de la cultura libre la persona autora aún tiene capacidad de decidir el destino de su obra, así como puede tener mecanismos de retribución. Pensar que el licenciamiento libre hace que el autor regale su trabajo es un mito recurrente entre las personas o las entidades que ven en los ideales de la cultura libre una amenaza a su sustento de vida o a su modelo de negocio.

Para la producción de libros con software estas libertades fomentan un ecosistema con tecnologías disponibles sin necesidad de un pago y que pueden ser amoldadas según los intereses u objetivos de un proyecto editorial. Esto quiere decir que en la edición con software libre se tiene la oportunidad de elegir cómo ejecutar un proyecto editorial, en lugar de delimitarlo a las posibilidades que nos ofrece algún programa o compañía.

Una ventaja adicional en el uso de herramientas libres es que estas tienden a consumir menos recursos. Por lo general un programa libre tiene un tamaño de archivo menor y necesita menos memoria RAM o CPU para trabajar. Gracias a esto no hay necesidad de adquirir equipo de cómputo o de contar con una máquina potente para hacer una publicación con calidad editorial.

Uno de los prejuicios sobre el software libre es la suposición de que sus programas son de menor calidad en relación con los programas propietarios. No obstante, como se mencionó con anterioridad, la gran mayoría del software propietario usa el software libre como biblioteca debido a su fiabilidad. La cuestión tal vez tiene su origen a dos carencias recurrentes en los programas libres destinados al usuario final:

1. Una experiencia de usuario poco grata
2. Un entorno gráfico menos atractivo

No obstante, de manera paulatina el software libre está ganando su lugar en el usuario final. Para quienes desean hacer publicaciones con herramientas libres todavía hay mucho camino por recorrer, aunque las bases ya están presentes: flujos de trabajo eficaces, comunidades que dan soporte incondicional, además de herramientas potentes y de gran calidad.

Apéndice 4. Estilos de Adjetiva Editorial

Cuerpo de texto. Consectetuer adipiscing elit. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Quisque vel erat eget diam consectetuer iaculis. Cras ante velit, suscipit et, porta tempus, dignissim quis, magna. Vivamus viverra, turpis nec rhoncus ultricies, diam turpis eleifend nisl, a eleifend ante felis ac sapien. Integer bibendum. Suspendisse in mi non neque bibendum convallis. Suspendisse potenti. Sed sit amet purus at felis adipiscing aliquam. Vivamus et nisl sit amet mauris aliquet molestie. Integer tortor massa, aliquam a, lacinia nonummy, sagittis nec, eros. Nunc non mauris id eros venenatis adipiscing. Cras et lectus ut nisl pharetra ornare. Proin leo risus, elementum eget, ultrices vitae, molestie sed, erat. Curabitur et lectus in tellus egestas hendrerit. Sed dapibus ipsum. Quisque sit amet ligula. Suspendisse odio dolor, semper id, feugiat quis, sodales id, mauris. Curabitur id ligula ac libero malesuada pharetra.

Encabezado 2

Bloque de cita. Cras ut mi sit amet quam consequat consequat. Aenean ut lectus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Suspendisse vel sapien. Nullam non turpis. Pellentesque elementum pharetra ligula. In rhoncus. Aliquam vel enim consequat sem aliquet hendrerit. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nam felis.

Unas itálicas. Cursus vel, sagittis a, dolor. Nullam turpis lacus, ultrices vel, sagittis vitae, dapibus vel, elit. Suspendisse auctor, sapien et suscipit tempor, turpis enim consequat sem, eu dictum nunc lorem at massa. Pellentesque scelerisque purus. Etiam sed enim. Maecenas sed tortor id turpis consequat consequat. Curabitur fringilla. Sed risus wisi, dictum a, sagittis nec, luctus ac, neque. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Sed nibh neque, aliquam ut, sagittis id, gravida et, est. Aenean consectetuer pretium enim.

Encabezado 3

Unas negritas. Nunc vulputate leo id urna. Donec dictum. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Suspendisse dictum, magna consectetuer hendrerit volutpat, sapien felis faucibus justo, ac dictum lacus pede in metus. Nam commodo. Sed consequat, leo pretium sagittis congue, ante nunc laoreet nisl, ac aliquam risus tellus commodo elit. Cras at elit. Pellentesque suscipit erat vitae mauris.

• Lista no numerada. Vivamus neque velit, ornare vitae, tempor vel, ultrices et, wisi.
  • Segundo nivel. Phasellus nunc turpis, cursus non, rhoncus vitae, sollicitudin vel, velit.
• Cras pede. Vivamus suscipit lorem sed felis. Vestibulum vestibulum ultrices turpis.

Unas itálicas con negritas. Lorem ipsum dolor sit amet, elit. Praesent ornare nulla nec justo. Sed nec risus ac risus fermentum vestibulum. Etiam viverra viverra sem. Etiam molestie mi quis metus hendrerit tristique.

Encabezado 4

Unas versalitas. Suspendisse potenti. Cras ut mi sit amet quam consequat consequat. Aenean ut lectus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Suspendisse vel sapien. Nullam non turpis. Pellentesque elementum pharetra ligula. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Nam felis.

1. Lista numerada. Vivamus neque velit, ornare vitae, tempor vel, ultrices et, wisi. Cras pede.
   1. Segundo nivel. Phasellus nunc turpis, cursus non, rhoncus vitae, sollicitudin vel, velit.
2. Vivamus suscipit lorem sed felis.

Unas versales. Vestibulum vestibulum ultrices turpis. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Praesent ornare nulla nec justo. Sed nec risus ac risus fermentum vestibulum. Etiam viverra viverra sem. Etiam molestie mi quis metus hendrerit tristique.

Encabezado 5

Un resaltado. Vivamus neque velit, ornare vitae, tempor vel, ultrices et, wisi.² Cras pede. Phasellus nunc turpis, cursus non, rhoncus vitae, sollicitudin vel, velit. Vivamus suscipit lorem sed felis.³ Vestibulum vestibulum ultrices turpis. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Praesent ornare nulla nec justo. Sed nec risus ac risus fermentum vestibulum. Etiam viverra viverra sem. Etiam molestie mi quis metus hendrerit tristique.

Encabezado 6

Una fórmula matemática embebida:

Una fórmula matemática en la misma línea: .

Aquí es posible tener las tablas nativas como son las tablas embebidas en Scribus. Esta tabla nativa se puede usar en Scribus para sus tablas nativas aunque el estilo difiere significativamente.

Apéndice 5. Elementos adicionales

A continuación se muestras elementos adicionales de la sintaxis Markdown soportada por Pandoc que no aparece en el resto del documento.

Cite

Citado (id1?; id2?; id3?)

DefinitionList

Término 1

Definición 1

Término 2 con marcado en línea

Primer párrafo de la definición del término 2

{ línea de código como segundo párrafo de la definición del término 2 }

Tercer párrafo de la definición del término 2.

DoubleQuoted

‘’Entrecomillado inglés’’

HorizontalRule

LineBlock

LineBreak

Corte
de línea

SingleQuoted

‘Entrecomillado simple’

Strikeout

Tachado

Subscript

_Subíndice

Superscript

^Superíndice

Índice analítico

Colofón

Una prueba.⁴

sh test