Créer un livre électronique au format epub3, partie 2 : ePub Anatomy

Dans cette triple série d’articles, Making of a book, Créer un livre électronique au format ePub3, et Making of an (audio)book, je vous propose le résultat de mes recherches, de mes essais et de mes explorations diverses et variées sur la façon de produire un livre, respectivement en format papier, en format électronique, et en format audio. Ces articles ont vocation à évoluer dans le temps, aussi n’hésitez pas à vous inscrire à la Newsletter d’écaille & de plume qui vous avertira de toute mise à jour.

Précédemment dans la série

Après avoir fait un tour des raisons qui peuvent pousser à mettre un livre au format EPUB et balayé rapidement les options qui s’offraient à nous pour ce faire, nous avons appris dans la première partie comment structurer son texte dans un logiciel de traitement de texte comme LibreOffice, ou dans Scrivener, puis comment exporter le document (ou le compiler) ainsi mis en forme sous un format EPUB. C’est ainsi que je vous ai laissés, haletants, sur le résultat pas vraiment laid, mais pas vraiment fantastique, de Fæe du Logis sur mon iPad dans le logiciel de lecture iBooks d’Apple.

Aujourd’hui nous allons donc aller plus loin et analyser le fichier que nous avons obtenu, afin de comprendre le fonctionnement d’un livre au format EPUB3, et commencer, si possible, à réparer ce qui nous semble aller de travers.

L’incision initiale : sous l’enveloppe de l’EPUB

Avant toute chose, il vous faut un EPUB sous la main.

Soit vous suivez l’article précédent et créez votre propre EPUB, soit vous pouvez télécharger la maquette d’EPUB3 que je vous livre en téléchargement gratuit. Il vous suffit pour cela de renseigner votre adresse mail (que je n’utiliserai pas à d’autres fins).

Il suffit de glisser-déposer le fichier EPUB dans la fenêtre de l’application, et le scalpel virtuel vous ouvre le dossier.

Vous allez y trouver deux types de fichiers organisés en un squelette immuable : les fichiers obligatoires, qui sont les organes vitaux de l’EPUB (en bleu sur la capture d’écran ci-dessous), et les fichiers facultatifs, qui en sont l’âme (en vert). Ces derniers sont essentiellement les fichiers de contenu de votre livre : le texte, les styles de texte, les images, les fontes, les fichiers audio ou vidéo qui forment votre œuvre. Nous nous y intéresserons plus tard, même si ce sera le plus important pour vous.

Deux fichiers ont la même fonction, ils servent à créer la table des matières du livre (ou Table of Contents en anglais, d’où le nom qui lui est souvent attribué : toc.ncx ou contents.xhtml), respectivement dans la norme EPUB2 et la norme EPUB3. Afin de garder une rétrocompatibilité vers les appareils de lecture plus anciens, il sera bien avisé de garder ces deux fichiers. Vous remarquerez aussi qu’un fichier est à la fois vital et libre, c’est le fichier .opf, auquel vous pouvez donner le nom que vous voulez, du moment que vous en avez placé un dans le dossier OEBPS de votre livre.

Comme vous le voyez, une bonne part des dossiers est immuable d’un livre à l’autre. Ce qui m’a donné l’idée de me constituer une maquette, une sorte de template comme on dit en informatique, un « patron » à réutiliser à volonté lorsque j’ai besoin de créer un nouveau livre.

Les instruments de la dissection : l’éditeur de texte

Pour aller plus loin, vous allez devoir ouvrir les fichiers les uns après les autres pour examiner puis modifier le code. Il vous faut donc un programme que l’on appelle un éditeur de texte. Comme un traitement de texte, mais pour les codes informatiques.

J’utilise pour ma part Brackets, qui est libre et multi-plateforme, ou son remplaçant, Visual Studio Code. Comme la plupart de ses cousins, il est capable de colorer les lignes de code en fonction de leur syntaxe pour bien reconnaître les paramètres et pour ne pas (trop) se tromper. C’est lui qui va vous permettre de corriger et de modifier l’ADN de votre EPUB.

Grâce à ce logiciel, vous pouvez lire les fichiers codés et les modifier, puis en vérifier l’aperçu (quand le code est connu par le logiciel, ce qui n’est pas le cas de l’OPF, par exemple).

Vous remarquerez que les lignes de code commencent toutes par le caractère « < » et se terminent toutes par le caractère « > ». C’est ce qu’on appelle des balises, comme nous l’avons vu dans le précédent épisode. Ces balises sont des instructions, comme des verbes dans une phrase de français. Tout ce qui sera entre les balises servira à préciser l’instruction donnée dans la phrase. Il y a ainsi une syntaxe particulière à respecter, qui demande un apprentissage parfois long…

Mais pour le moment, contentons-nous d’ouvrir les fichiers de notre archive EPUB avec VS Code. Pour cela soit vous glissez le fichier sur l’icône de Visual Studio Code dans votre Dock, soit vous faites un clic droit sur le fichier que vous voulez ouvrir et vous choisissez Visual Studio Code dans le menu déroulant Ouvrir avec.

Les Organes vitaux de l’EPUB

Ce sont des fichiers dont il ne faut jamais modifier ni le nom ni la structure, au risque de rendre votre EPUB illisible.

Ces organes vitaux sont au nombre de cinq.

• Le fichier mimetype, qui ne contient qu’une seule ligne, destinée à faire comprendre à un logiciel comment décoder le livre. C’est un fichier que vous ne devrez jamais modifier, car la ligne de code ne doit pas varier d’un seul caractère.
• Le fichier container.xml, qui ne devra pas être touché lui non plus, sauf si vous désirez changer le nom ou l’emplacement de votre fichier OPF, qui est le véritable cerveau de votre livre. Le fichier container.xml sert en effet essentiellement à renseigner l’emplacement et le nom du fichier OPF. Il est enfermé dans un dossier dont le nom ne doit pas être modifié, le dossier META-INF.
• Le fichier OPF (Open Publication Format), donc, qui mérite que l’on s’y attarde un peu plus loin, car il pourra, lui, être modifié selon vos besoins.
• Le fichier nav (souvent appelé contents.xhtml ou toc.xhtml), qui est le fichier contenant la table des matières dans la norme EPUB3.
• Le fichier .ncx, qui est le fichier contenant la table des matières dans la norme précédente EPUB2.

Les trois derniers fichiers sont les plus importants, et nous allons y jeter un coup d’œil plus attentif.

Neurochirurgie du fichier OPF, cerveau de l’EPUB

Ce fichier OPF (nommons-le livre.opf) est le principal pourvoyeur d’erreurs lors de la construction d’un EPUB, car c’est lui qui est le plus compliqué à fabriquer correctement, tant les règles qui dictent sa constitution sont drastiques.

Véritable cerveau de l’EPUB, il contient cinq parties distinctes.

• Les déclarations de références, qui indiquent à l’application de lecture les langages informatiques à utiliser, constituent le package.
• Les métadatas du livre, c’est-à-dire toutes les informations sur son identité, sont encodées dans la partie metadata. On y trouve la langue dans laquelle il est écrit, son auteur (ou ses auteurs), les éventuels collaborateurs (illustrateurs par exemple), sa date de fabrication, sa date d’édition, son éditeur, une courte description (un résumé par exemple, la 4e de couverture…), son image de couverture, les droits qui y sont liés (licence Creative Commons, Copyright…).
• Le manifeste déclare toutes les ressources intégrées dans le livre, sans en oublier une seule. Les images que vous allez utiliser, y compris la couverture, chaque fichier comprenant chaque chapitre, les fontes, tout, absolument tout, doit être listé ici.
• La spine décrit ensuite l’ordre dans lequel le livre se lit normalement. Mais vous verrez, c’est parfois un peu plus compliqué.
• Le guide est une spécificité de la vieille norme EPUB2.

Nous allons nous intéresser à chacune de ces parties un peu plus finement.

Le package

C’est une partie très codifiée à laquelle il vaut mieux ne rien changer sauf si l’on veut utiliser certaines fonctions propres à des lecteurs EPUB, comme iBooks d’Apple par exemple.

<?xml version="1.0" encoding="UTF-8"?>
<package xmlns="http://www.idpf.org/2007/opf" version="3.0" unique-identifier="PrimaryID">
    ...
</package>

Dans ce cas-là, il faut rajouter quelques précisions (vous verrez dans quels cas dans le tableau des metadatas ci-dessous).

Au passage, j’ai rajouté également xml:lang, un paramètre qui indique que nous sommes dans un EPUB dont la langue est le français. Vous aurez aussi noté que la version de l’EPUB est obligatoirement indiquée.

<!--?xml version="1.0" encoding="UTF-8"?-->
<package xmlns="http://www.idpf.org/2007/opf" version="3.0" xml:lang="fr" unique-identifier="pub-id" prefix="rendition: http://www.idpf.org/vocab/rendition/# ibooks: http://vocabulary.itunes.apple.com/rdf/ibooks/vocabulary-extensions-1.0/" xmlns:epub="http://www.idpf.org/2007/ops" xmlns:ibooks="http://apple.com/ibooks/html-extensions">
...
</package>

Les balises metadata

Les métadatas (ou métadonnées en bon français) permettent de bien référencer votre livre, et à ce titre il est très utile de se pencher sur leur cas. Le référencement correct de votre livre aidera vos lecteurs et vos lectrices à le retrouver dans la masse titanesque des ouvrages disponibles.

Hélas, ces métadonnées sont inscrites dans une syntaxe un peu hermétique qui réjouira plus ceux d’entre vous qui ont l’habitude des codes informatiques que ceux qui aiment la littérature. C’est assez abscons, il faut bien le reconnaître. J’ai donc décrypté pour vous la norme EPUB3, et voici la substantifique moelle de ce que j’ai pu en tirer.

Encadrées par les balises metadata, se trouvent chacun des paramètres identifiant non seulement les données essentielles de votre livre, mais aussi certaines autres données spécifiques pour des lecteurs d’EPUB particuliers (dans le cas ci-dessous, pour iBooks d’Apple).

Voici comment Scrivener liste ses métadatas :

    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
        <dc:title>Fée du Logis</dc:title>
        <dc:identifier id="PrimaryID">urn:uuid:E9B7CBB8-1D23-40C5-8053-E84F87026351</dc:identifier>
        <dc:language>en</dc:language>
        <meta property="dcterms:modified">2018-03-20T20:00:18Z</meta>
        <dc:creator id="author">Germain HUC</dc:creator>
        <meta refines="#author" property="role">aut</meta>
        <meta refines="#author" property="file-as">HUC, Germain</meta>
    </metadata>

D’abord, comme ce sont des balises, elles sont forcément enchâssées entre des signes <>.

Puis vient le sigle dc, pour Dublin Core, et l’élément de la norme Dublin Core. Ensuite, la valeur de la métadonnée, puis on referme la balise comme dans le langage HTML.

Vous trouverez plus de détails sur ce site, ou celui-ci, ou encore sur celui de la BnF.

Chaque balise peut être précisée par des métadonnées de « raffinement », indiquées dans des balises <meta>.

La liste des metadatas

Dans ce tableau (que vous pouvez manipuler à loisir et dans lequel vous pouvez même faire des recherches…), j’ai récapitulé toutes les métadonnées de ma connaissance, pour vous indiquer comment les utiliser. Vous pouvez vous référer à l’exemple de code ci-dessus pour vous ce que cela donne en situation. Vous trouverez la syntaxe correcte et les quelques subtilités.

N’hésitez pas à m’indiquer dans les commentaires si vous trouvez des erreurs, des approximations ou des ajouts à faire. Je ferai bien volontiers les corrections et ajouts qui s’imposent.

Le « manifeste »

C’est la partie du fichier qui recense toutes les ressources utilisées dans le livre. De la plus petite image jusqu’aux fontes de caractères spécifiques, en passant par chaque chapitre du livre, les éventuelles vidéos ou les bandes-son, les scripts d’interactivité qui permettront aux lecteurs de contrôler des animations, les scripts CSS des feuilles de style qui vont vous permettre de définir la mise en page… tout, tout, absolument tout le contenu du livre doit être déclaré dans ce manifeste, et selon une syntaxe là encore très précise.

On commence par des balises <manifest> qui encadrent une liste de balises <item>. Chaque item est une ressource présente dans le livre (un fichier si vous préférez) dont on indique une identité (id), le chemin dans l’arborescence (href), et surtout le type mime, un code qui explicite sa nature (et non pas à cause du Mime Marceau).

Les types mime et leur syntaxe sont d’ailleurs les plus compliqués à trouver. Je vous en liste les principaux dans un tableau un peu plus bas.

Voici comment Scrivener vous aura organisé cette partie.

    <manifest>
        <item id="ncx" href="toc.ncx" media-type="application/x-dtbncx+xml" fallback="contents"></item>
        <item id="contents" properties="nav" href="contents.xhtml" media-type="application/xhtml+xml"></item>
        <item id="body" href="body.xhtml" media-type="application/xhtml+xml"></item>
        <item id="style" href="css/stylesheet.css" media-type="text/css"></item>
    </manifest>

Et quant à moi, voici comment j’ai l’habitude d’organiser les choses : en regroupant les types de fichiers.

	<manifest>
		
		<!-- contenu -->
        <item id="ncx" href="toc.ncx" media-type="application/x-dtbncx+xml" fallback="contents"></item>
        <item id="contents" properties="nav" href="contents.xhtml" media-type="application/xhtml+xml"></item>
        <item id="body" href="body.xhtml" media-type="application/xhtml+xml"></item>
		
		<!-- styles -->
        <item id="style" href="css/stylesheet.css" media-type="text/css"></item>
		
		<!-- fontes -->
		
		<!-- images -->
		
    </manifest>

Vous voyez que j’ai enrichi mon livre avec des fontes de caractères précises, des feuilles de style, des images, le tout regroupé dans des dossiers spécifiques marqués par des balises de commentaire (qui ne sont donc pas codées). Il est ainsi plus facile de s’y retrouver par la suite, car si vous oubliez de déclarer ici un seul élément présent dans le livre, celui-ci deviendra illisible par les lecteurs EPUB…

Mon conseil : à chaque fois que vous ajoutez un fichier dans votre EPUB, insérez immédiatement la référence dans le manifeste du fichier OPF.

Vous êtes libre de donner le nom de votre choix aux items (sachant que le meilleur nom est celui qui vous permettra de savoir très rapidement à quel fichier précisément vous avez à faire), mais le chemin doit suivre les mêmes règles qu’un chemin de fichier classique sur votre ordinateur ou sur un site internet.

Par exemple mon fichier de fonte « Trajan Pro » se situe dans le dossier styles et son chemin sera donc : styles/TrajanPro-Regular.otf.

Enfin, petite subtilité qui m’a posé de nombreux problèmes, les « properties » ou propriétés de chaque élément. Il est impératif d’indiquer certaines particularités de vos fichiers. Si l’un de vos chapitres comporte une partie interactive (disons par exemple des boutons permettant de masquer ou d’afficher du texte caché), vous devrez ajouter sur la ligne de déclaration du manifeste la propriété « scripted ». Si un fichier de contenu contient la table des matières, vous devez indiquer la propriété « nav », s’il contient une image au format SVG, vous devrez indiquer « svg ». Si le fichier fait référence à plusieurs propriétés à la fois, vous devrez les séparer par un simple espace, suivant cette syntaxe :

Il est à noter que votre livre doit contenir au moins un élément nav. Nous en verrons l’utilité dans le troisième article de cette série.

Quant au fichier toc.ncx, qui ne sert à rien en EPUB3, mieux vaut le garder pour la rétrocompatibilité avec l’EPUB2…

L’épine dorsale : le « spine »

La partie suivante du fichier OPF est appelée le « spine ». C’est l’épine dorsale de votre livre. L’endroit où vous spécifiez quels sont les chapitres qui constituent votre ouvrage, et dans quel ordre ils doivent être lus. Inutile, dîtes-vous ? Pas tant que cela.

Car la subtilité vient du fait que vous pouvez avoir des fichiers qui constituent des annexes de votre livre et qui ne soient pas directement accessibles dans un ordre déterminé. Par exemple, une liste de définitions que votre lecteur pourrait aussi bien consulter au début de l’ouvrage qu’au milieu d’un chapitre. C’est ce qu’on appelle des fichiers « non linéaires » (ou non linear content en anglais). Vous ne savez pas dans quel ordre le disposer, mais vous voulez qu’il soit accessible. Vous devez donc le déclarer dans le spine, mais avec la mention « contenu non linéaire » (ou en code : linear= “no”). Ce fichier ne sera donc pas affiché comme un chapitre normal à la suite de son prédécesseur, mais appelé lorsque le lecteur fera une action (par exemple lorsqu’il cliquera sur la miniature d’un tableau).

     <spine toc="ncx">
        <itemref idref="contents" linear="yes"></itemref>
        <itemref idref="body" linear="yes"></itemref>
    </spine>

Le « guide », obsolète en EPUB3

Comme je vous l’ai déjà dit, le format EPUB3 est assez récent et n’est donc pas pris en charge par toutes les tablettes et toutes les liseuses existantes. Cependant il serait dommage de priver certains lecteurs de votre œuvre donc, même au prix d’un alourdissement de votre code, donc du poids de votre fichier, donc de sa réactivité, je pense que toutes les options permettant une rétrocompatibilité de votre livre vers l’EPUB2 sont intéressantes.

Le guide fait partie de ces options.

<guide>
        <reference type="toc" title="Contenu" href="contents.xhtml"></reference>
    </guide>

Au final, la planche anatomique d’un fichier livre.opf

Voici ce que donne le fichier dans sa totalité :

<?xml version="1.0" encoding="UTF-8"?>
<package xmlns="http://www.idpf.org/2007/opf" version="3.0" unique-identifier="PrimaryID">
    <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
        <dc:title>Fée du Logis</dc:title>
        <dc:identifier id="PrimaryID">urn:uuid:E9B7CBB8-1D23-40C5-8053-E84F87026351</dc:identifier>
        <dc:language>en</dc:language>
        <meta property="dcterms:modified">2018-03-20T20:00:18Z</meta>
        <dc:creator id="author">Germain HUC</dc:creator>
        <meta refines="#author" property="role">aut</meta>
        <meta refines="#author" property="file-as">HUC, Germain</meta>
    </metadata>
    <manifest>
		
		<!-- contenu -->
        <item id="ncx" href="toc.ncx" media-type="application/x-dtbncx+xml" fallback="contents"></item>
        <item id="contents" properties="nav" href="contents.xhtml" media-type="application/xhtml+xml"></item>
        <item id="body" href="body.xhtml" media-type="application/xhtml+xml"></item>
		
		<!-- styles -->
        <item id="style" href="css/stylesheet.css" media-type="text/css"></item>
		
		<!-- fontes -->
		
		<!-- images -->
		
    </manifest>
    <spine toc="ncx">
        <itemref idref="contents" linear="yes"></itemref>
        <itemref idref="body" linear="yes"></itemref>
    </spine>
    <guide>
        <reference type="toc" title="Contenu" href="contents.xhtml"></reference>
    </guide>
</package>

Comment bien se tenir à la table… des matières

Un livre ne serait pas un livre sans son sommaire, ou sa table des matières. Et le livre électronique ne fait pas exception. Mais dans un EPUB3, cette table des matières est à plusieurs endroits à la fois.

Tout d’abord, comme nous l’avons vu, dans la partie spine du fichier .opf.

Puis, pour le format EPUB3, dans un fichier HTML particulier souvent appelé toc ou nav, et listé dans le manifeste avec la propriété nav.

Enfin, pour la rétrocompatibilité avec l’EPUB2, dans un fichier au format spécial dont l’extension est .ncx.

Nous allons nous intéresser à ces deux fichiers en particulier.

Le fichier nav

Scrivener crée un fichier qui se nomme en l’occurrence toc.xhtml mais sa caractéristique principale est de contenir essentiellement une liste (codée en HTML par les balises <ol> et <li> imbriquées) des chapitres et sous-chapitres de votre livre. Ce fichier sera le canevas sur lequel s’appuiera le logiciel de lecture pour construire des liens vers vos différents chapitres. Et vous pouvez même remarquer que la balise <a> présente à chaque ligne, renvoie au fichier correspond au chapitre indiqué.

Si l’on simplifie, ce fichier n’est rien d’autre qu’un menu permettant d’accéder à chaque fichier, donc à chaque chapitre, de votre livre.

Il doit cependant suivre une règle immuable : la présence en début de liste de la balise <nav>, suivie de la précision ou propriété epub:type correspondante.

<!DOCTYPE html>
<html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
<head>
	<meta charset="utf-8"/>
	<title>Contenu</title>
	<link type="text/css" rel="stylesheet" href="css/stylesheet.css"/>
</head>
<body>

<p>Contenu</p>
<nav epub:type="toc" id="toc">
<ol>
<li><a href="body.xhtml">Chapitre I</a>
</ol>
</nav>

</body>
</html>

Le fichier ncx

Scrivener a aussi généré un fichier appelé toc.ncx où se trouve la même fonctionnalité que le fichier nav, mais pour les logiciels ne lisant que le format EPUB2.

Le principe structurant le fichier est le même, mais au lieu de faire appel aux balises HTML classiques de liste ordonnée (<ol>) et de ligne (<li>), le fichier utilise une syntaxe originale.

Il y aura donc une balise <navMap> qui indiquera le début du plan de votre table des matières.

Une balise <navPoint> qui marquera chaque chapitre, avec une propriété playOrder pour montrer au logiciel de lecture l’ordre dans lequel les chapitres doivent s’enchaîner logiquement.

Une balise <navLabel> indiquant le texte à afficher comme titre du chapitre dans le plan.

Et enfin un lien sous la forme non pas du classique hyperlien HTML (balise <a>) mais d’une nouvelle balise <content> suivie de la propriété src qui permet de déclarer le chemin du fichier correspondant au chapitre ou sous-chapitre.

On comprend combien l’EPUB3 est plus simple…

<?xml version="1.0" encoding="UTF-8"?>
<ncx xmlns="http://www.daisy.org/z3986/2005/ncx/" version="2005-1">
    <head>
        <meta name="dtb:uid" content="urn:uuid:E9B7CBB8-1D23-40C5-8053-E84F87026351"></meta>
        <meta name="dtb:depth" content="1"></meta>
        <meta name="dtb:totalPageCount" content="0"></meta>
        <meta name="dtb:maxPageNumber" content="0"></meta>
    </head>
    <docTitle>
        <text>Fée du Logis</text>
    </docTitle>
    <navMap>
        <navPoint id="navPoint-1" playOrder="1">
            <navLabel>
                <text>Contenu</text>
            </navLabel>
            <content src="contents.xhtml"></content>
        </navPoint>
        <navPoint id="navPoint-2" playOrder="2">
            <navLabel>
                <text>Chapitre I</text>
            </navLabel>
            <content src="body.xhtml"></content>
        </navPoint>
    </navMap>
</ncx>

L’âme de l’EPUB

C’est là le plus intéressant, puisque c’est ici que vous allez mettre en forme l’œuvre déjà écrite.

Cependant, en ouvrant le fichier avec Visual Studio Code, voici ce que vous allez trouver :

<!DOCTYPE html>
<html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops">
<head>
	<meta charset="utf-8"/>
	<link type="text/css" rel="stylesheet" href="css/stylesheet.css"/>
</head>
<body>

<p class="titre-de-chapitre-page-padding"><br /></p>
<p style="text-align: center; text-indent: 0em" id="doc1">Chapitre</p>
<p style="text-align: center; text-indent: 0em">I</p>

</body>
</html>

Que veulent dire ces codes ?

Ce sont là encore des balises, mais dans un langage différent de celui du fichier livre.opf. Ces lignes sont les mêmes que si votre livre avait été écrit dans un site internet, dans le langage de programmation HTML.

Quant au fichier qui commande la mise en forme de votre texte, c’est le fichier stylesheet.css. En l’ouvrant, voici ce que vous allez lire :

/* Base text formatting */
p { margin: 0rem 0% 0rem 0rem; text-indent: 0rem; }

/* Styles */
blockquote { margin: 1rem 0rem 1rem 0rem; }
blockquote p { margin: 1rem 0% 1rem 4.49rem; text-indent: 1.42rem; line-height: 1.1em; }
.mise-en-évidence { font-weight: normal; font-style: italic; text-decoration: none; }

/* Separators */
.separator { }

/* Page padding */
.titre-de-livre-page-padding { margin: 0rem 0rem 0rem 0rem; font-size: 1rem; line-height: 3rem; }
.titre-de-chapitre-page-padding { margin: 0rem 0rem 0rem 0rem; font-size: 1rem; line-height: 3rem; }

/* Tables */
/* Reset all potential built-in rendering assumptions so we have full control. */
table, table * {
    border: none;
    padding: 0em 0em 0em 0em;
    margin: 0em 0em 0em 0em;
}
table {
    /* Will centre tables on iBooks and others, but annoying, not ADE-based devices, which ignore auto margins. */
    margin: 1em auto 1em auto;
    border-spacing: 0em;
    border: solid #000;
    border-width: 0pt 0pt 1pt 1pt;
}

table caption {
    margin-top: 0.25em;
    caption-side: bottom;
    text-align: center;
}
...

Déroutant, n’est-ce pas ?

C’est tout à fait normal. Vous avez devant les yeux la traduction informatique des styles que vous aviez patiemment ciselés dans votre traitement de texte. Il faut seulement vous habituer à cette traduction un peu barbare, afin de maîtriser plus rapidement cette façon de parler, et au bout du compte, corriger les quelques erreurs qui se seront glissées dans la mise en forme (puisque, vous vous souvenez ? mon texte n’avait pas la même apparence affiché par LibreOffice et par iBooks sur mon iPad).

Cet apprentissage déborde largement le cadre de cette série, puisqu’il s’agit d’apprendre deux langages informatiques (assez simples) complémentaires et imbriqués que sont le HTML5 et le CSS3.

Avant de poursuivre, il sera donc nécessaire pour vous d’aller traîner vos guêtres à cet endroit là, où vous pourrez très facilement et gratuitement (ce qui ne gâche rien) apprendre les rudiments qui vous manquent peut-être.

Lorsque cela sera fait, nous reprendrons le cours de cette série passionnante de dissection d’un livre au format EPUB3 pour aller encore plus loin, dans l’épisode intitulé : Dessine-moi un EPUB.