PDF interpreter - work around GSView 5 and PAGELABEL pdfmarks

We added the ability to process PDF page labels as pdfmarks, instead of
using the .pagelabels operator (as used by pdfwrite) for the benefit of
DejaVu.

Unfortunately, GSView 5 redefines the pdfmark operator, and attempts
to process the information itself. This is a problem when it doesn't
recognise the pdfmark in question, which it does not with PAGELABEL.

There's no way for us to fix GSView 5, and we don't want to revert the
enhancement for DejaVu because that is still being actively maintained.

This commit is a rather ugly hack which relies upon the presence of a
specific named dictionary in userdict when GSView is executing. If that
dictionary is present then we don't create PAGELABEL pdfmarks, thus
avoiding confusing GSView 5.

1 files changed, 10 insertions, 0 deletions

diff --git a/Resource/Init/pdf_main.ps b/Resource/Init/pdf_main.ps
index 01af26af1..09f87353c 100644
--- a/Resource/Init/pdf_main.ps
+++ b/Resource/Init/pdf_main.ps
@@ -166,6 +166,16 @@ pdfdict begin
       % using .pdfpagelabels and not using pdfmarks
     /WantsPageLabels /GetDeviceParam .special_op
     {pop pop false}{true} ifelse
+
+    %% This is truly ugly.....
+    %% GSView 5 redefines pdfmark and processes it itself. However if it gets
+    %% a pdfmark it cannot cope with, it simply fails. Its not prepared to cope
+    %% with PAGELABEL pdfmarks, so we don't want to send it to them. There's no
+    %% way for us to fix GSView 5, its long out of any kind of support, but we do
+    %% try not to break it. We happen to know that GSView 5 installs a GSview
+    %% dictionary in userdict, so this test simply ensures we don't emit PAGELABEL
+    %% pdfmarks if that dictioanry is present.
+    userdict /GSview known {pop false} if
   } bind executeonly
   % generate pagelabel pdfmark
   /dopagelabel {  % -- dopagelabel --