Quote:
Originally Posted by Hadrien
Pour ce qui est d'extirper une structure d'un fichier XHTML:
- c'est relativement casse gueule et ça produira sûrement des erreurs plus difficiles à corriger que de partir de 0 et de faire la structure soi-même
- ça ne marcherait bien qu'avec des outils assez poussés qui ne seraient pas à mettre entre les mains du commun des mortels (par exemple Calibre le fait avec du XPath).
|
Personnellement, je n'ai jamais parlé d'extirper une structure d'un fichier XHTML, ni ici, ni dans nos conversations par mail, je suis même résolument contre. Je veux simplement pouvoir définir manuellement, dans une table de correspondances, pour l'ensemble d'un projet (donc le ou les flux qui constituent le livre), la signification des balises H1, H2, H3 au regard des notions de Parties, Chapitres, Sections: il n'y a rien là de casse gueule, cela revient au même que ton interface, mais je fais la définition une seule fois pour le livre, au lieu de faire du copier-coller à répétition, avec les risque d'erreur que cela comporte au bout de x chapitres et parties... Il faut également qu'on ait le choix de ne pas numéroter automatiquement dans le logiciel les parties et chapitres, car nous tenons, pour ce qui nous concerne, à garder les numérotations de nos documents source Word/OO qui reprennent celles de l'édition papier.
Personnellement, je reste persuadé que ce ne serait pas plus compliqué, alors, de faire un ebook en epub que de faire un ebook en Mobipocket (pour lequel je dois quand même définir quels niveaux de titres doivent être pris en compte pour la table des matière)
Concernant Calibre, je n'ai rien compris à la manière dont fonctionne son XPath, et je trouve le logiciel assez confus dans son utilisation sur ce point.
Quote:
Originally Posted by Hadrien
Après Feedbooks dans l'absolu c'est un webservice qui pourrait être utilisé de manière totalement transparente dans une chaîne de production: si quelqu'un le souhaite, il pourrait très bien avoir un outil qui ne fait que le découpage, balance cela à Feedbooks et après Feedbooks crée les différents formats et la distribution.
|
Le problème, c'est que, si Feedbooks produit effectivement des ebooks ePub de grande qualité, ce que ne conteste personne - il y a quand même ce problème de numérotation automatique des parties et chapitres qui est embêtant - ce webservice n'est absolument pas adapté à la production de dizaines, et même de centaines d'ebooks (je dis bien production et non conversion, puisque quand nous le faisons, nous partons de nos documents source).
Quote:
Originally Posted by Hadrien
Je vois que dans l'ensemble vous faites bien la distinction entre conversion et une chaîne de production ce qui est très important: Amazon avec DTP ou Smashwords communiquent à mon avis un mauvais message. Ils font croire aux petits éditeurs et aux auteurs qu'ils peuvent très bien créer des livres éléctroniques en utilisant un fichier Word voir PDF. C'est de mon point de vue totalement faux: produire des livres éléctroniques de qualité demande un véritable travail, et une démarche spécifique.
|
Je ne connais pas le truc dont tu parles concernant Amazon. Mais je continue à penser qu'on peut partir d'un fichier Word/OO, appliquer un modèle calculé pour le format epub (et autres travaux de préparation du style conversion des notes de bas de page), convertir en XHTML le doc, avec OO par exemple, définir manuellement la signification des niveaux de titres par rapport aux parties/chapitres/sections, ajouter un ou de deux flux XHTML à ce corps de texte, par exemple pour la couverture du livre, l'à propos du livre, etc et produire à partir de là un ebook epub correct.