Bug 692312 - PDF displayed incorrectly: pgfmanual
Summary: PDF displayed incorrectly: pgfmanual
Status: RESOLVED FIXED
Alias: None
Product: MuPDF
Classification: Unclassified
Component: mupdf (show other bugs)
Version: unspecified
Hardware: PC Linux
: P4 normal
Assignee: Tor Andersson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-28 22:13 UTC by Elias Pipping
Modified: 2011-08-09 22:57 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments
ghostscript reference (331.89 KB, application/x-xz)
2011-06-28 22:13 UTC, Elias Pipping
Details
mupdf (83.12 KB, application/x-xz)
2011-06-28 22:13 UTC, Elias Pipping
Details
mupdf output with the above-mentioned changes made (1.33 MB, image/png)
2011-06-29 08:41 UTC, Elias Pipping
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Elias Pipping 2011-06-28 22:13:16 UTC
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.
Comment 1 Elias Pipping 2011-06-28 22:13:44 UTC
Created attachment 7624 [details]
ghostscript reference
Comment 2 Elias Pipping 2011-06-28 22:13:58 UTC
Created attachment 7625 [details]
mupdf
Comment 3 zeniko 2011-06-29 05:28:41 UTC
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
Comment 4 Elias Pipping 2011-06-29 08:35:08 UTC
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?
Comment 5 Elias Pipping 2011-06-29 08:41:06 UTC
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.
Comment 6 zeniko 2011-06-29 14:04:56 UTC
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.
Comment 7 Elias Pipping 2011-06-29 14:09:57 UTC
(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.
Comment 8 zeniko 2011-06-29 14:24:20 UTC
(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.
Comment 9 Elias Pipping 2011-06-29 14:29:00 UTC
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).
Comment 10 Elias Pipping 2011-06-29 14:33:28 UTC
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.
Comment 11 Elias Pipping 2011-06-29 14:37:56 UTC
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.
Comment 12 zeniko 2011-06-29 14:43:15 UTC
(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.
Comment 13 Tor Andersson 2011-08-09 14:59:19 UTC
Fixing bug 692272 causes a crash with this test file in fz_draw_end_mask.
Comment 14 Tor Andersson 2011-08-09 16:17:36 UTC
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.
Comment 15 zeniko 2011-08-09 20:24:50 UTC
Tor: Is there any reason in_array isn't just local to pdf_run_stream?
Comment 16 zeniko 2011-08-09 20:45:58 UTC
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.
Comment 17 zeniko 2011-08-09 22:57:45 UTC
I've filed bug 692414 for the issue in comment #16, including a demonstration of the issue.