Rédaction scientifique

Plop,

Bon. Ça fait un moment que j'ai du mal avec les messages sur le forum mais depuis que j'essaye de rédiger un mini-tuto le besoin se fait encore plus ressentir de mon côté de faire un topic à ce sujet.

La rédaction scientifique est mal pensée !

Il y aurai plusieurs points que j'aimerai soumettre à vos avis :

• les possibilités de faire des macros pour le LaTeX ;
• la taille de la police de Mathjax totalement $d$ém$e$su$r$ée (même si j'ai fait parti de ceux qui ont voulu la grossir …) ;
• le problème de justification/alignement du texte ;
• des environnements pour les preuves et énoncés ;
• des possibilités pour faire automatiquement un index de notations.

J'ai des difficultés avec tout ce que j'ai cité plus haut. Et c'est pour moi un sérieux problème : je perds un trop beaucoup trop important à la gestion de la forme au lieu de m'inquiéter du fond de ce que j'écris. Je perds beaucoup en clarté quand j'essaye d'être rigoureux ce qui est quand même gênant quand on essaye de rédiger des maths …

Ou alors je suis le seul à me plaindre. M'enfin pour moi il y a une énorme différence de forme entre l'aspect visuel d'un article scientifique et d'une rédaction ici.

Peux-tu éclaircir le point "le problème de justification/alignement du texte" ? J'ai une erreur 403 quand je vais sur le lien de la rédaction. As-tu bien activé la beta ?

J'ai changé et mis le lien de la beta (étrange qu'il y ait deux liens différents possibles !).

Pour la justification, j'ai toujours trouvé ça beaucoup plus lisible et confortable d'avoir un texte justifié (du moins en maths). Du coup j'aimerai en discuter ici, ce que vous pensez m'intéresse

Il y a déjà eu des débats sur la justification ou non sur le web. Il y en eu un ici. Personnellement je suis contre.

Fais gaffe aussi à ne pas confondre les formats prévus par l'impression et l'affichage web/mobile.

C'est-à-dire ?

Tu veux dire que si on exporte en pdf on a bien une justification alors que pour l'affichage web/mobile non ? C'est quand même étonnant d'avoir deux politiques différentes …

C'est-à-dire que le PDF que tu montres est un format destiné à l'impression qui n'obéit pas aux mêmes règles et contraintes qu'une présentation pour affichage sur écran;

Le PDF a une justification parce qu'il (enfin, LaTeX qui le génère) gère correctement les coupures de mots, ce qui évite les brisures dans les lignes. C'est très exactement ce point – donc la non gestion des coupures de mots par le navigateur – qui fait qu'aujourd'hui on peut très difficilement avoir une justification propre sur navigateur. Et donc qui fait qu'on a décidé de s'en passer : la lisibilité nous paraissait préférable à l'aspect extérieur.

Sinon pour les autres points :

les possibilités de faire des macros pour le LaTeX ;

Ça c'est a voir coté mathjax.

la taille de la police de Mathjax totalement démesurée (même si j'ai fait parti de ceux qui ont voulu la grossir …) ;

Je ne la trouve pas spécialement grosse (mais peut être que ça dépend du navigo?). Dans tous les cas c'est facile à régler.

des environnements pour les preuves et énoncés ;

Que veux tu dire par là ? tu peux détailler ? Encore une fois, si c'est à l'intérieur des balises $, c'est mathjax qui va gérer ça et on a assez peu d'emprise là dessus. Si tu veux une syntaxe markdown pour styliser ces éléments, on peut en discuter par contre.

des possibilités pour faire automatiquement un index de notations.

Tu peux détailler aussi ce plus précisément ce point ? Que voudrais tu réellement ? Ton système idéal ?

Dans l'ensemble un certain nombre de point peuvent probablement être amélioré si quelqu'un prend son courage à deux mains pour configurer convenablement mathjax.

Mais dans l’ensemble comme mathjax prend les formules indépendamment les unes des autres, il va pas être facile de faire partager des choses entre plusieurs formules.

Pour le reste (probablement ton dernier point même si j'attends les détails) je pense qu'on pourra l'envisager à moyen terme. Actuellement c'est compliqué de faire des choses globales, partagé sur l'ensemble du tuto, car le markdown ne reçoit que les extraits indépendamment. Dans mon début de travail sur la refonte de cette section, j'ai prit une organisation qui devrait permettre ce genre de chose. Mais c'est loin d'être prêt.

Ah je suis pas contre ces idées en maths et physique ça doit être intéressant.

Pour l'énoncé je pense a un type de balise genre citation mais on mettrai un énoncé de problème (couleur de police plus lisible, et posibilite de mettre un titre plutôt qu'une source de citation, genre "Exercice 1".

Ensuite pour les index de notations si j'ai bien compris c'est le détail de ce que représente chaque élément dans une équation ?

Delta = b² -4ac

Delta : discriminant A : facteur devant x² B : facteur de x C : chiffre

Ça serait bien : au survole d'une équation d'avoir le récapitulatif des lettres, de leur sens. Dans un tableau dynamique

Plop,

Ok je comprends mieux pour la justification du texte.

Ah bah tu trouves pas qu'on voit clairement une différence de taille entre la police du texte et du mode math ? Personnellement elle est flagrante et même gênante.

Je veux dire des sortes d'encadrés (léger l'encadrement …) pour repérer plus facilement les énoncés, démo. Actuellement sur mon mini-tuto je trouve pas ça assez structuré et mal indiqué lorsqu'il s'agit d'un résultat ou d'une argumentation.

Idéalement, en début de texte, pouvoir faire un tableau où à chaque ligne on a un symbole et son explication.

Par exemple

• $\hat{\mathbf{C}}$ : la sphère de Riemann ;
• $\mathbf{C}\mathbf{P}^2$ : le plan projectif complexe ;
• ${\rm deg}(f)$ : le degré topologique de $f$ ;
• $v_x$ : le vecteur $v$ tangent à $x$.

Ce serait idéal d'avoir un système où l'auteur peut renseigner en même tant que l'écriture du corps la signification. I.e. lorsque j'écris pour la première fois $\hat{\mathbf{C}}$ je peux écrire avec une balise la définition de ce symbole.

Ce serait vraiment un système pour le document en général, contraire à ce que pense Blackline. Certains symboles sont très connus et ne nécessitent pas particulièrement d'attention (par exemple $\mathbf{R}$) mais d'autres sont plus exotique et devoir relire tout un document pour retrouver la signification est pas top.

Je veux dire des sortes d'encadrés (léger l'encadrement …) pour repérer plus facilement les énoncés, démo. Actuellement sur mon mini-tuto je trouve pas ça assez structuré et mal indiqué lorsqu'il s'agit d'un résultat ou d'une argumentation.

Tu voudrais avoir un bloc énoncé et un bloc démo, un peu comme

Donc pour les démos, tu voudrais une syntaxe markdown type celles pour les blocs d'infos ? plutot qu'un truc spécifique aux math ? Dans ce cas, c'est possible au niveau markdown. Il faudrait peut etre définir une balise particulière et configurable car ça va vite être long si on doit rajouter une syntaxe pour chaque type de blocs que quelqu'un voudra. On peut donc réfléchir à un type de bloc générique.

Pour le dernier point, en gros, tu voudrais une syntaxe type celle pour les abréviations mais plutot que de faire des abréviations ferait une liste de définition au début du tuto ? Dans ce cas ce n'est pas vraiment possible actuellement mais ça pourra l'etre a moyen/long terme quand le module aura été refait.

Pour la police, chez moi je vois une différence de police et une légère différence de taille mais le rendu est différent sur mon pc de bureau et mon tel alors… Je pense que ça c'est de la config de mathjax.

Oui mais en plus léger pour les blocs. Le but c'est pas de faire un énorme arc-en-ciel …

Dans mes documents LaTeX j'ai un très léger trait à gauche de chaque énoncé/démo et ça suffit largement.

Yup, l'idée c'est ça pour les notations.

Pour l'instant, j'utilise les citations pour différencier un peu certaines parties mathématiques du reste du texte. C'est le plus discret par rapport aux autres blocs.

Tu n'es pas le premier à demander un type de bloc particulier. On pourrait très bien imaginer assouplir la syntaxe des blocs pour un accepter un truc genre :

1
2
3
4
5

[[Énoncé]]
| Mon super énoncé

[[Démonstration]]
| Mon super énoncé

Qui produirait, quand ce n'est pas un des 5 actuellement définit, un div avec une légère mise en évidence et l'élément entre crochet en titre. Le style de tous ces blocs perso seraient identique mais le titre viendrait les personnaliser. On peut même imaginer calculer une sorte de hash a partir du titre qui déffinirait ainsi une couleur (légère) pour le fond du bloc. Ainsi deux blocs démonstrations auraient une couleur identique mais un bloc démonstration et un bloc énoncé auraient un rendu différent.

Ça rejoint un peu quelque chose qui me manque : un bloc "aside" générique. Pour gérer l'équivalent des encadrés dans un journal imprimé.

Est-ce que ça ne pourrait pas te convenir ?

Ces deux idées me paraissent pas mal. Faudrait quand même faire quelques tests pour en être sûr mais ça me plaît

le problème du coté "aside" est qu'elle a une sémantique de "non indispensable" différent de sa demande. Au moins au niveau de la balise du meme nom en html5.

Je pense qu'un bloc générique serait une bonne idée, avec la possibilité de spécifier un titre, chacun pourrait l'utiliser comme bon lui semble. Et comme dit plus haut, si le front met à disposition par ex 10 classes de rendu, je peux en sélectionner une a partir du hash du titre.

Si cette idée plait, suffit de faire un sujet dédié.

Pour le reste, la table des définitions ça me semble si ce n'est impossible, très compliqué actuellement. Il vaut mieux attendre la refonte.

Et il reste a trouver quelqu'un pour toucher à la config de mathjax

le problème du coté "aside" est qu'elle a une sémantique de "non indispensable" différent de sa demande. Au moins au niveau de la balise du meme nom en html5.

Je ne nie pas. Par contre, c'est bien ce côté "non indispensable" qui m'intéresse.

Bah alors on a peut être deux trucs différents là. Un nouveau type de bloc en plus des 5 existants pour la sémantique aside et la possibilité de faire des blocs génériques.

Notez que les deux sont pas spécialement dur à faire coté markdown. Le plus chiant serait peut être le aside car il faudrait générer la balise html5 particulière plutot qu'un div pour les autres, mais ça sera facile à rajouter.

edit: on peut imaginer aussi rajouter la sémantique aside comme un attribut des blocs. Par exemple :

1
2
3
4
5

[[Mon bloc]]
| Je suis un bloc normal

[[Mon autre bloc]]@
| Je suis un bloc type "aside" avec "Mon autre bloc" comme titre

Ce qui permet de conserver la possibilité de mettre un titre sur les asides

une autre solution serait de considérer qu'on rajoute la possibilité de mettre les titres. la syntaxe serait alors par exemple :

1
2

[[type_bloc]] : Mon titre de bloc
| Mon contenu

type_bloc serait alors une valeur parmi {attention|secret|information…|aside} (ou parmit {a|s|i…|o} pour les versions raccourcis) ou une valeur perso pour indiquer un type générique. Ce champs indique alors le type de bloc, parmi ceux existant + aside ou un que les auteurs peuvent utiliser pour différencier ces blocs du reste en les associant à une sémantique propre.

Le titre du bloc vient se rajouter à l'existant et est optionnel. Là on fait coup triple car en plus de permettre une personalisation du titre (le type_bloc va identifier la sémantique énoncé par exemple mais on peut lui donner comme Titre "Énoncé 3.14" sans que ça dissocie la sémantique) on permet de rajouter des titres aux blocs existant (ça a déjà été demandé plusieurs fois, entre autre pour les spoiler) tout en assurant la compatibilité avec le contenu existant (puisque le titre est optionnel).

Si ça plait, je peur proposer une zep sur le sujet ce week-end, histoire qu'on en duscute de l'extension des blocs, la syntaxe et qu'on coordonne markdown et front pour implémenter ça.