Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gribouille 0.3.0: A Grammar of Graphics for Typst

mickael.canouil.fr

Post reply on HN
Print view View original

91–100 of 101 posts

Re: Gribouille 0.3.0: A Grammar of Graphics for Typst

#91

Post by josephg »

tlarkworthy wrote: post #10
adamnemecek wrote: post #6

Earlier quoted context omitted.

The problem with markdown is that it's not extensible and that there is no spec. Essentially all READMEs would be better off using typst, they would make for better READMEs.

Of course it's extensible, you can put HTML in it, and HTML is extensible.

But you can't abstract. I can't make a custom template for an image + caption, and use it throughout my markdown document.

You can do some pretty wild stuff with html. But if you do, you get an unreadable jumble of markdown and HTML. It loses the single advantage of markdown - which is that its human readable as a text file.

Re: Gribouille 0.3.0: A Grammar of Graphics for Typst

#92

Post by josephg »

mastermage wrote: post #15
josephg wrote: post #12

Earlier quoted context omitted.

Right; but markdown has expanded beyond that niche. Lots of projects use markdown for other stuff - like mdbook, or for blogs. I think markdown is a great format for readme files. But for real documentation, the added features of typst are fantastic. Like, being able to write scripts, have figures and custom styling, populate data from JSON files, plugins, typography, numbered sections, footnotes and all sorts of oth…

Fascinating Ideas I love hearing opinions on this, it enriches me. I do belive that atleast simple files like for example READMEs will stay and perhaps are better to stay as Markdown. One advantage that has is that while scripting is cool, It make the document not plain text readable which is a tradeoff one can argue.

Yes, I agree. But not all technical writing is README files. For books and long form articles, markdown simply isn't powerful enough. And for stuff like this, nobody cares whether or not the source is readable as plain text.

Re: Gribouille 0.3.0: A Grammar of Graphics for Typst

#93

Post by tlarkworthy »

josephg wrote: post #91
tlarkworthy wrote: post #10

Earlier quoted context omitted.

Of course it's extensible, you can put HTML in it, and HTML is extensible.

But you can't abstract. I can't make a custom template for an image + caption, and use it throughout my markdown document. You can do some pretty wild stuff with html. But if you do, you get an unreadable jumble of markdown and HTML. It loses the single advantage of markdown - which is that its human readable as a text file.

HTML is human readable as a text file. It does lack abstraction though. I don't actually like markdown much but it is quicker for prose and when I want my images styled a certain way I drop to HTML

Re: Gribouille 0.3.0: A Grammar of Graphics for Typst

#94

Post by josephg »

tlarkworthy wrote: post #93
josephg wrote: post #91

Earlier quoted context omitted.

But you can't abstract. I can't make a custom template for an image + caption, and use it throughout my markdown document. You can do some pretty wild stuff with html. But if you do, you get an unreadable jumble of markdown and HTML. It loses the single advantage of markdown - which is that its human readable as a text file.

HTML is human readable as a text file. It does lack abstraction though. I don't actually like markdown much but it is quicker for prose and when I want my images styled a certain way I drop to HTML

> HTML is human readable as a text file.

It's horrible to read compared to markdown and typst.

    
Some cool sentence in html!


    Some cool *sentence* in **markdown!**

Re: Gribouille 0.3.0: A Grammar of Graphics for Typst

#95

Post by mcanouil »

MoonZ wrote: post #76
matijsvzuijlen wrote: post #18

Why are all the parameters full words except 'labs'? I find it jarring because to me 'lab' is short for laboratory, not label.

Jesters would say it's because author's a fan of labradors. (source: he's my neighbour)

No comment^^

Re: Gribouille 0.3.0: A Grammar of Graphics for Typst

#96

Post by mcanouil »

NiloCK wrote: post #58

Is typst a good tool for something like a flyer (eg, printable respecting fold lines) or more generically one-page posters? I see PDF as a blessed output, but it seems mostly in context of longer form typesetting -heavy workflows (books, papers), rather than design -heavy.

I do use them to make flyers and other PDF content.

You can see an example on my LinkedIn account I posted last week when travelling (it's in French). https://www.linkedin.com/feed/update/urn:li:activity:7472526...

Re: Gribouille 0.3.0: A Grammar of Graphics for Typst

#97

Post by mcanouil »

stared wrote: post #34

Interesting! If I get it right, the API is in the spirit of Observable Plot ( https://observablehq.com/plot/ ), less ggplot2. In any case, I'm curious whether aes is necessary, or whether it would suffice to drop this function entirely and just use keys in the mapping (similarly for labs). Or, more broadly, whether using patterns from other implementations of the Grammar of Graphics is a conscious decision, or some s…

That's still an open question to be honest. Whether or not I should still surface aes() or just drop it in favour of the plain dictionnary. it's indeed not really necessary, but makes it way easier for all ggplot2 (R), plotnine (Python), ggsql (SQL) users to switch or adopt Gribouille in typst.

Re: Gribouille 0.3.0: A Grammar of Graphics for Typst

#99

Post by stared »

mcanouil wrote: post #97
stared wrote: post #34

Interesting! If I get it right, the API is in the spirit of Observable Plot ( https://observablehq.com/plot/ ), less ggplot2. In any case, I'm curious whether aes is necessary, or whether it would suffice to drop this function entirely and just use keys in the mapping (similarly for labs). Or, more broadly, whether using patterns from other implementations of the Grammar of Graphics is a conscious decision, or some s…

That's still an open question to be honest. Whether or not I should still surface aes() or just drop it in favour of the plain dictionnary. it's indeed not really necessary, but makes it way easier for all ggplot2 (R), plotnine (Python), ggsql (SQL) users to switch or adopt Gribouille in typst.

My take: does something add value OR is there because were are just used to?

Gribouille is not ggplot2, or other. Syntax is different. Superficial keyword similarity is (usually) a false friend. Reusing a keyword might be useful, but keeping an unnecessary construction is (in my view), a cargo cult.

Typst itself breaks with a lot of LaTeX stuff, and it is good that it does not pretend it is LaTeX-with-Rust, but has a fresh look.

Re: Gribouille 0.3.0: A Grammar of Graphics for Typst

#100

Post by mcanouil »

stared wrote: post #99
mcanouil wrote: post #97

Earlier quoted context omitted.

That's still an open question to be honest. Whether or not I should still surface aes() or just drop it in favour of the plain dictionnary. it's indeed not really necessary, but makes it way easier for all ggplot2 (R), plotnine (Python), ggsql (SQL) users to switch or adopt Gribouille in typst.

My take: does something add value OR is there because were are just used to? Gribouille is not ggplot2, or other. Syntax is different. Superficial keyword similarity is (usually) a false friend. Reusing a keyword might be useful, but keeping an unnecessary construction is (in my view), a cargo cult. Typst itself breaks with a lot of LaTeX stuff, and it is good that it does not pretend it is LaTeX-with-Rust, but has a…

With a constructor, you get to document/validate. A plain dictionary makes this harder or virtually impossible (you most often will silently fail).

https://m.canouil.dev/gribouille/reference/core/aes.html

I already drifted apart from ggplot2/plotnine in many ways, I don't mind as long as it's not confusing.

I've opened a GitHub issue about this question (no ansers at this point): https://github.com/mcanouil/gribouille/issues/143

Post reply on HN