Rédaction scientifique

Je vais essayer de conclure ça. Concernant le problème de base je propose :

• Que quelqu'un crée un ticket pour demander à un dev de se pencher sur la configuration de mathjax pour améliorer les choses.
• Je vais proposer une ZEP pour étendre la sémantique des blocs et permettre ainsi de créer des sémantiques propre à chaque contenu.

Concernant les exports, la discussion devrait avoir lieu dans la ZEP-5. Contrairement à ce que dit Spacefox il y a régulièrement des remarques sur cet export. Sauf que plus que la qualité merdique, c'est surtout que les 3/4 du temps le pdf n'est même pas généré du tout. Pour le reste, je pense qu'on est tous d'accord pour dire qu'il faut fournir des exports du contenu. Actuellement il n'y a que le format html qui est a peu pret complètement géré. Le but de la zep-5 est justement de permettre l'export dans d'autres formats en rationalisant la chaine. Quand elle sera terminé, il sera possible de récupérer un pdf, un ebook ou même le latex (voir odf si il y a de la demande). Mais actuellement on a pas ça et aucun moyen de l'avoir. Que les auteurs veulent qu'on leur génère un latex, un odf ou directement le pdf, avant ça, il faut être capable de sortir autre chose que du html. Et c'est tout le but de la zep-05. L'export en pdf a été marqué en premier jalon car beaucoup de lecteurs voudraient un export pdf, même imparfait. Ça permettra en même temps de fournir un latex qui compile (car bon je peux te fournir un latex actuellement mais justement il compile pas, pas pratique). A partir de là ça voudra dire qu'on aura un pandoc qui comprend toute notre syntaxe et est capable de le ressortir dans un format différent. L'étape suivant sera alors soit la génération d'ebook, soit de html. A terme l'outil servira pour tous les parsings du markdown du site. Bref, dans tous les cas, pour que vous disposiez d'export, il faut faire avancer la zep-05. On a simplement choisi le latex comme premier format de sortie car il permet de faire a la fois de proposer les sources latex et de proposer des pdf sur le site. Latex qui compilera.

Je suis completement d'accord avec Dominus Carnufex. Pour moi, le metier de maquetiste est un vrai metier et la mise en page du contenu ne peut pas etre faite simplement de maniere uniforme pour tout type de contenu, et meme d'un article a un autre on a des besoin differents pour la mise en valeur.

On se heurte frontalement a la generation de PDF qui est toujours moche, mais j'irais meme plus loin: c'est un enjeu majeur du contenu sur Internet aujourd'hui. Je n'ai jamais lu aucun tutorial et evite autant que faire se peut de lire du contenu sur Internet pour ces problemes de presentation foireuse.

Je pense justement qu'un site se demarquerait largement avec des mises en page au cas par cas pour chaque contenu. Cela demande un effort supplementaire (surtout si on ne veut pas perdre les meta-information et la structure du document sous-jacent) mais c'est a mon avis un defi majeur que le web doit relever sur la presse papier.

@Höd : Même si on admet que des gens se chargent de ça, on va pas leur demander de convertir ça 100% à la mains, non ? Si il disposaient d'une base pré-exporté, non parfaite, mais qui compile ce serait la moindre des choses, non ?

Donc on en revient au besoin de sortir autre chose que du html de notre contenu. Et c'est le but de la zep-5. le fait que le premier jalon soit un export pdf ce n'est que s'assurer qu'on fournit un latex qui compile.

Höd, je ne comprends pas où tu veux en venir : tu dis :

1. Que tu ne lis jamais de contenu sur internet en PDF ?
2. Que tu ne lis jamais de contenu tout court sur internet ?
3. Autre chose ?

Parce que la 1 et la 2 sont quand même très, très différentes. Dans un cas c'est simplement l'un des supports, dans l'autre c'est la présentation générale du site que tu remets en question.

Je suis totalement d'accord avec Höd (vite vite, un screen !).

Ce qu'il voulait dire (en tout cas ce que j'en comprends) c'est que les ressources sur internet hors pdf travaillés humainement sont immondes à lire.

Je sais pas pour vous, mais jamais je n'essayerai d'apprendre des maths à partir d'une page HTML. La présentation est toute sauf travaillée pour et le contenu est déjà assez dur à lire pour qu'en plus il faille être indulgent avec la présentation.

Personnellement, si mon tuto sort un jour, il sera accompagné d'un PDF que j'aurai généré et géré moi même. Parce que si j'étais le lecteur, j'aurai un mal fou sans. Et ça vient pas de mon tuto. J'arrive pas à lire un tuto de maths sur ZdS ou ailleurs pour les mêmes raisons.

Faut dire aussi ce qui est: TeX est plus vieux que le web (je veux dire, le web tel qu'on le connait aujourd'hui, donc disont Netscape et le HTML ou un peu avant) et n'est pas destiné du tout à la même chose. Faut arrêter de croire qu'on va pouvoir arriver au même rendu sur navigateur que sur un PDF, c'est pas la même chose. Le web a des contrainte que le PDF n'as pas (par exemple, la taille change dans un cas et pas dans l'autre) et inversement.

Ce que j'ai l'impression de lire ici, c'est des gens qui se plaigne que le rendu de PDF de ZdS ne donne pas aussi bien qu'un document TeX qu'ils auraient passé quelque mois à faire avec tout ces packages cryptiques (mais tellement pratiques) et \renewcommand{}{} dont vous avez l'habitude. Bah non, le markdown est pas fait pour ça, ne l'as jamais été et ne le sera surement jamais, ou alors on écrirai directement les tutos en TeX (ou LaTeX, ou ConTeX, ou …). Et d'ailleurs, la remarque s'applique au couple HTML/CSS en général, une fois encore, c'est pas pensé pour faire ça.

Je vais éviter de me lancer dans le "plutôt que de vouloir que le contenu s'adapte à toi, même si c'est pas possible, adapte toi au contenu", parce que je vais me faire atomiser.

Quand à dire "Personnellement, si mon tuto sort un jour, il sera accompagné d'un PDF que j'aurai généré et géré moi même", ça n'as absolument rien à voir avec le ZdS, c'est juste que tu cherches à pouvoir offrir un document de bonne qualité à tes lecteurs, parce qu'ils le méritent et parce que tu aurais honte dans le cas contraire qu'il reparte avec cette image de toi. Patcher le markdown ne changera absolument rien à ça, et croire qu'un PDF généré par une machine donnera une aussi bonne qualité que le tien serait une utopie, surtout sachant que le tuto en lui-même contient des subtilités.

(j'allais conclure en disant que je trouvais bizarre de rager sur le rendu web des maths quand on possédait un blog sur les maths, mais l'adresse est morte o_O)

Dans ce cas je comprends, mais j'ai l'impression que ça ne s'applique qu'aux cas qui utilisent massivement les formules.

De mon point de vue, l'idéal pour ZdS serait de faire en sorte que la présentation soit optimale sur le web avant tout, puisque c'est le médium utilisé par la grande majorité de nos lecteurs.

Concernant les autres formats, mon point de vue est le suivant : idéalement, le lecteur (et l'auteur, pour n'importe quelle version de ses écrits), devrait pouvoir sortir n'importe quel format géré par Pandoc¹.

Maintenant la réalité c'est que Zeste de Savoir a un certain nombre de particularités en entrées et une équipe de bénévole réduite pour gérer tout ça proprement en sortir – et donc obtenir des formats utilisables.

Les formats qui me paraissent intéressants à gérer en sortie sont donc :

• Plain text, parce que c'est un peu le format pivot du pauvre ; à partir de ça l'auteur peut récupérer son contenu et en faire ce qu'il veut.
• EPUB pour être utilisable sur liseuse
• PDF avec un design conçu pour l'impression – sait-on jamais, on peut avoir une bonne raison d'imprimer un tuto.
• Markdown à condition qu'on puisse directement le ré-importer (pour faire des fonctions d'import/export et modifications hors ligne)

Je ne sais pas l'intérêt du PDF pour lecture sur écran. Je mets à part dans le cas d'un PDF soigné à la main. Quel serait l'intérêt d'un PDF généré automatiquement pour lecture à l'écran ? Sur tablette/liseuse il y a le ePub qui est bien plus adapté. Sur PC (qui lit rarement les ePub), hors ligne pourquoi pas, mais l'intérêt face à une sauvegarde de la page est faible. Si, pour les tutos de plusieurs pages, là ça peut servir.

Donc pourquoi pas aussi un format PDF pour lecture à l'écran.

Concernant les autres formats :

• InDesign ICML : aurait un véritable intérêt pour qui voudrait envoyer un tuto ZdS vers une chaîne d'impression professionnelle. Si vous voulez faire plaisir à votre correcteur / éditeur, envoyez-lui un fichier InDesign, ça lui épargnera une conversion.
• HTML 5 : pourquoi pas pour la génération en interne.
• XHTML : obsolète ou pour interaction avec des systèmes tiers.
• reStructuredText, MediaWiki markup, DokuWiki markup, Haddock markup, Textile, Asciidoc : divers langages de markup qui n'auraient d'intérêt qu'avec une interaction avec des systèmes tiers, et auxquels il faudrait ajouter nos spécificités.
• LaTeX, ConTeXt, RTF, DocBook, OpenDocument, ODT, Word docx : Langages qui concernent une édition hors-ligne dans un logiciel très spécifique. On pourrait imaginer sortir l'un de ces formats, mais ça pose des questions. Comme "quel format supporter par rapport à quel autre". Et ça va finir en guerre parce que dans la liste il y a des formats libres et des formats propriétaires très utilisés.
• GNU Texinfo, Haddock markup, FictionBook2, groff man pages, Emacs Org-Mode: Langages dédiés à des utilisations très spécifiques qui ne concernent pas ZdS.
• Slidy, Slideous, DZSlides, reveal.js, S5 HTML : langages pour faire des présentations. Ne concerne pas vraiment ZdS.

Non mais je comprend même pas ce débat. On est tous d'accords qu'il serait bien que Zds propose des exports autre que le html (qui est le seul a peu pret bien géré actuellement) ? Alors oui ces exports peuvent être proposé directement (comme le pdf qui devrait suffire à la majorité des auteurs/lecteurs) mais si vous voulez proposer un pdf nickel, vous souhaitez vraiment faire la conversion markdown -> latex entièrement à la main ?

Ce débat me dépasse. Vous vous focalisez sur l'export automatique en pdf qui serait tout le temps totalement mauvais alors que :

• le but est justement de proposer un export a peu pret potable pour la majorité,
• vous fournir d'autres formats d'exports de références pour vous permettre de les modifier à la main.

Alors si tout le monde se fout totalement des exports, j'aimerai qu'on me le dise maintenant car honnêtement j'ai autre chose a faire que de bosser sur un truc qui ne serait pas utilisé. Car bon si il n'y a que ça, je peux déjà vous fournir un export latex. Tout n'est pas géré à 100% et ça compile pas mais manifestement c'est déjà plus que vous en voulez.

En fait, je crois qu'on est un peu trop en débat philosophico-politique ici.

Donc pour en revenir aux fondamentaux, j'aimerais que ceux qui ont des difficultés avec les présentations offertes par ZdS (Holosmos, Höd entre autres) nous exposent ce qu'ils attendent de Zeste de Savoir, et ce d'un point de vue fonctionnel.

Une expression du besoin en somme.

Je renvoie a mon message précédent qui comportait une liste d'action concrète pour régler les problèmes de mathjax, des environnements inexistant et de l'aide à l'export de contenu.

Histoire de ne pas être jeté avec l'eau du bain, je vais essayer d'expliciter un peu ma position, visiblement mal comprise.

• Je n'ai aucun problème avec la présentation de ZdS sur le Web et ce parce qu'elle répond aux exigences fonctionnelles d'un outil générique de mise à disposition de contenu de type page Web. Il y a quelques détails, comme la question de la justification (mais je sais que je suis largement minoritaire, donc je n'insiste pas) ou le problème du temps de chargement de MathJax (pour lequel, si vous vous souvenez, j'ai apporté des pistes d'amélioration en explorant les possibilités de configuration de celui-ci), mais dans l'ensemble je suis pleinement satisfait.
• Il est nécessaire que ZdS offre un export en PDF fonctionnel et a minima pour ceux qui n'accordent pas d'importance particulière à la mise en forme de leurs PDF : cet outil d'export doit fonctionner, c'est-à-dire ne pas générer d'erreur, et je remercie Kje de plancher là-dessus. Et je m'excuse de ne pas avoir le temps de l'aider, alors même que c'est un des rares morceaux du code de ZdS où je pourrais participer, puisque c'est du Haskell.
• Cela étant, je pose comme un fait acquis et non comme un reproche fait à ZdS qu'un export automatique en PDF ne donnera jamais un rendu satisfaisant. C'est comme ça.
• Ce qui a pour conséquence que, une fois que le générateur de PDF sera fonctionnel, il ne me semble pas opportun de chercher à peaufiner le rendu automatisé. Il sera, de mon point de vue, alors temps de se consacrer plutôt à l'export en ODT ou LaTeX pour permettre à ceux qui y accordent une importance de retravailler ces fichiers ODT/LaTeX jusqu'à obtenir un rendu satisfaisant, et de se consacrer à permettre l'import d'un PDF/ePub retravaillé qui viendra remplacer le PDF/ePub généré automatiquement.

En fait ton dernier point est lié au point 2 : si on produit un pdf, le latex est disponible aussi en même temps (car c'est ce qui est utilisé pour générer le pdf). La compilation des pdf permet au passage de vérifier qu'on exporte un latex qui compile.

Oui, en effet. C'est juste qu'à titre personnel, le LaTeX, je m'en cogne : c'est l'export ODF qui m'intéresse.

C'est juste qu'à titre personnel, le LaTeX, je m'en cogne : c'est l'export ODF qui m'intéresse.

Là on tape très dans le problème que je soulevais au point 5 de la 2ème liste.

Euh… non. Rien n'empêche d'avoir un export en LaTeX et en autre chose. On peut se poser la question de la faisabilité pour les formats fermés, mais je ne vois pas en quoi le fait que le LaTeX et le format Word ne me soient d'aucune utilité interdit qu'ils soient disponibles aussi comme format d'export. D'autant moins sachant que ConTeXt étant un cousin du LaTeX et docx un dérivé du ODF, une bonne partie du code pour générer ces deux paires de formats sera commun.

Ce n'est pas ce que je dis. Mon point de vue, c'est que si on génère ces formats, il va falloir maintenir cette génération. Comme on a pas une puissance de dev infinie, il va falloir faire des choix. Et comme on a aucun critère de choix simple, chacun va demander son format préféré – très exactement ce que tu es en train de faire en fait – lequel sera très probablement différent du format préféré des autres. Ce qui va très probablement donner lieu à des débats sans fin.

Le but n'est absolument pas d'interdire des formats pour raisons idéologiques. C'est un simple problème pragmatique. Aujourd'hui on a tellement pas les ressources pour faire ces formats qu'on a même pas encore un export LaTeX fonctionnel – un grand merci à Kje qui bosse pour corriger ça d'ailleurs. Alors parler des formats supplémentaires utilisés par quelques personnes ici (incluant l'ODF), on en est très loin.

L'idéal serait bien entendu que chacun arrive à maintenir le format d'export qui l'intéresse.

2 remarques :

• notre fork de pandoc sera dans un dépot séparé, tout comme probablement le code pour le commander depuis les archives du site. Du coup on aura d'un coté le site qui proposera des exports et l’outil qui permetra de le faire hors-ligne depuis l'outil de conversion, directement. Il est donc tout a fait possible de limiter le nombre d'export sur le site mais, via l’outil, leur permettre de les faire eux-même "à la maison". Sachant qu'un premier niveau de personnalisation sera disponible à cette endroit là puisque l'outil permet de configurer l'export, au moins selon les paramètres de pandoc. Par exemple si c'est juste pour changer la police de caractère d'un pdf, pas besoin de repasser par le latex, c'est un paramètre a réglé au moment de l'export.
• Ensuite actuellement j'ai réussi à supporter notre syntaxe sans modifier l'ast de Pandoc. Ça a comme inconvénient que l'AST n'est pas très propre par endroit. Ça a par contre l'immense avantage que tout le contenu est parsé en entrée et les writers de pandoc, à défaut de les styliser correctement, doivent déjà être capable de fournir le contenu. Je n'ai jamais regardé la gestion de l'odf mais ça ne me surprendrait même pas que, par exemples, un texte dans un bloc info ai actuellement un style basique "info" de généré et qu'il ne resterait plus qu'à personnaliser.

Tout ça pour dire que la Zep-5 va dans ce sens et que le but est de proposer un même outils pour toutes conversions du site. La gestion d'un nouveau format supporté par pandoc sera a minima déjà fonctionnel et facilement améliorable. Le tout étant dans un dépot séparé, cela permet de laisser libre choix au site de ne proposer que les formats les plus courants et aux auteurs de disposer de tous les autres.

@SpaceFox : si la question est simplement de faire un choix dans les formats supportés prioritairement, je ne vois pas où se situe la difficulté.

Si je reprends ta classification, les points 4, 6 et 7 sont exclus d'office, du fait du peu d'intérêt qu'ils ont dans l'optique ZdS. Le point 3 (XHTML) peut être oublié aussi, puisque le format est dépassé. Le point 2 (HTML 5) est indispensable : c'est tout l'intérêt que Kje fasse un outil qui puisse servir aussi à générer les pages du site. En outre, le HTML 5 sera nécessaire pour générer des ePUB, quoi qu'il arrive. Pour le point 1, je n'en sais rien. Reste le fameux point 5.

Le LateX sera généré quoi qu'il arrive. Le RTF peut être laissé de côté, pour des raisons d'obsolescence : même Microsoft l'abandonne petit à petit au profit d'OOXML (le format derrière les docx). Quant à DocBook, la question se pose : c'est un format qui ne fait que décrire la structure du contenu sans s'intéresser à sa représentation, pour moi il est dispensable au même titre que les autres markdown-like. Restent alors trois formats : ConTeXt, ODF et OOXML.

Comme je l'ai dit, le premier aurait beaucoup de code commun avec la génération du LaTeX, les deux autres auraient non seulement du code commun entre eux, mais encore avec le rendu en HTML 5, puisqu'étant fondés sur du XML. Et en tout état de cause, ça réduit la « montagne de formats concurrents » à deux ou trois.

Alors c'est certain que ça demande du temps de développement. Mais si j'ai bien compris ce qu'explique Kje, s'il arrive à faire en sorte que notre markdown soit accepté en entrée par Pandoc, il n'y aura rien de spécial à faire pour que ces différents formats soient générés, fût-ce sous une forme un peu dégueu.

Et nous n'en demandons pas plus ! On ne demande pas que l'export en ODF/docx/squetuveux soit optimal, simplement qu'il n'y ait pas de perte d'information par rapport au markdown. Derrière, c'est nous qui ferons le travail de mise en forme, restructuration, etc. C'est précisément pour pouvoir faire ce travail-là qu'on demande à avoir d'autres formats d'export !

J'avais bien compris.

Et ce que je te dis depuis tout à l'heure, c'est que sans tenir compte de l'excellent travail de Kje, aujourd'hui ajouter un format d'export à ZdS (je parle bien du site ZdS là, pas du projet Pandoc de Kje) c'est du boulot et qu'il n'y a personne pour le faire. Que ce soit 1, 2 ou 50 formats le problème est le même.

C'est pas possible, tu cherches délibérément à être en désaccord avec moi, je vois que ça…

sans tenir compte de l'excellent travail de Kje

Ah ben forcément, si tu supprimes la base même de tout mon raisonnement, le pré-requis indispensable à tout ce dont je parle, ce que j'ai explicitement défini comme étant la première étape de ce que je demande, alors oui, forcément, ce que je dis n'a plus de sens. Mais ça s'appelle inventer un problème qui n'existe pas.

Depuis le début je réfléchis uniquement et explicitement dans le cadre de la ZEP-05 / outil Pandoc de Kje. À aucun moment je n'ai demandé qu'il y ait une solution intermédiaire d'ici au développement de cette ZEP. Alors, dans ces conditions et uniquement dans celles-ci où vois-tu qu'il y ait un problème à permettre l'export dans 3 formats différents ? Où ?!

Je ne parle pas de la génération du format de sortie mais de son intégration dans ZdS. Le fait que tu aies un bouton dans ton tuto pour dire "je veux récupérer le format X ou Y", et si possible sur la dernière version rédigée, parce que sinon ça n'a pas vraiment de sens. Aujourd'hui à cet endroit on a que "archive" parce que ça doit être une fonctionnalité de Git. Je n'ai jamais parlé de fonctionnalité intermédiaire.

Aujourd'hui autant que je sache, tous les exports sont générés à la publication du tuto. Il y a donc du dev à faire pour pouvoir les générer à la demande (mais ça doit gérer des problèmes de performances) ou à l'enregistrement (mais ça doit gérer d'autres problèmes de performance et des problèmes de place disque).

Tous les problèmes sont littéralement multipliés par le nombre de formats à gérer. Et aujourd'hui il n'y a personne pour gérer ces développements.

Il est là mon problème. Alors oui, je comprends que tu veuille un format intermédiaire X ou Y que Kje pourra sans doute générer sans problème. Sauf que cette génération n'est que la moitié du problème. Que mon rôle en tant que DTC c'est de faire en sorte que ce site tourne techniquement et qu'aujourd'hui on a déjà une masse délirante de bugs et de PR pas testées.

Alors quand je lis des demandes pour un format de fichier X ou Y bien particulier, je peux comprendre le besoin. Mais j'aimerais que chacun y mette un peu du sien et fasse preuve de pragmatisme, et évite les assertions du genre "C'est juste qu'à titre personnel, le LaTeX, je m'en cogne : c'est l'export ODF qui m'intéresse. :)".

PS : Si bien sûr je vois une PR bien ficelée à ce sujet, elle sera acceptée. Mais la question des formats à exporter doit d'abord être tranchée. Et avec pragmatisme, pas par pure idéologie.