Génération des PDF, état des lieux

Merci bien

Tient, note au passage, parce que ça fait plusieurs fois que ça revient:

il y a le « % LES SIGNAUX SINUSOÏDAUX EN PHYSIQUE % Aabu % 18 mars 2018 » qui traîne ;

… Est ce que tu génères bien les pdf avec python manage.py generate_pdf (j’imagine que oui) ? Parce que quand je fais mes tests en local, j’ai pas la ligne. On dirait que le md n’a pas changé par rapport à ce qui se faisait avant, ou que ça a été corrigé dans dev et que c’est pas encore le cas sur le site. En tout cas, j’arrive pas à reproduire

Oui, je génère bien avec cette commande là.

et oui, c’est parce que le markdown n’a pas été régénéré.

Ok. Ben à mon avis, ça doit venir du fait que le .md est pas régénéré, du coup (edit: grillé). Faudra trouver une astuce.

Un point que je remonte pendant ma deuxième lecture du PDF C++. D’avance mes excuses s’il a été dit, mais le PDF contient également les parties qui sont marquées à ne pas valider et donc non visibles sur la version en ligne.

merci @informaticienzero. C’est juste pas normal ça.

Je pense que la template LaTeX ne m’aime pas: ni mon dernier billet, ni mon dernier tutoriel n’ont de PDFs

Après, dans les deux cas, il contient des GIFs animés, donc ça peut jouer. Ceci étant dit, il n’y a plus d’astuce pour télécharger le .tex ? (je croyais qu’il suffisait de visualiser le .md et de changer l’extension, mais il est possible que ce soit moi qui fabule ).

les gifs semblent en effet générer des soucis j’ai mis le .tex à disposition tu pourras regarder du coup.

Un petit état des lieux (qui sert aussi de boussole pour la suite). On est capable de fournir un PDF pour les tutos Arduino, C, Réseaux et C++, c’est déjà une réussite, mais il y a bien sûr toujours quelques ratés et autres à gérer.

Les tableaux

La taille de chaque colonne n’est pas bien calculé pour le moment. On veut la longueur d’une ligne divisée par le nombre de colonnes, mais il faut aussi prendre en compte l’espacement du séparateur de colonnes (\tabcolsep). Donc en gros, la dimension d’une colonne d’un tableau à x colonnes doit être \dimexpr(\linewidth) / x - 2\tabcolsep et pas seulement \dimexpr(\linewidth) / x. Ça peut se régler du côté de zmarkdown, mais aussi du côté du template en fournissant une commande \columnWidth{x} qui fait ce calcul.

Toujours est-il que passé un certain nombre de colonnes, le tableau va être trop grand pour la page. Une solution envisagée est de mettre ce tableau en paysage s’il dépasse un certain nombre de cases. Pour le faire « facilement », il serait possible de repousser ce tableau dans une annexe réservée aux trop gros tableaux.

Les notes de bas de page

Quelques problèmes au niveau des notes de bas de page dans une légende remontés par @pierre_24. J’ai l’impression qu’un \protect sur la commande devrait suffire (à tester), mais plus globalement, je me demande de plus en plus dans quel cas \footnote nous poserait problème. La commande semble fonctionner dans longtable, et c’est le cas où elle pose généralement problème. Bref, je sens de plus en plus qu’utiliser \footnote protégée serait plus simple. À voir ?

De plus, utiliser ce premier point devrait régler (je pense) un problème soulevé par TAlone, à savoir l’endroit où renvoient les liens vers les notes de bas de page (on veut qu’ils renvoient à la note et pas au haut de la page).

Sommaire

Au niveau de la table des matières, on prend en compte des choses qui ne devraient pas être affichées. Ça cause problème si on y utilise par exemple une abréviation, en particulier pour le sommaire intégré au PDF (celui que la majorité des lecteurs PDF affiche sur le côté).

Je reprends également deux suggestions de @TAlone dans ce sujet.

• Les numéros de page dans la table des matières ne sont pas cliquables, ce serait chouette qu’ils le soient. (Très facile à régler)
• il y a beaucoup de blanc, par exemple je m’attendrais à ce que les introductions de parties (généralement quelques lignes), soient collées au premier titre de la partie.

La seconde en particulier mérité une petite discussion histoire que tout le monde soit d’accord sur le formatage des introductions.

• Autre rajout vu dans le PDF de mon billet ici (dans l’introduction plus précisément), le code inline est illisible dans les titres des blocs (en tout cas des blocs informations).

Réflexions par rapport à ça:

1. … Comment détecter les gros tableau ? (sino, je suis pour une commande \columnWidth, même si je sais qu’il y a(vait?) une volonté de générer un maximum de LaTeX "pur" à un certain point).
2. Je crois que \footnotemark + \footnotetext vient surtout d’une volonté de coller au plus près au markdown, qui distingue explicitement les deux (et qui permet, donc, de gérer les multiples appels à une même note). Maintenant, on pourrait effectivement traduire la syntaxe [^ une note] par \footnote et les autres par le combo sus-mentionné.
3. En ce qui concerne les intro/conclu, y’avait une idée qui traînait je sais plus ou de les traiter explicitement via des environnements ou un truc du genre (ce qui permettrait de faire la différence entre intro de partie et de chapitre, par exemple). Mais effectivement, y’a une discussion à avoir.

1. En attendant de trouver mieux, ce serait au nombre de colonnes, avec un nombre de colonnes fixé à partir duquel on passe au tableau en mode horizontal.
2. Au moins, on a un truc fonctionnel pour le moment. Mais après réflexion, je ne pense pas qu’on puisse avoir quelque chose qui convient à toutes les utilisations. Permettre les appels multiples à une même note c’est très bien, mais si les appels sont trop lointains, on pourrait faire appel à une note qui se trouvera sur une autre page du PDF. Et le lien de retour de la note vers son appel est plus compliqué si elle est utilisée plusieurs fois. Avec une nouvelle note à chaque fois, on colle un peu moins au Markdown, mais on n’a pas ces deux inconvénients.
3. Effectivement. Les environnements du template pour l’introduction et la conclusion ne sont pas utilisés par zmarkdown, mais au moins ils existent et ils sont plutôt facilement adaptables. Donc faut juste savoir quel résultat on veut.

Pendant que je prenais ma douche, j’ai pensé à comment les dates sont indiquées sur les PDFs. Je pense qu’il faudrait avoir comme date principale la date de publication/dernière mise à jour du tutoriel, et garder la date de création du PDF avec un message du genre « PDF généré le <date> ».

En attendant on a débloqué le PDF du tuto Arduino.