Created attachment 68034 [details] testcase.pdf The attached PDF crashes in FT_Outline_Decompose if rendered with 144 dpi: pdftops -eps -level3 -r 144 /media/Data/Testdaten/kunden/lns/180219/testcase.pdf testcase.eps
Created attachment 68035 [details] [review] sanity check With this patch pdftops doesn't crash anymore. BTW, it solves also the problem with 168.pdf.SIGSEGV.598.462 of bug 54090
Created attachment 68038 [details] [review] workaround The sanity check just heals the crash, but the PDF is not rendered correctly: In the output the letter "D" is missing. I digged a little bit deeper into it, and it was really funny: pdftops doesn't render the "D" with 144 dpi, but it does it with 72 dpi, 150 dpi or 300 dpi. When I render it with pdftoppm with 144 dpi, it works, too. So I looked into the differences between pdftoppm and pdftops and encountered, that the only difference is that in pdftoppm the font is loaded with FT_LOAD_NO_BITMAP because "aa" is true, but in pdftops the font is loaded without this option. So if we set antialias printing to true, it works also with pdftops. This seems to be only a workaround, but I'm not a freetype expert. Perhaps anybody else with a deeper knowledge can find a better way to solve the problem. In the meantime this patch could help...
No your patch does not help, it changes the output of all our postcript rendering, that's not helping ;-)
I'm going to regtest and most probably commit Thomas Patch. If freetype is returning valid outlines for 150dpi but not for 144dpi that's most probably a freetype bug and i'm sure they'd appreciate someone telling them. If noone does I'll tell them when i have some free time.
Thomas patch commited, i'm leaving the bug open as a reminder someone has to talk to the freetype people about this
We failed to talk to the freetype people. Close bug
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.