Repository navigation
Read the CFF outlines of OpenType fonts in the managed font reader - #470
Merged
Merged
Conversation
First part of step 6 of #412. Text gets its glyphs from GDI today (GraphicsPath.AddString, gdi32 for widths and kerning), which does not exist outside Windows. The new internal class TrueTypeFont reads font files itself: - .ttf files and every font of a .ttc collection; CFF-based .otf and bitmap-only fonts are recognized and report HasTrueTypeOutlines=false - glyph contours from glyf/loca with composite glyphs resolved (offsets, scales, 2x2 transforms, point matching) - cmap formats 0, 4, 6 and 12, including symbol fonts - advance widths (hmtx), metrics (head, hhea, OS/2) and names (name) - kerning pairs of the version 0 kern table, as GDI reads them - GetPathData returns the outline in the layout of a GDI+ GraphicsPath after AddString, so GlyphShapeBuilder.PathDataToPath2D can take it unchanged; the quadratic segments become cubic ones by exact degree elevation Nothing uses it yet: the font service that replaces GDI in Text and FontCache follows in the next pull request. The tests compare names, metrics, glyph indices, advance widths, all contours of 112 characters and the kerning with reference data that fontTools wrote from the same font (Liberation Sans, SIL OFL 1.1, added under tests/CADability.Tests/Files/Fonts together with the script that wrote the reference). They also check that the outline is exactly the quadratic curves, a font collection, and invalid input. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
…DI (#412) Second part of step 6 of #412. Text and FontCache no longer use GDI or GDI+: the glyph outlines, advance widths, kerning, metrics and the list of font families come from the static, settable FontProvider.Current, not from FrameImpl.MainFrame, so texts work without a frame and on every platform. - FontProvider and FontFace (public, new) describe what the kernel needs. A face returns its glyphs as Bezier path data in the layout of GraphicsPath.AddString, which the kernel turns into geometry with GlyphShapeBuilder as before, so no provider can flatten the outlines. - ManagedFontProvider (public, new) is the default on all platforms, as decided for #412. It indexes the TrueType fonts of the system font directories by reading only their header tables, and loads a font file when a face is used. Files and font data can be added. - FontCache no longer creates a GDI device context in its constructor or deletes it in a finalizer, which ended the process outside Windows. - Without any font, painting and the extent of a text leave it out; GetOutline and similar explicit requests throw an InvalidOperationException that says what to do. - ShowPropertyFont and DimensionStyle list the families of the provider. - CADability.Forms.GdiFontProvider (public, new) is the old GDI implementation for applications that want it. TrueTypeFont reads the underline and strikeout metrics, adds both as rectangles like GDI+ does, and can read only the header tables of a font file. Tests: both test projects register Liberation Sans in an assembly initializer, so texts have a font even on a machine without fonts. The text tests that were inconclusive on Linux ("text needs GDI") now run there; new FontProviderTests cover text without a frame, the default face for unknown fonts, the exception without fonts, underline and strikeout, style fallback, header-only reading and the finalizer. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
) Step 6, part 2b of #412. The managed reader of #466 skipped OpenType fonts with CFF outlines, which many .otf files have, so a text in such a font fell back to the default face. The new internal CffOutlines reads the "CFF " table: - INDEX and DICT structures, the FontMatrix (which is stored rounded, e.g. 0.00048828 for 1/2048) - the Type 2 charstring interpreter: all path operators including the specialized curves and lines, flex, hflex, hflex1, flex1, local and global subroutines with their bias, widths, hints and hint masks (skipped, they do not change the outline), the arithmetic operators - CID-keyed fonts with FDArray and FDSelect (formats 0 and 3) The cubic curves go into the GDI+ path data unchanged. Not supported: CFF2 (variable OpenType fonts) and the deprecated accent composition of endchar (seac). TrueTypeFont gets HasCffOutlines and HasOutlines, and ManagedFontProvider indexes .otf and .otc files too. Tests: make_cff_test_fonts.py makes two small test fonts from a subset of Inter (SIL OFL 1.1): InterCffTest.otf rewritten to use subroutines, the specialized operators, flex and hint masks, and InterCidTest.otf, the same glyphs as a CID-keyed font with two font dicts. The outlines of both are compared command by command with fontTools. Checked locally against fontTools on 18,672 glyphs of the 47 CFF fonts of the Linux container, 7 of them CID-keyed: all equal. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
This was referenced Oct 15, 2026
Resolves the conflict with #497 in FontCache: the managed font calls of this branch now run under the same lock (this) that #497 introduced, and Clear disposes the glyph display lists and empties all caches, including the faces. FontProvider.Current, which calls Clear, documents that the display lists of the views need to be rebuilt when it is set after texts were painted. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
ClearingTheFontCacheDisposesTheGlyphLists reflected on the 'kerning' field of the GDI FontCache, which this branch replaces by the 'faces' of FontProvider.Current, so it failed with a NullReferenceException on Windows. It now checks that Clear empties the faces, and it runs on every platform, because the font cache no longer needs GDI. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
…nto feature/font-service
FontFace.GetAdvanceWidth, GetKerning and GetGlyphPath took a char, a UTF-16 code unit. A character outside the Basic Multilingual Plane, e.g. most emoji, is a surrogate pair of two chars in a string, so it could never reach a font: the text went through the font char by char. They now take a code point (int). FontFace is new public API of this PR, so this is the time to change it; after a release, every custom font provider would break. - Text and FontCache go through the text as code points (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. - The GDI face measures a character beyond U+FFFF with GetTextExtentPoint32, because GetCharABCWidths only takes UTF-16 chars, and reads the kerning pairs as unsigned values. The new FontCodePointTests check with a recording font provider that "a", an emoji and "b" reach the font as three characters, with their widths, kerning and outlines; they fail when the surrogate pair is not combined. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
With StepImport.Parallel, CreateEntity runs on several threads, but it added mapped items to the HashSet mappedItems and, for assemblies, products to the HashSet products without a lock (the other place that adds products locks it). Concurrent Add calls can corrupt a HashSet, and the enumeration of mappedItems after the creation then met a null entry: a NullReferenceException in ImportStep.Read. StepCyclicReferenceTest from #498 imports a file with mapped items 20 times in parallel and showed this now and then on the 2-core CI runner. With the test process limited to 2 cores, it failed 3 of 30 times without this change and 0 of 60 times with it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5 (cherry picked from commit 85e21f1)
This was referenced Oct 19, 2026
Merged
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Step 6 of #412, part 2b.
Stacked on #468 (which is stacked on #466). The base is
feature/font-service, so the diff shows only this part. It is also merged intointegration/issue-412(#467).Why
The managed reader of #466/#468 skipped OpenType fonts with CFF outlines. Many
.otffiles are such fonts, so a text in one of them fell back to the default face. #468 named this as a behaviour change for the release notes; with this PR that limitation is gone.What
New internal
CADability/CffOutlines.csreads theCFFtable:0.00048828for 1/2048), so a factor within 0.1 % of 1 counts as 1.hvcurveto,vhcurveto,hhcurveto,vvcurveto,hlineto,vlineto,rcurveline,rlinecurve);flex,hflex,hflex1,flex1;FDArraywith a private dict and local subroutines per font dict, andFDSelectformats 0 and 3.The cubic curves go into the GDI+ path data unchanged, so
GlyphShapeBuildergets exact curves as for TrueType.Other changes:
TrueTypeFontgetsHasCffOutlinesandHasOutlines.ManagedFontProvideralso indexes.otfand.otcfiles.Not supported:
CFF2table. Such fonts are still left out.endchar(seac), which modern fonts do not use.Tests
make_cff_test_fonts.pymakes two small test fonts (about 12 KB each) from a subset of Inter (SIL OFL 1.1, registered inREUSE.toml). Inter as shipped uses only the general operators, so the script rewrites the charstrings without changing the outlines:InterCffTest.otf(name-keyed) uses the specialized operators,flex, hint masks, and local and global subroutines;InterCidTest.otfhas the same glyphs as a CID-keyed font with two font dicts, each with its own local subroutines.The script asserts with fontTools that both fonts draw exactly the outlines of the original subset.
New
CffOutlinesTests:.otf;Textin an OpenType font through theManagedFontProvider.Mutation check. I broke the interpreter deliberately in four places: the subroutine bias,
flex, the fifth operand ofhvcurveto, andFDSelect. Each break made a test fail; theFDSelectone only the CID test, as intended.Checked locally, not in CI:
Local run on Linux:
CADability.Tests: 638 passed, 12 skipped, 0 failed.CADability.ImportTests: 88 passed, 0 skipped, 0 failed.CADability.Formsbuild.No public API change in this part and no change to the csproj version.
🤖 Generated with Claude Code
https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
Generated by Claude Code