Description: I hae tested this issue, it only occurs in specific stylesheets ("title"-Stylesheets). Umlauts like ä, ö or ü are getting transformed into mere a,o and u within the resulting pdf-file, which is very very annoying. Steps to Reproduce: 1.Set a title with an umlaut 2.give it the stylesheet title or title1-4 (german: Überschrift1-4) 3.Export the pdf-File Actual Results: The ä,ö and ü-letters are transformed into a, o and u Expected Results: It should let the umlauts be umlauts Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0 Cyberfox/50.0
A test document with example of styles dropping format would be helpful--but we mostly need to know the font that the "title" style is corrupt with. So we know the configuration of your system please post the Help -> About dialog entry. Also, please identify the version of MS Windows, and the graphics card and driver you are using. All of those will impact the behavior of OpenGL or default GDI+ font fall back.
Created attachment 129727 [details] Test File with umlauts in different stylesheets
So here are the additional informations: - the font is Liberation Sans - Operating System is Windows 10 Pro x64 - Graphics Card is Intel HD 4000, Driver-Vers.: 10.18.10.4358
Created attachment 129730 [details] clip from exported PDF (5.2.4.1) -- not reproduced Can not reproduce, on Windows 10 Pro 64-bit en-US with Version: 5.2.4.1 (x64) Build ID: 9b50003582f07ac674d6451e411e9b77cccd2b22 CPU Threads: 8; OS Version: Windows 6.19; UI Render: default or GL Locale: en-US (en_US); Calc: group and Tools -> Options -> Language Settings -> Languages: Ignore system input language checked The export to PDF encodes the correct glyphs (u+00e4, u+00fc, u+00f6, u+00c4, u+00d6, u+00dc) from Liberation Sans and Liberation Serif into the PDFs. Likewise not reproduced with Version: 5.2.2.2 (x64) Build ID: 8f96e87c890bf8fa77463cd4b640a2312823f3ad CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US); Calc: CL
Could you test with 5.3 http://dev-builds.libreoffice.org/pre-releases/win/x86_64/LibreOfficeDev_5.3.0.0.beta2_Win_x64.msi Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists with 5.3.
Did some testing today - and one option that i didn't expect seems to be the problem: My pdf-viewer! I use Pdf-X-Change Viewer a long time now and without ever having problems interpreting pdf-files. However, in Acrobat-Reader DC, the umlauts in the testfiles pdf-export are shown correctly. This occurs only with Liberation Sans, though. I will have a try with 5.3 the next days but i now think this was indeed no Libre-Office Bug at all- Nevertheless - thanks for the support this far!!
Is this like bug 89246, except not with Type 1 fonts this time?
(In reply to Aron Budea from comment #7) > Is this like bug 89246, except not with Type 1 fonts this time? Yes, no substitution.. if the original font is indeed Lib. sans.
Created attachment 129765 [details] Sight of test document in Libre Office
Created attachment 129766 [details] Sight of document in x-change Viewer
Created attachment 129767 [details] Zoomed into xchange-viewer sight: the dots are there!
Created attachment 129768 [details] Sight of exported pdf in acrobat reader
I personally have no idea wether the font or the pdf-reader or libre-office is the source of the problem. I submitted some jpegs which represents quite all that i can provide: Test file in 5.3Dev and the pdf-Output in different readers. Interesting is that the dots of the umlauts don't get lost, but get displaced. My workaround is using another font (like Times or Liberation Serif) or alternatively using the acrobat reader (for in prints with x-change viewer, the dots on the umlauts are also displaced as seen in the document) I set the bug report back to unconfirmed
Have the umlauts with Liberation Sans, exported as PDF, viewed with X-change viewer, ever worked for you with an older version of LibreOffice?
I'm using Libre Office and PDF-X-Change Viewer together a long time now (since the libre office branch started) - and i always exported documents as pdf before printing without noticing any problems (and i used stylesheets quite excessively). Liberation Sans seems to be the standart font for the title-stylesheets, although i cannot recall, wether this was always so or not. So in conclusion, there is quite a chance that this problem didn't exist in a former version of Libre-Office. But I have to test this theory (lookup old documents/ install older Version) before i can be sure about this.
(In reply to don-elgrun from comment #15) > So in conclusion, there is quite a chance that this problem didn't exist in > a former version of Libre-Office. > But I have to test this theory (lookup old documents/ install older Version) > before i can be sure about this. You could use this to install old versions https://wiki.documentfoundation.org/SI-GUI Installer link: http://tdf.io/siguiexe
Export to PDF will be fine using PDF-Xchange (with probably every LibO version) when the test document is created with Version: 4.1.0.4 (probably any version in the 4.1 branch) Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28
Created attachment 133805 [details] Test file I'm struggling with the same problem in LibreOffice Impress using its default font Liberation Sans.
Created attachment 133806 [details] Test file after PDF export
(In reply to Ettore Atalan from comment #19) > Created attachment 133806 [details] > Test file after PDF export And what PDF viewer is causing you trouble? The file works fine with Okular and Firefox PDF viewer.
(In reply to Buovjaga from comment #20) > (In reply to Ettore Atalan from comment #19) > > Created attachment 133806 [details] > > Test file after PDF export > > And what PDF viewer is causing you trouble? The file works fine with Okular > and Firefox PDF viewer. Dear Reporter, Could you please answer the question above? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the question is answered
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20180502
I think it's safe to close this one. I had similar issue when testing Bug 115117 and old PDF-Xchange Viewer 2.5 was the culprit. New version didn't have problem. And Adobe works fine.