fix_subs Fixed the <sub> tags with admonition sub

.markdownlint.json

@@ -3,6 +3,7 @@
   "MD025": false,
   "MD013": false,
    "MD033": {
-    "allowed_elements": ["center", "sub", "i"]
+     "allowed_elements": ["center"]
    }
+
 }

content/post/emacs_clang_libopencm3.md

@@ -44,8 +44,10 @@ simply add the following to your `init.el`/`.emacs`[^1] file:
 (package-initialize)
 ```
 
-<sub>Emacs will need to be restarted or reloaded to load the package
+{{< sub >}}
-repository.</sub>
+Emacs will need to be restarted or reloaded to load the package
+repository.
+{{< /sub >}}
 
 ### Packages
 
@@ -54,7 +56,7 @@ Install the following packages in Emacs (`M-x package-install`):
 - `irony`
 - `company`
 - `company-irony`
-- `company-irony-c-headers` <sub>(_Required if you want header auto-completion_)</sub>
+- `company-irony-c-headers` _Required if you want header auto-completion_
 
 # Configuration
 
@@ -106,8 +108,10 @@ For an STM32F0 project, the context of the `.clang_complete` file would be:
 -DSTM32F0
 ```
 
-<sub>The above assumes that `libopencm3` is also places within the project
+{{< sub >}}
-directory</sub>
+The above assumes that `libopencm3` is also places within the project
+directory
+{{< /sub >}}
 
 {{< admonition warning Note >}}
 There is a strange issue that is encountered with non-working completion for new

content/post/gpg_best_practices_and_git.md

@@ -29,7 +29,9 @@ sub   rsa4096/A72FC2F1 2017-11-21 [E] [expires: 2020-02-23]
 sub   rsa4096/875953A2 2019-02-23 [S] [expires: 2020-02-23]
 ```
 
-<sub>Note: _I am using git version `2.20.1` in the above example._</sub>
+{{< sub >}}
+Note: I am using git version `2.20.1` in the above example.
+{{< /sub >}}
 
 # Getting Started with OpenPGP
 

content/post/hardened_linux.md

@@ -27,8 +27,10 @@ On Arch Linux, it's as simple as:
 # pacman -S linux-hardened linux-hardened-headers
 ```
 
-<sub><i>Optionally (additionally) run `mkinitcpio -p linux-hardened` as root if
+{{< sub >}}
-this wasn't already done automatically as part of the installation</i></sub>
+Optionally (additionally) run `mkinitcpio -p linux-hardened` as root if
+this wasn't already done automatically as part of the installation
+{{< /sub >}}
 
 The steps to boot to the hardened kernel will change based on your boot
 loader. Personally, I am using
@@ -83,8 +85,10 @@ LABEL archhardened
 ...
 ```
 
-<sub>Note that the `APPEND` may differ from the example, same with `options`
+{{< sub >}}
-for `systemd-boot`</sub>
+Note that the `APPEND` may differ from the example, same with `options`
+for `systemd-boot`
+{{< /sub >}}
 
 # Finish Line
 

content/post/stm32-part0.md

@@ -175,9 +175,11 @@ to be along with the internal pull-up or pull-down resistor mode:
 | `GPIO_PUPD_PULLUP`   | Internal pull-up resistor                               |
 | `GPIO_PUPD_PULLDOWN` | Internal pull-down resistor                             |
 
-<center><sub><i>Note: The documentation for these functions, provided by `libopencm3`
+{{< sub >}}
+Note: The documentation for these functions, provided by `libopencm3`
 authors, along with the function definition can be found
-[**here**](https://libopencm3.org/docs/latest/html/)</i></sub></center>
+[**here**](https://libopencm3.org/docs/latest/html/)
+{{< /sub >}}
 
 Having clarified that, as we want to **drive** the LEDs, we will need to
 configure the pins as outputs with no internal pull-up or pull-down resistor:
@@ -213,8 +215,10 @@ defined as well. This will encompass the output type, and output speed:
 | `GPIO_OSPEED_25MHZ`  | Up to 25MHz output speed (_equivalent to medium_) |
 | `GPIO_OSPEED_2MHZ`   | Up to 2MHz output speed (_equivalent to low_)     |
 
-<center><sub><i>Refer to the device datasheet for the frequency specifications
+{{< sub >}}
-and the power supply and load conditions for each speed</i></sub></center>
+Refer to the device datasheet for the frequency specifications
+and the power supply and load conditions for each speed
+{{< /sub >}}
 
 We'll be driving an output LED, as opposed to sinking it (_typical
 open-drain/open-collector sink configuration_), push-pull output mode will be
@@ -264,9 +268,11 @@ while(1) {
 }
 ```
 
-<center><sub><i>The details of why this is important can be found in the [While(1) in Embedded
+{{< sub >}}
-C -
+The details of why this is important can be found in the
-Explained](http://www.learningaboutelectronics.com/Articles/While-(1)-embedded-C.php) article</i></sub></center>
+[While(1) in Embedded C - Explained](http://www.learningaboutelectronics.com/Articles/While-(1)-embedded-C.php)
+article
+{{< /sub >}}
 
 **Voila!**
 

content/post/stm32-part1.md

@@ -277,8 +277,10 @@ for (i = 0; i < (sizeof(tim_oc_ids)/sizeof(tim_oc_ids[0])); ++i) {
 }
 ```
 
-<center><sub>_Determining the 'length' of an array in C is different than in
+{{< sub >}}
-other languages.[^2]_</sub></center>
+Determining the 'length' of an array in C is different than in
+other languages.[^2]
+{{< /sub >}}
 
 ## Enable the Timer
 

content/post/thinkpad_usb_fix.md

@@ -49,7 +49,9 @@ Using generic, non-branded digital calipers I was able to get the following
 | Pad Spacing (_along length_) |  _9.1mm_ |
 | Pad Spacing (_along width_)  | _15.4mm_ |
 | Pad Width                    |  _1.9mm_ |
-<center><sub>Fig. 1</sub></center>
+{{< sub >}}
+Fig. 1
+{{< /sub >}}
 
 # Shopping with Purpose
 
@@ -69,7 +71,9 @@ unbranded digital caliper. Those values are nearly spot-on.
 | Pad Spacing (_along length_) |  _9.1mm_ |   _9.1mm_ | **---**     |
 | Pad Spacing (_along width_)  | _15.4mm_ |  _15.7mm_ | _**-.3mm**_ |
 | Pad Width                    |  _1.9mm_ |  _2.30mm_ | _**-.4mm**_ |
-<center><sub>Fig. 2</sub></center>
+{{< sub >}}
+Fig. 2
+{{< /sub >}}
 
 The part was ordered, and arrived quickly at my doorstep. Stacked on top of each
 other the two receptacles matched up just as I had hoped.. **Fantastic!**