[Pkg-fonts-devel] Bug#595963: RFP: yanone-kaffeesatz -- TTF and OTF font in four weights

Nicolas Spalinger nicolas_spalinger at sil.org
Wed Sep 8 14:02:02 UTC 2010


Axel Beckert wrote:
> Hi,
> 
> Christian PERRIER wrote:
>> Quoting Axel Beckert (abe at debian.org):
>>> Package: wnpp
>>> Severity: wishlist
>>>
>>> * Package name    : yanone-kaffeesatz
>> Could that be turned out into ttf-yanone-kaffeesatz?
> 
> I deliberately did not choose ttf-yanone-kaffeesatz since the name
> above should be the source package name and not the binary name. (The
> same counts for the description. I'd not put my description in the
> binary packages, but I'm not very good at describing non-technical
> font characteristics.)
> 
> And if the source package will contain both, TTF and OTF, I would
> regard ttf-yanone-kaffeesatz as a very bad choice.
> 
> The resulting binary packages of course should be named
> ttf-yanone-kaffeesatz and otf-yanone-kaffeesatz.
> 
>> Of course, the package is meant to provide OTF and TTF fonts, but
>> that would at least follow the naming logic of other font packages?

Well, it you look at upstream descriptions there is an intended
difference of usage between the OTF and the TTF. One being specific to
another OS' rendering environment. Do we really need both debianized?

And I agree with Christian that we want to follow a general naming
convention for the fonts packages we maintain in the archive.

Although it was decided a while ago that a big renaming/split was not
essential for now, given our team resources. We have some
ttf-$foundry-$fontfamilyname containing OTF files at this stage and it's
not the end of the world IMHO. We can deal with that someday. (other
distros have renamed to fonts-$foundry-$fontfamilyname for example).


> If that is the logic, it is no logic.
> 
> But I fear it's really that mad:
> 
> Package: otf-freefont
> Source: ttf-freefont
> 
> And the source neither has TTF nor OTF but only SFDs. I regard such
> cases of source package names as quite misleading.
>
> Anyway, back to this RFP: I saw font packages in the archive which had
> only the TTF files in the source package while I also saw packages
> like ttf-freefont, which do have SFD files as "source" for the TTF and
> OTF files.
> 
> Then again, there are fonts under CC licenses (which seems fine for
> TTF files as they are "art" similar to images or texts) as well as
> GPL'ed fonts (where I'd expect to be able to get the SFD "source").
> 
> Does Debian make any difference between those two types of "free"
> fonts?

You seem to be missing some facts about fonts and font design in your
analysis, please allow me to try and explain:

- various open fonts we have in the archive are created with a buildpath
we can't fully reproduce with unrestricted tools at this stage. Or that
we can't fully rebuild to reach the same quality and feature parity than
the upstream release. The thing is that if a maintainer recreates a
different buildpath from the upstream author then they are effectively
committing to maintain a derivative version. But the final TTF or OTF is
both object and source as you can open them in fontforge, make
modifications and create a derivative. So even if the upstream release
only contains a set of final TTF files, it is already source you can use
to a certain extent. Yeah, quite unique I know but fonts are a special
kind of software. You can always export the ttf to text-based source
formats and work from that too: sfd, ufo, ttx. We're working to advocate
the release of more extended sources (smart font code, hinting, glyph
and attachment point databases, scripts, etc) to designers and working
on extending the open font design toolkit. It would be a pity (rather
silly really) to discard all the usable, distributable, modifiable,
redistributable fonts you have managed to get released under appropriate
licenses over the past few years because not all designers are using
fontforge on Debian as their preferred design environment. We're working
on this from I feel is a more productive angle. Also we don't have the
manpower to fork and separately maintain all the quality open fonts
currently in the archive.

- Fonts are software and CC licenses are for assets (content, documents,
music, images) and Creative Commons strongly discourages using a CC
combination for Software but recommends using dedicated OSI or
FSF-approved software license instead:

http://wiki.creativecommons.org/Frequently_Asked_Questions#Can_I_use_a_Creative_Commons_license_for_software.3F
" Can I use a Creative Commons license for software?
We do not recommend it. Creative Commons licenses should not be used for
software. We strongly encourage you to use one of the very good software
licenses which are already available. We recommend considering licenses
made available by the Free Software Foundation or listed at the Open
Source Initiative. Unlike our licenses, which do not make mention of
source or object code, these existing licenses were designed
specifically for use with software. "

Using CC licenses for fonts is a bug and something Debian should
discourage. Kaffeesatz's relicensing is good news in that regard.

- many GPL-ed fonts are still very fuzzy about what is the preferred
form for modification and have been created outside a reproducible
buildpath. What is their source? How can people properly satisfy the
source requirements of the GPL in a font context? Can they really make
use of it? (there is also the issue of how the GPL interacts with font
embedding).

- also "free fonts" is a very misleading expression as in the design
community it is always associated with dubious
maybe-redistribute-but-don't-modify-fonts, IOW freeware (often ripoffs).
Check your preferred search engine. We talk about libre/open fonts
instead to indicate the big difference between these fonts with a bad
reputation and fonts which their authors want to be usable,
distributable, modifiable, redistributable i.e. DFSG-compliant. We don't
want anyone to confuse the two! And well there's always the issue of
"free" being misunderstood as "this don't cost any money" but "free
font" as a fixed expression lead to even more misunderstandings and
should really be avoided.

> Because for Kaffeesatz you just get the TTF and OTF, not the source --
> if any exists at all. (I have no idea how many ways are there to
> create TTFs or if you even can create it directly in an editor.)

I doubt that the author of Kaffeesatz is using Debian or fontforge so
the fonts he has released under a DFSG license is what we get as source.
But we may get more in the future.

In the Google upstream repository we're setting up the recommended best
practises for designers to publish extended sources beyond the ttf.
Doesn't happen overnight though, give us a little time :-)

> It could also be a possibility to make two source packages out of it,
> ttf-yanone-kaffeesatz and otf-yanone-kaffeesatz since upstream
> distributes the font as two ZIP files, one for the TTFs and one for
> the OTFs -- which means that repackaging is necessary anyway, so a
> single source package would make no real difference, and I'd expect
> that our ftp-masters would prefer the single source package.
> 
> P.S.: Please Cc me, I'm not on the list.
> 
> 		Regards, Axel


Hope that helps,

Thank you for your efforts around font packaging. You're always welcome
to join our team and help out :-)

Cheers,

-- 
Nicolas Spalinger, NRSI volunteer
Debian/Ubuntu font teams
http://planet.open-fonts.org


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/attachments/20100908/c58150a7/attachment.pgp>


More information about the Pkg-fonts-devel mailing list