Krótka wersja:
- Czy jest jakiś sposób, aby zmusić program MS Word 2007 (lub nowszy) do kodowania względnych hiperłączy do plików (hiperłącze wskazujące np. Inny plik PDF) za pomocą typu akcji
Launch
zamiastURI
(oba typy określone na stronie 653 formatu Adobe Portable Document, PDF Reference, wersja 1.7, szóste wydanie - http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/pdf_reference_1-7.pdf )? Czy może jedynym rozwiązaniem jest wdrożenie postprocesora, który może zmienić wszystkie „niepoprawne”URI
hiperłącza do plików na ichLaunch
odpowiedniki?
Opracowana wersja:
Mam dwa dokumenty Worda; doc1.docx
oraz doc2.docx
(oba skompilowane z MS Word 2007).
W doc1.docx
umieszczam hiperłącze do wersji PDF mojego drugiego dokumentu ( doc2.pdf
) - teraz mam:
Następnie zapisuję doc1.docx
plik jako jedno .docx
i drugie .pdf
- PDF
generowanie jest obsługiwane przez wbudowanego wydawcę plików PDF w MS Word 2007 przy użyciu następujących opcji:
Jak dotąd tak dobrze - mam następującą strukturę folderów:
/superuser
- doc1.docx
- doc1.pdf
- doc2.docx
- doc2.pdf
Następnie otwieram za doc1.pdf
pomocą Adobe Reader X (wersja 10.1.3) i klikam hiperłącze wskazujące na doc2.pdf
. Ponieważ łącze jest względne, zgadłem / założyłem, że Adobe Reader X po prostu otworzy docelowy plik PDF w oddzielnym oknie lub w tym samym wystąpieniu Adobe Reader X (w zależności od opcji Open cross-document links in same window
określonej w:) Edit -> Preferences -> Documents
.
Tak jednak nie jest . Zamiast tego program Adobe Reader X rozwiązuje hiperłącze za pomocą domyślnej przeglądarki (w moim przypadku Google Chrome v21 + na Windows 7 x64) - i dla jasności - to jest problem . Chcę, aby program Adobe Reader X (i większość jego poprzedników) po prostu rozpoznał hiperłącze, otwierając docelowy plik PDF w innym wystąpieniu programu Adobe Reader X (zakładając, że odznaczyłem Open cross-document links in same window
opcję). Powtarzanie tego samego scenariusza przy użyciu mojego (domyślnego) czytnika plików PDF; Sumatra PDF działa zgodnie z oczekiwaniami - Sumatra PDF otwiera docelowy plik PDF w osobnym oknie i pokazuje mi zawartośćdoc2.pdf
. Dlaczego więc nie skorzystać z Sumatry PDF, pytasz? Chciałbym - jednak problem polega na tym, że pracuję nad projektem z potencjalnie dużą liczbą użytkowników końcowych i nie mogę założyć, że wszyscy korzystają z innego czytnika plików PDF niż Adobe Reader X - więc nie ma innej możliwości zastanawianie się, co się dzieje z programem Adobe Reader X.
Aby się tam dostać, zacząłem kopać.
Po pierwsze, patrząc na pasek adresu w Chrome, widać, że Adobe Reader X próbuje rozwiązać doc2.pdf
za pomocą file
schematu URI: file:///C:/superuser/doc2.pdf
- co wydaje mi się uczciwe (wklejenie tego samego URI w Run
oknie dialogowym w Windows 7 powoduje mój domyślny czytnik PDF (Sumatra PDF ), aby otworzyć plik) - ale dlaczego Adobe Reader X prosi domyślną przeglądarkę o obsługę pliku PDF?
Aby odpowiedzieć na to pytanie, kontynuowałem kopanie. Otwarcie doc1.pdf
w notatniku ++ ujawniło, że hiperłącze zostało zakodowane przy użyciu URI
typu akcji (patrz s. 653 i 662 w formacie Adobe Portable Document Format, PDF Reference, wersja 1.7, szósta edycja - http://wwwimages.adobe.com/www.adobe .com / content / dam / Adobe / en / devnet / pdf / pdfs / pdf_reference_1-7.pdf ):
/Type/Action/S/URI/URI(doc2.pdf)
Odwołanie do pliku PDF (p. 662) zawiera następujące informacje na temat URI
typu akcji:
Jednolity identyfikator zasobu (URI) to ciąg znaków, który identyfikuje (rozpoznaje) zasób w Internecie - zazwyczaj plik będący miejscem docelowym łącza hipertekstowego, chociaż może również rozpoznać zapytanie lub inną jednostkę.
Tak więc, co z pierwszej ręki wyglądało na poważny błąd w programie Adobe Reader X, zaczęło wyglądać na uczciwą implementację. Przynajmniej w tym momencie zorientowałem się, dlaczego Adobe Reader X zachowuje się tak, jak to robi - w wyniku czego pojawia się nowe pytanie, na które należy odpowiedzieć: jak poprawnie zakodować hiperłącze pliku (np. Link do doc2.pdf
), tak że wynikowy plik PDF tworzy Adobe Reader X obsłużyć sam link (zamiast prosić domyślną przeglądarkę o wykonanie zadania)?
Aby odpowiedzieć, że jeszcze raz spojrzałem na specyfikację PDF i znalazłem typ akcji Launch
- o tym typie odwołanie do pliku PDF zawiera następujące informacje (s. 659):
Operacja uruchamiania uruchamia aplikację lub otwiera lub drukuje dokument.
Więc wprowadzając następującą zmianę (używając notatnika ++):
Zastępowanie:
/Type/Action/S/URI/URI(doc2.pdf)
Z tym:
/Type/Action/S/Launch/F(doc2.pdf)
... Adobe Reader X następnie rozwiązuje łącze, otwierając doc2.pdf
plik w osobnym oknie / innym wystąpieniu Adobe Reader X - ponownie zakładając, że odznaczyłem Open cross-document links in same window
opcję (hura!).
A teraz do faktycznego / końcowego pytania, którego jeszcze nie udało mi się rozwiązać - czy jest jakiś sposób, aby MS Word 2007 (lub nowszy) kodował względne hiperłącza do plików (hiperłącze wskazujące np. Inny plik PDF) przy użyciu Typ akcji Launch
zamiast URI
(oba typy określone na stronie 653 Adobe Portable Document Format, PDF Reference, wersja 1.7, szósta edycja - http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en /devnet/pdf/pdfs/pdf_reference_1-7.pdf )? Czy może jedynym rozwiązaniem jest implementacja aplikacji postprocesorowej, która może zmienić wszystkie „niepoprawne” URI
hiperłącza plików na ich Launch
odpowiedniki?
Wiem, że może to spowodować wiele „TLDR” - ale jeśli uda ci się tu dotrzeć, naprawdę doceniam twoje zainteresowanie i mam nadzieję, że ty lub ktoś inny może skierować mnie we właściwym kierunku.
Dzięki.