Urbanbike

Index |
ou détaillée | Fil RSS | ATOM

Pages, ePub et bizarreries | 2

Les doigts dans le code

dans groummphh | usages

Suite de mes petites aventures. Bon, j'ai fini par me résoudre à ne plus attendre de cette version de Pages qu'elle fasse le boulot tout seul…! C'est là où la lecture du livre de Elizabeth Castro m'a aidé. Promis, j'y reviendrais.

En résumé, mon ePub était bon mais avec des trous…! Ces trous sont dus à chaque fois à la rupture du lien vers l'image mais exclusivement via l'export au format ePub depuis Pages.

Encore une fois, le PDF généré par cette même application ne présente aucun problème. Cela me prouve que mes liens dans Pages sont bons mais ne sont pas maintenus lors de la création du ePub.

Alors…?
Alors un fichier ePub, c'est une mécanique très simple. Le ePub est une bête archive ZIP avec des fichiers et des dossiers dedans… Et le contenu fonctionne, en gros, comme une série de pages HTML… Donc je me suis résolu à faire ce que je ne souhaitais pas faire, ouvrir le capot…

Premier souci, décompresser le fichier ePub dans un dossier spécifique. Stuffit fait très bien l'opération.

Ensuite, marri de n'apercevoir que 88 fichiers dans le dossier images du ePub décompressé, hop, je lui colle tous les fichiers manquants (ceux basculés en .png, profil RVB "pur jus" et retraités en 468 pixels de large). 472 fichiers plus tard, tout est au complet avec les fichiers PNG créés par Pages de plus (une puce parfaitement identifiée ainsi que la page de couverture).

Je ne regarde pas tous ces fichiers créés par l'export de Pages pour fabriquer le ePub. Ils sont déjà faits et c'est parfait.

2011027 epub 12 ok

Non, ce qui m'intéresse en dehors du dossier images, ce sont tous les fichiers dans le dossier OPS qui finissent par .xhtml…

2011027 epub 12a ok

Et pour les ouvrir, TextEdit ou, dans mon cas, BBEdit.

2011027 epub 19a ok

Là, pas une réelle surprise, c'est bourré de liens vides… Je cherche une chaîne commune (attention, il y a toujours des exceptions) et j'effectue un simple recherche remplacement…

2011027 epub 13 ok

…pour repérer plus facilement dans mon code de visu les liens à placer à nouveau.

2011027 epub 14 ok

Ensuite, en mettant côte à côte Pages et BBedit, même pas besoin d'afficher dans une fenêtre les fichiers images, Pages m'indique bien le nom de chaque fichier image en mode structure dans sa palette…

2011027 epub 15 ok

Un simple copier/coller (mais coller deux fois pour remplir également la balise ALT) suffit en étant précautionneux. Bon, j'ai vite oublié cette Balise ALT que j'ai remplacé par une info générique.

La surprise provient de quelques rares cas dans le texte où la succession de deux images dans mon document (dans deux paragraphes séparés) est remplacé par un seul lien. Ou la chaîne du lien n'a pas été remplacée car très légèrement différente (un argument manque).

2011027 epub 21 ok

Voire, sous un titre 3, l'image qui était placée et qui s'est volatilisée.

Une fois ces pièges repérés, les liens remis à neuf, le document .xhtml est simplement sauvegardé (attention à ne pas l'altérer en terme de structure).

Avant de continuer et de se lancer dans tout le document, je me suis offert quelques petites vérifications d'usage.

Remouliner un ePub…
Reste à fabriquer à chaque fois le fichier ePub. Rien de plus simple, il suffit de zipper le tout (en oubliant le dossier dans lequel vous avez placé toutes vos billes) et changer son nom à l'arrivée.

2011027 epub 18 ok

Via PathFinder (voir cette chronique sur urbanbike), je compresse l'ensemble au format ZIP et évite de laisser le nom d'arrivée, archive.zip en renommant le binz nom-du-bouquin.epub… C'est tout.

2011027 epub 18a ok

D'ailleurs, ce dossier contenant les éléments constitutifs de votre ePub sont à conserver tels quels car vous risquez d'y revenir régulièrement (du vécu…!!).

Le visualiser sur son Mac, c'est plus rapide
Certes, mais dois-je l'importer à nouveau dans le iPad pour vérifier…? Que nenni…!
Il existe un très bon contrôleur de ePub, une extension de FireFox nommée EPUBReader

2011027 epub 16 ok

(Image spécialement pour Guillaume…!)

Une rapide vérification via FireFox me permet de me rendre compte que toutes les images sont à nouveau présentes, que mon Emmental est devenu un Gruyère (rappel : le gruyère n'a pas de trous…).

Hop, je passe aux chapitres suivants. Etc.



Attention néanmoins…
Dans la série des trucs à ne pas oublier, homogénéisez les suffixes.

Si votre fichier image se nomme "zimage.png", il ne sera pas reconnu et affiché s'il est écrit dans le code du .xhtml "zimage.PNG". Et ce n'est pas EPUBReader qui va s'en rendre compte car fonctionnant dans un navigateur, il interprète l'un ou l'autre.

Réalisez correctement vos copiers/collers, cela va sans dire…!

Et puis si vous aviez une image référencée en .jpg et qu'elle a été convertie en .png, c'est ballot de ne pas corriger ce suffixe dans le code.

Bref, du temps, du temps et encore du temps. François Bon a raison de dire que c'est de l'artisanat.

Mais on y arrive et toutes les images fugitives sont désormais présentes dans ce ePub de 27,3 Mo…

2011027 IMG 2344

Mais je reste convaincu (éternel optimiste) que Pages new look devrait corriger ces désagréments… Tout comme une nouvelle mouture de Adobe CS. Allez, restons zen.

le 27/02/2011 à 18:15 | .(JavaScript doit être activé pour visualiser cette adresse email) à JChris d'Urbanbike | #

Pages, ePub et bizarreries

Anomalies sur la version '09 ou erreurs de ma part…?

dans groummphh | usages

Avertissement, difficile de faire court quand on se retrouve face à ce type de problème. Autant être exhaustif.

Que les choses soient claires, j'aime bien Pages (voir cette chronique sur urbanbike).

Mais devant produire un fichier ePub pour un ouvrage à venir (voir cette chronique sur urbanbike), je me retrouve face à un truc étrange que je soumets aux lecteurs curieux…

Certes, le ePub à produire contient près de 470 copies d'écran. Ce que je produis a été accepté par le validateur d'Apple, mon ePub s'affiche fort bien dans mon iPad. Sauf qu'il est à trous…! Un véritable Emmental numérique. Le texte est au complet, les images non. Pas de rupture nette, genre, les premières pages puis plus rien. Non, des disparitions même pas régulières…!

Comme c'est un ePub, il suffit de dézipper le fichier pour voir son contenu et jeter un oeil dans le dossier images. Et à chaque tentative, très exactement 88 images sont retenues et toujours (…j'insiste…!) les mêmes.

2011026 pages bug 08

Mon dernier dossier après moults corrections…

2011026 pages bug 08a

Le précédent dans la corbeille…

2011026 pages bug 08b

Étrange, étrange…!

Du coup, je me suis demandé si c'était le mélange PNG et JPG qui posait problème… Hop, tout converti en PNG…!

Ensuite, je me suis demandé si c'était la taille des images (le dossier source tourne autour des 228 Mo) qui posait coinçait.

Comme la largeur maximale des fichiers image dans un ePub ne dépasse pas les 468 pixels, j'ai mouliné mes 470 fichiers et des poussières pour les porter à cette largeur et mon dossier d'illustrations s'est réduit à 33 Mo.

Après je me suis posé la question des liens : est-ce que mes liens sont corrects. Là, aucune possibilité de le vérifier comme sur InDesign qui affiche le lien complet. Pages indique juste que c'est telle image qui est lié mais sans indiquer le chemin.

Pour en avoir le coeur net, j'ai dupliqué mon dossier de travail puis utilisé Name Mangler (voir cette chronique sur urbanbike) pour les renommer séquentiellement.

Puis j'ai testé la solution de réimporter (non, j'aime perdre du temps…!) en lieu et place chaque image préalablement renommée et placée dans un dossier également renommé…!

Et là, étrange de chez étrange…!

2011026 pages bug 01

À ma gauche, mon document de travail avec une image avec son nom préalable (petit coup de zoom)…

2011026 pages bug 01a

À droite le même fichier image allégé (468 pixels de large), renommé et placé dans un nouveau dossier…

2011026 pages bug 01b

Pour que les choses soient faites dans le règles de l'art, pas de cliqué/déplacé mais une véritable importation dans Pages…

2011026 pages bug 02

Petit coup de zoom…!

2011026 pages bug 02a

Donc, j'importe bien une image nommée 469.png depuis un dossier "zim"…

2011026 pages bug 03

L'import étant effectué, je clique sur l'image pour la sélectionner et lire son nom dans Pages… Coup de zoom…!

2011026 pages bug 04a

Ahhhhhhhhhh… ! Le nom du fichier reste identique à l'étape précédente. Bon, imaginez que j'ai fait un grand nombre de tests, viré l'image, l'importer dans un autre chapitre… Niet ! Comme si Pages conservait la mémoire du fichier d'origine…! Et essayé sur plein d'images dans mon document. Sans résultat. Même créé un document vierge, importé cette image puis copié/collé et… Et non…!

Vous vous souvenez de l'épisode du sparadrap du Capitaine Haddock…?!

Bon, là, j'ai craqué. Mauvaises ondes. Le XV tricolore s'est pris une déculottée au même instant.


Alors…?
Alors, je suis revenu à mon dossier de départ (les images non renommées séquentiellement) car je me suis rappelé que les images d'origine étaient toutes avec un suffixe .PNG et celles retraitées par Name Mangler finissaient par .png…

Et puis, également pour ne pas perdre encore trop de temps (sic…!) et en prévision d'un résultat incertain.

Du coup j'ai tenté une autre opération, opéré cette fois-ci en mode structure et en jouant sur le simple cliqué glissé depuis le finder (…depuis PathFinder dans mon cas).

2011026 pages bug 05

Là, il s'agissait simplement de glisser à côté de l'image précédente la version modifiée puis de supprimer la plus ancienne (ruse…!). Et pour repérer le bon grain de l'ivraie, de jeter un oeil sur le suffixe.

2011026 pages bug 05a

La nouvelle image se termine bien par .png (en minuscules)…

2011026 pages bug 06

La première se finit bien par…

2011026 pages bug 06a

.PNG en capitales.

Facile alors de supprimer l'image d'origine et donc d'être certain d'avoir placé la nouvelle depuis le nouveau répertoire…

2011026 pages bug 07

Hop, petit coup de zoom… .png (en minuscules)

2011026 pages bug 07a

Étant ainsi assuré que les images étaient bien remplacées, j'ai poursuivi sur une large centaine d'illustrations puis réalisé un ePub de contrôle…

Pour finir par me retrouve à nouveau bloqué à 88 images…!!!

Tout en constatant (retour à la première copie d'écran de ce billet) que les remplacements avaient bien eu lieu…!

2011026 pages bug 08c

Bref, cela coince quelque part…!
Soit il y a un souci (mais en ce cas, pourquoi Pages ne me le signale pas — aucune image flottante mentionnée dans son rapport d'export) ; soit je suis tombé sur la limite de cette version en terme d'images embarquées. Soit je suis une buse (pas impossible non plus…!)…

À suivre…! Et PDF4ever !!



NB : on annonce une nouvelle version de iWork'11. Si cette dernière corrige ce souci/limite, je suis preneur…!

NB 2 : de là à ce que je retourne sous InDesign, il y a un pas… que je ne souhaite pas franchir à nouveau…!


NB 3 : Dimanche matin. Eurêka mais j'ai mis les doigts dans le code. Suite des explications avec copies d'écran comme précédemment avant demain. Mais toutes les images (deux premiers chapitres) sont désormais visibles… Ouf…!

le 26/02/2011 à 20:15 | .(JavaScript doit être activé pour visualiser cette adresse email) à JChris d'Urbanbike | #

Google et fermes de contenus

Petite humeur de circonstance

dans groummphh

Lu sur abondance ce matin. Après des hauts et des bas, Google vient de se décider à changer ses algorithmes et vise particulièrement les fermes de contenus. Pourquoi pas.

C'est quoi une ferme de contenus ? C'est un site qui récupère les flux d'autres sites pour nourrir ses propres colonnes. Par exemple, les billets d'urbanbike sont utilisés comme du contenu. Cela ne me gêne pas même si ce sont des sites qui arborent de la publicité et sont donc plus à même de vivre de possibles retours financiers dus à cet affichage.

C'est généralement bien foutu comme sur Wikio, les internautes peuvent voter, tweeter pour des billets et même commenter. En y pensant, je trouve cette situation paradoxale…! Il y a certainement des gens qui lisent urbanbike par le biais de ces fermes de contenus, votent favorablement (ou pas…) pour un billet, commentent. Sauf que les principaux intéressés — la petite bande de rédacteurs d'urbanbike — n'en savent strictement rien !

Peu importe, c'est pas mon truc. Je ne vais pas vous saouler à nouveau sur mes choix en matière de publicité, il suffit de lire les derniers paragraphes de cette page…! J'ai même viré l'an passé Google Analytics (il ne reste que les balises de commentaire dans le source). Bien sûr, cela doit nuire grandement au référencement mais autant aller au bout de mes convictions.

Alors, ce changement de stratégie de Google annonce-il des perspectives plus intéressantes pour des sites comme le notre ?! J'avoue que je n'attends rien de nouveau, ce qui m'évitera des désillusions.

Pour finir, merci à tous ceux qui commandent des livres sur Eyrolles.com en passant par les liens ad hoc sur urbanbike, cela nous a permis en 2010 de régler la facture de notre excellent hébergeur et quelques noms de domaine.

Ah, si, dernier point : que nous soyons — ou non — mentionnés par d'autres sites est du même tabac : on s'en bat les couettes. Inversement, j'aime bien sourcer, question d'éducation. CQFD.

C'est dit…!

20110226 IMG 7982 c1

Pub personnelle pour le printemps qui pointe… Photo pondue du jour

le 26/02/2011 à 12:30 | .(JavaScript doit être activé pour visualiser cette adresse email) à JChris d'Urbanbike | #