ZEP-05 : Refonte du traitement markdown pour l'export

a marqué ce sujet comme résolu.

À titre personnel, je ne mettrais pas le fond de couleur. Stricto sensu, la simple indentation supplémentaire du texte suffit à matérialiser une citation longue (c'est comme ça qu'on fait ordinairement en typographie). Les guillemets géants lèvent toute ambiguïté, aussi le fond différent apparaît quelque peu superfétatoire.

En terme de design, je ne vaux pas grand chose, mais si vous avez besoin d'avis sur la typo pure, je peux proposer mon aide.

+0 -0

@Dominus

J'ai fais les quelques modifs que tu m'a proposé :

Mais tout cela ce sont des modifs au niveau template et comme le souligne Eskimon c'est très facile et rapide à faire quand on connaît Latex. Je pense que quand tout sera correctement parsé, on pourra faire un sujet dédié au rendu pdf. Je montrerais le rendu et on essaira de l'améliorer. Voir si quelqu'un propose un design particulier, je pourrais tenter de le reproduire. Mais cette intégration est assez mineur pour la majorité des éléments (exception faite des tableaux qui vont être assez compliqués a styliser).

@Eskimon : <3

[mode-reveur] On pourrait même organiser un/des des ateliers pour que les zesteurs proposent leurs propres templates étou (mon dieu j'aime ce site et son ouverture qui permet tant de choses et de perspectives) [/mode-reveur]

Bah vas y lance si ça te fais plaisir. Je ne suis pas particulièrement persuadé qu'on a beaucoup de monde qui reve de designer des pages de livres, mais pourquoi pas.

Bonjour,

J'aurais besoin d'un avis. Pour implémenter le parsage des smileys, on a besoin du lien "chaine à detecter" -> "image à afficher". Je pourrais les mettre en dur mais ce ne serait pas terrible.

Une autre solution est de passer un fichier dédié. Pourquoi pas.

Je propose une 3 options : transformer les smileys en "abbréviation d'images". En gros tout comme pour les abbréviations de texte, on utiliserait un pattern pour définir ce lien. Par exemple :

1
*![:-)](smile.png)

Le support des smileys pour pandoc consisterai dans pandoc donc de juste parser ça et ainsi faire les remplacements. Le site pourrait alors supporter nos smiley en fournissant avant l'extrait la liste des smileys de base. On gagnerait au passage la possibilité aux auteurs de rajouter leurs propres "smileys" localement, uniquement confiné à leur message. Cela ne serait pas forcément souvent utile mais dans le cadre de certains tutos où il peut être necessaire d'insérer une même petite image régulièrement dans le texte, ça pourrait être pratique.

Vous en pensez quoi ?

+0 -0

Dans l'optique "pouvoir changer a la volée le pack de smiley utilisé quand je navigue sur le site" lequel serait le mieux ?

En dur ce serait la mort. Les deux autres c'est pareil, tu passera le fichier qui correspond au pack dans la ligne de commande, c'est très facile. En gros la différence est de savoir si on rend accessible au markdown de l'utilisateur la possibilité de spécifier un smiley.

+0 -0

[…] la différence est de savoir si on rend accessible au markdown de l'utilisateur la possibilité de spécifier un smiley.

C'est un bon moyen d'avoir un effet sapin de noel, a mon avis c'est a éviter… (mais ce n'est que mon avis). Perso quand je navigue j'aime avoir une certaine harmonie, et ne pas voir des smileys de différents sets en fait parti.

+0 -0

Cela ne permet de spécifier un smiley que localement. Dans un unique message. Typiquement tu mettrais dans ton message :

1
2
3
*![<3](coeur.png)

blal blalb <3

Cela remplacerais juste le coeur dans ton extrait. Ça ne va pas s'éttendre ailleurs que dans le message. Du coup il n'y a pas vraiment plus de risque qu'actuellement car il est déjà possible d'insérer les images que tu veux dans un message.

+0 -0

Dans l'optique "pouvoir changer a la volée le pack de smiley utilisé quand je navigue sur le site"

Pour les PDF c'est à proscrire. Pour le site, c'est à voir.

Avec la solution que tu présentes Kje, ça voudrait dire qu'il faudrait un fichier qui liste les smileys avec le format que tu indiques :

1
2
3
*![<3](coeur.png)
*![:)](content.png)
*![:(](triste.png)

et que changer de thème de smiley = charger un fichier différent, avec des URLs différentes. C'est bien ça ?

et que changer de thème de smiley = charger un fichier différent, avec des URLs différentes. C'est bien ça ?

Yep mais en fait la syntaxe, peut importe en fait. En gros le truc est qu'il faut pouvoir passer la liste des symbole avec l'image associé. Soit on passe alors à Pandoc un fichier de conf (genre un json) avec ces infos, soit on ajoute une syntaxe pour définir ce "lien" directement en markdown, comme on peut le faire actuellement avec les abbréviation. Dans les deux cas, pour définir une série de smiley pour le site, cela revient a fournir un fichier de plus a pandoc (puisque pandoc concatène tous les fichiers qui lui sont fournit on peut lui préparer un fichier contenant la définition des différents smiley de base). La seule vrai différence est que si c'est une syntaxe markdown, cela veux dire que l'auteur peut définir lui aussi ce genre d'annotation dans son texte. La question est donc de savoir si c'est genant ou pas.

À part ça, je trouve la façon de faire propre et astucieuse.

En fait c'est surtout que rajouter ça dans le markdown m'évite de faire des modifs ailleurs que dans le parseur de markdown. Sinon il faut que je rajoute un argument sur la ligne de commande, le parse spécifiquement, etc.

Petit point d'avancement

Bon j'ai pas eu des tonnes de temps cette semaine. depuis la dernière fois les commentaires dans le markdown sont supportés tout comme les légendes explicites des figures et des formules mathématiques + quelques petits bugs et des corrections proposés ici sur le rendu. Bref, ça avance doucement. Le gros du boulot qu'il reste va être les abréviations qui sont parsés mais ignoré par pandoc qu'il va être difficile d'insérer d'une manière compatible a la fois entre le html et les pdf sans toucher à l'AST, et les Smileys qui me demandent d’interagir avec le monde extérieur pour avoir la liste des smileys à parser.

+0 -0

J'ai rajouté le support des abbréviations. Ça n'a pas été simple sans toucher à l'AST mais ça devrait le faire. Pour le rendu PDF, je regroupe toutes les abréviations définit dans le markdown dans une section dédié qui est inséré en début du document, dans chapitre non numéroté.

Exemple de rendu d'une page listant les abréviations d'un big tuto

Au niveau parsing, je commence donc a voir le bout, il reste :

  • Au moins Dailymotion en plus dans les vidéos
  • Smiley
  • Légende des codes + Support de la mise en évidence de lignes de codes en particulier

Comme dit sur un autre sujet, j'ai décidé d'arrêter de développer sur zds, a minima. Cette zep est donc la principale concerné.

Comme déjà dit, tout le dev fait pour l'instant sur Pandoc est dans un branche "zds-flavored-markdown" dans le fork qui est sur mon compte github. Mercredi je pousserais en rab une modif du template actuel pour supporter tout ce qui a été ajouté. Si quelqu'un veut reprendre, qu'il n'hésite pas. Moi je m'en occupe plus.

Salut !

Accepterais-tu d'aider quelqu'un à reprendre ton travail, en lui expliquant ce que tu as fait, comment tu l'as fait et ce qu'il était prévu de faire ?

Je n'ai personnellement pas le temps de m'atteler au code, mais je veux bien jouer le rôle du débutant perdu pour aller vers la rédaction d'une explication technique de la ZEP.

Merci !

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte