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

par | Oct 18, 2014 | L'encre & la plume, Les Pixe-Ailes du Phœnix | 0 commentaires

Dans cette double série d’articles, Making of a book, et Créer un livre électronique au format ePub3, 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 et en format électronique. 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 ePub3 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.

Attention, cet article est déconseillé aux personnes qui seraient allergiques aux codes informatiques…

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).

Un fichier ePub n’est pas un fichier de texte simple. C’est plutôt un dossier de plusieurs fichiers différents, codé dans une archive .zip, mais dont l’extension de fichier a été renommée .epub. Tout cela est bien complexe, n’est-ce pas ? C’est pourquoi je préfère utiliser un programme spécifique pour ouvrir l’enveloppe du livre et mettre à nu les rouages internes.

Sur Mac, je me sers de ePub Packager. C’est une application payante, mais très efficace et très pratique : elle extrait pour moi le dossier enfermé dans l’archive et me dépose ce dossier sur le bureau de l’ordinateur. Je n’ai plus qu’à ouvrir le dossier et fouiller à l’intérieur. Je l’utilise également dans l’autre sens, une fois mon livre terminé, pour créer l’archive ePub définitive.

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 Espresso sous Mac. 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. 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’ordre donné 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 Espresso. Pour cela soit vous glissez le fichier sur l’icône d’Espresso dans votre Dock, soit vous faites un clic droit sur le fichier que vous voulez ouvrir et vous choisissez Espresso 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.

Le fichier mimetype

Il 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

Lui non plus ne devra pas être touché, 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.

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. En l’ouvrant, vous allez trouver cinq parties distinctes, dont seules quatre seront indispensables en ePub3.

La première partie est constituée de lignes qui déclarant à quels langages informatiques on doit se référer. C’est assez compliqué et il vaut mieux ne rien changer à ces lignes 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>
Les lignes de déclaration de l'opf sans metadatas

 

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 lignes de déclaration de l'opf avec metadatas spécifiques à iBooks

 

Les balises metadata

Le premier rôle du fichier .opf est de déclarer les metadatas du livre, c’est-à-dire les informations essentielles sur son identité : 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…). Tout cela dans un langage 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, mais c’est indispensable. 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 metadatas, 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 metadatas :

    <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>
les metadatas de Scrivener

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 metadatas 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.

TypeMetadataSignificationObligatoire ou OptionnelleValeurs possiblesNote
Identification du livre : Dublin Core (dc)dc:titleLe titre de l'ouvrageObligatoireVotre imaginaire...
Identification du livre : Dublin Core (dc)dc:creatorLe ou les noms des créateurs (auteur, illustrateur)OptionnelVotre imaginaire...
Identification du livre : Dublin Core (dc)dc:identifierUn identifiant pour l'ouvrage, comme l'ISBN par exempleObligatoireVotre imaginaire...
Identification du livre : Dublin Core (dc)dc:publisherL'éditeur de l'ouvrageOptionnelVotre imaginaire...
Identification du livre : Dublin Core (dc)dc:languageLa langue principale de l'ouvrageObligatoireToutes les langues...
Identification du livre : Dublin Core (dc)dc:contributorLe ou les noms des contributeurs de l'ouvrageOptionnelVotre imaginaire...
Identification du livre : Dublin Core (dc)dc:dateLa date de publication de l'ePubOptionnelUne date quelconque au format AAAA-MM-JJ
Identification du livre : Dublin Core (dc)dc:sourceLa ou les sources de l'ouvrage (si c'est un recueil de nouvelles déjà publiées par exemple)OptionnelVotre imaginaire...
Précisions sur une baliserefinesDonne des indications sur une metadata précédenteOptionnelaut = auteur
bkd = book designer
bkp = book producer
edt = editor
cov = cover creator
ill = illustrateur
pbl = publisher
trl = translator
Rendu dans iBooks d'Appleibooks:bindingIndique si dans un livre à mise en page fixe la "pliure" du livre entre deux pages est visibleOptionneltrue, falsedans la balise package doit apparaître une ligne de définition.
Rendu dans iBooks d'Appleibooks:ipad-orientation-lockIndique si le livre est bloqué dans une orientation sur un iPadOptionnelportrait-only, landscape-onlydans la balise package doit apparaître une ligne de définition.
Rendu dans iBooks d'Appleibooks:specified-fontsIndique à iBooks qu'il doit utiliser les fontes intégrées dans l'ePubObligatoire si fontes intégrées dans l'ePub pour iBookstrue, falsedans la balise package doit apparaître une ligne de définition.
Rendu dans iBooks d'Appleibooks:versionIndique la version d'iBooks nécessaire pour lire l'ePubOptionnelUne version d'iBooksdans la balise package doit apparaître une ligne de définition.
Rendu général de l'ePubrendition:flowIndique si le rendu en flux doit être de type "site internet" ou de type "page de livre"Optionnelpaginated, scrolled-continuous, scrolled-doc, auto
Rendu général de l'ePubrendition:layoutIndique si le livre est de type mise en page fixe ou de fluxOptionnelpre-paginated, reflowable
Rendu général de l'ePubrendition:orientationIndique si le livre peut être lu en paysage, portrait, ou les deuxOptionnellandscape, portrait, auto (dans ce cas le texte sera adapté en fonction de l'orientation du système de lecture)
Rendu général de l'ePubrendition:spreadIndique si en mode paysage deux pages sont montrées ou une seule.Optionnelauto, both (dans ces cas-là, deux pages)
none (dans ce cas, une seule page même en paysage)

Le « manifeste »

La deuxième partie du fichier, la plus complexe à mon avis, est celle 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.

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>
Le manifeste créé par Scrivener

 

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>
Mon organisation du manifeste

 

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. 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.

Comme vous avez aussi pu le constater, chaque fichier doit être suivi d’un code qui explicite sa nature. On appelle ça un type « mime » (non pas à cause du Mime Marceau). Il s’agit cependant de trouver le bon type mime pour chaque fichier. Vous pouvez consulter la liste de Wikipedia, ou bien directement la très longue liste qui se trouve ici. Pour ma part j’ai fait une petite liste des fichiers les plus utilisés dans un ePub, par catégorie, ce qui rend l’intégration dans le manifeste plus aisée.

Classe de fichierExtension du fichiermedia-typeproperties
Chapitre ou partie du livre.html
.xhtml
application/xhtml+xmlnav si contient la table des matières
svg si contient des images svg
scripted si contient du javascript ou une référence javascript
Fonte de caractères.otfapplication/x-font-otf
Fonte de caractères.ttfapplication/x-font-ttf
Fonte de caractères.wofapplication/font-woff
Image.jpgimage/jpeg
Image.pngimage/png
Audio.m4aaudio/mp4
Audio (ne fonctionne pas sur iPad).mp3audio/mpeg
Vidéo.m4vvideo/mp4
Vidéo (ne fonctionne pas sur iPad).webmvideo/webm
Script d'interactivité.jstext/javascript
Feuille de style.csstext/css

Chaque « item » est référencé par un nom (« id ») et par un chemin d’accès (« href »). Vous êtes libre de donner le nom de votre choix au fichier (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 :

<item id="page_couverture" href="page_couverture.html" media-type="application/xhtml+xml" properties="svg nav scripted"></item>
Syntaxe des propriétés

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 spine créé par Scrivener

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>
Le guide créé par Scrivener

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>
le fichier livre.opf modifié par mes soins

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 contents.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 contents.xhtml généré par Scrivener

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>
Le fichier toc.ncx généré par Scrivener

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 Espresso, 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>
Le premier chapitre de Fée du Logis codé en 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;
}
...
Le fichier stylesheet.css créé par Scrivener

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.

Pin It on Pinterest

Shares