[Pkg-fonts-devel] Common script for conversion of font files
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Wed Feb 16 04:41:13 UTC 2011
On 02/15/2011 07:44 PM, Rogério Brito wrote:
> In other words, we won't have the infrastructure needed for that, not today,
> not in a million years, not whenever. Only if we change our computational
> models.
Somehow, the upstream team generated the fonts that they ship. We ought
to be able to replicate that. Why do we need to change our
computational models to do so?
> Summarizing, I am not against having the fonts built from source: just do
> that in the package building phase and, say, use the command line utility of
> fontforge to compare the result with what upstream gives us. If they are the
> same, throw them away and ship upstream's version.
hmm, i'd say if they are the same, throw away upstream's version and
keep the one we built since there's no difference :p
But the real question is what to do if there was a difference, not if
they're the same. If upstream ships a piece of code, with source and
binary, and we compile the source and get a binary that behaves
differently, we don't throw out our version and ship what they shipped.
I don't think we should make an exception to that rule if the software
happens to be a font.
> A recent case:
>
> http://bugs.debian.org/609094#10
> http://packages.qa.debian.org/f/fontforge/news/20110118T151726Z.html
I followed this discussion, and was happy to see that we could arrive at
what seems to be a functional solution by tweaking the toolchain to
bring the generated font more in-line with the binaries produced by
upstream.
That's a good thing.
As an upstream font developer (albeit a casual one), i actually
appreciate that other people attempt to build my font from source, and
will report if it fails with new versions of the toolchain. That's
useful information for me, since i'm not always tracking the bleeding
edge of the toolchain myself.
> And we are not even talking here about kerning and grid-fitting...
if we have problems with kerning, grid-fitting, or any other part, we
need to know about them, and we need to improve our tools.
Regards,
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/attachments/20110215/95018fc8/attachment.pgp>
More information about the Pkg-fonts-devel
mailing list