Version courte:
- Existe-t-il un moyen de faire en sorte que MS Word 2007 (ou plus récent) code des hyperliens de fichiers relatifs (un hyperlien pointant vers, par exemple, un autre fichier PDF) à l'aide du type d'action
Launch
au lieu deURI
(les deux types spécifiés à la page 653 du format de document portable Adobe, Référence PDF, version 1.7, sixième édition - http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/pdf_reference_1-7.pdf )? Ou est la seule solution pour implémenter un post-processeur qui peut changer tous lesURI
liens hypertexte de fichiers encodés "faux" en leurLaunch
équivalent?
Version élaborée:
J'ai deux documents Word; doc1.docx
et doc2.docx
(tous deux compilés avec MS Word 2007).
Dans doc1.docx
je place un lien hypertexte vers une version PDF de mon deuxième document ( doc2.pdf
) - alors maintenant j'ai:
J'enregistre ensuite le doc1.docx
fichier à la fois .docx
et .pdf
- la PDF
génération est gérée par l'éditeur PDF intégré dans MS Word 2007 en utilisant les options suivantes:
Jusqu'ici tout va bien - j'ai alors la structure de dossiers suivante:
/superuser
- doc1.docx
- doc1.pdf
- doc2.docx
- doc2.pdf
Puis j'ouvre doc1.pdf
avec Adobe Reader X (version 10.1.3) et clique sur l'hyperlien pointant vers doc2.pdf
. Comme le lien est relatif, j'aurais deviné / supposé qu'Adobe Reader X ouvrirait simplement le fichier PDF cible dans une fenêtre distincte ou dans la même instance d'Adobe Reader X (selon l'option Open cross-document links in same window
spécifiée dans:) Edit -> Preferences -> Documents
.
Mais ce n'est pas le cas. Au lieu de cela, Adobe Reader X résout le lien hypertexte en utilisant le navigateur par défaut (dans mon cas, Google Chrome v21 + sur Windows 7 x64) - et pour être clair - c'est le problème . Je veux qu'Adobe Reader X (et la plupart de ses prédécesseurs) résolve simplement le lien hypertexte en ouvrant le PDF cible dans une autre instance d'Adobe Reader X (en supposant que j'ai décoché l' Open cross-document links in same window
option). Répéter le même scénario en utilisant mon lecteur PDF (par défaut); Sumatra PDF fonctionne comme prévu - Sumatra PDF ouvre le fichier PDF cible dans une fenêtre séparée et me montre le contenu dedoc2.pdf
. Alors pourquoi ne pas utiliser Sumatra PDF alors vous demandez? J'aurais adoré - cependant, le problème est que je travaille sur un projet avec potentiellement beaucoup d'utilisateurs finaux, et je ne peux pas supposer que tous utilisent un autre lecteur PDF qu'Adobe Reader X - donc, il n'y a pas d'autre moyen de contourner qui comprendre ce qui se passe avec Adobe Reader X.
Alors pour y arriver, j'ai commencé à creuser.
Tout d'abord, en regardant la barre d'adresse dans Chrome, on voit qu'Adobe Reader X essaie de résoudre en doc2.pdf
utilisant le file
schéma d'URI: file:///C:/superuser/doc2.pdf
- ce qui me semble juste (coller le même URI dans la Run
boîte de dialogue dans Windows 7 provoque mon lecteur PDF par défaut (Sumatra PDF ) pour ouvrir le fichier) - mais pourquoi Adobe Reader X demande-t-il au navigateur par défaut de gérer le PDF?
Pour répondre à cela, j'ai continué à creuser. L'ouverture doc1.pdf
dans le bloc-notes ++ a révélé que le lien hypertexte a été codé à l'aide du URI
type d'action (voir p. 653 et 662 dans Adobe Portable Document Format, PDF Reference, version 1.7, sixième édition - 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)
La référence PDF (p. 662) indique ce qui suit concernant le URI
type d'action:
Un identificateur de ressource uniforme (URI) est une chaîne qui identifie (résout) une ressource sur Internet, généralement un fichier qui est la destination d'un lien hypertexte, bien qu'il puisse également être résolu en une requête ou une autre entité.
Donc, ce qui à première vue ressemblait à un bogue majeur dans Adobe Reader X a commencé à ressembler à une implémentation équitable. Au moins, à ce stade, j'ai compris pourquoi Adobe Reader X se comporte comme il le fait - entraînant une nouvelle question à laquelle répondre: comment puis-je coder correctement un lien hypertexte de fichier (par exemple un lien vers doc2.pdf
) de sorte que le PDF résultant crée Adobe Reader X gérer le lien lui-même (au lieu de demander au navigateur par défaut de faire son travail)?
Pour répondre à cela, j'ai jeté un coup d'œil à la spécification PDF et trouvé le type d'action Launch
- à propos de ce type, la référence PDF indique ce qui suit (p. 659):
Une action de lancement lance une application ou ouvre ou imprime un document.
Donc, en faisant le changement suivant (en utilisant notepad ++):
Remplacement:
/Type/Action/S/URI/URI(doc2.pdf)
Avec ça:
/Type/Action/S/Launch/F(doc2.pdf)
... Adobe Reader X résout alors le lien en ouvrant le doc2.pdf
fichier dans une fenêtre séparée / une autre instance d'Adobe Reader X - encore une fois en supposant que j'ai décoché l' Open cross-document links in same window
option (hourra !!).
Et maintenant, revenons à la question réelle / finale que je n'ai pas encore réussi à résoudre - existe-t-il un moyen de faire en sorte que MS Word 2007 (ou plus récent) encode des hyperliens relatifs de fichiers (un hyperlien pointant vers, par exemple, un autre fichier PDF) en utilisant le Type d'action Launch
au lieu de URI
(les deux types spécifiés à la page 653 du format Adobe Portable Document Format, référence PDF, version 1.7, sixième édition - http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en /devnet/pdf/pdfs/pdf_reference_1-7.pdf )? Ou est-ce la seule solution pour implémenter une sorte d'application post-processeur qui peut changer tous les URI
hyperliens de fichiers encodés "incorrects" en leur Launch
équivalent?
Je sais que cela pourrait causer beaucoup de "TLDR" - mais si vous parvenez à arriver ici, j'apprécie vraiment votre intérêt et j'espère que vous ou quelqu'un d'autre pouvez me diriger dans la bonne direction.
Merci.