sc/source/core/data/column2.cxx | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit 126b1826c465002dccc7c354a584731fa70ec5fd
Author: Stephan Bergmann <sberg...@redhat.com>
AuthorDate: Fri Apr 8 15:05:50 2022 +0200
Commit: Stephan Bergmann <sberg...@redhat.com>
CommitDate: Fri Apr 8 16:44:51 2022 +0200
tdf#148423: Half a hack
"Regression" introduced with de4d296619b978ec303f1d7b1e2c78e13fa7a512 "Avoid
overflow in ScColumn::GetOptimalColWidth", which, for this bug document's
nWidth/nPPTX = 6004/0.0647708 = 92696.1, changed the calculation of nTwips
from
the undefined-behavior 92696 % 65536 = 27161 to the clamped 65535, but
which is
apparently a value large enough to cause "silent" issues (i.e., not causing
further undefined behavior) down the road, leading to a super-narrow column.
That commit already wondered whether sal_uInt16 is a useful choice here, but
lets keep that question unanswered and just clamp at half the previous
value,
which happens to cause presumably more pleasing results.
Change-Id: I1df642b2b9d6818c8be0f8d8f4567a00c399c154
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132734
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sberg...@redhat.com>
diff --git a/sc/source/core/data/column2.cxx b/sc/source/core/data/column2.cxx
index 249d4c1346ac..f0270e07eee9 100644
--- a/sc/source/core/data/column2.cxx
+++ b/sc/source/core/data/column2.cxx
@@ -825,7 +825,7 @@ sal_uInt16 ScColumn::GetOptimalColWidth(
{
nWidth += 2;
sal_uInt16 nTwips = static_cast<sal_uInt16>(
- std::min(nWidth / nPPTX,
double(std::numeric_limits<sal_uInt16>::max())));
+ std::min(nWidth / nPPTX,
double(std::numeric_limits<sal_uInt16>::max() / 2)));
return nTwips;
}
else
