Rédaction scientifique

Oui et non. On va taper dans l'arbre de Git, mais l'archive est bien généré à la demande (et pas mise en cache, si c'est ça la question). À priori, le travail reviendrait (remarquez le conditionnel) à faire de même et appeler pandoc a ce moment là, même si pandoc se traîne un peu pour certains formats.

Ce qui veut dire aussi que rien n'empêche l'utilisateur de choper l'archive et de le faire chez lui, si c'est possible pour nous, ça doit l'être pour lui.

Ça ne change rien au fait qu'il faut un développement pour l'intégrer et que les problèmes soulevés sont toujours présents. "Pandoc qui traîne un peu pour certains formats" = "il faut gérer proprement ce cas", par exemple.

Bon je propose qu'on ai avancé sur la zep-05, qui est la condition sine qua non pour tout le reste bouge, avant de débattre de ça.

J'en reviens à ma proposition des points à faire :

• Trouver un dev pour configurer convenablement mathjax (au moins faire un ticket)
• Faire une zep pour étendre la sémantique des blocs
• Avancer la zep-05.

Globalement plus le temps de m'en occuper et quand j'en ai un peu je l'investi ici :-).

J'ai essayé d'être clair dans les messages précédents. En principe j'ai fait ma liste de Nöel

Sinon, juste pour resituer le débat. J'ai parlé de pdf parce que le HTML actuel me plaisait pas du tout. Il est évident que je préfère avoir une bonne mise en page HTML qu'un pdf.

Mais vu que beaucoup de contraintes inhérentes au HTML se posent (MathJax, justification, mise en forme en général) j'ai suggéré de généraliser la proposition du pdf que l'auteur devrait faire lui-même. Vous avez enchaîné sur la génération automatique, qui à mon sens est problématique parce que de toute façon on ne devrait pas exposer de la même manière des maths, de l'histoire, de l'info, etc.

parce que de toute façon on ne devrait pas exposer de la même manière des maths, de l'histoire, de l'info, etc.

Je veux bien que tu détailles, pour deux raisons :

1. Ce problème se pose sur tous les formats, donc le HTML, qui est quand même le principal rendu de ce site.
2. En fait je ne suis pas d'accord avec cette assertion. Pour moi ce dont on a besoin, c'est de présenter proprement différents types de blocs : texte, formules, code, illustrations, … la nature contenu n'intervient pas là-dedans. Selon la nature du contenu tu utiliseras ou pas certains blocs, mais l'exposition générale reste la même.

Bah ce sont des raisons assez évidentes en principe.

Par exemple en mathématiques on a besoin de faire des démonstrations qui peuvent prendre de quelques lignes à plusieurs pages. Supposons que l'on ait un paragraphe ou deux (sinon on découpe en lemme traditionnellement, histoire que ça soit buvable). Eh bien j'ai eu beaucoup de problèmes à savoir comment mettre en forme la démonstration ici par exemple. D'habitude j'ai mon cadre préparé où il est clair qu'il s'agit de la démonstration et qu'en première lecture on peut s'en passer. Au final, j'ai des démonstrations pas assez rigoureuses parce que si je voulais les rendre plus rigides ça serait immonde à lire (trop gros, trop débordant sur tout, sans repères).

En fait de manière plus générale je pense qu'on est face à un problème de linéarité de la lecture. Par exemple ça me semble impossible de lire un texte historique autrement que linéairement. En maths ou en info c'est très différent. Il n'est pas rare d'avoir besoin de lire par couches successives et dans un ordre différent que celui affiché (et c'est normal). De fait, la présentation devrait en tenir compte alors que là c'est pénalisant.

Si le lecteur a envie de voir les résultats et méthodes de mon tuto en rédaction, il doit se taper la lecture de tout alors qu'il n'en a pas envie. S'il veut retrouver la signification d'une notation, bon courage sans chercher dans tout le texte. S'il veut lire les faits sans les preuves, impossible sans un effort particulier au lecteur (alors que je devrais l'indiquer).

Concrètement il est difficile de marquer le découpage du texte. Difficile d'indiquer le cadre formel. Difficile d'indiquer au lecteur les différentes "couches".

Pour les démos tu devrait les mettre dans une balise secret, c’est plus ou moins ce que fait Wikipédia d’ailleurs.

Ouais mais non. Les démonstration c'est essentiel dans un texte mathématique et le lecteur ne devrait pas passer à côté.

Autant je suis pour réduire légèrement la police, autant je suis entièrement contre les cacher. Parce qu'on comprend toujours mieux un sujet après la démo.

Que la sémantique du terme « secret » ne soit pas la bonne c’est entendu, mais ici c’est juste de la pure mise en page pour ne pas surcharger le texte.

Exactement comme sur les forums ou il n’est pas rare de poster un bout de code dans une balise secret. Il est évident que le code est une partie intéressante du message (voir même le seul intérêt), c’est une question de lisibilité de la page voilà tout.

Et si tu veux absolument un truc spécifique, ça va dans le 2ème point de la liste de Kje.

Depuis le début j'essaye de dire que je veux que le lecteur ait une lecture plus confortable, pas qu'il passe son temps à cliquer à droite et à gauche pour lire ce qu'il a envie de lire :0. C'est à l'auteur et à la mise en page de faire en sorte que ce soit agréable.

Salut,

Je ne lis JAMAIS de contenu pédagogique sur Internet, et j'essaye le moins possible sur un écran. Comme ce n'est jamais sur Internet, tu comprendras que les rares fois où je suis obligé (pas d'imprimante disponible bien souvent) alors je passe sur du PDF qui est souvent de toute manière bien plus propre et agréable à lire par sa sobriété.
Il faut dire que l'argument de la taille ne tient pas pour moi puisque tu peux zoomer, jusqu'à un certain point, celui où de toute manière ça n'a plus de sens de zoomer davantage, sur un PDF.

Ma lecture sur Internet se limite à des réponses courtes par nature, et dont le besoin de structuration et de présentation est quasi nulle, sur des forums (techniques ou non) ou des billets courts sur des plateformes de type « blog », voire quelques articles de journaux mais ça commence déjà à me piquer les yeux.

La raison est simplement que je trouve toute présentation sur Internet moche en général et qu'on perd une partie essentielle par rapport à la presse papier (ou ouvrages) que je lis, à savoir la maquette et la mise en valeur correcte du contenu. Du coup, en général il y a des PDF qui sont faits exprès, avec une mise en page plus ou moins soigné car il s'agit d'un ouvrage complet.

Tu comprendras que pour moi la question ne se situe donc pas dans la génération du PDF qui est de toute manière une conséquence de ce que j'évoque.

Je trouve que pouvoir allier à la fois système générique d'édition et de publication avec une mise en page propre à chaque contenu, tout en gardant une structure et des meta-données sous-jacentes qui permette un travail de sémantique et de data-mining est un défi majeur que l'Internet doit relever pour totalement exister en tant que média presse / edition. Cela semble impossible mais à vrai dire j'ai vu passer des discussions là dessus dans un certain laboratoire français bien connu dédié à l'informatique notamment et donc cela ne m'étonnerait pas que ce puisse être un sujet actif de recherche dans les prochaines années.

Je suis pour le coup totalement HS par rapport à la discussion initiée, mais c'était peut être pour relativiser la nécessité d'une fonction d'export de PDF qui soit visuellement au top.

De manière général, je suis en accord avec le message de Dominus Carnufex. Dans le détail, je voudrais un système qui marche (ce qui n'est pas le cas du système actuel dans le cas des gros tuto mathématiques). Les solutions proposée (rendu serveur, rendu dégradé, images…) me conviennent toute, puisque de toute façon, je n'attends pas d'une intégrale la possibilité de faire un copier/coller (mais si c'est possible à la wikipedia, c'est un plus).

En tant que lecteur, un système d'affichage différent pour les démonstrations, comme il en existe pour le code (```), serait utile. De la même manière, j'imagine difficilement un texte un peu long sans numérotation des équations.

Pour finir, les notes, les abréviations, les définitions et les références sont 4 choses différentes. Les deux premiers sont présentes. Les définitions ont déjà été discuté par Holosmos plus tôt (sans qu'une solution simple ne soit trouvé). Pour les références, leur absence m'a dissuadé de sourcé l'article que j'ai écrit. Le sourçage, c'est déjà lourd de base, si en plus il faut faire attention pour ne pas le mélanger avec les notes, ça devient méga-lourd. Je tiens à préciser que je suis parfaitement conscient que ça risque d'être très compliqué. On demande ce qui manque/serait un plus, je réponds. Ça m'a manqué, mais ce n'est pas indispensable.

Je n'attends pas d'un tuto sur le net un export parfait pour la lecture, mais tout de même un truc pour dépanner ou pour lire hors ligne (j'ai quelques documents pdf des tutos du SdZ, carrément laid, mais qui m'ont déjà servis par le passée).

En temps qu'auteur, il faut un export « source » (typiquement, le markdown !). De là, j'estime que c'est à moi de transformer ça en vrai LaTeX/ODT/… si je veux faire un document propre (probablement que je ne veux pas, et si je veux, alors je serais prêt à y passer du temps).

À titre purement personnel, l'export ODT, je m'en balance. Par contre le LaTeX m'intéresse. Comme quoi la situation risque de vite devenir très compliqué.

Ah ben enfin un argument recevable ! Enfin ! On y est…

OK, donc, je suis d'accord, ça risque d'être emmerdant si tout le monde peut faire générer le format qu'il veut quand il le veut.

Du coup, j'ai fait quelques essais. Je ne sais pas ce qu'il en est pour Word, mais LibO (et les autres de la même famille) sont capables d'importer du HTML. J'ai essayé avec différents extraits de tutos, pour voir ce qui passait bien, et ce qui merdouillait.

• Les images passent bien, ainsi que leurs légendes, mais pour les images hébergées sur ZdS, c'est une adresse locale qui est donnée, et forcément, LibO ne les trouve pas sur mon disque.
• A priori, les vidéos doivent donner plus ou moins le même résultat.
• Le code est très moche, et toute la coloration syntaxique est perdue, mais au moins il est là, ainsi que la numérotation.
• Les maths ne passent absolument pas, le rendu accole simplement le texte en Unicode sans mise en forme et la formule en LaTeX, qui n'est même pas comprise par l'outil de formules de LibO.
• Les blocs spéciaux (à l'exception du bloc « spoiler » toujours identifié par son lien cliquable) sont totalement passés à la trappe.
• Les notes, forcément, ont la forme de liens internes et non de vraies notes.
• Les liens internes sont bien conservés.
• En principe, le reste marche bien (j'ai testé titres, sous-titres, titres d'extraits, citations, tableaux, gras, italique).

L'essentiel de ces limitations vient du fait que LibO n'utilise pas de classes quand il manipule du HTML mais écrit tout dans les arguments style=.

Tout ça pour dire que, même si c'est loin d'être parfait, on peut déjà avoir une bonne base pour travailler sous un éditeur de texte avec un export du HTML. Ce qui permettrait de se passer de l'export en ODF et en OOXML.

En termes de performances, ce serait équivalent à faire une prévisualisation de l'ensemble du tutoriel depuis l'interface de rédaction. En clair, c'est tout à fait acceptable : l'aperçu est systématiquement affiché quand on édite un extrait, donc faire un export du tutoriel complet consommerait légèrement moins de ressources qu'ouvrir tous les extraits l'un après l'autre pour copier le markdown (ce qu'on est réduit à faire pour l'instant), puisqu'il n'y aurait pas à générer l'interface.

Bref, cela reste une fonctionnalité à développer, et il faut que quelqu'un le fasse, mais au moins on a une solution technique acceptable pour les auteurs et « pragmatique et sans idéologie »…

PS : dans l'idéal, ce serait bien que le HTML exporté ne soit pas strictement celui affiché sur le site. En particulier, il faudrait que les sources des images soient en chemin absolu et non relatif, que les blocs spéciaux soient identifiés autrement que pas une classe, et que les maths ne soient pas générés mais simplement laissés sous leur forme LaTeX de base. Ce n'est pas indispensable, mais ce serait un plus.

Ah ben enfin un argument recevable ! Enfin ! On y est…

C'est juste celui que je répète en boucle depuis 3 pages…

Je fait un up pour plusieurs raisons :

• pour dire bonjour (parce que la politesse) ;
• pour savoir si on peut faire le point sur les évolutions possibles du Mathjax et Markdown ;
• l'ouverture d'une ZEP ? Je sais pas du tout comment ça marche, peut-être que des plus expérimentés peuvent s'y coller

Pour étendre le markdown, je serait pour attendre un peu. Une fois que la zep-5 commencera a toucher au but en genrant les pdf du site, je pensait lancer une grosse zep "markdown v2". Actuellement, avec deux outils en parallèle, c'est assez compliqué de faire évoluer le langage.

En fait, comme l'a dit très justement c_pages sur IRC, il suffirait d'ajouter un bloc neutre pour déjà régler pas mal de soucis de rédaction.

Une sorte de bloc un peu grisé et on pourra déjà présenter bien mieux les contenus scientifiques !

La réponse est donnée par Kje quelques posts plus haut: "faire une ZEP pour étendre la sémantique des blocs". Et là, tu les auras tes blocs "théorème 84" "Lemme 62" et "Exemple 42"

Une sorte de bloc un peu grisé et on pourra déjà présenter bien mieux les contenus scientifique mathématiques !

Fix'd: je rédige du contenu scientifique et je n'ai sérieusement aucune utilité du bloc "théorème" (et pourtant, je fais des publications dans mon domaine). Faut pas déconner, non plus.

"Théorème" c'est un mot assez mathématique. Mais avoir un bloc "hypothèses" ou "loi" ou "algo" ou "whatever" ça peut toujours rendre service dans une rédaction scientifique. En tout cas en maths c'est à mon avis indispensable.

Je disais ça parce que l’environnement "théorème/lemme/machin" existe en (La/Con)TeX et que je sais que c'est à ça que tu fais ultimement référence quand tu fais tes demandes de blocs (ou des environnement que tu a créé toi-même sur base de ceux là, si tu es aventurier). Je dis aussi ça pour dire que un bloc générique est amplement suffisant et qu'il y a pas besoin de sur-spécialiser ou chaque personne va demander "son" bloc spécifique (j'ai pas d'idée sur l'instant, mais je suis sur que je pourrais trouver un truc super-spécialisé dans d'autres domaines).

En fait je préfere éviter de toucher au markdown tant que la zep 5 n'est pas plus avancé. La solution pratique mérite de toute façon débat mais clairement je suis pas motivé pour lancer ce chantier tout de suite, pour m'éviter de toucher au python-zmarkdown. Apres si un truc simple est fortement demandé par la communauté je peux faire une exception mais faut que la solution soit pérenne et discuté.