summaryrefslogtreecommitdiff
path: root/sc/source/ui/inc/inputhdl.hxx
diff options
context:
space:
mode:
authorMiklos Vajna <vmiklos@collabora.com>2023-11-15 08:24:39 +0100
committerMiklos Vajna <vmiklos@collabora.com>2023-11-15 10:14:25 +0100
commit47d824dd167eb34b08e5aec7141d2d9e6e996b34 (patch)
treecb2c512336328b7b566873e90c2d615edcdbb9f7 /sc/source/ui/inc/inputhdl.hxx
parentdf9e08cd765731451bf58b2d23590db7263d49fe (diff)
tdf#157911 sw floattable: fix inconsistent inferred bottom border on split
The bugdoc has a split table between page 1 and page 2. The last row of page 1 has a half bottom border: it starts on the left of the table, but finishes earlier than the right of the table. This is since commit 08aea5526c75ff4c5385e960bd940f10ffa19cd5 (tdf#156351 sw floattable: fix missing bottom border in master table, 2023-08-21). The trouble is that Writer table borders are really at a cell-level (and not at row or table level), the current partial border happens because the first row has merged cells and the last row on page 1 doesn't have merged cells, so the layout can't do a 1:1 mapping between the first row and last row cells. It's also far from clear if the fixed result should be no bottom border or a table-width bottom border: - Word documents can have cell-level borders (where no inferred border is wanted) and table-level borders (where inferred borders are wanted), see the tdf#156351 bugdoc for a case where such inferring is wanted - In case only cell-level borders are defined, then Word doesn't do such inferring Fix the problem by always inferring such borders, because: - Writer already did this in some cases for a long time, see commit a4da71fb824f2d4ecc7c01f4deb2865ba52f5f4c (INTEGRATION: CWS fmebugs04 (1.115.46); FILE MERGED 2008/05/13 13:56:19 fme 1.115.46.2: #i9860# Top border for tables - correction 2008/05/13 13:49:23 fme 1.115.46.1: #i9860# Top border for tables, 2008-06-06) - The Word UI creates table borders by default, so the majority of the DOCX documents also want this inferring An alternative could be to only do such inferring for Word documents with a compat flag, but that looks poor, given that Word doesn't always do such inferring itself, either. Change-Id: I052e4591e99d066c3109e8ab8b590e97c8aebd36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159429 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
Diffstat (limited to 'sc/source/ui/inc/inputhdl.hxx')
0 files changed, 0 insertions, 0 deletions