generated from coulomb/repo-seed
95 lines
6.7 KiB
Markdown
95 lines
6.7 KiB
Markdown
**Short Take**
|
||
Quarkdown is much closer to a programmable publishing/typesetting system than to what `markitect-tool` is becoming. It compiles Markdown-like source into polished HTML/PDF/slides/docs with a Turing-complete function language, layout standard library, media pipeline, live preview, and renderer/post-renderer stack.
|
||
|
||
`markitect-tool` is better positioned as a document infrastructure and pipeline framework: contracts, validation, extraction, references, processors, literate workflows, cache/index backends, provenance, and future policy/context engines. Quarkdown could fit as an optional output/rendering target or inspiration source, but I would not fold its language model into Markitect core.
|
||
|
||
**What Quarkdown 2.0 Adds**
|
||
As of the Heise article on April 24, 2026 and the GitHub stable release on April 23, 2026, `v2.0.0` is the latest stable release I’d treat as relevant here. GitHub also shows a “Development build” pre-release, but given our current date of May 4, 2026, I would not base planning on that timestamp.
|
||
|
||
Main 2.0 changes:
|
||
|
||
- Permission system for compile-time access control: `project-read`, `global-read`, `network`, `native-content`, `all`, configured with `--allow` / `--deny`.
|
||
- Fully offline HTML output: fonts, code themes, and optional libraries are bundled/copied instead of relying on CDNs, with exceptions for some font cases.
|
||
- Parallel rendering across sibling elements.
|
||
- Lighter media storage: copy by reference and checksum validation to avoid unnecessary copies.
|
||
- Static `public/` assets copied to output root.
|
||
- HTML `baseurl`, canonical links, and `sitemap.xml`.
|
||
- Root output path symbol `@` for shared output-root assets.
|
||
- `.image` function with fine-grained media behavior.
|
||
- Linked `.ref` cross-references for headings, figures, tables, code blocks, equations, and custom numbered blocks.
|
||
- Function-call line continuation and `.keybinding`.
|
||
|
||
**What Is Novel Compared With Markitect**
|
||
Quarkdown’s big novelty is the integrated authoring-to-rendering loop. It has one language that covers Markdown, functions, variables, loops, conditionals, layout, document metadata, includes, media handling, cross-references, themes, slides, docs, paged output, live preview, and post-rendering.
|
||
|
||
Markitect currently has parts of this as infrastructure concepts, but not as one renderable authoring language.
|
||
|
||
Notably novel or stronger in Quarkdown:
|
||
|
||
- Rich function language inside Markdown.
|
||
- Layout primitives: rows, columns, grids, boxes, alignment, page margins, slides config.
|
||
- Numbering and references as rendered document semantics.
|
||
- First-class media storage and static asset output.
|
||
- Offline HTML packaging.
|
||
- Live preview/compiler workflow.
|
||
- Static-site-ish output support: sitemap, canonical links, `public/`.
|
||
- User-facing document types: `plain`, `paged`, `slides`, `docs`.
|
||
- A full compiler pipeline: lexing, parsing, function expansion, traversal, rendering, post-rendering.
|
||
|
||
**What Markitect Already Has Conceptually**
|
||
Markitect already has several “deeper infrastructure” equivalents, though often not renderer-facing:
|
||
|
||
- Includes/transclusion: `mkt include`, reference-backed processor include.
|
||
- References: namespaces, fragments, sections, regions, fenced blocks, tags, line ranges.
|
||
- Cross-reference foundation: content units and IDs exist, though rendered links do not.
|
||
- Processors: deterministic fenced-block processor registry.
|
||
- Literate workflows: `mkt tangle`, `mkt weave`, named chunks.
|
||
- Contracts: document expectations, metrics, fields, assertions, rubrics.
|
||
- Templates/generation: deterministic templates and generation hooks.
|
||
- Provenance: operation and backend provenance envelopes.
|
||
- Cache/backend planning: snapshot identity, refresh planning, dependency invalidation.
|
||
- Permission/policy concept: backend fabric has policy gateways, but not yet a Quarkdown-style execution sandbox.
|
||
|
||
**Where Quarkdown Could Fit**
|
||
Best fit: optional rendering/export backend.
|
||
|
||
Possible integration shape:
|
||
|
||
- `markitect-tool` validates, extracts, composes, resolves references, checks contracts, runs deterministic processors, and emits Quarkdown source.
|
||
- Quarkdown compiles that source to HTML/PDF/slides/docs.
|
||
- Markitect backend tracks Quarkdown source inputs, generated outputs, media dependencies, checksums, and provenance.
|
||
- Markitect contracts could validate “pre-render” structure, while Quarkdown handles final layout/render semantics.
|
||
|
||
This is cleaner than reimplementing Quarkdown’s renderer. Let Quarkdown be a publishing target; let Markitect remain the contract/pipeline/cache/provenance layer.
|
||
|
||
**Gaps To Revisit Later**
|
||
High-value gaps inspired by Quarkdown:
|
||
|
||
- Render-aware cross-reference model: figures, tables, equations, code blocks, custom numbered units.
|
||
- Asset/media pipeline: copied assets, checksums, public directory, root asset references.
|
||
- Output profiles: `plain`, `docs`, `slides`, `paged` as generation targets.
|
||
- Permission sandbox for processors and assisted/LLM execution.
|
||
- Preview/watch mode, probably later and outside core.
|
||
- Function-call style macro layer, but only if kept separate from core Markdown contracts.
|
||
- Document numbering and generated ToC as structured operations.
|
||
- Quarkdown export adapter: `mkt export quarkdown` or a dataflow step in WP-0011.
|
||
- Provenance for rendered outputs: source unit -> generated page/slide/asset.
|
||
|
||
**Caution**
|
||
Quarkdown is GPL/AGPL-licensed depending on module/binary, so direct code reuse is probably not a good fit unless licensing is deliberately accepted. Conceptual interoperability or invoking it as an external tool is safer.
|
||
|
||
**Recommendation**
|
||
Do not pivot Markitect toward being “our own Quarkdown.” Instead, add a future workplan or WP-0011/WP-0005 notes for:
|
||
|
||
1. Quarkdown export adapter.
|
||
2. Render-aware reference/numbering model.
|
||
3. Media/static asset pipeline.
|
||
4. Processor permission sandbox.
|
||
5. Output provenance for rendered artifacts.
|
||
|
||
That would let Markitect gain Quarkdown’s practical publishing utility without corrupting the elegant infrastructure direction we’ve built.
|
||
|
||
Sources: [Heise article](https://www.heise.de/en/news/Books-and-slides-from-Markdown-Quarkdown-2-0-is-here-11271511.html), [Quarkdown v2.0.0 release notes](https://github.com/iamgio/quarkdown/releases/tag/v2.0.0), [Quarkdown homepage](https://quarkdown.com/), [function syntax docs](https://quarkdown.com/wiki/syntax-of-a-function-call/), [include docs](https://quarkdown.com/wiki/including-other-quarkdown-files/), [media storage docs](https://quarkdown.com/wiki/media-storage/), [pipeline docs](https://quarkdown.com/wiki/pipeline---function-call-expansion/).
|
||
|
||
My take: Quarkdown’s function language is a very good inspiration for a future Markitect “document function layer,” especially if we keep it optional, markdown-close, typed enough for contracts, and integrated with our provenance/cache/access-control fabric.
|