Most of the code is agnostic from the output format, QuickDraw commands are just sent to a graphical port abstraction (in theory, there is still some untangling to do). The current implementation uses mostly Core Graphics, Core Text and to a less extent the Video-Toolbox to do the actual rendering.

I would welcome anyone wanting to implement an SVG renderer, but I'm not interested in doing so myself. My goal is to have a tool that allows the average Mac OS user to open QuickDraw files and copy-paste them wherever they need them (yes, the UX could be improved). Why did I not choose SVG?

First, PDF is widely supported on Mac OS X (and other platforms), SVG can be rendered in web-browsers and Inkscape. If you want functional copy/paste or printing, you need to use Core Graphics.

Second, Core Graphics is an API, SVG is a data format. My code tries to delegate as much as possible to the backend. So, for instance, if a QuickTime payload uses the TIFF codec, the TIFF file is just sent to the back-end, you can't embed a TIFF file in SVG, any RGB or YUV data needs to be serialized back to PNG.

Yes, this could be solved by linking in K libraries and frameworks, but my goal was to hack-around with a small (for 2025), self-sustained application.

Is it a vector format? It could capture pixels as well, and patterns.

It is, in one variant anyway, a re-playing (capture) of the QuickDraw drawing commands. It is one reason it is a hard format to decode without having the original Mac Toolbox QuickDraw code handy.

Ah, I missed that part.