ghostscript @9.05_0 missing characters in loaded fonts

[rosgen@…]

Since upgrading ghostscript to @9.05_0 certain characters in postscript and pdf files are not displayed. Reverting to @9.04_1 fixes the problem.

This is on a system running 10.6.8. Potentially relevant ports installed are:

freetype @2.4.9_1+universal
fontconfig @2.9.0_1+universal

The problem occurs on the attached pdf file (and on other files). The text in the left margin is missing several characters. I've attached two screenshots: the behaviour in 0.94_1.png is the correct behaviour displayed by ghostscript @9.04_1, while the behaviour shown in 0.95_0.png is what ghostscript @9.05_0 displays. Other pdf viewers agree with the output of @9.04_1.

The console output of @9.05_0 on this file is:

GPL Ghostscript 9.05 (2012-02-08)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 20.
Page 1
Loading NimbusRomNo9L-Regu font from /opt/local/share/ghostscript/9.05/Resource/Font/NimbusRomNo9L-Regu... 3438920 2049811 6310512 5008808 3 done.
>>showpage, press <return> to continue<<

Whereas in @9.04_1 the output is:

GPL Ghostscript 9.04 (2011-08-05)
Copyright (C) 2011 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 20.
Page 1
Loading NimbusRomNo9L-Regu font from /opt/local/share/ghostscript/9.04/Resource/Font/NimbusRomNo9L-Regu... 3559648 2160956 6127704 4819707 3 done.
>>showpage, press <return> to continue<<

The only differences are in the numbers displayed regarding the loaded font. It seems like the font is either corrupt or being loaded incorrectly.

[rosgen@…]

pdf file that is not correctly displayed

[rosgen@…]

incorrect behaviour (@9.05_0)

[rosgen@…]

correct behaviour (@9.04_1)

[takanori@…]

I guess this is because the latest freetype is broken.

I could reproduce your bug using the latest ghostscript (@9.05) and freetype (@2.4.9_1) easily. But when I downgrated freetype to @2.4.8_0, the problem was gone.

Reverting to @9.04_1 fixes the problem.

ghostscript @9.04_1 uses its own freetype library. (i.e. it doesn't depend on MacPorts' freetype library.) So, the problem doesn't occur even if MacPorts' freetype library is broken..

[ryandesign (Ryan Carsten Schmidt)]

See also #33830, a similar report about evince and gv.

[takanori@…]

Well, maybe we should apply a quick fix like the following to avoid this problem. Until the latest freetype library would be fixed.

$ LANG=C svn diff
Index: Portfile
===================================================================
--- Portfile	(revision 90131)
+++ Portfile	(working copy)
@@ -5,6 +5,7 @@
 
 name            ghostscript
 version         9.05
+revision        1
 categories      print
 license         GPL-3+
 maintainers     takanori openmaintainer
@@ -68,7 +69,7 @@
 depends_build   port:pkgconfig
 
 post-extract {
-    foreach d {freetype jbig2dec jpeg lcms2 libpng tiff zlib} {
+    foreach d {jbig2dec jpeg lcms2 libpng tiff zlib} {
         move "${worksrcpath}/${d}" "${worksrcpath}/${d}_local"
     }
 

This patch just makes ghostscript not to use MacPorts' freetype library.

Any thoughts?

[carmine.maffei@…]

I confirm the problem with freetype @2.4.9_1. I had missing characters when converting (ImageMagick) eps files created in octave-devel to tiff or any other graphical format. Solved with the activation of freetype @2.4.8_0.

[takanori@…]

Anyway I committed the patch in r91582 as a workaround.

[jmroot (Joshua Root)]

Is this still a problem with freetype 2.4.10?

[pixilla (Bradley Giesbrecht)]

Cc Me!

[takanori@…]

Replying to jmr@…:

Is this still a problem with freetype 2.4.10?

As far as I have tested, this problem does not occur on ghostscript @9.06_1/freetype @2.4.10_0.