Created attachment 143384 [details] To demonstrate PDF shows fewer memo lines than on original When a form showing a scrollable memo field containing more lines than the field can display is exported as a PDF file with "Create PDF form" checked, the field on the resultant PDF file shows a scrollable field containing fewer visible lines than in the field on the database form, though the hidden lines may be viewed by scrolling. I suspect a font problem in that the font used in the PDF file is different from (and slightly larger than) the default font used in the database form field. To demonstrate :- 1. Open the attached "Test7 - Memo.odb" database file. 2. Open form "Form1" - this will display a form containing a field of type memo containing 10 lines, of which the first 7 lines are visible, with a scrollbar allowing the remaining 3 lines to be viewed. 3. From the menu bar, select "File", then "Export as PDF..." 4. On the right hand side of the resultant "PDF Options" panel, check only "Create PDF Form" and "View PDF after export", then select "Export" 5. Save the resultant PDF file to a convenient place - it will then be automatically displayed. 6. Observe that the scrollable field on the PDF file displays 5 visible lines, not 7, and they appear to be preceded by a blank half-line. Using the scrollbar, it is possible to view the remaining 5 lines, and they appear to be followed by a blank half-line.
I suspect that it may be relevant that my screen resolution is 1440 x 900.
Hello, Thanks for reporting the issue. I see different behaviours depending on the PDF Viewer. Which one are you using? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the question has been answered
You are right Xisco Faulí - behaviour is very dependent on the PDF viewer used. If I open the PDF file with my default PDF viewer of Adobe Acrobat Reader DC (build 2018.011.20058), behaviour is as described in the original bug report, ie. 5 out of 10 lines are visible in the panel, rather than 7 out of 10 as on the original ODB document form. Unlike on the original ODB document form, there is no vertical scrollbar to indicate that there are further (hidden) lines. If I click in the panel, a vertical scrollbar appears and the remaining 5 lines may be viewed either by using the scrollbar, or by repeatedly selecting cursor-down. If I open the PDF file with Microsoft Internet Explorer 11 (build 11.228.17134.0), it shows apparently identical behaviour . However, if I open the PDF file with Google Chrome (build 68.0.3440.106), 8 out of 10 lines are visible in the panel. There is no vertical scrollbar to indicate that there are further (hidden) lines. If I click in the panel, no vertical scrollbar appears, but the remaining 2 lines may be viewed by repeatedly selecting cursor-down. If I open the PDF file with Microsoft Edge (build 42.17134.1.0), 7 out of 10 lines are visible in the panel. There is no vertical scrollbar to indicate that there are further (hidden) lines. If I click in the panel, no vertical scrollbar appears, but the remaining 3 lines may be viewed by repeatedly selecting cursor-down. If I try to open the PDF file with LibreOffice Write or LibreOffice Impress, it actually opens the file with LibreOffice Draw and seems to convert it to an ODF Drawing (.odg) file before displaying. In this case, all 10 lines are displayed (with no vertical scrollbar), but only the first 9 are within the panel and the remaining line is below the panel. If I try to open the PDF file with Microsoft Word 2016, it attempts to convert it to an editable Word document before displaying, but fails miserably. The panel is displayed, but is empty. None of the PDF viewers that I have tried exactly replicates the original ODB document form, but it appears at first that Microsoft Edge is the closest in behaviour.
I confirm with Adobe Acrobat. I wonder, if it really matters, though. Version: 6.2.0.0.alpha0+ (x64) Build ID: 414ef6cb187dd3bbcc917dbedf3c0c1cc8668f60 CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-08-21_00:13:04 Locale: fi-FI (fi_FI); Calc: threaded
Tested with LibreOffice 3.3.0. Similar symptoms to those described in the original bug report are exhibited using 3.3.0, so set version to "Inherited from OOo"
Dear Alan Wheeler, 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! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 156460 [details] Similar test database using Firefox
I have added a second attachment of the test database created with LibreOffice using embedded Firefox, rather than HSQLDB. It still shows similar symptoms to as originally reported. Now using LibreOffice 6.3.3.2. Information copied from "About LibreOffice" :- Version: 6.3.3.2 (x64) Build ID: a64200df03143b798afd1ec74a12ab50359878ed CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-GB (en_GB); UI-Language: en-GB Calc: threaded
Dear Alan Wheeler, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still present in LibreOffice 7.2.4.1 Version: 7.2.4.1 (x64) / LibreOffice Community Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9 CPU threads: 4; OS: Windows 10.0 Build 22000; UI render: default; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: CL There appears to be 2 problems :- 1) The font and font size used in the form are not completely specified or embedded when exporting, so the PDF reader chooses a reasonable base 14 font. Different PDF readers make different choices, so appearance differs when displaying the exported file and rarely exactly matches the appearance on the original form. 2) The position within the text box is slightly lower when displaying the exported file than it was in the text box on the original form.
Still present on 7.6.4 Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 4; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded