Bug 108222 - PDF Form: Bad characters metrics? only in Linux PDF viewer (click in shows correct content)
Summary: PDF Form: Bad characters metrics? only in Linux PDF viewer (click in shows co...
Status: RESOLVED DUPLICATE of bug 50879
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, filter:pdf
Depends on:
Blocks: PDF-Export Form-Controls
  Show dependency treegraph
Reported: 2017-05-29 14:09 UTC by Andreas Gruenbacher
Modified: 2021-04-21 13:59 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Example form demonstrating the bug: pdf (7.91 KB, application/pdf)
2017-05-29 14:09 UTC, Andreas Gruenbacher
Example form demonstrating the bug: source odt (8.49 KB, application/vnd.oasis.opendocument.text)
2017-05-29 14:10 UTC, Andreas Gruenbacher
Screenshot of bug in PDF viewer (4.49 KB, image/png)
2017-05-29 14:14 UTC, Andreas Gruenbacher
Example created with LO 5.2.6 in Windows (8.33 KB, application/pdf)
2019-01-04 08:30 UTC, Timur
Example created with LO 6.3+ in Windows (8.39 KB, application/pdf)
2019-01-04 08:32 UTC, Timur
Opened and saved in Adobe Acrobat on Windows (13.92 KB, application/pdf)
2019-01-09 21:52 UTC, Andreas Gruenbacher

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Gruenbacher 2017-05-29 14:09:28 UTC
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.
Comment 1 Andreas Gruenbacher 2017-05-29 14:10:33 UTC
Created attachment 133696 [details]
Example form demonstrating the bug: source odt
Comment 2 Andreas Gruenbacher 2017-05-29 14:14:29 UTC
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.)
Comment 3 Xisco Faulí 2017-05-31 16:09:06 UTC
Confirmed in

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


LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-
Comment 4 Andreas Gruenbacher 2018-01-02 21:08:01 UTC
The bug still exists in LibreOffice 5.4.4, which probably isn't surprising given that Xisco could reproduce in

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!
Comment 5 Timur 2019-01-03 15:08:29 UTC
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".
Comment 6 Andreas Gruenbacher 2019-01-03 19:16:41 UTC
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.
Comment 7 Timur 2019-01-04 08:30:07 UTC
Created attachment 147988 [details]
Example created with LO 5.2.6 in Windows
Comment 8 Timur 2019-01-04 08:32:50 UTC
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
Comment 9 Andreas Gruenbacher 2019-01-09 21:49:42 UTC
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.
Comment 10 Andreas Gruenbacher 2019-01-09 21:52:41 UTC
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.
Comment 11 QA Administrators 2021-01-09 03:49:43 UTC Comment hidden (obsolete)
Comment 12 Timur 2021-04-21 13:22:57 UTC
This is fixed for me in Lo 7.1.
I bisected to 6294.. fix in bug 50879.
Could be considered Fixed, but I'll mark duplicate.

*** This bug has been marked as a duplicate of bug 50879 ***