[Openfontlibrary] new release of the Ubuntu titling font

[Dave Crossland]

On 02 Jan 2008 19:34:21 -0800, George Williams <gww at silcom.com> wrote:
> On Wed, 2008-01-02 at 19:03, Dave Crossland wrote:
> > FontLab VFBs are _not_ free formats. There are two I know of,
> > UFO and SFD.
>
> There are also ttf, otf, pfb, etc.

Since posting on list I've made a longer blog post that fills in some
unstated assumptions, including this unstated distinction between font
source code and object code.

"Fonts are a kind of software, although they are slightly different to
programs, but sometimes contain real programs.

Font source code, like a FontForge SFD file or a FontLab VFB file,
includes primarily font outline data and «metrics,» inter-letter
spacing numerical table data. This is always stored in an unobfuscated
machine-readable format, as humans need a machine to intepret and
visualise the data to make sense of it. Font source code can
secondarily contain information such as guidelines and elements of
composite characters (eg, the accents placed over Latin characters
like é) and programs that assemble the composite characters and
express «sophisticated» substitution behaviours.

Font object code, like a TrueType TTF or OpenType OTF files, do by
definition contain all the primarly font data needed for practical use
typesetting text, and are not obfuscated so they are still editable
with all font development programs. But they do not include much of
the secondary information (substitution behaviours are included as
«dumb» OpenType substitution lookup tables) if any at all
(guidelines.)

The information missing from the object file that is not «essential» -
the guidelines are inferrable from the design, and the obfuscated
«compiled» information could be decompiled - and the primary
information is still useful: A font developer using free software can
collaborate with a developer using non-free software, using only font
object data.

That is, they will be unable to collaborate fully.

This could be a problem, for example in lacking the same guides they
may add slight inconsistencies to the design."
- http://understandinglimited.com/2008/01/03/font-sourcecode/

> Reading these standard formats is trivial, there isn't the huge loss of
> information you get when you go from source code to executable. There's
> very little info stored in the sfd which is not in the ttf/otf final
> font.

This is great news. However, although the loss is not huge, I believe
it encumbers collaboration - so, the named guideline feature you
recently added to FontForge at my suggestion, is one clear example of
the loss involved.

> The distinction between source and final product isn't really relevant
> in the font world -- or I don't think it is.

I think it is become more and more relevant.

Build scripts especially.

> Don't know what's in VFB as FontLab doesn't have any description they
> can provide. I assume they are similar in capabilities to an sfd file.

I am yet to do a thorough feature survey of Fontlab, because I'm
coming up with plenty of ideas on my own just using FontForge, and
seeing other students on the MATD course using it. However, there seem
to be no major kinds of data that Fontlab users can author that
FontForge users can not. If I find any, I'll let you know ;-)

> Adam T. has asked me for a description of the sfd format (and didn't
> tell me not to tell others), so at some point FontLab might support that
> too.

That would be fantastic!

> > The XML schema "UFO" developed by the Robofab project could be a free
> > format, suitable for FontForge-FontLab collaboration since both
> > programs already read and write it, but I'm not sure it technically
> > can encode all the information that is encoded in a VFB file.
>
> UFO directories do not contain GPOS/GSUB info in their spec, they appear
> to be primarily designed to store the glyph outlines. The RoboFab people
> tell me GPOS/GSUB data can be included by throwing in Adobe feature
> files. Unfortunately Adobe feature files cannot express everything that
> goes into GPOS/GSUB either.
>
> So assuming VFB files can contain all GPOS info, then I believe UFO
> directories cannot express everything in them.

Thanks for clarifying this! :-)

-- 
Regards,
Dave