/* SAFE Arabic font override
   - Applies ONLY on RTL / Arabic pages
   - Does NOT change font-size
   - Does NOT override icon fonts
*/

/* Self-hosted (no external network dependency - required for offline/air-gapped
   operation). Arabic-script glyph subset only, matching what this file actually
   renders text in. */
@font-face {
  font-family: "Cairo";
  font-style: normal;
  font-weight: 300 600;
  font-display: swap;
  src: url("/assets/grc_tool/fonts/cairo/cairo-arabic.woff2") format("woff2");
  unicode-range: U+0600-06FF, U+0750-077F, U+0870-088E, U+0890-0891, U+0897-08E1, U+08E3-08FF, U+200C-200E, U+2010-2011, U+204F, U+2E41, U+FB50-FDFF, U+FE70-FE74, U+FE76-FEFC;
}
/* Tajawal intentionally NOT declared here (and not referenced in the font
   stack below) -- Cairo is the sole approved Arabic UI font system-wide;
   Tajawal must never render, even as a fallback, so it isn't given a
   @font-face at all. */

html[dir="rtl"], html:lang(ar), html[lang^="ar"] {
  --grc-ar-font: "Cairo","IBM Plex Sans Arabic","Noto Sans Arabic",system-ui,-apple-system,"Segoe UI",Arial,sans-serif;
  /* Several theme files (daroo_risk_center_page.css and its theme variants)
     build their own font stack from this --font variable instead of using
     --grc-ar-font directly. Redefining it here, once, at the same RTL/Arabic
     scope covers them without having to patch each theme file individually. */
  --font: var(--grc-ar-font);
}

/* Was a hand-maintained whitelist of "known" text containers (no universal
   selector, no !important) -- kept missing new ones as the product grew
   (dashboards, widgets, every new custom popup/dialog this session added).
   The whitelist approach is fundamentally unable to guarantee "everything":
   any Bootstrap/Frappe/third-party component with its OWN explicit
   font-family (exactly what broke .modal-content under plain .modal below,
   see the kept comment) silently wins over a same-or-lower-specificity
   whitelist rule the moment it isn't individually listed. Switched to a
   real universal selector + !important, which by CSS rules can only be
   beaten by another !important rule of equal-or-higher specificity -- i.e.
   exactly the icon-font and monospace overrides below, which are both
   already !important and more specific, and nothing else. This is the
   only way to actually satisfy "everywhere: all dashboards, all popups". */
html[dir="rtl"] *,
html:lang(ar) *,
html[lang^="ar"] * {
  font-family: var(--grc-ar-font) !important;
}

/* DO NOT break icons.
   font-family: inherit was not enough — the nearest ancestor with an
   explicit font-family is the Cairo rule above, so "inherit"
   resolved to the Arabic text font and broke every icon glyph (icon fonts
   map unicode codepoints to shapes in their own font file only). Each
   icon class is forced back to its own required font explicitly instead. */
html[dir="rtl"] .fa {
  font-family: "FontAwesome" !important;
}
html[dir="rtl"] .fas, html[dir="rtl"] .fa-solid {
  font-family: "Font Awesome 5 Free", "Font Awesome 6 Free" !important;
  font-weight: 900 !important;
}
html[dir="rtl"] .far, html[dir="rtl"] .fa-regular {
  font-family: "Font Awesome 5 Free", "Font Awesome 6 Free" !important;
  font-weight: 400 !important;
}
html[dir="rtl"] .fab, html[dir="rtl"] .fa-brands {
  font-family: "Font Awesome 5 Brands", "Font Awesome 6 Brands" !important;
}
html[dir="rtl"] .octicon {
  font-family: "octicons" !important;
}
html[dir="rtl"] .uil {
  font-family: "Unicons" !important;
}
html[dir="rtl"] .material-icons {
  font-family: "Material Icons" !important;
}
html[dir="rtl"] svg,
html[dir="rtl"] i[class*="icon"] {
  font-family: inherit;
}

/* DO NOT break code/monospace rendering (Server Script, Client Script,
   Print Format, Jinja/HTML editors, and any <pre>/<code> block all rely on
   a monospace family for alignment/legibility) -- the universal rule above
   would otherwise force Cairo onto these too, same failure class as icons. */
html[dir="rtl"] pre,
html[dir="rtl"] code,
html[dir="rtl"] kbd,
html[dir="rtl"] samp,
html[dir="rtl"] .CodeMirror,
html[dir="rtl"] .cm-editor,
html[dir="rtl"] .cm-content,
html[dir="rtl"] .ace_editor {
  font-family: "SFMono-Regular", "Consolas", "Liberation Mono", Menlo, Courier, monospace !important;
}

/* Universal Cairo coverage for bilingual content shown on English-mode
   pages (html[dir="ltr"] html[lang="en"]) -- this project's own standing
   convention stacks Arabic-then-English in the SAME field everywhere
   (Risk/Control/Compliance titles, dashboard cards, etc.), and that Arabic
   text renders even when the page itself is in English mode, where every
   rule above (all scoped to html[dir="rtl"]/lang=ar) never applies at all.
   Confirmed live: Home dashboard is html[dir="ltr"][lang="en"] while
   displaying real Arabic risk/control titles inline -- those were
   rendering in Frappe's own Latin font's fallback glyphs, not Cairo.

   Fix: prepend "Cairo" to the EXACT SAME stack Frappe's own body already
   computes (confirmed live via getComputedStyle) instead of swapping in a
   different stack. Cairo's own @font-face above only carries an Arabic-
   script unicode-range, so per CSS font-matching rules the browser uses
   Cairo for Arabic characters only and silently falls through to
   InterVariable/Inter/... for every Latin character -- Frappe's own
   Latin rendering is provably unchanged, only Arabic glyphs newly render
   in Cairo instead of whatever the Latin font's own (usually poor) Arabic
   glyphs were. This is additive to, not a replacement of, the RTL-mode
   rules above, which still fully apply when a page truly is Arabic/RTL. */
* {
  font-family: "Cairo", InterVariable, Inter, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif !important;
}

.fa {
  font-family: "FontAwesome" !important;
}
.fas, .fa-solid {
  font-family: "Font Awesome 5 Free", "Font Awesome 6 Free" !important;
  font-weight: 900 !important;
}
.far, .fa-regular {
  font-family: "Font Awesome 5 Free", "Font Awesome 6 Free" !important;
  font-weight: 400 !important;
}
.fab, .fa-brands {
  font-family: "Font Awesome 5 Brands", "Font Awesome 6 Brands" !important;
}
.octicon {
  font-family: "octicons" !important;
}
.uil {
  font-family: "Unicons" !important;
}
.material-icons {
  font-family: "Material Icons" !important;
}
svg,
i[class*="icon"] {
  font-family: inherit;
}

pre,
code,
kbd,
samp,
.CodeMirror,
.cm-editor,
.cm-content,
.ace_editor {
  font-family: "SFMono-Regular", "Consolas", "Liberation Mono", Menlo, Courier, monospace !important;
}

/* Website topbar brand link and footer copyright line render whatever
   company name/text is configured in Website Settings -- almost always
   pure Latin script (e.g. "Brains Valley Consultancy Services Co.").
   Under html[dir="rtl"] with the browser's default unicode-bidi: normal,
   the Unicode bidi algorithm treats trailing neutral/weak punctuation
   (the period) as belonging to the RTL paragraph context and visually
   reorders it to the front of the string (".Brains Valley..." instead of
   "...Services Co."), even though every character in the string is LTR.
   unicode-bidi: plaintext makes the browser derive direction from the
   text's own first strong character instead of inheriting the ancestor's
   dir, so a Latin company name renders left-to-right correctly regardless
   of the surrounding RTL page, while an Arabic one configured in its
   place would still correctly render right-to-left on its own. Found
   2026-08-19 auditing the guest /login page's Arabic language switch. */
html[dir="rtl"] .navbar .nav-link,
html[dir="rtl"] .footer-powered {
  unicode-bidi: plaintext;
}