fitH value not recognized by pdfremotestartview

[davidcarlisle]

Roughly translated from

http://www.guitex.org/home/en/forum/5-tex-e-latex/109472-hyperref-valore-non-riconosciuto-da-pdfremotestartview#109497

\documentclass{article}
\usepackage[pdfremotestartview=FitH]{hyperref}
\begin{document}
Prova
\end{document}

appears to be valid according to the list on page 11 of the manual, but produces

Package hyperref Warning: Invalid value `FitH'
(hyperref)                of `pdfremotestartview'
(hyperref)                is replaced by `Fit' on input line 4362.

[davidcarlisle]

again taken from the guitex thread

So, null is a reserved word of the PDF language (see PDF Reference, sixth edition, Version 1.7, subsection 3.2.8 ), not of the regex language! When writing null, Rahtz and Oberdiek actually meant that, after FitH, either a number, o a literal null must follow: indeed, this is what the abovementioned manual prescribes in subsection 8.2.1. In other words, according to specifications, the value FitH for the pdfremotestartview option should be followed by an argument, and indicated as

\hypersetup{pdfremotestartview={FitH null}}

or, if you know what you are doing, with null replaced by a numerical value (for explanations, see again subsection 8.2.1 of the cited manual).

Now, subsection 8.2.1 isn’t very clear, but, by experiment, you can see that a “bare” FitH value (that is, one without any following argument) is accepted as well in Acrobat Reader, and makes a link behave as expected when clicked. This means that we can allow such an argumentless version too.

If we take into account also the issue about the malformed pattern, caused by the fragment

Fit(|B|%
    (H|V|BH|BV) (null|\HyPat@NonNegativeReal/)|%

that indeed contains an empty alternative immediately after Fit(, and which caused pdfTeX to report correctly an empty (sub)expression, we can dare to formulate the following proposal for amending the definition of the pdfremotestartview key:

\define@key{Hyp}{pdfremotestartview}{%
  \ifx\\#1\\%
    \def\@pdfremotestartview{/Fit}%
  \else
    \hypercalcbpdef\@pdfremotestartview{#1}%
    \edef\@pdfremotestartview{\@pdfremotestartview}%
    \Hy@Match\@pdfremotestartview{}{%
      ^(XYZ(%
            ()| % add "+" after the space?
            (null|-?\HyPat@NonNegativeReal/) % add "+" after the space?
            (null|-?\HyPat@NonNegativeReal/) % add "+" after the space?
            (null|\HyPat@NonNegativeReal/)%
          )|% end of "XYZ"
        Fit(%
            ()|%
            B|%
            (H|V|BH|BV)(%
                ()| % add "+" after the space?
                (null|\HyPat@NonNegativeReal/)%
              )|%
            R % add "+" after the space?
                \HyPat@NonNegativeReal/ % add "+" after the space?
                \HyPat@NonNegativeReal/ % add "+" after the space?
                \HyPat@NonNegativeReal/ % add "+" after the space?
                \HyPat@NonNegativeReal/%
          )% end of "Fit"
      )$%
    }{}{%
      \Hy@Warning{%
         Invalid value `\@pdfremotestartview'\MessageBreak
         of `pdfremotestartview'\MessageBreak
         is replaced by `Fit'%
      }%
      \let\@pdfremotestartview\@empty
    }%
    \ifx\@pdfremotestartview\@empty
      \def\@pdfremotestartview{/Fit}%
    \else
      \edef\@pdfremotestartview{/\@pdfremotestartview}%
    \fi
  \fi
}

Of course, there are still lots of things I don’t understand yet. For example, why is the syntax of pdfremotestartview checked, but not, say, that of pdfstartview?

Ciao.

--
Gustavo

[u-fischer]

Seems to work fine now, so I'm closing the issue.