LibreOffice 7 - Writer A user create forms with a text box with this attributes:
- 5 lines height
- Multiline (multipleparagraphs) input control
- 200 characters limit
- Vertical scroll bar OFF
However, on when filling that text field, in ODT and exported PDF, user can press intro 20 times and enter text more than 5 lines of text.
In Writer, scrollbar is not showed, but user can enter "Enter" key without limits
In exported PDF, scrollbar IS showed when user typed more than 5 times "Enter" key , despite, exceeding text will NOT visible cause exceeds control visible area. That should not happen!!!
Steps to Reproduce:
1.Create a text control en a Form in Writer with 5 lines height
2.Disable scrollbar in text control properties
3.Enable multiparagraph content
4.Exit "Form edition" mode
5.Try to insert text on that control
6.Press "Enter" more than 5 times
In Writer: Can continue entering carriage returns without limit
In exported PDF form: Scroll bar appear after hitting +5 times "Enter" and can continue withot limits.
No control over lines ("enter") entered by user.
User Profile Reset: Yes
Stop letting user to enter more carriage returns if number of carriage returns exceed text control height
Happens in Windows and Linux and distint versions of LibreOffice (all 7.x.x)
I tried the following steps
1. Display "Form Control" tolbar
2. Insert TextBox and make sure, that setting for scrollbar in general properties dialog is "None"
3. Exit Design Mode
4. Enter several paragraphs in TextBox (so that it doesn't fit with the height of the TextBox
5. Export to PDF
Actual Result: PDF has a scrollbar
Expected result: PDF has no scrollbar
Rafael, I don't understand, why you expect a limit of CR. I won't expect this.
(In reply to Dieter from comment #1)
> Rafael, I don't understand, why you expect a limit of CR. I won't expect
Rafael, could you please explain it?
Could you please also test, if behaviour has changed in the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? P
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Scenario: Writer form with a text box.The user specifies in the text box properties that it should be no longer than 300 characters. Writer perfectly controls the number of characters the user enters, even counting carriage returns.
The problem I want to point out is in cases where the user enters carriage returns and the text does not fit in the height provided for the text box. Writer will allow the user to enter as many lines as they want, even if this means that they will not be seen (if they exceed the height of the box, as I mentioned). But the problem gets worse when, for example, the user EXPORTS to PDF to submit the document.
In the Writer document the recipient of the document can see all the text by scrolling down with the course keys (or with the vertical scroll bar if it has been activated in the text box).
However, if the user wants to send the document already filled in to the recipient and exports the form to PDF/A , activating this option and deactivating the option "Create PDF form", the recipient will not be able to see the text that exceeds the height of the text box, as he/she cannot scroll down it, and this is a very serious problem: The recipient of the document will not be able to see all the content, even if the vertical scroll bar is activated in the Writer form. Moreover, even if the problem of the vertical scroll bar not appearing when exporting is corrected, if the recipient prints the document, the text that does not appear that exceeds the height of the text box will not be printed on the paper.
The only solution I can think of is to enable an "autosize" option that makes the text box taller as the user types, or to not allow the user to type beyond the height of the text box.
Pretty sure that this is an old problem, or rather a different way of presenting an already well known limitation of multiline form controls.
Multiline form controls in Writer do not auto-resize, either by expanding the box size, or reducing the font size of the content (unless something has changed very recently and I missed it).
There is a discussion here:
on how to achieve what I think you are looking for, using macros.
As you can see, it is a very old thread, dating back initially to 2008.
(In reply to rafael.linux.user from comment #3)
Thnak you for response. Problem is now more clear for me. But i think this is an enhancement request rather than a bug. So I add design-team.
cc: Design-Team for further input and decision
My scenario follows comment 1 with a max text length set to 10 so I can enter 5 numbers (plus CR/LF).
In Writer I can change the numbers but not add more. In the exported PDF I can add (an unlimited number of) characters. The option "Max.text length" is not respected.
Sizing the control in Writer to show exactly 5 lines with no scrollbars works well. But the PDF will show scrollbars anyway. The option "Scrollbars" is not respected.
I don't see autoresize playing a role here. My expectation is that PDF follows the document.
Maybe a duplicate of bug 101800.
(In reply to Heiko Tietze from comment #6)
> My scenario follows comment 1 with a max text length set to 10 so I can
> enter 5 numbers (plus CR/LF).
> Issue 1:
> In Writer I can change the numbers but not add more. In the exported PDF I
> can add (an unlimited number of) characters. The option "Max.text length" is
> not respected.
@Heike: what do you do about the possibility of being able to add CR in the Writer document text box despite setting a visible line limit through the dimensions of the text box ?
The OP mentions this as one of his problems as well in comment 1.
I agree with you with regard to the PDF export problem, where the exported PDF doesn't respect the criteria defined in the ODT. From that perspective, at least part of this bug report is a DUP of bug 101800.
My comments in regard to autoresize were in response to the OP's comment 3, paragraph 4.
(In reply to Alex Thurgood from comment #8)
> @Heiko: what do you do about the possibility of being able to add CR in the
> Writer document text box despite setting a visible line limit through the
> dimensions of the text box ?
Don't know an attribute that defines the number of visible lines (and does it makes any sense?). What I do is to size the control so it shows a certain number of lines. The exported PDF uses this height attribute correctly.
Users do not understand what makes sense or not. For this reason, any application must control everything it allows the user to do. The person creating the form can, of course, define a height for the text box. But that does not control the amount of carriage returns or the amount of text the user can enter. If, as I have already explained, the user enters more carriage returns than the height of the text box, when exporting to PDF, the text will not be displayed.
It is a basic rule to consider ALL the situations that can occur on the part of the user in order to control them in the application (in our case, in a Writer form).