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
LaunchzamiastURI(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”URIhiperłącza do plików na ichLaunchodpowiedniki?
Opracowana wersja:
Mam dwa dokumenty Worda; doc1.docxoraz doc2.docx(oba skompilowane z MS Word 2007).
W doc1.docxumieszczam hiperłącze do wersji PDF mojego drugiego dokumentu ( doc2.pdf) - teraz mam:

Następnie zapisuję doc1.docxplik jako jedno .docxi drugie .pdf- PDFgenerowanie 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.pdfpomocą 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 windowokreś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 windowopcję). 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.pdfza pomocą fileschematu URI: file:///C:/superuser/doc2.pdf- co wydaje mi się uczciwe (wklejenie tego samego URI w Runoknie 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.pdfw notatniku ++ ujawniło, że hiperłącze zostało zakodowane przy użyciu URItypu 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 URItypu 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.pdfplik w osobnym oknie / innym wystąpieniu Adobe Reader X - ponownie zakładając, że odznaczyłem Open cross-document links in same windowopcję (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 Launchzamiast 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” URIhiperłącza plików na ich Launchodpowiedniki?
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.