The cover of the TikZ/PFG manual[1] is displayed incorrectly. [1] http://ftp.gwdg.de/pub/ctan/graphics/pgf/base/doc/generic/pgf/pgfmanual.pdf Here's a comparison: pipping@bogus /home/pipping % gs -sDEVICE=png16m -r400 -dNOPAUSE -dBATCH -dFirstPage=1 -dLastPage=1 -sOutputFile=gs.png /opt/texlive/2010/texmf-dist/doc/generic/pgf/pgfmanual.pdf GPL Ghostscript 9.02 (2011-03-30) 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 1. Page 1 pipping@bogus /home/pipping % pdfdraw -r400 -o pdfdraw.png /opt/texlive/2010/texmf-dist/doc/generic/pgf/pgfmanual.pdf 1 + pdf/pdf_xref.c:335: pdf_read_new_xref(): object id (37226 0 R) out of range (0..37225) | pdf/pdf_xref.c:411: pdf_read_xref(): cannot read xref (ofs=5260639) | pdf/pdf_xref.c:431: pdf_read_xref_sections(): cannot read xref section | pdf/pdf_xref.c:491: pdf_load_xref(): cannot read xref \ pdf/pdf_xref.c:532: pdf_open_xref_with_stream(): trying to repair + pdf/pdf_interpret.c:2149: pdf_run_stream(): syntax error in array | pdf/pdf_interpret.c:2234: pdf_run_buffer(): cannot parse content stream | pdf/pdf_interpret.c:1087: pdf_run_xobject(): cannot interpret XObject stream \ pdf/pdf_interpret.c:147: pdf_begin_group(): cannot run softmask + pdf/pdf_interpret.c:2149: pdf_run_stream(): syntax error in array | pdf/pdf_interpret.c:2234: pdf_run_buffer(): cannot parse content stream | pdf/pdf_interpret.c:1087: pdf_run_xobject(): cannot interpret XObject stream \ pdf/pdf_interpret.c:147: pdf_begin_group(): cannot run softmask + pdf/pdf_interpret.c:2149: pdf_run_stream(): syntax error in array | pdf/pdf_interpret.c:2234: pdf_run_buffer(): cannot parse content stream | pdf/pdf_interpret.c:1087: pdf_run_xobject(): cannot interpret XObject stream \ pdf/pdf_interpret.c:147: pdf_begin_group(): cannot run softmask pipping@bogus /home/pipping % (I'm attaching gs.png and pdfdraw.png) This is with mupdf git-cbf50e333dc1e80cd968c5ee931b4d6886b116a4.
Created attachment 7624 [details] ghostscript reference
Created attachment 7625 [details] mupdf
Thanks for the report. This seems to be caused by the same underlying issue as bug 692282 (state being unintentionally reused when xobjects are interpreted recursively). Our fix: http://code.google.com/p/sumatrapdf/source/detail?r=4002
Something like --- a/pdf/pdf_interpret.c +++ b/pdf/pdf_interpret.c @@ -2138,8 +2138,10 @@ pdf_run_stream(pdf_csi *csi, fz_obj *rdb, fz_stream *file, char *buf, int buflen pdf_show_space(csi, -fz_atof(buf) * gstate->size * 0.001f); } else if (tok == PDF_TOK_STRING) - { + { /* cf. http://bugs.ghostscript.com/show_bug.cgi?id=692312 */ + csi->in_array = 0; pdf_show_string(csi, (unsigned char *)buf, len); + csi->in_array = 1; } else if (tok == PDF_TOK_KEYWORD) { indeed fixes the issue for me, thanks. I still get + pdf/pdf_xref.c:335: pdf_read_new_xref(): object id (37226 0 R) out of range (0..37225) | pdf/pdf_xref.c:411: pdf_read_xref(): cannot read xref (ofs=5260639) | pdf/pdf_xref.c:431: pdf_read_xref_sections(): cannot read xref section | pdf/pdf_xref.c:491: pdf_load_xref(): cannot read xref \ pdf/pdf_xref.c:532: pdf_open_xref_with_stream(): trying to repair on startup. I this related?
Created attachment 7629 [details] mupdf output with the above-mentioned changes made (In reply to comment #3) > Thanks for the report. This seems to be caused by the same underlying issue as > bug 692282 (state being unintentionally reused when xobjects are interpreted > recursively). > > Our fix: http://code.google.com/p/sumatrapdf/source/detail?r=4002 Does this display the mirrored lower half as well? Because it does not for me.
Have you also applied http://code.google.com/p/sumatrapdf/source/detail?r=3911 from bug 692282? Then I do indeed get the expected result. BTW: The remaining warning is unrelated and can be ignored for this issue.
(In reply to comment #6) > Have you also applied http://code.google.com/p/sumatrapdf/source/detail?r=3911 > from bug 692282? Then I do indeed get the expected result. > > BTW: The remaining warning is unrelated and can be ignored for this issue. That patch does not affect the appearance of the before-mentioned pdf for me.
(In reply to comment #7) > That patch does not affect the appearance of the before-mentioned pdf for me. Our MuPDF contains dozens of patches over the official trunk. So this is most likely due to any other fix that hasn't yet been ported upstream.
How do these patches usually make their way back to mupdf? Is it all a matter of time? If that is so, I guess there is nothing left to be done here (so that the bug could be closed).
While applying the current http://software.zeniko.ch/sumatrapdf/SumatraMuPDF.patch to the git HEAD of mupdf works (says "SumatraPDF revision 4000" at the top), I get a segfault on startup after recompilation so I can't test that either.
I can confirm however that doing a svn checkout http://sumatrapdf.googlecode.com/svn/trunk/mupdf/ and running `make` in there produces a version of mupdf that handles the pgfmanual this bug is about perfectly well.
(In reply to comment #9) > How do these patches usually make their way back to mupdf? Is it all a matter > of time? Yes, we usually file bugs for issues we encounter and fix ourselves, and occasionally somebody goes through our patch set and merges the remaining bits from there. In case you start using our own MuPDF repository, please make sure to file issues at http://code.google.com/p/sumatrapdf/issues instead of here and leave the bug triage to us.
Fixing bug 692272 causes a crash with this test file in fz_draw_end_mask.
Fixed in 4214d2a553522a9ebb5c263368131aea813ebe03. Make sure the CSI works from a clean slate in pdf_run_stream, since it may be called to draw a softmask form pdf_flush_text in the middle of parsing a TJ text array. Also guard against xobject failures by catching instead of rethrowing xobject parse errors so that the begin and end group draw calls are balanced.
Tor: Is there any reason in_array isn't just local to pdf_run_stream?
Also due to this: If an xobject's content stream contains errors in an array (cf. "syntax error in array"), then the page's content stream will wrongly consider to be inside an array as well and fail unnecessarily.
I've filed bug 692414 for the issue in comment #16, including a demonstration of the issue.