Introduction

Nous avons vu dans les deux premiers volets de cette série comment structurer la mise en forme de votre livre pour rapidement le transformer en version électronique, puis l’anatomie d’un livre électronique au format ePub3.

Vous êtes maintenant prêts à réaliser votre premier livre en ePub3.

C’est une étape qui peut facilement intimider.

Il faudra manipuler du code informatique.

Il faudra faire des tests.

Il faudra ciseler votre livre pour qu’il atteigne vos critères de qualité.

Si produire un livre papier est finalement assez naturel, le façonnage d’un livre électronique l’est beaucoup moins à ceux qui ne sont pas familiers de l’univers du code informatique.

Si j’osais une comparaison, vous allez devoir vous transformer en joaillier, car les outils dont nous disposons actuellement sont aussi versatiles que les normes des livres électroniques elles-mêmes, et aussi délicats à manier que pour la taille d’une pierre précieuse. Un simple geste de travers et votre émeraude peut rapidement être gâtée.

Mais il y a une bonne nouvelle. Des petits lutins industrieux sont là pour vous aider, comme Jiminy Panoz, par exemple, qui œuvre depuis des années pour rendre la production de livres électroniques plus simple, plus opérante, plus fluide, et plus satisfaisante pour le lecteur comme pour l’éditeur et l’auteur lui-même.

Le seul écueil encore sur votre chemin reste que nombre de ces lutins, dont Jiminy lui-même, exposent souvent leurs idées, leurs astuces, leurs méthodes, dans la langue de l’auteur du Songe d’une nuit d’été.

Je vais donc vous présenter ici ce que j’en ai retenu pour ouvrager mes propres livres. Ce sera une base je l’espère suffisante pour que vous puissiez commencer vous aussi.

Et une fois que vous les aurez maîtrisées, sans doute serez-vous prêts à en apprendre plus dans les multiples sites spécialisés qui sont hébergés sur la Toile, en anglais.

Les outils

Bien évidemment, il serait trop simple que les mêmes outils que vous avez enfin maîtrisés pour votre livre papier puissent vraiment servir pour votre livre électronique.

Même si Jiminy Panoz a conçu un petit plug-in pour InDesign permettant de facilement transposer votre maquette papier en numérique, il vous sera nécessaire, à un moment où à un autre, de mettre les mains dans le moteur. Aussi suis-je partisan d’une méthode plus artisanale, même si, vous le verrez, l’automatisation pourra être d’une certaine utilité.

Le prérequis

N’espérez pas aborder cet article facilement sans avoir au moins quelques bases dans deux langages très simples de l’informatique actuelle : le HTML5 et le CSS3. Vous pourrez faire comme moi et suivre les cours d’openclassroom à cette adresse. La pédagogie est très didactique et vous apprendrez très rapidement les quelques rudiments qui vous seront nécessaires pour comprendre ce dont nous allons parler.

Le HTML5 servira à coder le texte de votre livre. Chaque chapitre ou section importante de votre livre sera un fichier HTML5. À l’intérieur de chacun de ces fichiers, chaque paragraphe sera encadré de balises, probablement des balises <p>, ou <span>, ou <i> ou <b>. Vos citations seront soit des <blockquote> soit des <cite>. Votre table des matières sera encadrée dans une balise <nav>.

Une grande partie de cette structure de base sera déjà faite pour vous lors de l’exportation de votre texte depuis Scrivener, aussi n’aurez-vous qu’à la peaufiner ou la corriger à la marge.

Le CSS3, lui, sera la partie la plus ardue et la plus ingrate. Il contrôle la forme de votre livre, son apparence dans l’application de lecture. Bref, c’est lui qui contient la matière de vos styles, ceux que vous avez conçus dans la version papier, et que vous devez transposer (sans toujours y coller parfaitement) dans une version numérique. C’est sur cette transposition que va porter l’essentiel de notre travail.

Espresso

Pour écrire ou corriger du code numérique, on peut utiliser un simple éditeur de texte comme Notepad ou Textedit. Un fichier de code n’est en effet rien d’autre qu’un fichier de texte dont l’extension est un peu différente.

Mais il est plus aisé et plus confortable d’utiliser un logiciel qui possède quelques fonctionnalités dédiées, comme la coloration du texte en fonction de la structure du code (les instructions d’une couleur, les variables dans une autre), l’indentation automatique (chaque balise étant indentée en fonction de sa place dans l’imbrication), ou même la fermeture des balises avec des raccourcis (car une balise doit toujours être refermée lorsqu’elle se termine).

C’est pour cela que j’ai choisi Espresso.

Facile à prendre en main, épuré visuellement, il permet néanmoins de garder un œil sur la structure de livre ePub (le volet sur la gauche) et sur celle du fichier lui-même (le volet sur la droite) en même temps que l’on inspecte ou modifie le code (fenêtre principale) et que l’on navigue dans divers fichiers en utilisant les onglets sur la barre supérieure. On peut également visualiser facilement le résultat final, dans le navigateur web de son choix, en cliquant sur l’icône en forme de boussole.

Il possède une fonction de recherche et de remplacement satisfaisante et maîtrise les règles du HTML5 comme du CSS3.

Blitz

Blitz est la pièce maîtresse de la conception de mon fichier de style en CSS3.

Mis à disposition et régulièrement mis à jour par Jiminy Panoz, Blitz est un framework, un cadre de travail dans la langue de Molière, qui a été pensé et peaufiné pour faciliter le casse-tête habituel que l’on peut rencontrer en essayant de rendre homogènes les styles que l’on a conçus pour son livre électronique.

Et surtout pour les rendre opérants sur presque toutes les solutions de lecture numérique.

Car le monde numérique a un gros désavantage sur le monde papier : là où un livre papier se présentera toujours sous la même forme quelles que soient les mains qui le tiendront, chaque application de lecture va traduire un peu différemment le même code et vous allez donc obtenir un rendu différent à chaque fois. Il est donc rare que deux lecteurs aient la même présentation de votre livre sur leur liseuse, sauf s’ils utilisent le même modèle, mais aussi la même version de l’appareil, ainsi que le même système d’exploitation, avec la même version…

Afin de remédier à cela, Blitz propose une façon originale de concevoir votre code CSS3, grâce à des briques simples déjà codées pour vous, que vous pouvez d’abord paramétrer.

Ainsi, il suffit de partir de la définition simple en phrases de ce que l’on veut obtenir, de chercher quelles briques de Blitz correspondent, de les paramétrer, puis de compiler le résultat.

Compiler ? Encore ?

Oui, comme Scrivener, Blitz est une sorte de traducteur, et l’obtention de votre code final (ou du moins de sa version préfinale, avant vos petits ajustements de dernière minute) est la dernière étape de la traduction.

Car Blitz n’utilise pas à proprement parler du CSS3.

Il traduit plutôt la conception de vos briques depuis un langage un peu plus évolué, nommé le LESS (petit jeu de mots anglais sur « less » qui veut dire « moins », car le code est souvent plus court), capable entre autres d’adapter une propriété CSS à des conditions précises, ce que ne permet pas nativement le CSS3.

LESS et CSS sont très proches, aussi n’aurez-vous aucun mal à vous adapter à ses particularités.

Crunch 2

Crunch est comme Espresso, un éditeur de code. Mais il permet gratuitement de travailler sur du code LESS, et de le compiler ensuite en CSS3 (il le « crunche » pour employer le mot franglais exact). C’est donc lui qui sera votre première interface avec les briques de Blitz.

Il se présente un peu comme Espresso : volet de gauche montrant la structure du framework LESS de Blitz, éditeur dans la fenêtre principale, des onglets au-dessus.

La structure de l’ePub

Tout commence bien sûr avec l’ossature de votre livre électronique. Comme nous l’avons vu dans le volet précédent, un ePub est structuré d’une façon très précise. C’est par cette structure que vous devez débuter la réalisation.

Plusieurs possibilités s’offrent à vous.

La construire vous-même. Fastidieux, mais possible.

Vous servir du modèle que je vous ai déjà livré dans les épisodes précédents de cette série d’articles.

Vous servir du fichier que Scrivener va compiler pour vous lorsque vous aurez terminé la rédaction et la correction de votre manuscrit.

Vous servir de la structure déjà fournie avec Blitz de Jiminy Panoz.

J’ai moi-même fait un petit mélange entre les solutions 2 et 4. La structure que je vous ai déjà fournie est donc basée sur celle de Blitz, avec quelques modifications personnelles.

Ainsi, j’ai choisi de séparer dans des dossiers différents certains éléments de l’OEBPS. J’ai donc un dossier Fonts pour les fontes de caractères, un dossier Images, un dossier Styles pour les fichiers CSS3, un dossier Texte pour tout ce qui touche aux pages du livre.

Pour ouvrir cette structure, il suffit de demander à Espresso d’en faire un Projet.

Il va présenter la hiérarchie de votre dossier sur la gauche, et en double-cliquant sur chaque fichier, vous pourrez l’ouvrir dans son interface.

L’avantage du squelette de Blitz réside dans le fait qu’il intègre des fichiers codés spécifiquement pour certaines pages spécifiques d’un livre. La couverture (cover.xhtml), la dédicace (dedication.xhtml), mais aussi la bibliographie, l’index, le glossaire, les remerciements, la préface, l’avant-propos, l’épilogue, et j’en passe. Chacune de ces pages contient un code epub:type qui permet de la caractériser de façon correcte pour que votre livre respecte la norme sémantique ePub3.

Vous n’aurez que trois choses à modifier sur chaque page.

Le xml:lang= »en » qui déclare que la langue principale est en anglais devra contenir la variable « fr » puisque vous écrirez en français.

Le nom éventuel des fichiers de style (ici c’est blitz.css et blitz-kindle.css) pour coller à vos propres styles. J’ai pour ma part conservé les noms originaux.

Le code de votre chapitre à la place de la balise de commentaire <!– Your contents here –>.

Vous voici prêts à débuter.

Toujours une question de styles

Quel est le vôtre ?

Êtes-vous du même genre que moi, à essayer de trouver une identité graphique très codifiée pour vos écrits, avec l’idée sous-jacente que, en papier ou en numérique, un de vos ouvrages doit être reconnaissable entre mille ?

Ou avez-vous en tête que la forme d’un livre doit être assez standard ?

Quoi qu’il en soit, vous devez déterminer quels seront les styles utilisés par votre texte.

Comment les paragraphes vont-ils apparaître ? Seront-ils indentés ou séparés par un petit espace, ou bien les deux (ce que je trouve personnellement hideux, mais tous les goûts sont dans la nature) ? Quelle police de caractère allez-vous utiliser ? Allez-vous utiliser les césures ?

Une fois que vous aurez les réponses à toutes ces questions, vous aurez déjà construit la plus grande partie de vos styles.

Mon flux

Comme pour la version papier, je pars de la base de mon manuscrit dans Scrivener.

Nous l’avons déjà vu dans l’article sur la version papier, je me sers d’un format de compilation particulier.

Pour la version papier je compile dans le format .rtf, pour la version électronique je me sers du format ePub3 que Scrivener génère.

Un texte marqué avec un nom de style particulier dans Scrivener (ou dans Word ou dans LibreOffice) gardera attaché le nom de ce style une fois compilé.

Ainsi, comme nous l’avons vu, j’ai créé un style dans Scrivener qui me permet de marquer les portions de texte qui sont vues par un autre angle, ou qui désignent une scène décalée temporellement ou spatialement, des flashbacks.

La compilation de Scrivener peut marquer le texte stylé pour le lier à la feuille de style CSS.

Il n’est donc besoin que ne marquer une seule fois le texte original, pour y appliquer ensuite les styles propres à chaque canal de diffusion : livre papier dans InDesign, livre électronique dans Espresso ou Sigyl.

Les styles nécessaires

Pour un livre électronique, vous allez avoir besoin de créer quelques styles.

• Bien sûr, le style de votre texte (parfois il peut y en avoir plusieurs, d’ailleurs).
• Le style des titres de chapitre.
• Le style du nom de l’auteur.
• Le style de l’éventuelle collection ou de l’éventuelle série.
• Le style des mentions légales.
• Le style du titre du livre.
• Le style de la table des matières.

Il sera inutile de prévoir des styles de numéros de page, puisque la lecture électronique se distingue justement par le fait que c’est l’application de lecture qui gère ce genre de choses, pas l’auteur ou l’éditeur.

D’ailleurs, une précision importante qu’il est sans doute bon de rappeler même si nous l’avons évoquée dans le premier volet de cette série est que le lecteur pourra, en version numérique, agir sur la forme que vous avez voulu donner à votre livre. Il pourra en changer les styles à sa convenance. Augmenter la taille de la police de caractères, aligner le texte à gauche ou le justifier, en changer la couleur, voire changer complètement la police de caractères ou même passer l’application en mode nuit.

Au final, votre feuille de style si patiemment élaborée ne sera qu’une proposition que le lecteur sera libre ou non d’accepter.

Je sais, c’est frustrant.

Mais c’est le jeu.

C’est pour cela que je prévois d’insérer au début du livre une page dénommée « Avertissement » dans laquelle j’indique au lecteur que l’ouvrage a été pensé avec une maquette numérique en tête, et qu’il pourra tirer le meilleur parti de sa lecture en activant ces styles.

Pour revenir à nos moutons, il se peut que vous ayez besoin de créer d’autres styles pour des raisons inhérentes à votre projet ou à votre texte (par exemple, le style de mes scènes intriquées, ou un style imitant un message informatique ou SMS).

Dans tous les cas, ce sont globalement les mêmes que dans votre projet Scrivener. À la différence près que les styles de Scrivener ne servent que pour marquer le texte sans véritablement lui donner une identité, et que cette dernière est définie dans les styles de la feuille CSS3.

Par exemple, mon corps de texte est défini pour ma maquette papier par un style de paragraphe justifié, sans retrait global, mais avec un retrait de première ligne, et un style de caractère de fonte Sorts Mill Goudy normal de corps 10 pixels avec un interlignage de 13 pixels, des ligatures communes et discrétionnaires activées.

La fonte Sorts Mill Goudy est assez bien adaptée à la lecture numérique (contrastes assez forts pour éviter les confusions de lettres, jambages assez grands), j’ai donc décidé de la garder, ce qui crée une unité d’identité entre les deux versions. Mais sur une tablette une taille de 10 pixels est trop faible pour être agréable. J’ai donc basculé sur une taille de 15 pixels, et gardé un interligne de 1,3, ce qui permet de conserver un aspect cohérent avec les proportions de la version papier. Quant aux ligatures, elles sont activées si l’application de lecture le permet, grâce à une astuce particulièrement maligne de Blitz que nous verrons plus tard, nommée « amélioration progressive » par Jiminy Panoz.

Compiler l’ePub depuis Scrivener

Une fois dressée la liste de vos styles, l’étape suivante est d’obtenir une version préliminaire de votre texte traduit dans le format ePub3. C’est le traditionnel passage par la compilation de Scrivener.

La version 3 du logiciel est en effet capable d’exporter votre texte dans le format ePub3, même si ce n’est pas avec le même raffinement que notre travail artisanal. Je me sers donc de cette base pour obtenir le code HTML5 de chaque chapitre de mon livre.

La marche à suivre vous est maintenant familière depuis que nous l’avons apprivoisée avec la version papier.

En sélectionnant Fichier > Compiler… vous êtes conduits à la fenêtre de compilation.

Vous pouvez vous servir du format de compilation Publication que je partageai avec vous il y a quelque temps déjà.

Dans ce cas vous le sélectionnez, et veillez ensuite à ce que le format de sortie soit ePub3. Vous cochez les chapitres que vous voulez inclure dans la compilation, ainsi qu’éventuellement la préface et la postface, et vous cliquez sur Compiler.

Scrivener crée donc un fichier ePub totalement fonctionnel, mais assez brut, dont nous ne garderons que les fichiers correspondants aux chapitres.

Pour ce faire, il faut ouvrir l’ePub avec ePub Packager, et extraire les fichiers HTML5 de votre texte. Pour ma part je les mets dans un dossier rangé à part. Et je détruis ce qu’il reste de l’ePub généré par Scrivener.

Petite incursion dans mon format de compilation

Au passage, nous pouvons détailler un peu le format de compilation Publication d’écaille & de plume, afin de vous montrer une petite astuce qui permettra que tous vos styles soient correctement marqués par Scrivener pour être parfaitement reconnus dans la feuille de style CSS3.

En vous rendant sur Fichier>Compiler… puis en faisant un clic droit sur le format de Publication, vous entrez dans la modification du format de compilation.

Sur la colonne de gauche, sélectionnez ePub3 pour faire apparaître les réglages spécifiques à cette exportation.

Puis descendez dans la colonne et cliquez sur Styles.

Cliquez sur le Style Scène intriquée. Vous vous rappelez ? C’est le style que j’ai créé dans Scrivener pour marquer les passages de flash-back ou de scènes qui se déroulent à un autre endroit en même temps dans le texte.

Dans la colonne de droite vous allez remarquer que dans la case CSS Class Name, j’ai noté italic.

Lors de la compilation de mon texte, les paragraphes qui seront marqués dans Scrivener comme des Scènes intriquées seront marqués dans le codage HTML5 avec la classe CSS3 italic, qui sera utilisée plus tard pour rendre leur apparence différente de celle des autres paragraphes.

Ainsi, automatiquement, tous mes paragraphes seront marqués sans que j’aie à m’en soucier.

De la même façon, j’ai créé un style de caractère pour les quelques premiers mots d’un chapitre, que j’ai nommé Première phrase de chapitre. Et son CSS Class Name sera first-sentence, qui fera référence au même nom dans la feuille de style CSS3 générée là encore automatiquement par Blitz une fois que vous l’aurez correctement paramétré.

Malin, non ?

Bien utilisée, la combinaison Scrivener/Blitz va vous faire gagner beaucoup de temps.

Blitz krieg

Une fois le texte exporté en HTML5, il est temps de nous occuper de la traduction de vos styles en CSS3.

C’est le rôle de Blitz, que vous pouvez télécharger ici. Vous aurez aussi une documentation (en anglais, mais très intéressante) ici. Je vais essayer pour ma part de vous guider dans ce que j’ai retenu de son utilisation, en me basant sur le tutoriel d’introduction mis à disposition par Jiminy lui-même sur Medium.

Il faut considérer Blitz comme un jeu de construction, où chaque brique peut être paramétrée.

Blitz comme une API

On peut tout d’abord se servir de Blitz comme d’un générateur de classes CSS, c’est-à-dire comme une base de code qui permet de donner des propriétés esthétiques et de positionnement à une balise HTML.

Par exemple, si nous voulons que les paragraphes simples du texte soient indentés et justifiés, il suffira d’attribuer les classes correspondantes (indent et justified respectivement) comme classe à nos balises <p> et Blitz aura généré le code tout seul. Cela donnera le code suivant dans le fichier HTML de votre chapitre.

<p class="indent justified">Ceci est un paragraphe indenté et justifié</p>

Dans ce cas-là, vous pouvez simplement vous servir du fichier blitz.css déjà fourni par Jiminy Panoz dans l’archive zip que vous avez téléchargée, et appeler les classes CSS qu’il a déjà paramétrées lorsque vous en aurez besoin pour votre texte.

Mais cela suppose que vous précisiez à chaque ligne de votre texte comment styler le paragraphe. Même avec les fonctions de recherche et de remplacement des logiciels, c’est fastidieux, car il faudra probablement que vous vérifiiez à chaque fois que votre paragraphe doit bien être stylé de cette façon. Si au beau milieu de votre texte vous avez des paragraphes de flash-back que vous vouliez présenter différemment (par exemple sans indentation), il vous faudra parcourir tout le texte pour faire vos modifications.

De plus, vous n’utiliserez alors que les classes principales de Blitz, en vous fermant la possibilité dont nous parlions tout à l’heure, c’est-à-dire l’amélioration progressive.

L’amélioration progressive

C’est un constat frustrant que chaque solution de lecture gère les possibilités de codage différemment, et que selon que votre lecteur utilisera une tablette Kobo ou Kindle, un iPad ou un ordinateur votre style apparaîtra différemment, mais aussi qu’il est possible qu’une application de lecture qui ne supporte pas les ligatures pour votre texte, par exemple, pourra très bien arrêter de comprendre votre fichier CSS complètement, ce qui engendrera un gros bug visuel et gâchera l’expérience de lecture d’une façon extrêmement désagréable.

Pour remédier à cela, et pour tout de même présenter à vos lecteurs ce que vous aviez prévu, l’amélioration progressive pose les fonctionnalités par couches successives. La base de votre présentation sera celle qui sera lisible par toutes les applications de lecture. Puis vous prévoirez dans votre fichier les fonctionnalités qui pourront apparaître si l’application les supporte. Ainsi, votre texte pourra être lisible dans tous les cas, et s’améliorera en présentation en fonction des capacités de l’application de lecture.

Blitz gère ça avec ce que l’on appelle les media-queries (ou requêtes de média en bon français) qui permettent de poser des conditions au code.

Par exemple, avec la syntaxe

@supports {amélioration{mettre en place l’amélioration}}

votre application de lecture saura quelle amélioration enclencher si elle est capable de la supporter. Les applications qui ne sauront pas le faire en resteront aux fonctionnalités basiques que vous aviez déjà prévues, voire aux fonctionnalités codées dans la syntaxe

@supports not {amélioration{fonctions basiques en cas de non-support}}.

Construction modulaire du fichier LESS

L’autre façon, la meilleure, de se servir de Blitz, est de construire un fichier CSS sur mesure.

Pour cela, nous allons faire nos paramétrages dans Crunch 2. Après avoir ouvert le logiciel, cliquez sur l’icône de dossier avec un signe + et ouvrez le dossier LESS. Puis parcourez l’arborescence de fichiers sur le volet de gauche. Si vous double-cliquez sur le fichier blitz.less, il sera ouvert dans la fenêtre principale.

Le fichier blitz.less

Ce fichier est le moteur du générateur Blitz. C’est lui qui détermine quelles options vous sont ouvertes pour générer le code CSS3 final.

La partie Namespaces permet de déclarer les normes auxquelles le fichier se réfère.

C’est ici que l’on peut déjà commencer à déclarer les fontes particulières que vous voudrez utiliser dans votre texte. Par exemple, pour ma police Sorts Mill Goudy, il suffit que j’insère la référence, en n’oubliant pas de spécifier à quel endroit de l’ePub se trouve le fichier de la fonte (ici dans le dossier Fonts).

Ainsi :

@font-face {
font-family: 'Sorts Mill Goudy';
src:  url('../Fonts/GoudyStM.otf');
}

@font-face {
font-family: 'Sorts Mill Goudy italic';
src:  url('../Fonts/GoudyStM-Italic.otf');
}

Vous pouvez par contre remarquer que la partie Begin CSS (début du CSS) contient 6 parties.

Les références sont des fichiers qui ne seront pas intégrés dans le code final, mais qui servent à paramétrer d’autres parties du code.

La partie core (ou noyau) est le cœur des variables qui vont générer le rythme des espaces et du texte, gérer les distances entre les paragraphes, les lignes, les tailles des caractères.

La partie base contient les styles qui sont nécessaires à presque tous les ouvrages électroniques.

Les extensions sont des petits ajouts qui vous seront peut-être utiles.

Les utilities (ou utilitaires) sont des références qui sont exportées par défaut dans le code final.

Enfin, le plug-in kindle permet de générer quelques spécificités pour le système de lecture d’Amazon.

Comme j’ai envie de me servir des fonctions d’amélioration progresives de Blitz, j’ai déplacé le fichier blitz-progressive.less dans la partie utilitaires et j’ai enlevé la parenthèse qui le marquait comme référence. Ainsi, le code CSS généré contiendra les styles rattachés à des fonctions avancées. De la même façon, comme j’ai besoin de paramétrer les césures (hyphens en anglais), pour le fichier hyphens.

Le noyau : variables.less

Il y a là deux réglages fondamentaux qui peuvent être très utiles si vous avez l’intention de doter votre ePub3 de polices de caractère un peu différentes de celles qui sont fournies par les applications de lecture. Il s’agit de la taille du corps de votre police (@body-font-size) et de la hauteur de l’interligne (@body-line-height). Par défaut, le premier paramètre est à 16 pixels et le deuxième à 1,5.

Ce réglage fonctionne avec la plupart des fontes.

Pour ma part, afin de caler l’impression de lecture sur la version papier, j’ai utilisé une fonte un peu haute (Sorts Mill Goudy), qui donne donc une impression massive inélégante en taille 16 pixels. Et le rythme de succession des lignes semble plus harmonieux avec un interligne réglé à 1,3. J’ai donc simplement changé ces réglages. Je n’ai rien touché d’autre.

Pour ce qui est du deuxième fichier du dossier core, rythm.less, je n’y ai pas touché non plus. Il s’agit d’un algorithme savamment dosé que je ne voulais pas casser.

La base

Ce sont les fondations du code CSS qui sera généré.

La première fondation est ce qu’on appelle le reset. Il remet à zéro tous les réglages que l’application de lecture peut avoir modifiés auparavant. Cela vous assure que votre code sera toujours basé sur quelque chose de propre, puisque remis à zéro. Il n’est pas nécessaire de toucher ce fichier.

Ensuite vient le fichier page.less. Il règle les paramètres d’une page de votre livre. Là encore, à moins que vous ne préfériez augmenter les marges de votre page, pas besoin d’y toucher.

La typographie

Le fichier typo.less est celui que vous allez le plus modifier.

C’est ici que vous allez pouvoir déterminer que tous vos paragraphes <p> seront indentés et justifiés par défaut, par exemple. Il suffit pour cela de trouver la classe <p>, et de lui appliquer une classe indent et justified. Car, oui, contrairement à un code CSS, un code LESS peut imbriquer des classes les unes aux autres.

C’est la puissance de la modularité de Blitz.

Les classes déjà paramétrées par Jiminy peuvent être utilisées comme des briques qui vont construire vos propres classes.

Par exemple, pour construire mon style de paragraphes pour le copyright, dénommé bien entendu copyright, voici le code LESS que j’ai inséré dans ce fichier.

.copyrights {
.fs-s;
.no-indent;
.disable-hyphens;
.align-center;
}

Il déclare que la taille de la police doit être petite, qu’il ne doit pas y avoir d’indentation ni de césure, et que le paragraphe doit être centré. Sans utiliser une seule ligne de code CSS ! Il suffit de décrire ce que vous voulez voir, et Blitz le code pour vous…

De même, pour l’amélioration progressive.

Si je veux que mes paragraphes utilisent les ligatures (clig, les ligatures communes, dlig, les ligatures discrétionnaires), le code LESS sera :

p {
    .indent;
    .justified;
    .supports-clig({
    .clig;
  });
.supports-dlig({
    .dlig;
  });
}

La compilation du fichier LESS en CSS

Il existe une multitude d’autres choses que vous pouvez paramétrer avec Blitz, notamment comment les images seront gérées, comment certains objets seront centrés, comment la hauteur de certains objets (dont les images) pourra être déterminée par la hauteur de l’écran de l’appareil de lecture, etc. Mais cela n’entre pas dans le cadre de cet article.

Sachez seulement que le principe sera toujours le même, celui de la modularité.

Et une fois que vous avez complété votre paramétrage de tous les fichiers contenus dans le framework LESS, il est temps de compiler votre fichier CSS3 final. Dans Crunch 2, il suffit de cliquer sur l’icône en forme de d’étau ou de C majuscule sur la droite de la fenêtre.

Et voici le fichier qui sera exporté.

@charset "UTF-8";
/*  blitz — CSS framework for reflowable eBooks      
    Version 1.1.2 by Jiminy Panoz                      
    Codename: Idle in Kangaroo Court W1                              
    License: MIT (https://opensource.org/licenses/MIT)   */
/* NAMESPACES */
@namespace h "http://www.w3.org/1999/xhtml/";
@namespace epub "http://www.idpf.org/2007/ops";
/* if you need to style epub:type */
@namespace m "http://www.w3.org/1998/Math/MathML/";
/* if you need to style MathML */
@namespace svg "http://www.w3.org/2000/svg";
/* if you need to style SVG */
@font-face {
  font-family: 'Sorts Mill Goudy';
  src: url('../Fonts/GoudyStM.otf');
}
@font-face {
  font-family: 'Sorts Mill Goudy italic';
  src: url('../Fonts/GoudyStM-Italic.otf');
}
html {
  /* Don't use it for styling, used as selector which can take a punch if anything goes wrong above */
}
/* Begin CSS */
/* RESET */
/* So here's the trick, we must reset to manage a number of problems once and for all: 
- HTML5 backwards compatibility (EPUB 3 file in EPUB 2 app); 
- user settings (e.g. line-height on Kobo and Kindle); 
- CSS bloat (DRY); 
- KFX for which a reset using `border: 0` seems to disable support; 
- etc.
It all started as a normalize and became a reset given the magnitude of the task.                                                          
*/
article,
address,
aside,
blockquote,
canvas,
dd,
details,
div,
dl,
dt,
figure,
figcaption,
footer,
h1,
h2,
h3,
h4,
h5,
h6,
header,
hr,
li,
main,
nav,
ol,
p,
pre,
section,
summary,
ul {
  margin: 0;
  padding: 0;
  /* RS may apply vertical padding to el such as p */
  font-size: 1em;
  /* Font size in pixel disable the user setting in legacy RMSDK */
  line-height: inherit;
  /* Kindle ignores it, Kobo needs it. If you don’t use inherit, the user setting may be disabled on some Kobo devices */
  text-indent: 0;
  font-style: normal;
  font-weight: normal;
}
/* This is absolutely necessary for backwards compatibility */
article,
aside,
figure,
figcaption,
footer,
header,
main,
nav,
section {
  display: block;
}
[hidden] {
  display: none;
}

/* Le reste du Reset, que je ne retranscris pas ici... */

/* PAGE LAYOUT */
@page {
  margin: 30px 30px 20px 30px;
  /* Recommended by Barnes & Noble in this old spec: https://simg1.imagesbn.com/pimages/pubit/support/pubit_epub_formatting_guide.pdf */
  padding: 0;
}
body {
  font-size: 93.75%;
  line-height: 1.3;
  margin: 0;
  /* RS will override margins anyways */
  padding: 0;
  widows: 2;
  /* iBooks and Kobo support widows and orphans */
  orphans: 2;
}
/* TYPOGRAPHY */
h1,
h2,
h3,
h4,
h5,
h6,
blockquote p cite,
dt,
pre,
address,
table,
caption,
th,
td,
p,
.align-left,
.align-center,
.align-right,
.caption,
.no-hyphens {
  adobe-hyphenate: none;
  /* proprietary for Legacy RMSDK */
  -ms-hyphens: none;
  -moz-hyphens: none;
  -webkit-hyphens: none;
  -epub-hyphens: none;
  hyphens: none;
}
/* Je ne retranscris pas non plus les codes pour les titres et on passe directement à ce que nous avons modifié dans Blitz */
p {
  font-family: "Sorts Mill Goudy", "Minion Pro", "Iowan Old Style", Palatino, "Palatino Linotype", "Palatino Nova", "BN Amasis", Cambria, FreeSerif, "Times New Roman", serif;
  text-indent: 1em;
  /* Designed as a class for body — We don't enforce as user setting > author */
  text-align: justify;
  adobe-hyphenate: auto;
  /* proprietary for Legacy RMSDK */
  -ms-hyphens: auto;
  -moz-hyphens: auto;
  -webkit-hyphens: auto;
  -epub-hyphens: auto;
  hyphens: auto;
  /* before and after not in spec but iBooks support all three (-webkit-) */
  -ms-hyphenate-limit-lines: 2;
  -moz-hyphenate-limit-lines: 2;
  -webkit-hyphenate-limit-lines: 2;
  hyphenate-limit-lines: 2;
  /* No support except Trident (Windows) */
  -ms-hyphenate-limit-chars: 6 3 2;
  -moz-hyphenate-limit-chars: 6 3 2;
  -webkit-hyphenate-limit-before: 3;
  -webkit-hyphenate-limit-after: 2;
  hyphenate-limit-chars: 6 3 2;
  /* No support except Trident (Windows) */
  -ms-hyphenate-limit-zone: 10%;
  -moz-hyphenate-limit-zone: 10%;
  -webkit-hyphenate-limit-zone: 10%;
  hyphenate-limit-zone: 10%;
  /* No support */
  -ms-hyphenate-limit-last: always;
  -moz-hyphenate-limit-last: always;
  -webkit-hyphenate-limit-last: always;
  hyphenate-limit-last: always;
}
@supports [1]-ms-font-feature-settings: "liga") or (-webkit-font-variant-ligatures: common-ligatures) or (font-variant-ligatures: common-ligatures {
  p {
    -ms-font-feature-settings: "liga";
    -webkit-font-variant-ligatures: common-ligatures;
    font-variant-ligatures: common-ligatures;
  }
}
@supports [2]-ms-font-feature-settings: "dlig") or (-webkit-font-variant-ligatures: discretionary-ligatures) or (font-variant-ligatures: discretionary-ligatures {
  p {
    -ms-font-feature-settings: "dlig";
    -webkit-font-variant-ligatures: discretionary-ligatures;
    font-variant-ligatures: discretionary-ligatures;
  }
}
.footnote {
  font-size: 0.93333333em;
  line-height: 1.39285714;
  text-indent: 0;
}
blockquote {
  margin: 1.3em 5%;
}
blockquote p {
  text-indent: 0;
  font-style: italic;
}
blockquote p i,
blockquote p em,
blockquote p cite {
  font-style: normal;
}
address {
  /* Styles */
}
.copyrights {
  font-size: 0.93333333em;
  line-height: 1.39285714;
  /* proprietary for Legacy RMSDK */
  adobe-hyphenate: none;
  /* proprietary for Legacy RMSDK */
  -ms-hyphens: none;
  -moz-hyphens: none;
  -webkit-hyphens: none;
  -epub-hyphens: none;
  hyphens: none;
  text-indent: 0;
  /* Necessary as RS may define text-indent for p */
  text-align: center;
}
.dedicace {
  /* Don't use that with span if i, cite, dfn or em can be used */
  font-style: italic;
  /* proprietary for Legacy RMSDK */
  adobe-hyphenate: none;
  /* proprietary for Legacy RMSDK */
  -ms-hyphens: none;
  -moz-hyphens: none;
  -webkit-hyphens: none;
  -epub-hyphens: none;
  hyphens: none;
  text-indent: 0;
  /* Necessary as RS may define text-indent for p */
  text-align: right;
  margin-left: 20%;
  margin-top: 5.2em;
}

/* FIGURES + IMAGES  */
figure {
  page-break-inside: avoid;
  break-inside: avoid;
  margin: 1.3em 0;
}
figcaption,
.caption {
  font-size: 0.93333333em;
  line-height: 1.39285714;
  text-indent: 0;
}
img {
  width: auto;
  max-width: 100%;
  /* Note: KF8 doesn't support max-width hence "width: auto;" as fallback */
  height: auto;
  object-fit: contain;
}
/* Note: portrait image styling + figcaption is a nightmare */
/* See https://github.com/jstallent/ImagesSingleFile for the css hack */
img.portrait {
  width: auto;
  max-width: 100%;
  /* Note: KF8 doesn't support max-width hence "width: auto;" as fallback */
  height: 100%;
  /* We try to prevent blank page after */
  max-height: 95%;
  /* Max value iBooks enforces */
}
.float-left img,
.float-right img {
  width: 100%;
  /* If it’s auto, image in floating container will overflow on Kobo iOS + Kindle */
}
@supports (height: 99vh) {
  img.portrait {
    height: 99vh;
  }
}
/* ETC... */

C’est ce fichier qui déterminera l’apparence de votre livre. Et vous l’aurez créé en un minimum d’effort.

Merci Jiminy !

Greffe des chapitres créés par Scrivener

Il est temps de greffer les chapitres exportés par Scrivener dans la coquille pour l’instant presque vide de votre maquette d’ePub3.

Pour ma part, comme la partie <head> de ces fichiers n’est pas aussi optimisée que celle fournie par Blitz, j’ouvre chaque chapitre créé par Scrivener et je sélectionne tout ce qui se trouve entre les balises <body> et </body> du fichier. Je copie ce bloc, et le viens le coller à l’endroit où Blitz indique Your content here. Dans la maquette que je vous ai fournie, c’est à la place du code :

<p>Ici c’est votre texte qui prend forme.</p>

<p>le reste du texte</p>

Et je recommence pour chaque chapitre en créant auparavant à chaque fois un fichier chapitre_numéro-de-chapitre.xhtml identique à ceux qui sont donnés en modèle.

Je n’oublie pas de déclarer chaque nouvel ajout dans le fichier opf, bien entendu (si vous ne vous souvenez plus de ce qu’est le fichier opf, faites un nouveau détour par l’épisode 2 de cette série, ePub Anatomy), en y notant dans le manifeste :

<item href="Texte/Chapitre_numéro-de-chapitre.xhtml" id="Chapitre_numéro-de-chapitre.xhtml" media-type="application/xhtml+xml"/>

Et dans le spine :

<itemref idref="Chapitre_numéro-de-chapitre.xhtml" linear="yes" />

Nettoyage des balises HTML

Cependant, comme Scrivener n’a pas de style pour les paragraphes classiques, il a la sale manie de coller un code de style sur chaque balise <p> qui n’a pas une classe CSS particulière. Cela se manifeste par une balise <span style= »color:#000000″></span> du plus mauvais effet.

Heureusement, il suffit de se servir de la fonction de recherche et remplacement d’Espresso pour remplacer d’abord la séquence de code <p><span style= »color: #000000″> par un simple <p>, puis la séquence </span></p> par un simple </p>.

Il ne faudra pas oublier de chasser les quelques balises </span> qui auront été oubliées, car contiguës à d’autres balises qu’à une balise </p>.

Une fois que cela sera fait, votre texte sera prêt. Vous avez fait le plus gros.

Vous pourrez aisément vérifier l’apparence de vos chapitres en visualisant le rendu grâce à la fonction d’Espesso le permettant (la boussole en haut de la fenêtre).

Les pages liminaires

Comme nous en avons déjà discuté dans l’épisode 2 de la série d’articles Making of a book, un livre ce n’est pas seulement que vos chapitres. C’est aussi d’autres pages comme une préface, un index, une bibliographie.

Chaque partie aura besoin d’un fichier de texte, comme chacun de vos chapitres.

De la même façon que vous l’avez fait auparavant, vous devrez y importer votre texte.

Et soit vous aurez déjà pensé vos styles auparavant (c’est par exemple ce que nous avons fait avec la classe CSS3 copyright dont nous parlions auparavant, et qui servira aux mentions légales de votre livre) ce qui vous fera gagner du temps puisque vous n’aurez qu’à appliquer le style correspondant à vos balises HTML, soit vous avez décidé d’utiliser les classes préfabriquées par Blitz pour déterminer a posteriori quelle apparence auront ces pages.

Dans ce dernier cas, vous allez devoir coder votre page HTML dans Espresso pour ajouter des classes et visualiser le rendu ensuite dans un navigateur internet de votre choix ou dans celui du logiciel lui-même, qui est assez bon pour cela je trouve. Cela peut être long, mais heureusement il y a souvent peu de texte dans les pages liminaires par rapport au corps d’un livre.

La navigation : fichier nav

Comme nous l’avons vu dans l’épisode 2 de cette série, ePub Anatomy, un ePub3 a besoin d’un fichier dédié à la navigation, encadré par des balises <nav epub:type= »toc »>.

Pour peaufiner votre livre électronique, vous aurez donc besoin de compléter ce fichier en y insérant les références de tous les chapitres de votre texte accessibles à la navigation, donc y compris les pages liminaires dont vous souhaiter intégrer les références dans le sommaire.

Ce sommaire est matérialisé par une liste en code HTML5, avec des balises <li> encadrées par une balise <ol>. Chaque ligne contient un lien avec une balise <a> qui mène au fichier correspondant au chapitre.

La navigation, fichier ncx

De la même façon, afin de garantir une rétrocompatibilité avec les solutions de lecture ePub2, il sera intéressant de remplir le fichier de navigation de cet ancien format, le fichier ncx.

Vous y mettrez les mêmes informations, mais codées différemment, entre des balises <navMap> encadrant des <navPoint>.

Les images

Les images sont parmi les objets les plus délicats à manier dans un fichier ePub.

Tout d’abord, elles doivent respecter certaines règles de taille et de poids.

En effet, l’iBookstore d’Apple exige que les images intérieures (même la couverture intérieure donc) ne dépassent pas les 4 millions de pixels.

Ensuite, le code CSS3 qui permet de les afficher correctement (notamment sans qu’elles soient coupées en deux entre deux pages) est assez complexe.

Enfin, leur positionnement est toujours délicat, notamment si vous voulez les centrer au milieu de la largeur de la page avec une taille définie.

C’est une des raisons pour lesquelles les modules de Blitz sont si intéressants. Ils ont été soignés pour éviter ces écueils.

Pour ma part, je fais un usage immodéré des classes Blitz telles que wrap-pourcentage qui permettent de centrer l’image en lui donnant une taille définie par le pourcentage indiqué, et portrait, qui permet de s’assurer que l’image est contenue au maximum de la hauteur de l’écran.

La couverture, elle, suit des règles différentes. Elle n’a notamment pas les limitations des images destinées à la maquette intérieure. Et elle est intégrée seulement dans le fichier qui contient le paramètre epub:type= »cover ».

On peut par contre lui appliquer les mêmes classes, notamment portrait.

Métamorphose en ePub

Une fois toutes ces étapes franchies, votre ePub est prêt à naître.

Il vous suffit de le glisser dans la fenêtre d’ePub Packager, puis de cliquer sur l’icône avec la flèche vers la droite notée Open. L’application vous ouvre une fenêtre qui montre l’emplacement de l’ePub généré.

Vous êtes presque au bout de vos peines. Normalement.

Le test ePubCheck

Car un ePub n’est pas vraiment un ePub tant qu’il n’a pas passé l’épreuve ePubCheck. Cette application en lignes de commande permet de savoir si votre fichier respecte bien toutes les normes de l’ePub, sur la forme comme sur le fond, sur le codage comme sur l’organisation et la hiérarchie, la syntaxe, bref : tout.

C’est un outil très pointilleux qui ne va laisser passer aucune erreur.

Aucune.

SAUF.

Certaines erreurs de frappe. Par exemple, comme cela m’est arrivé, avec des paramètres CSS tels que margin-left:20% si comme moi vous êtes étourdis et écrivez margin-left:2a0%.

L’ePub passera le test, mais sera affiché de façon complètement erratique sur une liseuse.

Le plus simple pour soumettre votre epub au test est cependant une interface graphique nommée ePubChecker, distribuée gratuitement par Pagina. Il suffit de glisser-déposer votre ePub dans la fenêtre d’ePubChecker, et l’application l’analyse, pour vous renvoyer les erreurs éventuelles, avec un écran rouge, ou vous avertir de la validation avec un écran vert.

Le test ultime : les différentes applications de lecture

Enfin, pour vous assurer que tout se passe bien, je ne saurai trop vous conseiller de tester votre fichier sur différentes applications de lecture, et au moins sur une liseuse, pour vous rendre compte du résultat en dehors d’un environnement informatique évolué qu’est l’ordinateur personnel.

Les liseuses embarquent des interpréteurs souvent plus tatillons que les navigateurs internet sur lesquels sont basés les logiciels tels qu’Espresso, par exemple.

Et comme nous venons de le voir, le test ePubCheck est incapable de donner un rendu de votre livre.

Il est donc important de savoir comment votre feuille de style se comporte sur une liseuse, si votre texte est lisible, formaté selon vos souhaits. En utilisant Blitz, vous avez une certaine garantie, mais même Blitz ne peut pas tout prévoir…

The eBook Identity, la Lecture dans la Peau

Vous savez dessiner un ePub3, mais il y a d’autres règles qui ne concernent pas véritablement le codage. Et vous devez les connaître pour que votre livre puisse véritablement avoir une identité.

Couverture, couverture

La couverture est la principale marque d’identité de votre livre. Comme nous en avons discuté pour la version papier, elle est l’interface avec votre public. Dans le cas d’un livre électronique, c’est même presque la seule, car c’est la couverture qui servira d’icône sur le bureau de votre ordinateur, comme elle servira d’image sur la page de la librairie en ligne.

Faites-en donc une version extrêmement haute définition, qui sera à fournir à votre libraire virtuel.

Quant à celle qui servira dans votre fichier lui-même, Apple recommande qu’elle soit au moins de 1440 pixels de large, et Amazon de 1660 pixels de large, mais n’hésitez pas à la faire plus grande encore. Par contre, optimisez-en son poids, afin de ne pas trop augmenter la lourdeur de votre fichier.

ISBN

Les livres numériques doivent avoir un ISBN, un numéro unique à treize chiffres qui identifie chaque édition de chaque ouvrage publié à travers le monde. Comme un livre numérique est considéré comme une édition différente de la version papier du même ouvrage si elle existe, son ISBN devra être différent.

Il devra être intégré dans le code du livre (dans le fichier opf), mais aussi visible par le lecteur (sur une page dédiée, appelée colophon, par exemple).

Nous discuterons d’ailleurs plus en détail des obligations légales diverses et variées dans un article dédié.

Dépôt légal

À la différence d’un livre papier, il n’existe pas d’obligation de dépôt légal d’un livre numérique en France.

Les robots de la Bibliothèque Nationale de France se chargent d’écumer le web à la recherche de tous les ouvrages numériques, et vous n’aurez donc pas de formalités à accomplir de ce côté-là.

It’s a Kindle of magic

Enfin, malgré le fait que le format Kindle ne soit pas vraiment de l’ePub3 vous serez obligés de proposer une version de votre livre adaptée à l’écosystème de lecture d’Amazon du fait de son extrême et écrasante majorité chez les possesseurs de ces applications de lecture.

La bonne nouvelle c’est que c’est presque Amazon qui le fait pour vous.

Il vous suffit de télécharger gratuitement Kindle Previewer 3, le logiciel maison d’Amazon chargé de la conversion vers le format propriétaire. Jiminy Panoz (encore lui !) en avait fait un petit article de test en 2016.

Une fois votre livre importé par simple glissé-déposé, KP3 mouline pendant un long moment et vous permet de simuler les applications Kindle sur différents appareils, afin d’en vérifier le rendu.

Vous aurez peut-être certains réglages à faire sur le fichier CSS3 spécifique généré par Blitz.

Puis vous sélectionnez Fichier>Exporter pour créer automatiquement une version Kindle de votre ePub3.

Étonnamment (ou pas), la version Kindle est toujours beaucoup plus lourde que la version ePub3.

Mais elle est indispensable.

Vers l’infini et au-delà

C’est le destin qui est maintenant promis à votre œuvre.

Vous avez en main deux versions de votre ouvrage, un fichier Kindle à mettre entre les mains des possesseurs de tablette Amazon, et un fichier ePub3 pour tous les autres.

Dans le prochain épisode, nous verrons comment les mener vers vos lecteurs.