Description: I use Calc for invoices, and most of the cells have lines of text that wrap into numerous lines. Even though my template is configured to be at "optimal height" many times after filling a cell the rows crowd the cell and run into the border. Then I reset the row for optimal height again and it looks normal. If I do this, then many times when I reopen the file some rows are crowding their border again, but the print preview looks normal. Then, if I reset the affected rows to optimal height, it looks normal in the working version but the print preview version shows extra space in the cell. My workaround has been to alway look at the print preview to check if it looks correct before printing since it seems to depict the printed or pdf version reliably. Steps to Reproduce: 1.Fill your Calc cell with rows of text 2.Format your Calc document's row height using "optimal height" 3.SAve, close the file, and reopen it. Actual Results: It doesn't alway happen for some unknown reason. Expected Results: Sometimes the row heights change on the working version. Reproducible: Sometimes User Profile Reset: No OpenGL enabled: Yes Additional Info: The working file should look exactly like the printed and print preview version. Should I enable OpenGL? I don't think I've ever had it enabled, but have enabled it now and will see if that fixes the problem.
Do your Calc generated invoice documents behave better if you set your default printer and then enable 'Use printer metrics for text formatting' checkbox from Tools -> Options -> LibreOffice Calc -> General panel? Still set optimal, but with printer metrics will hold the on screen to the printer for both the print preview and the final printed document. Comes at a performance drag on the manipulating the Calc sheet--so is not the default for normal spreadsheet use. Also, what version of LO are you working against--post text from the Help -> About LibreOffice dialog.
Dear Chet Valdes, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Chet Valdes, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp