Hi Martin, thanks for your fast response!
I'm using the web interface to reply since it seems that the mail alias
is broken...
On Tue Nov 27 00:41:15 2007, martin_hosken@sil.org wrote:
Show quoted text> > Hi, after upgrading to version 0.43, I found that you ship a font that
> > is considered non-free for Debian, so I removed it and placed a
> > different font in its place.
Show quoted text> I think you will find the Open Font License under which the test font is
> licensed is Debian compatible. There are a few OFL fonts in Debian now.
Maybe I rushed too much on that assumption. I didn't check debian-legal,
but now that I did, it seems that it's being considered DFSG-free. I
thought that the restriction on selling would render it non-free
instantly. Maybe other more people from the perl group (CC'ed) can add
on this.
Show quoted text> Rather than rushing to switch it, let's chat a little. Also can you send
> me the font you switched it with. It would be nice if the packaged
> version didn't drift too far from the upstream version.
Of course, we also want that. About the font, I'm attaching the one that
gave me the most amount of errors (and it kept failing after following
your advise), DejaVuSans.ttf.
Show quoted text> > After doing that, the test case fails with hundreds of errors. I've
> > tried with fonts from the dejavu and bitsream-vera packages without
> > success. So I think that maybe this is uncovering a bug in the
> > Font-TTF distribution.
Show quoted text> Well did you 1) create a benchmark font. 2) realise that copying a font
> the way the test code does, tends to normalise the font and so can
> result in binary differences that are not functionally different (or it
> may even tidy up the font). So it's best to use the output of ttfcopy as
> the benchmark.
No to both points, sorry. I assumed that any ttf font would be okay for
the test case. Now I've read the notes on the Font::TTF::Font manpage
which says how to run the test case which is almost identical to
ttfcopy.t, but the t/ttfcopy.t code wasn't very descriptive :).
I've tried running the code from the manpage: two runs in a row give the
same md5sum for Bitstraem Vera Sans; for DejaVu Sans it takes a *lot*
more CPU and the files differ. Below are the steps I did:
$ cat test # Verbatim from the manpage
$f = Font::TTF::Font->open($ARGV[0]);
# force a read of all the tables
$f->tables_do(sub { $_[0]->read; });
# force read of all glyphs (use read_dat to use lots of memory!)
# $f->{'loca'}->glyphs_do(sub { $_[0]->read; });
$f->{'loca'}->glyphs_do(sub { $_[0]->read_dat; });
# NB. no need to $g->update since $f->{'glyf'}->out will do it for us
$f->out($ARGV[1]);
$f->release; # clear up memory forcefully!
$ perl -Iblib -MFont::TTF::Font test
/usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf VeraOut1.ttf
$ perl -Iblib -MFont::TTF::Font test VeraOut1.ttf VeraOut2.ttf
$ perl -Iblib -MFont::TTF::Font test
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf DejaOut1.ttf
$ perl -Iblib -MFont::TTF::Font test DejaOut1.ttf DejaOut2.ttf
$ md5sum *ttf
3bb5379386a6973efbea081c12817f5f DejaOut1.ttf
c7f4864d7ea5a9e106b35cb0b0100f93 DejaOut2.ttf
1f6ceef6c75213c10f51679a696a96f4 VeraOut1.ttf
1f6ceef6c75213c10f51679a696a96f4 VeraOut2.ttf
$ ls -l *ttf
-rw-r--r-- 1 martin martin 592196 2007-11-27 03:55 DejaOut1.ttf
-rw-r--r-- 1 martin martin 582060 2007-11-27 03:55 DejaOut2.ttf
-rw-r--r-- 1 martin martin 66076 2007-11-27 03:54 VeraOut1.ttf
-rw-r--r-- 1 martin martin 66076 2007-11-27 03:54 VeraOut2.ttf
As a suggestion, wouldn't the test case be improved if you modify it to
automatically do the two passes so it can accept any TTF as input?
Cheers, Martín.