* Add images to src/img

* (script publication.sh) create build/src/imd directory
* modify markdown images links

chapters/en/4_Web_Of_Trust.md.txt

@@ -142,7 +142,7 @@ alternatives being tested around the world for a decentralised communication net
 -   **In-degree of vertex A**: number of incoming edges / head ends
     to A.
 
-![degrees of a vertex diagram](./images/degres.jpg)
+![degrees of a vertex diagram](src/img/degrees_en.jpg)
 
 -   **Path**: -aka "walk"- path to follow to get from vertex A to
     vertex B.
@@ -347,7 +347,7 @@ well as that of the monetary community as a whole. The `xpercent`
 parameter prevents the creation of a 'faction' that could take hold of
 the blockchain.
 
-![Sybil region](./images/wot-sybil.jpg)
+![Sybil region](src/img/wot-sybil.jpg)
 
 The Sybil regions are isolated from the rest of the graph in the sense
 that they can only receive certifications from other ill-intentioned
@@ -386,7 +386,7 @@ Our goal with the Ğ1 is to create a community of about one million
 members to test the consequences of a libre monetary system. Let's see
 how we can tweak the pair of sigQty and stepMax- to reach this size:
 
-![Average WoT size graph as a function of sigQty and stepMax](./images/wot-moy.png)
+![Average WoT size graph as a function of sigQty and stepMax](src/img/wot-moy.png)
 
 The maximum size of a Sybil region grows linearly with `sigQty` but
 exponentially with `stepMax`. Logic has it that we need to keep
@@ -448,7 +448,7 @@ Here is a graph showing the evolution of a Sybil region with the
 variation of `sigPeriod`. The simulation considers that honest members 
 and attackers both issue a certification each `sigPeriod` interval, in days:
 
-![size of the WoT according to sigPeriod and stepAttackers](./images/impact_sig_period.png)
+![size of the WoT according to sigPeriod and stepAttackers](src/img/impact_sig_period.png)
 
 As we see, there is a strong link between the
 growth speed of the region and `sigPeriod`. As evidenced here, we need a

chapters/fr/4_Web_Of_Trust.md.txt

@@ -142,7 +142,7 @@ alternatives being tested around the world for a decentralised communication net
 -   **In-degree of vertex A**: number of incoming edges / head ends
     to A.
 
-![degrees of a vertex diagram](./images/degres.jpg)
+![degrees of a vertex diagram](src/img/degrees_fr.jpg)
 
 -   **Path**: -aka "walk"- path to follow to get from vertex A to
     vertex B.
@@ -347,7 +347,7 @@ well as that of the monetary community as a whole. The `xpercent`
 parameter prevents the creation of a 'faction' that could take hold of
 the blockchain.
 
-![Sybil region](./images/wot-sybil.jpg)
+![Sybil region](src/img/wot-sybil.jpg)
 
 The Sybil regions are isolated from the rest of the graph in the sense
 that they can only receive certifications from other ill-intentioned
@@ -386,7 +386,7 @@ Our goal with the Ğ1 is to create a community of about one million
 members to test the consequences of a libre monetary system. Let's see
 how we can tweak the pair of sigQty and stepMax- to reach this size:
 
-![Average WoT size graph as a function of sigQty and stepMax](./images/wot-moy.png)
+![Average WoT size graph as a function of sigQty and stepMax](src/img/wot-moy.png)
 
 The maximum size of a Sybil region grows linearly with `sigQty` but
 exponentially with `stepMax`. Logic has it that we need to keep
@@ -448,7 +448,7 @@ Here is a graph showing the evolution of a Sybil region with the
 variation of `sigPeriod`. The simulation considers that honest members
 and attackers both issue a certification each `sigPeriod` interval, in days:
 
-![size of the WoT according to sigPeriod and stepAttackers](./images/impact_sig_period.png)
+![size of the WoT according to sigPeriod and stepAttackers](src/img/impact_sig_period.png)
 
 As we see, there is a strong link between the
 growth speed of the region and `sigPeriod`. As evidenced here, we need a

publication.sh

@@ -7,14 +7,11 @@
 
 # dépendances : pandoc
 hash pandoc 2>/dev/null || { echo >&2 "Ce générateur a besoin de la commande pandoc pour fonctionner. Mais cette commande n'est pas installée. Fin de l'exécution."; exit 1; }
-mkdir -p build/src/js
 ## Clean des dossiers de build et copie des assets
 [ -f whitepaper.html ] && rm whitepaper.html
 rm -rf build temp_whitepaper_html_en temp_whitepaper_html_fr temp_whitepaper_en.md temp_whitepaper_fr.md
-mkdir -p build/js
-#cp src/js/* build/js/
-mkdir build/img
-cp src/img/* build/img/
+mkdir -p build/src/img/
+cp src/img/* build/src/img/
 cp src/*.css build/
 
 ## Compilation des différents chapitres