sfd2ttf

[Dimi Paun]

On Fri, April 28, 2006 9:42 am, Mike McCormack said:
> Somebody has finally spent the time needed to:
> 1)  Eliminate a dependency (good!)

This is indeed a problem and it would eliminated in both
cases. It's just a matter of how we accomplish this.

> 2)  Keep binaries out of the GIT/CVS tree (good!)

I'm all for this, don't get me wrong. But it is not
an absolute thing, it has to be balanced against the
other evil. If we blindingly follow that it is just dogma,
and it doesn't seem to be such a worthy cause after all.

As I said, virtually any Java project in existance checks in
.jar files, and none of them suffer from any negative ill effect.

> The code is still a bit big, but I'm confident that can be addressed.

It's insanely big. And it's not a one time thing, we'll have to
maintain that. It's an ongoing cost. With what purpose? We will still
have the textual representation in GIT, so changes will be displayed
for those so inclined to read them. The binary files will not be included
in the diffs. Bottom line is that from an outside perspective the
diffs will not change. The only thing that will change is:
  1. No dep on fontforge
  2. Ability to control _which_ fontforge we use
  3. Uniformity in fonts used by users (easier to support, etc)
  4. Simplicity

What we loose is just an increased size of the archive. How big
will this increase be, BTW? Can someone please how big is a
.tar.bz2 of all the binary font files?

> If binaries were going into the source tree, then it would have started
> with the icon/bitmap resource.  Anybody remember who spent "tens of
> precious developer hours" to come up with bin2res so we didn't need to
> checkin binaries then?

Please, that's a trivial utility. As I said, it's a balancing act.
It was very simple to have the bin2res, it looks a lot more complicated
to have sfd2ttf. If all we wanted is to avoid binaries in GIT (why?),
we can covert .ttf to hex via bin2res :) But I think that would be
worse than the problem...

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.