[OpenFontLibrary] workflow hints

[Schrijver]

Op 15 jun 2010, om 12:15 heeft Barry Schwartz het volgende geschreven:

Hi,

> There is no way it would
> work for me; I've got my stuff in a combination of sfd, feature files,
> and python, with fontforge features hijacked to perform tasks for
> which they never were intended.

Yeah but that would be hard to handle in any collaboration setup no?

> My fear is that UFO will be to fontmaking as GNU Hurd is to
> GNU.

That’s incorrect. UFO is being used.
It was conceived as an interoperability format for font applications. It is actively being used in commercial font development tools like Superpolator, and OSP uses it inside their Nancy software.

We haven’t seen it used a lot for for open source distributed font development because that was never a design goal—it just happens to also work for that.

But again, it has been used and does work. The OpenBaskerville project is a proof of concept in this respect.

> Making tools to ease merging of sfd fonts seems, perhaps, a more
> worthwhile endeavor. If some people are using fontforge and others are
> using proprietary ware then the problem arises of how to keep the
> project itself from being a slave to the proprietary ware, and that
> might be really difficult. It would be necessary that nothing peculiar
> to the proprietary editor be contained in the font; and the
> proprietary editor would have to be able to handle peculiarities of
> fontforge that it might encounter. In the case of my own fonts, it
> would have to handle my spacing-by-anchors system, which may be a
> nontrivial requirement.

And these are exactly the reasons for and against using UFO.

If you use SFD, you can always use whatever new feature fontforge comes up with. I know Raph and Dave like to draw spiro curves, for example. That isn’t possible in UFO, and probably won’t be very soon since no other software than fontforge supports it.

That’s a real drawback.

On the other hand, having a file format that’s written for one program makes it more difficult to write new tools that use it, like the UFO diff visualisation GitHub made.

What’s for me really important and why I want to work with UFO: standardising on one program makes the world of open source type development more closed (even though all the software is free); opening up the workflow to other tools makes it more easy for people coming from a different background and for clasically trained designers to get involved.

> 
> Often it is best simply to say "Use GNU make" rather than try to write
> a Makefile that works on everything. :)
> 

UFO is not a makefile, it’s the source. That’s completely different.

For compiling the source to typefaces it does make sense to standardise on a certain tool and method; I could say use python/fontforge,

best,

Eric