From aa54c194ff5e3fa2f42909f4eb5c27d1b1366dc4 Mon Sep 17 00:00:00 2001
From: jaseg <git@jaseg.de>
Date: Sun, 19 Mar 2023 23:41:06 +0100
Subject: Make images on dark mode darker

---
 content/blog/kicad-mesh-plugin/index.rst       | 42 ++++++++++++++------------
 content/blog/multichannel-led-driver/index.rst | 18 ++++++-----
 content/blog/wifi-led-driver/index.rst         |  9 +++---
 content/projects/svg-flatten/index.rst         |  7 +++++
 4 files changed, 45 insertions(+), 31 deletions(-)

(limited to 'content')

diff --git a/content/blog/kicad-mesh-plugin/index.rst b/content/blog/kicad-mesh-plugin/index.rst
index 226f23f..df15933 100644
--- a/content/blog/kicad-mesh-plugin/index.rst
+++ b/content/blog/kicad-mesh-plugin/index.rst
@@ -125,25 +125,29 @@ means that on every step, the algorithm is choosing a new direction at random.
 
 .. raw:: html
 
-    <figure>
-    <figure class="side-by-side">
-        <img src="images/cells-0.svg" alt="a completely organized looking grid with spiral patterns all over.">
-        <figcaption>0%</figcaption>
-    </figure><figure class="side-by-side">
-        <img src="images/cells-25.svg">
-        <figcaption>25%</figcaption>
-    </figure><figure class="side-by-side">
-        <img src="images/cells-50.svg">
-        <figcaption>50%</figcaption>
-    </figure><figure class="side-by-side">
-        <img src="images/cells-75.svg">
-        <figcaption>75%</figcaption>
-    </figure><figure class="side-by-side">
-        <img src="images/cells-100.svg" alt="a completely random looking grid with cells aggregating into ireggular
-        areas that look like paint splotches.">
-        <figcaption>100%</figcaption>
-    </figure>
-    </figure>
+    <div class="subfigure">
+        <figure>
+            <img src="images/cells-0.svg" alt="a completely organized looking grid with spiral patterns all over.">
+            <figcaption>0%</figcaption>
+        </figure>
+        <figure>
+            <img src="images/cells-25.svg">
+            <figcaption>25%</figcaption>
+        </figure>
+        <figure>
+            <img src="images/cells-50.svg">
+            <figcaption>50%</figcaption>
+        </figure>
+        <figure>
+            <img src="images/cells-75.svg">
+            <figcaption>75%</figcaption>
+        </figure>
+        <figure>
+            <img src="images/cells-100.svg" alt="a completely random looking grid with cells aggregating into ireggular
+            areas that look like paint splotches.">
+            <figcaption>100%</figcaption>
+        </figure>
+    </div>
 
 After I have built this tree like you would do in a depth-first search, I draw my one or several mesh mesh traces into
 it. The core observation here is that there is only 16 possible ways a cell can be connected: It has four neighbors,
diff --git a/content/blog/multichannel-led-driver/index.rst b/content/blog/multichannel-led-driver/index.rst
index 7de03d5..86fab72 100644
--- a/content/blog/multichannel-led-driver/index.rst
+++ b/content/blog/multichannel-led-driver/index.rst
@@ -376,15 +376,16 @@ the resulting brightness curve below.
 
 .. raw:: html
     
-    <figure>
-        <figure class="side-by-side">
+    <div class="subfigure">
+        <figure>
             <img src="images/uncorrected_brightness_sim.svg" alt="">
             <figcaption>
                 Calculated brightness curve for the uncorrected BCM setup. As you can see, at low setpoints the result
                 is about as smooth as sandpaper, which is well in line with our observations. At high setpoints the
                 offset gets swamped out and the nonlinearity in the low bits is not visible anymore.
             </figcaption>
-        </figure><figure class="side-by-side">
+        </figure>
+       <figure>
             <img src="images/corrected_brightness_sim.svg" alt="">
             <figcaption>
                 Brightness curve for the corrected BCM setup extrapolated using actual measurements. Looks as buttery
@@ -392,7 +393,7 @@ the resulting brightness curve below.
             </figcaption>
             </figcaption>
         </figure>
-    </figure>
+    </div>
 
 .. _BPW34: http://www.vishay.com/docs/81521/bpw34.pdf
 .. _MCP6002: http://ww1.microchip.com/downloads/en/DeviceDoc/21733j.pdf
@@ -431,19 +432,20 @@ Conclusion
 
 .. raw:: html
 
-    <figure>
-        <figure class="side-by-side">
+    <div class="subfigure">
+        <figure>
             <a href="images/olsndot_schematic.png">
                 <img src="images/olsndot_schematic.png" alt="A picture of the LED driver schematic">
             </a>
             <figcaption>The LED driver <a href="images/olsndot_schematic.png">schematic</a></figcaption>
-        </figure><figure class="side-by-side">
+        </figure>
+        <figure>
             <a href="images/olsndot_pcb.png">
                 <img src="images/olsndot_pcb.png" alt="A picture of the LED driver PCB layout">
             </a>
             <figcaption>The LED driver <a href="images/olsndot_pcb.png">PCB layout</a></figcaption>
         </figure>
-    </figure>
+    </div>
 
 Putting some thought into the control circuitry and software, you can easily control large numbers of channels of LEDs
 using extremely inexpensive driving hardware without any compromises on dynamic range. The design we settled on can
diff --git a/content/blog/wifi-led-driver/index.rst b/content/blog/wifi-led-driver/index.rst
index f1e53a9..1c4024a 100644
--- a/content/blog/wifi-led-driver/index.rst
+++ b/content/blog/wifi-led-driver/index.rst
@@ -47,15 +47,16 @@ currents their `trip times get long enough that they become unlikely to trip in
 
 .. raw:: html
 
-    <figure>
-        <figure class="side-by-side">
+    <div class="subfigure">
+        <figure>
             <img src="images/schematic.png">
             <figcaption>
             The schematic of the driver board, with the ESP8266 on the top left, the STM32 microcontroller for LED
             modulation below, the shift register in the middle and the LED drivers and outputs on the right. 
             <a href="resource/schematic_and_pcb.pdf">Download PDF</a>
             </figcaption>
-        </figure><figure class="side-by-side">
+        </figure>
+        <figure>
             <img src="images/layout.png">
             <figcaption>
             The board layout with the top side being visible. The top side contains the footprint for the ESP8266, the
@@ -66,7 +67,7 @@ currents their `trip times get long enough that they become unlikely to trip in
             <a href="resource/schematic_and_pcb.pdf">Download PDF</a>
             </figcaption>
         </figure>
-    </figure>
+    </div>
 
 .. raw:: html
     
diff --git a/content/projects/svg-flatten/index.rst b/content/projects/svg-flatten/index.rst
index 1554bcf..ae9a8f3 100644
--- a/content/projects/svg-flatten/index.rst
+++ b/content/projects/svg-flatten/index.rst
@@ -13,3 +13,10 @@ summary: >
     part of gerbolyze.
 ---
 
+svg-flatten is a command-line utility that performs vector occlusion and clipping on SVG files, producing a flattened
+SVG file without overlapping elements, without changing what the file looks like. svg-flatten is used as a part of
+gerbolyze.
+
+I developed svg-flatten as part of gerbolyze_, but it can be used independently.
+
+.. _gerbolyze: {{< ref "projects/gerbolyze" >}}
-- 
cgit