DOSSIER-STANDALONE/docs/design/engine-linewidth-audit.md

Engine-Nordstern 1 — Strichbreiten-Audit (Papier-mm end-to-end)

Bezug: HANDOVER.md, Abschnitt ENGINE-NORDSTERN Punkt 1 ("Papier-mm-exakte Strichbreiten überall — Bildschirm bei jedem Massstab/Zoom = Druck"). Dieses Dokument ist ein Prüfbericht, kein Umbau — es fasst zusammen, wie die Strichbreite heute vom Modell bis zum Papier läuft, wo sie divergieren kann, und was konkret zu tun wäre. Nichts hieraus wurde umgesetzt.

Betroffene Pfade: src/plan/PlanView.tsx (SVG-Default + Print-Vorschau), src/plan/glPlan/* (WebGL2, aktueller Default-GPU-Pfad), src-tauri/render2d (WASM/WebGPU, ?engine=wasm), src/export/sceneToPrintSvg.ts + src/export/exportPdf.ts (Vektor-PDF). Referenz-Baseline für die 2D-Engine-Parität ist laut Commit ce6bd26 ?gl=0 (reiner SVG-Pfad) — NICHT der App-Default (der ist WebGL2, siehe Finding 1).

1. Modell der Wahrheit

So sollte eine Strichbreite in diesem Code korrekt fliessen:

1. Quelle: generatePlan.ts legt jede Strichbreite als weightMm / strokeWidthMm in echten Papier-Millimetern ab (Kommentarkopf, generatePlan.ts:76-79: "Alle Stricharten sind in mm Papier definiert"). Diese Zahl ist unabhängig von Zoom, Massstab und Render-Pfad — eine 0.18 mm Wand-Umrisslinie bleibt 0.18 mm, ganz gleich wo sie später landet.
2. Bildschirm bei Massstab 1:N: 1 Modell-Meter entspricht auf Papier 1000/N mm. Der Bildschirm zeigt PX_PER_M = 90 viewBox-Einheiten je Modell-Meter (PlanView.tsx:23). Eine mm-Breite belegt daher mm · N/1000 · PX_PER_M viewBox-Einheiten — das ist exakt printStrokeVb() (PlanView.tsx:2598-2600). Multipliziert mit der Geräte-px-je-viewBox-Einheit-Skala (meet, PlanView.tsx:2074-2078) ergibt das die tatsächliche Bildschirmbreite in Geräte-Pixeln. Reinzoomen (kleinere viewBox-Breite, grösseres meet) macht die Linie dicker — genau wie beim Herausvergrössern eines gedruckten Plans mit der Lupe. Das gilt für JEDE Zoomstufe gleichermassen: 250 % Zoom bei 1:50 zeigt exakt die 5-fache Pixelbreite von 100 % Zoom bei 1:50, und bei gegebenem Zoom ist 1:50 exakt doppelt so dick wie 1:100 (halber Nenner → doppelt so viele Weltmeter je Papiermm).
3. Druck/PDF: dieselbe Formel, nur ohne Geräte-px-Zwischenschritt — direkt mm bleibt mm — die Seite ist direkt in echten Papiermillimetern aufgespannt (sceneToPrintSvg.ts:99-125). Zusätzlich wird auf ISO-nahe Stiftstufen gerundet (PEN_STEPS, sceneToPrintSvg.ts:44), weil ein reales Zeichengerät/Plotter nur endlich viele Stiftbreiten kennt.
4. Eine Wahrheit: Seit 382771b bauen sowohl der Viewport (useWasmPlanRenderer.ts/nativeSync.ts) als auch der PDF-Export (exportPdf.ts:73) dieselbe planToRenderScene(plan)-Szene — der PDF-Pfad ist nur ein anderes Ziel derselben Szene, kein zweiter Interpret.

Korrekt hiesse also: jede der vier Anzeige-/Exportarten (SVG-Default, SVG-Print-Vorschau, GPU-Viewport, PDF) muss aus derselben weightMm, für denselben N, exakt dieselbe Papier-mm-Breite ergeben — bis auf die bewusste PEN_STEPS-Rundung im Druckpfad, die dokumentiert und überall gleichermassen sichtbar sein sollte (ist sie nicht, siehe Finding 2).

Ausdrücklich kein Teil dieses Modells: der Haarlinien-Modus (lineMode: "display", App-Default, viewSlice.ts:38,74). Er ist als bewusster Papier-mm-Ausstieg gedacht ("Display: all lines as constant hairlines (calm editing)", en.ts:173) — 1 Geräte-px, konstant, unabhängig von Zoom/Massstab. Er muss also NICHT der Papier-mm-Formel folgen, aber er muss in JEDEM Render-Pfad gleichermassen als Ausstieg wirken. Tut er nicht (Finding 1).

2. Pfad-für-Pfad-Trace

2a. SVG-Default (App-Start ohne ?gl=0, lineMode:"display")

Nur aktiv, wenn WebGL2 fehlschlägt (wantGl ist sonst true, s. Finding 1) — de facto der reine Fallback-Pfad.

• PlanView.tsx:2613: print = !hairline && paperScale != null && paperScale > 0 — mit hairline=true (Default) ist print immer false.
• PlanView.tsx:2617-2618:

  const weight = (mm: number): number =>
    hairline ? HAIRLINE_PX : print ? printStrokeVb(mm, paperScale!) : mmToPx(mm);
  

  HAIRLINE_PX = 1 (PlanView.tsx:2583), Einheit: Geräte-unabhängiger CSS-Pixel, gezeichnet mit vector-effect="non-scaling-stroke" (PlanView.tsx:2621, vfx) → bleibt beim Pan/Zoom optisch exakt 1 px, egal wie stark reingezoomt wird. Papier-mm spielt hier explizit KEINE Rolle.

2b. SVG-Print-Vorschau (lineMode:"print", weiterhin ?gl=0 oder

WebGL2-Fallback)

• print = true, weight(mm) = printStrokeVb(mm, paperScale!) (PlanView.tsx:2598-2600):

  function printStrokeVb(mm: number, n: number): number {
    return Math.max(1e-4, (mm * n) / 1000) * PX_PER_M;
  }
  

  vectorEffect entfällt (vfx = undefined, PlanView.tsx:2621) — die Linie skaliert MIT der Geometrie beim Zoomen, wie physisches Papier unter der Lupe. paperScale selbst ist der stabile, gemessene 1:N-Nenner (PlanView.tsx:458-460), nicht der live aus jedem Radzoom abgeleitete Wert — sonst würde Reinzoomen die Linien nicht dicker, sondern konstant halten (das wäre wieder Haarlinien-Verhalten). Keine PEN_STEPS-Rundung — die rohe mm-Zahl wird 1:1 in viewBox-Einheiten übersetzt.

2c. GPU-Viewport (WebGL2 useGlPlanRenderer.ts — App-DEFAULT; WASM

useWasmPlanRenderer.ts bei ?engine=wasm)

• Beide Hooks reichen paperScaleN unverändert an die Engine durch: useWasmPlanRenderer.ts:131-149 (render(viewBox, paperScaleN=100, textScaleN=100) → r.set_paper_scale(paperScaleN)); WebGL2 analog (useGlPlanRenderer.ts:102-116, kein textScaleN-Parameter überhaupt, s. Finding 3).
• PlanView.tsx ruft in JEDEM Render-Aufruf (PlanView.tsx:494,502,1080) renderGl(view, paperScaleForGl(view), textScaleForGl()). paperScaleForGl (PlanView.tsx:475-476):

  const paperScaleForGl = (v: ViewBox): number =>
    paperScaleRef.current ?? scaleFromView(v, svgRef.current) ?? 100;
  

  Kein hairline-Zweig. Egal ob lineMode "display" oder "print" ist, hier kommt immer ein echter 1:N-Papier-Nenner heraus.
• Rust-Seite (gpu.rs:606-616):

  let mm_px = mm_to_device_px(view_box, vw, vh, self.paper_scale_n);
  

  mm_to_device_px (ortho.rs:96-99) reproduziert exakt printStrokeVb: (paper_scale_n/1000.0) * PX_PER_M * meet — PX_PER_M = 90.0 (tessellate.rs:22, identisch zu TS). Die reine Mathematik ist also deckungsgleich zum SVG-Print-Pfad (2b) — aber sie läuft immer, auch wenn der Nutzer "Display: Haarlinien" gewählt hat. Siehe Finding 1.
• Stiftbreite pro Batch im Shader (shaders.rs:91, LINE_WGSL): width_px = max(0.6, stroke_px * stroke_scale) * miter — harte Untergrenze 0.6 Geräte-px, die weder die SVG- noch die PDF-Seite kennt (Finding 6). Identische Formel für Bögen (shaders.rs:209, ARC_WGSL) und im WebGL2-Pfad (glPlanRender.ts:243-249, Kommentar "klemmt bei ~0.6 px").
• Schraffur-Musterlinien laufen NICHT über mm_px, sondern über width_screen/px_per_screen (gpu.rs:661-665): Geräte-px = Breite × meet-Skala statt × mm→px — bewusst zoom-skalierend wie das SVG-<pattern>, nicht papierkonstant (s. toRenderScene.ts:371-375, Finding 4).

2d. Vektor-PDF (exportPdf.ts → sceneToPrintSvg.ts)

• exportPdf.ts:73: const scene = planToRenderScene(plan); — dieselbe Szene wie 2c, unabhängig vom aktuell gewählten lineMode der Ansicht.
• sceneToPrintSvg.ts:243-244:

  const effectiveMm = widthScreen ? (widthMm / PX_PER_M) * mmPerM : widthMm;
  const strokeMm = quantizePen(effectiveMm);
  

  PEN_STEPS = [0.13, 0.18, 0.25, 0.35, 0.5, 0.7, 1.0], MIN_PEN_MM = 0.13 (sceneToPrintSvg.ts:44,47). JEDE Linie/Umriss/Bogen/Schraffur wird auf die nächsthöhere Stufe gerundet, bevor sie ins SVG/PDF geht (sceneToPrintSvg.ts:251,274,301). Das ist der EINZIGE der vier Pfade, der überhaupt quantisiert.
• widthScreen-Konvertierung: widthMm (hier eigentlich viewBox-Einheiten, siehe 2c) wird über /PX_PER_M * mmPerM zurück in Weltmeter und dann in Papier-mm beim GEWÄHLTEN opts.scaleDenominator übersetzt — nicht beim Massstab, den die Live-Ansicht gerade zeigt (Finding 4).
• Text: sizeMm kommt unverändert aus RText.sizeMm (sceneToPrintSvg.ts:325, t.sizeMm, keine Nachskalierung) — aber die VERTIKALE Zeilenposition dieser Texte wurde in toRenderScene.ts mit einem festen STAMP_REF_N = 100 in Weltmeter umgerechnet (toRenderScene.ts:163-165, 481-483), unabhängig vom tatsächlich gewählten Export-N (Finding 3).

3. Findings (nach Schwere geordnet)

1. Haarlinien-Modus (App-Default) wird vom GPU-Renderer komplett ignoriert — betrifft den Standard-Zustand der App

lineMode startet auf "display" (viewSlice.ts:74), und WebGL2 ist der Default-Renderer (wantGl ist true, ausser ?gl=0, PlanView.tsx:433-437) — d. h. im frisch geladenen, unkonfigurierten App- Zustand rendert bereits der GPU-Pfad, und die "Display: Haarlinien"-Option tut nichts. paperScaleForGl (PlanView.tsx:475-476) liest nur paperScaleRef.current ?? scaleFromView(...) ?? 100 — der hairline-Boolean aus den Props (PlanView.tsx:2571) wird an dieser Stelle nie geprüft, obwohl das benachbarte textScaleForGl (PlanView.tsx:485-488) exakt diesen Zweig korrekt hat:

const textScaleForGl = (): number => {
  const print = !hairline && paperScale != null && paperScale > 0;
  return print ? paperScale! : 100;
};

Ergebnis: Text (Raumstempel) fällt im Haarlinien-Modus korrekt auf die Referenzskala 100 zurück, aber jede Wand-/Tür-/2D-Zeichenlinie wird trotzdem mit dem echten (gemessenen oder geschätzten) paperScale gezeichnet — sie wird beim Reinzoomen dicker statt konstant zu bleiben, exakt das Gegenteil dessen, was der Menüpunkt verspricht ("calm editing", en.ts:173). Der Bug betrifft sowohl useGlPlanRenderer.ts (Default) als auch useWasmPlanRenderer.ts (?engine=wasm) — keiner der beiden render()- Aufrufe kennt einen hairline-Parameter überhaupt.

2. PEN_STEPS-Quantisierung existiert NUR im PDF-Export — beide Live-Vorschauen (SVG-Print und GPU) zeigen unquantisierte Rohwerte

Konkret, mit den tatsächlichen Konstanten aus generatePlan.ts:

• LAYER_LINE_MM = 0.13 (generatePlan.ts:82), LAYER_DETAIL_FACTOR.fein = 0.7 (generatePlan.ts:90-93) → Schichtfuge im Detailgrad "fein": 0.13 · 0.7 = 0.091 mm (generatePlan.ts:1022, strokeWidthMm: LAYER_LINE_MM * LAYER_DETAIL_FACTOR[detail]). Die Bildschirm-Print-Vorschau zeigt genau diese 0.091 mm (printStrokeVb(0.091, N)); der PDF-Export klemmt via quantizePen auf MIN_PEN_MM = 0.13 mm — +43 % dicker im Druck als in der Vorschau.
• Türschwenkbogen: doorLwMm * 0.6 (generatePlan.ts:902) mit dem üblichen Fallback doorLwMm = LAYER_LINE_MM = 0.13 (generatePlan.ts:354) ergibt 0.078 mm. Screen zeigt 0.078 mm (nahezu unsichtbar dünn bei kleinen Massstäben), PDF klemmt auf 0.13 mm — +67 %.
• Wand-Umriss im Detailgrad "grob": outlineMm = wallLwMm · OUTLINE_DETAIL_FACTOR.grob (1.6) (generatePlan.ts:84-88, 648, 796); beim häufigen Fallback WALL_FALLBACK_MM = 0.18 (generatePlan.ts:97) ergibt das 0.288 mm. quantizePen(0.288) rundet auf die nächste Stufe 0.35 (PEN_STEPS, da 0.25 < 0.288 ≤ 0.35) — +21.5 % im Druck.

Das systematische Muster: der Detailgrad "fein" existiert explizit, um Nebenlinien DÜNNER zu machen (generatePlan.ts:52-58, LAYER_DETAIL_FACTOR.fein = 0.7) — aber sobald der berechnete Wert unter MIN_PEN_MM fällt, hebt die PDF-Quantisierung ihn wieder auf die Untergrenze an, ohne dass die Bildschirm-Vorschau (weder SVG-Print noch GPU) davon irgendetwas zeigt. Wer die Druckvorschau am Bildschirm beurteilt, sieht NICHT, was tatsächlich gedruckt wird.

3. Stempel-Zeilenabstand ist nur bei Massstab 1:100 exakt — SVG- und RenderScene-Pfad nutzen zwei verschiedene Formeln für dieselbe Grösse

Bereits als bekannte Alt-Lücke in HANDOVER.md (Commit 382771b, Punkt 6) vermerkt; hier präzise verortet:

• SVG (PlanView.tsx:2738-2739):

  const nRef = print ? paperScale! : 100;
  const unitPerPt = (1 / 72) * 0.0254 * nRef * PX_PER_M;
  

  nRef folgt im Druckmodus dem TATSÄCHLICH aktiven paperScale — der Zeilenabstand (lineGap = baseFs * 1.3, PlanView.tsx:2741) ist für jedes N korrekt in viewBox-Einheiten, weil er direkt aus unitPerPt (das N enthält) abgeleitet wird.
• RenderScene (toRenderScene.ts:163-165):

  const STAMP_REF_N = 100;
  const MM_TO_M = STAMP_REF_N / 1000;
  

  und (toRenderScene.ts:481-483):

  const baseH = baseMm * MM_TO_M; // Basisgröße in Modell-Metern
  const lineGap = baseH * 1.3;
  

  Hier ist der Umrechnungsfaktor MM_TO_M FEST auf N = 100 verdrahtet, unabhängig davon, mit welchem N der WASM-Viewport oder der PDF-Export tatsächlich rendert (paper_scale_n in gpu.rs, opts.scaleDenominator in sceneToPrintSvg.ts). Bei N = 100 sind beide Formeln identisch (das war offenbar der Verifikationsfall in 382771b); bei jedem anderen N — z. B. 1:50 — driftet der vertikale Zeilenabstand der Stempel-Mehrzeiler proportional zum Verhältnis N_wahr/100 auseinander, während die einzelne Zeilenhöhe (sizeMm) selbst korrekt bleibt. Betroffen: WASM-Viewport (2c) UND PDF-Export (2d) gleichermassen (beide beziehen RText aus derselben toRenderScene-Funktion); die WebGL2-Ansicht ist NICHT betroffen, weil sie Text grundsätzlich nicht selbst zeichnet, sondern die SVG-Overlay-Ebene weiterverwendet (PlanView.tsx:1592, useGpuRenderer ? wantWasm || p.kind !== "text" : ... — bei WebGL2 (wantWasm=false) werden Text-Primitive NIE aus dem SVG-Rendering herausgefiltert).

4. Schraffur-Strichbreite im PDF hängt vom GEWÄHLTEN Export-Massstab ab, nicht vom Massstab der Live-Vorschau

hatchPx wird in toRenderScene.ts:374-375 genau einmal, massstabsunabhängig berechnet:

const hatchMm = p.hatch.lineWeight > 0 ? p.hatch.lineWeight : 0.13;
const hatchPx = Math.max(0.6, hatchMm * (1 / 0.13));

— eine reine viewBox-Grösse (analog zum SVG-<pattern>-Strich, der absichtlich mit dem Zoom mitskaliert, damit die Schraffur bei jedem Zoom gleich dicht aussieht: Kommentar toRenderScene.ts:371-373). Erst beim Export wird daraus in sceneToPrintSvg.ts:243 effectiveMm = (widthMm / PX_PER_M) * mmPerM — und mmPerM = 1000 / opts.scaleDenominator (sceneToPrintSvg.ts:101) verwendet den vom Export-Dialog gewählten Massstab, NICHT den paperScale, den der Nutzer gerade in der "Print"-Live-Vorschau sieht (exportPdf.ts ruft sceneToPrintSvg mit opts.scaleDenominator aus den Export-Optionen, exportPdf.ts:61-79, völlig unabhängig vom PlanView-State).

Beispiel: lineWeight = 0.13 mm (Standard-Fuge, getHatch-Default) → hatchPx = max(0.6, 0.13 · (1/0.13)) = 1.0 viewBox-Einheiten.

• Export bei 1:50 (mmPerM = 20): effectiveMm = (1.0/90)·20 = 0.222 mm → quantizePen → 0.25 mm.
• Export bei 1:200 (mmPerM = 5): effectiveMm = (1.0/90)·5 = 0.056 mm → auf MIN_PEN_MM geklemmt → 0.13 mm.

Fast die doppelte Strichstärke allein durch die Wahl des Export-Massstabs, bei UNVERÄNDERTER Quell-lineWeight — und ohne dass die Bildschirm- "Print"-Vorschau (die ja mit dem live gemessenen paperScale arbeitet, nicht mit opts.scaleDenominator) das anzeigen könnte, solange beide Werte nicht zufällig übereinstimmen.

5. Dieselbe Formel existiert vierfach, nur durch Kommentare (nicht durch Typen/Code) synchron gehalten

PX_PER_M = 90 ist unabhängig deklariert in: PlanView.tsx:23 (SVG), glPlan/glPlanRender.ts:12 (WebGL2), tessellate.rs:22 (Rust, geteilt zwischen WASM-Viewport und Headless/Golden-Test) und sceneToPrintSvg.ts:64 (PDF-Serializer, mit explizitem Kommentar "MUSS mit dem dortigen uebereinstimmen, sonst driftet die Schraffur-Dichte des PDFs vom Viewport ab", sceneToPrintSvg.ts:61-62). Die Hatch-Dichte-Formel Math.max(0.6, weightMm · (1/0.13)) ist separat dupliziert in PlanView.tsx:2344-2345 (hatchStrokePx, SVG-<pattern>) und toRenderScene.ts:375 (hatchPx, GPU + PDF) — beide mit demselben "magischen" Faktor 1/0.13, ohne gemeinsame Konstante. Aktuell sind alle vier Kopien konsistent; das Risiko ist rein prospektiv (nächste Tuning-Änderung an einer Stelle vergisst die anderen drei) — aber genau das ist der Mechanismus, über den Findings wie 1-4 überhaupt erst entstehen können, ohne dass ein Typfehler oder Test anschlägt.

6. Drei unabhängige, nicht aufeinander abgestimmte Mindestbreiten-Politiken

• SVG-Print: Math.max(1e-4, ...) (PlanView.tsx:2599) — praktisch keine Untergrenze, verlässt sich auf das Antialiasing des Browsers.
• GPU (WebGL2 UND WASM, Linien UND Bögen): harter Floor von 0.6 Geräte-Pixel (shaders.rs:91,209; glPlanRender.ts:243-249, Kommentar "klemmt bei ~0.6 px").
• PDF: MIN_PEN_MM = 0.13 mm (sceneToPrintSvg.ts:38 in planToPrintSvg.ts, äquivalent sceneToPrintSvg.ts:47) — eine Papier-mm-Grösse, kein Pixelwert, konzeptionell etwas anderes als die GPU-Pixel-Untergrenze.

Auswirkung: bei sehr kleinem Massstab (weit rausgezoomt oder grosses N, z. B. Übersichtsplan 1:500) hält der GPU-Pfad sehr dünne Linien künstlich bei 0.6 px sichtbar, während dieselbe Linie im SVG-Pfad fast verschwindet und im PDF auf eine ganz andere (mm-basierte, massstabsabhängige) Grösse geklemmt wird. Kein Pfad kennt die Politik der anderen beiden. Niedrigere Priorität als 1-4, weil hier keine der drei Politiken die exportierte Papier-mm-Wahrheit verändert (die bleibt PDF-exklusiv über MIN_PEN_MM) — es geht nur um Bildschirm-Konsistenz zwischen SVG/GPU bei Extremzoom.

7. Toter Zweitpfad planToPrintSvg.ts dupliziert PEN_STEPS/mm-Logik komplett, unbenutzt aber vorhanden

src/export/planToPrintSvg.ts trägt seit 382771b einen Kopfkommentar "ERSETZT durch sceneToPrintSvg.ts … wird vom PDF-Export NICHT MEHR verwendet" (planToPrintSvg.ts:1-6) und ist tatsächlich nirgends mehr importiert (verifiziert per Grep über src/). Er enthält jedoch weiterhin eine eigene, unabhängige Kopie von PEN_STEPS/MIN_PEN_MM/quantizePen (planToPrintSvg.ts:35,38,40-45) und einer kompletten Plan→SVG-Serialisierung inkl. eigener PX_PER_M-Handhabung (planToPrintSvg.ts:326). Kein aktiver Bug, aber eine Falle: Copy-Paste-Wiederverwendung dieses Altpfads (z. B. für einen zukünftigen DXF/PNG-Export) würde eine dritte, potenziell abweichende Quantisierungs-Tabelle in den Baum ziehen.

4. Vorgeschlagene Fixes

zu Finding 1 (Haarlinien-Modus im GPU-Pfad)

Kleinste, korrekte Lösung: den hairline-Zustand als eigenen Parameter bis in den Shader durchreichen, analog zu paper_scale_n/text_scale_n.

• Rust (src-tauri/render2d/src/gpu.rs): neues Feld pub hairline: bool auf Renderer (Default false, neben paper_scale_n bei gpu.rs:422). In Renderer::render (gpu.rs:606-616): wenn self.hairline, mm_px NICHT aus mm_to_device_px(...) berechnen, sondern auf einen konstanten Geräte-px-Wert setzen (z. B. 1.0), UND dafür sorgen, dass der Shader width_mm in diesem Fall ignoriert (sonst bleibt die RELATIVE Differenz zwischen z. B. 0.13 mm und 0.35 mm bestehen, nur global skaliert — nicht das gewünschte "alle Linien exakt 1 px"). Sauberster Weg: ein neues hairline: u32-Feld in die pro-Frame-Uniform (Globals, shaders.rs:20-23 und ArcGlobals), im Fragment-/Vertex-Shader (shaders.rs:91, LINE_WGSL; shaders.rs:209, ARC_WGSL) per select(...) auf einen festen 1.0-px-Wert umschalten statt max(0.6, stroke_px * stroke_scale).
• src-tauri/render2d/src/web.rs: neue Methode set_hairline(&mut self, on: bool) neben set_paper_scale/set_text_scale (web.rs:146-155-Nachbarschaft).
• src/plan/useWasmPlanRenderer.ts: render() (useWasmPlanRenderer.ts:131-155) um einen hairline: boolean-Parameter erweitern, r.set_hairline(hairline) vor r.render() aufrufen.
• src/plan/useGlPlanRenderer.ts: analog — render() (Signatur aktuell (viewBox, paperScaleN=100)) um hairline erweitern; im WebGL2-Shader-Uniform-Pfad (glPlanRender.ts:159-165,213-215) mmToDevicePx bei hairline===true durch einen konstanten Wert ersetzen und im Fragment-Shader denselben select-Trick wie oben anwenden (glPlanShaders.ts, dort wo "~0.6 px"-Klemmung passiert, siehe Finding 6).
• src/plan/PlanView.tsx: paperScaleForGl (PlanView.tsx:475-476) bleibt wie sie ist (wird weiter für den Massstab-Nenner gebraucht, sobald der Nutzer zurück auf "Print" schaltet); stattdessen an allen drei renderGl(...)-Aufrufstellen (PlanView.tsx:494,502,1080) zusätzlich hairline durchreichen: renderGl(view, paperScaleForGl(view), textScaleForGl(), hairline).

zu Finding 2 (PEN_STEPS nur im PDF)

Zwei mögliche Richtungen, je nach gewünschtem Produktverhalten:

• Option A (Vorschau matcht Druck): quantizePen (sceneToPrintSvg.ts:50-54) in ein gemeinsames Modul auslagern (z. B. src/plan/penSteps.ts, exportiert PEN_STEPS, MIN_PEN_MM, quantizePen), von sceneToPrintSvg.ts UND von PlanView.tsx (printStrokeVb, PlanView.tsx:2598-2600) importieren und dort ebenfalls anwenden: printStrokeVb(mm, n) = Math.max(1e-4, (quantizePen(mm) * n) / 1000) * PX_PER_M. Für den GPU-Pfad müsste die Quantisierung dann VOR dem Scene-Bau passieren (in toRenderScene.ts, auf widthMm jeder RLine/ROutline/RPolyline/RArc, ausgenommen widthScreen-Einträge), damit WASM/WebGL2-Viewport dieselben Stufen zeigen wie SVG und PDF.
• Option B (Vorschau bleibt Rohgrösse, aber sichtbar gemacht): falls die feinkörnige Vorschau bewusst erhalten bleiben soll, zumindest den Stiftstufen-Sprung an der Stelle sichtbar machen, an der die Detailgrad- Faktoren definiert werden (generatePlan.ts:84-93) — z. B. ein Entwickler-/Lint-Test, der bei jedem OUTLINE_DETAIL_FACTOR/ LAYER_DETAIL_FACTOR-Wert prüft, ob das Produkt mit den üblichen Fallback-weightMm-Werten (WALL_FALLBACK_MM, LAYER_LINE_MM) exakt auf einer PEN_STEPS-Stufe landet, und sonst warnt.

Empfehlung: Option A — sie erfüllt den Nordstern wörtlich ("Bildschirm bei jedem Massstab = Druck").

zu Finding 3 (STAMP_REF_N)

In toRenderScene.ts STAMP_REF_N = 100 (toRenderScene.ts:163) durch den tatsächlichen Ziel-Massstab ersetzen. planToRenderScene(plan) kennt aktuell keinen N-Parameter (exportPdf.ts:73 ruft es ohne Massstabsangabe auf) — die Funktion müsste ein optionales paperScaleN-Argument bekommen (Default 100, um den Viewport-Aufruf ohne Massstabskontext — nativeSync.ts — nicht zu brechen, dort ist 100 ohnehin die richtige Referenz für den WASM-Viewport im Anzeigemodus, s. gpu.rs:422), und exportPdf.ts:73 müsste planToRenderScene(plan, opts.scaleDenominator) aufrufen. MM_TO_M (toRenderScene.ts:165) dann aus diesem Parameter statt aus der Konstante ableiten.

zu Finding 4 (Hatch-mm im PDF folgt dem Export-N, nicht dem Vorschau-N)

Kein Bug im engeren Sinn (die Formel ist in sich konsistent — die Schraffur soll ja pro gewähltem Blatt-Massstab eine sinnvolle Dichte haben), aber die Bildschirm-„Print"-Vorschau sollte denselben N verwenden, den der Export-Dialog tatsächlich benutzen wird, sonst lügt die Vorschau. Fix: paperScale in PlanView.tsx beim Öffnen des Export-Dialogs (bzw. der Export-Dialog selbst) mit opts.scaleDenominator vorbelegen/synchronisieren, statt zwei unabhängige State-Quellen zu pflegen — Ort: dort, wo der Export-Dialog scaleDenominator initialisiert (App.tsx, PDF-Export-UI) einen Default aus paperScale/liveScale (App.tsx, onScale-Callback, PlanView.tsx:794) übernehmen.

zu Finding 5 (vierfache Formel-Duplikation)

Eine gemeinsame TS-Konstantendatei src/plan/renderConstants.ts mit PX_PER_M = 90, HATCH_DENSITY_FACTOR = 1/0.13, HATCH_MIN_PX = 0.6 anlegen; PlanView.tsx, glPlan/glPlanRender.ts, toRenderScene.ts, sceneToPrintSvg.ts importieren daraus statt eigener Literale. Für die Rust-Seite (tessellate.rs:22, shaders.rs:142) ist echtes Teilen über die Sprachgrenze hinweg nicht trivial — dort bleibt nur ein Kommentar-Link auf die TS-Konstante plus ein Parity-Test (siehe Abschnitt 5), der bei Abweichung fehlschlägt statt bei stillem Drift.

zu Finding 6 (drei Mindestbreiten-Politiken)

Niedrige Priorität, aber falls angegangen: den 0.6-px-Floor aus den Shadern (shaders.rs:91,209, glPlanShaders.ts) als benannte Konstante exportieren/dokumentieren und explizit von 1e-4 (SVG) und MIN_PEN_MM=0.13 (PDF) abgrenzen — mindestens per Kommentar klarstellen, dass die drei UNTERSCHIEDLICHE Zwecke haben (GPU: Pixel-Sichtbarkeits-Floor; PDF: Papier-mm-Stiftgrenze) und NICHT synchronisiert werden müssen, damit niemand versehentlich versucht, sie anzugleichen und dabei die jeweils andere Semantik bricht.

zu Finding 7 (toter Pfad)

src/export/planToPrintSvg.ts entfernen (nach kurzer Rücksprache, ob der Kopfkommentar-Vermerk "bleibt nur als Referenz stehen" noch gewollt ist) oder, falls er als Referenz bleiben soll, seine PEN_STEPS/quantizePen-Kopie durch einen Import aus der in Finding 2 vorgeschlagenen gemeinsamen penSteps.ts ersetzen.

5. Verifikations-Rezept

Was schon existiert:

• scripts/probe-engine-parity.mjs vergleicht ?gl=0 gegen ?engine=wasm rein visuell (Screenshot-Diff von Auge, probe-parity-svg.png vs. probe-parity-wasm.png) — prüft NICHT quantitativ, ob Strichbreiten in Pixeln übereinstimmen, und deckt weder den Haarlinien-Modus noch den WebGL2-Default-Pfad noch den PDF-Export ab.
• src-tauri/render2d/tests/golden.rs vergleicht die Demo-Szene Pixel-für-Pixel gegen tests/golden/demo.png (Toleranz: Kanal-Delta > 2 auf < 0.5 % der Pixel, docs/design/engine-headless.md) — ein reiner GPU-Regressionstest, ohne SVG- oder PDF-Vergleich.
• Die einzige bisher dokumentierte mm-genaue Messung ist manuell: HANDOVER.md, Commit 382771b — pdftoppm-Messung eines exportierten PDFs (53.51×43.69 mm gegen erwartete 53.45×43.45 mm bei 1:100), einmalig, nicht als wiederholbares Skript hinterlegt.

Um den Nordstern ("Bildschirm bei jedem Zoom/Massstab = Druck") tatsächlich beweisbar zu machen, fehlt ein quantitativer End-to-End-Test, der:

1. Für eine feste Test-Szene (idealerweise die bestehende demo::demo_scene aus src-tauri/render2d/src/demo.rs, die bereits sowohl einen width_mm- als auch einen width_screen-Strich enthält, demo.rs:34,49-50) bei mehreren N (1:10, 1:50, 1:100) UND mehreren Zoomstufen:
   • den PDF-Export erzeugt und via pdftoppm -r <dpi> in ein PNG rendert, dort die Strichbreite in Pixeln misst und in mm zurückrechnet (bekannte DPI ⇒ bekannte mm/px);
   • denselben Frame headless über HeadlessRenderer::render_to_image (src-tauri/render2d/src/headless.rs) mit identischem paper_scale_n rendert und dieselbe Pixel-Breite misst;
   • beide mm-Werte gegen den erwarteten mm · N/1000-Sollwert UND gegeneinander vergleicht, mit einer Toleranz, die die PEN_STEPS-Rundung (Finding 2, sobald behoben: siehe Option A) einbezieht.
2. Den Haarlinien-Modus separat abdeckt: ein Screenshot-Vergleich bei zwei verschiedenen Zoomstufen im lineMode:"display" — die gemessene Pixelbreite MUSS bei beiden Zoomstufen identisch sein (Beweis, dass Finding 1 behoben ist), sowohl für WebGL2 (?gl ohne =0, App-Default) als auch für WASM (?engine=wasm).
3. probe-engine-parity.mjs um eine tatsächliche Pixel-Differenz-Metrik erweitert (statt nur Kindanzahl/Warnungen zu loggen wie aktuell probe-engine-parity.mjs:36-44) — z. B. eine bekannte Referenzlinie im Testmodell an fester Bildschirmposition, deren Strichbreite in beiden Screenshots per Pixel-Sampling gemessen und verglichen wird.

Bis dieser Test existiert, bleibt jede Aussage über "Bildschirm = Druck" eine Behauptung, die nur durch manuelles pdftoppm-Nachmessen einzelner Stichproben gedeckt ist — die in diesem Audit gefundenen Divergenzen (v. a. Finding 1 und 2) hätten mit den heutigen Probes nicht auffallen können, weil keiner von ihnen den Default-Zustand der App (lineMode:"display", WebGL2) gegen den Druckpfad misst.