Bug#1019717: Display of an SVG file broken due to gsfonts transition
On Tue, 23 May 2023, László Böszörményi wrote: On Tue, May 23, 2023 at 9:45 PM Albrecht Dreß 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. Bob -- Bob Friesenhahn bfrie...@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
Bug#1019717: Display of an SVG file broken due to gsfonts transition
On Tue, May 23, 2023 at 9:45 PM Albrecht Dreß 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
Bug#1019717: Display of an SVG file broken due to gsfonts transition
Hi Albrecht, Bob, [Written a day ago, forgot to send.] On Mon, May 22, 2023 at 6:51 PM Albrecht Dreß 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
Bug#1019717: Display of an SVG file broken due to gsfonts transition
Digging a little deeper into this, I /think/ this is a bug in the GraphicsMagick source file http://hg.code.sf.net/p/graphicsmagick/code/file/tip/config/type-ghostscript.mgk.in which hard-codes the font file names and just makes the path configurable. 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. Thanks, Albrecht. font-urw35-issue-1019717.patch.gz Description: application/gzip fix-gm-fonts.py.gz Description: application/gzip pgpwh8glYK_BO.pgp Description: PGP signature
Bug#1019717: Display of an SVG file broken due to gsfonts transition
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.
Bug#1019717: Display of an SVG file broken due to gsfonts transition
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 bfrie...@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
Bug#1019717: Display of an SVG file broken due to gsfonts transition
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 libc62.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 -- no debconf information
