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

a marqué ce sujet comme résolu.

En fait j'ai repris la couleur utilisé sur le site. Mais pourquoi pas, à voir. Après il faut bien voir que l'on ne pourra pas contenter tout le monde et, surtout, je ne suis pas sûrs d'être le mieux placer pour faire ce genre de choix. Je vais je pense corriger un peu les codes pour que ça jure moins vis a vis du reste et ensuite éviter de trop y toucher. Il faut déjà vérifier que la majorité du contenu passe bien, sans erreurs de compilation avec un rendu a correct. Quand ça ce sera fait, le reste ce sera des ajustement du template. On pourra lancer une plus grande concertation des membres sur le rendu précis. Mais a court terme je ne suis pas sûrs que l'urgence soit de régler au pixel pret les couleurs.

Un truc qui me gène, c'est le chevauchement inter-page des code qui est parfois carrément stupide. Par exemple, entre les pages 7 et 8, on a une accolade qui se balade. Entre les 10 et 11, c'est un commentaire sur deux lignes qui est tronqué (conclusion : il ne faut pas faire de commentaire sur 2 lignes !). Si on est dans les cas nécessitant une adaptation humaine dont on parlait dans l'autre sujet, soit ! C'est juste pour savoir s'il était possible d'imaginer quelque chose de simple, notamment pour le cas où le code dépasse d'une seule ligne.

J'insiste, si ce n'est pas possible facilement, un « pas possible » me contentera pleinement !

Édit : on a toujours un émoticône géant.

+0 -0

Tous les éditeurs de textes modernes gèrent parfaitement les lignes veuves et orphelines (c'est le nom du phénomène que tu décris). Vue le soin qu'apporte LaTeX à la typographie et tout, je serais très surpris qu'il n'y ait aucune option pour gérer ce genre de chose.

Le problème est là qu'on est pas dans de la typo pur mais dans des blocs de codes. C'est pas tant Latex qui a l'emprise mais le paquage listings. J'avais remarqué et je vais essayé de trouver un truc. Le truc est qu'il faut trouver un moyen pour que ce soit adaptatif. Un code qui tiens sur plus d'une page devra, forcément, être coupé. Dans le reste des cas il faudrait qu'il évite sauf si ça introduit trop de blanc. Je voudrait éviter de mettre les listings de codes dans des flottants car souvent le texte avant/après y fait référence directement, la position est importante. Je ne peux pas dire si ça va être facile ou non, j'ai pas encore cherché.

Édit : on a toujours un émoticône géant.

Oui c'était pas clair sur mon message mais c'est a priori réglé en local mais pas appliqué sur le pdf. La raison est que ça m'a demandé une petite modif dans le code de pandoc (pour distinguer Figure et images inlines) et j'ai dut, pour vérifier, recompiler pandoc, mettre a jour pas mal de trucs, etc. Comme j'étais sur mon eeepc, ça prenait du temps et comme j'allais me coucher, je ne savais pas si j'aurais le temps de finir. Donc j'ai envoyé le pdf sans mais j'étais en train de le régler en local. J'ai fais le choix de fixer les images inlines à une hauteur égale à celle du texte. Ça me semblait une bonne idée et on va voir ce que ça donne. La conséquence, ici, est que le smiley dans les notes de bas de page est du coup minuscule mais dans le texte ça devrait être propre.

Bon vous je ne sais pas mais moi cette ZEP qui avance dans l'ombre ça me saoule a force. Je vais donc je pense commencer le chemin de la mise en prod en visant son utilisation pour, dans un premier temps, la génération de pdf des articles.

Le plan est donc :

  1. Vous reproposer une version de l'article C++14 qu'on discute si le rendu est acceptable, si il y a des trucs flagrants à changer, etc.
  2. Passer le code sur TOUS les articles actuellement en prod. Le but est double :

    • Vérifier qu'aucun article de fait planter la compilation latex
    • Déceler de nouveaux problèmes de rendus (j'aurais besoin de vous pour tout regarder ;) )
  3. Nettoyer le code du fork de pandoc, rebaser avec l'upstream, le passer sur un dépot gérer par zds et documenter les principales modifications faites (je ne sais pas trop où mais bon)

  4. Nettoyer le code de "ZesteDePandoc" (le module python chargé de transformer une archive de tuto en un export, en assemblant les extraits, les infos metas, etc; le nom est temporaire, si vous avez mieux…), le passer sur un dépot gérer par zds et documenter les principales fonctionnalités.
  5. Repasser tous les articles avec ça (avec le fork de pandoc et avec l'original pour vérifier qu'a minima ça compile) pour vérifier que tout va bien.
  6. Intégrer ça dans le code de zeste de savoir.
+9 -0

Bon voila une nouvelle version de l'article. il y a encore quelques soucis mais j'ai bien du mal a voir comment les résoudres :

  • le tableau avec code est trop grand et dépasse de la page (a moins de connaitre a l'avance la largeur des colonnes ça semble impossible)
  • On ne peut pas remonter des notes de bas de page vers la définition d'un clic. C'est pas très genant je pense (car c'est destiné au papier et, au pire, ça fait moins d'une page a remonter). Je ne sais pas pourquoi le package "footnotebackref" ne marche pas.
  • dans la liste repertoriant les liens à la fin, ceux provenant des titres sont soulignés et pas les autres. Je n'ai aucune idée du pourquoi !

Pour les tableaux, peut-être qu'on ne peut pas gérer ça automatiquement, mais c'est possible de revenir sur le LaTeX pour modifier la taille du tableau non ?

Sinon, je suis tombé sur ce genre d'outils : http://baruch.ev-en.org/proj/chktex/ . Ca ne va pas aider pour générer automatiquement du code, mais ça peut donner plus d'informations sur par exemple pourquoi tu as les deux autres problèmes. Il y a d'autres outils à la fin de cette page : http://en.wikibooks.org/wiki/LaTeX/Errors_and_Warnings

Il reste un problème sur les liens.

Exemple, ce sera plus simple : la partie 2.1 contient un lien (2.1 Littéraux binaires (N3472 [Lien-1])). Dans la table des matières, ce lien n'est pas cliquable, car un clic renvoie vers la partie 2.14. Le titre de la partie s'appelle « 2.1 Littéraux binaires (N3472 [Lien-17]) », le numéro du lien, qui est ici cliquable, a été changé. Dans la rubrique liens, on remarque que les liens 1 et 17 sont bien identiques. Corrections proposée : ne pas mettre de liens dans les titres de la table des matières (de toute façon, ils ne sont pas cliquable !).

Pour le coup, je ne vois rien d'autre.

+0 -0

Bon pour les tableaux j'ai essayé pleins de trucs et ça marche pas :( c'est peut etre la combinaison tableau + code inline qui pose soucis. Pour le moment je laisse tomber.

Par contre pour les liens dans les titres je pense avoir trouver une solution. Ça me demande de changer des trucs dans le generateur latex de pandoc mais ça devrait virer les liens dans la TOC uniquement. Ce qui fait qu'elles ne seront plus en double et au passage ça va virer ceux qui ont un soulignement anormal dans la liste finale.


edit: Je confirme, ça fonctionne. Merci Gabbro d'avoir remarqué ça :)

+0 -0

Je viens de me rebaser avec l'upstream de Pandoc. Ils ont semble t'il commencer à rajouter CommonMark dans les langages supportés. Ce qui est étonnant est qu'au lieu d'en faire un dérivée du module markdown actuel, un tout nouveau, a part, a été créé. Cela veut dire que si on veut, a terme, être compatible commonmark, il faudra faire un travail supplémentaire pour pousser nos extensions dedans. Mais la bonne nouvelle est que cette ajout ne va pas provoquer de conflits avec les ajouts qu'on a put faire, et donc éviter des soucis court terme.

Salut Kje, j'ai une question un peu naïve, mais l'ancienne version de zmarkdown était vraiment très très simple à embarquer dans n'importe quelle application (juste deux répertoire à gratter). Pas de dépendances à installer ni rien.

En sera-t-il de même pour la version basée sur pandoc ? C'était bien pratique pour embarquer le parseur zmarkdown dans une app Java par exemple (firm1 l'avait fait je crois, et moi aussi).

S'il y a besoin de dépendances python à installer sur le système, est-ce-qu'il existe en Python l'équivalent du fatJar (ou shadowJar) en Java, qui va extraire toutes les dépendances pour les regrouper et les packager dans une seule et même archive ?

+0 -0

Pour ta question de dépendance, je ne sais pas trop. Je suis toujours sous unix ou j'instale tout a coups de pip ou apt-get. Pour la deuxième question, pour un équivalent d'avant (ie un extrait md -> une sortie HTML) il faudra utiliser pandoc. Donc il faudra le compiler pour la plateforme. De là tu peux l'appeler facilement en utilisant les entrees et sorties standard. Normalement GHC permet de compiler sur pas mal de plateforme donc je ne pense pas que ce soit un gros frein. Le binaire générer est normalement autonome. Le builder de pandoc permet aussi de générer un executable qui inclus les data donc on pourrait envisager d'inclure les css du site directement dedans.

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