+/*! @file font.mm
+ @disucssion
+ Cocoa has three classes which interact to form the font system:
+
+ NSFont: Represents a specific font (e.g. Times-Bold) at a specific size
+ with specific attributes. That is, it's basically like this class.
+ Notably, it doesn't hold an underlined flag, so this class does.
+ Available on all OS X versions.
+
+ NSFontManager: Fairly broad controller class which ties together the
+ model (NSFont) with the view (NSFontPanel). We are ignoring NSFontPanel
+ in this discussion. NSFontManager is actually a little broader than just
+ a controller though. It's also the traditional way of mutating fonts
+ and asking for a font with a certain family and certain attributes.
+ For example, you can use NSFont's factor methods to create a font named
+ @"Times-Roman" then use NSFontManager to imbue attributes like italic and
+ bold. You might do this if, for instance, you already have times at the
+ Roman weight but want to make it bold.
+
+ Alternatively, you can use NSFontManager to ask for a font in the @"Times"
+ family with the bold attribute.
+
+ NSFontManager is available on all OS X versions.
+
+ NSFontDescriptor: Added in OS X 10.3. Prior to this there was no specific
+ class to represent all of the attributes of a font. Instead, a regular
+ NSDictionary was used with a set of well-defined keys. Unfortunately,
+ there was no method accepting the attributes dictionary, only a method
+ to retrieve it from an NSFont. That meant that in order to create
+ a new font by imbueing certain attributes like Bold one would need
+ to use the specific method in NSFontManager to do so.
+
+ The NSFontDescriptor class, on the other hand, has factory methods which
+ can create a new font descriptor with an attributes dictionary as well
+ as mutate (by copy) an existing font descriptor using attributes from
+ an attributes dictionary.
+
+ In theory, most of what can be done using NSFontDescriptor can just as
+ well be done without it. NSFontDescriptor is basically just a shell
+ around an NSMutableDictionary with well-defined keys.
+
+
+ Getting back to the broad overview, font matching is one of the weaker points
+ in Cocoa's API and NSFontDescriptor is the easier to use solution.
+
+ That said, it's not impossible to implement font matching without it. For instance,
+ if you have a family name and want to list available variants (e.g. Bold, italic,
+ underlined) then you can ask NSFontManager for availableMembersOfFontFamily:.
+
+ The problem is that you can either match on family name or on font attributes
+ but not on both. To match both you have to do one then the other.
+ NSFontDescriptor allows you to get a list of fonts matching both a family name
+ and a particular set of attributes. Furthermore, the attributes instead of
+ being flags as in NSFontManager are instead well-defined keys in a dictionary.
+
+ The only way to get that behavior without NSFontManager is to pare down the
+ list as much as possible using the classic NSFontManager methods and then
+ to instantiate each font in the list and match on each font's afmDictionary.
+
+ A reasonable guess is that that's probably more or less exactly what
+ NSFontDescriptor does internally.
+ */