Skip to content

Run the kernel as WebAssembly in the Linux CI (#412) - #484

Merged
dsn27 merged 89 commits into
masterfrom
test/wasm-smoke
Oct 19, 2026
Merged

Run the kernel as WebAssembly in the Linux CI (#412)#484
dsn27 merged 89 commits into
masterfrom
test/wasm-smoke

Conversation

@dsn27

@dsn27 dsn27 commented Oct 16, 2026

Copy link
Copy Markdown
Collaborator

Part of #412 (step 9, verification).

Base: this PR targets integration/issue-412, because it needs both the font service (#466 → #472) and the picture and page setup changes (#473, #474), which are only combined there. Its own diff is just the smoke test. Retarget it to master once those PRs are merged.

Why

The goal of #412 is that CADability runs in the browser. So far that was argued, not shown. This PR runs CADability.dll in the browser runtime of .NET (WebAssembly, under Node.js) in every Linux CI run.

What

tests/CADability.WasmSmoke is a .NET 10 WebAssembly program (Microsoft.NET.Sdk.WebAssembly). It references CADability.csproj and runs 13 checks, without a frame and without GDI+:

  1. register a font from bytes; there are no system fonts in the browser
  2. create a project
  3. make a box minus a cylinder and check the volume
  4. measure a text and get its glyph outlines
  5. create a picture from PNG bytes
  6. paint the model through RecordingPaintTo3D, an IPaintTo3D of its own that replays display lists, and check the painted extent
  7. JSON round trip
  8. open a 1.x file with pictures
  9. open a 1.x file with page settings
  10. open Volumes.cdb.json
  11. import a STEP file
  12. export DXF and STL, and read the DXF back
  13. run the finalizers

The exit code is the number of failed checks. A new step in linux-ci.yml builds the program and runs it with node, which is preinstalled on the runner.

Result

Kernel Passed Failed
master (checks adapted to the old API) 6 7: PlatformNotSupportedException from System.Drawing.Common for text, picture and finalizers, and failures that follow from them
integration/issue-412 13 0

What this shows for the plan

  • Implementing IPaintTo3D works in the browser. RecordingPaintTo3D implements the interface unchanged, including PrepareBitmap(Bitmap) and Text(…, FontStyle, …). Naming GDI+ types in signatures is fine there; only creating GDI+ objects fails. So a browser front end can be written against the 1.x API, and the breaking step 8 (dropping System.Drawing.Common) is not needed for the browser.
  • Pictures are only painted as their outline in such a renderer, because IPaintTo3D has only Bitmap members for images (0 bitmap calls in the run). Showing the image itself needs the optional image interface discussed for Make CADability.dll platform independent: remove GDI+ from the core, porting the ShapeIt work #412; that is a separate PR.

Notes

  • No workload is needed. The plain WebAssembly SDK of .NET 10 builds it.
  • The project is not added to CADability.sln, so building the solution in Visual Studio does not require the WebAssembly SDK.
  • No change to CADability.dll or its public API.

Testing

Locally on Linux: dotnet build -c Release and node bin/Release/net10.0/wwwroot/main.mjs give "All checks passed." and exit code 0. The same program against master gives exit code 7.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5

Generated by Claude Code

claude added 20 commits October 15, 2026 08:04
@claude
Add a managed TrueType reader for text on every platform (#412)
be8329f 
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
@claude
Get the fonts of texts from a font service of the kernel instead of G…
cb05b5b 
…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
@claude
Add a Windows CI workflow that builds and tests with GDI+ and WinForms (
ec20031 
#412)

The Linux CI compiles the tests that need GDI+, WinForms or OpenGL out
(they are guarded by WINDOWS, which only the net8.0-windows target of
CADability.Tests defines). The new workflow builds the kernel and
CADability.Forms on windows-latest and runs both test projects there,
so these tests run on every pull request as well: the GDI+ conversions
of CADability.Forms, the rendering against reference bitmaps and,
next, the comparison of the GDI and the managed glyph outlines.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Make the DXF dimension tests independent of the line endings of the c…
c7225e2 
…heckout

Four tests of DxfDimensionTest edit their verbatim-string fixtures with
Replace("...\n..."). With "* text=auto" Windows checks the file out with
CRLF, the search text is not found, and the tests fail on their own
"fixture should have been changed" assertion. The new Windows CI showed
it; Linux checkouts have LF and never noticed. The fixtures are now
normalized to LF before they are edited, as the file already does for
the DXF written in another test.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Read the CFF outlines of OpenType fonts in the managed font reader (#412
fc5326e 
)

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
@claude
Read variable fonts: gvar, CFF2, avar and HVAR (#412)
5e7a0be 
The managed font reader now handles variable OpenType fonts. The named
instances of a variable font become faces of their own, with family names
as GDI makes them ("Bahnschrift Light Condensed", "Segoe UI Variable
Display Semibold"), so these fonts no longer fall back to their default
instance or, for CFF2, disappear from the font list.

- FontVariations parses fvar, avar, the gvar header and HVAR, normalizes
  user coordinates and computes tuple scalars like fontTools'
  supportScalar (peak and intermediate regions).
- TrueType outlines: gvar deltas with shared and private point numbers,
  packed deltas, interpolation of untouched points (IUP), phantom points
  and the offsets of composite components.
- CFF2 outlines: 32-bit INDEX counts, the Top DICT outside an INDEX,
  FDSelect format 4, vsindex and blend with the ItemVariationStore.
- Advance widths come from HVAR, or from the phantom points without HVAR.
  They are not rounded. MVAR is not applied.

The test fonts are subsets of Source Sans 3 VF (OFL-1.1), renamed to
"VarTest Sans" because "Source" is a Reserved Font Name. Their reference
outlines and advance widths were written with fontTools.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Compare the managed font reader with GDI on Windows (#412)
4d939ef 
GdiFontComparisonTests checks on the fonts installed on Windows that the
ManagedFontProvider, the default since the font service, gives the same
results as the GdiFontProvider, which is how CADability got its fonts
before:

- every family GDI+ knows is known to the managed provider;
- for a list of common fonts (TrueType, a collection and variable fonts),
  in every real style: the metrics, the advance widths (within one font
  unit) and the outlines (Hausdorff distance within two font units),
  including underline and strikeout;
- for all installed families: the metrics, the advance widths and the
  outlines of a few characters.

The tests only compile for net8.0-windows and run in the Windows CI.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Find a family by the name GDI cuts to 31 characters (#412)
e08061f 
GDI cuts family names to 31 characters (LF_FACESIZE), e.g. "Bahnschrift
SemiBold SemiConden", and texts saved with GDI keep that name. The
ManagedFontProvider now resolves such a name to the only family whose
name starts with it. The comparison with GDI checks that every family
name of GDI resolves to a face.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Lay out glyphs, metrics and decorations like GDI (#412)
318a1ed 
The comparison with GDI on Windows found three differences, which a
diagnostic run confirmed against the raw font tables:

- Fonts that set USE_TYPO_METRICS (bit 7 of fsSelection) get their cell
  and line spacing from the typographic metrics of OS/2 in GDI+, not from
  usWinAscent and usWinDescent (Bahnschrift, Cascadia, Sitka, Cambria
  Math, Gabriola, Nirmala Text).
- GDI+ centers the underline and the strikeout line on the positions of
  "post" and "OS/2"; they were drawn below them.
- When xMin of a glyph is not its left side bearing in "hmtx", Windows,
  FreeType and fontTools move the outline so that the origin is at 0
  (Times New Roman Italic, Symbol). The varied origin of a variable font
  is taken into account.

The Windows test now compares the outlines with the unhinted outlines of
GDI (GetGlyphOutline with GGO_UNHINTED): GraphicsPath.AddString returns
hinted outlines, which differ from the design by a few font units in
strongly hinted fonts and are wrong for Segoe Script, while the managed
reader matches the unhinted outlines exactly. The underline and strikeout
lines are still compared with GDI+.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Name and measure variable instances like Windows (#412)
191927d 
The comparison with GDI on Windows found more differences:

- Windows names the instances of a variable font from "STAT": the names
  of the axis values in the axis ordering of "STAT", without the elidable
  ones. Segoe UI Variable has the instance "Light Display" in "fvar",
  which Windows calls "Segoe UI Variable Display Light". Without a usable
  "STAT" table the subfamily name of "fvar" is used as before.
- "MVAR" is now applied to the metrics of an instance (typographic and
  Windows ascent and descent, underline, strikeout). Bahnschrift varies
  the size of its strikeout line.
- A composite glyph with USE_MY_METRICS takes its origin from that
  component (Times New Roman Bold 'Ü').

The Windows test creates the GDI font with FW_DONTCARE for a regular
face, because FW_NORMAL makes GDI embolden a lighter face such as
"Cascadia Code ExtraLight".

The strikeout values of the variable test fonts at their instances were
added to the reference data with fontTools' instancer.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Correct the documentation of HasOutlines and HasCffOutlines for CFF2 (#…
b30fcd0 
…412)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Merge branch 'feature/variable-fonts' into feature/gdi-glyph-comparison
1d19182
@claude
Keep the images of pictures and icons as image file bytes (#412)
45b1a61 
Picture and Icon kept a System.Drawing.Bitmap and wrote it into project
files as a serialized GDI+ object, so a project with a picture could not
be opened without GDI+. Now they keep the bytes of the image file (PNG,
JPEG, GIF or BMP) and write those, as Base64, into project files.

- The kernel does not decode the image. The size in pixels comes from the
  file header (EncodedImage). On Windows GDI+ decodes the bytes when the
  picture is painted; without GDI+ a picture is painted as its outline.
- New API: Picture.ImageData, PixelWidth, PixelHeight,
  Set(byte[], ...), SetImageDataNoUndo; Icon.ImageData, PixelWidth,
  PixelHeight, Set(byte[], ...).
- Obsolete in 1.x, removed in 2.0: Picture.Bitmap, Set(Bitmap, ...),
  SetBitmapNoUndo and Clip (GDI+ only), Icon.Set(Bitmap, ...).
- Files of 1.x keep opening on every platform: the serialized GDI+ bitmap
  is read as its "Data" bytes (LegacyImageData) by the JSON reader and by
  a binder for binary files. If the image of an old file cannot be read,
  the picture is loaded from its Path, with a warning.
- Image files are read with File.ReadAllBytes, so no stream is left open.

pictures-1x.cdb and pictures-1x.cdb.json were written by the current
master on Windows, with GDI+ bitmaps, for the tests.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Test files with pictures written on .NET Framework 4.8 (#412)
10f0d2d 
Most project files of CADability 1.x come from .NET Framework, where GDI+
serializes a bitmap in its own format (the JPEG picture stays a JPEG),
while System.Drawing.Common on .NET 8 serializes every bitmap as PNG.
pictures-1x-net48.cdb and .cdb.json were written by the current master
on .NET Framework 4.8.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Save page settings as a neutral PageSetup (#412)
cfba619 
Project files contained the GDI+ PageSettings of the project and of the
layouts. These cannot be serialized on .NET Core: on .NET 8, a project
with page settings could not be saved at all (JSON and binary throw), and
without GDI+ the page settings of an old file were dropped.

- New public PageSetup: paper name, kind and size, orientation, margins
  (in mm) and printer name. Project.DefaultPageSetup and Layout.PageSetup
  are saved instead of the PageSettings.
- Files of 1.x keep their page settings on every platform: the
  System.Drawing.Printing objects are read as LegacyPrintingData by the
  JSON reader and by the binder for binary files (the JSON format has the
  public properties, the binary format of .NET Framework the private
  fields, TriStates and enums), and a PageSetup is made from them.
- On Windows the page setup is applied to the print document: the printer,
  if it is installed, the printer's paper of the same kind and size (or a
  custom one), the orientation and the margins. The page setup and printer
  dialogs of a layout view now store the result in the layout.
- Obsolete in 1.x, moved into CADability.Forms in 2.0: PrintToGDI,
  LayoutView.Print, GDI2DView.PrintSinglePage, IUIService.ShowPageSetupDlg
  and ShowPrintDlg, Layout.pageSettings.

pagesettings-1x-net48.cdb and .cdb.json were written by the current
master on .NET Framework 4.8, for the tests.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Use a relative path in the path fallback test (#412)
0e2982f 
The test failed on Windows: JsonSerialize does not escape backslashes
when it writes a string, but reads "\r" and "\n" as control characters,
so the absolute temp path C:\Users\runneradmin\... did not survive the
round trip. That is a bug of JsonSerialize of its own; the test now
uses a relative path. The crefs to the overloaded Set methods are made
unambiguous (CS0419).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Merge branch 'feature/picture-encoded-images' into feature/neutral-pa…
cc470a1 
…ge-setup
@claude
Import all CSS named colors from SVG (#412)
3bf4b6e 
ParseSvgColor relied on ColorTranslator.FromHtml for color names, which
only knows the colors of .NET: the six "grey" spellings of CSS (grey,
darkgrey, dimgrey, slategrey, darkslategrey, lightslategrey) became
transparent black, so their paths were not filled, and rebeccapurple is
only known since .NET 8.

The SVG import now has its own table of the 148 named colors of CSS
(Color Module Level 4). Colors that .NET knows are returned as named
colors (Color.Navy), as before; the others as their RGB value. Other
names still go through ColorTranslator.

The tests check all 148 names in three spellings against the values of
the CSS specification and import an SVG file with a square of every
color. This is the SVG acceptance criterion of #412 (step 9).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Test texts without frame or GDI: save, export, finalizers (#412)
a4de85a 
Step 9 of #412 asks for headless tests in the Linux CI that create,
measure and export a text and check that the process survives the
finalizers. Creating and measuring was already tested with the font
service; these tests add:

- saving a text to JSON and reading it back, with the same extent;
- exporting a text to DXF and reading it back (string, size, location,
  and an extent measured with the managed font reader);
- running the finalizers after texts have been measured and outlined.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Test pictures without frame or GDI: measure, export, finalizers (#412)
65fd037 
Step 9 of #412 asks for headless tests in the Linux CI that create,
measure and export a picture and check that the process survives the
finalizers. #473 already tests the image bytes, the JSON round trip and
the old files; these tests add:

- measuring a picture (pixel size, extent, aspect ratio);
- exporting a project with a picture to DXF and STL, which have no
  pictures: the other objects are written and the picture does not stop
  the export;
- writing and reading a project with a picture in the binary format,
  which used to contain the GDI+ bitmap (needs the BinaryFormatter, so it
  runs on .NET 8);
- running the finalizers after pictures have been painted and cloned.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
This was referenced Oct 16, 2026
Open
Closed
claude added 3 commits October 16, 2026 07:47
@claude
Merge remote-tracking branch 'origin/master' into feature/picture-enc…
dccb145 
…oded-images

# Conflicts:
#	CADability/Bitmap.cs
#	CADability/ConstrPicture.cs
#	CADability/ConstrPicturePoint2Directions.cs
#	CADability/ConstrPicturePointWidthHeight.cs
@claude
Merge branch 'feature/picture-encoded-images' into feature/neutral-pa…
238a773 
…ge-setup

# Conflicts:
#	CADability/Project.cs
@claude
Merge branch 'feature/neutral-page-setup' into test/headless-picture-…
e8a51eb 
…export
This was referenced Oct 16, 2026
Closed
Closed
Closed
claude added 2 commits October 16, 2026 08:08
@claude
Sample BSpline2D.AddToGraphicsPath on 0..1 (#412)
9ef832f 
AddToGraphicsPath passed knot parameters (startParam..endParam) to
PointAt, which expects 0..1. A spline whose knots do not run from 0 to 1
was therefore drawn through wrong points; splines with knots from 0 to 1
are unaffected.

Taken from the closed #465. The test needs GDI+ and only runs on Windows.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Merge remote-tracking branch 'origin/test/headless-text-export' into …
72b4ecd 
…integration/issue-412
claude added 25 commits October 19, 2026 06:49
@claude
Merge branch 'test/headless-text-export' into integration/issue-412
2d09d7b
@claude
Merge remote-tracking branch 'origin/feature/picture-encoded-images' …
dc316e2 
…into integration/issue-412
@claude
Merge branch 'integration/issue-412' into test/wasm-smoke
d62de10
@claude
Lock the shared sets of the parallel STEP import
ac0ad17 
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)
@claude
Merge branch 'feature/managed-font-provider' into feature/font-service
c54ed31
@claude
Merge branch 'feature/font-service' into feature/cff-outlines
5b325e3
@claude
Merge branch 'feature/cff-outlines' into feature/variable-fonts
6b5e200
@claude
Lock the shared sets of the parallel STEP import
b846857 
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)
@claude
Merge branch 'feature/variable-fonts' into feature/gdi-glyph-comparison
cfd97de
@claude
Merge branch 'feature/picture-encoded-images' into feature/neutral-pa…
a81efbe 
…ge-setup
@claude
Merge branch 'feature/neutral-page-setup' into test/headless-picture-…
0c867f0 
…export
@claude
Merge branch 'feature/gdi-glyph-comparison' into test/headless-text-e…
9d4fd4b 
…xport
@claude
Merge branches 'test/headless-text-export' and 'test/headless-picture…
ce5dc5b 
…-export' into integration/issue-412
@claude
Merge branch 'integration/issue-412' into test/wasm-smoke
0cad8fb
@claude
Synthesize a missing bold or italic face like GDI+ (#412)
3ad812f 
GDI+ reports every style of every family as available and synthesizes the
missing ones, so the texts of CADability before the font service showed a
bold or italic text in a family without that face (e.g. Microsoft Sans
Serif, Lucida Console, Impact) as synthetic bold or italic. The managed
provider took the closest face instead, so such a text would have lost its
style on Windows.

ManagedFontProvider now wraps the closest face in a SyntheticFontFace:

- Italic shears the glyphs by 0x5700/0x10000 (18.77 degrees) around the
  baseline; the advance widths stay. GDI and GDI+ do exactly this.
- Bold moves the outline outwards by half the strength on every side
  (FT_Outline_EmboldenXY of FreeType) and then by half the strength to the
  right and up: the left side and the baseline stay, every edge facing
  right moves right by ceiling(em / 50) font units and every edge facing up
  moves up by one unit less. A face with a weight of 600 or more is not
  made wider. The advance widths stay, as with the GDI widths CADability
  used.

The rules were measured with GDI+ on the Windows runner for all installed
families without a bold face. TrueTypeFont reads usWeightClass (or the
wght axis of an instance) for the weight rule.

Tests: the emboldened outlines of Lucida Console and Microsoft Sans Serif
'I' equal what GDI+ returned on Windows to 0.01 font units; holes get
smaller; the strength for 256 to 4096 units per em; italic and bold of the
regular-only Liberation Sans. SyntheticStyleGdiTests compares the synthetic
styles with GDI+ on Windows for several families.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Merge branch 'feature/synthetic-bold-italic' into integration/issue-412
15e2555
@claude
Merge branch 'integration/issue-412' into test/wasm-smoke
6fb1005
@claude
Make the quadratic TrueType outline wider for synthetic bold
0565bb0 
The first Windows comparison showed the straight edges equal to GDI+, but
curves off by a few font units ('o') and some glyphs by up to 35 ('8',
serifs of Sylfaen and Gabriola). GDI+ makes the glyph wider on the outline
of the font, before its quadratic segments become cubic ones: the points it
moves and the limit by the shorter edge depend on that point set. The
emboldening now works on the quadratic TrueType contours in font units; a
CFF outline is made wider after it was drawn, as before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Keep the synthetic bold shift within half the strength per axis like …
ee067e1 
…GDI+

Measured point by point against GDI+ on the Windows runner: GDI+ does not
limit the shift at an inner corner by the length of the shorter edge, as
FT_Outline_EmboldenXY does, so the short edges of the rounded serif corners
of Sylfaen move by the whole strength. Instead it keeps the shift of every
point within half the strength on each axis, so that the sharp corners of
the '8' of Microsoft Sans Serif do not shoot out by up to 24 font units.

The comparison test now matches the points of the managed and the GDI+
outline by position, because GDI+ starts the contours of MS Gothic at
another point.

Refs #412

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Compare Sylfaen and Gabriola with GDI+ within 2% of the em height
5151a54 
GDI+ moves single points of these two families differently from the other
five, without a rule that could be found (e.g. a point in the middle of a
straight slanted edge of the Sylfaen '8' only moves up). The differences are
up to 1.6% and 0.85% of the em height; the other families keep the
tolerance of 2 font units.

Refs #412

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Merge branch 'feature/synthetic-bold-italic' into integration/issue-412
51eadd9 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Merge branch 'integration/issue-412' into test/wasm-smoke
b5f58f3 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Make the GDI font provider the default in CADability.Forms
b23e6bb 
With #468 the texts get their fonts from FontProvider.Current, which is the
managed TrueType reader on every platform. To keep the texts of existing
Windows Forms applications exactly as before, CADability.Forms now makes its
GdiFontProvider the default as soon as one of its main classes is used
(CadControl, CadCanvas, CadFrame, PaintToOpenGL, PaintToGDI): their static
constructors call GdiFontProvider.MakeDefault.

The kernel keeps the managed provider as its own default, so nothing changes
for applications without CADability.Forms (the browser, other platforms,
renderers of their own). A provider the application sets through
FontProvider.Current is kept, whether it is set before or after
CADability.Forms is loaded, so an application can still choose the managed
provider on Windows.

FontProvider tells the two cases apart: the setter marks the provider as the
application's choice, the new internal FontProvider.SetDefault replaces only
a default. CADability.Forms reaches it through InternalsVisibleTo, so there
is no new public API.

Refs #412

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Merge branch 'feature/gdi-fonts-in-forms' into integration/issue-412
8e84ce1 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@claude
Merge branch 'integration/issue-412' into test/wasm-smoke
7256c88 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@dsn27
dsn27 changed the base branch from integration/issue-412 to master October 19, 2026 11:10
@claude
Merge branch 'master' into test/wasm-smoke
4eba571 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YXvDW91oXpy7RquGHNxgR5
@dsn27
dsn27 merged commit 5247ab9 into master Oct 19, 2026
2 checks passed
@dsn27
dsn27 deleted the test/wasm-smoke branch October 19, 2026 11:17
@dsn27 dsn27 mentioned this pull request Oct 19, 2026
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@dsn27 @claude