Bug 103959 - Merged cell contents do not overflow cell boundaries, but still affect print range calculations
Summary: Merged cell contents do not overflow cell boundaries, but still affect print ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Calc-Merge-Split
  Show dependency tree / graph
 
Reported: 2016-11-16 17:37 UTC by tmacalp
Modified: 2024-08-12 03:13 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description tmacalp 2016-11-16 17:37:59 UTC 
Description:
Normally, cells that contain text longer than what the cell boundaries allow will overflow to adjacent cells as long as those adjacent cells are empty (and wrapping is not enabled).  When cells are merged, they no longer are capable of overflowing, but they still extend the print range to the adjacent cells they would have overflowed to.

This has affected a few of my users.  They set up forms with merged cells, but forget to use wrapping.  It leads to all kinds of confusion when they attempt to print their form that appears to be contained in a single page, but extends to multiple pages.

Steps to Reproduce:
1. New spreadsheet
2. View->Page Break (so we can see where pages are breaking)
2. Type a super long line in cell A1 that extends to a second page
3. Note that the A1 cell contents spill over into adjacent columns and extend print range
4. Select cell range A1:B1
5. Format->Merge cells->Merge cells
6. Note that the merged cell now truncate cell contents to the cell boundary (with red triangle indicator), but the print range is still extended

Actual Results:  
The merged cell truncate cell contents to the cell boundary (with red triangle indicator), but the print range is still extended.

Expected Results:
I see no reason why merged cells should truncate contents.  IMO, they should behave like normal cells and overflow their contents to neighboring cells if they're empty.  This would make it obvious that cell wrapping should be enabled.


Reproducible: Always

User Profile Reset: No

Additional Info:
Tested using ancient OpenOffice 3.2.1 and still affects version 5.2.3.3 using Fedora 23.


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Comment 1 Buovjaga 2016-11-24 10:40:52 UTC 
Repro.

Win 7 Pro 64-bit Version: 5.3.0.0.alpha1+
Build ID: 172325bedf69bbc162f3c1948264451c90c105a3
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-11-21_05:26:40
Locale: fi-FI (fi_FI); Calc: group
Comment 2 QA Administrators 2018-06-04 02:34:13 UTC Comment hidden (obsolete)
Comment 3 Ming Hua 2019-02-11 15:04:27 UTC 
I can confirm that I still experience this bug as recent as 6.1.5.

Version: 6.1.5.2 (x64)
Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805
CPU threads: 2; OS: Windows 10.0; UI render: default; 
Locale: zh-CN (zh_CN); Calc: group threaded
Comment 4 QA Administrators 2021-05-28 04:50:23 UTC Comment hidden (obsolete)
Comment 5 Timur 2022-08-12 11:52:13 UTC 
(In reply to tmacalp from comment #0)
> Actual Results:  
> The merged cell truncate cell contents to the cell boundary (with red
> triangle indicator), but the print range is still extended.

Print range is still extended only with Format->Merge and Unmerge cells->Merge cells (bug that should be resolved here) and not with Merge and Center Cells. 

Both truncate cell contents (may remain as another bug of lower priority, as workaround is to merge more cells). This behavior is the same in MSO. 

Repro 7.5+.
Comment 6 QA Administrators 2024-08-12 03:13:15 UTC 
Dear tmacalp,

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