Given that PICT is a vector format at heart, what'd be ideal would be a conversion to SVG. At one point I had part of a tool written to do that, but it didn't handle text very well.
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.
It was a vector format which could contain embedded bitmaps - which also neatly describes SVG. The format was fairly well documented in "Inside Macintosh: Imaging With QuickDraw", particularly appendix A ("Picture Opcodes").
