1. Fonts are obviously not required to compile, so any such dependency should be in RDEPEND, not DEPEND.
2. Hard coding a specific font is ugly. What's wrong with /usr/share/fonts/TTF ?
3. media-fonts/ttf-bitstream-vera is non-free, so not an ideal choice if a hard-coded font is needed.
I believe media-fonts/ttf-bitstream-vera provides the so-called "standard 14 fonts" that can be included in any PDF file without embedding. It's also noteworthy to mention that reportlab ships some fonts itself, including bitstream-vera fonts. Now, I think that the "standard 14 fonts" are actually Type-1 fonts and not TTF fonts.
Now, as far as the media-fonts/ttf-bitstream-vera "free-ness", albeit not an OSI approved license, it is really pretty free. They allow derivative works, redistribution, etc. They just cannot be sold as a stand-alone font.
I would like to see what the python devs have to say about the dep as well as whether or not the reportlab-shipped fonts should be removed. I think it should be safe to remove the dep. However the question becomes should we replace it with media-fonts/font-bitstream-type1 or whatever package provides the nicest "standard 14 fonts"?
(In reply to comment #1)
> They just cannot be sold as a stand-alone font.
In other words, you're not free to sell them, one of the essential freedoms of free software. (some try to argue you can include a simple hello-world program to workaround this, but I feel this is trying to get off on a technicality, and any court would honour the intention of the license)
> I would like to see what the python devs have to say about the dep as well as
> whether or not the reportlab-shipped fonts should be removed. I think it should
> be safe to remove the dep. However the question becomes should we replace it
> with media-fonts/font-bitstream-type1 or whatever package provides the nicest
> "standard 14 fonts"?
This is a case for virtual/ttf-fonts, IMO.
*** Bug 335768 has been marked as a duplicate of this bug. ***
+*reportlab-3.1.8-r1 (13 Dec 2014)
+ 13 Dec 2014; Pacho Ramos <email@example.com> +reportlab-3.1.8-r1.ebuild,
+ -reportlab-2.5-r1.ebuild, -reportlab-2.5.ebuild, -reportlab-2.7.ebuild,
+ Use dejavu instead of bitstream-vera fonts (#405183), drop old
dejavu has the same problems.
(In reply to Luke-Jr from comment #0)
> 1. Fonts are obviously not required to compile, so any such dependency
> should be in RDEPEND, not DEPEND.
> 2. Hard coding a specific font is ugly. What's wrong with
> /usr/share/fonts/TTF ?
> 3. media-fonts/ttf-bitstream-vera is non-free, so not an ideal choice if a
> hard-coded font is needed.
I see two different approaches in distributions:
1. We and Fedora are changing upstream default locations to match dejavu. Fedora is applying this patch (equivalent to our sed command):
I would see two options:
- Isn't there any common font dir shared between all virtual/ttf-fonts
- If not, we would need to list the paths for all the providers (and keep on eye on any additions to that virtual). But, does this really work with all that providers?
2. OpenSUSE and Arch don't change anything in the paths, and they simply don't depend on any font at all => What would occur if we don't satisfy that dep? :/
Removing the truetype sed and the dep on dejavu works just fine for me. It falls back on another font then.
Actually, a use-dep on pillow[truetype] should be added.
+ 01 Jul 2015; Ben de Groot <firstname.lastname@example.org> +reportlab-3.2.0.ebuild:
+ Version bump. No longer depend on media-fonts/dejavu (bug #405183). Acked by