Bug#1019717: Display of an SVG file broken due to gsfonts transition

Russ Allbery

unread,

Sep 13, 2022, 8:30:03 PM9/13/22

to

Package: graphicsmagick
Version: 1.4+really1.3.38+hg16739-1
Severity: normal
X-Debbugs-Cc: r...@debian.org

Attempting to display an SVG file breaks due to a missing font file:

% gm display _static/spawning.svg
gm display: Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb) [No such file or directory].

(The image in question was created via the Python seqdiag package, which
is packaged in Debian as python3-seqdiag, although I am using it directly
from PyPI via a virtualenv.)

This is presumably due to the transition from gsfonts to fonts-urw-base35
recently discussed on debian-devel:

https://lists.debian.org/debian-devel/2022/08/msg00263.html

I'm not sure precisely what has to change in GraphicsMagick to use the
new package, though.

-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages graphicsmagick depends on:
ii libc6 2.34-8
ii libgraphicsmagick-q16-3 1.4+really1.3.38+hg16739-1

graphicsmagick recommends no packages.

Versions of packages graphicsmagick suggests:
pn graphicsmagick-dbg <none>

-- no debconf information

Bob Friesenhahn

unread,

Sep 14, 2022, 11:00:03 AM9/14/22

to

On Tue, 13 Sep 2022, Russ Allbery wrote:
> X-Debbugs-Cc: r...@debian.org
>
> Attempting to display an SVG file breaks due to a missing font file:
>
> % gm display _static/spawning.svg
> gm display: Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb) [No such file or directory].
>
> (The image in question was created via the Python seqdiag package, which
> is packaged in Debian as python3-seqdiag, although I am using it directly
> from PyPI via a virtualenv.)
>
> This is presumably due to the transition from gsfonts to fonts-urw-base35
> recently discussed on debian-devel:
>
> https://lists.debian.org/debian-devel/2022/08/msg00263.html
>
> I'm not sure precisely what has to change in GraphicsMagick to use the
> new package, though.

The path to the fonts may be configured via the --with-gs-font-dir
configure option.

The configure script does check /usr/share/fonts/type1/gsfonts but
perhaps the path has been overridden, or the fonts-urw-base35 package
was not installed when the configure script was executed, or there is
a bug.

Bob
--
Bob Friesenhahn
bfri...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Albrecht Dreß

unread,

May 22, 2023, 1:00:04 PM5/22/23

to

The issue is still present in libgraphicsmagick-q16-3 v. 1.4+really1.3.40-4 and makes using the library with the standard config files somehow unusable as soon as any SVG with a "text" container is involved. It would be great if a fix would be available before the final Bookworm release.

Thanks, Albrecht.

László Böszörményi

unread,

May 23, 2023, 4:52:09 PM5/23/23

to

On Tue, May 23, 2023 at 9:45 PM Albrecht Dreß <albrech...@posteo.de> wrote:
> I added the attached patch file to the Debian patches and re-build the package, which now processes SVG files as expected, so this seems to be a fix.
>
> Also attached is the *very* ugly Python script I used to extract the URW font paths from the Ghostscript config and to modify type-ghostscript.mgk.in - maybe it is helpful.
These fixes [1] you submitted look OK, let's loop-in the upstream developer.

Thanks,
Laszlo/GCS
[1] https://bugs.debian.org/1019717#20

László Böszörményi

unread,

May 23, 2023, 4:52:09 PM5/23/23

to

Hi Albrecht, Bob,

[Written a day ago, forgot to send.]

On Mon, May 22, 2023 at 6:51 PM Albrecht Dreß <albrech...@posteo.de> wrote:
> The issue is still present in libgraphicsmagick-q16-3 v. 1.4+really1.3.40-4 and makes using the library with the standard config files somehow unusable as soon as any SVG with a "text" container is involved. It would be great if a fix would be available before the final Bookworm release.

It's an upstream bug; there was a gsfonts -> fonts-urw-base35
transition which resulted in different font files. But GM has the font
names hardcoded. The default seems to be n019003l.pfb [1] and font
variants are also hardcoded [2]. But the package fonts-urw-base35 has
none of these pfb files.
Not sure what to do at this point. Alter the font names in GM or ship
the hardcoded fonts?

Regards,
Laszlo/GCS
[1] http://hg.graphicsmagick.org/hg/GraphicsMagick/file/c41d8933edef/magick/nt_base.c#l1713
[2] http://hg.graphicsmagick.org/hg/GraphicsMagick/file/c41d8933edef/wmf/src/font.h#l82
[3] https://packages.debian.org/bookworm/all/fonts-urw-base35/filelist

Bob Friesenhahn

unread,

May 23, 2023, 9:31:57 PM5/23/23

to

On Tue, 23 May 2023, László Böszörményi wrote:

> On Tue, May 23, 2023 at 9:45 PM Albrecht Dreß <albrech...@posteo.de> wrote:
>> I added the attached patch file to the Debian patches and re-build the package, which now processes SVG files as expected, so this seems to be a fix

Sorry, I had totally forgotten about this issue.

I did not see the final generated product attached to the issue. On
the system I am looking at, there is a
/etc/ghostscript/fontmap.d/10gsfonts.conf file which must be similar
in nature to the /etc/ghostscript/fontmap.d/10fonts-urw-base35.conf
which Debian is using.

Rather than modify type-ghostscript.mgk.in, it is likely better to
create a new file "type-urw-base35.mgk" and add it to the list of
files specifically for Debian. Since the font installation paths are
fixed for Debian then just store hard-coded paths in the mgk file
since there is no reason to configure or search for them.

I recall that Ghostscript (i.e. "Artifex Software, Inc.") has disowned
the original set of font files which was distributed with it so
perhaps these URW fonts are not accurately described as Ghostscript
fonts.

GraphicsMagick should of course support Fontconfig. I am not sure
what the impact of doing so (e.g. run-time performance) is. I have
not studied it at all.