[Openfontlibrary] new release of the Ubuntu titling font
benlaenen at gmail.com
Sun Jan 13 05:32:31 PST 2008
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
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.
See above, we can extract all hinting instructions, but that's like
being able to extract all machine code instructions from a compiled
> 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
> Extracting the significant source code from the font file itself is
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
More information about the Openfontlibrary