Hamlet: einen professionellen Publishing-Editor für 4D entwickeln

Entwicklungs-Aktualisierung

Hamlet: Aufbau eines professionellen Verlagsredaktors für 4D, WASM & ActiveX

Hamlet ist eine der wichtigsten Entwicklungen in unserer aktuellen Produkt-Roadmap: ein nativer reicher Text, Seitenlayout und Datenbank-Publishing-Editor, der zunächst für 4D entwickelt wurde, mit einem zukünftigen Weg in Richtung des Browsers und anderer Windows Datenbankumgebungen. Das Ziel ist ehrgeizig, aber klar: Entwicklern einen seriösen Dokumenteditor zu geben, der mit echten Datenbanken arbeiten und professionelle Ergebnisse für Rechnungen, Berichte, Briefe, Vorlagen und Veröffentlichungsarbeiten erzeugen kann.

Warum Hamlet existiert

Die Grundidee ist einfach: kombinieren Sie einen reichhaltigen Dokumenteditor mit der Veröffentlichung von Datenbanken. Ein Benutzer sollte in der Lage sein, ein Dokument visuell zu gestalten, Live-Datenbankfelder in ihn zu platzieren, reale Daten zu präsentieren, Rechnungslinien oder verwandte Aufzeichnungen zu wiederholen und dann das Ergebnis zu exportieren oder zu drucken, ohne die Treue zu verlieren.

Das bedeutet, dass Hamlet nicht nur ein Text-Editor ist. Es ist eine Publishing-Oberfläche, ein Template-Designer, eine Datenbank-Fusion-Engine und eine eingebettbare Anwendungskomponente.

Was umgesetzt wurde

• Rich Textbearbeitung: Schriftfamilie, Schriftgröße, fett, Kursivschrift, Unterzeichnung, Streik, Überschrift, Unterschrift, Textfarbe, Highlight, Zeilenhöhe, Buchstabenentfernung, Baseline Shift und Stilläufe.
• Absätze in Form: Ausrichtung, Abstand, Gedankenstrich, Listen, Tab-Stops, Absätze-Hintergründe und Absätze-Grenzen.
• Layout der Seite: Papier-Vorinstellungen, benutzerdefinierte Seitengrößen, Margen, Gitter, Kopfzeilen, Fußzeilen, Seitennummern, Seitenzählfelder, Zoom-Modus, Regeln und Seitenchrom.
• Dokumentenobjekte: Tabellen, Bilder, PDF-Dateien, Textfelder, Zeilen, Formen, benutzerdefinierte Objekte und Inline-Datenplatzhalter werden als echte Dokumentmodellobjekte dargestellt.
• Tabellen: Reihen- und Spaltenbearbeitung, Zelltext, Zell-Styling, Tabellen-Styling, Fusionen, Unfusionen, Tabellen-Styl-Vorinstellungen, Tabellen-Zell-Datenbindungen und wiederholende Tabellenreihen für die Datenbankveröffentlichung.
• Bilder und PDF-Dateien: eingebettete Bildnutzlasten, Datei-Import, Fit-Modus, Erntefokus, PDF-Import, PDF-Kontrolle, Seitenwahl, Page-Box-Handling und skalierbares Rendering.
• Veröffentlichung der Datenbank: Felder, Variablen, Methoden, Formeln, Ausdrücke, Live-Binding-IDs, Direct-Refresh, strukturierte Resolver-Ergebnisse, Rückschreibschirme, Wiederholungsregionen, Tabellenreihenregionen und Workflows zur Zusammenführung von aktuellen Aufzeichnungen.
• Einfuhr und Ausfuhr: Hamlet-Paketdateien, einfacher Text, unterstützte HTML, PDF, PNG, mehrseitige PNG-Export-, RTF- und DOCX-Konversionswege.
• Ausgangspipeline: eine Seite-Display-List-Architektur erfasst die aufgebaute Seite-Wahrheit und wiederholt sie für PDF, PNG und Druck-Ausgabe.

Die Benutzeroberfläche

Hamlet bewegt sich in Richtung eines professionellen schwimmenden Toolpanel-Systems, ähnlich im Geist zu Veröffentlichung und Design-Anwendungen. Das aktuelle Toolpanel-System umfasst Panels für Character, Paragraph, Pages, Object, Color, Data und Styles. Diese Panels teilen die gleiche interne Architektur für Zeichnung, Hit-Testing, Dropdowns, Gruppierung, Docking, Zusammenbruch, Bewegung und Area-State-Persistenz.

Die schwierigen Teile

Die größte Herausforderung besteht darin, nicht isolierte Funktionen hinzuzufügen. Die eigentliche Herausforderung besteht darin, alle Funktionen innerhalb einer eingebetteten Komponente sicher zusammenzuarbeiten. Das Zeichnen muss schnell und deterministisch sein. Große Dokumente müssen reaktionsfähig bleiben. Die Datenbank-Vorsicht darf die Vorlage nicht zerstören. Export muss mit dem übereinstimmen, was der Benutzer auf dem Bildschirm sieht.

• Eingebettete Betriebssicherheit: Der Editor muss sich in Host-Umgebungen wie 4D Formularen, zukünftigen Browseroberflächen und Windows Komponentencontainern korrekt verhalten.
• Große Dokumentleistung: Textlayout, Toolbar-Zustand, Seitengeometrie und Sorge-Sichtbarkeit müssen wiederholte vollständige Dokument-Scans vermeiden.
• Datenbank-Platzhalter: Fälle und Formeln können keine einfachen Text-Token sein, sie müssen echte grafische Dokumentobjekte mit stabiler Identität sein.
• Datenschutz: Das Vorschauen der gelösten Daten darf den verborgenen Vorlageinhalt nicht heimlich mutieren.
• Exportvertragbarkeit: PDF, PNG und Drucksausgabe müssen aus derselben Seite stammen wie der Editor, nicht aus einer zweiten Layout-Engine.

Der Weg vor uns

Hamlet ist bereits ein leistungsstarker Prototyp, aber er ist noch nicht fertig.

• Visuelle Überprüfung: mehr Screenshots und Gold-Output-Tests für PDF, PNG, Druck, Toolpanels, Bilder, Tabellen und komplexe Seitenlayouts.
• Druck- und Ausfuhrlaufzeit: Stärkere Suchfähigkeit/Vektortreue, Ressourcenpolitik mit hoher Auflösung, Sektionskenntnisse und breitere mehrseitige Akzeptanzstests.
• RTF- und DOCX-Fähigkeit: Die ersten Import- und Ausfuhrwege bestehen, aber eine vollständige Formatdeckung und eine breitere Hin- und Rückverbindlichkeitskompatibilität bleiben künftige Arbeiten.
• Fortgeschrittene Veröffentlichungs-UI: Sie werden in der Lage sein, die Daten zu verarbeiten, um die Daten zu erfassen und zu verarbeiten.
• Objektbearbeitungspolish: Richere Bild-, PDF-, Tabellen-, Zeilen-, Formen- und Textbox-Steuerungen.
• Windows Parität: Windows-Rendering, -Dialog, -Clipboard, -Druck und -PDF/Bild-Unterstützung müssen noch mit der macOS-Implementierung mithalten.

Über 4D hinaus: Browser und ActiveX Ambitionen

Obwohl Hamlet zunächst als 4D-Komponente gebaut wird, ist die langfristige Vision breiter.

Eine browserbasierte Hamlet würde die Tür zum Web-hosted-Dokumentbearbeitung, Online-Template-Design und serververnetzten Publishing-Workflows öffnen. Eine ActiveX-Version würde Hamlet wertvoll für bestehende Windows-Datenbank-Anwendungen machen, insbesondere Umgebungen wie Visual FoxPro, in denen eingebettete Dokumenterzeugung und Datenbank-getriebene Berichterstattung immer noch wichtig sind.

Diese zukünftigen Versionen erfordern ernsthafte Ingenieurarbeit. Ein Browser-Build bedeutet die Anpassung von Rendering, Eingabe, Schriftarten, Clipboard, Dateizugriff und Exportverhalten an die Webplattform. Ein ActiveX-Build bedeutet die Erstellung einer stabilen Windows Komponentenoberfläche, COM/ActiveX Automatisierungs-APIs, Host-Integration, Druckverhalten und Bereitstellungsregeln. Aber die Richtung ist klar: Hamlet sollte eine wiederverwendbare Verlagsmaschine werden, nicht nur ein Single-Host-Editor.

Die Zukunft

Die langfristige Vision ist, dass Hamlet die Dokumentenmaschine wird, auf die sich Entwickler verlassen können, wenn gewöhnliche Textbereiche nicht ausreichen. Es sollte Datenbank-getriebene Vorlagen, professionelle Bearbeitung, Seitenlayout, wiederverwendbare Stile, eingebettete Medien, druckbereite Ausgabe und automatisierte Dokumenterzeugung aus Code unterstützen.

In 4D kann Hamlet ein nativer Publishing-Editor werden. In dem Browser könnte eine zukünftige WASM-Version das gleiche Bearbeitungs- und Publishing-Modell in Webanwendungen bringen. Auf Windows könnte eine zukünftige ActiveX-Version Hamlet in FoxPro Datenbanken und andere ActiveX-fähige Anwendungen bringen, die noch ernsthafte Dokumenterzeugung benötigen.

Deshalb ist diese Entwicklung wichtig: Hamlet ist kein kosmetisches Merkmal, sondern die Grundlage für eine neue Klasse von Datenbank-basierten Dokument- und Publikationsanwendungen.

Kurz gesagt: Hamlet bewegt sich von einem reichen Text-Editor-Prototyp zu einer vollständigen Publishing-Engine für 4D, mit einem zukünftigen Weg in Richtung WebAssembly im Browser und ActiveX auf Windows. Es gibt noch ernsthafte Arbeit vor sich, aber die Architektur ist jetzt stark genug, um die Zukunft zu tragen, die wir aufbauen.