FS#46744 - [ghostscript] Wrong glyphs with Libertine fonts

Attached to Project: Arch Linux
Opened by Rodrigo Rivas Costa (rodrigorc) - Thursday, 15 October 2015, 22:29 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 09 January 2016, 19:58 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Jan Alexander Steffens (heftig)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

When showing a PDF file containing text with Libertine TrueType fonts, the image shows weird glyphs instead of some letters. Since GS filter is used by my printer driver, the hard copy of the PDF is also garbled.

Additional info:
* 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. It looks like only the TrueType variants are affected. The OpenType and the Graphite ones (from ttf-linux-libertine-g) are also ok.

Steps to reproduce:

* Set the font to "Linux Libertine", size 20.
* Write "abcdefghijklmnopqrstuvwxyz" in a LibreOffice Writer document.
* Export to "test.pdf" with default parameters.
* Open the PDF with command "gs test.pdf".
* The PDF is correct, because "evince test.pdf" shows the text fine.

Attached files:
* test.pdf: A sample PDF with serveral variants of the Libertine font.
* test.png: That same PDF, rendered by GS.
   test.pdf (43 KiB)
   test.png (67.7 KiB)
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Saturday, 09 January 2016, 19:58 GMT
Reason for closing:  Fixed
Comment by Andreas Radke (AndyRTR) - Friday, 16 October 2015, 07:56 GMT
Please report this to the ghostscript tracker.
Comment by Rodrigo Rivas Costa (rodrigorc) - Friday, 16 October 2015, 12:38 GMT
Done: http://bugs.ghostscript.com/show_bug.cgi?id=696281
Comment by Rodrigo Rivas Costa (rodrigorc) - Monday, 19 October 2015, 21:22 GMT
Well, upstream people have closed my bug as WORKSFORME (that is, for them). Maybe it is a library issue (upstream GS embeds a lot of third party libraries), or maybe it is just my installation?

Can anyone reproduce this bug with the attached file, or is just me?
Comment by Rodrigo Rivas Costa (rodrigorc) - Monday, 02 November 2015, 20:13 GMT
For what is worth, the new 9.18-4 does not solve the issue...
Comment by Andreas Radke (AndyRTR) - Monday, 04 January 2016, 18:23 GMT
Please do some more research and maybe try out, if using internal libs can solve your issue. Can you check, when the issue was introduced?

You may want to check how other distros build GS:

http://pkgs.fedoraproject.org/cgit/ghostscript.git/tree/ghostscript.spec?id=c5fb0925b166dd614113fe343ca5b5fdfadf0e54 (pretty outdated)
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/ghostscript-gpl/ghostscript-gpl-9.18.ebuild
https://packages.debian.org/stretch/ghostscript (pretty outdated)
Comment by Matt Kline (mrkline) - Tuesday, 05 January 2016, 02:51 GMT
I'm encountering the same issue. I generated a PDF using XeLaTeX, and anything involving postscript (ghostscript, a2ps, printing via CUPS, etc.) generates similar artifacts.
Comment by Rodrigo Rivas Costa (rodrigorc) - Tuesday, 05 January 2016, 19:21 GMT
Ok, I managed to do a few experiments, with gs-9.18-4. I removed the line from PKGBUILD that deletes the internal libraries and it worked fine!
Then, I deleted all but freetype (`rm -rf jpeg libpng zlib jasper expat tiff lcms lcms2 cups/libs`) and it worked too!
Then, I deleted only freetype but kept all the other internal libraries (`rm -rf freetype`) and it failed.

So the problem is clearly in not using the internal freetype library. It is a patched version of freetype 2.5.5, while the one in my system is 2.6.2. Maybe the problem was related to the custom gs patching so I gathered the upstream code from [1] and copied it in place of the local GS library. It worked fine so the patches are not related to this issue.

I tried to replace the local copy of freetype-2.5.5 with a copy of the upstream freetype-2.6.2 but it didn't even compile. It looks like GS is not using the autobuild scripts from freetype, but it cherry-pick-compiles the source files from the freetype directory manually (using `base/freetype.mak`).

HTH.

[1]: http://download.savannah.gnu.org/releases/freetype/freetype-2.5.5.tar.bz2
Comment by Andreas Radke (AndyRTR) - Tuesday, 05 January 2016, 21:28 GMT
Can you please try to downgrade freetype to 2.6.0 or 2.6.1 and check when building gs against system ft starts to fail? It could be a bug in Freetype as well. I wonder why the gs guy in the upstream report couldn't reproduce it.
Comment by Andreas Radke (AndyRTR) - Tuesday, 05 January 2016, 21:39 GMT
Jan, could this bug caused by the hinting changes you've introduced lately?
Comment by Jan Alexander Steffens (heftig) - Tuesday, 05 January 2016, 22:39 GMT
A completely unpatched FreeType 2.5.5 has the same problems.
Comment by Rodrigo Rivas Costa (rodrigorc) - Tuesday, 05 January 2016, 23:25 GMT
I downgraded to freetype2-2.5.5-1 and recompiled gs without the local freetype library. It failed again.

So, local, unpatched, freetype-2.5.5 works fine but system freetype-2.5.5 fails...

I can only think that the error is eitherbecause of some Arch patches to the freetype code or it is because of the way gs compiles this library.

I'll try to find the Arch patches to freetype-2.5.5 and apply them to the local freetype library, and see if it fails...
Comment by Rodrigo Rivas Costa (rodrigorc) - Tuesday, 05 January 2016, 23:47 GMT
And... I patched the upstream freetype-2.5.5 with the Arch patches, put it in the local library directory, and it works fine.

Summing up, any try I did:

* local library, any version, any patches: it works.
* system library, any version: it fails.

I tried compiling gs from the upstream sources, instead of with `makepkg`, maybe to try and bisect it, but I was unable to build it...
Comment by Jan Alexander Steffens (heftig) - Wednesday, 06 January 2016, 03:21 GMT
I suspect there might be more that GS does, like configuring the build of FT a certain way (e.g via defines) or altering the behavior of other code if the internal FT is deactivated.
Comment by Andreas Radke (AndyRTR) - Wednesday, 06 January 2016, 08:48 GMT
I'm going to build gs with internal freetype to solve the bug.

Rodrigo, can you please report report back in the upstream that all system freetype libs fail here. Maybe they can explain the difference and why it works for them. It would be nice if we can revert later to a working system lib.
Comment by Andreas Radke (AndyRTR) - Wednesday, 06 January 2016, 09:28 GMT
9.18-5 in testing should work using internal freetype.
Comment by Rodrigo Rivas Costa (rodrigorc) - Wednesday, 06 January 2016, 12:21 GMT
I confirm that 9.18-5 works perfectly fine.

Yes, I will report back to upstream. And I'll keep on trying to build and bisect upstream code in my spare time... I don't like unsolved mysteries.
Comment by Rodrigo Rivas Costa (rodrigorc) - Wednesday, 06 January 2016, 23:42 GMT
Hey, I finally managed to bisect it! The offending commit is 3d3982f844fed6d6cb092055980900289fb6a402 [1]

What this commit did was to disable the autodetection of the system freetype library. Local freetype: fine; system freetype: never found, use default internal buggy font rasterizer.

I also wrote a patch [2], just one line.


[1]: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=3d3982f844fed6d6cb092055980900289fb6a402
[2]: http://bugs.ghostscript.com/attachment.cgi?id=12221
Comment by Andreas Radke (AndyRTR) - Saturday, 09 January 2016, 06:28 GMT
Please test 9.18-6 that includes the upstream fix

http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=8f5d28536e4518716fdfe974e580194c8f57871d

Thanks for your help and work with upstream!
Comment by Rodrigo Rivas Costa (rodrigorc) - Saturday, 09 January 2016, 17:30 GMT
Finally, version 9.18-6 works fine!

Loading...