Bug 141255 - Writer forms: Can't limit carriage returns (scrollbar is not disabled despite it should be)
Summary: Writer forms: Can't limit carriage returns (scrollbar is not disabled despite...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.1.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:pdf
Depends on:
Blocks: PDF-Export Form-Controls
  Show dependency treegraph
 
Reported: 2021-03-25 23:51 UTC by rafael.linux.user
Modified: 2024-03-29 12:48 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rafael.linux.user 2021-03-25 23:51:02 UTC
Description:
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

Actual Results:
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.

Expected Results:
No control over lines ("enter") entered by user.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
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)
Comment 1 Dieter 2021-04-30 07:07:53 UTC
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.
Comment 2 Dieter 2022-03-14 18:57:25 UTC
(In reply to Dieter from comment #1)
> Rafael, I don't understand, why you expect a limit of CR. I won't expect
> this.

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.
Comment 3 rafael.linux.user 2022-03-16 09:07:10 UTC
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.

Thanks
Comment 4 Alex Thurgood 2022-03-22 11:39:36 UTC
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:

https://forum.openoffice.org/en/forum/viewtopic.php?f=39&t=11875

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.
Comment 5 Dieter 2022-03-23 07:42:31 UTC
(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
Comment 6 Heiko Tietze 2022-03-23 08:56:29 UTC
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.

Issue 2:
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.
Comment 7 Heiko Tietze 2022-03-23 08:57:35 UTC
Maybe a duplicate of bug 101800.
Comment 8 Alex Thurgood 2022-03-23 11:02:40 UTC
(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.
Comment 9 Heiko Tietze 2022-03-23 14:20:07 UTC
(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.
Comment 10 rafael.linux.user 2022-03-28 09:39:02 UTC
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).
Comment 11 QA Administrators 2024-03-28 03:13:01 UTC
Dear rafael.linux.user,

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
Comment 12 rafael.linux.user 2024-03-29 12:48:40 UTC
Sincerely, I have no time to test now and as no other users seem to be concerned about the problem, I conclude that I have wasted my time reporting the issue.