/* ==========================================================================
   fonts.css — the only @font-face declarations in the project.

   WHY THIS FILE EXISTS

   The site used to name four families in its font stack and load none of them
   from here. `css/fonts.css` declared 24 faces for the Persian fonts in
   fonts/ — Dana, Hafez, Hamrah, Manshoor, Melli, Onvan and so on — and not one
   page linked the file, so every declaration was dead weight and the 1.4 MB of
   font files it pointed at was never downloaded.

   Meanwhile the stack in css/tokens.css asked for 'Vazirmatn','IRANYekanX',
   'Gofteh' — none of which had a face here — and the families the JavaScript
   actually fetched (Inter, Noto Sans SC) were not in the stack at all. So the
   homepage downloaded Inter and then rendered in system-ui, and 404.html and
   privacy.html requested JetBrains Mono and nothing else, which is how the same
   sentence ended up in three different typefaces across the site.

   WHAT IS HERE, AND WHY

   One family: Vazirmatn, as a single variable file carrying a 100–900 weight
   axis. It is the only file in fonts/.

   WHY THE FAMILY CHANGED

   The previous family, Dana, is a single STATIC face. It was declared as
   `font-weight:100 900`, so the browser served the same file for every weight
   and there was no real 900 to render — measured, not assumed: the width of a
   rendered vertical stroke (alef at 60px) was 200px at weight 300 and 200px at
   900. Every `font-weight` in the site rendered as 400.

   That went unnoticed because the headings looked emphatic anyway. They were
   faking the missing weight with `-webkit-text-stroke:.5px`, and on a 16.5px
   Persian title half a pixel of outline on each side of the glyph is a large
   share of the stem. The result read as smeared rather than bold, and it was
   worst in Persian, where the letterforms are thinner and carry more joining
   detail than the Latin ones beside them.

   Vazirmatn's variable axis is real: the same measurement gives 200px at 300,
   246px at 400, 328px at 700 and 369px at 900. The headings can therefore be
   set by weight, which is what the stylesheets were already asking for, and the
   stroke is gone rather than merely reduced.

   The file name carries square brackets, so the URL in the @font-face is
   percent-encoded — `Vazirmatn%5Bwght%5D.woff2`. Unencoded, the request 404s
   and the whole site falls back to system-ui with no visible error.

   Vazirmatn also has tabular figures, so `0` and `1` share an advance. On a
   site full of IP addresses, port numbers and version strings that is not a
   nicety, and `l`, `1` and `I` are all distinct, which a technical blog needs.

   The mono stack deliberately does not live here. There is no monospace file in
   fonts/ — the only file there is a Persian text face — so code, paths and
   identifiers fall to the platform's UI monospace, chosen in css/tokens.css.

   COVERAGE, MEASURED RATHER THAN ASSUMED

   One typeface across the site is only half the claim; the other half is that
   the typeface actually has the glyphs. Measured in the browser against the real
   production stack, by comparing the rendered advance of a string in
   "'Vazirmatn', system-ui, sans-serif" with the same string in Vazirmatn alone
   and in system-ui alone (identical to the first means Vazirmatn rendered it,
   identical to the second means the fallback did):

      Persian, Arabic, Latin   every character from Vazirmatn
      French  é à ç û ê î œ   NOT in Vazirmatn; these fall through to system-ui,
                               so a French word is set in two faces mid-word
      Chinese                  NOT in Vazirmatn at all; the advance is exactly
                               1em per glyph, the signature of a full-width CJK
                               fallback

   The French and Chinese gaps are a real conflict between two requirements, not
   an oversight: a single typeface everywhere, and no font downloads. They cannot
   both hold for those two languages with this file. Everything needed to settle
   it is above — the honest fixes are dropping the two locales or shipping one
   more local face. Until then the dictionary entries stay in js/main.js, so
   restoring either language is a one-line change to the switcher.
   ========================================================================== */

@font-face{
  font-family:'Vazirmatn';
  src:url('../fonts/Vazirmatn%5Bwght%5D.woff2') format('woff2-variations'),
       url('../fonts/Vazirmatn%5Bwght%5D.woff2') format('woff2');
  /* A real wght axis, 100–900, in one 108 KB file. Verified by measuring the
     rendered stem width of a single vertical stroke (alef) rather than assumed
     from the file name: 200px at weight 300, 246px at 400, 328px at 700 and
     369px at 900 — a 50% real increase in stroke thickness.

     That measurement is the whole point. The previous family, Dana, has no fvar
     table at all: the same stem measured 200px at every weight, so every
     `font-weight` on the site rendered as 400 and the headings had no real
     hierarchy. They were faking one with a `-webkit-text-stroke`, which is what
     made the Persian titles look smeared rather than bold. */
  font-weight:100 900;
  font-style:normal;
  font-display:swap;
  /* Same-origin, 108 KB, and it is the only face, so there is no competing
     family to avoid a swap for. */
  text-rendering:optimizeLegibility;
}