Illustrations and Graphics

The smallest useful visual explanation

JR Dream’s working direction is Functional Architectural Graphics. Use restrained graphics to explain order, relationships and responsibility when they improve understanding. This supporting system reuses the existing foundations rather than creating new brand symbols.

Start with text. Choose photography when a real environment, person or physical condition matters; an accepted icon and label when a familiar action needs a scanning cue; a diagram when a relationship, decision or handover needs explanation.

These are internally accepted working specifications, pending implementation testing and final company approval. Every example here is an instructional schematic, not verified JR Dream operations, property data, reporting authority or a delivery commitment.

Source: Illustrations & Graphics Exploration & Validation v1.0, pages 1 and 10.

Functional graphics, without decorative scenes

Information-bearing graphics must answer a specific question. Show useful order, responsibility, association or comparison with clear labels and the fewest useful elements. A fact, instruction or short list often needs no diagram.

The source adopts no conceptual illustration library. Characters, mascots, isometric cities, fake digital infrastructure and custom empty-state scenes are excluded at this stage. Revisit conceptual illustration only for a specific unmet explanatory need after simpler formats fail.

Architectural geometry supplies a restrained structure, not a licence to invent site plans or graphic motifs. The complete logo stays unchanged; never extract its skyline, circuitry or emblem as a node, connector or decoration.

Source: Illustrations & Graphics Exploration & Validation v1.0, pages 1–2 and 7–10.

Source-supported graphic categories

The source’s small master set is Flow, Decision, Relationship, Comparison and Timeline. These formats do not establish a measured architectural drawing standard or a decorative illustration style. A chart is conditional on a real need; none is added here because there is no approved dataset to explain.

Source: Illustrations & Graphics Exploration & Validation v1.0, pages 1 and 3–5, 9.

Construction, spacing and live labels

Node labels use Inter 16px / 1.4, weight 500; Arabic uses IBM Plex Sans Arabic 18px / 1.5, weight 500. Supporting roles use English 14px / 1.5 and Arabic 16px / 1.65. The examples use existing UI/body-small aliases so user font scaling and language rules remain effective.

Keep alignment deliberate, straight or orthogonal routes clear of text, and related groups 24px apart. Aim for 3–5 nodes per view as an editorial limit; split larger explanations into linked sections or a text equivalent. Heights grow with labels, rather than shrinking the type.

Diagram connector width is 2 CSS pixels. Lucide retains its separate 2-unit design stroke that scales with its icon canvas. Do not modify icon paths or strokes to imitate diagram connectors.

Source: Illustrations & Graphics Exploration & Validation v1.0, pages 2 and 9.

Colour, meaning and contrast

Use white/warm-white surfaces, charcoal labels and secondary-text connectors. Accessible action orange supports selected emphasis. Functional status colours apply only to an actual stated status, never an ordinary category or decorative scene. No gradients or new multicolour palette are introduced.

Independent recalculation matches all 5 source pairs to two decimals. These numerical checks do not certify a complete accessible graphic. A decorative separator is not a meaningful node boundary. Do not encode an important distinction through colour, thickness or a dashed line alone.

This source-based node recipe uses existing selection roles. The documentation sidebar’s accepted solid orange/white selection remains its own implementation choice, unchanged by this page.

Source: Illustrations & Graphics Exploration & Validation v1.0, pages 2, 5 and 9.

Order, decisions and relationships

Source: Illustrations & Graphics Exploration & Validation v1.0, pages 3–4 and 6.

Use graphics only where they help

Keep an explanation near its task. It is not a persistent decorative background. Documentation can use these same formats without claiming that a future product or workflow already exists.

Source: Illustrations & Graphics Exploration & Validation v1.0, pages 1, 4 and 7.

Graphics, icons and photography have different jobs

Iconography supplies a familiar scanning cue alongside a label. A functional graphic explains several steps or relationships. Photography explains a real environment or physical condition, under the existing rights and authenticity rules.

Do not enlarge an icon into a new illustration language, redraw approved glyphs, stylise a photograph into a substitute graphic, or reuse the logo as diagram material. This page uses no photographs or new icon assets. Conceptual illustration and architectural motifs are not adopted by this stage.

Source: Illustrations & Graphics Exploration & Validation v1.0, pages 1–2 and 7–10.

Clear versus ambiguous explanations

Source: Illustrations & Graphics Exploration & Validation v1.0, pages 3–5 and 7–8.

Readable, responsive and bilingual

Provide a short purpose and visible structured text describing every essential step, branch and relationship. Use live HTML for labels and order where practical. Meaningful standalone SVGs need an accessible title/description; hide redundant connector imagery when the labels and text already provide its meaning.

The source allows horizontal steps only at 768px and above when labels fit. Stack below that width, and earlier when longer copy or doubled text makes a row difficult. This is a diagram-fit rule, not a new page-grid band. These examples additionally require sufficient local width in rem units; nodes keep their type size and grow naturally.

Reading order remains semantic when layout changes. RTL requires separately reviewed wording, role placement and arrow direction, not a reflection of the entire graphic. Preserve the logo, category icons, numbers and reference IDs; use bdi for mixed identifiers. No unreviewed Arabic source sample or invented Arabic wording is used.

All specimens are static explanations, not interactive nodes. If later made interactive, use appropriate native controls, meaningful names, keyboard operation, visible focus and existing minimum targets. Do not introduce hover-only explanations. Contrast and automated layout checks alone do not certify comprehensive accessibility.

Source: Illustrations & Graphics Exploration & Validation v1.0, pages 2, 6–7 and 10.

Documents and presentations

CSS pixels, points and millimetres remain separate. Vector geometry can scale, but labels and meaning still need review at the intended size. The website’s PDF export demonstrates complete content flow, not validation of the native physical recipes.

Source: Illustrations & Graphics Exploration & Validation v1.0, pages 8–10.

Implementation and asset governance

.graphic-node {
  padding: var(--space-16);
  border: var(--border-thin) solid var(--border-control);
  border-radius: var(--radius-control);
  background: var(--surface-primary);
  color: var(--text-primary);
  font-size: var(--type-ui-size);
  font-weight: var(--weight-medium);
  line-height: var(--type-ui-leading);
  min-inline-size: 0;
  overflow-wrap: anywhere;
  /* No fixed block height. Labels stay live and can wrap. */
}
.graphic-connector path {
  fill: none;
  stroke: var(--text-secondary);
  stroke-width: var(--border-strong);
}
/* Use --space-32 between steps and --space-24 between related groups.
   Start with a vertical list; use horizontal steps only at >=768px
   AND when the available width and enlarged labels fit.
   This diagram-fit rule does not replace the page grid bands.
   Keep connectors in reserved space, outside node text. */

<figure aria-labelledby="example-purpose">
  <figcaption id="example-purpose">Association example, not an operating model</figcaption>
  <svg width="32" height="8" viewBox="0 0 32 8"
       role="img" aria-labelledby="line-title line-desc" focusable="false">
    <title id="line-title">Association line</title>
    <desc id="line-desc">Plain line, not a sequence arrow.</desc>
    <path d="M0 4H32" fill="none"
          stroke="var(--text-secondary)" stroke-width="var(--border-strong)" />
  </svg>
  <p>Text equivalent: B is associated with A; no order is implied.</p>
</figure>
<!-- With equivalent adjacent wording, hide a redundant connector SVG
     using aria-hidden="true" and focusable="false" instead.
     IDs must be unique for every informative instance.
     In React, a title's children must be a single string. -->

// Keep one content record with stable node IDs and semantic order.
// Translate/review labels separately; do not mirror a whole SVG.
// In horizontal RTL flow, resolve directional connectors toward the
// next semantic step. Vertical order remains top-to-bottom.
// Preserve the logo, category icons, numbers and reference identifiers.
// Isolate mixed identifiers: <bdi dir="ltr">JRD-GFX-001</bdi>.

// HTML/CSS suits live, wrapping labels and ordered relationships.
// SVG suits simple vector paths with purpose/title/description.
// If exporting outlined text or a flattened image, retain a complete
// accessible structured text equivalent and an editable master.
// Re-route connectors after content changes; never cover text with lines.

The proposed Graphic aliases in the PDF map to existing values; they are not a parallel token architecture. These specimens use the central tokens directly. The local fit threshold is a documentation implementation choice, not a new brand breakpoint. No production component API or Figma library is created.

For future masters, retain stable node IDs, one authoritative content record, semantic order, editable text and variable-height frames. Update wording/roles/branch labels in the master and re-route connectors after reflow. Create a separate layout variant only when needed.

Prefer SVG for simple vectors and PNG only when the receiving application cannot render SVG reliably. Keep editable masters and full text equivalents for outlined or flattened exports. Record ID, purpose, language, master/source, version, content owner, hypothetical/verified status, approval and text description. Keep masters, language exports, content/descriptions and licences organised without adding an asset-management platform.

Source: Illustrations & Graphics Exploration & Validation v1.0, pages 6 and 9–10.

Validation and approval status

The source reports 20 WeasyPrint/Pango process width simulations, font rendering, selected contrast calculations and static PDF review. These are source-study results, not browser or assistive-technology certification for this application.

Tests executed for this page are recorded in docs/stage-02.2h-implementation.md. The canonical URL remains /docs/foundations/graphics; the requested Illustrations URL redirects to it without a duplicate page or navigation entry.

• Actual roles, branches, responsibilities, service associations, dates, datasets and exceptions require business validation before a factual diagram is published.
• Competent Arabic review, approved bilingual labels, real RTL reading order and mixed-content checks remain pending.
• Screen readers, real devices, other browsers, actual zoom/reflow, text-spacing overrides and native forced-colours review remain pending.
• Native export/import, editable SVG text/fallback, accessible PDF structure, physical print/projector proof and final company approval remain pending.