[Openfontlibrary] Raph's font format

Tue Oct 31 11:17:41 PST 2006

I posted in passing about designing my own font format, and got a fair
amount of response. I'd like to address the main points in detail.

The question about whether to create your own thing or join forces
with an existing effort recurs over and over again in the free
software world. In this particular case, there are good arguments on
either side. Often, it's not primarily a technical decision, but has
more to do with the vitality of a project, and the extent to which
people can get along with each other and work cooperatively.

So, let me set out the main arguments for and against, and then
hopefully it will be clear why I am leaning in favor of doing my own
format from scratch. Of course, that decision is not set in stone
either, and if it became clear to me that joining forces with another
effort was the right thing to do, I would in a heartbeat.

First and foremost, the file format I use for storing master outlines
will not be based on Bezier curves. Rather, it is an interpolating
spline similar to Ikarus and Metafont, but with some interesting new
features that I believe make them absolutely ideal for font design.
I've been thinking about these problems for years, and have been
working intensively for the past two years on the specifics. I'm
writing up my ideas as a PhD, and am also filing a patent. I will make
a patent grant allowing GPL implementation. Until the patent is filed,
I am being fairly quiet about discussing the details. This will happen
fairly soon, then all will be revealed.

Because I'm using different primitives, there is no chance of file
format interoperability with existing formats. Rather,
interoperability will be achieved through a conversion tool. Once you
_know_ you have a conversion tool, then you can also convert the
syntax and metadata properties of the file, in addition to just the
rocket science at its heart.

Given that a conversion tool is necessary, my strong impulse is to
make my format as simple as possible, and to avoid the various layers
of cruft that have built up over font formats over the decades.

My choice for the underlying syntax is s-expressions. This is because
s-expressions are easily powerful enough to meet my needs, yet so
simple that they can be roundtripped in 30 lines or so of Python, and
not many more of C. By contrast, an XML parser is a pretty major
effort.

This is what my current format looks like. This is a slightly
simplified '6' from Inconsolata. Like UFO, I'm currently storing one
glyph per file.

(plate
  (o 335 70)
  (o 432 89)
  (v 501 136)
  (v 449 191)
  (o 335 142)
  (o 219 212)
  (o 183 298)
  (v 168 421)
  (o 314 334)
  (o 483 429)
  (o 519 563)
  (o 478 720)
  (o 314 812)
  (o 143 717)
  (o 88 492)
  (o 143 195)
  (z)
  (o 318 405)
  (o 222 441)
  (v 172 502)
  (o 175 578)
  (o 207 671)
  (o 313 740)
  (o 418 675)
  (o 440 564)
  (o 422 479)
  (z)
)

This file format is nearly self-evident. You could convert this to
Ikarus format and use Ikarus tools, and you'd get ok results. Using my
tools, you get the cubic Bezier path in the PDF file I've attached.
I'm also working on generating optimized TrueType outlines.

Right now, I'm just working with static points, but a strong
motivation for all this work is to make variation practical. In
addition to plain x and y coordinates, I easily imagine s-expressions
representing lerps based on the positions of various sliders, and the
possibility of mixing different reference frames (one for the body of
the letter, one for the descender, say) that can be manipulated
independently. My goal is to provide at least as much power as
Metafont and Multiple Master, but with graphical interaction based on
sliders and reference frames, rather than PhD-level constraint
programming or having to come up with 2^n masters and have highly
nonintuitive rules about their structure being "compatible."

In addition to the outlines, a font format needs a way of naming the
glyphs, representing metrics and kerning info, and dealing with
complex script issues (which includes typographic refinements such as
ligatures, at least from the point of view of a file format). UFO is
definitely a possibility for such things, but from what I can see is
still pretty unfinished.

So it should be clear that I _need_ to create a lot of my own stuff,
in order to support the new stuff that I'm doing with the curve
primitives and the framework for variation. There simply isn't
anything out there that works now. I could of course adapt an existing
format such as UFO, but that also means inheriting its complexity,
cruft, and (to some extent) limitations.

To sum, I think having my own format is more a case of healthy
diversity than gratuitous fragmentation. Others may disagree, and of
course the beauty of free software is that they're free to remix the
ideas and code to scratch their itch.

Raph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6.pdf
Type: application/pdf
Size: 6912 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/openfontlibrary/attachments/20061031/81242d55/6.pdf