OS X port

[JanX2]

Hi Daniel!

I just ported this over to OS X. It’s a framework there and the way I ported it is a bit hacky, but it allows you to make changes without thinking much about OS X compatibility.

A few issues seem worthy of improvement:

1. Currently the way of getting to the attributed string is pretty roundabout as it requires many passes over the string to produce the result. We could probably improve that by using NSScanner to scan using an NSCharacterSet of the private use area code points, and building a tree from that. Alternatively, we could use the version of discount I have been working on. It produces a parse tree directly. Currently it’s missing span level support in the parse tree...
2. The different headline sizes should not be derived by addition but via multiplication so that we can get them to behave like this:
   http://www.markboulton.co.uk/journal/five-simple-steps-to-better-typography-part-4
3. The license is missing. I would like to propose using the MIT license.

Cheers,
Jan

[danieleggert]

Thanks. I'm busy right now, but will look into this ASAP. There are some generic changes & cleanup that I've been wanting to work on…

[danieleggert]

Jan,

I truly appreciate your effort. I really dislike using #define to make UIFont etc. to their OS X counterparts. It would be much cleaner to use a generic base class and then a specialised subclass for both iOS and OS X. I'll take a look at that…

Also: Why do you want to build a framework on OS X. For performance reasons that is generally discouraged. Your app will load faster if you either just add the source code to the main project, or (like on iOS) build a .a file and add that. But maybe there's a good reason?

Daniel

[JanX2]

I agree that this would be cleaner. My solution was quick to implement and doesn’t hinder ongoing development.

Why should a framework be much slower? A framework is just a repackaged dynamic library. Once everything is setup there won’t be much of difference. See http://www.mikeash.com/pyblog/friday-qa-2012-11-09-dyld-dynamic-linking-on-os-x.html. Macs are a lot faster than iOS device in any case. ;)

Anyway. The way this is currently implemented is very slow anyway compared to what direct string processing could achieve. But it works and I don’t plane to run megabytes of text through it. :)

[danieleggert]

Dynamic libraries make application launch slow because the run-time linker has to do a lot of work — basically a lot of the complexity that's mentioned in Mike’s article goes away if you link statically.

The other performance issue is when using the library. I know I could do way better. This is just a rather quick and dirty hack that allows me to use a relatively well-tested MarkDown parser library and wrap it with some Objective C.

[JanX2]

You are right, of course. But using a framework is very convenient. And, as I wrote before: Macs are fast. My apps launch instantaneously despite my use of frameworks.

[JanX2]

This seems like a good way to go:
https://github.com/Cocoanetics/DTCoreText/blob/master/Core/Source/DTCompatibility.h

This approach requires renaming UIColor to DTColor (in this example), though.

[danieleggert]

Thanks again. While being super busy right now, I've had a chance to work on refactoring the parser to be more generic, such that it can then be used by both AppKit and UIKit code bases (and also pure CoreText). Each of these 3 uses cases would then use its own subclass of the parser whilst the main logic stays in the base class. I hope to have this merged back into the main branch in Feb 2013.