<aside> 🌐 https://ghostscript.com/r/Resolution-Independent-Clist

</aside>

[Probably already out of date. Ken and Chris have both expressed the opinion that we should be working at the device level, so that's what I'm trialing.]

Resolution Independent Clist

The what now?

The current clist is device-dependent; most particularly, it is resolution dependent, but also bakes in other things like colorspace etc. As such we can’t interpret the page once, and then rerender it multiple times unless we just want exact carbon copies of it.

This has been identified as something that we’d like Ghostscript to be able to do?

We should probably refer to this as the “High level clist” or “Device independent clist”, as that better captures what we need from it.

Why?

Well, the simplest example is panning and zooming within viewers.

The Display device currently has a mode where it can rerender different regions of a page repeatedly. For this, it uses a clist. It is limited to not being able to change the zoom, however. For that, we’d need resolution independence.

Also, previews - some printers might want to display a ‘preview’ of a page on a screen before printing it. This would require colorspace independence.

While it can be accomplished with the current clist, rendering a large page using ‘tiles’ is sometimes of value.

[Any other examples gratefully received.]

Discussion on this subject

A lot of the ideas on this page spring from a discussion on #artifex. Logs can be found here: https://ghostscript.com/privateirclogs/2020/09/07.html starting at 13:52:02. I’ve attempted to distill the ideas expressed here. Any mistakes are my own, etc.

How to implement this?

My initial thought was that there were several ways to go about coding this:

1 Implement a new displaylist device. 1 Work in the same way as the current clist. 1 Reimplement something akin to the clist using subclassing.

1 Implement a new displaylist device

This is akin to the way MuPDF works; there we create the device, run to it, and we are left with a display list object. We can then run that display list object back to a different device to get the output we actually want.