tasklet - sfd2ttf - eliminate dependency on FontForge (for anybody who's interested)
Hi, Wine's build time dependency on FontForge is causing a bit of a problem, as can be seen by browsing the wine-devel archives for the last month. I propose that a small sfd2ttf utility be written and used instead of FontForge to eliminate the dependency, and make everybody a little happier. George Williams, the author of FontForge, is happy for us to use his code under LGPL, providing that we give the correct attributions. He'd probably like to sign off on the final code though. Alexandre agrees with the idea of an sfd2ttf utility, and is likely to accept it into the Wine tree, provided that is small enough (read 1/2 files) and is appropriately cut down. As I'm busy with my day job at the moment, we're only missing somebody to write it. Any volunteers? Mike
Mike McCormack wrote:
As I'm busy with my day job at the moment, we're only missing somebody to write it. Any volunteers?
I'd be happy to volunteer, but.. 1.) I haven't got the knowhow (I don't even know what an sfd file is) :-). 2.) Seems like slight overkill, considering that the user can just install FontForge. What is wrong with the simpler solution you mentioned:
* put a warning about this in configure
?
On 4/13/06, Molle Bestefich <molle.bestefich(a)gmail.com> wrote:
2.) Seems like slight overkill, considering that the user can just install FontForge. What is wrong with the simpler solution you mentioned:
* put a warning about this in configure
This issue that we can really do decent font support with our fonts and not building them creates problems. So it'd be really nice to have the fonts available rather than just warn someone they won't be. Sure, installing fontforge isn't too hard (I did it in all of about 2 minutes last night) but eventually it's going to cause problems. Maybe because it doesn't work on a future FreeBSD or MacOS X release, maybe because one of their releases is broken with regard to our sfd files and we have to work around it, etc, etc. What Mike's task boils down to is making a simple font generation tool. Fontforge has about 800 bizillion features and we need two: parsing sfd files and generating a TTF from them. -Brian
On 4/14/06, Brian Vincent <brian.vincent(a)gmail.com> wrote:
This issue that we can really do decent font support with our fonts and not building them creates problems. So it'd be really nice to have the fonts available rather than just warn someone they won't be. Sure, installing fontforge isn't too hard (I did it in all of about 2 minutes last night) but eventually it's going to cause problems. Maybe because it doesn't work on a future FreeBSD or MacOS X release, maybe because one of their releases is broken with regard to our sfd files and we have to work around it, etc, etc. What Mike's task boils down to is making a simple font generation tool. Fontforge has about 800 bizillion features and we need two: parsing sfd files and generating a TTF from them.
Maybe this is a stupid question, but why can't we just distribute the ttf files directly? n0dalus.
On 4/13/06, n0dalus <n0dalus+wine(a)gmail.com> wrote:
Maybe this is a stupid question, but why can't we just distribute the ttf files directly?
Because we're masochists and prefer to build tools. It's definitely the simple solution and we're capable of doing that. There used to be issues with having binary files in CVS, but I'm not sure that's as big of a problem. However, as a general rule of thumb the source code releases are just that - source code. The proper solution is to distribute the .sfd files and compile them during the build process. It's the same reason we don't include .bmp or .avi files; we have tools to build them from the resource files. The goal here is to take the functionality in fontforge and trim it down to the bare minimum of what we need. -Brian
Brian Vincent wrote:
2.) Seems like slight overkill, considering that the user can just install FontForge. What is wrong with the simpler solution you mentioned:
* put a warning about this in configure
This issue that we can really do decent font support with our fonts and not building them creates problems. So it'd be really nice to have the fonts available rather than just warn someone they won't be. Sure, installing fontforge isn't too hard (I did it in all of about 2 minutes last night) but eventually it's going to cause problems. Maybe because it doesn't work on a future FreeBSD or MacOS X release, maybe because one of their releases is broken with regard to our sfd files and we have to work around it, etc, etc. What Mike's task boils down to is making a simple font generation tool. Fontforge has about 800 bizillion features and we need two: parsing sfd files and generating a TTF from them.
Ok, thank you for that explanation. And I guess that the FontForge license prohibits using pieces of code from there, right?
On 4/13/06, Molle Bestefich <molle.bestefich(a)gmail.com> wrote:
Ok, thank you for that explanation. And I guess that the FontForge license prohibits using pieces of code from there, right?
Actually, as the first email read, the author of FontForge is happy to let us use his code. So all we really need is someone that has the know-how to do it... I agree with everyone else here, the easiest solution is to include the binaries, but since we dont like to do that, then the sfd2ttf is the next best possible option, and I prefer that over making users install fontforge.. It would probably solve a lot of the other font-related bugs that have cropped up in bugzilla over the last month or so. Tom
On 4/13/06, Tom Spear <speeddymon(a)gmail.com> wrote:
On 4/13/06, Molle Bestefich <molle.bestefich(a)gmail.com> wrote:
Ok, thank you for that explanation. And I guess that the FontForge license prohibits using pieces of code from there, right?
Actually, as the first email read, the author of FontForge is happy to let us use his code. So all we really need is someone that has the know-how to do it... I agree with everyone else here, the easiest solution is to include the binaries, but since we dont like to do that, then the sfd2ttf is the next best possible option, and I prefer that over making users install fontforge.. It would probably solve a lot of the other font-related bugs that have cropped up in bugzilla over the last month or so.
Tom
And with that being said, I have created a tasklet bug in bugzilla. http://bugs.winehq.org/show_bug.cgi?id=5065 Tom
On 4/13/06, Molle Bestefich <molle.bestefich(a)gmail.com> wrote:
Ok, thank you for that explanation. And I guess that the FontForge license prohibits using pieces of code from there, right?
Nope - read Mike's earlier email. George Williams agreed to relicense the necessary bits under LGPL. -Brian
Molle Bestefich wrote:
2.) Seems like slight overkill, considering that the user can just install FontForge.
Eliminating dependencies[1] is a Good Thing (tm). It makes it easier for people to install and use our software. We're also discovered that not all versions of FontForge are equal, and that's not easy to detect in configure.
What is wrong with the simpler solution you mentioned:
* put a warning about this in configure
We have one now. People can't read :) I suspect it also has to do with people configuring Wine like this: ./configure && make which means any configure warnings will most likely be missed. We can try go a step further and pass a non-zero exit code to the shell, so the above fails. The FontForge author has indicated that he will give permission to license sfd2ttf based on FontForge code as LGPL. The task is to take some of the FontForge code, turn it into a sfd2ttf and make it acceptable for inclusion into Wine. Mike [1] http://www.joelonsoftware.com/articles/fog0000000007.html
On 4/14/06, Mike McCormack <mike(a)codeweavers.com> wrote:
The FontForge author has indicated that he will give permission to license sfd2ttf based on FontForge code as LGPL.
The task is to take some of the FontForge code, turn it into a sfd2ttf and make it acceptable for inclusion into Wine.
So, I guess the easiest way to do this is to run the program through gcov and work out which code gets used and what doesn't in the process of converting the fonts. n0dalus.
participants (5)
-
Brian Vincent -
Mike McCormack -
Molle Bestefich -
n0dalus -
Tom Spear