Development Update
Hamlet: Building a Professional Publishing Editor for 4D, WASM & ActiveX
Hamlet is one of the most important developments in our current product roadmap: a native rich text, page layout, and database publishing editor built first for 4D, with a future path toward the browser and other Windows database environments. The goal is ambitious but clear: give developers a serious document editor that can work with real database data and produce professional output for invoices, reports, letters, templates, and publishing workflows.
The idea behind Hamlet
Business applications often need much more than a simple text field. They need structured documents, database-aware templates, styled output, page layout, print/PDF generation, and an editor that feels integrated instead of bolted on. Hamlet is our answer to that need.
Why Hamlet Exists
The core idea is simple: combine a rich document editor with database publishing. A user should be able to design a document visually, place live database fields into it, preview real data, repeat invoice lines or related records, and then export or print the result without losing fidelity.
That means Hamlet is not just a text editor. It is a publishing surface, a template designer, a database merge engine, and an embeddable application component. It is being built to support both interactive editing and automated/offscreen document generation.
What Has Been Implemented
- Rich text editing: font family, font size, bold, italic, underline, strike, superscript, subscript, text color, highlight, line height, letter spacing, baseline shift, and style runs.
- Paragraph formatting: alignment, spacing, indents, lists, tab stops, paragraph backgrounds, and paragraph borders.
- Page layout: paper presets, custom page sizes, margins, gutters, headers, footers, page numbers, page count fields, zoom modes, rulers, and page chrome.
- Document objects: tables, images, PDFs, text boxes, lines, shapes, custom objects, and inline data placeholders are represented as real document model objects.
- Tables: row and column editing, cell text, cell styling, table styling, merges, unmerges, table style presets, table-cell data bindings, and repeating table rows for database publishing.
- Images and PDFs: embedded image payloads, file import, fit modes, crop focus, PDF import, PDF inspection, page selection, page-box handling, and scaled rendering.
- Database publishing: fields, variables, methods, formulas, expressions, live binding ids, direct refresh, structured resolver results, writeback guards, repeating regions, table row regions, and current-record merge workflows.
- Import and export: Hamlet package files, plain text, supported HTML, PDF, PNG, multi-page PNG export, RTF, and DOCX conversion paths.
- Output pipeline: a page display-list architecture records the laid-out page truth and replays it for PDF, PNG, and print output.
The User Interface Direction
Hamlet is moving toward a professional floating toolpanel system, similar in spirit to publishing and design applications. The current toolpanel system includes panels for Character, Paragraph, Pages, Object, Color, Data, and Styles. These panels share the same internal architecture for drawing, hit testing, dropdowns, grouping, docking, collapsing, movement, and area-state persistence.
The Hard Parts
The biggest challenge is not adding isolated features. The real challenge is making all features work together safely inside an embedded component. Drawing must be fast and deterministic. Large documents must remain responsive. Database preview must not destroy the template. Export must match what the user sees on screen.
- Embedded runtime safety: the editor must behave correctly inside host environments such as 4D forms, future browser surfaces, and Windows component containers.
- Large document performance: text layout, toolbar state, page geometry, and caret visibility must avoid repeated full-document scans.
- Database placeholders: fields and formulas cannot be plain text tokens. They must be real graphical document objects with stable identity.
- Data view protection: previewing resolved data must not secretly mutate hidden template content.
- Export fidelity: PDF, PNG, and print output must come from the same page truth as the editor, not from a second layout engine.
The Road Ahead
Hamlet is already a powerful prototype, but it is not finished. The next phase is about polish, fidelity, platform completeness, and workflow depth.
- Visual verification: more screenshot and golden-output testing for PDF, PNG, print, toolpanels, images, tables, and complex page layouts.
- Print and export maturity: stronger searchable/vector fidelity, high-resolution resource policy, section-aware output, and broader multi-page acceptance testing.
- RTF and DOCX fidelity: the first import/export paths exist, but full format coverage and broader round-trip compatibility remain future work.
- Advanced publishing UI: deeper relation browsing, better formatter tools, and more guided database publishing workflows.
- Object editing polish: richer image, PDF, table, line, shape, and text-box controls.
- Windows parity: Windows rendering, dialogs, clipboard, printing, and PDF/image support must still catch up with the macOS implementation.
Beyond 4D: Browser and ActiveX Ambitions
Although Hamlet is being built first as a 4D component, the longer-term vision is broader. The core architecture is being shaped so that Hamlet can eventually become available in more environments than one desktop plug-in host.
Future platform goals
- WASM/browser version: a WebAssembly edition that can run directly in the browser, making Hamlet usable in web applications while preserving the same document model, page layout concepts, and publishing workflow.
- ActiveX component: a Windows ActiveX version for FoxPro databases and other Windows applications that support ActiveX controls, allowing legacy and desktop database systems to embed Hamlet as a professional document editor and publishing component.
- Shared document foundation: the goal is to keep the document model, template concepts, style system, object model, and publishing logic consistent across 4D, browser, and Windows component hosts.
A browser-based Hamlet would open the door to web-hosted document editing, online template design, and server-connected publishing workflows. An ActiveX version would make Hamlet valuable to existing Windows database applications, especially environments such as Visual FoxPro where embedded document generation and database-driven reporting are still important.
These future versions will require serious engineering work. A browser build means adapting rendering, input, fonts, clipboard, file access, and export behavior to the web platform. An ActiveX build means creating a stable Windows component surface, COM/ActiveX automation APIs, host integration, printing behavior, and deployment rules. But the direction is clear: Hamlet should become a reusable publishing engine, not only a single-host editor.
The Future
The long-term vision is for Hamlet to become the document engine developers can rely on when ordinary text areas are not enough. It should support database-driven templates, professional editing, page layout, reusable styles, embedded media, print-ready output, and automated document generation from code.
In 4D, Hamlet can become a native publishing editor. In the browser, a future WASM version could bring that same editing and publishing model to web applications. On Windows, a future ActiveX version could bring Hamlet into FoxPro databases and other ActiveX-capable applications that still need serious document generation.
That is why this development matters. Hamlet is not a cosmetic feature. It is a foundation for a new class of database-driven document and publishing applications.
In short: Hamlet is moving from a rich text editor prototype toward a full publishing engine for 4D, with a future path toward WebAssembly in the browser and ActiveX on Windows. There is still serious work ahead, but the architecture is now strong enough to carry the future we are building toward.
