Lo que debes saber sobre mis lectores electrónicos (e-readers) Papyre 6.1, Papyre ALEX y Booq AVANT para disfrutar al máximo de la lectura de libros electrónicos en su formato ePUB (y en los demás: PDF, FB2, EPUB,...) más comunes
Mostrando entradas con la etiqueta TOC. Mostrar todas las entradas
Mostrando entradas con la etiqueta TOC. Mostrar todas las entradas

jueves, octubre 13

Las BBPP de LARdT para un ePUB decente. La reseña y la Tabla de contenido (TOC)


Y después de la página de Colofón seguimos avanzando por el libro y llegamos a la reseña.
 
 La reseña
La reseña incluye un resumen del libro que se captura en el campo descripción de los metadatos. Es interesante y práctico ya que los libros electrónicos no pueden hojearse como  los libros impresos; y en general resulta más complicado hacerse una idea del contenido en un examen superficial.
La reseña en el ASUS TRANSFORMER La reseña aparece como entrada del TOCReseña (Resumen del contenido)” para un acceso sencillo.  Algunos lectores, como por ejemplo el MyLibrary del ASUS Transformer  muestran esta información en el bookshelf; lo cual es de gran utilidad.





La Tabla de Contenido (TOC)
La tabla de contenido es lo que habitualmente se llama índice en los libros impresos. Los libros de las BBPP de LARdT incluyen el índice TOC generado por el programa lector en lugar de incluir una página dentro del libro propiamente dicha con una lista de enlaces a los distintos capítulos y partes del libro. Es mejor práctica hacerlo así, ya que hay algunos lectores que no manejan correctamente los enlaces internos (o directamente no los manejan) en cuyo caso el usuario se quedaría con una página del libro inútil y sin funcionalidad de índice.
La TOC generada se hace en función de las cabeceras y títulos de los capítulos, partes, subcapítulos y demás divisiones del libro, mediante la utilización del código heading.

Empezamos asignando el h3 (nivel 3) a la división más frecuente y reconocible que existe en cualquier libro: el capítulo. De ahí, vamos subiendo hacia arriba (parte o “libro”: h2) y bajando hacia abajo (Subcapítulos: h4). De esta forma, nunca nos hemos quedado sin niveles de heading para asignar a las distintas partes del libro. Hay que tener en cuenta de que disponemos únicamente de h1 a h6, pero con esta atribución han resultado suficientes hasta la fecha.

Otra característica interesante de las TOC generadas es que ofrecen además el indentado correspondiente a los distintos niveles, como veréis a continuación en los pantallazos de los dispositivos (EXCEPTO EL Mylibrary del ASUS TRANSFORMER que no ofrece dicho indentado y muestra el índice de forma plana).



Los “truquis” 
Hay además un par de trucos con el código XHTML del ePUB para retocar un poco el resultado final del índice TOC generado:

sigilNotInTOC: este parámetro sirve para que la entrada de heading correspondiente no aparezca en la Tabla de contenido, lo que a veces puede resultar interesante, para una mayor legibilidad.



title: con este parámetro podemos asociar un texto específico a la entrada de TOC del heading correspondiente y cambiar el que aparecería por defecto. Es decir, el texto que aparece en el libro asociado a dicho heading (un título de capítulo, por ejemplo) puede aparecer de forma distinta en el índice.

Más “Truquis”
Y hay casos en los que el libro no tiene división alguna por capítulos, o estos no aparecen indicados de ninguna forma, aunque en la edición en papel, mediante el cambio de página, por ejemplo, resultan evidentes. Como además resulta obligatorio partir el texto del libro en trozos que no sobrepasen los 300Kb sin comprimir (e incluso algunos lectores establecen limitaciones más estrictas) podemos aprovechar para incluir un heading “invisible”, pero que aparezca en el TOC para facilitar la navegación por el libro, porque debemos recordar que los libros electrónicos no pueden hojearse.
Así podemos incluir por ejemplo al principio de cada archivo XHTML de los que componen el libro una línea:

<h3 title=”En un lugar de la Mancha…”></h3>
con parte de la primera frase del primer párrafo terminada en puntos suspensivos.
En el libro no aparecerá nada, pero sin embargo disfrutaremos de un índice TOC perfectamente funcional.

viernes, septiembre 24

Los “heading” y la creación de TOCs en las BBPP LARdT 1.0 (“Buenas Prácticas de LARdT para un ePUB decente”) (Cap. 08)


A veces un ebook te puede volver loco Las etiquetas “heading” (h1, h2, h3,…) se usan muy frecuentemente en HTML porque dado que jerarquizan el contenido y a la vez suelen tener vinculados formatos de estilo (con tamaño de fuentes creciente, negrita, subrayados, etc..) resultan muy prácticas. Es lo que se llama “marcado semántico”: algo etiquetado como <h1> siempre será más visible que lo que esté etiquetado como <h2>.
Dada esta prevalencia en HTML parece natural que su uso se extienda también al XHTML de los ePUB. Y aquí es donde merece la pena realizar un comentario.

Un uso disperso
Todos los que componemos libros en ePUB usamos los headings. Y de forma distinta, lo cual a veces resulta problemático. Las BBPP LARdT 1.0 también contienen su propio criterio de aplicación, como no. Al menos tiene la ventaja de ser siempre idéntico. Por eso, he pensado que no estaría mal que fuera generalizándose un uso un poco más uniforme de los “headings”, es decir, unas “buenas prácticas”. 

Los headings en las BBPP LARdT 1.0
El criterio de los headings en las BBPP LARdT 1.0 es como sigue:
h1” – Reservado para el nombre de Autor.
h2” – Reservado para el título del libro.
h3” – Primer nivel (mayor) jerárquico existente en la estructura del libro. Si existe la división en “Libro”, “Tomo”, “Parte”, etc… se le aplica este heading. Si no existen subdivisiones mayores entonces se aplica a los capítulos.
h4” – Segundo nivel jerárquico en la estructura del libro; que según lo expuesto para el nivel de heading anterior se aplicara al “capítulo” o a los “subcapítulos”.
h5” – Tercer nivel jerárquico. Para las subdivisiones inferiores. Si fuera necesario, esta estructura puede ampliarse hasta el infinito “h6”, “h7”,… pero lo cierto es que no he encontrado un libro que necesite más de 3 niveles jerárquicos de organización.
Y por último, recalcar que no se utilizan los “headings” para ningún otro contenido que no tenga que ver con la estructura y división jerárquica del libro.

Así los usos más frecuentes son:

h3” – Parte, “Libro”, “Tomo”

   “h4” – “Capítulo”
       “h5” – “Subcapítulo”
ó bien
h3” – “Capítulo”

     “h4” – “Subcapítulo”

¿Por qué no utilizamos “h1” y “h2” para las partes del libro? Pues simplemente porque cuando empezamos a trabajar con los libros en ePUB utilizábamos el programa de edición SIGIL y este seguía la practica de reservar los dos primeros niveles de heading para envolver el nombre del autor y el título del libro en la portada. Lo que envolvieras entre etiquetas <h1></h1> se incorporaba de forma automática como nombre del autor en los metadatos del libro; y lo mismo ocurría con  <h2>título</h2>.
Así empezamos y luego hemos seguido haciéndolo así. Si los libros tuvieran generalmente muchos subniveles a lo mejor hubiéramos abandonado esta práctica, pero como ya he dicho, normalmente 2 ò 3 niveles son suficientes para expresar la estructura de un libro.
Pero lo bueno del caso es que de este hecho “histórico” más o menos fortuito se ha derivado una consecuencia bastante interesante.

Generar la TOC del libro a partir de los “heading” 
Resulta que SIGIL sigue la convención propia de los programas de tratamiento de texto (Word, OpenOffice) de generar la TOC (tabla de contenido –índice-) automáticamente a partir de la estructura de “headings” del texto. Evidentemente, el programa permite editar y modificar a gusto del usuario la TOC generada automáticamente. Y es lógico que lo haga porque, en principio, una de las características propias del formato ePUB es la posibilidad (en realidad, la obligatoriedad) de crear la TOC del libro. Hasta aquí todo correcto: uno compone el libro, el editor te ayuda generando la TOC automáticamente a partir de las etiquetas “heading” y luego uno hace el ajuste que le parece más conveniente. El libro ePUB queda con su TOC a medida y  todos contentos.

Las sorpresas de ADOBE MOBILE READER
Pero resulta que en este mundo cruel de los libros electrónicos nada es lo que parece. Resulta que hemos encontrado que algunas implementaciones del programa más extendido para la lectura de ePUB, el ADOBE MOBILE READER (es decir, la contraparte e-book del ADOBE DIGITAL EDITIONS de tu PC); en vez de utilizar la TOC incrustada en el ePUB siguen la misma práctica que Word; es decir CREAN LA TOC A PARTIR DE LAS ETIQUETAS HEADING existentes en el texto.
El problema que aparece es que si utilizas expresiones “heading”, por ejemplo, para separadores del texto del tipo de las típicas estrellitas

<h5>* * *</h5>




…te puedes encontrar con que el TOC de tu libro aparece así:


snapshot_26





o así;





snapshot_23lo que no es plan, vamos.


Así pues, la práctica que adoptamos un poco por casualidad, por fortuna luego ha resultado bastante útil.


Recapitulando: Aunque en teoría no debería ser así, resulta conveniente utilizar la etiqueta “Heading” sólo y únicamente para aquellos contenidos que se desee que aparezcan en la TOC.




¿Y por qué utilizar una ”escala móvil” en lugar de una fija?


Dejando aparte toda esta incidencia del ADOBE MOBILE READER, también me han preguntado porqué no asocio los niveles de “heading” a subdivisiones fijas del libro. Es decir, por ejemplo y empezando en <h3> (“escala fija”):


h3” - siempre para 

Capítulos

h4” - siempre para Subcapítulos


h5” – siempre para divisiones dentro de capítulos o subcapítulos


h6” – Subtítulos


h7” – siempre para cualquier otra división de menos importancia.




Nota: a efectos de este ejemplo, es trivial empezar en h1 o en h3.





Sin embargo en las BBPP LARdT 1.0 como los distintos niveles de heading se asocian de mayor a menor con las subdivisiones existentes en cada libro, los capítulos unas veces serán <h3> y otras <h4> dependiendo si existe un nivel de división por encima (tipo “Libro”, “Parte”, “Tomo”,…) o no.


Yo soy partidario de este tipo de “escala móvil” porque me parece que es mucho más fácil el que todos coincidamos en que un libro tiene 2,3, ó n niveles de división; a que coincidamos en la definición de “subcapítulo”, “subtítulo” etc…


Tampoco me parece conveniente el que la numeración de los “headings” tenga “huecos”; en el ejemplo anterior de escala fija un libro podría no tener “h5” (no hay subdivisiones en los capítulos) y si “h6” (subtítulos); dependiendo además de cómo se defina cada parte.





Por todos estos motivos, las BBPP LARdT 1.0 utilizan los “headings” para etiquetar:


- únicamente los contenidos que deben aparecer en el TOC





- asociando cada nivel de forma biunívoca y de mayor a menor a los distintos niveles de división y organización (partes); de forma correlativa (sin huecos) y empezando en <h3>


- respetando el concepto de etiquetado semántico: <h1> siempre será más visible (fuente de mayor tamaño, negrita, etc..) que <h2>; <h2> será más visible que <h3>; y así sucesivamente.


- <h1> y <h2> en realidad quedan sin uso porque el nombre de autor y el título del libro; ya están suficientemente gestionados e identificados con su inclusión en los metadatos del libro.








En cualquier caso, como ya sabéis los que seguís este BLOG, esto son las BBPP LARdT 1.0 y no las tablas de la ley. Son completamente opinables y, seguramente, mejorables. Espero abrir el debate.




Para terminar, este POST ha sido inspirado por una interesante discusión vía mail con Javier Maray al que podéis considerar como co-autor (¡aunque a lo mejor no coincidimos en todo!).