[mike-doctorina]

Split out of #27, where this arrived inside a commit about hit-testing (93a8791), hardcoded Menlo first for every platform, and was mentioned nowhere in the description or the changelog.

The bug it fixes

Flutter hands fontFamily straight to the platform font manager, and only some of them know the CSS generic 'monospace':

Platform	'monospace'	Result before
Android (font config), Linux (fontconfig)	resolves	correct
Web	resolves (browser / Noto fallback)	correct
iOS, macOS (CoreText)	not known	inline code fell back to the proportional body face
Windows (DirectWrite)	not known	same

So inline `code` and fenced blocks silently stopped looking like code on Apple and Windows.

What this does

Substitute a real face on exactly the two platforms that need it, and keep the generic everywhere it already worked:

String get kMonospaceFontFamily {
  if (kIsWeb) return 'monospace';
  return switch (defaultTargetPlatform) {
    TargetPlatform.iOS || TargetPlatform.macOS => 'Menlo',      // ships with every release
    TargetPlatform.windows => 'Consolas',                        // ships since Vista
    TargetPlatform.android || TargetPlatform.fuchsia || TargetPlatform.linux => 'monospace',
  };
}

kMonospaceFontFamilyFallback follows and ends in 'monospace' again, so a platform missing its primary face still lands on a real monospace one instead of the proportional default.

Web deliberately keeps the generic: its renderer cannot reach arbitrary system fonts, so naming one could not help, and this guarantees mobile web is byte-identical to 0.2.0.

Rendering on Android, Fuchsia, Linux and web is unchanged. Only Apple and Windows move, and only in the direction of correctness.

It also makes the face replaceable

There was no supported way to change it. Inline code goes through MarkdownThemeData.textStyleFor, so subclassing the theme moved that half — but BlockPainter$Code builds its base style in a static method reading the global directly, so fenced blocks did not follow. The only ways out were abusing SyntaxHighlighter.baseStyleFor to set a font family, or reimplementing the whole fence painter through theme.builder. The two halves could not even be changed by the same mechanism.

MarkdownThemeData(
  textStyle: ...,
  monospaceFontFamily: 'JetBrains Mono',
  monospaceFontFamilyFallback: ['Fira Code'],   // optional
)

null keeps the platform default; an empty fallback list means "no fallbacks", not "unset". Both paths read effectiveMonospaceFontFamily / effectiveMonospaceFontFamilyFallback, which are public so a custom block painter can use them too. Threaded through mergeTheme, copyWith and lerp (a family cannot be interpolated — it snaps at t < 0.5).

⚠️ Needs a look on a real build before merge

Font resolution is not observable in flutter_test — the harness substitutes a stub font, so the 15 tests here pin the family string we pass, not that Menlo / Consolas actually resolve. Please eyeball a real iOS, macOS and Windows build.

Tests

15 cases in test/theme/theme_test.dart: the generic survives on Android / Fuchsia / Linux, substitution happens on iOS / macOS / Windows, every platform's chain ends in 'monospace' and contains its primary, non-monospace spans keep the body face, a host override wins on every platform, an empty fallback list is honoured, copyWith carries it, and a fenced block renders.

flutter test test/unit_test.dart → 987 passed. dart analyze --fatal-infos --fatal-warnings lib/ test/ → clean.

One nit: copyWith carries the override needs a cast, because on master MarkdownThemeData.copyWith still returns the base ThemeExtension<MarkdownThemeData>. #27 narrows that return type, so I left the cast here with a comment rather than have two PRs touch the same line.

---

Credit: @itsezlife spotted the underlying bug in #27 and wrote the first fix. What changed here is the shape: platform-aware instead of Menlo-first everywhere, plus the theme knob.