Support theme-aware diagrams:

- SVG diagrams can adapt to the visual theme of the site through CSS.
- Use the include_svg filter to include a diagram that adapts to the
  theme.
- The styles/_diagrams.scss file controls the color mappings for
  theme-aware digrams.
- Theme-aware diagrams are limited to specific colors and diagram
  styles. Use UMLet or Google Draw and confirm that the diagram is still
  legible when you build it.
- This commit updates existing diagrams in most places to be
  theme-aware.

content/concepts/payment-system-basics/accounts/accounts.md

@@ -110,7 +110,7 @@ XRP Ledger addresses are encoded using [base58][] with the _dictionary_ `rpshnaf
 
 The following diagram shows the relationship between keys and addresses:
 
-[![Master Public Key + Type Prefix → Account ID + Checksum → Address](img/address-encoding.png)](img/address-encoding.png)
+{{ include_svg("img/address-encoding.svg", "Master Public Key + Type Prefix → Account ID + Checksum → Address") }}
 
 The formula for calculating an XRP Ledger address from a public key is as follows. For the complete example code, see [`encode_address.js`](https://github.com/ripple/ripple-dev-portal/blob/master/content/_code-samples/address_encoding/encode_address.js). For the process of deriving a public key from a passphrase or seed value, see [Key Derivation](cryptographic-keys.html#key-derivation).
 

content/concepts/payment-system-basics/accounts/cryptographic-keys.md

@@ -156,7 +156,7 @@ The key derivation processes described here are implemented in multiple places a
 ### Ed25519 Key Derivation
 [[Source]](https://github.com/ripple/rippled/blob/fc7ecd672a3b9748bfea52ce65996e324553c05f/src/ripple/protocol/impl/SecretKey.cpp#L203 "Source")
 
-[![Passphrase → Seed → Secret Key → Prefix + Public Key](img/key-derivation-ed25519.png)](img/key-derivation-ed25519.png)
+{{ include_svg("img/key-derivation-ed25519.svg", "Passphrase → Seed → Secret Key → Prefix + Public Key") }}
 
 1. Calculate the [SHA-512Half][] of the seed value. The result is the 32-byte secret key.
 
@@ -177,7 +177,7 @@ The key derivation processes described here are implemented in multiple places a
 ### secp256k1 Key Derivation
 [[Source]](https://github.com/ripple/rippled/blob/develop/src/ripple/crypto/impl/GenerateDeterministicKey.cpp "Source")
 
-[![Passphrase → Seed → Root Key Pair → Intermediate Key Pair → Master Key Pair](img/key-derivation-secp256k1.png)](img/key-derivation-secp256k1.png)
+{{ include_svg("img/key-derivation-secp256k1.svg", "Passphrase → Seed → Root Key Pair → Intermediate Key Pair → Master Key Pair") }}
 
 Key derivation for secp256k1 XRP Ledger account keys involves more steps than Ed25519 key derivation for a couple reasons:
 

content/concepts/payment-system-basics/ledgers.md

@@ -2,13 +2,13 @@
 
 The XRP Ledger is a shared, global ledger that is open to all. Individual participants can trust the integrity of the ledger without having to trust any single institution to manage it. The `rippled` server software accomplishes this by managing a ledger database that can only be updated according to very specific rules. Each instance of `rippled` keeps a full copy of the ledger, and the peer-to-peer network of `rippled` servers distributes candidate transactions among themselves. The consensus process determines which transactions get applied to each new version of the ledger. See also: [The Consensus Process](consensus.html).
 
-![Diagram: Each ledger is the result of applying transactions to the previous ledger version.](img/ledger-changes.png)
+{{ include_svg("img/ledger-changes.svg", "Diagram: Each ledger is the result of applying transactions to the previous ledger version.") }}
 
 The shared global ledger is actually a series of individual ledgers, or ledger versions, which `rippled` keeps in its internal database. Every ledger version has a [Ledger Index][] which identifies the order in which ledgers occur. Each closed ledger version also has an identifying hash value, which uniquely identifies the contents of that ledger. At any given time, a `rippled` instance has an in-progress "current" open ledger, plus some number of closed ledgers that have not yet been approved by consensus, and any number of historical ledgers that have been validated by consensus. Only the validated ledgers are certain to be correct and immutable.
 
 A single ledger version consists of several parts:
 
-![Diagram: A ledger has transactions, a state tree, and a header with the close time and validation info](img/anatomy-of-a-ledger-simplified.png)
+{{ include_svg("img/anatomy-of-a-ledger-simplified.svg", "Diagram: A ledger has transactions, a state tree, and a header with the close time and validation info") }}
 
 * A **header** - The [Ledger Index][], hashes of its other contents, and other metadata.
 * A **transaction tree** - The [transactions](transaction-formats.html) that were applied to the previous ledger to make this one. Transactions are the _only_ way to change the ledger.