Fonts are different between daily PPA and bzr repository

The problem is, that the fonts we bundle in bzr are quite outdated. Updating the font files would be a good idea, but is currently not possible, as the newer versions of FreeSans and FreeSerif are licensed under GPLv3 while Widelands is GPLv2 ... often discussed issue. Perhaps time to talk about it again...

By the way, I prefer the "old outdated" fonts of Widelands, because using them lines are more spaced and icons do not overlap.

Widelands is not strictly GPLv2 according to our source file headers:
"This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version."
So I think it is no big problem to add GPLv3 content. The whole program/package would be GPLv3 in this case, but the source code could remain GPLv2. But the discussion is slightly off topic here.

I've compared the daily PPA with a self-compiled version on Ubuntu Precise, and I see the same difference.

$ ls -la /usr/share/games/widelands/fonts/
total 12
drwxr-xr-x 3 root root 4096 Apr 5 04:53 .
drwxr-xr-x 14 root root 4096 Apr 5 04:53 ..
lrwxrwxrwx 1 root root 45 Apr 4 16:37 FreeSans.ttf -> ../../../fonts/truetype/freefont/FreeSans.ttf
lrwxrwxrwx 1 root root 46 Apr 4 16:37 FreeSerif.ttf -> ../../../fonts/truetype/freefont/FreeSerif.ttf
drwxr-xr-x 2 root root 4096 Apr 5 04:52 Widelands

I'm curious why the fonts try to link to system fonts and whether this is expected behaviour. Looks like the Widelands font (which would not be found on the system) is installed.

@#5: not sure if I've followed all the steps, but I'm quite sure the linking of fonts id defined here (http://bazaar.launchpad.net/~widelands-dev/widelands/debian/view/head:/debian/rules)

It should be of highest priority to fix the debian and ubuntu releases and not the daily ppa...
To fix the ppa later is no problem at all. This holds for the font problem and the language problem.
So, if you care, please contact the debian maintainer.

Fwiw, while looking into bug 973701, I discovered timowi's ppa seem to install the fonts like expected:

$ ls -la /usr/share/games/widelands/fonts/
total 1512
drwxr-xr-x 3 root root 4096 2012-04-09 15:36 .
drwxr-xr-x 14 root root 4096 2012-04-09 15:36 ..
-rw-r--r-- 1 root root 422472 2011-04-15 20:40 FreeSans.ttf
-rw-r--r-- 1 root root 1108164 2011-04-15 20:40 FreeSerif.ttf
drwxr-xr-x 2 root root 4096 2012-04-09 15:36 Widelands

Setting to incomplete for bug sweeping.

I explored what went on when packaging Widelands a while back when merging/tweaking the latest packaging from Debian. And it seems that the font symlinks are by design (see the rules file, specifically the override_dh_auto_install section) [1]. Presumably this is done because the fonts themselves are available in another package which then benefits any program on the system rather than Widelands shipping its own, duplicated fonts.

Though, Nasenbaer mentioned in #2 that there is a GPL2 vs 3 issue here, but won't the symlinked fonts be the newer ones potentially creating a problem here?

[1] http://bazaar.launchpad.net/~widelands-dev/widelands/debian/view/head:/debian/rules

not for us. The problem is for debian then.

[Expired for widelands because there has been no activity for 60 days.]

What is the conclusion here? I think the ppa should install the fonts that are ideal for us - not caring too much about debian conventions. When debian builds their .debs for releases and they decide to change the contents it is their problem.

I am not sure which fonts are idea for us though and I suggest we update the fonts we ship if that is beneficial. Licensing can be figured out.

Shipping our own fonts will definitely make it easier to make sure the strings fit on the buttons etc. in our translations.

[Expired for widelands because there has been no activity for 60 days.]

hjd, are we still linking to other peoples fonts in our PPA? If so, could you change that? Our PPA should be as close to our upstream as possible. If some debian maintainer feels that Widelands should use other fonts, they should change it in their .deb. Agreed?

+1 from me.

We will have more font packages included when my font branch is merged, and having some in the package and some linked would make things rather crazy.

I really think we should work together with the Debian maintainers on this one to find a solution suitable for all of us. I've therefore taken the liberty to assign this to one of them, Martin Quinson, for his input. You probably know more on the Debian-side of this issue than me.

In the meantime, some rough comments on my part:
From Debian's point of view, if a thousand packages all use the same fonts, there's no point in installing and storing new duplicates of the same font for each package. Therefore the fonts are split out and installed once in a single package which all the other packages can depend on. This takes less disk space, band width etc. and makes it easier to keep the operating system consistent.

The main reason we see a difference is because we use an older version of the fonts, while the common font used for the packages is newer. (See btw #10 and #11)

>Our PPA should be as close to our upstream as possible.

Well, there's really two upstreams here; we maintain the Widelands code, and Debian maintains the packaging. In order to build the daily builds in our PPA, we take the Debian packaging and do a couple of tweaks, mainly adjusting the list of dependencies to match what is actually needed in current trunk. My goal is that we can keep our packaging up to date by syncing newer versions from Debian, and provide a good basis for the changes needed when packaging the next stable release because we will already have done much of the work to keep trunk packages working. (Basically get a loop going where changes are pulled in both directions, and we benefit from each others work)

For that to work optimally, I'd prefer to keep our changes of the packaging to a minimum. This reduces the delta of changes, making it easier to merge in the latest packaging changes from Debian. (It also makes it easier for the maintainers to pull in our changes withouth having to filter out too much when preparing the package of a new stable release)

So it is rather easy to use the fonts from the Widelands repo instead, but I don't want to diverge too much from the Debian packaging if we can avoid it. Both to make it easier to keep the loop mentioned above going, but also because the vast majority of users on Debian/Ubuntu/Linux Mint and any derivatives of will use the packages available in the official repo. It's easy to say "oh, that's up for the maintainers to fix", but really it affects the Widelands our users will get, so it is in our interest to work together on this issue.

I'm also curious how the new fonts will enter into this discussion, and whether they exist in Debian or not at this point. (Btw, we already have a mix of fonts in our (the Widelands font) and other packages (every other I believe) today, so it's not all that crazy :) )

I think we should update our font version then. We use licenses that differ from our own for the font packages anyway, because otherwise it would not be feasible to have fonts for all languages at all.

I had another look, FreeSans.ttf and FreeSerif.ttf are used by Doxygen stuff only. Widelands itself uses DejaVu or depending on locale some other font set. So, linking FreeSans.ttf and FreeSerif.ttf won't affect the game at all.

Reply to #18:
> if a thousand packages all use the same fonts

I do not buy into that. disk space is cheap and fonts are tiny - so are images and data files. And there are not thousands of packages on any system, maybe a thousand. It is perfectly fine if all of them ship what they need (in contrast, any Mac OS App must ship all of it's dependencies except for the ones guaranteed to be on the system and that makes for simpler deployment, more stability and happier customers).

I understand and support the rest of the argument that we want to be as close to the upstream packaging with our PPA. My prime concern is our upstream though and we must have a consistent look and feel on all systems. I'd rather ship our own fonts and use them as data than using the debian fonts if at all possible. Widelands will not use any other system font, why should it depend on them then? Martin, is there no way around using the debian fonts?

#20: so that means that what upstream does right now does not really affect the game at all? So this discussion is moot than and we can just use our own fonts and be done with?

Did we at some point switch our main font from FreeSans/FreeSerif to DejaVu? This bug might have been reported before that. The discussion as such is still valid though, since packages might also link to DejaVu in the future if it is a system font, or MicroHei for CJK languages, which we will have soon.

Just to make sure, here's the grep output for FreeSans and FreeSerif:

bratzbert@museum:~/sources/widelands/trunk$ grep "FreeSans" * -r
build/doc/Doxyfile:# FreeSans.ttf font (which doxygen will put there itself). If you specify a
ChangeLog:- Now using new fonts (!FreeSans and !FreeSerif) licensed under GPL
doc/Doxyfile.in:# FreeSans.ttf font (which doxygen will put there itself). If you specify a
Binary file fonts/FreeSans.ttf matches

bratzbert@museum:~/sources/widelands/trunk$ grep "FreeSerif" * -r
ChangeLog:- Now using new fonts (!FreeSans and !FreeSerif) licensed under GPL
Binary file fonts/FreeSerif.ttf matches

And the full Doxygen comments are:

# By default doxygen will tell dot to use the output directory to look for the
# FreeSans.ttf font (which doxygen will put there itself). If you specify a
# different font using DOT_FONTNAME you can set the path where dot
# can find it using this tag.

# By default doxygen will tell dot to use the output directory to look for the
# FreeSans.ttf font (which doxygen will put there itself). If you specify a
# different font using DOT_FONTNAME you can set the path where dot
# can find it using this tag.

So, I think we get rid of these two font files. I don't know anything about Doxygen and I haven't tested it, but FreeSerif can go in any case.

The only thing that Debian requests is that the font files are not *dupplicated* over the packages. I confess that I only checked the file name to see whether the font files are the same. The automated robots checking for that in debian are more cleaver as they relay on md5sum (but they were not existing when I first packaged widelands)

If you are using a font called FreeSans.ttf which is not the classical (GPL) FreeSans.ttf, then I'll get fooled. But on the other hand, you should probably not use a non-classical font file without a good reason, I'd say.

If you guys confirm that you really want these fonts (after having checked that it's indeed not a duplicate), I'll use your version of course.

BTW, freefont and freesans are not the only fonts files that I link in the debian package:
  DejaVuSansBold.ttf -> ../../../fonts/truetype/dejavu/DejaVuSans-Bold.ttf
  DejaVuSansMonoBold.ttf -> ../../../fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf
  DejaVuSansMono.ttf -> ../../../fonts/truetype/dejavu/DejaVuSansMono.ttf
  DejaVuSans.ttf -> ../../../fonts/truetype/dejavu/DejaVuSans.ttf
  DejaVuSerifBold.ttf -> ../../../fonts/truetype/dejavu/DejaVuSerif-Bold.ttf
  DejaVuSerif.ttf -> ../../../fonts/truetype/dejavu/DejaVuSerif.ttf

But according to /usr/share/games/widelands/fonts/README.DejaVu that should be ok:
   Widelands uses the excellent Free Fonts from http://dejavu-fonts.org/. The only
   change did was renaming Oblique into Italic as we do not want to make a
   difference in our code base. Following is the DejaVu License.

Is it possible that dejavu got updated upstream without being updated in your tree?

I have been working on the font system recently (yet to be merged, https://code.launchpad.net/~widelands-dev/widelands/fonts/+merge/238608), and as a side effect the DejaVu fonts will get their original names back. So, we should have the same font version soon. So, linking should be fine since your robots do an MD5 sum.

Actually, the robots detect if we forgot to do a link ourselves, but the actual linking is still manual.

BTW, I just stumbled over http://pkg-fonts.alioth.debian.org/review/src-widelands.html which lists all the font files provided by the package. I am more and more convinced that you guys use an obsolete version of dejavu fonts, since the robot did not detect that they are similar in other packages.

That may explain the visual difference for the several fonts that I linked.

(forgot to say that it is perfectly your right to use an obsolete version of the dejavu fonts, and that I will stop doing the substitution if you want me too -- sorry for the noise)

As I said in #24, DejaVu will be updated soon. I just downloaded version 2.34 this week. So, I think it is fine. I don't know anything about packaging though, so I think we should hear what the others have to say to our recent posts before we make a final decision.

> Did we at some point switch our main font from FreeSans/FreeSerif to DejaVu?

Yes, I think I did that switch when I introduced the new font renderer as we did not have an oblique and bold version of the fonts we were using before. I did not spend a ton of time looking for the right font though and only looked after the licenses. I am fine with switching away from these fonts again.

> Is it possible that dejavu got updated upstream without being updated in your tree?

Entirely possible. I much rather use an outdated font though than having the look and feel changed by something external. Though I understand now that debian never does that - if we are using outdated fonts we will not get forced to use the new ones. I am confused though why the debian package then ships different fonts than the ones we use.

I conclude from this discussion that moving forward we should do the following:

- Merge Gun's branch (which will update our fonts to recent versions).
- Let the linkbot figure out that stuff our fonts are duplicated and apply the suggested linking for it.
- Keep taps on the debian font packages in the future so that we ship our own fonts as soon as the linked fonts are updated - so that the game does not change it's look and feel through a change in another font package.

Everybody agrees? Only the last step seems iffy - can that be automated?

Martin: Thanks for stopping by and answering our questions. Much appreciated. :)

>> Is it possible that dejavu got updated upstream without being updated in your tree?

>Entirely possible. I much rather use an outdated font though than having the look and feel changed by something external.

Fairly sure this happened. I don't remember the last time anyone actively updated the fonts until Gun's branch mentioned above.

>Though I understand now that debian never does that - if we are using outdated fonts we will not get forced to use the new ones. I am confused though why the debian package then ships different fonts than the ones we use.

Well... Technically it ships without these fonts but with a dependency to the font packages which provides them. Which was mentioned in #23, it was believed that since the name was the same, they were the exact same fonts which already existed in the other packages.
Presumably the Widelands-bundled fonts were stuck at a particular version while the Debian package pointed to whichever latest packaged version of the font, which led to noticable differences over time. Still DejaVu in both places, but different versions.

>- Keep taps on the debian font packages in the future so that we ship our own fonts as soon as the linked fonts are updated - so that the game does not change it's look and feel through a change in another font package. (...) can that be automated?

Semi-automated at least. If you look at https://tracker.debian.org/pkg/fonts-dejavu, that's the dejavu font package in Debian. Other font packages will have similar pages. Under news it has a list of the recently packaged versions (you can see they included 1.34 earlier this year). The megaphone in the news headline will give you an RSS-feed to keep track of any changes which happen to the package. Presumably (knowing Debian), there is also a mailing list where we can get notifications on this.

So packaging-wise (once Gun's branch has been merged):
A) I believe the packages in our PPA should use the Widelands-bundled fonts, and stop linking to external fonts.
B) Throughout the development cycle we keep an eye on newer versions of the fonts we use and include them in the Widelands repo as they appear. (Our PPA continous to use whatever happens to be the latest fonts we have in the Widelands repo)
C) Once we get an official release and it is time to package it in Debian, we use the linkbot to check for duplicates. Any font we have in Widelands which is also packaged in Debian, is replaced with a link/dependency. In the case where Widelands has an older/newer version of a font than Debian, we use the one provided in Widelands. (Debian packages may replace some fonts, but only the ones where Debian already has the exact same one)
D) After a new Widelands version has been packaged in Debian, we merge the packaging to our PPA. The PPA continues to use the fonts from the Widelands-repo, and we are effectively in state A/B again.

sounds like a plan. Can we close this bug then when we merge the fonts branch?

>Can we close this bug then when we merge the fonts branch?

Almost. We'll also need the branch I've attached to stop replacing the bundled fonts. (This is step A as outlined above.)
That should take care of things on the Widelands-side.

With the latest packaging merge and PPA build we have reached step A. We now use the Widelands-bundled fonts.

Fixed in build19-rc1.