bugGNU gv - Bugs: bug #13200, pdf problems with gv

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #13200: pdf problems with gv

Submitter:  None
Submitted:  Thu 26 May 2005 03:57:04 PM UTC
Votes: 200
 
Category:  PDF rendering Severity:  4 - Important
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  jemarch
Open/Closed:  Closed Release:  3.6.3

Jump to the original submission

Mon 25 Jun 2007 09:09:56 PM UTC, comment #6: 

Patch applied and tested.

Jose E. Marchesi <jemarch>
Wed 11 Oct 2006 06:25:29 PM UTC, comment #5: 

Why is this working patch not included in the just released version 3.6.2?

Anonymous
Sat 03 Jun 2006 01:18:03 PM UTC, comment #4: 

The submitted patch works for me. If this is the way to solve it, it should be included in next release.

Johan Nilsson <wtfquestionmark>
Thu 13 Apr 2006 07:47:46 PM UTC, comment #3: 

This patch fixes the problem by changing the program to do the following: If the input file is updated (recognised by signal or by watch, does not matter), then the forked ghostscript is terminated and a new one is opened.


As usual, my contact info is given in the patch file as comment.

Anonymous
Fri 28 Oct 2005 09:45:52 AM UTC, comment #2: 

Exactly the same problem with

kfkf:~ hbf$ gv --version
gv 3.6.1
kfkf:~ hbf$ uname -a
Darwin <left out> 8.2.0 Darwin Kernel Version 8.2.0: Fri Jun 24 17:46:54 PDT 2005; root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh powerpc

Kaspar Fischer <kfhbf>
Mon 22 Aug 2005 08:52:16 PM UTC, comment #1: 

I have the same problem and found a simple
workaround (which might also help to track the
problem down). In the example above, the problem
only occurs if the file was changed. Therefore, if
I do:

pdflatex blah.tex; sleep 1; touch blah.pdf

things get much better. When gv loads the file the
second time, it displays it (and I can just once
lower the window with the error messages such that
it is out of the way --- at least with my fvwm2
window-manager).

However, this only helps if I add something to
blah.tex. If I remove something, I have to touch
blah.pdf twice, such that the workaround is:

pdflatex blah.tex; sleep 1; touch blah.pdf; sleep 1; touch blah.pdf

Well, this is not beautiful, but better than
dismissing the error message all the time.

> gv --version

gv 3.6.1

> uname -a

Darwin indigo.local 7.9.0 Darwin Kernel Version
7.9.0: Wed Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power
Macintosh powerpc


Anonymous
Thu 26 May 2005 03:57:04 PM UTC, original submission:  

Consider this latex code:

   \documentclass[12pt]{article}
   \begin{document}
   hello there.
   \end{document}

Compile the code and run gv on the resulting pdf file (assume gv "watches" the pdf file so that the pdf file gets reloaded when it changes):

   $ pdflatex blah.tex
   $ gv blah.pdf &

Whenever you add or subtract text to the pdf document, gv displays an error message.  For example, if I added the line "goodbye":

   \documentclass[12pt]{article}
   \begin{document}
   hello there.
   goodbye.
   \end{document}

and recompile:

   $ pdflatex blah.tex

gv displays a pop-up window with the error message:

Error: /syntaxerror in --token--GPL Ghostscript 8.01: Unrecoverable error,
exit code 1

Operand stack:
   --dict:5/5(L)--   false   DefaultGray   DefaultGray   ColorSpace
--dict:5/5(L)--   Resources   162   1   0   1   -1.10b   --nostringval--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
   %--nostringval--   2   %stopped_push   --nostringval--   --nostringval--
   %--nostringval--   false   1   %stopped_push   1   3   %oparray_pop   1
   %3   %oparray_pop   1   3   %oparray_pop   1   3   %oparray_pop
   %.runexec2   --nostringval--   --nostringval--   --nostringError:
   %/syntaxerror in readxrefentry
Operand stack:
   --dict:5/5(L)--   false   DefaultGray   DefaultGray   ColorSpace
--dict:5/5(L)--   Resources   162   1   0   1   stream   endobj
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
   %--nostringval--   2   %stopped_push   --nostringval--   --nostringval--
   %--nostringval--   false   1   %stopped_push   1   3   %oparray_pop   1
   %3   %oparray_pop   1   3   %oparray_pop   1   3   %oparray_pop
   %.runexec2   --nostringval--   --nostringval--   --nostringval--   2
   %%stopped_push   --nostringval--   --nostringval--   --nostringval--
   %--nostringval--   --nostringval--   %packedarray_continue
   %--nostringval--   --nostringval--   --nostringval--   --nostringval--
   %--nostringval--   --nostringval--   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1053/1123(ro)(G)--   --dict:0/20(G)--   --dict:74/200(L)--
--dict:100/127(ro)(GGPL Ghostscript 8.01: Unrecoverable error, exit code 1
)--   --dict:230/230(ro)(G)--   --dict:20/24(L)--
Current allocation mode is local

Click the pop-up's "dismiss" button.  gv's main window is blank.

Now if I manually reload the document with "Right click | Reload", the pdf
document reloads and displays correctly!

It's wierd -- as if gv initially has a problem interpreting the pdf file, but when it reloads the pdf, it parses everything correctly.


The problem happens even when gv isn't instructed to watch the pdf file.  For example:

1. Click "State | Watch File" to disable watching.

2. Remove "goodbye":

   \documentclass[12pt]{article}
   \begin{document}
   hello there.
   \end{document}

3. Recompile:

   $ pdflatex blah.tex

4. Reload the pdf file with "Right click | reload"

5. A pop-up appears with the error message:

   Current allocation mode is local
   Error: /syntaxerror in readxrefentry
   ...
   (stack output removed for brevity)

6. Click "Dismiss" to dismiss the pop-up.  gv's main window is blank.

7. Again, click "Right click | reload"

8. The pdf file reloads and displays correctly.


This problem occurs on all my systems (Debian/testing, Debian/unstable).

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #9780:  gv-update.patch added by None (624B - text/x-patch - This patch fixes the problem, see comment)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jemarch (Updated the item)
  •  

    There are 200 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-06-25 jemarch StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2007-06-25 jemarch ReleaseNone 3.6.3
    2007-06-25 jemarch StatusNone In Progress
    2006-06-03 wtfquestionmark Carbon-Copy- Added wtfquestionmark
    2006-04-13 None Attached File- Added gv-update.patch, #9780
    2006-04-09 toolan Carbon-Copy- Added toolan
    2005-10-28 kfhbf Carbon-Copy- Added kfhbf
    2005-05-26 jemarch Severity3 - Normal 4 - Important
        Assigned toNone jemarch

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code