Created attachment 11987 [details] Sample PDF file with the problem With gs 9.18 the attached PDF with embedded Libertine font is not rendered properly. The attached PNG show what it looks like in my system. It looks like only the TTF variant is affected. The ODF and the Graphice variants are ok. Version information: * Arch-Linux up to date. * ghostscript 9.18-1, 9.18-2, 9.18-3 are affected. However 9.16-1 works fine. * ttf-linux-libertine 5.3.0-3.
Created attachment 11988 [details] Wrong render of test.pdf
I don't see this problem here, what is the *exact* command line you are running ? Where did you get Ghostscript from ? Did you build it yourself ? The bug report says 'master' and yet you refer to three versions of Ghostscript that do not match our numbering. The current version of Ghostscript is 9.18, there are no sub numbers after that. This 'looks like' a problem with FreeType so I would suggest you get the current source from our repository, specifically *including* all the 3rd party libraries, and build that without using shared libraries. If the problem disappears then its likely that the version of FreeType on your system has a problem.
Created attachment 11990 [details] My output Seems to work just fine for me. You might want to check the Freetype version gs is linked with - we're using 2.5.5, IIRC.
Oh, and it looks like a problem with TTF hinting, so you might see the problem go away with the "-dGridFitTT=0" option.
> The bug report says 'master' and yet you refer to three versions of Ghostscript that do not match our numbering. The current version of Ghostscript is 9.18, there are no sub numbers after that. Yes, sorry. The third number is the ArchLinux packaging iteration. That would be just 9.18 for you. The latest one in the new-bug combobox, was 9.17 so I went for the next thing. Effectively "-dGridFitTT=0" fixes the issue (I wish it were on the man page). Compiling all the shared libraries my be a bit out of my league, but I will try downgrading freetype to 2.5.5 and see what happens. Anyway, the weird thing is that freetype-2.6.1+ghostscript-9.18 fails, while freetype-2.6.1+ghostscript-9.16 works fine. Maybe 9.16 was not using ttf hinting by default?
...and downgrading freetype to 2.5.5 (dynamic linking) changes nothing at all.
(In reply to Rodrigo Rivas Costa from comment #5) > > The bug report says 'master' and yet you refer to three versions of Ghostscript that do not match our numbering. The current version of Ghostscript is 9.18, there are no sub numbers after that. > > Yes, sorry. The third number is the ArchLinux packaging iteration. That > would be just 9.18 for you. The latest one in the new-bug combobox, was 9.17 > so I went for the next thing. > > Effectively "-dGridFitTT=0" fixes the issue (I wish it were on the man page). > > Compiling all the shared libraries my be a bit out of my league, but I will > try downgrading freetype to 2.5.5 and see what happens. > > Anyway, the weird thing is that freetype-2.6.1+ghostscript-9.18 fails, while > freetype-2.6.1+ghostscript-9.16 works fine. Maybe 9.16 was not using ttf > hinting by default? The use or otherwise of the hinting hasn't changed between 9.16 and 9.18. What has changed is that we now control the scaling differently for the hinting phase, but I'd expect that to *reduce* problems such as this. Of course, you *still* haven't given a command line.....
> Of course, you *still* haven't given a command line..... Well, I didn't add the command line because it was not very interesting. The PNG is a capture of: $ gs test.pdf BTW, I've just tried mupdf-1.7_a, and it works fine: $ mupdf test.pdf ;-)
(In reply to Rodrigo Rivas Costa from comment #8) > > Of course, you *still* haven't given a command line..... > > Well, I didn't add the command line because it was not very interesting. The > PNG is a capture of: > > $ gs test.pdf Well, actually, that's *extremely* important because it tells us the resolution and scaling - still makes no difference to my results, the file still looks correct. > BTW, I've just tried mupdf-1.7_a, and it works fine: > > $ mupdf test.pdf Totally irrelevant - mupdf drives Freetype in a very different fashion to Ghostcript, and mupdf always ignored TTF hinting (because it always uses anti-aliased rendering).
I've now tried Freetype 2.6.1 (the latest release), and I don't see the rendering issues reported. The best I can recommend is that you work with the gs package maintainer for your distro to try to narrow down the problem to something I can reproduce. If you can do that, please reopen this bug with the details, and I will be happy to look into it.
I've been doing some research about this issue. You can see the details in the Arch bug report [1], but here are the conclusions: - Using the local copy of freetype2, version 2.5.5, no matter if patched or unpatched, with GS patches, or with Arch patches, it works fine. - Using the system freetype2, either version 2.5.5 or 2.6.2, it does NOT work. I suspect that the cause of the difference is the way the local copy of freetype2 is compiled in gs: It does not use the freetype configure script, but instead a custom freetype.mak. I'll keep trying to narrow down the issue and inform here of anything else. [1]: https://bugs.archlinux.org/task/46744
Eureka! I managed to bisect this issue, and here is the offender commit: commit 3d3982f844fed6d6cb092055980900289fb6a402 Author: Chris Liddell <chris.liddell@artifex.com> Date: Fri Aug 28 12:00:03 2015 +0100 Add "safe" defaults for the FT and LCMS2 source dirs So we don't risk (too much) finding spurious headers for wrong versions when linking to shared libraries for Freetype and LittleCMS2, use the same safe default ("src") as the other shared libs. No cluster differences This patch does several things, but the problematic one narrows down to two lines in configure.ac, one changed and the other unchanged. This is the changed one: -FTSRCDIR= +FTSRCDIR=src And this is the unchanged one: if test -z $FTSRCDIR; then This test is used when the local freetype copy is not found, to look for the system one (pkg-config or whatever). But now `FTSRCDIR` is never empty so the system library is never looked for and gs falls back to the internal renderer (or whatever). The fix is easy enough: check FT_BRIDGE instead of FTSRCDIR
Created attachment 12221 [details] patch to fix the system freetype autodetection issue
That's great work tracking that down. I really thought I had tested linking with libfreetype, but maybe I didn't pay close enough attention to what happened. My only concern with your patch is the possibility of unwanted interaction with the other (commercial) scaler/renderer we support (and possibly future, alternatives). My preference would be this patch: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=ce1c2547 if that seems okay to you?
(In reply to Chris Liddell (chrisl) from comment #14) > My only concern with your patch is the possibility of unwanted interaction > with the other (commercial) scaler/renderer we support (and possibly future, > alternatives). > > My preference would be this patch: > > http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff; > h=ce1c2547 > > > if that seems okay to you? Well, I don't know how the other renderers are configured, but looking at configure.ac, as is, your code and mine should be equivalent. The relevant lines are something like this: FTSRCDIR=src FT_BRIDGE=0 if test x"$enable_freetype" != xno; then if ft-in-source-tree; then FTSRCDIR=dir-in-source-tree FT_BRIDGE=1 fi if -z FTSRCDIR; then # <--- here!!! # use pkg-config or whatever to find freetype fi fi As I see it, in this case, checking FT_BRIDGE=0 or FTSRCDIR=src are totally equivalent. I used FT_BRIDGE because it looked less fragile and it was already used elsewhere in the file. But, as I said before, I am fine either way.
(In reply to Rodrigo Rivas Costa from comment #15) > (In reply to Chris Liddell (chrisl) from comment #14) > > My only concern with your patch is the possibility of unwanted interaction > > with the other (commercial) scaler/renderer we support (and possibly future, > > alternatives). > > > > My preference would be this patch: > > > > http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff; > > h=ce1c2547 > > > > > > if that seems okay to you? > > Well, I don't know how the other renderers are configured, but looking at > configure.ac, as is, your code and mine should be equivalent. > <SNIP> As things stand, yes the two are equivalent. But *in theory* it is supposed to be possible to configure "that other font scaler/renderer" as the only one, in practice it currently doesn't quite work - but if they ever resolve the issues that prevent that working, checking FT_BRIDGE wouldn't be sufficient (as, in that case, FT_BRIDGE=0 would be a valid configuration).
I've committed my version of the patch: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8f5d285 Thanks again for doing all the legwork on this one - much appreciated!