Fantastic—I’ve written a QuickDraw PICT converter, but I focused narrowly on just extracting pixel data. The format is basically a way to encode QuickDraw drawing commands, and getting the original image back (in the general case) means reimplementing QuickDraw.
The old Mac game Avara used this format for levels. It was funky… you could place blocks in a 3D world, and control elevation and height by changing the corner radius of rectangles. You needed a QuickDraw image editor to make levels, like ClarisDraw.
I really wish I'd had this tool six months ago when I was designing a GUI program for macOS 9. I wanted to import pictures from my modern laptop to a PowerBook Duo and vice versa. Converting all the assets was a pain, and I think this tool would've been incredibly convenient, even just for previewing the images.
The program existed six months ago. That said, currently it only allows to render old QuickDraw pictures on a modern Mac OS X. A tool going the other direction would be simple for bitmaps (just use PNG) or very complicated for vector data.
One thing I'm thinking about making a tool that uses old codecs to make compact images for 68K machines. Basically, use today's CPU power to make efficient road-pizza images.
Offtopic but which tools and resources would you recommend to get started with MacOS 9 GUI development?
I’ve experience with WinAPI/MFC but the classic Macintosh API is quite different and I’d often run into hangs when trying to run simple hello world-ish C++ programs compiled with CodeWarrior.
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.
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").
There is an export button in the right side of the toolbar. (Square with arrow going out). This will let you export the image as a PDF. You can also drag the picture to another application (or the desktop).
Fantastic—I’ve written a QuickDraw PICT converter, but I focused narrowly on just extracting pixel data. The format is basically a way to encode QuickDraw drawing commands, and getting the original image back (in the general case) means reimplementing QuickDraw.
The old Mac game Avara used this format for levels. It was funky… you could place blocks in a 3D world, and control elevation and height by changing the corner radius of rectangles. You needed a QuickDraw image editor to make levels, like ClarisDraw.
I really wish I'd had this tool six months ago when I was designing a GUI program for macOS 9. I wanted to import pictures from my modern laptop to a PowerBook Duo and vice versa. Converting all the assets was a pain, and I think this tool would've been incredibly convenient, even just for previewing the images.
The program existed six months ago. That said, currently it only allows to render old QuickDraw pictures on a modern Mac OS X. A tool going the other direction would be simple for bitmaps (just use PNG) or very complicated for vector data.
One thing I'm thinking about making a tool that uses old codecs to make compact images for 68K machines. Basically, use today's CPU power to make efficient road-pizza images.
Offtopic but which tools and resources would you recommend to get started with MacOS 9 GUI development?
I’ve experience with WinAPI/MFC but the classic Macintosh API is quite different and I’d often run into hangs when trying to run simple hello world-ish C++ programs compiled with CodeWarrior.
Great work! If I open your program in ResEdit, will I uncover a hidden Dogcow?
Thanks. The program is a "modern" Swift program, so no resource fork and no hidden DogCow.
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.
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").
https://developer.apple.com/library/archive/documentation/ma...
Then I am now surprised that SVG can embed bitmaps. Thanks.
PICT supported vector commands like FrameRect and FillOval, bitmap commands like BitsRect, and even embedded PostScript via PicComments.
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.
There is an export button in the right side of the toolbar. (Square with arrow going out). This will let you export the image as a PDF. You can also drag the picture to another application (or the desktop).
The readme mentions a PDF conversion tool, but I just cut and pasted into Preview, and that seemed to work.
What is the point of a graphics api that rasterizes into semi-permanent storage? Surely you just end up with pixel-poking a granulated mess
I just opened a PICT file in Preview on Mac and it also offers PDF export. What's the advantage of using this app?
> What's the advantage of using this app?
From the README:
> Preview can only open a small subset of the files I have.
Ah, I missed that part.
Love this