Hace poco me acordé de uno de esos problemas cuya solución puede ser tan obvia que puede llegar a ser imposible descubrirla sin pasarla varias veces por alto. Eventualmente logré encontrarla, por suerte, así que decidí explicarla aquí para quizás ayudar a alguien mientras trabaja en un libro electrónico.
Resulta que al hacer un EPUB en Adobe InDesign y después convertirlo a MOBI o AZW3, suele aparece un extraño error: al abrir una nota al pie en la ventana emergente del lector Paperwhite, a veces la primera línea muestra un enorme sangrado, que desarma por completo la diagramación. El sangrado no aparece en Adobe Digital Editions, iBooks o en Kindle Previewer.1
Después de revisar y probar todas las alternativas que se me ocurrieron, solo pude concluir que el error no proviene de la hoja de estilos. Google tampoco ayudó mucho: apenas encontré dos entradas en foros de Adobe y Mobileread sobre el mismo problema, ninguna con una respuesta clara. Así que tuve seguir dándome cabezazos contra el escritorio por varias horas hasta dar con la solución —como suele pasar— cuando me alejé del computador para hacer otra cosa.
La causa
La culpa, resulta, es de la estructura. Específicamente, la estructura de la nota al pie que InDesign genera de manera automática:
<div class="_idFootnotes">
<div id="footnote-043" class="_idFootnote">
<p class="footnote"><a class="_idFootnoteAnchor _idGenColorInherit" href="chapter1.xhtml#footnote-043-backlink">1</a>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras est quam, commodo eu neque at, mattis mollis ligula. Mauris ultricies odio id pharetra elementum.</p>
</div>
</div>
Sucede que InDesign, con el fin de mejorar la legibilidad para los tontos humanos, agrega esos espacios o indentaciones2 antes de las etiquetas <div> y <p> (al principio de las líneas 2 a 5 en el ejemplo). Por lo general estos saltos no afectan el resultado final, ya que cualquier programa bien armado sabe que debe ignorarlos al momento de mostrar el contenido según el diseño.
Sin embargo, el problema que nos convoca ocurre porque la ventana emergente de Kindle Paperwhite, que no ha sido tan bien programada como el resto de la interfaz, ignora las etiquetas que cuidadosamente hemos puesto y solo muestra el texto sin formato. Esto hace que la indentación aparezca como si fuera parte del texto de la nota, lo que desconfigura el resultado final esperado.
La solución
Para solucionar este caso, basta con eliminar la indentación por medio de una búsqueda en Sigil con comandos GREP3 que eliminen los espacios innecesario en todas las notas sin modificar el resto del contenido. Para eso, podemos ingresar esta búsqueda con expresiones regulares activadas (y cambiando el nombre del estilo al respectivo nombre del estilo de las notas):
\n\s*<p class="estilo-de-la-nota">(.+?)</p>\s*</div>
La reemplazamos por esto:
<p class="estilo-de-la-nota">\1</p></div>
Y ya está, problema resuelto, las notas se verán impecables con un clic, y nos habremos evitado un dolor de cabeza en durante la diagramación del ebook… al menos hasta que nos topemos con la siguiente causa de dolor de cabeza.
- No sé si pasará en otros dispositivos Kindle. Asumo que sí, pero no tengo cómo comprobarlo. Sí sé que no ocurre en la app para Windows o para iOS, que no muestran las notas en ventana emergente tampoco importa qué herramienta use para la conversión: el sangrado permanece. ↩
- La Real Academia Española preferiría que en este contexto use el término sangrado en vez del anglicismo indentación, pero justamente lo que quiero es diferenciar entre el sangrado de texto y la indentación de código. Así que por favor no le avisen a la RAE. ↩
- En teoría debería servir para cualquier programa que permita comandos GREP, pero en algunos puede funcionar de manera diferente, por lo que habrá que hacer los ajustes correspondientes. ↩
