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
Created attachment 193025 [details] sample ODT Tested on Linux with: Version: 7.6.5.2 (X86_64) / LibreOffice Community Build ID: 38d5f62f85355c192ef5f1dd47c5c0c0c6d6598b CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded 1. Created the attached ODT with hyperlink to directory with "ü" in name 2. Link works in app 3. Exported to PDF Results: link works in Evince, Okular. Does not work in Firefox (not clickable) nor Chromium (clickable). On Windows 11 with LO 24.2.1.2, using path file:///C:/Users/Quickemu/umlaüt, it Works in app but the exported PDF shows the path as C:/Users/Quickemu/umla%C3%BCt - Clicking the link in Sumatra PDF does not open the file browser, it shows as file:///C:/Users/Quickemu/umla%C3%BCt - In Firefox, no result - In Edge, clickable but does not open the file browser, shows as file:///C:/Users/Quickemu/umlaüt but opening it into a new tab shows "about:blank#blocked", which makes it look like Edge is not allowing it. Can you please: - update to a currently supported version (7.5 won't see further releases; please use 7.6 or 24.2) - test again, and try opening the PDF in various PDF viewer (implementations vary greatly)
I have installed 7.6.5.2 The behaviour doesn't change. Note that browsers normally consider a link to computers filesystem as a fault and as a security issue. (During normally browsing in the internet, a website with filesystem links is either not finished (web developer has forgotten to replace local ressources by hosted ressources, so the webpage works only on developer's computer) or exploits some issues in order to harm the computer.) On Firefox, I got a add-on that enables local links for local stored documents. On Edge, I don't have such an add-on. I tested more readers. In browser Edge, no link worked (see above), but using the PDF from steps 1 to 3, the hoover bubble help displays an 'ü', while the PDF from steps 4 to 6 displays a %FC instead of the 'ü'. Both look promising. In browser Firefox no link worked and also no link preview (like hoover bubble) is visible. So I cannot retrieve infos from it. SumatraPDF and PDFXChange works as already described.
In browser Firefox no link worked -- despite the mentioned add-on that apparently works only for HTML.