Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Merge new characters from Chromium OS core fonts|
|Product:||[Fedora] Fedora||Reporter:||Cody Boisclair <cody>|
|Component:||liberation-fonts||Assignee:||Tom "spot" Callaway <tcallawa>|
|Status:||CLOSED CANTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||fonts-bugs, i18n-bugs, jpokorny, petersen, pnemade, psatpute, tcallawa|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-03-16 16:35:56 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Cody Boisclair 2010-09-26 16:52:21 EDT
Description of problem: Chromium OS includes new fonts called Arimo, Cousine, and Tinos. These fonts are, in fact, identical in design to the the Liberation fonts; more accurately, they're new font files direct from Steve Matteson using the same character designs as Liberation. However, these fonts include a vastly larger character set, including such glyphs as Polytonic Greek, Altaic Cyrillic and IPA that might be useful for certain locales. The latest revision of the Chromium fonts, as of now, is downloadable here: http://commondatastorage.googleapis.com/chromeos-localmirror/distfiles/croscorefonts-0.0.4.tar.gz And the relevant issues from Chromium OS are here: http://code.google.com/p/chromium-os/issues/detail?id=5287 http://code.google.com/p/chromium-os/issues/detail?id=5941 Would it be possible to work with Google and/or Steve Matteson to get these new characters merged into the Liberation fonts as well?
Comment 1 Jens Petersen 2010-09-27 02:08:00 EDT
What is their license?
Comment 2 Nicolas Mailhot 2010-09-27 03:50:07 EDT
Probably not the one we want. But then that's Red Hat legal's fault for not using a standard font license such as the OFL that would have been Google-compatible (btw I've not had the time to look at liberation for a long time, I'm pretty sure the new narrow fonts fail repo-font-audit and the WWS naming test. Please fix the fonts)
Comment 3 Cody Boisclair 2010-09-27 08:06:32 EDT
The new fonts are indeed released under the OFL, according to their metadata.
Comment 4 Pravin Satpute 2010-09-27 10:34:09 EDT
i am doubtful, can we pick glyphs from OFL licensed font? we are using "License: Liberation"
Comment 5 Nicolas Mailhot 2010-09-27 13:36:59 EDT
(In reply to comment #4) > i am doubtful, can we pick glyphs from OFL licensed font? > > we are using "License: Liberation" Nope. Liberation is a weird GPL-based licence and OFL, while permissive, includes some "additional restrictions" that won't map The only good way out of this mess is for Red Hat to negociate with Ascender (and other major contributors such as Oracle) the OFL-ing of Liberation. Quite frankly, I don't see much a future for Liberation unless its licensing is fixed. The days of custom font licenses are past. A gpl-ish standard font license would have been nice but since the FSF never bothered with it gpl-ish fonts are dying from lack of license standardisation. Anyway, this is a problem for spot
Comment 6 Nicolas Mailhot 2010-09-27 13:37:54 EDT
Let's make that clear, reassigning
Comment 7 Jens Petersen 2011-02-03 00:49:24 EST
Hmm maybe croscorefonts could even replace liberation fonts?
Comment 8 Jens Petersen 2011-02-03 01:08:09 EST
Anyway given that the fonts are under OFL and a different name, they could be packaged for Fedora anyway and then people can choose the fonts they prefer?
Comment 9 Nicolas Mailhot 2011-02-03 03:54:53 EST
Sure. Packaging new fonts is always good. It's sad that the licensing mistakes made at liberation release time will probably make it an evolutionnary dead-end (I don't see any third-party nowadays prefering to contribute to a project with Liberation's weird licensing when an OFL alternative is available), and will also prevent merging with the Google fonts (who wants to talk with SUN/Oracle to know if their contributions can be added to the Google fonts under the OFL ?)
Comment 10 Tom "spot" Callaway 2012-03-16 16:35:56 EDT
I don't see a good way of doing this. I think the only option would be for those to be packaged separately. I agree with Nicolas's sentiment in Comment 9.