Opened a few PICT files I threw at it.
Looking for an Export… item but did not see that. I suppose one reason to open an old PICT file is to save it as a PNG or something that will be easier to open in the future.
Looking for an Export… item but did not see that. I suppose one reason to open an old PICT file is to save it as a PNG or something that will be easier to open in the future.
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.
Version 1 PICTs: https://show.docjava.com/posterous/file/2012/07/9614411-DOC0...
I have the Version 2 documentation around here somewhere. I don't think I've looked at it in 20 years, though.
https://developer.apple.com/library/archive/documentation/ma...
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.