Version corta:
- ¿Hay alguna manera de hacer que MS Word 2007 (o más reciente) codifique hipervínculos de archivos relativos (un hipervínculo que apunta, por ejemplo, a otro archivo PDF) usando el Tipo de acción en
Launch
lugar deURI
(ambos tipos especificados en la página 653 del Formato de documento portátil de Adobe, Referencia en PDF, versión 1.7, sexta edición: http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/pdf_reference_1-7.pdf )? ¿O es la única solución para implementar un postprocesador que puede cambiar todos losURI
hipervínculos de archivos codificados "incorrectos" a suLaunch
equivalente?
Versión elaborada:
Tengo dos documentos de Word; doc1.docx
y doc2.docx
(ambos compilados con MS Word 2007).
En doc1.docx
coloco un hipervínculo a una versión en PDF de mi segundo documento ( doc2.pdf
) - por lo que ahora que tengo:
Luego guardo el doc1.docx
archivo como ambos .docx
y .pdf
- la PDF
generación es manejada por el editor de PDF incorporado en MS Word 2007 usando las siguientes opciones:
Hasta ahora todo bien, entonces tengo la siguiente estructura de carpetas:
/superuser
- doc1.docx
- doc1.pdf
- doc2.docx
- doc2.pdf
Luego abro doc1.pdf
con Adobe Reader X (versión 10.1.3) y hago clic en el hipervínculo que apunta doc2.pdf
. Como el enlace es relativo, habría adivinado / asumido que Adobe Reader X simplemente abriría el archivo PDF de destino en una ventana separada o en la misma instancia de Adobe Reader X (dependiendo de la opción Open cross-document links in same window
especificada en:) Edit -> Preferences -> Documents
.
Sin embargo, ese no es el caso. En cambio, Adobe Reader X resuelve el hipervínculo utilizando el navegador predeterminado (en mi caso Google Chrome v21 + en Windows 7 x64), y para ser claros, este es el problema . Quiero que Adobe Reader X (y la mayoría de sus predecesores) resuelva el hipervínculo abriendo el PDF de destino en otra instancia de Adobe Reader X (suponiendo que haya desmarcado la Open cross-document links in same window
opción). Repetir el mismo escenario con mi lector de PDF (predeterminado); Sumatra PDF funciona como se esperaba: Sumatra PDF abre el archivo PDF de destino en una ventana separada y me muestra el contenido dedoc2.pdf
. Entonces, ¿por qué no usar Sumatra PDF y luego lo preguntas? Me hubiera encantado, sin embargo, el problema es que estoy trabajando en un proyecto con una gran cantidad de usuarios finales, y no puedo suponer que todos usan otro lector de PDF que Adobe Reader X, por lo que no hay otra forma que descubrir qué está pasando con Adobe Reader X.
Entonces, para llegar allí, comencé a cavar.
Primero, al mirar la barra de direcciones en Chrome, se ve que Adobe Reader X intenta resolver doc2.pdf
usando el file
esquema URI: file:///C:/superuser/doc2.pdf
- lo que me parece justo (pegar el mismo URI en el Run
cuadro de diálogo en Windows 7 causa mi lector de PDF predeterminado (Sumatra PDF ) para abrir el archivo), pero ¿por qué Adobe Reader X le pide al navegador predeterminado que maneje el PDF?
Para responder eso, continué cavando. La apertura doc1.pdf
en notepad ++ reveló que el hipervínculo se ha codificado utilizando el URI
Tipo de acción (consulte las páginas 653 y 662 en el formato de documento portátil de Adobe, PDF Reference, versión 1.7, sexta edición - http://wwwimages.adobe.com/www.adobe .com / content / dam / Adobe / es / devnet / pdf / pdfs / pdf_reference_1-7.pdf ):
/Type/Action/S/URI/URI(doc2.pdf)
La referencia en PDF (p. 662) establece lo siguiente sobre el URI
tipo de acción:
Un identificador uniforme de recursos (URI) es una cadena que identifica (resuelve) un recurso en Internet, generalmente un archivo que es el destino de un enlace de hipertexto, aunque también puede resolver una consulta u otra entidad.
Entonces, lo que de primera mano parecía un error importante en Adobe Reader X comenzó a verse como una implementación justa. Al menos, en este punto, descubrí por qué Adobe Reader X se comporta como lo hace, lo que resultó en una nueva pregunta para responder: ¿cómo codifico correctamente un hipervínculo de archivo (por ejemplo, un enlace a doc2.pdf
) de modo que el PDF resultante esté haciendo Adobe Reader X manejar el enlace en sí (en lugar de pedirle al navegador predeterminado que haga su trabajo)?
Para responder a eso, eché otro vistazo a la especificación de PDF y encontré el Tipo de acción Launch
: sobre ese tipo, la referencia del PDF establece lo siguiente (p. 659):
Una acción de inicio inicia una aplicación o abre o imprime un documento.
Entonces, haciendo el siguiente cambio (usando notepad ++):
Sustitución:
/Type/Action/S/URI/URI(doc2.pdf)
Con este:
/Type/Action/S/Launch/F(doc2.pdf)
... Adobe Reader X resuelve el enlace abriendo el doc2.pdf
archivo en una ventana separada / otra instancia de Adobe Reader X, una vez más, suponiendo que haya desmarcado la Open cross-document links in same window
opción (¡hurra!).
Y ahora, hasta la pregunta real / final que aún no he logrado resolver, ¿hay alguna manera de hacer que MS Word 2007 (o más reciente) codifique hipervínculos de archivos relativos (un hipervínculo que apunta, por ejemplo, a otro archivo PDF) usando el Tipo de acción en Launch
lugar de URI
(ambos tipos especificados en la página 653 de Adobe Portable Document Format, PDF Reference, versión 1.7, sexta edición - http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en /devnet/pdf/pdfs/pdf_reference_1-7.pdf )? ¿O es la única solución para implementar algún tipo de aplicación de postprocesador que pueda cambiar todos los URI
hipervínculos de archivos codificados "incorrectos" a su Launch
equivalente?
Sé que esto podría causar mucho "TLDR", pero si logras llegar aquí, realmente aprecio tu interés y espero que tú o alguien más puedan señalarme en la dirección correcta.
Gracias.