Tema 0: Las BBPP de LARdT: Teoría y Conceptos

Coco se ha puesto la bata de profesor y se ha empeñado en que le dejemos dar una charla teórica sobre las BBPP LARdT (“Las Buenas Prácticas de LARdT para un ePUB decente”).
Y Coco puede llegar a ser muy insistente así que allá va. Esperamos que sea de vuestro interés, este programa de “PAPYRE STREET”.

0.- ¿POR QUÉ EL FORMATO ePUB?

Los PDFs son estupendos y se utilizan para un montón de cosas; el FB2 es practico, poseedor de una arquitectura sencilla pero flexible y potente al mismo tiempo; y sobre todo tiene herramientas que permiten tanto la generación (BOOK DESIGNER) como la lectura (COOLREADER) de libros electrónicos de gran calidad. Pero el único formato libre, soportado por la industria como estándar para el libro electrónico es el ePUB. Por eso, para ser un buen ebook tendrá que ser ePUB. En el conjunto de estándares y procedimientos recogidos en las BBPP LARdT, ebook y ePUB son términos sinónimos.


1.- ¿POR QÚE LAS BUENAS PRÁCTICAS DE LARDT PARA UN EPUB DECENTE?

Porque la calidad general de los ePUBs que circulan por ahí, es en general, tan deficiente que te amargan la lectura del contenido. Pero no sólo se trata de los archivos generados por los particulares. Sorprendentemente, la industria no parece haber realizado ningún esfuerzo en explorar las posibilidades del nuevo medio. En el mejor de los casos, se intenta hacer una copia lo más fiel posible del original en papel. Pero aunque esto se logre normalmente no es lo adecuado. Es tan inadecuado que la calidad de la “experiencia de lectura” se degrada mucho.
Y es que un libro en una pantalla de tinta electrónica de 6”, es muy distinto que en su soporte original en papel. Y por eso, se hace necesario re-examinar las convenciones habituales de publicación. En cierto sentido, es necesario crear un nuevo “lenguaje” para el nuevo medio.
Las BBPP LARdT se han ido creando, de forma evolutiva para mejorar la calidad de la experiencia de lectura. No son la única forma de hacer las cosas; y encontrareis partes que son muy mejorables, ya sea por que estarán muy determinados por el conjunto de herramientas que se utilizan y pueden perder validez en otros escenarios diferentes; o por que se han creado de forma histórica y evolutiva. Pero al menos, son un conjunto de prácticas que intentan mantener cierta coherencia y unidad de propósito.

Las diferencias entre un libro en papel y un libro en tinta-electrónica

Los libros convencionales se pueden hojear; y en ese sentido tienen “3 dimensiones”, tienen profundidad. Esta profundidad hace posible que de un sólo golpe de vista se capte la estructura y diseño visual del libro. La maquetación es muy eficiente como medio para transmitir meta-contenido. No sólo funciona como formato, sino que puede funcionar como transmisor de contenido.
Ej.: Un libro que utilice una numeración absurda para los capítulos (Cap. 1, 3, 5, 7, 2, 4, 6, 8…). 
En un libro en papel, tras la sorpresa inicial, de un simple hojeo percibiremos cierta “estructura” dentro del aparente desorden y supondremos que esa numeración significa algo, tiene una razón de ser y aporta contenido/significado a la historia.
Sin embargo, en un libro-e, lo más probable es que pensemos que se trata de un error de numeración, porque no es posible “hojear”. Es mucho más difícil percibir ese tipo de cosas. No posee la “visibilidad” del libro convencional. Y sobre todo, la página. En el libro tradicional, la página es el ladrillo fundamental que compone su estructura visual. En el libro en tinta-e, en realidad, no existe como elemento de dimensión fija. Sólo por este motivo, resulta evidente la necesidad de un tratamiento distinto.

Consecuencias y principios generales a nivel de contexto
Esto implica que si deseamos mantener una “experiencia de lectura” equiparable, tendremos que tenerlo en cuenta; y aplicar criterios de formato distintos.
¿Cuales?
Pues, la idea general a nivel de contexto es:

- mantener en lo posible los criterios y prácticas utilizados en el libro tradicional; y que están avalados por el uso; para beneficiarnos de que son fácilmente identificables; de que resultan conocidos (Ej.: respetar al máximo las convenciones tipográficas establecidas por la industria: guionado, entrecomillados,…)
- pero al mismo tiempo innovar en todo aquello que no resulte práctico u operativo en un entorno de tinta-e.

Ejemplos de criterios innovados: el “nuevo lenguaje”

- La repetibilidad (el que las mismas cosas sean siempre presentadas de igual forma) facilita el reconocimiento y la visibilidad. Por eso, se intenta modelizar el libro y sus componentes: dividirlo en componentes identificados a los que se les procura dar siempre el mismo tratamiento. Por ejemplo, la tipificación de los diferentes tipos de cabeceras de capítulo (“Romano + Texto”, “Número + Texto", …) y la aplicación a los mismos, del formato con “caja”.
- Los espacios y líneas en blanco son un poderoso elemento de formato en el libro en papel. Sin embargo, en el libro en tinta-e, al carecer del “hojeo”, de  “vista de pájaro”; dicen mucho menos; y obligan a multiplicar los avances de página. Resulta evidente que el libro-e tiene “horror al vacío”.
- Las llamadas de las notas al final tienen en el menor tamaño posible en el libro tradicional para no interrumpir el texto. En el libro en tinta-e deben aumentar de tamaño, e incluso ser mas grandes que el cuerpo del texto si queremos que tengan un uso práctico.
- El control de versiones: en el libro Gutenberg las buenas ediciones mantienen un “control de versiones” (ediciones críticas, ediciones definitivas, etc…). Es evidente que en el libro electrónico por su naturaleza informática se hace muy necesario un control de versiones lo más estricto y eficiente posible.  Las BBPP LARdT, implementan un doble control de versiones. Por un lado, una versión del libro completo, registrando en formato de fecha la primera edición ePUB del libro y la versión corriente (aaaammdd). Pero además, se controla la versión “informática” del libro asociada al nombre de la hoja de estilos CSS (BBPPLARdTvN_nnnvar.css). Por ejemplo, “BBPPLARdTv1_171LEA.css” es la versión 1.171 en la variante LEA, que se refiere a que utiliza la fuente LEANDER para los Títulos y epígrafes de parte y capítulo.
El objetivo de este doble control de versiones es facilitar la mejora del formato del libro de forma independiente a las modificaciones en su contenido.

2.- PRESUPUESTOS PREVIOS Y METODOLOGÍA.
En términos generales, cuando estemos hablando de cómo crear un libro ePUB según las BBPP LARdT, s

siempre partiremos de un escenario en el que tenemos un texto en un formato digital cualquiera distinto de ePUB y lo convertimos, mejorándolo en el proceso. En la descripción del procedimiento vamos a modelizar la realidad distinguiendo 3 FASES, (aunque podríamos haber elegido cualquier otro número). Hay que tener en cuenta que estas fases dependen de las herramientas concretas y maneras de trabajar que utilizamos, así que pueden considerarse otros distintos.
— Pre–proceso: tareas previas o preparatorias a la conversión al formato ePUB. Generalmente, hasta terminar la preparación del un HTML FILTRADO con el texto del libro.
— Procesamiento o Prensa ePUB: utilizaremos nuestro HTML filtrado como input del programa ToDoePUB. Después de la ejecución del programa con la aplicación de los “RegEx de las BBPP”; ToDoePUB producirá un archivo ePUB perfectamente válido aunque le faltan algunos retoques finales.
— Pos–proceso: Abriremos nuestro ePUB en SIGIL para aplicar esos retoques finales y ajustes con vistas a alcanzar el nivel de calidad deseado. Estos retoques serán la fase de pos-proceso que terminará con un archivo ePUB con todos los detalles de calidad incluidos en la versión vigente de las BBPP LARdT.

El objetivo ideal debería ser reducir la fase de pos-proceso (es la más “manual”, por lo tanto consume tiempo y puede generar errores) mediante la automatización de la implementación de las BBPP LARdT en el programa ToDoePUB


3.- ¿CUALES BUENAS PRÁCTICAS SE IMPLEMENTEAN EN LAS “BBPP LARDT PARA UN EPUB DECENTE”?

Al final las BBPP, son eso, BUENAS PRÁCTICAS, a aplicar de forma repetible y consistente para asegurar unos mínimos de calidad y usabilidad en el libro ePUB.

Temas a tener en cuenta dentro del CUERPO DEL TEXTO

- EL USO CORRECTO DE LOS GUIONES (LARGOS y CORTOS):  

Lo primero es dejar claro qué símbolos tipográficos deben usarse.

Está el guión largo que se expresará con la ENTIDAD XHTML “MDASH” (guión con un ancho equivalente a la “m”).
— —
Está el guión corto que se expresará con la ENTIDAD XHTML “NDASH” (guión con un ancho equivalente a la letra “n”)
– –
Está el “menos”, el signo de la resta que se expresará con la ENTIDAD XHTML “MINUS”
− −

Aplicaremos la norma habitual de uso de la industria tipográfica. El guión largo MDASH se usará:
- para indicar el cambio de interlocutor en los diálogos, independientemente de que corresponda iniciar un párrafo o no.
- para indicar una oración subordinada, sustituyendo el uso de paréntesis.  Es decir, lo que pudiera ir entre paréntesis, debe ir entre guiones.
El guión de apertura y cierre van inmediatamente antes y después de la palabra que anteceden o siguen. Es decir, pegados, o sea sin espacio entre el guión y la palabra.

QUEDAN MUCHOS más temas, pero ya se nos ha acabado el tiempo por hoy, así que terminamos como siempre en “PAPYRE STREET”:

Y recordad, niños, esto es CERCA y esto es LEJOS

Leed más en BBPP LARdT v1.0, BBPP LARdT v1.14, BBPP LARdT v1.15

Reglas “oficiales” para crear el “Orden de autor” para los nombres complicados: ordena tu biblioteca como un profesional.

Dentro del ISSN (Estándar internacional para Número Internacional  Normalizado de Publicaciones Seriadas) se incluyen los criterios de conversión (“inversión”) para los autores con  nombres complicados.

Los apellidos con partículas
Que en este caso se refiere a los artículos determinados y no al carbón activado. 
En Español, se posponen las preposiciones que preceden a los apellidos; vayan solas, acompañadas del articulo o sean contracciones de preposición y artículo:

Miguel de Cervantes Saavedra         Cervantes Saavedra, Miguel de
Vicente de la Fuente                      Fuente, Vicente de la
Ramón del Valle-Inclán                   Valle-Inclán, Ramón del
Eugenio d'Ors                               Ors, Eugenio d'

El artículo, si no lleva preposición, aparece siempre en primer lugar,
independientemente de que vaya separado, unido o enlazado al apellido:

Modesto La fuente                       La fuente, Modesto
Modesto Lafuente                        Lafuente, Modesto
Modesto La Fuente                      La Fuente, Modesto
Modesto La-Fuente                      La-Fuente, Modesto

Se comenzará también por el artículo, aunque vaya precedido de
preposición, si el artículo va unido o enlazado al nombre, o éste va en mayúscula:

José de Laserna                        Laserna, José de
Rafael de La-Hoz                       La-Hoz, Rafael de
Diego de Las Muelas                  Las Muelas, Diego de

Francés

Se empieza siempre por el artículo (le, la l', les, un une, des) y la contracción de preposición y artículo (du, au ; des, aux):

Jean de la Fontaine                   La Fontaine, Jean de
Fhilippe de L'Espinoy                  L'espinoy, Philippe de
Jean Baptiste du Hamel              Du Hamel, Jean Baptiste

Si la preposición va sola, se comienza por la parte del nombre que la sigue:

Guy de Maupasant                   Maupasant, Guy de
Charles de Gaulle                     Gaulle, Charles de

Inglés

Se empieza siempre por la preposición o el artículo:

Olivia de Havilland                    De Havilland, Olivia
Miriam Allen de Ford                 De Ford, Miriam Allen
John dos Passos                      Dos Passos, John
John le Carré                          Le Carré, John

Alemán   
Se empieza por la parte del nombre que siga a las partículas cuando se trate de preposición o una preposición y un artículo separado:

Max von Sydow                      Sydow, Max von
Karl Gustav von Platen             Platen, Karl Gustav von
Ludwing van Beethoven           Beethoven, Ludwing van
Friedrich von der Hagen           Hagen, Friedrich von der

Pero si se trata de una contracción de artículo y preposición será ésta
quien inicie la entrada:

Johnn Gofried am Ende            Am Ende, Johan Gofried
Karl zum Winkel                     Zum Winkel, Karl

Portugués

 
S

e empieza por la parte del nombre que siga a la partícula:


Joao dos Santos                      Santos, Joao dos
Julio Concelao da Fernandes     Fernandes, Julio Concelao da

Italiano

Para autores modernos se anteponen las partículas, ya sean artículo, preposición o contracción de ambos:

Niccólo lo Savio                        Lo Savio, Niccólo de
Alessandro D'Ancona                 D’Ancona, Alessandro
Giovanni Battista de Rosi            De Rosi, Giovanni Battista
 

Se exceptúan las cpartículas de, d', dei, degli, de l’, que indican origen noble y
acompañan a los apellidos italianos que han vivido antes del siglo XIX:
Lorenzo de Medici                    Medici, Lorenzo de

Apellidos con términos de parentesco

Los portugueses (fiho, junior, neto, sobrinho) se sitúan después del apellido:

Hugo Andrade de Sousa Junior    Sousa Junior, Hugo Andrade de 

En lengua inglesa los téminos que indican parentesco o relación familiar (Mac, Mc, O', Fitz, A') se anteponen al apellido:

Laurence O'Connor                   O'Connor, Laurence

En alfabetos no latinos las partículas que indican relación de parentesco son Abu (padre), Ibn (hijo), Ben (nieto de), siempre se sitúan antes del apellido:

Muhammad Abu Zahra             Abu Zahra, Muhammad

Más arreglos con RegEx (Expresiones Regulares) después de la conversión desde PDF a un ePUB para Mi PAPYRE 6.1 reader

Como ya sabéis, los PDFs dan para mucho cuando de convertirlos a ePUB se trata, sobre todo por el tipo de “zurraspas” que nos quedan antes de lograr un ebook decente. Ya hemos comentado varios ejemplos en este BLOG (aquí y también aquí)  pero viendo estos ejemplos no he podido resistirme a preguntarle a Coco y compartir sus soluciones.

Todo lo que siempre quiso saber sobre el formato ePUB de sus ebooks y nunca se atrevió a preguntar (Cap. 03)

Estábamos explicando el detalle de lo que hay dentro

de un ePUB en el

Capítulo 02

de la serie. Un archivo ePUB viene a ser algo parecido a esto:

ePUB File:.    
│     mimetype   
│
├───META-INF    
│    container.xml      
│               
└───OEBPS       
      │    content.opf    
      │    toc.ncx            
      │       
      ├───Images 
      │      img0001.jpeg 
      │      img0002.jpeg
      │         …... 
      │      img0007.png    
      │ 
      ├───Styles 
      │      style001.css 
      │ 
      └───Text  
             content001.xhtml 
             content002.xhtml 
             content003.xhtml  
                     ...       
             content026.xhtml 
             content027.xhtml 
             content028.xhtml 

Y habíamos terminado de describir que es y para que vale el archivo “content.opf”.

Así pues, retomamos la explicación sobre:

La estructura y contenido de un fichero ePUB

Nos habiamos quedado a punto de comentar el archivo
- toc.ncx: que como indica su nombre controla la tabla de contenidos (índice) del libro. Controla lo que se muestra en el panel izquierdo (generalmente) de los programas de lectura (CALIBRE, LUCIFOX, ADE, etc…)



 
El uid debe coincidir con el registrado en “content.opf”.
doctitle: lo contenido por esta etiqueta aparecerá como título del libro en el programa de lectura, aunque no coincida con lo registrado en los metadatos de “content.opf”.
La etiqueta navpoint marca el listado de capítulos, siendo el nombre del capítulo, el texto adjunto y el src (source) el archivo vinculado que incluye el contenido de ese capítulo.
El atributo “playOrder” de la etiqueta navpoint indica el orden de lectura que ese capítulo supone en el hilo narrativo del libro.

Curiosamente, según las especificaciones el “id” de un capítulo puede ser cualquiera cosa, pero evidentemente será mucho más fácil darle el mismo “id” (identificador único) que ya usamos para el archivo que contiene el capítulo en el fichero “content.opf” (ver Capítulo 02) para evitar liarse.
Además, algún programa de lectura es posible que no muestre correctamente el índice o TOC del libro; o simplemente se vuelva loco si los “id”s no coinciden en los 2 archivos (toc.ncx y content.opf)

También es de Perogrullo pero los valores de playorder tienen que estar en orden. (Un ítem con playorder 1 siempre deberá estar antes que el ítem con el playorder 2)
Tampoco son aconsejables los “huecos” en el playorder, generan errores de aplicación durante la lectura.

- styles.css: puedes usar una hoja de estilo CSS para formatear la presentación de estilo de tu libro.

  Pero el archivo debe estar listado en el manifiesto de “content.opf” o no funcionará. 
 

 

- archivos xhtml: son el texto del libro, el contenido; y deben ser documentos XML 1.1. Puedes tener tantos archivos como capítulos (o más) o tener el libro entero en 1 sólo archivo con marcadores que indiquen la separación de los capítulos. Evidentemente, es mejor que coincida con la división en capítulos.

y básicamente, esto es lo más importante que hay que saber sobre en archivo ePUB.
Parece más complicado de lo que es en realidad.

Y recordad, niños, esto es CERCA y esto es LEJOS

Todo lo que siempre quiso saber sobre el formato ePUB de sus ebooks y nunca se atrevió a preguntar (Cap. 02)

La estructura y contenido de un fichero ePUB
En Todo lo que siempre quiso saber sobre el formato ePUB (Cap. 01) empezabamos a analizar en detalle el contenido de un archivo ePUB. Veamos la estructura en detalle:

ePUB File:.    
│     mimetype   
│
├───META-INF    
│    container.xml      
│               
└───OEBPS       
      │    content.opf    
      │    toc.ncx            
      │       
      ├───Images 
      │      img0001.jpeg 
      │      img0002.jpeg
      │         …... 
      │      img0007.png    
      │ 
      ├───Styles 
      │      style001.css 
      │ 
      └───Text  
             content001.xhtml 
             content002.xhtml 
             content003.xhtml  
                     ...       
             content026.xhtml 
             content027.xhtml 
             content028.xhtml 

     

He cogido un libro cualquiera y lo he destripado. Y Coco nos va a ir contando que es cada cosa: 
Por cierto, los nombres de los archivos distinguen entre mayusculas y minusculas, asi que ojito. 
el archivo mimetype

Es un archivo de texto que como su propio nombre indica declara explicitamente que el archivo es un ePUB y no otra cosa. Dentro contiene SIEMPRE una única frase:

"application/epub+zip"

que sirve para que el sistema operativo no se confunda y crea que es otra cosa en lugar de un archivo ePUB (por ejemplo un archivo ZIP). Para que funcione, este archivo tiene que estar situado el primero de la lista (físicamente, dentro del contenedor) y además sin comprimir, para que pueda ser leído por el sistema operativo o la aplicación de lectura sin dificultades.

el directorio META-INF

Este directorio contiene el archivo “container.xml” que indica a la aplicación de lectura dónde se encuentra el texto del libro, indicando la ubicación del archivo “content.opf”. Este directorio es identico para cualquier libro ePUB.


 

 

directorio OEBPS


Como podeis ver es LA UBICACIÓN RECOMENDADA (no deja de ser curiosa esta relajación del estándar; las especificaciones de IDPF no obligan a que el libro esté aquí dentro pero hay lectores que no funcionan si no lo encuentran en este directorio) para el contenido del libro, incluyendo las imágenes en su directorio correspondiente.


Puedes ubicar el contenido del libro en otro sitio, siempre y cuando indiques en el archivo “container.xml” donde queda situado “content.opf”, que a su vez desarrolla el detalle de dónde están los componentes del libro.


Dentro de OEBPS tendremos:


             - Directorio images: con los archivos gráficos (portada, ilustraciones, …) del libro.

             - Content.opf: este archivo XML debe recoger una lista de todos los archivos incluidos en nuestro contenedor ePUB (y EL ORDEN en el que van); y muy importante, los metadatos (autor, género, …) 
Veamoslo en contexto:


 
Podría tener cualquier otro nombre, siempre y cuando esto se refleje en “container.xml”. De hecho, los ebooks procedentes de FEEDBOOKS, tienen como “firma” característica ciertas variantes sobre la estructura ePUB común. Una de estas diferencias es llamar al fichero que hace el papel de “content.opf”, “fb.opf”

Los metadatos

Son esa información que sirve para distinguir entre un ePUB hecho con cariño y otro hecho “a lo que salga”; además de ofrecer información sobre el libro contenido en nuestro archivo ePUB. Y se encuentran DENTRO del fichero “container.xml”. Los que no pueden faltar son: 
dc:title – Título del libro


dc:language – Idioma del libro, según la codificación de la lista RFC 3066. dc:identifier – Código identificador único del archivo ePUB. Cada fichero ePUB tendrá uno distinto (distintos ePUBs sobre el mismo libro, distintos ids). Normamente es generado por el programa dónde cambiamos de formato nuestros ebooks; pero si generamos un ePUB desde cero, sería una buena práctica incluir el ISBN como parte del código.


Puede haber muchas clases de metadatos posibles; que recogen todo tipo de información sobre la obra literaria incluida en nuestro ePUB.

El manifiesto

Como vemos en la imagen, otro contenido típico del archivo “content.opf” es el manifest, que es una lista (sin orden estricto) de los archivos contenidos en el ePUB, con una declaración del tipo de archivo que es cada uno. (image, xhtml, text,…)


Además a cada archivo se le asigna un identificador que se utiliza en la sección “spine”.


 
La espina (“

spine”), es la parte del archivo dónde se establece el orden de lectura de los archivos que forman el contenido del libro y que venía listados desde el “manifest”.


No es necesario incluir TODOS los archivos en la espina; únicamente lo que se necesite para establecer un orden de lectura correcto. (por ejemplo, no se suele incluir los archivos de imagen).





Resumiendo, “container.xml” nos dice donde está “content.opf”; y en “content.opf” encontramos, la lista de TODOS los archivos que componen el libro (contenido: texto e imagen, formato: estilos CSS, estructura: TOC, etc…) en el manifiesto; y en la espina el ORDEN NECESARIO para una LECTURA CORRECTA del libro. Y de propina, los metadatos, que no tienen que ver con archivos, sino que son atributos (caracteristicas) de la entidad “libro”.





Y lo demás, lo vemos a ir dejando para el capítulo 3.

Y recordad, niños, esto es CERCA y esto es LEJOS

Arreglando la conversión de un PDF en libro ePUB para Mi PAPYRE 6.1 reader ¡con muchas notas a pie de libro!

Para hacer la conversión del título “Corsarios de Levante” partimos de un PDF que está protegido por lo que no ha sido posible realizar las tareas de pre-proceso (recortar pies y cabeceras, revisar el reflow, etc…) típicas para conseguir una conversión sin muchos problemas. Ha sido necesario por tanto depurar pies y cabeceras que aparecían mezclados en mitad del texto y otros errores típicos en estos casos de los que ya hemos hablado en este BLOG. Pero este libro se caracteriza además por incluir casi 100 notas a pie de libro (añadidas por el editor digital de la versión PDF, no por el autor original) que aclaran muchos de los términos marineros y militares del relato. Como mejoran bastante la experiencia de lectura me parecía necesario incluirlas en la versión ePUB.

Gestionando un montón de notas

En el archivo PDF, las notas aparecen originalmente como se muestra en la foto, pero después de la conversión, como podéis comprobar aparecen simplemente como un número “pegado” a la palabra en cuestión. Un auténtico desastre multiplicado por cien.


Así que se impone utilizar RegEx para arreglar este entuerto.
Empezamos a buscar una expresión de búsqueda que nos encuentre todas las ocurrencias y nada más que las ocurrencias relacionadas con este error.
Necesitamos una expresión que encuentre palabras terminadas en un número y con un espacio o signo de puntuación a continuación. Desgraciadamente si no delimitamos cuantos números estamos buscando, la expresión nos encontrará también, cosas como nombres de estilo CSS (“calibre9”, por ejemplo). Así que lo partimos en 2 tandas, primero buscaremos 1 a 1 las palabras terminadas en un digito (las notas del 1 al 9), y reemplazaremos 1 a 1 excluyendo las otras cosas que podamos encontrar; y luego ya podremos de un sólo golpe reemplazar las notas del 10 al 95 ya que no se confunden con ninguna otra cosa.

La expresión de sustitución tendrá que incluir el código para convertir ese número en una nota dentro del texto. Así pues:

Como siempre, si pulsáis en la imagen accederéis al código. 
¡Ale-hop! y …
 
es decir, donde antes ponía:

bajando la entena1.
ahora queda:

bajando la entena. <a title="[1]" href="#_ftn1" id="_ftnref1" name="_ftnref1"><span class="MsoPie">[1]</span></a>

Pero no hemos terminado ni mucho menos. Al final del libro nos quedan varias

páginas con el texto aclaratorio de las notas (son 95) que tendremos que vincular a las notas situadas dentro del texto. El problema es que para cada nota, después de copiar-pegar el código tendríamos que realizar al menos 5 modificaciones (1 para cada vez que aparece el número de la nota); por lo que estamos hablando de casi ¡500 ediciones! No puede ser.
Nuestro amigo Coco, nos sugiere que hagamos algún invento que nos ahorre este trabajo tan tedioso.

  
Lo primero va a ser copiar el texto de las notas a pie de libro en un archivo de texto plano TXT, de forma que cada nota ocupe una línea con su número de nota al inicio de la línea. Con un copiar-pegar y unos cuantos retornos de carro lo hacemos muy rápidamente:

Y ahora vamos a crear un programita que mediante un bucle para los valores 1 a 95, lea la frase correspondiente con el texto de la nota, le añada el código necesario para convertirlo en una nota a pie de libro y escriba el resultado en otro archivo de texto.
 

Como siempre, si pulsáis en la imagen accederéis al código. 
Como soy un tío muy rarito el programa esta hecho en KIXTART, un dialecto BASIC interprete de MICROSOFT orientado al scripting para la gestión de sistemas pero convertirlo a algo más universal, como por ejemplo VISUAL BASIC es muy sencillo porque la sintaxis es muy similar.
Resumiendo:

Para n=1 a 95, leo el archivo con el texto de las notas frase a frase hasta que encuentro la línea con la nota número n; le quito el comienzo de la línea dónde está el número de la nota para dejar sólo el texto. A ese texto le añado delante el código necesario para que sea una nota a pie de libro, cuya parte variable es el número n de la nota. Escribo la frase resultante en otro archivo de texto, donde me quedaran al final 95 líneas, una para cada nota a pie de libro.
Este es el archivo DESTINO resultante:
Por último, solo queda hacer un copiar-pegar desde este archivo a nuestro e-book en ePUB y ¡Voilá!

Todo lo que siempre quiso saber sobre el formato ePUB de sus ebooks y nunca se atrevió a preguntar (Cap. 01)

¿Quien lo inventa?
La International Digital Publishing Forum es una alianza de empresas para establecer los estándares tecnológicos y comerciales de la publicación digital. Sus miembros acordaron la definición de ePUB como la extensión de archivo (o sea todo lo que se llame “.epub”) que llevaran los libros electrónicos.

¿Que debe cumplir?
Pero no vale cualquier libro electrónico. Debe cumplir las siguientes características:
- en formato XML

- con reflow, (la capacidad de reajustar automáticamente los componentes del texto cuando se produzcan cambios en el formato del documento: tipo/tamaño de letra, márgenes, ventana de presentación, etc… Es lo que hace que los libros electrónicos no tengan un número de páginas fijo, sino que tienen una paginación dinámica).
- libre, abierto y sin encriptar
- y que cumple tres conjuntos abiertos de especificaciones:  la Open Publication Structure (OPS), Open Packaging Format (OPF) y Open Container Format (OCF). Estas especificaciones o estándares detallan lo que puede llevar dentro un ePUB, cómo debe estar organizado internamente y su modo de empaquetamiento (como fichero ZIP).
Dicho de otra forma, un fichero ePUB es un container (Contenedor), es decir una caja donde se guardan una serie de archivos (fundamentalmente en formato XHTML), cuyas características y contenidos están definidos y delimitados (mediante XML) y que se organizan y ordenan de una forma concreta (en una estructura de directorios definida). Y todo ello se empaqueta comprimiéndolo en formato ZIP.

Coco nos sugiere que hagamos la siguiente prueba:  Renombra un archivo “.ePUB” a “.ZIP”; y haz doble-click encima. El descompresor que tengas instalado en tu ordenador descomprimirá el archivo y te mostrará la estructura de directorios que incluye todos los archivos que forman parte de un ePUB.


¿Qué contiene un archivo ePub?

Si hacéis la prueba podréis comprobar que contiene una estructura como esta:

  

├───META-INF 
└───OEBPS 
 ├───Images 
 ├───Styles 
 └───Text 

Esta estructura de directorios es fija y debe darse siempre. El detalle de lo que se encuentra en cada directorio, cómo debe estar formado y para que sirve será objeto del Cap 02: Todo lo que siempre quiso saber sobre ePUB.

Cómo retocar con RegEx la conversión CALIBRE desde el formato PDF y conseguir mejores ebooks en ePUB para Mi reader PAPYRE 6.1 (Cap.02)

En el capítulo anterior habíamos pedido ayuda a Coco para que nos enseñara cómo arreglar los errores que se producen en la conversión de un archivo PDF hacia ePUB en CALIBRE.
Vamos a continuar utilizando RegEx para retocar el texto para conseguir un archivo ePUB sin errores.

ARREGLANDO LOS ERRORES MÁS HABITUALES
Los errores más habituales tienen que ver con la interrupción del flujo de texto, partiendose frases y párrafos en donde no procede.

Párrafo interrumpido por un RETORNO DE CARRO:
Vemos como la frase se corta y empieza un nuevo párrafo.
La expresión de búsqueda será:
  

He incluido las vocales acentuadas con la expresión “\()”
La expresión de sustitución es: \1 \3 Es decir, la última letra del primer párrafo, un espacio y la primera letra del segundo párrafo.
Además de seleccionar el check de “Match Case” para asegurar la diferenciación entre MAYUSCULAS y MINUSCULAS, conviene seleccionar “Minimal Matching” que asegura que se seleccionan los “segmentos” de texto más pequeños de todos aquellos que cumplen la condición de búsqueda.
Pulsamos ENTER y ¡Voilá!…
 
Carácteres espúreos al final de una frase:
Son números, correspondientes a la paginación del archivo PDF. En este caso, la expresión de búsqueda es sencilla:
  
Buscamos un bloque de entre 1 y 3
números (el libro no tiene más de 999 páginas) situado entre un punto “.” con un espacio detrás y una etiqueta de cierre de párrafo.
Lo sustituimos simplemente por un punto “.” seguido de la etiqueta de cierre de párrafo.
Pulsamos ENTER y “Abra-ca-dabra”…

 
MÁS párrafos interrumpidos por un RETORNO DE CARRO
 ¿Pero NO HABIAMOS RESUELTO ESTE TIPO DE ERROR antes? preguntareis. Pues sí, pero NO. Porque en la expresión de búsqueda anterior no incluimos caracteres especiales cómo la coma “,” y la interrogación “¿”. Así pues nos queda cubrir los casos en los que intervienen estos caracteres que son escasos pero que en un libro de 300 y pico páginas pueden darse cerca de 50 veces. Lo resolvemos sin necesidad de RegEx, simplemente copiando la cadena a sustituir:
  Le damos al ENTER y ¡Zas!…
 
Parrafos interrumpidos por un RETORNO DE CARRO después de un guión largo
Al incluir otro tipo de carácter especial, el guión largo “—” (EM Dash) también se escapó de la primera expresión de sustitución. A veces no queda más remedio que realizar este tipo de depuración “por capas de cebolla”, desde lo más general hasta los casos particulares. Aquí la expresión de búsqueda es más compleja:

Como siempre en este caso, debemos marcar el check de “Match Case” para asegurarnos de discriminar entre MAYUSCULAS y MINUSCULAS. Pulsamos ENTER para ver la magia de RegEx en acción:
 
Parrafos interrumpidos por un RETORNO DE CARRO después de un guión largo cuando es un COMIENZO de FRASE
 

Ya sólo nos queda por resolver el caso más enrevesado y dificil de diferenciar del texto correcto. Es cuando después de guión largo “—” (EM Dash) se rompe el párrafo; y el primer carácter del párrafo siguiente es una MAYÚSCULA, lo cual hace que sea muy dificil de distinguir de un principio de frase legítimo.
Tendremos como expresión de busqueda:

OJO! con el “Match Case” y “Minimal Matching”; Pero aquí el truco para comprobar que efectivamente se ha roto la frase de forma incorrecta es que existe un punto “.” justo antes del guión largo “—” (EM Dash); lo que indica que el mismo es el primer caracter de una nueva frase y no el último de la corriente.
Como siempre despúés de pulsar ENTER:
 
Los casos que hemos resuelto con estos retoques han eliminado cerca de 800 errores del texto, lo que supone la diferencia entre un ebook decente y una chapuza.