Created attachment 117465 [details]
sample textbox as displayed in adobe reader
Creating a PDF text box object, exporting/saving it as PDF and opening the PDF in Adobe Reader or other Readers like PDF X-Change-Viewer result in weird white inline borders between the writable field and the border of the field.
This just happens with "flat" or "3D" borders of text boxes. Text boxes without borders get correctly filled up so that the whole defined box space is filled with the writable field.
Black border is the normal text box with "3D" border. Blue field is the writable area.
Expected result: the blue field should be "maximised" to the border.
Actual result: if your font size is bigger than the blue box but would fit into the text box the font will be cut off.
please give step-by-step instructions to show how do you create that PDF text box object in LibO.
and tell the LibO version you are using and your O/S
LibreOffice version: all since about 3.2 - currently installed: 188.8.131.52
O/S: Windows 8.1 Pro
Steps to reproduce(loosely translated from the german descriptions):
- Open LibreOffice writer
- Add the form symbols to the menu if not enabled yet
- Click the "textfield" button (maybe "textbox")
- Draw the textbox at any size
- Click "Export to PDF"
- Open in any PDF reader - Adobe Reader works best because it hilights fillable forms in the blue background as shown in my attached screenshot
If i open the form in Adobe Acrobat i can see, that the form field is way smaller than the box border.
This feature was working correctly in 3.0 or 3.1 but is in this state since then.
A few versions ago it was even worse - the white inner border of the box overlayed the text inside even while printing. That seems no longer to do so - but the white border is still annoying for users who need to fill these forms.
Maybe make the cell padding of a text box at least configurable?
(In reply to Florian Wicke from comment #3)
> LibreOffice version: all since about 3.2 - currently installed: 184.108.40.206
> O/S: Windows 8.1 Pro
> This feature was working correctly in 3.0 or 3.1 but is in this state since
I think you refer to old OpenOffice versions since LibO first release was 3.3.0
I adjust version and hardware fields and set back status to UNCONFIRMED
I'll retest later with the steps you described. thanks
NitroPDF shows the fillable area correctly filling the text box.
Win 7 Pro 64-bit, Version: 220.127.116.11
Build ID: 2c39ebcf046445232b798108aa8a7e7d89552ea8
Please attach a sample document as well as the pdf export - setting back to NEEDINFO - once you provide a simple sample document as well as the corresponding PDF please set to UNCONFIRMED.
Thanks for your patience! We have millions of users and a small group of contributors - the more you do to help us, the faster the process goes.
Feel free to jump into our chat to say hello and to get involved: http://webchat.freenode.net/?channels=libreoffice-qa
Created attachment 117614 [details]
simple document with textbox
Created attachment 117615 [details]
simple document with textbox (PDF)
Created attachment 117616 [details]
simple document with textbox (screenshot from Adobe Acrobat)
as requested a sample document, this document exported as pdf and a screenshot of this document from Adobe Acrobat where you can see that the fillable "Textbox1" is placed inside the text box with cell padding.
* simple document with textbox: form_test.odt
* simple document with textbox (PDF): form_test.pdf
* simple document with textbox (screenshot from Adobe Acrobat): form_test.jpg
Created attachment 117618 [details]
simple document with textbox (small box)
Created attachment 117619 [details]
simple document with textbox (small box) (PDF)
I added two more files where you can see the problem even better - even with NitroPDF.
If you fill the form the letters get cut inside the text box with the white padding border.
Ok, I was looking at it the wrong way.. I can confirm the behavior.
I don't see it as a problem, but I'll set to NEW anyways.
Bug is still present in 5.0.2 and still very annoying :-(
I understand that there are more serious problems than just "layout bugs" but is there anything else i could do to help to get this padding problem fixed?
(In reply to Florian Wicke from comment #15)
> Bug is still present in 5.0.2 and still very annoying :-(
> I understand that there are more serious problems than just "layout bugs"
> but is there anything else i could do to help to get this padding problem
If you want to lower the number of bugs in general, but don't know C++, you can start triaging reports to make them high-quality: https://wiki.documentfoundation.org/QA/Triage_For_Beginners
Thus you will help the developers fix bugs faster.
You might also try sponsoring your issue on FS: http://freedomsponsors.org/
Created attachment 130614 [details]
Text box with a patch removing the cell padding
The bug is in core/vcl/source/gdi/pdfwriter_impl.cxx
around line 4218, it reads:
if( rWidget.Border )
// adjust edit area accounting for border
sal_Int32 nDelta = aFont.GetFontHeight()/4;
if( nDelta < 1 )
nDelta = 1;
rIntern.m_aRect.Left() += nDelta;
rIntern.m_aRect.Top() += nDelta;
rIntern.m_aRect.Right() -= nDelta;
Commenting all of this in order no to apply anymore the nDelta leads to the attachment, which if I understand correctly is what Florian wants.
Note that the attachment has been created using the form_test.odt attachment provided here.
By the way I traced this to the following commit:
Author: Jens-Heiner Rechtien <email@example.com>
Date: Wed Sep 8 15:21:42 2004 +0000
which contains loads of changes, but might be related to "2004/05/18 13:57:02 pl 18.104.22.168: begin to implement PDF widgets", so I'd say that it has "always" been there; this was Ooo 1.1.2 or 1.1.3...
(some newer commits did change this code a little, but not its behaviour, there are only changes of names of parameters or method names).
Yes, the attached document from JC Cardot is exactly what i meant it should be. Is there any reason to add this nDelta to the border area?
JC: thank you for the investigation. Please submit the patch to gerrit so developers can review it: https://wiki.documentfoundation.org/Development/gerrit
Also relevant: https://wiki.documentfoundation.org/Development/GetInvolved
If you want to continue looking into bug fixes, that would be great. An alternative would be to continue as a QA investigator: https://wiki.documentfoundation.org/QA
Just asking as we desperately need skilled bug detectives like yourself.
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Still the case, also on Mac
Build ID: 25c390e17a7f1c018b5eed1ef7dfd568b76f4a84
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx;
Locale: en-US (en_US.UTF-8); UI-Language: en-US