https://bugs.documentfoundation.org/show_bug.cgi?id=112225
Stephan Bergmann <sberg...@redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |NOTABUG
Status|UNCONFIRMED |RESOLVED
--- Comment #6 from Stephan Bergmann <sberg...@redhat.com> ---
(In reply to Thomas Lendo from comment #0)
> Is it necessary to percent-encoding (URL encoding) all hyperlink UTF-8
> characters today? Some Windows programs like PDF-XChange have problems to
> open such encoded hyperlinks (e.g. "f%C3%BCr" is problematic but not "für").
That appears to be a shortcoming of those "Windows programs like PDF-XChange".
(And I suggest you get in touch with them.)
With your sample PDF files from attachment 138438, "Bug 112225 Straßenbrücken
(exported with LibO 6.1).pdf" contains
> <</Type/Action/S/URI/URI(file:///C:/Users/ths/Desktop/Bug%20112225%20Stra%C3%9Fenbr%C3%BCcken.docx)>>
while "Bug 112225 Straßenbrücken (saved with Word 2013).pdf" contains
> <</Type/Action/S/URI/URI(Bug%20112225%20Straßenbrücken.odt) >>
when interpreting the file's bytes as UTF-8. (The difference in absolute vs.
relative URL is apparently as per your comment 3.)
But at least
<https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf>
"PDF 1.7", section 12.6.4.7 "Interactive Features: Actions: Action Types: URI
Actions" in table 206 "Additoinal entries specific to a URI action" on page
424, specifies that key "URI" is of type "ASCII string" with value: "(Required)
The uniform resource identifier to resolve, encoded in 7-bit ASCII."
And your "...(exported with LibO 6.1).pdf" matches that requirement while your
"...(saved with Word 2013).pdf" does not.
(See also
<https://git.libreoffice.org/core/+/a346dfccd7e342d776dd59eb3ed128557e22a1bf%5E%21>
"tdf#70833: IDNA support when exporing hyperlinks to PDF" for how we are
careful to write ASCII-only URI values.)
--
You are receiving this mail because:
You are the assignee for the bug.
