Description: This mostly concerns the height of multi-line text boxes in reports. But as you will see it really concerns all calculated field heights in reports. Some real world data is very-variable in size. For example a 'Notes' text field attached to each accounting record or a product description record might be empty or 20 or more lines. Currently the Base report writer formats text boxes to be of the same height for all records, no matter what the data size is. Thus, if you want all your data to show up on the report, then you must make the height of your text boxes tall enough that your very largest data will not overflow the box. Unfortunately this sometimes means all records have to have that same huge height, wasting much paper, and making reports very unfriendly to read with having to flip thru many pages with not much data on each. Instead of having a fixed height, it would be much better to format reports on the fly and calculate the line, field and group heights based on the actual data content of each record. If a record needs to be 1" tall because it has 5 lines of text then make it that tall. But if there is no text, then allow it to be reduced to the minimum height. I'll attach a demonstration data base in a moment. Thanks! Steps to Reproduce: Open the attached database and then open the 'dietary recommendation' report. Actual Results: Because some records don't have much or any text in multi-line text fields, e.g. From, Excess, and Other Notes, most report pages are full of mostly white space rather than data content. Expected Results: Allow adjusting height of records to the height of actual data. Note: This requires new 'Allow to grow (yes/no)?', and 'Allow to shrink (yes/no)?' properties be added to text and other fields, AND these also need to be added to group properties. Then for example, if can shrink is true, and no data exists this can possibly reduce the height of that field. The total height of a group will be the max height of the tallest group for that record. Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: TextDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Created attachment 140364 [details] Database with data and a report showing this issue
Isn't this a duplicate of bug 45789?
*** This bug has been marked as a duplicate of bug 45789 ***
It seems LibreOffice Writer has serious troubles in the most recent versions. It makes Linux systems (maybe only when working with KDE) crash in the most catastrophic way. First the screen gets blocked, you are not able to do anything, but moving the mouse cursor (interestingly this keeps working). After a few seconds, the screen goes to black and the system halts without any care for anything. I've gone through many forums. Changing memory assignation does not help. The failure tends to happen with non-trivial documents, independently of the size (seems more often with long documents, though). May be some relation with mark, copy, paste operations, but this is not sure either. Somebody reported that they had to go to an older version of LibreOffice and the trouble disapears, I am considering this possibility. In any case, I wonder how, I wonder why, LibreOffice team is not solving this catastrophic situation that is annoying so many people (just search to see how many cases of sudden crash are being reported). My configuration: OpenSuse Leap 42.3 (64 bits), kernel 4.4.162-78-default KDE Plasma 5.8.7 LibreOfice 6.0.5.2, included in OpenSuse official distribution and later updated from official repositories Best regards, David