2 Punkte von GN⁺ 1 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Verbindet Markdown-basierte Dokumenterstellung mit Satzfunktionen auf LaTeX-Niveau, sodass sich mit einem einzigen Tool alles von wissenschaftlichen Arbeiten bis hin zu Büchern, Präsentationen, statischen Websites und Wissensdatenbanken umsetzen lässt
  • In einer Syntax mit weniger Boilerplate lassen sich Elemente wie Autor, Seitenränder, Abstract, Bilder und Zitate direkt einfügen, sodass Inhalt und Layout gemeinsam geschrieben werden können
  • Mit einer einzigen .doctype-Einstellung kann zwischen den Dokumenttypen paged, plain, docs und slides gewechselt werden; unterstützt werden sogar interaktive Präsentationen
  • Bietet schnelle Kompilierung und Live-Vorschau; mit Turing-vollständigem Scripting und der Wiederverwendung von Funktionen und Argumenten lässt sich wiederkehrende Layout-Arbeit reduzieren
  • Kostenlos und als Open Source verfügbar; der Compiler wird kontinuierlich weiterentwickelt und bleibt freie Software

Änderungen im Release 2.0.0: veröffentlicht am 23. April 2026

  • Die HTML-Ausgabe erfolgt nun vollständig offline, wodurch Darstellungsfehler und fehlende Funktionen durch Abhängigkeiten von CDN und Google Fonts deutlich reduziert werden
  • Ein neues Berechtigungssystem wurde hinzugefügt: Mit --allow und --deny lässt sich steuern, worauf ein Dokument während der Kompilierung zugreifen darf; fehlen Berechtigungen, wird sofort ein Fehler ausgegeben, was die Sicherheit erhöht
  • Das Standard-Ausgabeverzeichnis wurde von ./output auf ./quarkdown-output geändert; Workflows, die vom bisherigen Standardpfad abhängen, müssen angepasst werden
  • Bei Verwendung von --preview basiert der Standard-Ausgabename nicht mehr auf .docname, sondern auf dem Format preview-<mainfile>-<hash>, was die Stabilität der Vorschau erhöht
  • Paralleles Rendering wurde eingeführt, sodass bei großen Dokumenten gleichrangige Elemente gleichzeitig verarbeitet werden und sich die Rendering-Leistung verbessert
  • Das public/-Verzeichnis im Projektstamm kann unverändert in das Wurzelverzeichnis der HTML-Ergebnisse kopiert werden, was die Bereitstellung von robots.txt, CNAME und gemeinsam genutzten statischen Assets erleichtert
  • Mit der neuen Funktion .htmloptions kann baseurl gesetzt werden; dadurch lassen sich canonical links in jede Seite einfügen und außerdem sitemap.xml erzeugen, was die Suchmaschinenfreundlichkeit verbessert
  • Bei der HTML-Kompilierung werden in Links und Bildern nun @-Root-Pfadsymbole unterstützt, sodass gemeinsame Assets von jedem Unterdokument aus konsistent referenziert werden können
  • Die neue primitive Funktion .image wurde hinzugefügt und erlaubt eine feine Steuerung von Größe, Bildunterschrift und der Verwendung fixer relativer Pfade; sie passt außerdem gut zur Nutzung von public/-Assets
  • Cross-Reference-Links für alle referenzierbaren Elemente werden nun unterstützt, sodass zu Abbildungen, Tabellen, Code-Blöcken, Formeln und benutzerdefinierten nummerierten Blöcken per Klick gesprungen werden kann
  • Der Name des Standardbibliotheksmoduls Injection wurde zu Html geändert; bestehende Dokumente oder Referenzcode müssen daher angepasst werden
  • Auch das weiße Aufblitzen in der Live-Vorschau des Dark Themes sowie Probleme mit dem Quarkdoc-Wiki-Link wurden behoben, was die Nutzung angenehmer macht

1 Kommentare

 
GN⁺ 1 일 전
Hacker-News-Kommentare
  • Ehrlich gesagt ist es schon beeindruckend, aber für mich liegt der Kern von Markdown in seiner extremen Einfachheit
    Man kann es auch ohne GUI bearbeiten, selbst wenn man es in VIM im Terminal schreibt, hat man ungefähr ein Gefühl dafür, wie das Ergebnis aussehen wird, und selbst die rohe .md-Datei lässt sich einfach gut lesen
    Wenn man aber immer mehr Funktionen daraufpackt, muss man ständig unbekannte Befehle nachschlagen, merkt sie sich am Ende doch nicht, ist sich ohne Rendering nicht mehr sicher, wie es aussieht, und wünscht sich schließlich einen WYSIWYG-Editor
    Das wirkt ein bisschen wie die Idee, auf eine QWERTY-Tastatur auch noch kyrillische Zeichen, Devanagari, Chinesisch und arabische Tasten zu packen
    und dann landet man am Ende wieder bei hunt and peck

    • Für mich ist einer der großen Vorteile von Markdown, dass es halbwegs WYSIWYG ist
      Die Grundsyntax greift ja genau die Art wieder auf, wie Menschen schon immer versucht haben, in Texten Formatierung nachzuahmen, sodass die Eingabe selbst meistens direkt gut lesbar bleibt
      Auch wenn man Markdown nicht genau schreiben kann, gibt es beim Lesen meist keine Probleme, Tabellen sehen wie Tabellen aus und Absätze einfach wie Absätze
      Manchmal muss ich die Syntax noch einmal nachschlagen, aber das ist okay. Ein größerer passiver als aktiver Wortschatz ist ganz normal
      Deshalb beurteile ich so etwas eher nach der Lesbarkeit des Quelltexts, und vieles von dem, was hier gezeigt wurde, scheint nach diesem Maßstab keinen besonders großen Netto-Gewinn zu bringen
      Allerdings habe ich kein Beispiel für Formelsatz gesehen, und in den seltenen Fällen, in denen ich LaTeX benutze, liegt das meist an Mathematik, die in Markdown nicht geht, daher würde mich interessieren, wie das dort tatsächlich aussieht
    • Das ist ein ziemlich überzeugendes Argument
      Trotzdem wirkt Quarkdown eindeutig wie ein Schritt über direkt geschriebenes LaTeX hinaus, und auch bei Vorhersehbarkeit des Ergebnisses sowie bei LLM-gestützter Bearbeitung scheint es besser kompatibel zu sein als GUI-Editoren wie Word
    • Man muss einfach ein noch mächtigeres Quarkdown bauen, ohne seltsame neue Befehle auswendig lernen zu müssen, und mit einer glatten UI/UX dazu
      Der Name könnte dann Microsoft Word sein
    • Ich baue auch gerade einen kleinen Markdown-Renderer, und schon einen Namen zu finden ist schwer, und selbst wenn er fertig ist, Menschen dazu zu bringen, ihn zu benutzen, ist noch schwerer
      Heutzutage fällt man mit einem normalen "plain markdown"-Editor kaum noch auf, und um auf die HN-Startseite zu kommen, braucht man offenbar am Ende doch Funktionalität und Reife, die über normales Markdown hinausgehen
      Es fühlt sich ein bisschen wie natürliche Selektion an
    • Obsidian.md ist als grundlegender WYSIWYG-Editor für Markdown wirklich hervorragend
  • Es wäre schön, eine Gegenüberstellung all dieser Tools und Markup-Sprachen auf einmal zu haben
    MyST, Pandoc, Quarkdown, Quarto, Typst einmal nebeneinander
    Quarto und Pandoc verwenden Pandoc Markdown, und https://www.zettlr.com/ ebenso
    Dagegen wirken Quarkdown und Typst eher wie programmierbare Markup-Sprachen näher an LaTeX oder HTML+Javascript, sodass wohl noch nicht entschieden ist, wer wirklich der Nachfolger von LaTeX wird

    • Die meisten davon habe ich selbst benutzt und werde das auch weiter tun, grob kann man sie so einteilen
      Markdown ist .txt mit ein bisschen syntaktischem Zucker obendrauf und lässt sich nach PDF oder HTML exportieren
      Quarto ist Markdown, bei dem man Codeblöcke ausführen möchte
      Typst ist LaTeX modern neu gebaut, sodass 90 % des Ballasts weg sind, aber gefühlt auch 10 % der Funktionen fehlen
      Die Wissenschaft mag Neues traditionell nicht, daher wird Typst dort wohl selbst dann nicht besonders willkommen sein, wenn man es einsetzt
      Pandoc ist letztlich ein Tool, um nach PDF, HTML und andere Formate zu exportieren
      Meist sieht man schnell, welche Tool-Kategorie man braucht, und es gibt auch Dinge wie asciidoc, aber wenn man überlegt, welche Bereiche die Kombination aus markdown/quarto/typst nicht abdeckt, bleibt nicht viel übrig
      Eigentlich höchstens WYSIWYG-Editoren
    • In die Vergleichsliste könnte man auch djot aufnehmen
      Es wirkt wie ein gut designtes und ziemlich gründliches Superset von Markdown
      https://djot.net/
    • Ich wollte Typst wirklich lieben
      Wenn ich LaTeX nicht mehr benutzen müsste, wäre das großartig gewesen, aber in echten Projekten bin ich auf zu viele Edge Cases gestoßen und am Ende doch wieder zu LaTeX zurückgekehrt
      Es gibt Dinge aus LaTeX, die fehlen, und die schwache Pandoc-Konvertierbarkeit war ebenfalls ein großer Faktor
      Ich hoffe wirklich, dass nur noch diese letzten 10 % fehlen
    • Falls du genau so einen Vergleich meinst: Den gibt es schon
      https://github.com/iamgio/quarkdown#comparison
    • Pandoc liegt auf einer anderen Ebene als die anderen Tools
      Man kann beliebige Filter auf das Zwischenformat JSON anwenden und damit praktisch jede gewünschte Transformation umsetzen, und es wandelt verschiedenste Formate in dieses JSON oder wieder daraus zurück
      Deshalb bevorzuge ich Systeme auf Pandoc-Basis, und Dinge, die das Basistool nicht kann, lassen sich oft mit einem einfachen Inline-Filter lösen
  • Nach dem Standardmodell der Physik-Software wird Quarkdown zu Quarkup, wenn man es in Atom bearbeitet, und man muss Neutron Mail durch Proton Mail ersetzen
    Funktioniert allerdings nur, wenn man mit der linken Hand tippt, dabei eine Electron-App baut und auch noch einen anti-Neutrinos AI blogpost schreibt

  • Mein kurzes Urteil wäre: Das ist im Grunde eher Markdown mit Makros im LaTeX-Stil
    Nur nennt man sie hier Funktionen, vermutlich weil es mindestens eine Funktion mit Seiteneffekten gibt – nämlich diejenige, mit der man neue Funktionen definiert
    Diese syntaktische Reinheit von "alles ist eine Funktion" gefällt mir, aber dass Struktur und Styling so natürlich im HTML/CSS-Stil vermischt werden, ist ein wenig zwiespältig. Wobei diese Grenze ohnehin schon immer unscharf war
    Trotzdem ist es ziemlich cool, und ich kann verstehen, warum viele skeptisch reagieren, wenn man Markdown stark verändern will
    Die Kritik, dass zu viele Funktionen die Lesbarkeit des Quelltexts verschlechtern können, stimmt auch, und manchmal ist Turing-Unvollständigkeit tatsächlich ein Vorteil
    Aber als Entwurf dafür, Markdown Funktionen hinzuzufügen, ist das insgesamt ein ziemlich sauberes Design

  • Ich bin der Autor und Projektleiter von Quarkdown
    Angefangen hat es als Forschungsprojekt an der Universität, und ich hätte mir nie vorstellen können, dass es zwei Jahre später so aussehen würde
    Danke für das Interesse, ich werde versuchen, auf so viele Kommentare wie möglich zu antworten

    • Mich würde interessieren, ob du in v3 die Syntax für Fettschrift "reparieren" willst
      Ich fand immer schon, dass *bold* und _italic_ sinnvoller wären als **bold** und *italic*
      Dieser zusätzliche Stern in Markdown ist kein besonders gutes Design und gerade beim Bearbeiten von Markdown auf Handy oder Tablet ziemlich unpraktisch
    • Die Idee, Funktionen in ein Textformat einzubauen, wirkt ziemlich ungewohnt
      Selbst in GUI-Dokumenten versucht man Makros normalerweise eher zu vermeiden, deshalb würde mich interessieren, ob Quarkdown ursprünglich für komplexe und repetitive Dokumente gedacht war
      Danke, dass du Fragen annimmst
    • Ich habe https://iamgio.eu/2025-12-10-accidentally-in-silicon-valley/ gelesen, und es freut mich, dass es für dich offenbar gut gelaufen ist
  • Beim Überfliegen der Dokumentation hatte ich etwas Sorge, ob das Auswertungsmodell für diese Aufgabe passend ist
    Bei Textlayout muss man normalerweise, wenn man an einer Stelle etwas anpasst, den restlichen Aufbau neu berechnen, weil sich dadurch die Platzierung an anderer Stelle verschiebt; man braucht also eine Struktur, die bis zu einem Fixpunkt iteriert
    Typst hat dafür das Konzept von context https://typst.app/docs/reference/context/, aber bei Quarkdown habe ich nichts Vergleichbares gesehen. Vielleicht habe ich es übersehen
    Ich bin bei Buchprojekten von der Kombination pandoc/md/LaTeX auf Typst umgestiegen und ziemlich zufrieden damit
    Es fühlt sich gut an, in einer modernen Sprache zu programmieren, und ist auch deutlich schneller als pandoc+LaTeX
    https://functionalprogrammingstrategies.com/

  • Aus Sicht von AsciiDoc wirkt das Syntaxdesign von Quarkdown sauber, besonders die benutzerdefinierten Funktionen gefallen mir
    Allerdings habe ich den Eindruck, dass in dieser Kategorie nicht die Quellsprache selbst der schwierigere Teil ist, sondern die Output-Pipeline
    Cross-References, Admonitions, bedingte Inhalte, funktionsbasierte Wiederverwendung und ähnliche Markdown-Erweiterungen lassen sich vom Design her ausreichend behandeln
    Die eigentliche Hürde kommt danach: etwa Tagged PDFs für PDF/UA, die reproduzierbar als deterministic build entstehen, auch wenn sich die Umgebung ändert, hreflang und cross-document linking für mehrsprachige Dokumentationsseiten oder incremental rebuilds, die auch bei einem 500-seitigen Buch noch durchhalten
    Gerade in der EU ist PDF/UA seit Inkrafttreten des European Accessibility Act am 28. Juni 2025 noch wichtiger geworden
    Mich würde interessieren, wie ihr die vier Doctypes, besonders paged, weiterentwickeln wollt

  • In die Vergleichstabelle gehört auch MyST
    https://mystmd.org/
    Das könnte künftig durchaus der neue Markdown-Standard werden

    • Oder auch Typst wäre einen Eintrag wert
      Es ist zwar keine Markdown-Erweiterung, aber Zielsetzung und Anwendungsfälle sind ziemlich ähnlich
    • Die Kombination MyST + Sphinx ist sehr gut
      Nur starke LSP-Unterstützung fehlt, zumindest ist es mir nicht gelungen, das in helix sauber zum Laufen zu bringen
      Mein Blog ist ebenfalls mit pydata-sphinx-theme und myst gebaut
    • Damit kenne ich mich nicht gut aus
      Wenn du willst, kannst du die Tabelle per PR direkt selbst aktualisieren
  • In meiner App habe ich einen etwas anderen Ansatz gewählt
    Ich habe mich auf Lesbarkeit und den einfachen Umgang mit großen Mermaid-Diagrammen konzentriert und kürzlich außerdem einen Vollbildmodus zum Navigieren wie auf einer Karte hinzugefügt
    https://mdview.io/s/97af684b

  • Wenn ich ein SSG benutze, lasse ich die Eingabe lieber möglichst als sauberes Markdown und lagere Formatierungsdetails in CSS aus
    Zum Beispiel muss man nichts wie .abstract eigens schreiben, wenn CSS den ersten Absatz einfach als Abstract behandeln kann
    Dieses Projekt scheint dagegen eher in Richtung reichhaltigerer selbstgenügsamer Dokumente zu gehen
    Es gibt kein CSS, aber viele vordefinierte Styling-Optionen, und deshalb muss ich ständig an frühes HTML denken
    HTML 1 hatte keine Farben und fast keine Formatierung und war damit Markdown ähnlich, während mit HTML 3 nach und nach vieles dazukam – daran erinnert mich diese Entwicklung