Images in quadwriter

[otherjoel]

In #lang quadwriter/markdown saving the below to the same folder as test.jpg

#lang quadwriter/markdown

![image](test.jpg)

—then doing Run in DrRacket results in div: unbound identifier in: div

Also: pict->quad would be useful

[mbutterick]

How should a quadwriter/markdown image be scaled and positioned, by default?

[mbutterick]

By the principle of least user labor, it doesn’t seem like quadwriter should rely on the native size of the image file, because that would impose a lot of new preparation of the image files to get them right.

OTOH assuming that an image wants to be a block-level element, scaling the image to the full width of the line seems like it would often be too big.

PS What would a pict->quad function do?

[otherjoel]

How should a quadwriter/markdown image be scaled and positioned, by default?

Specifically for the markdown variant, for raster images as block-level elements, I would scale the image using the DPI metadata in the original file, or if that is wider than the text block I would scale it down to fit. Not sure about vector images. Center it in the text block and use the alt text, if any, as a caption underneath.

[otherjoel]

PS What would a pict->quad function do?

It would be good to be able to include picts built with the racket/draw functions in the PDF output. even to be able to place them at precise coordinates on the page. Two use cases I have in mind are Racket REPL example output and book cover design.

[mbutterick]

A Racket pict is just a precursor object to a rendered file. So unless I misunderstand, the pict->quad could be as simple as this, where you render your pict object to png as a temp file, and then pass the path of this file as an image-data attribute:

#lang racket
(require quadwriter pict)

(define mypict (cloud 100 75 "lavenderblush"))

(define (pict->quad p [type 'png])
  (define fn (format "~a~a.~a" (object-name p) (eq-hash-code p) type))
  (send (pict->bitmap mypict) save-file fn type)
  `(q ((image-data ,fn))))

(render-pdf (pict->quad mypict) "test.pdf")

(Of course, there is nothing magical about the temp filename)

[mbutterick]

That doesn’t help with the scaling / positioning, which I have to think about more.

[mbutterick]

I would scale the image using the DPI metadata in the original file

BTW are you certain that PNG files carry DPI metadata? I have not found evidence of this yet, though I never want to rule out my own ignorance as a contributing factor.

[otherjoel]

the pict->quad could be as simple as this, where you render your pict object to png as a temp file, and then pass the path of this file as an image-data attribute

That could work for sure, though wouldn't it be cleaner to do this in-memory, and avoid leaving artifacts on the filesystem to clean up?

BTW are you certain that PNG files carry DPI metadata?

Yeah, I’m actually certain they may not…looks like the PNG standard specifies an optional header for dots per meter. Bummer, although maybe it does make things simpler if you just say scaling info must be specified in (or derivable from) the q-expression regardless of the image file format.

[otherjoel]

Image scaling could have a document-wide DPI value with a useful default, or specifiable by keyword argument

Outside of quadwriter/markdown, perhaps there could be three ways to handle scaling besides (i.e. overriding) the above:

1. Individual q-expressions with image data could specify a DPI value, and the print size and width of the image would be derived from this.
2. Or an expression could specify one of width or height (in what, points?) and the image would be scaled accordingly, retaining its aspect ratio.
3. Or both width and height could be specified and the image would be forced into those dimensions.

[mbutterick]

That could work for sure, though wouldn't it be cleaner to do this in-memory, and avoid leaving artifacts on the filesystem to clean up?

I’ll have to think about it more. Yes, cleaner in one sense. But a temp file is going to have to be made somewhere along the way. It’s arguably dirtier for quadwriter to handle that housekeeping because it requires it to know about Racket pict objects (whereas so far, I’ve been trying to keep everything restricted to the Q-expression interface).

Image scaling could have a document-wide DPI value with a useful default, or specifiable by keyword argument

I’ve implemented it more or less as you suggest. quadwriter/markdown arbitrarily imposes an image height of 150 pixels. It seems like the scaling needs a little more finesse so that it cooperates with the line width, so that if you set an image scale, and then make the line width smaller (say, by adding columns) that the images aren’t left at their former size.

[mbutterick]

(but for now, your original example should work)