Tufte-css: Démarquez-vous ?

Pandoc propose des modèles sur lesquels s'appuyer, la création d'un modèle Tufte pandoc devrait donc être simple.

@langford s'avère qu'il existe déjà un modèle Tufte pour Pandoc, voir mon commentaire ici pour plus de détails sur la conversion de Markdown/Multi-Markdown en style Tufte : https://github.com/daveliepmann/tufte-css/issues/30#issuecomment - 128718117

@xHN35RQ après $body$ et s'attend à peu près à mettre du texte avant et après, et ne semble pas destiné à manipuler réellement le texte généré à partir de la démarque. Vous utiliseriez des rédacteurs personnalisés pandoc que vous pouvez écrire (alléluia) en Lua. J'ai écrit un écrivain personnalisé barebones qui implémente simplement des notes secondaires et ajoute la balise article : voir gist . J'espère étendre cela au fur et à mesure que je continue à écrire tufte-css pour inclure toutes les fonctionnalités fournies, idéalement sans avoir à modifier quoi que ce soit à propos de pandoc markdown ou de ses lecteurs.

(Pour être complet, je pourrais mentionner les filtres pandoc comme quelque chose qui pourrait éventuellement être nécessaire pour produire entièrement du HTML compatible tufte-css à partir de la démarque pandoc, mais probablement uniquement pour des choses très délicates. Les filtres manipulent l'AST, avant qu'un AST ne soit donné à un écrivain personnalisé . Le bon endroit pour créer des notes de style tufte-css était dans le rédacteur personnalisé, pas en tant que filtre.)

@fasiha bon travail. Vous avez fait un début prometteur ici. :+1:

Je ne pense pas qu'il existe un équivalent facilement disponible aux _sections_ tufte-css dans Markdown, c'est-à-dire un regroupement de paragraphes et de titres. Mais je pense que j'aime l'idée des sections, je pense qu'avoir un niveau supplémentaire d'organisation des documents sera utile sur la route.

Des suggestions de la communauté sur la façon d'indiquer des sections dans Markdown ?

@fasiha Qu'en est-il d'un filtre qui prend les éléments de titre et tous les éléments de paragraphe jusqu'à l'élément de titre suivant ? Ensuite, enveloppez-les dans des balises <section> (ou des balises <div> ) et appliquez-y le css souhaité ?

Merci d'avoir pesé @vyp. D'après ma lecture de la première page de tufte-css, section peut capturer plus d'un titre, ou des paragraphes sans titre. C'est-à-dire qu'il ne s'agit pas simplement d'un conteneur d'en-tête et de contenu. Dans mon document, j'intègre simplement <section> tant que code HTML brut dans le Markdown pour le moment. Pour cela, je pense pouvoir accepter le code HTML brut.

@fasiha Ah désolé, vous avez raison. Parce qu'une section est définie comme un "groupement logique de texte et de titres", il est impossible de déterminer exactement ce qu'est une section dans un document sans intervention humaine (c'est-à-dire que nous marquons en fait les sections comme des informations sémantiques, tout comme nous marquons avec accent avec des astérisques ou des traits de soulignement). Et oui, je ne suis au courant d'aucune syntaxe préexistante pour ces "sections" dans n'importe quelle saveur de démarque, alors bonne prise.

L'utilisation <section> balises

Une autre façon de procéder serait d'utiliser le fait que tufte dit qu'il utilise h2 pour les "titres de section", donc peut-être qu'une "section" peut être définie comme une balise h2 et tout jusqu'à la balise h2 suivante et ainsi de suite. Mais je ne sais pas si c'est ce que voulait l'auteur de tufte.

Les éléments H2 ne sont pas des sources fiables de démarcation de section. Par exemple, certains documents utilisent à la place des étendues « nouvelle pensée ». Je suis sûr que d'autres variations apparaîtront dans la nature.

Le 8 août 2015, à 23h49, vyp [email protected] a écrit :

@fasiha Ah désolé, vous avez raison. Parce qu'une section est définie comme un "groupement logique de texte et de titres", il est impossible de déterminer exactement ce qu'est une section dans un document sans intervention humaine (c'est-à-dire que nous marquons en fait les sections comme des informations sémantiques, tout comme nous marquons avec accent avec des astérisques ou des traits de soulignement). Et oui, je ne suis au courant d'aucune syntaxe préexistante pour ces "sections" dans n'importe quelle saveur de démarque, alors bonne prise.

Utilisation brute

tags est la meilleure chose à faire dans ce cas (autre que de définir votre propre syntaxe de type démarque pour cela et d'écrire un analyseur pour cela).

Une autre façon de procéder serait d'utiliser le fait que tufte dit qu'il utilise h2 pour les "titres de section", donc peut-être qu'une "section" peut être définie comme une balise h2 et tout jusqu'à la balise h2 suivante et ainsi de suite. Mais je ne sais pas si c'est ce que voulait l'auteur de tufte.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Je suppose que si quelqu'un veut éviter d'utiliser des balises <section> dans leur démarque, une syntaxe similaire à celle de <hr> peut ne pas être difficile à implémenter. La syntaxe pour les <hr> 's est essentiellement "trois tirets, astérisques ou traits de soulignement ou plus sur une ligne par eux-mêmes". Ainsi, par exemple, vous pouvez définir arbitrairement une démarcation de "section" comme "trois signes égaux ou plus" (ou ce que vous préférez), puis utiliser un filtre pandoc pour tout envelopper entre chaque couple de ces paragraphes avec uniquement des signes égaux.

J'ai seulement choisi "une ligne de signes égal" parce que je suppose que c'est à quoi ressemblerait la division des sections avec du texte brut ? Et parce que pandoc markdown analysera cela comme un seul paragraphe, ce qui signifie que votre filtre peut simplement vérifier chaque paragraphe s'il n'a que des signes égal ou non, et s'il est uniquement composé de signe égal, supposez que cela fait partie d'une démarcation de section.

Salut à tous (et merci à @daveliepmann de glasseye dans lequel j'ai utilisé le Tufte.css (donc merci à tout le monde pour cela) et dans lequel j'ai cherché à intégrer le markdown, d3 et la mise en page Tufte. Pour le moment, c'est vraiment un prototype avec beaucoup de coins coupés. Quand j'aurai un moment, j'aimerais nettoyer le code et rationaliser un peu la conception (à ce stade, je vais parcourir vos commentaires sur le css). Mais je voulais voir si cela valait la peine de le faire en premier et je pense que c'est le cas. Quoi qu'il en soit, j'aimerais avoir des commentaires.

ReStructuredText se prêterait-il mieux que Markdown au type d'annotations nécessaires ici ?

@coppeliaMLA Merci d'avoir mentionné glasseye, c'est un travail incroyable.

@rbcarson Je ne suis pas OP, mais si la question s'adresse à tout le monde ici et que vous voulez mon avis, je ne connais personnellement pas très bien le texte restructuré, donc je ne peux pas vraiment le dire. Mais vous avez peut-être raison, la syntaxe de démarcation de base créée par Gruber, Swartz et co, je pense, a été inspirée de la façon dont les gens écrivaient des e-mails (en texte brut) à l'époque. Donc, cela n'a commencé qu'aussi complexe (ou aussi "capable") que le message électronique moyen pouvait l'être, pas un document de recherche ou une autre forme d'écriture qui utilise beaucoup de notes secondaires ou qui suit ou a un sens avec le style de Tufte.

Donc, au fil des ans, il n'y a pas eu beaucoup d'autres types de syntaxe que vous pouvez entasser dans "markdown" parce que tout l'intérêt est qu'il est censé être lisible sous forme de texte brut. Comment transmettez-vous visuellement des notes secondaires en texte brut ? Néanmoins, je pense que la démarque étendue de pandoc a fait un très bon travail à cet égard.

Donc, je pense que restructuredtext a quelque chose qui s'appelle des directives ou quelque chose, qui vous permet de construire une syntaxe (ou quelque chose ?) pour un type particulier de données ? Si c'est un peu le cas, oui, je pense que le texte restructuré est probablement plus acceptable ici. Mais comme je l'ai dit, je n'ai pas beaucoup d'expérience avec cela, donc je ne peux pas vous aider davantage.

restructuredText serait inutile pour mes besoins, qui sont des projets déjà documentés en démarques

Le 17 août 2015, à 04h24, vyp [email protected] a écrit :

@coppeliaMLA Merci d'avoir mentionné glasseye, c'est un travail incroyable.

@rbcarson Je ne suis pas OP, mais si la question s'adresse à tout le monde ici et que vous voulez mon avis, je ne connais personnellement pas très bien le texte restructuré, donc je ne peux pas vraiment le dire. Mais vous avez peut-être raison, la syntaxe de démarcation de base créée par Gruber, Swartz et co, je pense, a été inspirée de la façon dont les gens écrivaient des e-mails (en texte brut) à l'époque. Donc, cela n'a commencé qu'aussi complexe (ou aussi "capable") que le message électronique moyen pouvait l'être, pas un document de recherche ou une autre forme d'écriture qui utilise beaucoup de notes secondaires ou qui suit ou a un sens avec le style de Tufte.

Donc, au fil des ans, il n'y a pas eu beaucoup d'autres types de syntaxe que vous pouvez entasser dans "markdown" parce que tout l'intérêt est qu'il est censé être lisible sous forme de texte brut. Comment transmettez-vous visuellement des notes secondaires en texte brut ? Néanmoins, je pense que la démarque étendue de pandoc a fait un très bon travail à cet égard.

Donc, je pense que restructuredtext a quelque chose qui s'appelle des directives ou quelque chose, qui vous permet de construire une syntaxe (ou quelque chose ?) pour un type particulier de données ? Si c'est un peu le cas, oui, je pense que le texte restructuré est probablement plus acceptable ici. Mais comme je l'ai dit, je n'ai pas beaucoup d'expérience avec cela, donc je ne peux pas vous aider davantage.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

@coppeliaMLA très intéressant ! : utilisez pandoc pour générer du HTML avec des balises spéciales, puis, dans un deuxième temps, utilisez un autre programme pour étendre les balises spéciales en Javascript et HTML. Mon approche a consisté à créer un rédacteur personnalisé Pandoc qui utilise les balises spéciales, en faisant efficacement glasseye.py en Lua, en utilisant Pandoc AST au lieu de l'analyse BeautifulSoup, mais il semble que glasseye fonctionne très bien. Je vais essayer de lisser mes documents et vous informer sur son repo de tout problème. Les choses qui sont difficiles à faire dans un écrivain Pandoc peuvent être plus faciles à faire en post-traitement, et vice versa, mais la seule façon de le savoir est d'écrire un tas de documents :)

@fasiha merci. Votre méthode semble plus efficace et je pense que je pourrais peut-être prendre cette direction à la fin. J'ai opté pour python car cela m'a permis de créer un prototype rapide. Mais comme vous le dites, expérimenter sur de nombreux documents affinera la meilleure méthode. Je prévois de l'utiliser autant que possible dans mon travail quotidien pour voir où cela me mène. Ce serait génial si vous pouviez essayer. J'adore entendre comment ça se passe!

Voir #31 et aussi #58

Pour ce que ça vaut : je viens de rassembler tufte-pandoc-css pour résoudre le problème de la rédaction de notes annexes dans Markdown. C'est juste une démonstration de l'utilisation d'un filtre Pandoc personnalisé que j'ai écrit appelé pandoc-sidenote .

Pour le voir en action :

• Une ré-implémentation tufte-css/index.html dans un Markdown à la saveur Pandoc
• Une démo de certaines autres fonctionnalités de Pandoc , comme les blocs de code mis en évidence par la syntaxe.

@jez cool ! Je vais voir si je peux trouver un projet avec lequel faire un tourbillon.

Je viens de trouver ce fil via Google

Vous voudrez peut-être jeter un œil à xmark : qui convertit la démarque en Tufte-CSS via XSLT.

@vieiro wow c'est sympa. Super travail