Quote:Original post by Yann L
Robert, I fully understand your frustration. I downloaded paintlib and looked at the source. It's a nightmare of bad design and horrific programming style. The fact that even the guy who wrote it doesn't want to maintain it anymore speaks for itself.

So, as far as I see it, you only have three choices left:

1) Somehow try to compile paintlib.
2) Drop PICT support entirely, and rely on libpng for PNG support.
3) Write a PICT decoder yourself.

For the first option, well good luck. This thing looks like highly hacked together open source. It's most certainly not industry ready by any quality standards, and I wouldn't trust it for a second in a comercial product. This could end up in a support nightmare, when your plugin crashes under weird conditions somewhere in the paintlib source. And since it isn't officially maintained anymore since 2005, you'd essentially be on your own.

The second option is obviously the easiest and most painless, but I don't know if the lack of PICT support is acceptable for your product.

If not, then the third might be your only real option. Apple published a very brief note about the PICT format here (from 1985 :) It doesn't look too hard, if you only decode the bitmap information and leave the vector data alone. Note that paintlib will also only decode bitmaps, and not vector images. If you must, you can look into plpictdec.cpp from paintlib to help you figuring out the format (if you manage to look at that source long enough without ripping your eyes out...)

Unfortunately I'm not aware of any commercial grade image libraries capable of reading PICT, except Quicktime. Honestly, I have never ever encountered this format on the PC before.

Good luck !

Quote:Original post by Yann L
abort() is the default error handler, you have to override it with your own.

As I mentioned above, libpng is using setjmp() for that. That's a kind of old-school exception handling, a relict from the pre-OOP days. It has nothing in common with modern C++ exception handling except for the name. Essentially, it's nothing more than a global goto with some stack push/pop magic so that the stack frames don't go out of sync when jumping out of a deep function.

There's an example provided with the libpng docs:

Quote:
When libpng encounters an error, it expects to longjmp back
to your routine. Therefore, you will need to call setjmp and pass
your png_jmpbuf(png_ptr). If you read the file from different
routines, you will need to update the jmpbuf field every time you enter
a new routine that will call a png_*() function.

See your documentation of setjmp/longjmp for your compiler for more
information on setjmp/longjmp. See the discussion on libpng error
handling in the Customizing Libpng section below for more information
on the libpng error handling. If an error occurs, and libpng longjmp's
back to your setjmp, you will want to call png_destroy_read_struct() to
free any memory.

if (setjmp(png_jmpbuf(png_ptr)))
{
// This is where you end up, whenever libpng encounters an error !
// Think of it as your error handler. Clean up libpng here and return
// your own error code to the calling function.
png_destroy_read_struct(&png_ptr, &info_ptr, &end_info);
fclose(fp);
return( YOUR_ERROR_CODE );
}

I added a few clarifictions in bold.

Just as a reminder, setjmp/longjmp are considered evil by todays standards. But they work quite well in the context of libpng, and won't interfere with your C++ code.