Bug 118616 - PDF export of a form's scrollable memo field shows fewer lines than on the original form
Summary: PDF export of a form's scrollable memo field shows fewer lines than on the or...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2018-07-07 21:12 UTC by Alan Wheeler
Modified: 2023-12-17 11:33 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
To demonstrate PDF shows fewer memo lines than on original (12.20 KB, application/vnd.sun.xml.base)
2018-07-07 21:12 UTC, Alan Wheeler
Details
Similar test database using Firefox (10.76 KB, application/vnd.sun.xml.base)
2019-12-10 17:08 UTC, Alan Wheeler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Wheeler 2018-07-07 21:12:26 UTC
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.
Comment 1 Alan Wheeler 2018-07-14 23:02:47 UTC
I suspect that it may be relevant that my screen resolution is 1440 x 900.
Comment 2 Xisco Faulí 2018-08-29 10:39:42 UTC
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
Comment 3 Alan Wheeler 2018-08-29 12:12:07 UTC
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.
Comment 4 Buovjaga 2018-08-31 14:22:21 UTC
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
Comment 5 Alan Wheeler 2018-09-05 14:25:00 UTC
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"
Comment 6 QA Administrators 2019-12-10 04:05:31 UTC Comment hidden (obsolete)
Comment 7 Alan Wheeler 2019-12-10 17:08:01 UTC
Created attachment 156460 [details]
Similar test database using Firefox
Comment 8 Alan Wheeler 2019-12-10 17:13:39 UTC
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
Comment 9 QA Administrators 2021-12-10 04:22:44 UTC Comment hidden (obsolete)
Comment 10 Alan Wheeler 2021-12-16 20:52:00 UTC
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.
Comment 11 QA Administrators 2023-12-17 03:12:47 UTC Comment hidden (obsolete)
Comment 12 Alan Wheeler 2023-12-17 11:33:19 UTC
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