J'ai entrepris la réécriture de l'exportation et je m'interroge sur la pertinence des différents formats. Pour le HTML je n'ai pas de doute, en revanche pour les autres formats je ne sais pas.

Je n'ai pas définitivement renoncé au PDF, bien que dans ce cas l'élément bloquant c'est le traitement des images incluses dans le texte. Il faudra donc utiliser un parser pour traiter correctement les différents tags.

Le TXT et le CSV sont plutôt concurrents, est-il pertinent de maintenir les deux? Bien entendu ça s'applique à l'exportation des tables.

Pour ce qui est du texte lui-même (l'export BOOK), le HTML est privilégié. Mais je pense qu'il est souhaitable de maintenir le TXT.

Je pense en profiter pour supprimer le type "Summary" et le remplacer par l'exportation de la table "Internal". Dans ce cas ce serait une exportation TXT exclusivement.

Que pensez-vous de tout ça?

Si nous avons un format d'export correct, il est toujours possible d'utiliser des outils externes pour convertir (pandoc par exemple).
A tester toutefois.
Je ne pense pas que la plus-value de oStoryBook soit la conversion de formats divers. Un ou deux formats "universels" et la dépendance vis à vis de programmes externes qui feront la conversion mieux que nous me semble une bonne approche.

<avis perso PDF>Sur les formats eux-mêmes, et pour mon utilisation, PDF ne me servira pas, c'est un format "trop final", et trop lié au système (une pagination stricte me semble inappropriée avec la multitude de devices aujourd'hui)</avis perso PDF>

Si je devais donner une préférence (pour le contenu "livre" hors tables):

1) HTML5 "strict" (c'est à dire avec les tags fermants, etc...). Voire XHTML.
Aujourd'hui, par exemple, l'export html n'est pas valide (version 5.0.3).
 
2) XML (vue organisationnelle). FB2 (exemple) est un  schéma que j'appelle fonctionnel, adapté aux romans (d'où le nom, FictionBook). Mais on pourrait choisir le nôtre, avec une description correcte du schéma.

3) ODT pour pouvoir le lire au choix dans LibreOffice/M$ Office, et ailleurs. Ici, contrairement aux (1) et (2), on devrait essayer de respecter la mise en page au plus près. J'insiste, pour que le (1) ne soit pas comme l'export HTML de LibreOffice, qui est illisible, spaghetti, et non utilisable (j'ai planté Calibre plusieurs fois avec le HTML en question), simplement car ils essaient de préserver la présentation.

4) LaTeX, pour permettre une mise en page correcte avec d'autres outils. En fait, un export LaTeX permettrait à peu près toutes les conversions "formatées" (ODT, PDF, etc...) avec un outil externe.

5) EPUB (encore une fois en restant "clean" au niveau des styles). Si le (1) est correct, le format ePub est relativement simple. Si le (1) est parfait, pandoc fera le boulot.
Pourquoi j'aime bien ePub ? Car l'utilisateur final choisit ses styles. L'auteur n'a rien à dire (imposer une fonte, ou une taille de caractères, ou pire: des couleurs).

Pour les tables, ou la base, outre:
1) CSV/TXT (pour moi c'est pareil, comme tu le remarques justement)

il y a aussi:

2) XML database serait bienvenu (export/import). Celui-ci serait un dump complet du livre dans un fichier unique. Utile si on change de version, ou de DB, etc, si on peut importer/exporter vers un format texte (sans DB)... A ce propos, un mode batch de oStoryBook serait le bienvenu, pour faire des conversions lorsqu'on compile le projet, comme:
  

A propos, je suppose que les développeurs travaillent sur quelques fichiers exemple. Ce serait une bonne idée d'en avoir un (petit) dans la distribution, qui utilise quelques caractéristiques du logiciel.
Il y a bien les 2 exemples de la page "Sample Files", serait-il possible de les inclure dans la distribution ? Ile pourraient être enrichis par la suite, avec des textes plus compliqués (je pense à l'écriture de haut en bas et droite vers gauche).
De même, la doc semble être générée par oStoryBook. Existerait-il un ".db" quelque-part, à mettre aussi dans la distribution (au moins dans git) ?

Book
Je suis d'accord avec toi pour le HTML 5, je te laisse explorer en profondeur le code pour voir où il faudrait intervenir. Tu t'apercevras que l'exportation actuelle ne poserait pas de problème, mais qu'en revanche c'est l'éditeur qui sera le centre d'attention.

Le fait d'avoir du HTML5 correctement écrit me semble propice à diverses conversions via des outils externes (odt, pdf, epub).

L'export en LaTex a été demandé, au moins à deux reprises. Là aussi je suppose qu'avec un HTML5 il doit exister un outil de conversion adapté et performant (je ne connais pas LaTex).

Database
Ça concerne l'exportation des tables, la réécriture que j'ai engagé devrait permettre d'harmoniser grandement cet aspect. Le choix du XML me paraît toujours le plus indiqué, plutôt que le TXT ou le CSV (relativement limité pour importer les données ailleurs). Je n'ai pas exploré les possibilités Calc (ou Excel) en la matière.

L'export SQL, quant à lui, est réalisé directement par le moteur H2.

Fichiers d'exemples
C'est une bonne idée d'en intégrer un ou deux dans la distribution. Je travail avec "Le Médecin malgré lui" et "De la Terre à la lune", il serait très simple de les intégrer, puisqu'ils sont déjà disponibles en téléchargement. J'avais aussi l'intention d'ajouter "Orgueil et préjugé" qui présente l'avantage d'être dans le domaine public et disponible dans de nombreuses langues. Eventuellement on pourrait envisager de distribuer un paquet complémentaire "Exemples".

Manuel de l'utilisateur
Tu peux le récupérer à partir du repository sur Tuxfamily (via FTP) à l'adresse :
ftp://ftp.tuxfamily.org/ostorybook/ostorybook.tuxfamily.org-web/htdocs/doc/fr

Rory a déjà fait une traduction, il me reste à refaire les captures d'écran nécessaires.

J'ai l'intention de l'intégrer dans l'arborescence de développement. Il sera ensuite disponible via le Git.

J'ai aussi commencé à réécrire le site Web avec oStorybook, ça ne concerne que la partie statique (donc hors forum, news, blog et témoignages). C'est en partant de ce test que j'ai amélioré certaines choses pour l'export HTML. Pour me changer les idées de temps en temps je commence à écrire le CSS qui sera indispensable. Ça conduit inévitablement à concevoir oStorybook sous la forme d'un outil de conception d'un site Web.

Divers
Pourrais-tu compléter ton inscription comme développeur? Il te faut un compte sur:
- le site Web principal : c'est fait
- Flyspray : c'est fait
- le site Tuxfamily : pour t'ajouter comme admin sur https://panel.tuxfamily.org/
- en option : un compte sur Sourceforge et un autre sur Github (il existe déjà)

Il faudra que je vous fasse une petite doc sur les différentes règles applicables à ces serveurs. Par exemple l'espace sur Tuxfamily est restreint, on ne peut donc pas y conserver l'archivage des anciennes versions. Du coup je m'efforce de le faire sur Sourceforge.

Je pars du principe que chaque développeur est aussi admin. Même s'il ne fait pas de l'admin il doit disposer de toutes les prérogatives.

> Book
> [...] Tu t'apercevras que l'exportation actuelle ne poserait pas de problème, > mais qu'en revanche c'est l'éditeur qui sera le centre d'attention.

Je suis loin de regarder dans le code, j'en suis à git

> Le fait d'avoir du HTML5 correctement écrit me semble propice à diverses
> conversions via des outils externes (odt, pdf, epub).

> L'export en LaTex a été demandé, au moins à deux reprises.

En fait, LaTex permet un export plus propre encore...

> Database
> Ça concerne l'exportation des tables, la réécriture que j'ai engagé devrait
> permettre d'harmoniser grandement cet aspect. Le choix du XML me paraît
> toujours le plus indiqué, plutôt que le TXT ou le CSV (relativement limité
> pour importer les données ailleurs).

Entièrement d'accord. CSV ou autres formats "plats" sont assez limités. Surtout qu'il est facile d'utiliser des outils externes pour passer de xml à csv par exemple (avec un xsl correct).

> Je n'ai pas exploré les possibilités Calc (ou Excel) en la matière.

Pas vraiment besoin, car un xml permet de faire un csv complet (sans perte d'information), ce qui n'est pas forcément vrai dans le sens contraire...

> Fichiers d'exemples
> [...]
> Eventuellement on pourrait envisager de distribuer un paquet
> complémentaire "Exemples".

Oui, avec plusieurs langues, en particulier non-occidentales.

> Manuel de l'utilisateur
> J'ai l'intention de l'intégrer dans l'arborescence de développement. Il sera
> ensuite disponible via le Git.

En fait, je pense que tout devrait être sur git. Ainsi que le moyen de tout reconstruire. Et peut-être que du nettoyage pourrait être fait, j'ai l'impression de beaucoup de trucs ne sont pas vraiment utiles (des .odt, sans indication de leur utilisation, par exemple, des librairies qui varient sans savoir pourquoi, etc...).

Mon avis: Un "git clone" (ou pull) ne devrait récupérer que ce qui est nécessaire, mais avec tout ce qui fait partie du projet.
Sans les vieux trucs historiques (README de version 4 dans la version 5, par exemple). C'est pas simple, je sais .

> [...]j'ai amélioré certaines choses pour l'export HTML. Pour me changer les > idées de temps en temps je commence à écrire le CSS qui sera
> indispensable. Ça conduit inévitablement à concevoir oStorybook sous la
> forme d'un outil de conception d'un site Web.

Hum...

> Divers
> Pourrais-tu compléter ton inscription comme développeur? Il te faut un
> compte sur:
> - le site Web principal : c'est fait
> - Flyspray : c'est fait
> - le site Tuxfamily : pour t'ajouter comme admin sur
> https://panel.tuxfamily.org/
> - en option : un compte sur Sourceforge et un autre sur Github (il existe déjà)

Je crois avoir un compte sur sourceforge, il faut que je le retrouve.

> Il faudra que je vous fasse une petite doc sur les différentes règles
> applicables à ces serveurs. Par exemple l'espace sur Tuxfamily est restreint, > on ne peut donc pas y conserver l'archivage des anciennes versions.
> Du coup je m'efforce de le faire sur Sourceforge.

Pourquoi les deux ? Ça va devenir ingérable, par exemple à vouloir plusieurs branches de devs....
Exemple: Je commence un travail sur la base de données, qui va prendre des semaines. Je fais donc une branche (tuxfamily), que je tiens à jour. Un merge final étant prévu bien plus tard.

Quelle est la limite exactement ? En est-on loin ? Quid de mon idée de mailing-list, si tuxfamily ne peut pas supporter ses archives ? Du coup  une très mauvaise idée de ma part, non (sachant que beaucoup risquent de top-poster, et ainsi multiplier la taille des messages)?

---

Rectified by bodiccea 23/01/2017 13:56