[Openfontlibrary] new release of the Ubuntu titling font

[Ben Laenen]

On Sunday 13 January 2008, Christopher Fynn wrote:
> OK the closet thing to source code ma be something like the FontForge
> / FontLab file used to create the font *plus* additional things used
> like MS Volt project files, Adobe feature files,  python scripts,
> etc. Though you can quibble about  details or particular fonts it is
> questionable whether *in most cases* these "sources" contain much if
> anything that is very significant or useful beyond what can easily be
> extracted from the font file itself.

Okay, I understand that for most people fonts are glyphs which are 
outlines. But we've mentioned a lot of times now that fonts are *much* 
more that is useful information. And we have a bit of experience with 
DejaVu with things that are missing in the ttf "sources" we've 
inherited from Vera. (but Vera as we all know wasn't licensed under 
GPL, but under it's own BS Vera license; point is that the same would 
happen with every GPL font as well)

Take the CVT table for the hinting instructions for example (that's a 
big table with numbers that are used for hinting, sorry for going 
technical immediately). We've never been able to get a full table of 
what all those numbers do. We know about a dozen of them in each font 
which we can use to make our own hinting instructions. That leaves more 
than 200 in each font file (and there are 10 of them) which have no 
meaning to us at all. Numbers which could be very useful for us if we 
knew what they were. Trying to "decode" that table would just take too 
much time, as that would mean reading and interpreting the instructions 
of each glyph in each font, so we have to keep them as black boxes.

And the same happens with the "prep" (alters CVT numbers for specific 
font sizes) or "func" (a few functions which alter numbers on the 
stack, or changes CVT numbers) hinting instructions: we just don't 
understand what they do. Hinting instructions is almost like machine 
code, we just can't understand what they do without documentation, and 
there's not the slightest hint available to us about that.

These things aren't useless information, they effectively define how the 
fonts will look on your screen. We could do good things with it if we 
only understood what they're doing.

I've effectively been thinking once to just drop all current 
instructions and start from scratch.

> I don't think the fonts & compiled executables are comparable.
> One cannot easily decompile a binary originally written in C and
> come up with anything that looks like the "source code" used to write
> the program - or perhaps more to the point directly import a compiled
> executable directly into a programming IDE and make changes - in the
> way you can import a font file into a font editor and start making
> changes.

The more I look at it, the more I am convinced that compiled fonts and 
compiled executables are comparable. The instructions above *are* 
programs. Again, calling what you get when you "decompile" those into 
the human-readable form the "source" you get a program with a heap, a 
stack and a lot of low-level stack and point manipulation instructions. 
Now, that doesn't really look too different compared to a compiled 
program, does it? Since that's basically what is being done when 
compiling a program: translate your high-level code to low-level 
instructions which manipulate stacks and heaps and do system calls. I 
challenge everyone to understand those low-level instructions from even 
a small C program. But it's what we have to do in DejaVu with what 
we've got from Vera, although there's something higher level available, 
which is much easier to understand and manipulate. Don't think that 
hinters at Bitstream manually entered all those instructions...

> Not necessarily - you can extract *all* the outline,

As said above: design a glyph in cubic curves, compile it in ttf and get 
quadratic curves, open ttf and convert quadratic curves back to cubic 
ones and you get different curves than the original ones. We 
effectively cannot extract the original curves again.

> hinting,

See above, we can extract all hinting instructions, but that's like 
being able to extract all machine code instructions from a compiled 
program.

> OpenType tables etc from the final font.

Even OpenType tables have useful metadata in font sources, if only 
giving a name telling what they do.

> - If some kind of "auto 
> hinting" was used while generating the font the final font may in
> fact contain much more information than the original VFB or other
> "source" file.

Ugh, that's just plainly wrong.


> What you may be missing are things like guidelines (usually easily
> extrapolated) or build scripts (not used for many fonts) - How
> significant are these in most cases?

extrapolation will give errors, ttf point coordinates are also usually 
rounded to integers as well, giving more errors when trying to retrieve 
original data.

> Extracting the significant source code from the font file itself is
> trivial

No, extracting a source code format which will give the same output as 
the compiled font when recompiled is trivial (but then again, that's 
exactly the same like translating a compiled program to some 
human-readable machine code, which you could also compile to binary 
form again and get the same end-result). Extracting the significant 
source code cannot be done.

> and in many cases more accessible in that final format than 
> in e.g a FontLab VFB file. - So, to me, this seems an unnecessary
> restriction in the case of fonts.

No argument there, but if there were VFB files, there would be some way 
eventually to look into it and see what the original source was. It 
would still be better than what we have now: no way at all to retrieve 
the original source.

> If GPL does force this should it be considered appropriate license to
> use for fonts ??

GPL would work great if we would enforce that "source" part of it, which 
is now blatantly ignored. If they don't want to release source, just 
use OFL, don't misuse the GPL then.

> Why be so fundamentalist in the case of fonts? -  in many ways
> shouldn't fonts be considered more akin to graphics or even music
> than to executable programs?
>
> 1) The *significant* "source code" of a font is accessible or easily
> extractable from the font file itself.

Again, see above, if your "significant" means "gives the same result 
when compiled again", then you're right of course.

> 2) Unlike other software most fonts are perfectly functional for
> years and years without modification. I can use the original Adobe
> Type 1 fonts or URW Type 1 fonts from years ago on a modern system
> with no loss of functionality. Realistically in the overwhelming
> majority of cases users will never want to modify a font. So in
> practical terms there are probably few real world cases where use of
> a font released with full source code redistribution  has any
> practical or useful advantage over using one released without -

Free fonts have the same purpose as free software: being able to modify 
and redestribute, and derivatives need to be Free as well. And 
modifications happened a lot to a lot of the Free fonts so far (adding 
a few glyphs, fixing things, adding opentype features, you name it).

And in the overwhelming majority of cases users of programs will never 
want to modify it either. 99.99% of users will never look at the linux 
kernel source code but use Linux everyday. So maybe only 0.001% of 
users try to open a font in FontForge, but that's not significantly 
different compared with programs.

> 3) Usually one font can be simply substituted by another without
> significantly affecting anything - except maybe aesthetically - so it
> is not like users can be "locked into" a particular font in the same
> way they may be locked into particular software applications or
> operating systems unless they have access to the source code. [An
> exeption to this might be GUI or system fonts used as standard in
> Menus, dialog boxes etc. ]

OK, it happens to be easier to make derivatives from a compiled font 
file compared to a compiled program. And that's why OFL doesn't require 
source code either. I'm only trying to make you people understand that 
there *is* source code available for fonts, and that that source is 
inherently different from any decompiled version from a 
ttf/otf/whatever. Since GPL requires redistribution of the source when 
one makes modifications, or if you just redistribute it yourself, fonts 
like the Liberation Fonts are effectively unredistributable.

> 4) If you are not allowed to modify a particular font - I can think
> of few cases where the font could not easily be substituted with one
> you can modify.

?

> IMO for *all* these reasons the need for having full original "source
> code" for fonts is in no way compatible with the need for having
> source code for executable programs.

IMO, the only way to get high quality derivatives from a font would be 
if you have access to the original source.

> In order to encourage font designers to make their fonts in some way
> freely available, rather than imposing such restrictions  I think
> there should be an easy way for designers to choose from a number of
> licenses appropriate to fonts (including OFL) and select one they are
> comfortable with - in the same way Creative Commons offers different
> license choices for other artistic creations.

Sure, if they want OFL, good for them, I'm not pursuing the source for 
those fonts then (even though it would be nice to have), but could we 
keep GPL for the fonts *with* source code, as the GPL requires?

> Some designers will be prepared to release fonts which may be freely
> distributed but will want to protect their designs by not allowing
> modifications or derivatives. While this may be less than ideal - I
> think it should be catered for and made easy - especially where the
> alternative is that the font may only be commercially available.

dafont.com has everything you need

> - Chris

Greetings
Ben