[Openfontlibrary] Font File Type and Admins?

[George Williams]

On Wed, 2006-10-25 at 10:45, Dave Crossland wrote:
> I'm also wondering about UFO.
> 
> The UFO format from the TTX [1] project seems promising. Like most
> forms of XML, its an interchange format for source code, not
> functional code. A UFO is like a Mac OS X 'bundle', a folder with XML
> files inside, that can be treated as one file. Each XML file inside
> describes each glyph, and this eases collaborative working with
> CVS/SVN/etc as you can get a simple changelog of each glyph. Being
> XML, you can use whatever XML tools you are familiar with, like say
> python.
> 
> UFO has some technical limitations at the moment though, it doesnt do
> a bunch of important stuff like metrics yet, but it seems very
> promising. 
UFO[1] has support for horizontal advance widths and horizontal
(non-class) kerning. It documents, but does not support vertical
advances for glyphs.

I get the impression that the UFO docs were written as a work in
progress... and never updated. There are comments indicating that they
are/were thinking about class based kerning, but no resolution to those
comments.

UFO has no support for contextual positioning, single glyph positioning,
nor some of the other GPOS lookup types.

UFO has no support for ligatures nor any other substitutions (no GSUB at
all).

UFO appears to support the ttf 'name' table -- but only for one language
(which to my mind renders this support useless).

===========================================================
On Wed, 2006-10-25 at 11:28, Raph Levien wrote:
> Dave's suggestion of UFO is also
> plausible as a source format, but as far as I know it isn't widely
> used - certainly until FontForge has native support for it.
Ok, the (fontforge) cvs tree now contains the ability to read/write UFO
and GLIF files. Or it contains the ability to read/write what I think
UFO & GLIF files look like -- all I can actually say is that ff can read
it's own output -- I've never seen a real UFO bundle.

If anyone has such a thing I would appreciate it if you could test.

FF's implementation does support vertical advances, and I made the
obvious extension to support vertical (non-class based) kerning.

Large fonts get loaded slowly because there are so many tiny files to
open and parse.

[1] http://just.letterror.com/ltrwiki/UnifiedFontObject