otherjoel
commented
4 years ago Let’s see if I understand you. Under the current designs my Pollen tag functions each branch depending on the output format, and produce either HTML-esque x-expressions, or q-expressions that I can pass to Quad. You are proposing that perhaps Quad also have an HTML writer that tries to emit web pages that look close to the PDF output for the same q-expression? So that if I want, I can just have my Pollen project emit q-expressions only, and then have it tell Quad whether I want to make web pages or PDF files from those q-expression.
I don’t see this approach as taking anything away from Pollen, since I can still do what I was doing before if I want to (and I probably will). I think it could potentially be nicer for people who want web pages alongside their PDF files but don’t necessarily want to fiddle with HTML/CSS.
However, it would involve making lots of design decisions about how to translate q-expressions designed for print into a web context. Personally I’ve done so much thinking about moving things the other direction that this is a little hard to think about. I imagine the simplest thing would be just dropping directives that don’t apply to the web, like page sizes, page breaks, etc. Then, too, the HTML output will need to be at least somewhat customizable in order to be useful. (For example, people may want ways to link multiple pages together, as with multiple-document rendering in #lang scribble/manual, or ways of integrating the pages into the design of a larger site.) You’ll have to decide the point at which you tell those people “you’ll need to do that in Pollen the old way.”
(Personally: since I already have the web piece extremely nailed down thanks to Pollen, but am excited about a pure-Racket PDF generator, my selfish hope is that efforts in this direction come after I am able to ditch most of my LaTeX templates forever 😎)
mbutterick
odanoburu
I’m thinking more about where Quad fits into the Pollen toolchain. For instance, so far I’ve thought about Quad mostly as a way of rendering PDF, including from Pollen sources. Which it can do today, in a simplified way.
But as I experiment with making
polyfiles — admittedly, something I haven’t done much of in the past — I’m wondering if Quad wants to slot in higher. What I notice is that most of the tag functions for apolyfile have to branch based on(current-poly-target). Which is fine, as far as it goes, and provides fine control for each output target, for those who want that.But most of the formatting chores that occupy human consciousness are more vanilla — e.g., “center this text", "make this bold", etc. So I’m wondering if it would make more sense to move Quad up in the hierarchy. For instance, make each tag function in a
polyfile emit consistent Quad markup (regardless of the output format), and then let Quad figure out the rendering based on the output format.I suppose this is similar to what Racket’s Scribble system already does, in terms of having multiple renderers (Markdown, HTML, LaTeX) that can generate output from a single Scribble file. Those renderers are notoriously difficult to customize, however, and indeed that’s part of the reason I made Pollen in the first place — to have very precise control of output, without having to contend with Scribble’s opinions. By that view, maybe making Quad more opinionated would send Pollen in a direction nobody wants.