diff options
author | Miklos Vajna <vmiklos@collabora.com> | 2023-11-15 08:24:39 +0100 |
---|---|---|
committer | Miklos Vajna <vmiklos@collabora.com> | 2023-11-15 10:14:25 +0100 |
commit | 47d824dd167eb34b08e5aec7141d2d9e6e996b34 (patch) | |
tree | cb2c512336328b7b566873e90c2d615edcdbb9f7 /sc/source/ui/inc/inputhdl.hxx | |
parent | df9e08cd765731451bf58b2d23590db7263d49fe (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