Typography

A script-aware typography system

JR Dream uses Inter for English and IBM Plex Sans Arabic for Arabic. The shared sans-serif approach supports a consistent information hierarchy while each script keeps its own sizes, rhythm and line heights.

Use these working specifications across digital interfaces, documentation and future corporate experiences. Presentation and document recipes use the same families at their own point sizes. Do not stretch either typeface or replace the lettering inside the supplied logo.

The specification is internally accepted, pending implementation validation, competent Arabic review and final company approval. No linguistically approved Arabic specimen copy is available for this page. Arabic-font specimens use technical digits only; they are not translations or a choice of business numeral convention.

Source: Typography System Exploration & Validation v1.0, pages 1–2, 5 and 12.

Font families and local files

Both families are locally hosted, unmodified files obtained through the official Google Fonts repository. The checked-in files and hashes in public/fonts/README.md fix the deployed versions. styles/fonts.css uses real faces and font-display: swap; the typography stylesheet disables synthetic faces and enables automatic optical sizing.

Both fonts declare SIL Open Font License 1.1. The source records permission for commercial use and document embedding. Retain copyright and licence notices with redistributed fonts, do not sell fonts alone, and respect Reserved Font Names when modifying. The Plex licence reserves “Plex”. This task does not modify, convert or redistribute font files outside the project.

The source prefers official WOFF2 for future web production and static TTF/OTF for desktop editing. This implementation retains the existing full TTF files and Arabic coverage; no conversion or subsetting is performed. Fallbacks are availability fallbacks, not visually equivalent substitutes.

Source: Typography System Exploration & Validation v1.0, pages 2, 8, 11 and 12; local font metadata, font declarations, provenance record and retained OFL licences.

Working font weights

Use actual 400, 500 and 600 faces. The hierarchy requires no weight above 600. English and Arabic examples below demonstrate those same three weights without synthesised bold or italic.

Source: Typography System Exploration & Validation v1.0, pages 1–4 and 11.

Digital type hierarchy

Sizes are source CSS-pixel references at a 16px root. The implementation uses equivalent rem units. D / T / M means desktop / tablet / mobile; line height is a unitless multiplier and tracking is in em. Values below resolve from the existing CSS, including its responsive overrides.

Generic size variables resolve through language aliases, such as --type-h1-size to --type-en-h1-size or --type-ar-h1-size. Heading leading uses --type-h1-leading through --type-h6-leading; large and regular body share --type-body-leading. Small body uses --type-body-small-leading.

Live specimens at the current viewport

Each sample uses the existing responsive variables. Style names are labels, not extra document headings. Arabic-font samples contain technical digits only; actual Arabic wording is pending.

Use one H1 per page as the source’s editorial convention, with meaningful heading levels below it. A display style can decorate the page H1; do not use all heading levels merely to create visual variety.

Source: Typography System Exploration & Validation v1.0, page 3; implementation: styles/tokens.css and styles/typography.css.

Contextual typography

Specification tables on this page demonstrate existing 14px / 1.5 English table text and medium-weight headers. Use 16px English / 18px Arabic for content-heavy tables, keeping the same readable leading. Use tabular figures only for comparable numeric columns; do not treat reference codes as quantities.

Presentation and document reference

These are source-defined point values for physical/document contexts, not new CSS tokens or a print redesign of this website. Nominal sizes still require actual-size and recipient-software testing.

Reduce slide wording before reducing type size. Confirm exact installed font names, embed where supported, export PDF and compare Arabic joins and line breaks. Recipient substitution, projector distance and physical proofs remain unverified.

Source: Typography System Exploration & Validation v1.0, pages 4, 8–10.

Responsive typography

Headlines step down across these existing bands. Body sizes remain stable on mobile. The live specimens above follow the current viewport, while the hierarchy tables retain all three reference sizes. No separate typography breakpoint system is introduced.

Keep the root at 100%, allow text to wrap and containers to grow, and do not disable zoom or cap text to fit fixed heights. Wide tables scroll inside their own keyboard-accessible regions while the article remains in normal document flow.

Source: Typography System Exploration & Validation v1.0, pages 6, 11 and 12.

Arabic and bilingual layout

• Set both lang="ar" and dir="rtl" on Arabic sections. Keep English sections LTR and use start alignment, not a forced shared left edge.
• Use IBM Plex Sans Arabic at section level, with Arabic-specific heading and body metrics. Arabic regular body is 18px / 1.7; changing only the font family or body size is insufficient.
• Keep Arabic letter spacing at zero, normal word spacing and no uppercase transformation. Do not justify paragraphs, insert manual kashida, add spaces to stretch lines, synthesize italic or horizontally scale either font.
• Isolate codes, dates, URLs and Latin names with bdi, giving an explicit direction when known. Do not reverse strings manually. Use an explicit English font span only when necessary; isolated identifiers can retain the section font.
• Choose Western or Arabic-Indic business numerals with the business and Arabic reviewer. Do not mix conventions in a data column; preserve machine identifiers in their original form.

Source: Typography System Exploration & Validation v1.0, pages 3, 5, 6, 11 and 12.

Accessibility, readability and writing

• Retain the script-specific unitless leading in the tables. Arabic needs room for connected forms, dots and diacritics; equal English and Arabic sizes/leading are not a reliable recipe.
• English paragraph guidance is 45–75 characters, about 65ch maximum. The Arabic measure near 55ch is provisional and needs visual review: ch is not a count of Arabic characters.
• Allow user text enlargement and spacing overrides without clipped labels or fixed-height text boxes. The source leaves a full text-spacing override test pending; it does not define new letter or word spacing values for this purpose.
• Keep meaningful heading order, correct language attributes and visible field labels. Essential guidance must remain above optional caption size.
• Use paragraph spacing instead of blank-line characters or manual text boxes that disrupt reading order. Prefer start alignment and avoid justified paragraphs.
• Use charcoal or muted text on tested light surfaces and white on charcoal. Small white action labels stay on accessible action orange. A heading style does not exempt ordinary text from contrast checks.

Use the Colour foundation’s tested pairings and restrictions when applying these text roles. Font scaling, spacing, focus, language and assistive-technology behaviour need validation beyond a small contrast sample.

Project writing standard

Do not use Unicode U+2014 in authored JR Dream content. Use a comma, colon, full stop or grammatically appropriate standard hyphen according to the sentence. This applies to documentation, UI copy, accessibility descriptions, developer explanations and future corporate website content. The persistent rule is recorded in AGENTS.md.

Source: Typography System Exploration & Validation v1.0, pages 3–6, 9–12; punctuation convention is a project instruction, not a typography PDF specification.

Developer implementation

Reuse the existing font declarations, central tokens and language-aware aliases. Do not duplicate the type scale in components. A genuinely English subsection inside Arabic must declare its language and direction so English metrics are restored.

/* Load the existing fonts.css, tokens.css and typography.css.
   Language aliases already select the script and responsive band. */
.feature-title {
  font-family: var(--font-content);
  font-size: var(--type-h1-size);
  font-weight: var(--weight-semibold);
  line-height: var(--type-h1-leading);
  letter-spacing: var(--tracking-h1);
  text-align: start;
}
.reading-text {
  font-family: var(--font-content);
  font-size: var(--type-body-size);
  font-weight: var(--weight-regular);
  line-height: var(--type-body-leading);
  max-inline-size: var(--measure);
}
.comparable-number { font-variant-numeric: tabular-nums; }
/* Headings remain semantic HTML. Do not create another breakpoint scale.
   Keep html at 100%, font-synthesis: none and optical sizing: auto,
   as the existing stylesheets do. */

<section lang="en" dir="ltr">
  <h2>Implementation example</h2>
  <p class="reading-text">English documentation content.</p>
</section>

<!-- Template only: approved Arabic text has not been supplied. -->
<section lang="ar" dir="rtl">
  <!-- Insert approved Arabic heading and paragraph here. -->
  <!-- Isolate Latin identifiers and dates without reversing strings: -->
  <bdi dir="ltr">JR-024</bdi>
  <bdi dir="ltr">2026-10-20</bdi>
  <!-- Add lang="en" dir="ltr" to a genuinely English subsection.
       Leave isolated identifiers in the section font unless needed. -->
</section>

The HTML is a technical template with no Arabic sample prose. Font fallback line breaks, diacritics, long labels and mixed punctuation require later testing with approved content. Never apply font CSS to reconstruct or replace the supplied logo lettering.

Source: Typography System Exploration & Validation v1.0, pages 5, 10–12; snippets are documentation implementation guidance.

Validation and approval status

No comprehensive WCAG conformance, Arabic linguistic approval, production release or final company approval is claimed. Real Arabic content remains a validation requirement, not an inferred result from technical digit specimens.

Source: Typography System Exploration & Validation v1.0, page 12; prior implementation records and current Stage 02.2C report.