breaklint prüft die Seite, die am Ende gedruckt wird.

In einer Zeile ausprobieren

npx breaklint --demo

Der Befehl braucht keinen Browser und keine Konfiguration. Er endet mit Exit 1, weil das mitgelieferte Beispiel absichtlich Befunde enthält — eine Demo, die mit 0 endet, zeigt nie, wie ein Befund aussieht. Der Block unten ist unveränderte Ausgabe dieses Befehls. Die Regelkette darin ist die echte; die Seite, die sie beurteilt, ist ein handgeschriebenes Fixture, damit jeder Regelpfad ohne Browser erreichbar ist — der Bericht schreibt selbst in sein source-Feld, welche Art Fixture er gelesen hat.

error layout/unbreakable-block-too-tall  page 2
  measured   848 px; threshold 606 px (uncalibrated)
  detail     This block asks not to be broken and is
             848.00 px tall; the page content box is
             606.00 px. It cannot fit on any page.
  source     examples/demo.html:31

Warum es das gibt

Prosa-Linter sehen keine Seite. Satzsysteme sehen die Seite, kennen aber die deutsche typografische Konvention nicht. Für Dokumente, die aus HTML zu PDF entstehen, gab es beides nicht.

Der Anlass war ein Fall, den die Prüfung am Quelltext nicht gefunden hat: eine Grafik bestand die XML-Validitätsprüfung und eine Geometrieprüfung — und kam mit kollidierenden Beschriftungen aus dem Renderer. Ob eine Seite trägt, entscheidet sich nach der Paginierung, im Renderer, mit den Schriften, die tatsächlich verfügbar waren.

Was geprüft wird

Fünfzehn Regeln. Zwei davon können einen Build scheitern lassen; zwölf weitere sind Hinweise, bis man mit --fail-on warn ausdrücklich mehr verlangt; und eine — layout/half-empty-page — ist experimentell und bewegt nie einen Exit-Code, auch dann nicht. Diese Trennung ist keine Vorsicht, sondern die Beweislast: nur zwei Regeln vergleichen unmittelbar gemessene Größen mit einer strukturellen Grenze.

Was nicht kalibriert ist — und warum das dransteht

Keine der fünfzehn Schwellen ist an einem Korpus echter Dokumente mit menschlich geprüfter Wahrheit kalibriert. Deshalb steht uncalibrated im Datentyp, in jedem einzelnen Befund und auf jeder Regelseite. Die Fixtures zeigen, dass jede Regel tut, was sie sagt — nicht, dass das Gesagte über ein reales Dokument das Richtige ist.

Das ist der Unterschied zwischen einer verifizierten und einer validierten Implementierung, und nur das Erste wird behauptet. Ein Prüfer, dessen grüner Zustand nichts bedeutet, ist gefährlicher als gar kein Prüfer — deshalb führt das Repository eine eigene Seite darüber, was fertig gemessen ist und was nicht.

Was es nicht tut

Voraussetzungen

Node 20 oder neuer, auf macOS oder Linux. Ein Lauf über echte Dokumente braucht zusätzlich einen Chromium-basierten Browser und [email protected]; pdfjs-dist rastert das erzeugte PDF, um Belege an Befunde zu binden. Windows wird nicht unterstützt — die Prozessbehandlung ruht auf POSIX-Prozessgruppen —, und Linux ist noch nicht empirisch gemessen: der Prozess- und Profilpfad ist bisher nur auf macOS belegt.

npm i -D breaklint
npm i -D puppeteer-core [email protected] [email protected]

breaklint verwendet zur Prüfzeit kein Sprachmodell. Es führt keine Inferenz aus und enthält keinen API-Client.

Herkunft

breaklint entsteht bei Dargel Solutions und ist unter der MIT-Lizenz frei verwendbar, auch kommerziell. Teile des Repositories wurden mit Hilfe von Sprachmodellen geschrieben; der Regelsatz, die Schwellen und ihre Quellen wurden von einem Menschen gewählt. Jede Regel, die sich auf das deutsche Regelwerk der Rechtschreibung beruft, wurde gegen dessen veröffentlichten Text geprüft, nicht gegen die Zusammenfassung eines Modells.