Created attachment 133695 [details]
Example form demonstrating the bug: pdf
In PDF Forms created with LibreOffice, some accented and special characters are displayed incorrectly: they can be entered normally, but when leaving the field, they are displayed as if they had zero width, printing one character over the other.
This includes relatively common characters like "…" (HORIZONTAL ELLIPSIS) and "š" (LATIN SMALL LETTER S WITH CARON).
I have checked the following things:
* LibreOffice itself displays those characters correctly.
* The bug is in the created PDF file, not in the PDF viewer: different PDF
viewers all do not display those characters correctly.
* PDF forms created by other programs do not exhibit this bug.
* This bug exists in various versions of OpenOffice and LibreOffice.
* Changing the font does not have an effect.
* Changing the PDF export options does not help.
Created attachment 133696 [details]
Example form demonstrating the bug: source odt
Created attachment 133697 [details]
Screenshot of bug in PDF viewer
Here, field1 contains the string "š…A", but all three characters are rendered on top of each other. (The character A itself would render correctly.)
Build ID: 9956849c2ea6049582e2ccf04c355542c1ef00a1
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: group
The bug still exists in LibreOffice 5.4.4, which probably isn't surprising given that Xisco could reproduce in 220.127.116.11.alpha0+.
Bug 98479 seems to describe the same problem --- characters like š, …, and € that are printed on top of each other --- but apparently there are also characters like Ř and Ť that "disappear" completely.
Could a kind soul familiar with the PDF file format perhaps diagnose what's wrong with the generated PDF files? Thanks a lot!
I don't reproduce this in Windows with reported LO 5.2.6 not current.
I do reproduce in Linux also with LO master 6.3+ and Xreader and Evince as PDF viewers but I'm not sure it's LO bug.
Because same exported PDF like attachment 133695 [details] appears correctly in Windows PDF viewer.
And because Linux Adobe Reader 9.5.5 show it right.
This remind me of Bug 84963.
I change to minor because click in shows correct "š…A".
Timur, if the bug cannot be reproduced with LibreOffice on Windows, could you please attach a pdf file generated on Windows that behaves correctly so that we can verify?
I have tried viewing attachment 133695 [details] with different viewers on Linux as well as iOS; unfortunately I do not have access to Windows. They all have the problem shown in attachment 133696 [details]. PDF forms created with programs other than LibreOffice do not have this issue on any of those viewers. So it is clear that this is a bug in LibreOffice, and not in the viewers of different vendors on different platforms.
When you click on the input field, you see that you see the correct "š…A" field contents. That's great, it means that the form stores the correct data, but forms created in LibreOffice still don't work for languages that use any of the affected characters. If you're using pdf forms, this is a really bad bug. So please don't be upset when I change the bug severity back to normal, for the lack of access to higher severitis.
Created attachment 147988 [details]
Example created with LO 5.2.6 in Windows
Created attachment 147989 [details]
Example created with LO 6.3+ in Windows
Andreas, please also try Adobe Reader for Linux.
This is minor per https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Both attachment 147988 [details] and attachment 147989 [details] are buggy. I'm getting the result shown in attachment 133697 [details] in Evince, and a similar result on Adobe Acrobat Reader for iOS. So it's not true that the Windows version of LibreOffice isn't affected.
I cannot try this out on Acrbat Reader for Linux because this product isn't being offered by Adobe anymore, and the old versions of that viewer that can still be found on the Internet are almost completely broken by now.
I've had a friend open the PDF from attachment 133695 [details] in the full version of Adobe Acrobat on Windows and save it again though, and the result is a PDF that works in Evince as well as Adobe Acrobat Reader for iOS. It's absolutely clear that the bug is in the PDF generated be LibreOffice.
Created attachment 148186 [details]
Opened and saved in Adobe Acrobat on Windows
This is attachment 133695 [details], opened in Adobe Acrobat for Windows and saved again. The result works as expected.