petit ajout au dépot de whitepaper, la publication en html avec du style, et la compilation du livre blanc en epub, mobi et fb2.
j’y propose aussi un dossier pour la version FR (qui ne contient pour le moment que les textes en english en markdown) de chacun des chapitres et une table des matières pour la version HTML.
lancer bash publication.sh pour rebuilder le tout vers un dossier « built ».
le script de publication râle si il manque pandoc ou ebook-convert de Calibre.
Markdown n’est pas un standard, n’a pas de spécification. Chacun fait son markdown.
Quelque soit le logiciel utilisé pour décliner différents format (pandoc, sphinx, Jrst, etc), je préconise d’utiliser le format RestructuredText pour le White Paper (on peut s’inspirer des sources de la TRM en ligne qui est en RestructuredText et regorge de formules mathématiques) .
@matograine, je peux t’aider là dessus, si tu décides de basculer en RestructuredText.
Concernant les formule, j’ai trouvé une solution, c’est d’utiliser le script JS MathJax. Je l’ai fait sur la branche formule. Il y a un copyright à respecter (licence Apache).
Ce souci se serait posé de la même façon avec du Rst, je pense.
@Vit J’ai regardé un peu la syntaxe Rst, et elle semble avoir plus d’options (échelle des figures, numérotation, etc…). Ça me paraît une bonne idée de passer sur ce format, je vais approfondir.
Whitepaper ou pas Whitepaper ?
Le terme « whitepaper » me semble de moins en moins approprié :
le doc que je prévois ne contient aucune preuve mathématique,
au vu des découvertes de @Lucas, le fonctionnement de la TdC va changer dans les prochaines versions de Duniter,
d’autres évolutions de protocole sont à prévoir, selon @elois. Le WP pourrait être amené à changer.
Avoir un document descriptif est tout de même essentiel pour faciliter l’accueil de nouveaux contributeurs. J’utiliserai donc le titre « descriptif technique », daterai le document, et indiquerai dès le début qu’il s’agit du d’un descriptif basé sur le protocole DUBP v13.
Comme je ne rentre pas trop loin dans les détails, la réécriture de certaines parties sera nécessaires pour des gros changements uniquement:
règles de la TdC
difficulté personnalisée (l’augmentation n’est pas linéaire)
OK, je suis passé sur Sphinx, et effectivement, les formules sont bien mieux gérées. J’ai numéroté les formules et les figures. Merci à @SALLY pour sa relecture, j’ai reformulé certains points.
Je suis allé aussi loin que j’ai pu, et le résultat est ici : html et pdf.
enlever le chemin qui n’a pas lieu d’être tout en haut de la page
élargir la colonne de table des matières
enlever la dépendance à gstatic (Sphinx utilise des polices g**gle )
en PDF, les sources sont placées en bas de page, or j’aimerais aussi les avoir dans la partie « sources » en fin de doc, comme dans le html. Saurais-tu faire cela ?
@tykayn, désolé, j’ai dû abandonner ton travail en cours de route.
Je pense que c’est fini sur le fonds, une relecture serait bienvenue
Le dossier build pourrit l’historique Git, ne faudrait-il pas l’ajouter dans .gitignore ? Il faudrait alors que publication.sh copie les fichiers publiables dans un autre dossier non ignoré.
Les images sont en JPEG, ça serait plus propre de les générer en LaTeX ou d’inclure des SVG, au pire des PNG.
Tu as choisi le thème « pyramid » dans la config, si celui-ci ne te convient vraiment pas, tu peux choisir un autre thème.
Le thème te convient, mais tu veux le modifier, deux solutions graduelles :
Tu peux modifier les options du thèmes dans la config. Pour « pyramid », seules deux options sont disponibles. Dont sidebarwidth qui te permet d’ajuster la largeur du menu je pense.
Pour les autres changements, tu peux surcharger le thème avec des templates personnalisés ayant le même nom que les templates d’origine et que tu places dans le dossier « _templates » défini dans ta configuration. Voir la partie templating de cette page :
Pour le pdf, c’est plus compliqué car cela se passe en général dans la config latex du fichier de configuration. Et là bon courage ! Internet est ton ami, mais tu peux déjà fouiller ici, y a un footer configurable :
pour le dossier de build j’hésitais à le mettre en ignore. mais il a l’avantage de pouvoir rendre lisible le résultat dans gitlab sans avoir à compiler le projet.
un build de la CI de gitlab pourrait faire ce job et publier une page d’ailleurs.
bon c’est chouette tout ça on va avoir des formules propres !
j’ai pas du tout lu le contenu des chapitres, du coup aucune idée si les infos sont bien à jour. (vivement une version fr, n’ayons pas peur de l’utiliser)
gare aussi aux infos de copyright en bas de document, je doute qu’un whitepaper soit publié avec une licence « tous droits réservés »
j’ai fait une première traduction en français avec Linguee, il faudra relire plein de choses avant que ça soit bon, mais ça traduit mille fois mieux que google.
@tykayn La plus grande partie du texte existe déjà en Français. Ce descriptif technique est, pour sa majeure partie, une compilation des articles cités en début de fil. Il y a quelques précisions et reformulation, l’intro et la partie 1 qui sont tout de mon crû mais le reste existe déjà en français.
edit pour ajouter les liens :
Le premier, theoretical n’est vraisemblablement plus dispo en francais. J’ai encore une version .md du texte
pour la traduction j’ai un contributeur à Fedora qui propose qu’on utilise le weblate de chez eux et de le relier au dépot du whitepaper pour que les fichiers md soient automatiquement mis a jour quand de nouvelles traductions sont approuvées, au lieu de devoir gérer notre propre weblate.
)
mais le reste existe déjà en français.