https://bugs.documentfoundation.org/show_bug.cgi?id=160066
Bug ID: 160066
Summary: Export Writer-Document into PDF malforms an embedded
file system link
Product: LibreOffice
Version: 7.5.9.2 release
Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Printing and PDF export
Assignee: [email protected]
Reporter: [email protected]
Description:
Links with "ü" in it aren't converted properly to PDF.
Note that I am not really sure if this is an issue with Writer. Maybe this is
an issue with PDF viewers.
Steps to Reproduce:
Note that I tried to translate manually all menu items etc. from german to
english. Hence, exact spelling may differ, but I hope I can share the spirit.
1. I got a document with a network filesystem links. They are links to
directories, not files. Among others, there is one link containing non Ascii
characters.
Link (as displayed in the requester gotten with context menu's "Edit link"):
file://network_storage/path1/path2/path3/path4/path5/name%20with%20_ü_%20and%20spaces/path7
Note that I edited the path manually in order to not disclose internal
information; nevertheless, I don't changed the overall-depth and the depth of
the problematic directory name, containing an "ü".
When I open the document in Writer, I can Ctrl-Click on the link, and it opens
an Explorer-Window displaying the linked directory. Fine.
2. Export a PDF via File menu, "Export as >", "Export as PDF ..."
3. Open the resulting PDF with PDF-XChange-Viewer. Hoovering the link there
shows a bubble help with the link destination. There the "ü" is replaced by
"%C3%BC", i.e. instead of "name%20with%20_ü_%20and%20spaces" there is
"name%20with%20_%C3%BC_%20and%20spaces". Clicking it yields an error about file
not found. (Note: "%C3%BC" happens to be a percent-encoded UTF-8 encoding of
"ü".)
This is the issue. Continue for further hints:
4. Change the link manually by replacing the "ü" by "%FC" (the percent-encoded
Windows-1252 code of "ü"). This link won't work in Writer with Ctrl-Click.
5. Repeat to export PDF and open it in PDF-XChange-Viewer.
6. Hoovering reveals the manually coded percent encoded Windows-1252 char. I.e.
"name%20with%20_%FC_%20and%20spaces" appears. Clicking the link opens the
wanted Explorer window. Voilà.
I tried another PDF viewer (SumatraPDF), but it didn't process any link
correctly, whether it contains "ü" or not. Apparently it precedes any link by
the path the PDF resides, maybe because it didn't grasp that the path is
already an absolute one. But according to the error messages that appear, it
also deals with an Unicode encoded "ü" after steps 1..3 and a
Windows-1252-encoded "ü" after steps 4..6.
I assume this is a SumatraPDF-related issue. I just want to mention in case.
Actual Results:
PDF-Xchange doesn't process the link correctly, unless I manually "preprocess"
it as described above (steps 4 ff).
Expected Results:
PDF-Xchange should process the link correctly with no "preprocessing".
Reproducible: Always
User Profile Reset: No
Additional Info:
I didn't do any exhausting "first affected version" search; instead I just
mention the version current used. I got no knowledge about a former version
that is not affected.
[Information automatically included from LibreOffice]
Locale: de
Module: TextDocument
[Information guessed from browser]
OS: Windows (All)
OS is 64bit: no
--
You are receiving this mail because:
You are the assignee for the bug.
