Ajouter un appel de référence dans la métadonnée de résumé introduit un léger bug sur la preview #1141

lakonis · 2024-12-09T21:08:07Z

Comme le titre l'indique, un appel de référence, par exemple [@auteur] au sein d'un résumé (métadonnée abstract > text_f), génère une preview problématique avec des bouts de résumé répétés en boucle et placé au-dessus de l'encart affichant les métadonnées.

The text was updated successfully, but these errors were encountered:

ggrossetie · 2024-12-10T07:51:12Z

Effectivement, j'arrive à reproduire :

@RochDLY Est-ce que [@auteur] est une syntaxe particulière qui est interprété par le moteur de templating ? Quel est le comportement attendu ?

RochDLY · 2024-12-10T08:34:07Z

Je viens de reproduire également. Pour moi le problème est qu'en intégrant des clés bibliographiques dans les métadonnées, le moteur remet les balises <meta> dans le <body> de la preview (juste avant le <header>).

Les hyperliens apparraissent dans des  ce qui, j'imagine, les fait apparaître à l'écran.

La question du comportement n'est pas évidente à traiter :

À mon sens, on ne met pas de référence bibliographique dans un résumé, ni dans des remerciements, ni ailleurs dans les métadonnées (je n'ai jamais vu ce cas. Au contraire, c'est une chose qu'on supprime si jamais il y en a). Le résumé est l'élément de l'article qui sera affiché un peu partout sur le web si l'article est publié : si jamais il y a une référence dedans, par exemple (Toto, 1994), comment un lecteur sait à quel document Toto fait référence sans accéder à l'article complet (et il faut encore que l'article soit en accès libre). Exemple : les métadonnées de l'article sont accessibles sur ORCID et sur HAL, mais pas l'article associé. À ce moment-là (Toto, 1994) ne réfère à rien du tout.
La syntaxe [@clef_reference_bib] est une syntaxe Markdown, pas une syntaxe YAML. Pandoc est "permissif" et traite la syntaxe du Markdown à l'intérieur des valeurs affectées aux clefs YAML.
Dans les métadonnées HTML (voir ci-dessous), on supprime la syntaxe Markdown, tandis que dans le résumé affiché dans le <body>, elle y est présente :

$if(abstract)$
$for(abstract)$
  <meta name="description" xml:lang="$abstract.lang$" lang="$abstract.lang$" content="$abstract.text$" />
  <meta name="DC.description" xml:lang="$abstract.lang$" lang="$abstract.lang$" content="$abstract.text$" />
$endfor$
$endif$

$if(abstract)$
  <div class="description">
$for(abstract)$
    <div property="description" class="resume" lang="$abstract.lang$">$abstract.text_f$</div>
$endfor$
  </div>
$endif$

Aussi, lorsqu'on prête attention au <head> de la preview, on se rend compte que le strip sur la syntaxe markdown ne fonctionne pas bien puisqu'il y a un  qui apparaît dans le contenu de la métadonnée.

Au regarde de ces points, et sous réserve que ça vous convienne : 

On supprime la référence dans les métadonnées (on s'en fiche à cet endroit et le span ne doit pas être présent dans un <head>)
Le résumé dans la preview est juste composé d'un <div> (cf image ci-dessous). Est-ce qu'on s'autorise à mettre un  à l'intérieur ? (est-ce que c'est citeproc qui crée le  ?) dans tous les cas, on devrait virer l'hyperlien qui renvoie vers la référence en bibliographie

thom4parisot · 2024-12-10T09:30:05Z

À mon sens, on ne met pas de référence bibliographique dans un résumé, ni dans des remerciements, ni ailleurs dans les métadonnées

Ben c'est ce qu'a l'air de vouloir faire @lakonis, non ? Est-ce que c'est un cas intéressant à prendre en compte ? (ou on se limite parce qu'on n'en connait que peu l'usage avec Pandoc ?)

RochDLY · 2024-12-10T09:44:15Z

Je prends un exemple, si on va chercher un article de Nicolas Sauret sur son profil ORCID, ou mieux encore, un article sur isidore.science.

Dans les deux cas les articles sont accessibles en ligne. Dans les deux cas j'ai un abstract affiché : si il y avait une ref dedans avec (Toto, 1994) je serais obligé d'aller dans l'article complet tout en bas de la page pour savoir de quelle référence il s'agit (ce qui fait un peu long en termes de navigation pour une ref).

C'est pas une question de technique. La question que je soulève c'est plutôt : au-delà de la preview de Stylo, quel est l'usage d'une référence dans les métadonnées ?

lakonis · 2024-12-10T09:57:55Z

À mon sens, on ne met pas de référence bibliographique dans un résumé, ni dans des remerciements, ni ailleurs dans les métadonnées

Ben c'est ce qu'a l'air de vouloir faire @lakonis, non ? Est-ce que c'est un cas intéressant à prendre en compte ? (ou on se limite parce qu'on n'en connait que peu l'usage avec Pandoc ?)

À vrai dire, c'est vraiment un oubli de ma part. Dans un résumé, par défaut je n'aurais pas intégré de référence. C'est le résultat d'un copier-coller trop rapide.

thom4parisot · 2024-12-10T09:58:43Z

Dac. Par contre ça veut dire que Pandoc interprète quand même la référence bibliographique, que ça fiche le bazar, et que ça, on s'en passerait ?

lakonis · 2024-12-10T10:43:27Z

non le problème vient plus probablement de notre spécificité d'avoir voulu traiter le cas de métadonnées "formatées" (text_f) vs non-formatées (text). Les premières sont utilisées dans le body, tandis que les secondes sont générées (nettoyées) à partir du text_f pour être utilisées dans le head comme éléments meta.

@RochDLY est en train de vérifier ce que pandoc fait aujourd'hui, car notre distinction formaté/non-formaté venait d'un besoin non traité par pandoc en 2017 : avoir de l'italique ou un exposant dans un titre d'article, ou dans un résumé.

Il est possible que pandoc est intégré cela depuis : capacité à gérer les balises markdown déclarées dans le yaml. À vérifier !

RochDLY · 2024-12-10T11:18:17Z

Rappel de ce qu'on fait dans Stylo :

On utilise les métadonnées d'un article pour alimenter deux endroits à la fois : le <head> et le <body> du html.

Dans le head, les balises <meta> ne prennent généralement que des attributs et du texte (dans l'attribut content ou alors comme valeur du type title.text).

Si on met une emphase dans un titre (title: "_Stylo_") va créer <title>Stylo</title> dans le <head> du HTML, sachant que les balises  seront considérées comme du texte brut (et le titre ressemblera à " Stylo ").

Dans le <body> , ces éléments structurels seront interprétées, et on aura bien un titre de niveau 1 avec Stylo en italique.

Le système mis en place avec ou sans _f permet de contourner ce comportement et de supprimer les éléments structurels du Markdown pour les informations qui vont dans le <head> (pour que par exemple <title>Stylo</title> apparaisse sans les ).

Comportement de Pandoc : 

Dans Pandoc, le comportement est d'interpréter les valeurs affectées dans le YAML comme du Markdown, d'ailleurs depuis un fix de 2022, si une variante de markdown est passée en commande en entrée, pandoc interprétera les métadonnées selon cette variante (voir la note de release). Sinon, par défaut, il interprète selon la saveur par défaut.
D'ailleurs, il me semble que c'est grâce à ces modifications que l'on peut, par exemple, ajouter de la syntaxe LaTeX pour ajouter des paquets LaTeX dans le préambule d'un output .tex

Pour autant, je n'ai pas l'impression que Pandoc ait changé quoi que ce soit par rapport à notre problème de distribution des métadonnées dans le HTML

antoinentl · 2024-12-10T11:24:39Z

Le fonctionnement idéal serait de pouvoir traiter un seul champ, exemple avec une syntaxe qui n'existe pas :

title: Mon _titre_
appel dans les métadonnées avec une fonction du type plainify : `plainify($title$)
appel dans le body avec une fonction du type markdownify : markdownify($title$)

RochDLY · 2024-12-10T11:31:59Z

Le fonctionnement idéal serait de pouvoir traiter un seul champ, exemple avec une syntaxe qui n'existe pas :

title: Mon _titre_

appel dans les métadonnées avec une fonction du type plainify : `plainify(title)

appel dans le body avec une fonction du type markdownify : markdownify($title$)

C'est plus ou moins ce qu'on fait déjà (ta fonction markdownify() est déjà prise en charge par Pandoc, comportement par défaut) et on fait l'équivalent de la fonction plainify() à partir de l'entrée YAML (qu'on duplique en lui retirant les balises markdown).

Le problème c'est que ça ne prend pas en compte les références bibliographiques, et à voir le cas soulevé par @lakonis, ça génère des problèmes dans la preview (et certainement dans le HTML généré par l'export, à tester).

marviro · 2024-12-10T14:29:44Z

non le problème vient plus probablement de notre spécificité d'avoir voulu traiter le cas de métadonnées "formatées" (text_f) vs non-formatées (text). Les premières sont utilisées dans le body, tandis que les secondes sont générées (nettoyées) à partir du text_f pour être utilisées dans le head comme éléments meta.

@RochDLY est en train de vérifier ce que pandoc fait aujourd'hui, car notre distinction formaté/non-formaté venait d'un besoin non traité par pandoc en 2017 : avoir de l'italique ou un exposant dans un titre d'article, ou dans un résumé.

Il est possible que pandoc est intégré cela depuis : capacité à gérer les balises markdown déclarées dans le yaml. À vérifier !

Pandoc depuis toujours traite les balises md dans le yaml. Le problème est un autre: nous mettons certaines métadonnées dans le head de l'html et dans ce contexte on ne peut pas baliser. Par ex: <meta type="keyword">... On peut pas faire ça. D'où nécessité d'avoir le texte non formaté. Car Pandoc le traite, justement.

lakonis · 2024-12-10T15:20:15Z

Car Pandoc le traite, justement.

Oui question de point de vue :) Pandoc traite le markdown de certains éléments yaml, mais Pandoc ne le traite pas comme nous souhaitons le faire, c'est-à-dire avoir ces éléments éditoriaux formatés ET non-formatés pour les meta.

Après, le bug soulevé ici relève plus spécifiquement de l'introduction d'une référence biblio dans les métadonnées, au-delà du formatage markdown. Et le comportement est sacrément bizarre, voir l'analyse de @RochDLY (voir aussi ci-dessus) :

Pour moi le problème est qu'en intégrant des clés bibliographiques dans les métadonnées, le moteur remet les balises dans le de la preview (juste avant le
).

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ajouter un appel de référence dans la métadonnée de résumé introduit un léger bug sur la preview #1141

Ajouter un appel de référence dans la métadonnée de résumé introduit un léger bug sur la preview #1141

lakonis commented Dec 9, 2024

ggrossetie commented Dec 10, 2024

RochDLY commented Dec 10, 2024 •

edited

Loading

thom4parisot commented Dec 10, 2024 •

edited

Loading

RochDLY commented Dec 10, 2024 •

edited

Loading

lakonis commented Dec 10, 2024

thom4parisot commented Dec 10, 2024 •

edited

Loading

lakonis commented Dec 10, 2024

RochDLY commented Dec 10, 2024

antoinentl commented Dec 10, 2024

RochDLY commented Dec 10, 2024 •

edited

Loading

marviro commented Dec 10, 2024

lakonis commented Dec 10, 2024

Ajouter un appel de référence dans la métadonnée de résumé introduit un léger bug sur la preview #1141

Ajouter un appel de référence dans la métadonnée de résumé introduit un léger bug sur la preview #1141

Comments

lakonis commented Dec 9, 2024

ggrossetie commented Dec 10, 2024

RochDLY commented Dec 10, 2024 • edited Loading

thom4parisot commented Dec 10, 2024 • edited Loading

RochDLY commented Dec 10, 2024 • edited Loading

lakonis commented Dec 10, 2024

thom4parisot commented Dec 10, 2024 • edited Loading

lakonis commented Dec 10, 2024

RochDLY commented Dec 10, 2024

antoinentl commented Dec 10, 2024

RochDLY commented Dec 10, 2024 • edited Loading

marviro commented Dec 10, 2024

lakonis commented Dec 10, 2024

RochDLY commented Dec 10, 2024 •

edited

Loading

thom4parisot commented Dec 10, 2024 •

edited

Loading

RochDLY commented Dec 10, 2024 •

edited

Loading

thom4parisot commented Dec 10, 2024 •

edited

Loading

RochDLY commented Dec 10, 2024 •

edited

Loading