[dsn27]

Step 6 of #412, part 2 of 3.

Stacked on #466. The base branch is feature/managed-font-provider, so the diff shows only this part. Once #466 is merged, change the base to master. Both are also merged into the integration branch integration/issue-412 (#467).

What changes

Text and FontCache no longer use GDI or GDI+. Outlines, advance widths, kerning, metrics and the list of font families all come from the static, settable FontProvider.Current, and no longer from FrameImpl.MainFrame. Texts therefore work without a frame and on every platform.

New public API (minor version)

Type	Assembly	Purpose
FontProvider	kernel	abstract: Current (static, settable), GetFamilyNames(), GetFace(family, bold, italic), GetDefaultFace(bold, italic)
FontFace	kernel	abstract: metrics in font units, GetAdvanceWidth, GetKerning (em units), GetGlyphPath
ManagedFontProvider	kernel	default provider, reads TrueType files itself (#466)
GdiFontProvider	CADability.Forms	the previous GDI implementation, opt-in

FontFace.GetGlyphPath returns Bezier path data in the layout of GraphicsPath.AddString. The kernel builds the geometry from it with the existing GlyphShapeBuilder, as before. A provider therefore cannot flatten the outlines, and every provider produces the same exact curves (problem 2 in #412).

The new API uses bool bold, bool italic and not System.Drawing.FontStyle, so step 8 does not have to break it again.

ManagedFontProvider (default on all platforms, as decided for #412)

• It indexes the system font directories of Windows, Linux and macOS, including fonts installed per user.
• Indexing reads only the header tables of each file (head, hhea, maxp, OS/2, post, name), so hundreds of fonts are indexed quickly. A font file is loaded completely only when one of its faces is used.
• AddFontFile and AddFontData add more fonts, e.g. embedded resources.
• Face selection: the exact style first, then the same weight, then regular, then any face. A missing bold or italic face is not synthesized; GDI does synthesize it.
• An unknown family falls back to GetDefaultFace: Microsoft Sans Serif, Arial, Liberation Sans, DejaVu Sans, Helvetica, Noto Sans, FreeSans, otherwise the first family.

Problem 1 of #412 is fixed

• No GDI handle in FontCache: it no longer creates a device context in its constructor or deletes one in its finalizer. Outside Windows the constructor threw and the finalizer then ended the process.
• Without any font:
  • Painting and the extent of a text leave the text out instead of failing.
  • GetOutline, GetShapes and GetCenterline throw an InvalidOperationException that says what to do.

Other changes

• ShowPropertyFont and DimensionStyle list the families of the provider instead of System.Drawing.FontFamily.Families.
• TrueTypeFont:
  • reads the underline and strikeout metrics (post, OS/2) and adds both as rectangles over the advance width, as GDI+ does;
  • can read only the header tables of a file (ReadHeaders).

Behaviour changes for the release notes

• On Windows, texts now use the managed reader by default. The glyphs come from the same font files and should match GDI within float precision. Part 3 adds the Windows test that compares them.

• What the managed reader leaves out:

  • OpenType fonts with CFF outlines (some .otf files) cannot be read. A text in such a font falls back to the default face. Read the CFF outlines of OpenType fonts in the managed font reader #470 removes this limitation.
  • Variable fonts: only the default instance is known (added after the first Windows CI run). GDI lists the named instances of a variable font as families of their own, e.g. "Bahnschrift Light Condensed" or "Segoe UI Variable Text" on Windows 11. The managed reader reads only the default outlines (glyf without gvar) and knows only the family of the default instance, e.g. "Bahnschrift". A text in such a named instance falls back to the default face. Variable OpenType fonts with CFF2 outlines are left out completely. The Windows CI run of the integration branch showed this: the glyph tests for these instances were skipped there.
  • Bold and italic faces a family does not have are not synthesized.

  Applications that need any of these can set FontProvider.Current = new GdiFontProvider(). Support for variable fonts (named instances, gvar and CFF2) is a possible follow-up.

• CADability.Gdi (public) is no longer used by the kernel for fonts. It stays until 2.0.

Tests

• Test fonts: Both test projects register Liberation Sans (bundled under tests/CADability.Tests/Files/Fonts, OFL) in an [AssemblyInitialize], in addition to the system fonts. Texts therefore have a font even on a build server without any fonts installed.
• Text tests now run on Linux: The tests that were inconclusive there ("text needs GDI") now run: 6 in ProjectTest and 5 in ImportTests. The guards are removed.
• New FontProviderTests:
  • text without a frame;
  • its width matches the advance widths and kerning;
  • an unknown font uses the default face;
  • the exception without fonts, while painting and extent survive;
  • underline and strikeout;
  • style fallback and case-insensitive family names;
  • header-only reading;
  • no finalizer that can crash the process.
• FontCacheGlyphTests: no longer limited to Windows. They run for every installed font, plus a new DataRow for Liberation Sans. The survey over all fonts (CADABILITY_FONT_SURVEY=1) found 0 fonts with glyphs without triangles among the 47 TrueType fonts in the Linux container.

Local run on Linux:

• CADability.Tests: 633 passed, 12 skipped (Windows fonts that are not installed), 0 failed.
• CADability.ImportTests: 88 passed, 0 skipped (5 before), 0 failed.
• The same, again all green, with /usr/share/fonts hidden, which simulates a runner without fonts.
• The kernel and CADability.Forms build.

On Windows (the Windows CI of #469, run on the integration branch): the reference-bitmap tests in ProjectTest, which now render text from the managed reader, pass. So do the glyph tests for Arial, Calibri, Segoe UI and Bahnschrift.

No change to the csproj version.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5

[dsn27]

Merged master into this branch. #497 conflicted with it in FontCache (Text.cs), because #497 added locking and display list disposal to the GDI version that this PR replaces. The resolution:

• GetOutline2D and GetKerning call the managed font face under the same lock (this) that Let hosts recover the display after renderer failures (#493, #494, #495, #496) #497 introduced.
• Clear disposes the glyph display lists, as in Let hosts recover the display after renderer failures (#493, #494, #495, #496) #497, and empties all caches, including the faces of this PR.
• The faces lock is always taken after lock (this), so the two locks are taken in the same order everywhere.
• FontProvider.Current calls Clear when it is set, so its documentation now says what Let hosts recover the display after renderer failures (#493, #494, #495, #496) #497's Text.ClearFontCache says: set it before texts are painted, or rebuild the display lists of the views afterwards.

The stacked PRs #470, #471, #472 and #479 contain the merge as well; none of them had further conflicts. CADability.Tests on Linux: 655 passed here, 676 on #479.

---

Generated by Claude Code

[dsn27]

One more adaptation after the merge with #497.

RendererRecoveryTests.ClearingTheFontCacheDisposesTheGlyphLists reflects on the private kerning field of the GDI FontCache. This PR replaces that field with the faces of FontProvider.Current. On Linux the test was skipped as inconclusive ("needs GDI"), but on Windows it failed with a NullReferenceException; the Windows job of the integration branch #467 showed this.

The test now checks that Clear disposes the glyph list and empties cache, centerLineCache, fontCharacteristicsCache and faces. It also runs on every platform now, because the font cache no longer needs GDI.

CADability.Tests on Linux: 656 passed, 0 failed.

---

Generated by Claude Code

[dsn27]

The Linux job on 830f7574 failed in CADability.ImportTests: StepCyclicReferenceTest.import_step_with_representations_that_map_each_other threw a NullReferenceException in ImportStep.Read (ImportStep.cs:1683, the loop over mapping_source.mapped_representation.items). All 659 CADability.Tests passed in the same run.

This failure is not caused by this PR. The test comes from #498, which is now on master, and this PR does not touch ImportStep. The test deliberately runs 20 parallel imports of a STEP file with mutually mapping representations, to provoke a race in the cycle cutting of #498. Locally, on the same commit, it passed 40 times in a row, which is 800 parallel imports. The race therefore seems to show only now and then, on the 2-core runner.

I am re-running the failed job once. If it fails again, the race in the parallel STEP import of #498 needs a fix on master; no such fix exists yet.

---

Generated by Claude Code

[dsn27]

API change in this PR: FontFace now takes Unicode code points (int) instead of char. The methods are GetAdvanceWidth(int codePoint), GetKerning(int left, int right) and GetGlyphPath(int codePoint, …).

Why: a character outside the Basic Multilingual Plane, for example most emoji, is a surrogate pair of two char in a string. Because the text went through the font char by char, such a character could never reach a font. FontFace is new public API of this PR, so now is the time to change it. After a release, the change would break every custom font provider.

What changed:

• Text and FontCache go through the text as code points, using Text.CodePoints. A surrogate pair is one character; a lone surrogate stays the char it is.
• The managed face passes the code point on to the cmap, which already supports format 12.
• GdiFontProvider measures a character beyond U+FFFF with GetTextExtentPoint32, because GetCharABCWidths only takes UTF-16 chars. It also reads the kerning pairs as unsigned values.

Tests: the new FontCodePointTests use a recording font provider. They check that "a", an emoji and "b" reach the font as three characters, with their widths, kerning and outlines, and that they fail when the surrogate pair is not combined.

Emoji themselves still need a font that contains them and a font fallback; that is a separate topic. This change only makes the API ready for them.

#470, #471, #472 and #479 contain the change; there were no conflicts.

CADability.Tests on Linux: 662 passed here and 683 on #479. The Windows build of the tests compiles.

---

Generated by Claude Code