enh: adhere to style guide and reorg landing (#598)

* enh: adhere to style guide and reorg landing

* links

* Apply suggestion from @lwasser

Author: lwasser

_static/fonts/NunitoSans-Italic-VariableFont.woff2

@@ -4,16 +4,17 @@
   --pyos-color-secondary: #8045e5;
   --pyos-color-secondary-highlight: #591bc2;
   --pyos-color-tertiary: #a66c98;
-  --pyos-color-dark: #542568;
+  --pyos-color-dark: #33205c; /* Brand dark purple - #33205c */
   --pyos-color-light: #daabcf;
 
   /* Darkmode Adjustments*/
   --pyos-dm-color-primary: #c483e0;
 
   /* Fonts (overrides base theme) */
   --pst-font-family-heading: "Poppins", sans-serif;
-  --pst-font-family-base: "Poppins", sans-serif;
-  --pyos-font-family-h1: "Itim", serif;
+  --pst-font-family-base: "NunitoSans", sans-serif;
+  --pyos-font-family-h1: "Poppins", sans-serif;
+  --pst-font-family-heading-weight: 400;
 }
 
 /* anything related to the dark theme */
@@ -32,6 +33,17 @@ body {
   font-size: 1rem;
 }
 
+/* nav bar poppins font */
+.bd-header,
+.bd-header .navbar-nav,
+.bd-header .navbar-nav .nav-link,
+.bd-header .navbar-header-items,
+.bd-header .navbar-item,
+.navbar-item .nav-item {
+  font-family: "Poppins", sans-serif !important;
+  font-weight: 400 !important;
+}
+
 /* Allow the center content to expand to wide on wide screens */
 @media (min-width: 960px) {
   .bd-page-width {
@@ -65,6 +77,10 @@ body p {
   margin-bottom: 70px !important;
 }
 
+.admonition-title {
+  font-family: "Poppins", sans-serif !important;
+}
+
 h1 {
   margin-top: 10px;
   margin-bottom: 40px;
@@ -73,6 +89,7 @@ h1 {
 }
 h2 {
   margin-top: 1em;
+  color: var(--pyos-h1-color);
 }
 
 h3 {
@@ -94,7 +111,9 @@ figcaption {
 }
 
 .admonition p {
-  font-size: 0.9em;
+  font-size: 0.95em;
+  font-family: Poppins, sans-serif;
+  font-weight: 200;
 }
 
 /* Navbar */
@@ -198,12 +217,14 @@ html[data-theme="light"] {
   --pst-color-success-text: #fff;
   --pst-color-success-highlight: #00381a;
   --sd-color-success: var(--pst-color-success);
+  --pst-color-link: #735fab;
+  --pst-color-link-hover: #591bc2;
   --sd-color-success-text: var(--pst-color-success-text);
   --sd-color-success-highlight: var(--pst-color-success-highlight);
   --sd-color-success-bg: #d6ece1;
   --sd-color-success-bg-text: #14181e;
-  --pst-color-info: #a66c98; /* general admonition */
-  --pst-color-info-bg: #eac8e2;
+  --pst-color-info: #33205c; /* general admonition */
+  --pst-color-info-bg: #bab3d4;
   --pst-heading-color: var(--pyos-color-dark);
   --pyos-h1-color: var(--pyos-color-dark);
 }
@@ -318,6 +339,25 @@ See https://github.com/pydata/pydata-sphinx-theme/pull/1784
   font-weight: 600;
   src: url("./fonts/poppins-v20-latin-600.woff2") format("woff2"); /* Chrome 36+, Opera 23+, Firefox 39+, Safari 12+, iOS 10+ */
 }
+
+/* nunitosans-regular - latin */
+@font-face {
+  font-display: swap;
+  font-family: "NunitoSans";
+  font-style: normal;
+  font-weight: 400;
+  src: url("./fonts/NunitoSans-VariableFont.woff2") format("woff2");
+}
+
+/* nunitosans-italic - latin */
+@font-face {
+  font-display: swap;
+  font-family: "NunitoSans";
+  font-style: italic;
+  font-weight: 400;
+  src: url("./fonts/NunitoSans-Italic-VariableFont.woff2") format("woff2");
+}
+
 /* Cards */
 
 /* todo light and dark adaptations needed */
@@ -329,6 +369,7 @@ See https://github.com/pydata/pydata-sphinx-theme/pull/1784
   border-bottom: 2px solid #999;
   font-size: 1.2rem;
   font-weight: 600 !important;
+  font-family: "Poppins", sans-serif !important;
 }
 
 .sd-card-header {

_static/fonts/NunitoSans-VariableFont.woff2

@@ -1,6 +1,6 @@
 # Python Package Code Style, Format and Linters
 
-```{admonition} Take Aways
+:::{admonition} Take Aways
 
 * pyOpenSci requires authors to follow PEP 8 code format guidelines
 * Setting up a code formatters like Black and isort will help you enforce PEP 8 style guidelines and also consistent, readable code format
@@ -9,7 +9,7 @@
 each time you make a commit.
 * [precommit.ci](https://pre-commit.ci/) is a bot that you can add to your GitHub repository. It will automagically apply code format to every PR using the tools specified in your pre-commit-config.yaml file. It can save significant time and make contributions easier for new contributors.
 * Automation is good! By making code quality tools care of your code, you can focus on structural and high values tasks.
-```
+:::
 
 Consistent code format and style is useful to both your package
 and across the scientific Python ecosystem because using similar
@@ -35,6 +35,7 @@ a discussion of:
 1. Setting up pre-commit hooks and the pre-commit.ci bot to make using code
    format tools in daily workflows and in pull requests on GitHub easier.
 
+(code-style-tools)=
 ## Use a code format tool (or tools) to make your life easier
 
 We suggest that you use a code format tool, or a set of format tools, because
@@ -57,18 +58,18 @@ the work out of manually implementing code format requirements.
 Consistent code format across packages within the (scientific) Python ecosystem,
 will also broadly make code easier to scan, understand and contribute to.
 
-## Linting vs format and style
+## Linting vs. format and style
 
 Before we dive in let's get a few definitions out of the way.
 
-### Code Linting
+### Code linting
 
 A code linter is a tool that will review your code and
 identify errors or issues. A linter typically does not modify your code. It
 will tell you what the error is and on what line it was discovered. Flake8,
 discussed below, is an example of a commonly-used code linter.
 
-### Code Formatters (and stylers)
+### Code formatters (and stylers)
 
 Code formatters will reformat your code for you. Python focused code formatters
 often follow PEP 8 standards. However, they also make stylistic decisions about
@@ -82,6 +83,7 @@ You will learn more about Black below.
 
 ## Code linting, formatting and styling tools
 
+(about-black)=
 ### Black
 
 [Black](https://black.readthedocs.io/en/stable/) is a code
@@ -94,14 +96,15 @@ some exceptions. A few examples of those exceptions are below:
 - Black will not adjust line length in your comments or docstrings.
 - This tool will not review and fix import order (you need `isort` or `ruff` to do that - see below).
 
-```{tip}
+:::{tip}
 If you are interested in seeing how Black will format your code, you can
 use the [Black playground](https://black.vercel.app/)
-```
+:::
 
 Using a code formatter like Black will leave you more time to work on
 code function rather than worry about format.
 
+(about-flake8)=
 ### Flake8
 
 To adhere to Python `pep8` format standards, you might want to add
@@ -186,6 +189,7 @@ Python file `temporal.py` imports after `isort` has been run
 :end-before: def calc_annual_mean
 :::
 
+(about-ruff)=
 ### Ruff
 
 [Ruff](https://docs.astral.sh/ruff/) is a new addition to the code quality
@@ -272,13 +276,13 @@ on your the code files in your commit. It will update any files to match
 black format standards. You can then retype the commit and push files to
 GitHub that have been formatted by black. -->
 
-```{important}
+:::{important}
 If have a Python code-base and multiple maintainers actively working
 on the code, and you intend to run a tool like Black, be sure to coordinate across your team. An initial commit that
 applies Black to your entire package will likely change a significant amount of
 your code. This could lead to merge conflicts on open and new PR's before the
 new changes are merged.
-```
+:::
 
 ## General pre commit checks
 

_static/pyos.css

@@ -3,9 +3,11 @@
 This guide is focused on packages that are either pure-python or that
 have a few simple extensions in another language such as C or C++.
 
-In the future, we want to provide resources for packaging workflows that require more complex builds. If you have questions about these types of package, please [add a question to our discourse](https://pyopensci.discourse.group/) or open an [issue about this guide specifically in the GitHub repo for this guide](https://github.com/pyOpenSci/python-package-guide/issues). There are many nuances to building and distributing Python packages that have compiled extensions requiring non-Python dependencies at build time. For an overview and thorough discussion of these nuances, please see [this site.](https://pypackaging-native.github.io/)
+For comprehensive guidance on packaging compiled projects with C/C++/Fortran/Rust extensions, see the [Scientific Python Development Guide on compiled packaging](https://learn.scientific-python.org/development/guides/packaging-compiled/). This is the best reference for complex builds and covers scikit-build-core, meson-python, maturin, and other modern build backends.
 
-## Pure Python Packages vs. packages with extensions in other languages
+If you have questions about these types of package, please open an [issue about this guide specifically in the GitHub repo for this guide](https://github.com/pyOpenSci/python-package-guide/issues). There are many nuances to building and distributing Python packages that have compiled extensions requiring non-Python dependencies at build time. For an overview and thorough discussion of these nuances, please see [this site.](https://pypackaging-native.github.io/)
+
+## Pure Python packages vs. packages with extensions in other languages
 
 You can classify Python package complexity into three general categories. These
 categories can in turn help you select the correct package frontend and