adjust asset building and path of generated images under source/

book/Makefile

@@ -25,7 +25,7 @@ clean-all: clean
 
 # convert all SVG to plain SVGs without metadata and paths instead of text
 convert-svg:
-	for file in $(SOURCEDIR)/diag/*.svg $(SOURCEDIR)/drawio/*.svg; do if [[ ! -f $(SOURCEDIR)/plain_svg/$$(basename $$file) ]]; then $(INKSCAPE) --export-text-to-path --export-plain-svg --export-filename=$(SOURCEDIR)/plain_svg/$$(basename $$file) $$file; fi; done
+	for file in $(SOURCEDIR)/../assets/inkscape/*.svg $(SOURCEDIR)/../assets/drawio/*.svg; do if [[ ! -f $(SOURCEDIR)/plain_svg/$$(basename $$file) ]]; then $(INKSCAPE) --export-text-to-path --export-plain-svg --export-filename=$(SOURCEDIR)/plain_svg/$$(basename $$file) $$file; fi; done
 
 epub: convert-svg
 	@$(SPHINXBUILD) -M epub "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

book/source/09-verification.md

@@ -135,7 +135,7 @@ However, the RFC [states](https://www.ietf.org/archive/id/draft-ietf-openpgp-cry
 In this case, the implementation uses the preferences from the subkey binding signature, but if no such subpacket is found on the latest binding signature, it falls back to the preferences from the direct key signature.
 This is called attribute shadowing, since direct key signature subpackets apply to all subkeys, but are shadowed by binding signature subpackets.
 
-```{figure} drawio/attribute-shadowing.png
+```{figure} img/drawio/attribute-shadowing.png
 :name: fig-signature-verification-attribute-shadowing
 :alt: Depicts a certificate with to dedicated signing subkeys and a subkey binding signature each. The primary key carries a direct-key signature, which specifies SHA-512 and SHA-256 as hash algorithm preferences. The binding signature of the first signing subkey does not specify preferences, while the binding signature of the second subkey defines SHA-384. Signatures made using the first subkey source the hash algorithm preferences from the direct-key signature, due to the absence of a preference subpacket on the binding signature, while for signature made using the second subkey the direct-key signature's preferences are shadowed by the subkey signatures preferences subpacket.
 
@@ -163,7 +163,7 @@ In other words:
   - because `C` is not yet in effect, and
   - `A` is shadowed, because it is older than `B`.
 
-```{figure} drawio/cert-validity-subkey.png
+```{figure} img/drawio/cert-validity-subkey.png
 :name: fig-signature-verification-subkey-validity
 :alt: Depicts a gantt-style diagram visualizing how the validity of a certificates components changes over time, depending on component signatures.
 
@@ -177,7 +177,7 @@ Signature shadowing should not be confused with attribute shadowing.
 
 As attribute and signature shadowing can occur in combination, it is not always obvious which properties a key has at a given time.
 
-```{figure} drawio/dk-attributes-and-shadowing.png
+```{figure} img/drawio/dk-attributes-and-shadowing.png
 :name: fig-signature-verification-signature-shadowing
 :alt: Depicts a certificate with a subkey, whose capabilities change over time, due to signature shadowing another.
 
@@ -212,7 +212,7 @@ If the user wants to compose a signed message using the associated OpenPGP key t
 
 The specification recommends that implementations decide which signature takes precedence by the way the certificate is "addressed."
 
-```{figure} drawio/narrow-interpretation.png
+```{figure} img/drawio/narrow-interpretation.png
 
 Preferences are sourced from signatures on different components, depending on how the key is addressed.
 ```

book/source/img/README

@@ -0,0 +1 @@
+Generated image data, based on source material in book/assets/