Add Theme Fonts topic (EN + JA)

[TorreyBetts]

Closes #758.

Adds a Theme Fonts topic under Theming (Web SDK), in English and Japanese, documenting how the RevealTheme font properties resolve and how to use them with the font style support added in Infragistics-BusinessTools/Reveal#4009.

New topic: web/theming-fonts

• The five font properties (regularFont, mediumFont, boldFont, italicFont, boldItalicFont) and examples of where each is used.
• The family-per-style model: each property takes a font family and Reveal renders it at normal weight and style.
• Both supported patterns with code: a dedicated family per style, and one family for every style with the faces derived from the page's @font-face rules (weight/style table included).
• The @font-face prerequisite, with a Google Fonts <link> and a self-hosted example, and a caution to add the stylesheet before assigning the theme.
• The missing-face case, with the console warning text quoted so it is searchable, and screenshots of the same dashboard with and without the bold face available.
• Limitations: fonts registered only through the FontFace constructor, and the installed-font fallback.
• A note on the behavior change: italicFont and boldItalicFont were previously accepted but not applied on the web.

Other changes

• web/theming-dashboards: italicFont and boldItalicFont added to the property table, with a pointer to the new topic.
• sidebars.ts: Theming is now a category with Fonts as its child; Japanese labels added to current.json.
• Japanese translation of the topic and both screenshots copied to the ja image folder.

Release notes are not touched here; the italicFont/boldItalicFont behavior change is ready to be picked up when the next version's notes are written.

[zdrawku]

@TorreyBetts , at first look it looks okay to me.

I passed the doc to my local testing sample asking to verify the content against it, and this is what I got as results:

1. "the same value as regularFont" is a literal string compare — and fails silently.

   The doc's contract is "when a style property has the same value as regularFont." That's an exact !== in aliasFor(), applied before _firstFamily() normalizes. So both of these name the same family and neither aliases:

   theme.regularFont = "Crimson Pro";
   
   theme.boldFont    = "'Crimson Pro'";      // quoted
   
   theme.italicFont  = "Crimson Pro, serif"; // fallback list
   
   

   Both render at the 344.23px system-fallback width. Worse — zero warnings. The early return happens before registration, so the slot never enters the set whenReady() diagnoses. This is the only completely silent failure mode in the feature (missingFaces at least warns four times), and the doc's wording actively invites it. Suggest a caution that the name must match character-for-character, unquoted, with no fallback list.

   2. "A rule that declares a weight range, as variable fonts do, matches any weight inside the range" is misleading.

   The matcher does accept the range — that part is true. But _renameFamily() rewrites only the font-family descriptor, so the alias inherits font-weight: 200 900, resolves to 400, and renders regular while reporting injected and usable. Measured, same two font files:

   
   @font-face declaration | medium | bold | italic | bold-italic
   -- | -- | -- | -- | --
   font-weight: 200 900 (variable) | 337.81 ✗ | 337.81 ✗ | 317.84 ✓ | 317.84 ✓
   discrete 400/500/700 | 344.01 ✓ | 359.5 ✓ | 317.84 ✓ | 350.51 ✓

Only the descriptor differs. This matters because the doc recommends self-hosting and the Google Fonts examples only pass by accident — Google serves discrete per-subset weights. Variable fonts are increasingly the default way fonts ship. Either add a caution to declare discrete weights, or fix the alias to pin font-weight/font-style to the requested value.

3. The RevealSdkSettings.theme mutation trap is undocumented.

Every code sample in the PR happens to do it right (new RevealTheme() → assign), but nothing says the assignment is what applies it. Mutating the live theme injects zero aliases:

RevealSdkSettings.theme.boldFont = "Crimson Pro";   // does nothing

Aliases are requested from updateRevealTheme(), whose only caller is the theme setter. The getter returns the live object, so mutation never triggers it. Fonts still appear to load and everything renders regular — indistinguishable from the bug this feature fixes. Worth an explicit wrong/right pair, especially since the neighbouring refreshTheme note may lead readers to assume that's the apply step.

[TorreyBetts]

@zdrawku thanks, all three were accurate. I checked each against fontStyleAliases.ts / revealSdkSettings.ts on develop and addressed them in 782244b (EN + JA). Replying to #759 (review).

1. Exact string compare. Confirmed: aliasFor() compares slotFont !== regularFont before _firstFamily() normalizes, and the early return skips registration, so nothing is diagnosed. The section now says the property must be set to exactly the same string as regularFont, followed by a caution with your quoted and fallback-list examples, a statement that no warning is logged, and the advice to assign every property from a single variable. I worded it as "identical string" rather than "unquoted, no fallback list" because a quoted name or a fallback list does alias as long as regularFont carries the same string.

2. Weight ranges. Confirmed and reproduced. Cloning a font-weight: 200 900 rule with only font-family renamed measures 480.59 at normal weight, identical to the real 400 face (real 700 is 510.05). I removed the "matches any weight inside the range" sentence and added a Variable Fonts subsection: declare one rule per weight with a single font-weight value, and every rule can point at the same variable font file. I measured that form too and it renders at the pinned weight (510.05 for 700). Two additions from testing:

• Google Fonts is not immune. Requesting a range (wght@200..900) returns font-weight: 200 900 rules, so the Google Fonts paragraph now says to request a list of weights and not a range.
• boldItalicFont is affected as well as mediumFont and boldFont. In your table the variable bold-italic width (317.84) equals the italic width, against 350.51 for the discrete declaration, so it is rendering 400 italic. The doc lists all three properties; italicFont is fine because 400 is the weight it asks for.

3. Theme mutation. Confirmed: the getter returns the live _currentTheme and the setter is the only path into updateRevealTheme(). I added an Applying Font Changes section with the wrong/right pair (mutating RevealSdkSettings.theme versus clone(), change, assign), a note that the mutation logs no warning, and a sentence that RevealView.refreshTheme does not replace the assignment, it reloads the dashboard with the theme that was last assigned.

Both locales build cleanly with the new anchors resolving (#variable-fonts, #applying-font-changes, and their Japanese equivalents).

[zdrawku]

Well done