sw: fix handling of table vs fly overlaps in the AddVerticalFlyOffsets case
When a table overlaps with a fly frame, Writer creates a fly portion
inside the relevant cell frame (increasing its height), and Word shifts
the table down. Both are valid approaches, but the rendering result is
different in case the table has a border.
So keep the default unchanged, but in case the AddVerticalFlyOffsets
compat flag (set by the Word importers) is set, avoid the overlap the
Word way.
Note that the table frame uses the full width (available in the body)
even for e.g. 50% width tables, so check for the overlap using the print
area, which does not always overlap.
Finally, don't always require a valid frame area definition from the fly
frame:
- the mentioned i#46807 bugdoc currently doesn't need that check
- the fly frame area definition becomes valid only after already
positioning the table, leading to an overlap
Keep that check for the non-compat case, though.
Change-Id: I9202050befebf2efdbb5395ded6fcb52b378d8e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88724
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
2020-02-14 09:29:44 -06:00
|
|
|
# -*- Mode: makefile-gmake; tab-width: 4; indent-tabs-mode: t -*-
|
|
|
|
|
#*************************************************************************
|
|
|
|
|
#
|
|
|
|
|
# This file is part of the LibreOffice project.
|
|
|
|
|
#
|
|
|
|
|
# This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
|
# License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
|
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
|
#
|
|
|
|
|
#*************************************************************************
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_CppunitTest,sw_core_layout))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_common_precompiled_header,sw_core_layout))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_add_exception_objects,sw_core_layout, \
|
|
|
|
|
sw/qa/core/layout/layout \
|
|
|
|
|
))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_libraries,sw_core_layout, \
|
|
|
|
|
comphelper \
|
|
|
|
|
cppu \
|
|
|
|
|
cppuhelper \
|
|
|
|
|
sal \
|
|
|
|
|
sfx \
|
|
|
|
|
sw \
|
2020-07-30 14:18:46 -05:00
|
|
|
swqahelper \
|
sw: fix handling of table vs fly overlaps in the AddVerticalFlyOffsets case
When a table overlaps with a fly frame, Writer creates a fly portion
inside the relevant cell frame (increasing its height), and Word shifts
the table down. Both are valid approaches, but the rendering result is
different in case the table has a border.
So keep the default unchanged, but in case the AddVerticalFlyOffsets
compat flag (set by the Word importers) is set, avoid the overlap the
Word way.
Note that the table frame uses the full width (available in the body)
even for e.g. 50% width tables, so check for the overlap using the print
area, which does not always overlap.
Finally, don't always require a valid frame area definition from the fly
frame:
- the mentioned i#46807 bugdoc currently doesn't need that check
- the fly frame area definition becomes valid only after already
positioning the table, leading to an overlap
Keep that check for the non-compat case, though.
Change-Id: I9202050befebf2efdbb5395ded6fcb52b378d8e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88724
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
2020-02-14 09:29:44 -06:00
|
|
|
test \
|
|
|
|
|
unotest \
|
|
|
|
|
utl \
|
|
|
|
|
vcl \
|
|
|
|
|
svt \
|
|
|
|
|
tl \
|
|
|
|
|
svl \
|
2020-10-29 07:41:06 -05:00
|
|
|
svxcore \
|
sw: fix handling of table vs fly overlaps in the AddVerticalFlyOffsets case
When a table overlaps with a fly frame, Writer creates a fly portion
inside the relevant cell frame (increasing its height), and Word shifts
the table down. Both are valid approaches, but the rendering result is
different in case the table has a border.
So keep the default unchanged, but in case the AddVerticalFlyOffsets
compat flag (set by the Word importers) is set, avoid the overlap the
Word way.
Note that the table frame uses the full width (available in the body)
even for e.g. 50% width tables, so check for the overlap using the print
area, which does not always overlap.
Finally, don't always require a valid frame area definition from the fly
frame:
- the mentioned i#46807 bugdoc currently doesn't need that check
- the fly frame area definition becomes valid only after already
positioning the table, leading to an overlap
Keep that check for the non-compat case, though.
Change-Id: I9202050befebf2efdbb5395ded6fcb52b378d8e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88724
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
2020-02-14 09:29:44 -06:00
|
|
|
))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_externals,sw_core_layout,\
|
|
|
|
|
boost_headers \
|
|
|
|
|
libxml2 \
|
|
|
|
|
))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_set_include,sw_core_layout,\
|
|
|
|
|
-I$(SRCDIR)/sw/inc \
|
|
|
|
|
-I$(SRCDIR)/sw/source/core/inc \
|
|
|
|
|
-I$(SRCDIR)/sw/source/uibase/inc \
|
|
|
|
|
-I$(SRCDIR)/sw/qa/inc \
|
|
|
|
|
$$(INCLUDE) \
|
|
|
|
|
))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_api,sw_core_layout,\
|
|
|
|
|
udkapi \
|
|
|
|
|
offapi \
|
|
|
|
|
oovbaapi \
|
|
|
|
|
))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_ure,sw_core_layout))
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_vcl,sw_core_layout))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_rdb,sw_core_layout,services))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_custom_headers,sw_core_layout,\
|
|
|
|
|
officecfg/registry \
|
|
|
|
|
))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_configuration,sw_core_layout))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_uiconfigs,sw_core_layout, \
|
|
|
|
|
modules/swriter \
|
2020-09-11 04:44:25 -05:00
|
|
|
svt \
|
|
|
|
|
svx \
|
sw: fix handling of table vs fly overlaps in the AddVerticalFlyOffsets case
When a table overlaps with a fly frame, Writer creates a fly portion
inside the relevant cell frame (increasing its height), and Word shifts
the table down. Both are valid approaches, but the rendering result is
different in case the table has a border.
So keep the default unchanged, but in case the AddVerticalFlyOffsets
compat flag (set by the Word importers) is set, avoid the overlap the
Word way.
Note that the table frame uses the full width (available in the body)
even for e.g. 50% width tables, so check for the overlap using the print
area, which does not always overlap.
Finally, don't always require a valid frame area definition from the fly
frame:
- the mentioned i#46807 bugdoc currently doesn't need that check
- the fly frame area definition becomes valid only after already
positioning the table, leading to an overlap
Keep that check for the non-compat case, though.
Change-Id: I9202050befebf2efdbb5395ded6fcb52b378d8e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88724
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
2020-02-14 09:29:44 -06:00
|
|
|
))
|
|
|
|
|
|
|
|
|
|
$(eval $(call gb_CppunitTest_use_more_fonts,sw_core_layout))
|
|
|
|
|
|
|
|
|
|
# vim: set noet sw=4 ts=4:
|
