[Offtopic] Pain in PDF printing on my mac, workaround...

So, since I spent three hours of my life on this, I figured a post on the internets for other to find was worth writing.

My goal was simple. My wife had created a document in pages and wanted it professionally printed. First attempt was a simple "save as pdf". That failed, as there were tiny inconsistencies when viewed on a PC. I installed adobe reader on my mac and low and behold, they showed up there. I thought PDFs were supposed to look the same everywhere...

Some google research pointed to PDF X-3, which iWorks claims to be able to export. It is apparently a subset of PDF that everyone agrees on. Yes, let that last sentence sink in. PDF, the format that is supposed to look the same everywhere, now has a sub-format to do that job. Eitherway, attempts to export the document fail with a generic "can not create PDF-X3" error. Apparently this is a long standing bug with iWorks where some complicated documents throw that error. No fix, no work around. This is starting to sound like bloody Linux...

Alright, next approach is using the "ColorSync Utility" to create a filter. People online seem to saying this sometimes works. After launching the beast, I find out that it apparently fails to save resolution settings at all. This means when I filter wife's document through it, it comes out looking like 1990 smacked it upside the head, low resolution and all...

The solution I have come up with is the 500 lb  (226 kg for my metric friends) sledgehammer of a solution.

1. Open iWorks. Save document as PDF that won't work in adobe.
2. Open PDF in preview, File->Save As.
3. Selection JPG, change quality to full and DPI to 500.
4. Send that 15 meg JPG to the printer...

Magecrawl on Mac Part II (libtcod, SDL, and init code...)

This is a bunch of technical details about getting libtcod working on the mac. You might just be interested in the announcement post.

As promised, this post is a breakdown of the work it took to make libtcod work natively on the mac. By "native", I am not knocking the wonderful work Michael De Rosa did for previous releases. I'm referring to ones produced auto-magically by the cmake system,  no manual xcodeprojs, .dylibs and all.

The wonderful part of generated xcodeprojs is that they will stay in date as further changes are made. Nobody has to figure out what changes were made, and manually update things. This hopefully means that mac ports of the new version should come out same day or very soon after releases.

Enough about that...getting libtcod working on the mac involved two major sections of work.

Part I: Build system

Getting cmake to play nicely with the mac wasn't too painful. I had noted places in my CMakeLists.txt where apple variables were needed when I created them, so the first step was filling them all in. Unlike the windows builds, the mac build currently uses the framework versions of libsdl and libpng. I'm unsure if this will require users installing those frameworks before use.... I did this since I wanted .dylibs of libtcod. The only other issue that SWIG apparently doesn't ship arrays_csharp.i built in for the mac. I had to download it from svn and copy it into the right place.

Part II: Crashes on launch, init code, and mac

This is where the pain started. The sample programs crashes on launch, due to an objective c exception about preconditions not being met. After some digging, I found this. Apparently, SDL does some funny business to get initially properly on the mac. You need to include an object c file in your build and use a particular version of a main function.

What happens on the mac is when you include the SDL headers, it renames your main via macros to something else. The objective c file defines its own main statement, which does the correct initing and then calls SDL_main which calls your main.

This obviously doesn't work very well if your a C# program who doesn't have a main! I had a friend at work who know objective c well to bounce ideas off of, and then I ran into this. It's a simple objective c method I could call from C code before initing SDL that would handle the mac stuff for me. No more renaming main nonsense for me. It worked great.

Just one note, all of this doesn't apply if your use the "unix" style SDL libraries. Those you can use just normally, they don't need extra setup. However, I wanted a "real" mac port, dylibs and all. There is now code in libtcod that will fixup the mac specific stuff when you call console init. Hence, it works fine no matter the calling language.

I normally try not to get this implementation specific when writing posts, however I couldn't find all this info in one place. If somebody is trying to get an SDL based library working on the mac, particularly in C#, I hope this info finds you well...

Magecrawl on Mac Part I (Announcement)

Success!

One libtcod had a working mac version, getting magecrawl working was trivial, thanks to the wonderful work by the mono team. Other than a bitness issue that was my own stupid mistake, all it took was dropping the native libtcod mac .dylib and. so, adding a single config file, and off it ran.

Getting libtcod to work on the mac was a bit more work, and a very technical breakdown of issues and solutions will follow in another post soon to come.

Now back to prototyping that skill tree viewer...