Safe from the Losing Fight

There comes a time in a man’s life when he must write about glyphs. This is that time.

…but I don’t need a pyramid

Glyphs are essentially pictures. They’re are a lot like hieroglyphs, except with less hiero, and they don’t necessarily involve Egyptians or slave labor. Glyphs are drawn on the screen to represent a character or group of characters. They can also be special symbols, such as the clover used for the command key. Before a string is drawn to the screen, the characters are first converted to glyphs, then the glyphs are drawn to the screen.

Although it’s rarely necessary to drop down to the glyph level, let’s be honest: who doesn’t want a chance to play around with glyphs? After all, all the cool pharaohs are doing it.

Obtaining a glyph

Before you can do anything with a glyph, you have to get one, just like before you can use a pyramid, someone has to be dead, preferably a mummy.

If you just have plain text, getting the glyphs is pretty easy. You just use NSLayoutManager:


NSTextStorage* storage = [[[NSTextStorage alloc] initWithString:string] autorelease];
NSLayoutManager* layout = [[[NSLayoutManager alloc] init] autorelease];
[layout setTextStorage:storage];

// ... do something with the glyph...
}


string, as passed in to the NSTextStorage object, is the string you want glyphs for.

As I mentioned earlier you can also have glyphs that are special symbols. Typically, these are font specific, and are named. For example, the command key glyph is in the special .Keyboard font, and is named “propellor.” It only takes a couple of lines to get ahold of it:


NSFont* font = [NSFont fontWithName:@".Keyboard" size:13];
NSGlyph glyph = [font glyphWithName:@"propellor"];


I should note that NSGlyph is just an unsigned integer.

Wasn’t that fun? Sure it’s not a large, geometrically shaped, timeless monument in your honor, but what did you want from a blog?

Draw like an Egyptian

Glyphs aren’t that much use unless you can draw them. As the pyramids show, things are the easiest when you make someone else do all the hard work. To that end, the easiest way to draw a glyph is to take advantage of NSAttributedString.

First, I’m going to assume I already have the font and glyph, retrieved from the previous example.

Second, I need to build up a glyph info (NSGlyphInfo) object. Since glyphs are often specific to fonts, I have to include the font as well as the glyph code. What’s not completely obvious is what the “base string” is for. It is essentially a placeholder string, that will be replaced by the specified glyph when it is drawn.

The following code shows how to create a glyph info object for the command key glyph.


NSString* baseString = [NSString stringWithFormat:@"%C", 0xFFFD];
NSGlyphInfo* glyphInfo = [NSGlyphInfo glyphInfoWithGlyph:glyph forFont:font baseString: baseString];


You might be wondering why I chose the 0xFFFD character for a base string. Much like the pyramids, it’s a mystery to me. Some glyphs (like those in the Apple Symbols font) will draw with just about any base string you give it. However, other glyphs, like those in .Keyboard, only draw if you give them a specific base string.

I discovered the 0xFFFD value by dropping in a NSTextView in Interface Builder, running the app, and dropping in a bunch of glyphs using the Character Palette Input Method. Then I called textStorage on the NSTextView (which returns a subclass of NSAttributedString) and dumped out the NSAttributedString.

Now that I have a glyph info object, I can create my NSAttributedString. I just need to specify attributes for the font, NSFontAttributeName, and the glyph itself, via NSGlyphInfoAttributeName.


NSDictionary* attributes = [NSDictionary dictionaryWithObjectsAndKeys: font, NSFontAttributeName, glyphInfo, NSGlyphInfoAttributeName, nil];
NSAttributedString* string = [[NSAttributedString alloc] initWithString: baseString attributes:attributes];


Notice that for the string, I just provide the base string. I could include regular text, which could contain multiple instances of the base string. Each instance of the base string would be replaced by the glyph when drawn.

Now that I have a NSAttributedString, there a couple of things I can do with it. If I have a control of some sort, like, say, a NSTextField, I can just call setAttributedStringValue: and pass in my attributed string, and the control will take care of drawing it. Otherwise, I can take a more direct approach, and call drawAtPoint: or drawInRect: on the NSAttributedString.

If using NSAttributedString isn’t low level enough for you, then you’re a control freak and should seriously seek professional help. But before you go, first consider NSBezierPath.

In this example, let’s assume font is a NSFont that contains all the glyphs I want to use. Also, assume glyphs is an NSArray of NSNumbers containing the glyph codes I want to draw. Note that this means the sample code will only work if all glyphs are from the same font.


NSBezierPath* path = [NSBezierPath bezierPath];
float left = 0;

NSSize advancement = [font advancementForGlyph: glyph];
left += advancement.width;
}
[[NSColor blackColor] set];
[path fill];


Since glyphs are font specific, I have to ask the font for glyph measurements, in order to place the glyphs properly.

More interestingly, note that since I have a NSBezierPath, I can do any sort of graphic transform or translation on the glyphs. I can rotate them, change their color, or do my own kerning. If you’re writing your own graphics program, handling text at the glyph level, using NSBezierPaths, is very useful.

Beating a dead mummy

Hopefully this post has given you many insights into what you can do glyphs. Namely, build pyramids. Or attributed strings. Whatever.

Although I’ve written more about Cocoa than Carbon, my professional gig is usually the opposite. My experience is in (often large) commercial shrink wrap software, which, at this point, is usually written in Carbon. Because of this, I recently had to opportunity to discover what it takes to print to PDF in a Carbon application. Of course, by “opportunity” I mean excruciating, unending pain.

It turns out that you only need one API to change your print loop to dump out to a PDF:

extern OSStatus
PMSessionSetDestination(
  PMPrintSession      printSession,
  PMPrintSettings     printSettings,
  PMDestinationType   destType,
  CFStringRef         destFormat,
  CFURLRef            destLocation);

It’s defined in PMCore.h, and even has documentation for it in the headers. You simply pass in the print session and settings, then specify kPMDestinationFile for the destination type, kPMDocumentFormatPDF for the destination format, and then a CFURLRef for the location of the PDF file.

Easy huh?

Unless you have to go find this API for yourself. i.e. You want to print to a PDF, but don’t know what API will actually do that. You see, the Print Manager documentation is part of Apple’s patented Don’t Document a Damn Thing initiative. And as I can attest, it’s a resounding success.

I searched through the headers (which still draws bizarre stares from Windows people. “You mean Apple doesn’t like developers enough to even provide real documentation?”), but couldn’t find anything that actually did what I needed. I googled for it too, but to no avail. I eventually found the API by digging through an email list archive.

Carbon documentation is apparently highly classified information at Apple. No one is supposed to know about it, let alone talk about it. It’s approximately at the same level of secrecy as the Freemason’s secret handshake. Except that I assume Apple would dispatch someone to take you out if you discovered any information on the Carbon API’s. That’s the only reason I can determine for the sparseness of documentation.

Unless you buy the other reason I’ve heard: Cocoa is the way of the future, so it doesn’t benefit Apple to document the old APIs. I mean, obviously, since I can’t figure out how to do something in Carbon, I should just port this 500kloc+ application to Cocoa. After all, we all saw Steve port an entire application by just checking a little box. And remember that demo where they build an entire word processor without writing a line of code? Why can’t you be that good?

What I’m thankful for this year: bitterness.

I’m in the process of translating an incomplete Java program I wrote into an Objective-C program. It’s a simple interpreter for a very simple kid programming language. At the time, it had been a while since I had dabbled in Java and thought it would be fun to get back into it. After all, it had “generics” and whatnot now, and other features that C++ programmers claimed it needed to be a “real” language. And what could be more fun than the overuse of angle brackets, incomprehensible error messages about type conflicts, and sounding all smart rambling on about “generics?”

Gooey Troubles

The Java programming went well until I had to start implementing the user interface for the interpreter. Now the language uses lots of graphics and such, because its supposed to be visual, and thus more fun for the kiddies. Although I remembered Java as being a nicely designed language, with a good runtime library, I had forgotten how bad the GUI programming was. Perhaps I was simply repressing the traumatic memories.

First off, there are a lot more choices for GUI programming in Java now than there was the last time I did Java programming. Back in the day, it was AWT (Abstract Window Kit) or nothing. AWT wasn’t horrible, assuming you were a masochist, but you couldn’t precisely position things, and the controls never looked native. Oh, and it was insanely slow too.

Fortunately, today you have more than one choice when it comes to UI toolkits. There’s still AWT, but Sun also introduced Swing (as in, swing from a rope) to replace AWT, and IBM came up with SWT, which apparently stands for “Swearing With Toolkits.” Now, when I say Sun replaced AWT with Swing, I actually mean they confused the hell out of me. Because Swing doesn’t actually replace AWT. It kinda supplements it in some places, while in others outright replaces AWT classes. But good luck figuring out which class does what. After about an hour with the Swing documentation I decided it’d be easier to just implement the entire UI in ASCII art. Oh, and if you were worried about the non-native control look in AWT, don’t worry, Sun kept that feature for Swing.

Then there’s SWT, which apparently stands for Surely the Wrong Thing. It was created by IBM for the Eclipse project, because AWT and Swing were so awful. But don’t worry, IBM bested Sun at its own game and managed to create something that was even worse. The Mac version of SWT was written by an Mac hating chipmunk. It uses old style Carbon controls and Quickdraw. That’s right, not even HIView’s and CoreGraphics, much less Cocoa. I’m hoping that since Adobe has an Eclipse plugin now, that they’ll rewrite SWT/Mac to be something decent, much like what they did with Premiere.

There’s also the Java Cocoa bindings from Apple. They’re not all that up-to-date though, and Apple has said they’re not going to be supported any more. Furthermore, if I’m going to be writing to Cocoa, why am I writing this program in Java?

So that’s where I stopped with the Java project. I decided that I didn’t really need all this pain to do, what should be, basic GUI programming.

Learning from the pain

I have a confession to make: I like Java. Or, more precisely, I want to like Java. I like the simple language design. It’s easy to read and write. It comes with a great runtime library: built-in threads and sockets and all sorts of good stuff. I think there’s a few things Objective-C can learn from Java, other than how to be tasty.

Probably the biggest thing I noticed when converting this Java program into Objective-C was the the garbage collection. What used to be a one line assignment in Java ended up being three or four lines in Objective-C to make sure it was retained and released properly. I found that there was more Objective-C code than Java code, primarily because I needed to manually manage memory. When I write straight Objective-C code, I don’t really think about it, because where I started, C++, memory management is even more manual. But doing the conversion really drove the point home: I’m wasting a lot of thought cycles and code on memory management. I also found that I suddenly had to worry about cyclic references, which I didn’t have to worry about in Java.

I know Objective-C 2.0 is going to have garbage collection, but it can’t get here soon enough for me. This conversion process only confirms the fact that the feature is well overdue, and how insufficient simple reference counting is.

Speaking of memory management, why is it that I have to manually call alloc and init? And inside my init, why do I have to manually call my super class and check self for nil? Why do I have to call my super class in dealloc? Maybe I’m delirious from all the reference counting I’ve been doing, but it seems to me like that’s all boilerplate code. Boilerplate that the compiler should be taking care of, not lazy ‘ol me.

Other than memory management, my other gripe is exceptions. Objective-C doesn’t unwind the stack per-se, it essentially just restores the stack and registers to a previous location, much like a thread context switch. i.e. It does a setjump() and longjump(). That means things get left dangling, memory leaks (‘cause, you know, no garbage collection) and it’s generally harder to clean things up and get back to a known, stable state. I know exceptions still work this way because of historical reasons, but it has to move on at some point. Currently the exception handling is pretty much worthless, which is probably why Apple still recommends NSErrors instead of exceptions. Exceptions aren’t worthless, just the way Objective-C implements them is.

No, it really was that painful

Now, lest you think I’ve gone all soft on Java, I have plenty of other gripes about Java. These didn’t come rushing back until I started the conversion to Objective-C.

Enums. Seriously, Sun, what up with that? One of the easiest to understand programming concepts, that’s equally as easy to implement, and it’s completely not there. What, did you think I’d like to list out every constant value, along with it’s type and value, instead of the compiler inferring the type and automatically generating a value for me? I may be a masochist, but I’m not that much of a masochist.

I’m still trying to figure out mule-headed reasons behind the “no free functions” rule. Is the thought that it would force the users to write object-oriented code? As they should be well aware, you can write really bad non-objected oriented code using just classes. Just look at MFC. Furthermore, just because someone writes a free function, that doesn’t make the code not object oriented. This failure of the Java language just feels like a religious argument to me.

Java really strives to be easy to read and understand. This lead to the fact that object parameters are passed by reference, while scalars are always pass by value. While this is somewhat easy to understand (See kids, this arbitrary type is reference, while this other arbitrary type is value), it doesn’t help real programmers. Because sometimes, I just have the crazy urge to retrieve the results of a function that’s done some work for me. I had more than a few classes that were just wrappers around out parameters.

And don’t even get me started on that stupid exception specification checking. Morons.

Ending the pain

Comparing Java to Objective-C is interesting to me because Java was influenced by Objective-C. All in all, almost all constructs in Java have a direct equal in Objective-C, which makes the conversion process fairly straight forward. However, while Java has continued to evolve, Objective-C hasn’t. Well, Apple is pushing forward with Objective-C 2.0 improvements, but the language has been dormant for many years. Hopefully, Apple will continue the improvements, and Objective-C can catch up.

As for Java, they just need to scrap all their previous GUI attempts and start over again. Until then, I don’t care how much support for “generics” or other modern language features Sun adds, I can’t take it seriously as a language or a platform.