<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - pdfinfo/pdffonts cannot process >2GB files" href="https://bugs.freedesktop.org/show_bug.cgi?id=44085#c24">Comment # 24</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - pdfinfo/pdffonts cannot process >2GB files" href="https://bugs.freedesktop.org/show_bug.cgi?id=44085">bug 44085</a> from <a class="email" href="mailto:ajohnson@redneon.com" title="Adrian Johnson <ajohnson@redneon.com>"> Adrian Johnson</a> <pre>Created <a href="attachment.cgi?id=72449" name="attach_72449" title="fix uninitialised memory">attachment 72449</a> <a href="attachment.cgi?id=72449&action=edit" title="fix uninitialised memory">[details]</a> <a href='page.cgi?id=splinter.html&bug=44085&attachment=72449'>[review]</a> fix uninitialised memory I've found the rendering differences for bug-poppler26533.pdf to be caused by uninitialised memory in splash. This patch fixes the problem. I don't have any idea why tauya.f8.pdf is showing differences however I suspect it is an existing problem that is just failing in a different way with the large file patches. The tauya.f8 pdf is very broken. It has a broken font (corrupted Flate stream). Poppler does not seem to have error detection in the Flate decompression and renders mostly garbage. Ghostscript detects the broken stream and substitutes a different font resulting in what appears to be correct output. If I remove the font descriptor from the pdf forcing poppler to substitute the font, the output is the same as ghostscript with no regression when using the large font patches. Acroread complains the font is broken and displays garbage. So at this point I think the patches are ready for review.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>