[Sorry for the re-post, I did not know had to subscribe to the Fedora list.]
Hello Pravin Satpute et al.,
I am one of the maintainers of the liberation-fonts package in Debian
(it is called fonts-liberation there ) and I am a bit concerned about
the current state of development and the future of these fonts. I have
read that the new release 2.00.1 based on Google Crosscore fonts has
been defered from Fedora 18 because of rendering regressions .
However, since then development has apparently stopped in the GIT
Have these rendering regressions been identified? Are they going to get
addressed in the fonts or in other parts of the font rendering stack?
Will there be another release of the liberation-fonts in the short term
or have these fonts been defered altogether in favor of another font family?
Thanks for your replies,
Hi, I've added a bunch of IPA letters to the Liberation Serif font.
Here's a picture of them:
[image: Inline image 1]
IPA letters are more than just mirror versions of regular latin letters, so
I tried to make them "real", following the serif rules, etc. For example
the /ɹ/ letter has only one serif on top, and the crossbar on /ə/ is at the
same height as the one on /e/. I've only done the Regular weight, but if
you're interested I can do italic, bold, etc.
The TTF and SFD source are attached. It's very rough—the letter outlines
aren't fused (to make editing easier), and there might be some
clockwise/counterclockwise errors. The letters displayed fine in Inkscape
Le Mar 23 juillet 2013 19:26, T.C. Hollingsworth a écrit :
> Honestly, I'd prefer that we fixed this in Fedora. It solves this
> problem quite nicely, and I don't really think it's that widespread an
> issue anyway.
Historically it was quite widespread. The only bit of font metadata one
could rely on was the font name, and then not always. A font author would
widely announce the relicensing of his font and not change the metadata in
the font files. Even Google Droid had rotten licensing metadata when it
was first released IIRC
However there has been quite a lot evangelization about this issue in
free/open font circles those past years, so the situation may have
> (I'm going to run a script to check soon; I'm
> downloading 300MB worth of fonts right now. ;-)
> AFAICS it shouldn't be too hard to script up something so this would
> as easy as `fixfontmd --copyright "$(head -n3 LICENSE)" --licensedesc
> "$(cat LICENSE)" --licenseurl "http://example.com/LICENSE"` for
> I'd be happy to add a guideline for this and fix up existing packages
> if this seems amenable.
If you can write a tool that makes it easy to fix opentype licensing
fields at build time, I'll be delighted to support any guideline change
that mandated its use. However if you go in this direction please check on
the fonts and openfontlibrary list knowledgeable people agree there are no
wrong side-effect (this will reach debian font packagers at least BTW)
Le Lun 22 juillet 2013 17:07, Robert Marcano a écrit :
> Fonts has licenses, some of them require the license to be shown or the
> copyright displayed, some fonts has the copyright added to their
> metadata, I don't find for example that gnu-free-serif-fonts says on
> it's metadata that is GPL+3 with exceptions.
I'd say that when a font requires some communication of licensing
downstream, but forgets to put its own license in the font metadata,
that's an upstream problem. Upstream can not complain Fedora didn't work
hard enough about something it didn't do itself.
It's another thing when the licensing actually prohibits distribution, but
we don't have those in Fedora, and people that deploy such fonts in Fedora
can write deny apache rules themselves (though providing a sample of tuch
a rule would be good)