Bug#595963: [Pkg-fonts-devel] Bug#595963: RFP: yanone-kaffeesatz -- TTF and OTF font in four weights
Nicolas Spalinger wrote:
> 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?
Well, as far as I read it one is optimized for DTP usage and the other
one for GUI usage, so I expect both variants to be useful.
> 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.
Ok, so this has been discussed already.
> 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).
fonts-$foundry-$fontfamilyname sounds way more sane to me for source
I'm glad to see that topic on the todo list, I though wonder why newly
packaged stuff should not start using what is planned. Or is just
planned to change it, but not yet decided how to change it?
> > 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:
I do. So thanks for your time to explain them. :-)
> - 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.
Ok, didn't knew that indeed. Good to know and glad to hear..
> 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.
Sure. I was just wondering why a TTF without it's source is still free
software. You explained that well.
> - Fonts are software
I wasn't really aware of that. I basically saw them like some vector
or pixel graphic image...
> and CC licenses are for assets (content, documents, music, images)
> and Creative Commons strongly discourages using a CC combination for
Yep. That's well known for me. I just applied it to fonts the other
way round because I saw fonts more like assets than software.
> Using CC licenses for fonts is a bug and something Debian should
Oh, even that bad?
> Kaffeesatz's relicensing is good news in that regard.
Yeah, I figured that when reading
And just now I noticed that you are one of the authors of that
license. Thanks for that license!
> - 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?
That's basically the question I wondered about.
> (there is also the issue of how the GPL interacts with font
> - 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.
Short said: the common problem with the multiple meanings of the word
> Hope that helps,
It did indeed, thanks a lot!
> Thank you for your efforts around font packaging. You're always welcome
> to join our team and help out :-)
Not sure if I'll go that far and join the team, but at least I
sponsored already some font packages. :-)
,''`. | Axel Beckert <firstname.lastname@example.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5