question for those who like poly files #26

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 poly files — 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 a poly file 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 poly file 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.

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 `poly` files — 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 a `poly` file 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 `poly` file 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.

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 😎)

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 😎)

You’ll have to decide the point at which you tell those people “you’ll need to do that in Pollen the old way.”

Good point. There are necessarily places where the translation is inexact. Furthermore nothing prevents these kind of libraries from emerging in the future. For instance I have been experimenting with a #lang resume that would produce simple résumés (similar to your #lang bookcover, though less customizable). But that’s the kind of thing that can be layered atop Pollen / Quad — it doesn’t need to be intrinsic to the system design.

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

Yes, LaTeX seems to be the recurring pain point. OK, you’ve convinced me. If Quad can substitute for LaTeX on simple-to-medium layout jobs, it will be sufficiently useful. As for the Pollen/Quad integration on poly files, I think the current system could benefit from further smoothing. But that can be a problem for another day.

> You’ll have to decide the point at which you tell those people “you’ll need to do that in Pollen the old way.” Good point. There are necessarily places where the translation is inexact. Furthermore nothing prevents these kind of libraries from emerging in the future. For instance I have been experimenting with a `#lang resume` that would produce simple résumés (similar to your `#lang bookcover`, though less customizable). But that’s the kind of thing that can be layered atop Pollen / Quad — it doesn’t need to be intrinsic to the system design. > 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 Yes, LaTeX seems to be the recurring pain point. OK, you’ve convinced me. If Quad can substitute for LaTeX on simple-to-medium layout jobs, it will be sufficiently useful. As for the Pollen/Quad integration on `poly` files, I think the current system could benefit from further smoothing. But that can be a problem for another day.

If I may say so (even if I have little experience with poly files), I like the idea of having reasonable output configured out-of-the-box, since the customizability pollen is known for is still there if the user needs it (but most users don't).

If Quad can substitute for LaTeX on simple-to-medium layout jobs, it will be sufficiently useful.

I'd be very happy with that :) I would like to try a #lang letter soon!

If I may say so (even if I have little experience with poly files), I like the idea of having reasonable output configured out-of-the-box, since the customizability pollen is known for is still there if the user needs it (but most users don't). > If Quad can substitute for LaTeX on simple-to-medium layout jobs, it will be sufficiently useful. I'd be very happy with that :) I would like to try a `#lang letter` soon!

I would like to try a #lang letter soon!

One key advantage of #lang letter or #lang resume is that it clearly announces the space where it plans to succeed. That is, it’s easier to make format-agnostic rendering work on a specific kind of document than any kind of document.

I could also see making a #lang pollen-doc-lang-maker that would be a toolkit for assembling these document-specific languages. For instance, as I’m experimenting with the résumé, I’m noticing that it’s important to have some kind of structured field entry & validation, in addition to the usual free-form markup.

But I’ll get Quad working first 😉

> I would like to try a `#lang letter` soon! One key advantage of `#lang letter` or `#lang resume` is that it clearly announces the space where it plans to succeed. That is, it’s easier to make format-agnostic rendering work on a specific kind of document than any kind of document. I could also see making a `#lang pollen-doc-lang-maker` that would be a toolkit for assembling these document-specific languages. For instance, as I’m experimenting with the résumé, I’m noticing that it’s important to have some kind of structured field entry & validation, in addition to the usual free-form markup. But I’ll get Quad working first 😉

I could also see making a #lang pollen-doc-lang-maker that would be a toolkit for assembling these document-specific languages.

that would be nice!

But I’ll get Quad working first

may I ask what is missing? is there a roadmap/TODO? I'm curious

> I could also see making a #lang pollen-doc-lang-maker that would be a toolkit for assembling these document-specific languages. that would be nice! > But I’ll get Quad working first may I ask what is missing? is there a roadmap/TODO? I'm curious

I’m curious too 🤘 What I’m doing is converting all the PDFs that I currently maintain into Pollen+Quad so that I can suffer through all the indignities. For instance, my MB Type FAQ is now a Pollen markup document that emits Quad markup. My font license is a quadwriter document. And so on.

I’m curious too 🤘 What I’m doing is converting all the PDFs that I currently maintain into Pollen+Quad so that I can suffer through all the indignities. For instance, my [MB Type FAQ](http://mbtype.com/faq) is now a Pollen markup document that emits Quad markup. My [font license](http://mbtype.com/license) is a `quadwriter` document. And so on.

@otherjoel has asked for a quad dialect that allows arbitrary positioning of text boxes, which I agree is necessary for certain kinds of layouts, so that’s coming up too.

@otherjoel has asked for a `quad` dialect that allows arbitrary positioning of text boxes, which I agree is necessary for certain kinds of layouts, so that’s coming up too.

Labels Milestones

question for those who like `poly` files #26

Labels Milestones

question for those who like poly files #26

question for those who like `poly` files #26