Control: severity -1 wishlist Control: tag -1 + patch >>>>> Ivan Shmakov <oneing...@gmail.com> writes: >>>>> Keith Packard <kei...@keithp.com> writes:
[…]
>> fontconfig isn't useful without at least one font installed on the
>> system.
Which may've been indicating that the libpoppler19 dependency on
libfontconfig1 is unwarranted. Obviously, there's no easy way
to avoid such a dependency.
>> Many fontconfig using applications will crash if there aren't any
>> fonts on the system at all.
> ACK, thanks for the clarification.
> However, it may be considered a bug in those applications, and
> downgrading the dependency to Recommends: may still be justified as
> long as there's a considerable amount of software (depending directly
> or indirectly on fontconfig) that remains useful even in the absence
> of any fonts.
Also to note is that recommended packages /are/ installed by
default, so should such a dependency be left unsatisfied, it
would most probably be because of an explicit action of the
administrator.
>> In the case of gnunet-server, it's using libextractor3 which
>> provides PDF support, and rendering arbitrary PDF files will require
>> at least one font accessed through fontconfig.
> The point is that, AIUI, libextractor3 is used to extract keywords
> from PDF files, and /not/ to /render/ them. Therefore, I'd expect
> for GNUnet node to operate even if no fonts are installed on the
> system. (I'd expect the same from, say, pdftotext of poppler-utils,
> BTW.)
> By this weekend, I hope to check if it's possible (and sensible) to
> run a GNUnet node (or other software depending on fontconfig) without
> any of the fonts installed.
It took longer than I expected, but I can confirm that neither
extract(1), nor pdftotext(1) (both depending on libpoppler19 and
thus fontconfig-config) require fonts to operate. (I presume
that GNUnet “non-GUI” processes don't use fonts, either.)
Consider, e. g.:
$ pdftotext -- \
www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf \
/dev/stdout \
| head
INTERNATIONAL TELECOMMUNICATION UNION
ITU-T
TELECOMMUNICATION
STANDARDIZATION SECTOR
OF ITU
X.680
(07/2002)
$ extract -- \
www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf \
| head
Keywords for file www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf:
mimetype - application/pdf
mimetype - audio/mpeg
format version - MPEG-2
resource type - MPEG-2 Layer I audio, 256 kbps (CBR), 22050 Hz, joint stereo,
copyright, original
duration - 0m38
mimetype - application/pdf
produced by software - Acrobat Distiller 5.0.5 (Windows)
page count - 146
format - PDF 1.3
$
To stress it out: due to the libpoppler19 ← libfontconfig1
dependency, the latter may become a requirement on systems
deployed to deal with PDF files (as in: search engine indexing.)
Given that such a system may itself reside on a “virtual”,
resource-limited (as in: a couple of GiB's of filesystem space)
server, it may be entirely reasonable to try to save every MiB
of the available FS space.
That being said, ttf-bitstream-vera takes less than a MiB (as
per Installed-Size:), so this issue could certainly be deferred
until Wheezy is released. (And then perhaps the considerations
above would no longer be of much importance.)
Anyway, the patch is MIME'd.
(FWIW, I've used an equivs package, as per the definition
MIME'd, for the tests above.)
--
FSF associate member #7257 np. snusdam.mod
--- debian/control.~1~ 2012-04-16 21:23:27.000000000 +0000
+++ debian/control 2012-11-10 20:07:17.000000000 +0000
@@ -32,7 +32,8 @@
Package: fontconfig-config
Section: fonts
Architecture: all
-Depends: ${misc:Depends}, ucf (>= 0.29), ttf-dejavu-core | ttf-bitstream-vera | ttf-freefont | gsfonts-x11
+Depends: ${misc:Depends}, ucf (>= 0.29)
+Recommends: ttf-dejavu-core | ttf-bitstream-vera | ttf-freefont | gsfonts-x11
Replaces: fontconfig (<< 2.3.2-2)
Conflicts: fontconfig (<< 2.3.2-2)
Multi-Arch: foreign
binSkWxbJEkhU.bin
Description: application/debian-equivs
