My FOSS text editor, KeenWrite[1], takes a similar approach: Markdown -> XHTML -> TeX -> PDF. The software architecture shows how you can have processor chains:
I developed KeenWrite to help write a sci-fi novel where I can use variables for character names, places, etc. See the tutorials[2] for details.
For anyone still using pandoc and shell scripts, my Typesetting Markdown[3] series describes building a script-based infrastructure for converting Markdown into PDF.
I was really excited when I read your post. I've long looked for a good MarkDown -> PDF or RTF workflow, so I gave KeenWrite a quick try. At first glance I really thought I'd be exactly the user for this tool, but quickly realized that the discoverability of KeenWrite isn't nearly good enough.
Upon launch, I'm presented with three panes. I've got a MarkDown authoring interface and an output preview. Great. I drop in some markdown and it renders.
Then I have a "variables.yaml" pane open with three little controls, "Create", "Rename", and "Delete". Ok... I'm editing a YAML file. But it's a clunky nested node editor. People can edit a MarkDown file but you don't think it's faster to simply let people edit YAML in text?
So, I get it, I'm editing a YAML file that stores metadata about... SOMETHING about my document output. Except I don't have a single example of a variable. Not a single one. I have no idea what variables are available and exploring every single menu option tells me nothing. Help only provides a small about page with no link to the documentation.
So, I go to keenwrite.com and click documentation. It takes me to a single GitLab readme that talks about different command line launch options, and then finally how to begin to use metadata, but the options all revolve around creating an .Rmd file and using R or creating a "definitions.yaml" instead of a "variables.yaml" in a seperate editor.
This is the moment I realize there's no chance this tool is going to be useful for me.
For me, the issue is not document conversion and is content de-duplication. Product A and Product B manual will share number of sections. Any spelling or grammar error must be updated in Product A and B manuals. They man share the same additions.
So far LaTex has been the only solution to allow binding shared sections into multiple document builds. These are for internal and customer facing information. Only binding duplication is in the revision overview sections pertaining to each document build.
Looking at the "mock" document (https://github.com/iamgio/quarkdown/tree/main/mock) which is supposed to be a comprehensive and detailed guide for all visual elements, I don't see ways of getting anything other than basic markdown tables. How do you get merged cells? Cell formatting? Typst has some nice ways of implementing sophisticated grids and tables.
Also how do you implement things like different page numbering for front matter content and the main content? In general, the "simplicity" of markdown seems to be taking away a lot of granular control that people use LaTeX and Typst for.
>And surely the learning curve is not easier than Typst?
To be fair, (most) markdown is valid Quarkdown. Barrier to entry really doesnt get any lower than that. Of course the learning curve is not fully synonymous with the barrier to entry, but it's a significant part.
And "learning curve" is really such a subjective quality. Kinda fucked from the start once you put it in a comparison table. Explicit features are more objective but even then sometimes products dont NEED certain features because of their design.
I guess that the similarity of the names come from different places, and in this case might be a remembrance of QuarkXPress. It's convergent evolution! :D
Was going to ask the same question. Was talking to a friend just 2 days ago who redid all his lecture scripts with quarto and embedded the lecture presentations. Looked neat. Also that quarto interacts well with R studio and jupyter notebooks comes as a big plus.
But I always hate it when a templating language grows function calls and all of that. Maybe it makes sense in this context, I'm not sure.
But if you end up using it together with another language, maybe for server side rendering or some kind of document from data generation, you quickly realize that switching between the two languages wastes a lot of time, and the templating language is never as powerful as the "real" language. So I prefer JSX, or something like Javascript's tagged template literals. Something where you use a real programming language, but where the context of the document is understood, so you don't have to worry about escaping or XSS.
This, Typst, etc etc are primarily typesetting systems for papers.
I would love alternatives to HTML or whatever, but I tried Typst too and it's very clear that the authors only really care about typesetting for papers and other long form prose. Stuff like forms, invoices, flyers, handouts, leaflets, business cards -- an afterthought, at best.
Edit: Actually I was thinking of Sile not Typst, but I think the same applies to Typst too. I didn't dig into Typst too much because it was commercial though.
> Stuff like forms, invoices, flyers, handouts, leaflets, business cards -- an afterthought, at best.
It is because you can typeset beautiful long text algorithmically and all these small forms like invoices and flyers are more graphical design than typesetting: you need to place many small elements precisely, not relative to each other but to the edges of the page / optical centers / etc. It is not very convenient without WYSIWYG. Possible, yes, but will require many trial-and-error when in WYSIWYG layout program can be done from first try.
Think about tabloids too: text, which wraps around non-rectangualr images, cut-outs, etc. Hard to do without seeing what you do, only with text and coordinates.
Is there any reason why you can't use Typst for any of the stuff you mentioned? I can't see why you couldn't (except for interactive forms, which is already being worked on [1]. The pdf-writer low-level backend seems to have already implemented support for form fields, so it seems like a matter of time until it is implemented in Typst).
The online editor is commercial. They have a github repository releasing Typst under an Apache 2.0 license for free. I installed it using cargo (Rust), and don't use the online editor.
You can use typst locally and bypass the commercial bits. It is really easy to create different kinds of documents with it. I have been using it to create slides and handouts, and for that I already find it much easier to use than the alternatives.
My first "real" usecase for Typst was a poster [0], since it was much easier than doing it in LaTeX. It's missing some features, like wrapping around figures and flowing text between boxes, but TeX doesn't have the second either and both are planned in Typst.
Since 70% of comments under each of these posts are always "why not LaTeX?!", I want to start by reaffirming: yes, I do want a modern Markdown-based typesetting system. There even is a place of several of them. It would be absolutely nice to replace LaTeX, simply because it's old trash with remarkably inconvenient syntax, so, yes, a system with full control over markup is desirable. And if it necessarily increases verbosity, then there absolutely is a place for something "just a touch more powerful than markdown".
However, at a glance it doesn't strike me as what I was looking for. There aren't too many examples, but it seems like it leans heavier towards "just a touch more powerful than markdown" rather than to "replace LaTeX" (or Typst, for that matter). And for the first scenario to play out, it must be really seamless to use. This one doesn't seem to be.
1. Just to take care of the elephant in the room: JVM. Same as many others, I won't even bother installing it to try it out, so it doesn't help virality much.
2. I don't like the syntax. It needs to be as compatible with plain markdown as possible, and this one isn't quite. My main issue is with argument to a function being tabulated. It seems like it will lead to the whole document being tabulated. It is a natural for markdown-compatible add-ons to employ a code/monospace blocks, but ```plugin-name is a better way to do it, because it doesn't mean you have to reformat your whole document when you decide to step off from plain markdown.
3. Since a "better markdown" is something more suitable for something that starts as your personal notes (if you are specifically working on preparing a document for publishing, indeed you can just do it in LaTeX as well), I suppose it's only useful to an extent it is integrated into your notetaking app. Surely, there are still some people who do it in Emacs or Vim, but even such a retrograde as myself eventually moved on to Obsidian. I want ways to control my document structure better inside my notetaking app with a potential ability to publish. But as a standalone thing, I'm not sure why would I use it. At least Typst has a proprietary online editor. I suppose, that's also how nearly everyone uses it.
You know what, while you're at it, I might as well bring it up. How about XML?
I haven't really tried writing large pieces of text in it but I am already seriously considering. All other alternatives are too complicated and have a learning curve that gets in the way of writing itself. With XML, I'd be able to define my own tags and run them by a parser later on to auto-generate indexable footnotes, and create my own ways of structuring text besides the usual ones (chapters, sections, etcetera). Has anyone tried this approach?
Well basic markdown is super useful to do stuff quickly.
Problem is when people started to build systems upon systems upon something that should not be used for more complicated cases.
Maybe not a problem because I don't care but I just see how loads of things that someone created to be "just that" someone takes without understanding and builds on top instead of understanding limitations and scope of the initial idea or system.
It is "oh it is missing a feature" - where it is "no it wasn't built to do that".
I have seen notepad in windows shipping some formatting features, I don't see that as an improvement. Notepad was notepad for purpose.
If 2005 text editors autocomplete made it easy to balance and indent html/xml tags and syntax highlighting like today, would JSON, Yaml, Markdown have taken off? In The Art of Unix Programming from 2003, the author states editing xml by hand is torture, hence we must invent unique text formats and parsers for the same.
Ah yes, writing my notes down in css and html. My favorite!
Seriously though, every time some new hotness comes along, you don’t really have to use it or even waste your time looking at it. Markdown will likely be here after all of its derivatives are long gone.
I strongly suggest that the greet call uses a slightly different syntax (e.g. two dots) as the system otherwise can't introduce new keywords without risking conflict with function names in existing documents.
Does it need more keywords? This syntax reminds me of Smalltalk syntax a little and Smalltalk famously got away with merely 6 keywords. I didn't check the syntax in detail for quarkdown, and I don't expect it to be as well thought out as Smalltalk, but it is quite possible to get away with only few keywords. Question is then how complete their concept is right now. Also there could be a versioning mechanism, that labels a document as for a specific version of Quarkdown.
> What could be mistaken for a planet is actually a quark or, more specifically, a down quark, an elementary particle that is a major constituent of matter: they give life to every complex structure we know of, while also being one of the lightest objects in existence.
Cool project, but seems dangerous to use the word “Quark” in a publishing context RE: QuarkXPress:
I like it for what it is, a layer on top of markdown. That said, the main usage of markdown for me is that it's just the content and it doesn't have any opinions on the layout let alone logic.
I can add those with the use of css/js for web and interpreters and themes for print/non web.
Interested in this! Recently wrote a thesis. Wanted to use markdown, but that had too many limitations.
After learning and using LaTeX for a bit I got used to it, but the overall experience of setting it up and its usability leaves a lot of room for improvements. But on the other hand it's established in academic writing.
Do hope to see something based on markdown be able to replace LaTeX in the future.
With Emacs and AUCTeX and a few macros for tab completion I could generally transcribe a math lecture in real time. If you're using completion then the verbosity isn't a downside and in fact helps add structure for automation.
The main drawback for writing something like a thesis is that LaTeX not great to outline in. I think for my thesis I ended up doing initial drafts in org-mode and exporting into LaTeX to view it.
Then once the overall structure took shape I edited the LaTeX directly. Otherwise you end up having to embed LaTeX markup in your markdown doc because markdown is underspecified compared to TeX.
Quarto is probably what you're looking for. It's what we've been using for scientific publications in gov science research labs the past couple of years. Can output to LaTeX and incorporate templates and such.
Very intriguing. I write my resume in a blend of LaTeX and Markdown, use Pandoc to convert the file to LaTeX, which then gets turned into a PDF. This might be a tidier solution on the front end, though I like my current flow because the maturity of all the tools means I can come back to my resume after several years and it'll still compile.
The comparison to LaTeX is a bit unfair... the latex code is much larger than it needs to, and does things that the quarkdown doesn't (like floating the figure in the page).
Once you remove that, both versions look essentially equivalent and just as readable.
I would like to have a compiled demo PDF available for download, along with a direct comparison of the same paper created in LaTeX. I would like to see the differences both on screen and in print.
Is this standalone, as in: an actual file format people can use? From their website it looks like it won't work without using their service or hosting something yourself?
Because muscle-memory is a powerful force, and it's a convenient universal input language.
It's why after years of powershell I still reflexively reach for "ls" not "Get-ChildItem"
( "ls" is aliased by default to Get-ChildItem thankfully! )
Markdown is familiar, easy to use, and very human readable and editable without fear of breaking a compilation step.
Typesetting languages however, TeX, LaTex, postscript or the nightmare of the PDF spec, are not.
If I send someone who doesn't know anything about a document markdown, then there's a good chance they'll be able to make simple edits in their favourite text editor and not screw things up.
If I send someone HTML, they'll likely be able to do simple edits but there's greater risk of breaking elements or styling. Not as bad as with stricter languages, but still significantly more chance than with markdown annotations.
If I send someone some TeX, they'll probably not know what to even do with it, they'll likely get confused and ask for a file format they can use.
Reducing how many different languages we have to master is important, so I think it's great if there's a way to write everything in flavours of markdown.
Write markdown everywhere, and let the backends compile to relevant outputs.
In this instance, it's left perhaps a bit function-heavy so there's still larger "risk", but that's likely something that can be solved through templating.
We have flavours of MD, for github issues, for typesetting, for stackoverflow questions. Slack and Discord have (limited) MD support. We can write blogs in MD through jekyll.
MD is everywhere, it's a convenient universal input language.
I was a bit surprised to see Kotlin as the main language (I quite like it, but had to move away from JRE-based anything) I hope it can be built as a native binary...
There is kotlin native these days; so not impossible.
Kotlin is kind of nice for this stuff; which is probably why they picked it. IMHO Kotlin is undervalued as a python replacement; it's pretty convenient for a lot of data processing stuff. And being able to use whatever Java libraries are around is also not a bad thing.
Anyway since it is kotlin, you could use kts (the scripting support). You'd still need a jre and kotlin installed but it would make it easy to invoke from the command line and it would be able to pull in jar file dependencies straight from maven central. There might also be a possible path to build this thing via Graal and package it up as native. Another option is to package everything with docker and call it with a simple shell script. And finally, Kotlin has a native compiler as well but I assume there are too many jvm dependencies to be able to use that.
So, there are a few options here to make using this more convenient.
I get that people don't like the braces in TeX but ... :-)
I'm only half sarcastic here, I don't like them either. I have recently been using pandoc[1] to do the things they are talking about, I had added some stuff in perl using the Template Toolkit[2] to make HTML pages. My issue is that I have very different fugue states for writing vs. coding. Switching states breaks my flow so I've been trying to make the two modes as orthogonal as possible.
I'm curious if anyone has used something like this to go straight to PNG. My use case is that I have a surplus epaper display that can display pngs it fetches from the network and I've been forwarding it my todo list. Have been doing this with a LuaTeX flow but would like something a bit more seamless.
Any reason to not just use Pandoc? It's been 15 years since I ran into this problem, but even at that point Pandoc made it pretty easy to go from Markdown -> Latex and then render from Latex -> PDF. The benefit of this pipeline is that if I needed to fine tune any of the Latex there was flexibility to do so.
Which is where MyST [0] gets its structural cues. That's another alternative missing from the comparison table of this project, and an interesting one for how much it seems to be going for the science community that loves Jupyter notebooks.
Had a chance to read the wiki/docs deeper. Quarkdown seems to use puppeteer and chrome-print-to-pdf to generate PDF from HTML [1].
So, aside from the more minimal format or Markdown compared to HTML, I don't see much appeal in quarkdown compared to feeding HTML to a headless chrome instance.
But it is a cool project if one wants to turn a bunch of markdown files to say a book or an article.
This is so powerful, it makes me wonder why they didn't just make a new markdowny syntax for Latex so they could reuse everything from the Latex ecosystem. A bit like what CoffeeScript was for JavaScript, I mean.
That assumes that the only issue with LaTeX is its syntax. Other issues I can think of are that LaTeX doesn't generate HTML and that LaTeX is completely Unicode-disabled.
I've recently started rewriting basic process documentation into markdown, which also needs to be printed with a simple header and footer. I found that rendering to html, adding pagedjs cdn, and adding a styled header & footer tags looks and prints great already.
It's surprising how close html & css are to being a pretty good layout system.
I have been generating documents for a while using https://github.com/enhuiz/eisvogel. It's nice to use markdown, but I feel really limited, and can't do much customization.
I want to move on from LaTeX syntax as much as the next person (hard to read, etc.),
But as a consumer/user, wouldn't a more uniform syntax (large adoption of Typst, etc) be preferable to having multiple different typesetting systems. I feel like the prevailing aspect of LaTeX is its universality?
Agreed, it's about _imperative_ vs _declarative_ languages.
The problem with languages like LaTeX etc. is they treat a document as a linear sequence of instructions: "write this text", "switch to justify right" etc. - I think that made sense when LaTeX was created, but publishing has come a long way and imperative thinking doesn't help.
A declarative form of document is the way forward. HTML is -kind of- like that, but unfortunately the assumption that a document is a linear list of stuff is still in there. That's one reason it doesn't work well for print.
Some things I would want to see in a typesetting system:
- Having a typesetting quality and control like TeX does, including mathematical typesetting, although improvements could be made to that, too. (I think I would also like the syntax more like TeX has)
- You can include PostScript codes within the document which can run during the typesetting process (rather than only during output), therefore allowing it to affect decisions of page breaks, etc, as well as allowing PostScript to draw diagrams and control text rendering. (I had written a PostScript program to load PK fonts, so that would make it possible to use PK fonts from TeX as well.)
- Full support for non-Unicode text (without converting it internally to Unicode). (It is OK if it also supports Unicode as long as the code to support Unicode is avoided when not using it (in the entire document or in a part of it).)
Looks amazing of course, but usually it is the nitty gritty details where the mess and headache begins. How can I be confident that this is a viable alternative to fully fledged and mature alternatives like LaTeX?
I've started using presenterm for markdown presentations. Given that markdown is just a format, a comprehensive comparison should find the tools using markdown to export to pdf and epub.
I felt the same way, though once I scrolled down to the LaTeX comparison it was more obvious. The first few code examples being how you define a function don't lend themselves to showcasing how markdown-esque the actual usage is.
EDIT: I was just teasing, probably inappropriately my apologies. I use org-mode -> LaTeX for a similar markdown to article flow. I think it's a good idea and the results look nice.
If the LLM's are starting to output Quarkdown by default - even just one provider (like OpenAI), this will catch on like wildfire. The limitations of Markdown is getting a bit old.
Maybe look at Quarto? Almost every project I start now begins with `quarto project create`. From there I can pivot the material into HTML, .docx, PDF, .PPTX, Typst, LaTeX, and all of them simultaneously.
There's plenty of of "proper" markup languages and full programming languages to actually write code in.
Why do we need a hybrid program like this, which is not as simple as pure markup, and is not as powerful as a proper templating language?
I personally just run markdown -> HTML/CSS -> python templating (Jinja or something) -> PDF/HTML
As a dev, I find this works the best for me. But I also cannot imagine that learning Quarkdown would improve my workflow meaningfully, and I also cannot imagine recommending someone learn such a niche product instead of having them learn HTML/CSS and Python (Jinja if they need fancy). Seems like a comparable amount of effort.
That's why these things don't go anywhere. If I need to write formatting details, it is better to use LaTeX which is a well-tested and stable language that will last for another 30 years.
Could definitely see using this for docs. We end up with HTML scattered through our markdown files whenever we need something beyond basic formatting, which is ugly. The ecosystem support is the real question though - Markdown works everywhere because it's been around forever.
thangalin|9 months ago
https://gitlab.com/DaveJarvis/KeenWrite/-/blob/main/docs/ima...
I developed KeenWrite to help write a sci-fi novel where I can use variables for character names, places, etc. See the tutorials[2] for details.
For anyone still using pandoc and shell scripts, my Typesetting Markdown[3] series describes building a script-based infrastructure for converting Markdown into PDF.
[1]: https://keenwrite.com/
[2]: https://www.youtube.com/watch?v=CFCqe3A5dFg&t=15s
[3]: https://dave.autonoma.ca/blog/2019/05/22/typesetting-markdow...
techtalsky|8 months ago
Upon launch, I'm presented with three panes. I've got a MarkDown authoring interface and an output preview. Great. I drop in some markdown and it renders.
Then I have a "variables.yaml" pane open with three little controls, "Create", "Rename", and "Delete". Ok... I'm editing a YAML file. But it's a clunky nested node editor. People can edit a MarkDown file but you don't think it's faster to simply let people edit YAML in text?
So, I get it, I'm editing a YAML file that stores metadata about... SOMETHING about my document output. Except I don't have a single example of a variable. Not a single one. I have no idea what variables are available and exploring every single menu option tells me nothing. Help only provides a small about page with no link to the documentation.
So, I go to keenwrite.com and click documentation. It takes me to a single GitLab readme that talks about different command line launch options, and then finally how to begin to use metadata, but the options all revolve around creating an .Rmd file and using R or creating a "definitions.yaml" instead of a "variables.yaml" in a seperate editor.
This is the moment I realize there's no chance this tool is going to be useful for me.
yndoendo|9 months ago
So far LaTex has been the only solution to allow binding shared sections into multiple document builds. These are for internal and customer facing information. Only binding duplication is in the revision overview sections pertaining to each document build.
structural|9 months ago
Kinda surprising that it isn't mentioned in their feature comparison matrix at all.
msravi|9 months ago
Also how do you implement things like different page numbering for front matter content and the main content? In general, the "simplicity" of markdown seems to be taking away a lot of granular control that people use LaTeX and Typst for.
junon|9 months ago
shark1|9 months ago
blenderob|9 months ago
Surely LaTeX has full scripting ability even though I wouldn't wish such a punishment on anyone.
Surely Quarkdown's gibberish like syntax is not more concise and more readable than Typst?
And surely the learning curve is not easier than Typst? I'd say the learning curve is more or less the same as Typst.
Surely LaTeX can also produce HTML with tex4ht?
nonethewiser|9 months ago
To be fair, (most) markdown is valid Quarkdown. Barrier to entry really doesnt get any lower than that. Of course the learning curve is not fully synonymous with the barrier to entry, but it's a significant part.
And "learning curve" is really such a subjective quality. Kinda fucked from the start once you put it in a comparison table. Explicit features are more objective but even then sometimes products dont NEED certain features because of their design.
flenserboy|9 months ago
kccqzy|9 months ago
The comparison table is clearly inaccurate.
account-5|9 months ago
[0] https://quarto.org/
jsilence|9 months ago
tecleandor|9 months ago
riedel|9 months ago
pinoy420|9 months ago
[deleted]
looneysquash|9 months ago
But I always hate it when a templating language grows function calls and all of that. Maybe it makes sense in this context, I'm not sure.
But if you end up using it together with another language, maybe for server side rendering or some kind of document from data generation, you quickly realize that switching between the two languages wastes a lot of time, and the templating language is never as powerful as the "real" language. So I prefer JSX, or something like Javascript's tagged template literals. Something where you use a real programming language, but where the context of the document is understood, so you don't have to worry about escaping or XSS.
rendaw|9 months ago
I would love alternatives to HTML or whatever, but I tried Typst too and it's very clear that the authors only really care about typesetting for papers and other long form prose. Stuff like forms, invoices, flyers, handouts, leaflets, business cards -- an afterthought, at best.
Edit: Actually I was thinking of Sile not Typst, but I think the same applies to Typst too. I didn't dig into Typst too much because it was commercial though.
blacklion|9 months ago
It is because you can typeset beautiful long text algorithmically and all these small forms like invoices and flyers are more graphical design than typesetting: you need to place many small elements precisely, not relative to each other but to the edges of the page / optical centers / etc. It is not very convenient without WYSIWYG. Possible, yes, but will require many trial-and-error when in WYSIWYG layout program can be done from first try.
Think about tabloids too: text, which wraps around non-rectangualr images, cut-outs, etc. Hard to do without seeing what you do, only with text and coordinates.
Edit: typo test → text.
andy12_|9 months ago
[1] https://github.com/typst/typst/issues/1765
freefrog334433|9 months ago
fmoralesc|9 months ago
dvdkon|9 months ago
[0]: https://dvdkon.ggu.cz/projects/pppql/poster.pdf
kzrdude|9 months ago
It's very satisfying to play with visualizations in Typst, especially since it updates the output so fast (instant for small projects).
dleeftink|9 months ago
[0]: https://github.com/pagedjs/pagedjs
davidpapermill|9 months ago
[deleted]
cbarrick|9 months ago
Quarkdown:
rST:krick|9 months ago
However, at a glance it doesn't strike me as what I was looking for. There aren't too many examples, but it seems like it leans heavier towards "just a touch more powerful than markdown" rather than to "replace LaTeX" (or Typst, for that matter). And for the first scenario to play out, it must be really seamless to use. This one doesn't seem to be.
1. Just to take care of the elephant in the room: JVM. Same as many others, I won't even bother installing it to try it out, so it doesn't help virality much.
2. I don't like the syntax. It needs to be as compatible with plain markdown as possible, and this one isn't quite. My main issue is with argument to a function being tabulated. It seems like it will lead to the whole document being tabulated. It is a natural for markdown-compatible add-ons to employ a code/monospace blocks, but ```plugin-name is a better way to do it, because it doesn't mean you have to reformat your whole document when you decide to step off from plain markdown.
3. Since a "better markdown" is something more suitable for something that starts as your personal notes (if you are specifically working on preparing a document for publishing, indeed you can just do it in LaTeX as well), I suppose it's only useful to an extent it is integrated into your notetaking app. Surely, there are still some people who do it in Emacs or Vim, but even such a retrograde as myself eventually moved on to Obsidian. I want ways to control my document structure better inside my notetaking app with a potential ability to publish. But as a standalone thing, I'm not sure why would I use it. At least Typst has a proprietary online editor. I suppose, that's also how nearly everyone uses it.
deppep|9 months ago
AmazingTurtle|9 months ago
rTX5CMRXIfFG|9 months ago
I haven't really tried writing large pieces of text in it but I am already seriously considering. All other alternatives are too complicated and have a learning curve that gets in the way of writing itself. With XML, I'd be able to define my own tags and run them by a parser later on to auto-generate indexable footnotes, and create my own ways of structuring text besides the usual ones (chapters, sections, etcetera). Has anyone tried this approach?
ozim|9 months ago
Problem is when people started to build systems upon systems upon something that should not be used for more complicated cases.
Maybe not a problem because I don't care but I just see how loads of things that someone created to be "just that" someone takes without understanding and builds on top instead of understanding limitations and scope of the initial idea or system.
It is "oh it is missing a feature" - where it is "no it wasn't built to do that".
I have seen notepad in windows shipping some formatting features, I don't see that as an improvement. Notepad was notepad for purpose.
setopt|9 months ago
eGQjxkKF6fif|9 months ago
Having to know and learn 300 clunky frameworks, 97 different syntaxes it gets old.
HTML. CSS. Javascript.
Ask the AI to give me a markdown to html converter, good2go
aitchnyu|9 months ago
360MustangScope|9 months ago
Seriously though, every time some new hotness comes along, you don’t really have to use it or even waste your time looking at it. Markdown will likely be here after all of its derivatives are long gone.
silvestrov|9 months ago
zelphirkalt|9 months ago
maxloh|9 months ago
That way any new keywords won't be a backward incompatible change.
Lammy|9 months ago
Cool project, but seems dangerous to use the word “Quark” in a publishing context RE: QuarkXPress:
- https://tsdr.uspto.gov/#caseNumber=90886976&caseSearchType=U...
- https://tsdr.uspto.gov/#caseNumber=97009034&caseSearchType=U...
(Why do they have two for the same word?)
TheEdonian|9 months ago
I can add those with the use of css/js for web and interpreters and themes for print/non web.
bryanhogan|9 months ago
After learning and using LaTeX for a bit I got used to it, but the overall experience of setting it up and its usability leaves a lot of room for improvements. But on the other hand it's established in academic writing.
Do hope to see something based on markdown be able to replace LaTeX in the future.
ants_everywhere|9 months ago
The main drawback for writing something like a thesis is that LaTeX not great to outline in. I think for my thesis I ended up doing initial drafts in org-mode and exporting into LaTeX to view it.
Then once the overall structure took shape I edited the LaTeX directly. Otherwise you end up having to embed LaTeX markup in your markdown doc because markdown is underspecified compared to TeX.
Onawa|9 months ago
ryukoposting|9 months ago
francislavoie|9 months ago
codychan|9 months ago
xvfLJfx9|9 months ago
g0db1t|9 months ago
[deleted]
enriquto|9 months ago
Once you remove that, both versions look essentially equivalent and just as readable.
eviks|9 months ago
randomtoast|9 months ago
quaintdev|9 months ago
atoav|9 months ago
jamesgill|9 months ago
xnorswap|9 months ago
It's why after years of powershell I still reflexively reach for "ls" not "Get-ChildItem"
( "ls" is aliased by default to Get-ChildItem thankfully! )
Markdown is familiar, easy to use, and very human readable and editable without fear of breaking a compilation step.
Typesetting languages however, TeX, LaTex, postscript or the nightmare of the PDF spec, are not.
If I send someone who doesn't know anything about a document markdown, then there's a good chance they'll be able to make simple edits in their favourite text editor and not screw things up.
If I send someone HTML, they'll likely be able to do simple edits but there's greater risk of breaking elements or styling. Not as bad as with stricter languages, but still significantly more chance than with markdown annotations.
If I send someone some TeX, they'll probably not know what to even do with it, they'll likely get confused and ask for a file format they can use.
Reducing how many different languages we have to master is important, so I think it's great if there's a way to write everything in flavours of markdown.
Write markdown everywhere, and let the backends compile to relevant outputs.
In this instance, it's left perhaps a bit function-heavy so there's still larger "risk", but that's likely something that can be solved through templating.
We have flavours of MD, for github issues, for typesetting, for stackoverflow questions. Slack and Discord have (limited) MD support. We can write blogs in MD through jekyll.
MD is everywhere, it's a convenient universal input language.
blenderob|9 months ago
rcarmo|9 months ago
jillesvangurp|9 months ago
Kotlin is kind of nice for this stuff; which is probably why they picked it. IMHO Kotlin is undervalued as a python replacement; it's pretty convenient for a lot of data processing stuff. And being able to use whatever Java libraries are around is also not a bad thing.
Anyway since it is kotlin, you could use kts (the scripting support). You'd still need a jre and kotlin installed but it would make it easy to invoke from the command line and it would be able to pull in jar file dependencies straight from maven central. There might also be a possible path to build this thing via Graal and package it up as native. Another option is to package everything with docker and call it with a simple shell script. And finally, Kotlin has a native compiler as well but I assume there are too many jvm dependencies to be able to use that.
So, there are a few options here to make using this more convenient.
ChuckMcM|9 months ago
I'm only half sarcastic here, I don't like them either. I have recently been using pandoc[1] to do the things they are talking about, I had added some stuff in perl using the Template Toolkit[2] to make HTML pages. My issue is that I have very different fugue states for writing vs. coding. Switching states breaks my flow so I've been trying to make the two modes as orthogonal as possible.
I'm curious if anyone has used something like this to go straight to PNG. My use case is that I have a surplus epaper display that can display pngs it fetches from the network and I've been forwarding it my todo list. Have been doing this with a LuaTeX flow but would like something a bit more seamless.
[1] Pandoc -- https://pandoc.org/
[2] Template Toolkit -- https://template-toolkit.org/
yowlingcat|9 months ago
bovermyer|9 months ago
cluckindan|9 months ago
https://github.com/iamgio/quarkdown/blob/main/mock/images.qm...
formerly_proven|9 months ago
WorldMaker|9 months ago
[0] https://mystmd.org/
skwee357|9 months ago
As some who uses headless chrome to turn html into pdf (for invoices), I have been looking for something simpler and faster.
I tried typst, but it felt messy to me. I wonder if quarkdown offers more streamlined experience
skwee357|9 months ago
So, aside from the more minimal format or Markdown compared to HTML, I don't see much appeal in quarkdown compared to feeding HTML to a headless chrome instance.
But it is a cool project if one wants to turn a bunch of markdown files to say a book or an article.
[1] https://github.com/iamgio/quarkdown/wiki/pdf-export
promiseofbeans|9 months ago
https://weasyprint.org/
Also the only good implementation of web layout/rendering I've seen done in python.
dev_l1x_be|9 months ago
What exactly is messy about Typst?
skrebbel|9 months ago
Timwi|9 months ago
eviks|9 months ago
DrNosferatu|9 months ago
infogulch|9 months ago
It's surprising how close html & css are to being a pretty good layout system.
Faelian2|9 months ago
I have been generating documents for a while using https://github.com/enhuiz/eisvogel. It's nice to use markdown, but I feel really limited, and can't do much customization.
I would love to see some templates for this.
RollingRo11|9 months ago
But as a consumer/user, wouldn't a more uniform syntax (large adoption of Typst, etc) be preferable to having multiple different typesetting systems. I feel like the prevailing aspect of LaTeX is its universality?
(Then again, who hates options).
darkhorse13|9 months ago
klez|9 months ago
codedokode|9 months ago
Also Markdown is pretty bad format, for example it doesn't even have a specification, lot of ambiguity etc. Avoid it.
davidpapermill|9 months ago
The problem with languages like LaTeX etc. is they treat a document as a linear sequence of instructions: "write this text", "switch to justify right" etc. - I think that made sense when LaTeX was created, but publishing has come a long way and imperative thinking doesn't help.
A declarative form of document is the way forward. HTML is -kind of- like that, but unfortunately the assumption that a document is a linear list of stuff is still in there. That's one reason it doesn't work well for print.
zzo38computer|9 months ago
- Having a typesetting quality and control like TeX does, including mathematical typesetting, although improvements could be made to that, too. (I think I would also like the syntax more like TeX has)
- You can include PostScript codes within the document which can run during the typesetting process (rather than only during output), therefore allowing it to affect decisions of page breaks, etc, as well as allowing PostScript to draw diagrams and control text rendering. (I had written a PostScript program to load PK fonts, so that would make it possible to use PK fonts from TeX as well.)
- Full support for non-Unicode text (without converting it internally to Unicode). (It is OK if it also supports Unicode as long as the code to support Unicode is avoided when not using it (in the entire document or in a part of it).)
cAtte_|9 months ago
petalmind|9 months ago
jinay|9 months ago
I'd love to see how far I can take this by giving it to an LLM and asking it to format for me with Quarkdown.
coherentpony|9 months ago
Oh my god. It just occurred to me that LLMs may have a better experience “browsing the internet” than humans do.
That is so tragically depressing.
jdthedisciple|9 months ago
SuperV1234|9 months ago
https://github.com/vittorioromeo/majsdown
freefrog334433|9 months ago
silveraxe93|9 months ago
- https://marp.app/
asplake|9 months ago
pedro_movai|9 months ago
https://github.com/pedroth/nabladown.js
charlie0|9 months ago
glenngillen|9 months ago
ouked|9 months ago
dariosalvi78|9 months ago
unknown|9 months ago
[deleted]
Aloisius|9 months ago
apatheticonion|9 months ago
artemonster|9 months ago
ekianjo|9 months ago
ants_everywhere|9 months ago
EDIT: I was just teasing, probably inappropriately my apologies. I use org-mode -> LaTeX for a similar markdown to article flow. I think it's a good idea and the results look nice.
blueflow|9 months ago
dvfjsdhgfv|9 months ago
GZGavinZhao|9 months ago
sgt|9 months ago
andrepd|9 months ago
worldsavior|9 months ago
bowsamic|9 months ago
Is very slightly more concise syntax worth it?
speerer|9 months ago
Onawa|9 months ago
majkinetor|9 months ago
As a comparison to scripting features of Quarkdown, above uses macros plugin which enables python scripting
AceJohnny2|9 months ago
revskill|9 months ago
eviks|9 months ago
nextaccountic|9 months ago
akagusu|9 months ago
> Java 17 or higher is required.
klez|9 months ago
bigbuppo|9 months ago
robinsonb5|9 months ago
tinthedev|9 months ago
Markdown is for keeping things simple.
There's plenty of of "proper" markup languages and full programming languages to actually write code in.
Why do we need a hybrid program like this, which is not as simple as pure markup, and is not as powerful as a proper templating language?
I personally just run markdown -> HTML/CSS -> python templating (Jinja or something) -> PDF/HTML
As a dev, I find this works the best for me. But I also cannot imagine that learning Quarkdown would improve my workflow meaningfully, and I also cannot imagine recommending someone learn such a niche product instead of having them learn HTML/CSS and Python (Jinja if they need fancy). Seems like a comparable amount of effort.
tiffanyh|9 months ago
Which is why you see Typst it's strongest competitor in the Comparison Chart.
andai|9 months ago
My ideas start in Obsidian (Markdown) and then I use pandoc and add a bunch of cursed inline LaTeX hacks to the Markdown for the final product.
I guess cursed hacks are part of any workflow, but I am definitely going to check this out.
throwawaymaths|9 months ago
coliveira|9 months ago
beneboy|9 months ago
MisterTea|9 months ago
Unix philosophy vs highly integrated vertical Microsoft style applications. One benefits users, the other, the vendor.
nonethewiser|9 months ago
Uh...
maybe thats why they just want markdown -> PDF/HTML
unknown|9 months ago
[deleted]
g0db1t|9 months ago
[deleted]
blacklion|9 months ago
[deleted]
throwawaymaths|9 months ago