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.
How is difficulty applied?
''''''''''''''''''''''''''
The numeric value of difficulty is taken from an array of possible
hashes out of all possible hashes. In DUBPv13 the hash of a block is its
sha256 hexadecimal hash.
To understand the difficulty, we make a euclidiean division of the
difficulty by 16.
Here’s an example with a difficulty value of 70:
.. math::
:label: eucl_division
70 / 16 = 4 with a remainder of 6.
The valid hashes are the ones starting with four zeros and with the
fifth character less than or equal to 9 (6 in hexadecimal notation). The
valid hashes are then written as starting with: ``0000[0-9]``. This is
a bit different from Bitcoin, where the difficulty is only ruled by the
number of zeroes.
Si je comprends ce qui est dit, pour une difficulté de 70, le hash attendu devrait être 0000[0-6], et l’exemple est faux.
Si j’observe comment la difficulté est mise en place, le dernier caractère correspond non pas au reste exprimé en hexadécimal, mais à (15 - reste) exprimé en hexadécimal.
ex. sur la GT :
diff = 75
75/16 = 4 et reste 11
15-11 = 4
hash attendu : 0000[0-4]
| jyt-test | 0000[0-4]* | 7.2 × 10^5 | 75 |
edit - c’est la règle BRG_62 qui correspond à ma compréhension.
@matograine non je parle du texte que tu à cité en premier dans ton précédent message. Le texte sur le site officiel de Duniter est bien correct et conforme à la règle BRG_62
@matograine je parle de ce texte là, celui à partir duquel tu posais ta question. Je ne l’ai jamais vu avant, je ne sais pas qui l’a écrit ni où tu l’as trouvé. En tout cas ce texte comporte deux erreurs :
1 - 9 se représente bien 9 en notation hexa, je ne sais pas pourquoi l’auteur de ce texte a ajouté cette précision fausse entre parenthèses
2 - La difficulté dans le bitcoin ne dépend pas uniquement du nombre de zéros, de plus le texte ne précise pas si l’on parle de zéros binaires ou hexa, c’est très différent car dans le 2ème cas la granulométrie est 16 fois plus fine… Quant au bitcoin il ne se base pas vraiment sur un nombre de zéros (ça c’est ce que tout le monde dit en vulga pour simplifier), la réalité est bien plus compliquée : Difficulty - Bitcoin Wiki
Bon. Cette fois, je crois qu’on est presque « ça-y-est ».
J’ai râlé, pesté, attendu parce que :
je n’arrivais pas à mettre les sources à la fin du document PDF.
je n’arrivais pas à faire en sorte que la table des matières ne soit pas dépliée (html)
J’ai laché prise . Donc ceusses qui voudront ces améliorations bienvenue sont librement invité.e.s à les réaliser.
Améliorations :
le script de génération est prêt pour de futures traductions
le PDF n’a plus de chapitre « sources » vide à la fin
le script génère un fichier .epub
Voici donc le descriptif technique, en .html et .pdf.
Pour moi j’ai fini. J’ai mis @elois, @cgeek et @inso comme co-rédacteurs, vu que j’ai compilé leurs oeuvres. Je vous laisse faire des remarques s’il y en a. Je ne sais pas bien s’il faut publier une version 1.0, je vais attendre d’avoir eu des derniers retours pour le faire.
Je pense que @HugoTrentesaux en particulier sera intéressé pour le futur site web de Duniter. Je pense que l’annonce d’un WP devrait être faite en même temps que le futur site.