Some quick thoughts about the project space I see myself working in (meaning personal coding projects that aren’t the productivity tools I mentioned before), both now and for the foreseeable future. To be honest, it’s mostly a roadmap for myself, posted here as part of working in public.
Bookmaking tools
One of the areas in the project space is bookmaking tools: tools that help with making either print books or ebooks. What I’ve worked on in that area (and some of these are still in progress or in the future):
Storybook — writing tool (covered under the productivity tools, yes, but I feel it fits in here)
Creativity tools
The next area, somewhat related, is creativity tools: tools for making art, music, etc. I do realize that there’s a bit of overlap between the two areas — art can be used in books, for example. This is not a rigorous taxonomy.
While I haven’t done much in this area so far, the intersection of software and art has been calling to me more lately. I expect creativity tools to become much more of a focus for me, probably even more so than the bookmaking tools.
Human-Computer Interaction
Last but not least, HCI. My master’s thesis is in this area, and much of my other work also touches on it in limited ways. (What I mean by that, I think, is that with projects like Trill, Curves, and Press, the parts that have most interested me are the interfaces. Also, those interfaces have been textual in these particular cases, but I’m also interested in other kinds of UIs.) So I plan to start building more proofs of concept and interface experiments — like the spatial interface ideas I mentioned several weeks ago.
Last year I posted a note about Curves, a Python type design library I was working on. At the time I’d given up on it, but I recently had some new ideas on how to make it more ergonomic. It now stands resurrected:
Since I don’t think I mentioned it in my earlier post: the idea is that programming language constructs (functions, variables, source control, etc.) may make it easier to design a typeface, given the parametric and repetitive nature of that work.
It’s still a work in progress and very much an experiment — placing points in code rather than in a GUI will always have some friction to it — but it seems promising enough now that it’s worth finishing it and trying to use it for some actual type design.
Update on projects: I’m working on a short story. All of my story drafts of late have turned darker than I’d like, so this one is intentionally not dark. Seems to be going better than the others.
I’m also partway through revising my next picture book. This one is a story (as opposed to The Circle Book, which was just a list of random things) and I’m excited. The urge to design a typeface for it has proven too strong to resist, though, so I’m working on that as well. The typeface is called Golly. I’ll post some screenshots soon (I’m almost done with the lowercase letters).
Sidenote on type design: I built Curves (a Python library for designing type, via exporting to UFO and compiling that to OTF) to see whether designing type in code works. Turns out it doesn’t. Even with easy previews (SVG and @font-face), the cognitive gap between the code and the points seems to be a little too much. I have some other ideas for type design tools that seem more promising, though. More on that later.
And I’m slowly working on the remaining reader’s editions (print/PDF of D&C, Pearl of Great Price, and Words of the Prophets).
I threw together a (very) rough mockup to explain a few of the ideas I mentioned last week:
Again, super rough, and lots will change. Salient points:
Text preview windows. They’re using Markdown converted to HTML and styled with CSS. The idea is to be able to see how your changes affect the typeface when it’s being used on a page (and with the age of ereaders, it’s good to be able to test light on dark as well).
Revisions. Ideally, it’d be nice to have a preview pane showing a page using an older revision and a preview pane showing your current work, so you can see if your changes are better or worse. And being able to revert to an older revision would reduce the stress of trying things out. (Hmm, I wonder if branching ala Git would be worthwhile…)
Glyph code. Under the glyph, you can see some rudimentary code describing the glyph. I’m not sure this is the syntax I’d use, but it’d be something fairly similar. (Point type, point coordinates, and then zero to two control points.)
Regular + italic. As you can see in the preview windows, I want to make it easy to preview italic along with the regular. I don’t know yet what ramifications this has for the font view or glyph editing, but I’ll figure it out.
What I’m not including in this mockup:
A tool palette. I’m not sure yet if I want to have one at all, actually. With the heavy emphasis on keyboard shortcuts (and with a search that knows about tools), I don’t know if I need one. Or at least not a traditional palette. We’ll see.
Settings menus for each window. Still not sure how I want this to work, but it would be similar to the side panels in Blender.
And of course there’s a lot more to figure out and work through.
As I start getting more into designing type, I’m finding that I’m not as happy with FontForge. It works, yes, and I can design fonts with it, but it’s not beautiful, aesthetically or functionally. It doesn’t sing. It also has a lot of friction that slows me down. I’ve looked at the other font editors out there — FontLab, RoboFont, Glyphs — and they don’t really do it for me either. (Nor are they in my budget at the moment.)
I realized I’ve been spoiled by Vim and Blender, both of which have steep(ish) learning curves but which also are incredibly rewarding and efficient for power users. I want that kind of a tool to use when designing type. So, because this is me, I’m going to build one.
Well, sort of. I’m going to talk through the design out loud on here as I go along, occasionally building prototypes to better explain what I’m getting at. I’m sure at some point I’ll actually build it, since I already want to use it instead of FontForge, but for now I need more experience building type with existing tools so I can better know where the friction points are.
I’m calling it Curves, and yes, it’s partly tongue-in-cheek. Here’s a brief overview of some of the ideas behind it (some of which are already in existing font editors):
Power tool for advanced users. Reading about Douglas Englebart’s philosophy on computing has gotten me itching to make power tools instead of newbie tools. There’s nothing wrong with newbies, but I’m more intrigued by the idea of focusing on power users. Learning curves are okay. (Weak pun semi-intended.)
Web-based. Originally I wanted to make this a desktop app like Vim or Blender, but the more I looked into it, the less interested I got (C/C++ no longer appeal to me, and doing the UI in OpenGL to be cross-platform would put me at a lower level than I’d like, since I didn’t really like any of the OpenGL UI toolkits I looked at). Besides, all my recent experience is in web stuff, and being able to edit fonts from anywhere will be nice. (I think seeing Tridiv yesterday helped cement this decision for me, by the way.) Also, since web fonts are one of the main targets of an app like this, being able to load and preview the fonts in-browser will be a big plus. And web services have a lot of potential.
Panes. I really, really love Blender’s windowing system, with non-overlapping panes. (Vim has something similar, though I don’t really use it that much.) I also love being able to easily store different layouts for different uses. With type design, this kind of setup feels like the right choice and would make it so much easier to switch between different parts of making type (designing glyphs, spacing/kerning, previewing text, OpenType features, etc.).
Heavily keyboard driven. I’m thinking about possibly using chording and/or sequences (the latter ala Gmail, thanks to Mousetrap). Everything customizable, of course. At this point I’m thinking of borrowing Blender’s shortcuts for selecting (‘a’), moving (‘g’), scaling (‘s’), and rotating (‘r’) points, since they’re all on the left hand, which frees your right hand for the mouse. But we’ll see.
Command line. I don’t mean running it from the Unix command line, but rather that I want a command line as an integral part of the app. Command lines are really, really powerful, and the idea of one specifically tuned for designing type makes me giddy.
Search. Not just searching for glyphs by name, but a powerful query syntax so I can easily get a list of glyphs wider than X or with left sidebearings smaller than Y or what have you. And saved searches, of course, like smart playlists in iTunes.
Scripting. Of course. Python or JavaScript. I’m looking forward to being able to generate kerning pairs via Python rather than having to do that outside of the app and paste the resulting pairs in. Or being able to script a set of things to do just before exporting to OTF (like removing overlap and checking for points at extrema and stuff).
Focus on designing text faces for use as body copy. I’m still not sure what that actually means in practice, but some ideas are: previewing pages of text instead of just lines; editing and previewing the italic and bold weights together with the regular (rather than as separate fonts); programmatic relationships between regular and italic and such; visually edited components that can hook together intelligently and automatically remove overlap on export.
UFO. No, not flying saucers. The Unified Font Object format is a nice XML-based schema that already has support in most existing editors and feels like a good platform to build on. (Besides, RoboFab can already read and write it.)
Great OpenType feature support. One of my beefs with FontForge is that I have to use its UI for OpenType features. I’d much rather use Adobe’s text-based feature file format. Yes, FontForge can import/export it, but it’s not FF’s native way to edit OpenType, and I wish it were. (I, uh, like text.)
DSL for editing glyph points. Visually drawing glyphs is nice, but I want to have a text editor pane beneath my glyph with code for that glyph that I can edit. (Text can be nicer for precision editing.) This would probably be a small domain-specific language. I’ve also thought about integrating it more completely — a fully-fleshed out parametric type design language, kind of like Metapost. The trick would be finding the sweet spot between writing parametric code and designing visually. I have some ideas for this that I’m excited to explore.
There’s more (I’m very interested in finding ways to improve the UI for drawing Bézier curves), but that’s quite enough for now.
