I worked on this mainly to see what the impact of the
docx changes would be on RTF.
It seemed to be OK. This patch shows that RTF
can now import gradient page backgrounds.
It does NOT import image backgrounds
(at least no the ones I tested)
because they were specified as
XML_sn: fillBlip
XML_sv: <shape_as_text_string>
which is an unknown property in RTFSdrImport::resolve.
The only fill type that RTFSdrImport::resolve knows about
is XML_gradient.
The only existing unit test I noted was
page-background.rtf
Change-Id: Ie40b91468d21b29a102472c859cd1eecfcb2a5f7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163199
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Commit 963de9feb3 "sw: fix issue with
copying stashed frame format" fixed the actual bug here, but introduced
a new memory leak.
This causes an assert in CppunitTest_uiwriter3:
cppunittester: svl/source/items/itempool.cxx:779: void SfxItemPool::Remove(const SfxPoolItem&): Assertion `rItem.GetRefCount() && "RefCount == 0, Remove impossible"' failed.
The assert happens only when this is backported to the libreoffice-7-6
branch, because commit ab7c81f556 "ITEM:
Get away from classic 'poolable' Item flag" removed the assert.
The problem is that a SwFormatFrameSize inside a footer SwFrameFormat is
leaked 4 times, because 4 SwFrameFormats are leaked; the leak is that
SwDoc::CopyPageDesc() creates a new pNewFormat, passed it to
StashFrameFormat(), which copies it but doesn't free it.
There is also a usage of std::shared_ptr here that is very questionable;
SwFrameFormat should never be shared between different SwPageDesc.
(regression from commit b802ab694a)
Change-Id: I44133bc5e6789a51ce064f1aa5ea8b325224365b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163854
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
because when the dynamic symbol lookup fails, the dummy factory
returns nullptrs to code expecting valid pointers, and end up with
a much harder bug to diagnose, instead of failing at the actual
problem site.
Change-Id: I8e4885dc192b7089e1b1716567b41420309e8984
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163853
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
When using various Japanese input methods, the last event will be a
repeating key down event with a single delete character while the
Backspace key, Delete key, or Fn-Delete keys are pressed. These key
events are now ignored since setting mbTextInputWantsNonRepeatKeyDown
to YES for these events will trigger an assert or crash when saving a
.docx document.
Change-Id: If3762fcf41aa82bf4aa5dc7d1f15c1d282c86f99
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163875
Tested-by: Jenkins
Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
...that was present in instdir/share/registry/res/registry_en-US.xcd but for
which the underlying instdir/share/registry/*.xcd files are not included in
static/CustomTarget_emscripten_fs_image.mk, so causing
> warn:configmgr:42:1:configmgr/source/xcuparser.cxx:292: unknown component "org.openoffice.Office.PresentationMinimizer" in "file:///instdir/program/../share/registry/res/registry_en-US.xcd"
etc. in the browser console. (This commit just hides those .xcu behind
ENABLE_WASM_STRIP_* for which localizations ended up in
instdir/share/registry/res/registry_en-US.xcd and caused the above warnings. It
does not clean up the mess further. Also note that the list of files to include
in static/CustomTarget_emscripten_fs_image.mk is largely hard-coded, so somewhat
guessing at the right ENABLE_WASM_STRIP_* to use here.)
Change-Id: I1781f5cb530fe251e63bcad456c2ab1735cf1b3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163852
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...for which the underlying .xcd files are not included in
static/CustomTarget_emscripten_fs_image.mk, so causing
> warn:configmgr:42:1:configmgr/source/xcuparser.cxx:904: ignoring modify of unknown set member node "StarOffice XML (Base)" in "file:///instdir/program/../share/registry/res/fcfg_langpack_en-US.xcd"
etc. in the browser console. (Though note that the list of files to include in
static/CustomTarget_emscripten_fs_image.mk is largely hard-coded, so somewhat
guessing at the right ENABLE_WASM_STRIP_* to use here.)
Change-Id: If3d506514ccdbacb7e64cf62b08093831640c572
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163829
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
and stop an automatic 180 reversal on import.
Some documents had gradient reversals on every round trip,
typically when the angle was 0-179
(mainly seen in ODT examples,
since DOCX/RTF imports defaulted to be angle 180).
The negative sign has special meaning,
indicating that the start and end colors
should be swapped.
Well, swapping colors was not intentional in the export logic.
Previously there was a mistaken idea
that any angles > 180 needed to be swapped on import,
and likely that is what prompted this overly complicated formula
to try to avoid any angle > 180 during export
by allowing negative angles.
This tdf#126533 patchset has already eliminated import checks
for angles > 180, so now a sane formula can be applied on export.
In order to do that, we have to avoid emulating color swaps
with 180 degree rotations at import time.
So ONLY do color swapping with start/end,
and leave the angle alone.
That GREATLY helps unit tests (which otherwise would flip-flop
the angle and the color start/stop).
Very unhelpful was an undocumented, indecipherable
inversion when converting to DML angle.
Boy, I hope I got this right...
make CppunitTest_sw_rtfexport8 \
CPPUNIT_TEST_NAME=testTdf159824_gradientAngle3
make CppunitTest_sw_rtfexport8 \
CPPUNIT_TEST_NAME=testTdf159824_gradientAngle4
make CppunitTest_sw_ooxmlexport7 \
CPPUNIT_TEST_NAME=testTdf126533_axialAngle2
Eliminating the inversion for ooxml7 test is fine
since inversion does nothing to an axial.
Otherwise, eliminating inversions corresponds to a color swap.
Change-Id: I2aae0a7595807569ffc740689ff3840692d6159d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163798
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
The fillAngle is important for obvious visual reasons,
but also significantly because a negative angle
means that the start/end colors should be swapped
(which is the normal case since
LO's 0 degree angle == -180 VML/RTF angle).
There were no existing unit tests with a "fillAngle" specified,
or with a non-180 angle (0 VML/RTF angle) in LO.
make CppunitTest_sw_rtfexport8 \
CPPUNIT_TEST_NAME=testTdf159824_gradientAngle1
make CppunitTest_sw_rtfexport8 \
CPPUNIT_TEST_NAME=testTdf159824_gradientAngle2
make CppunitTest_sw_rtfexport8 \
CPPUNIT_TEST_NAME=testTdf159824_axialGradient
Change-Id: I4bb2c47bd2a79833d11bedac72ba2152b65b7c73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163714
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
...from 86f4727920, as all the platforms define
gb_UnoApiHeadersTarget_select_variant in effectively the same way, anyway. (And
whether or not any of this actually makes any sense the way it is currently
done.)
Change-Id: I3b53ed3ee58b1115da31839aba5b2852dfe40920
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163826
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
When the typelib_TypeDescription is null, the following code would dereference a
null pointer anyway (but which doesn't necessarily cause an immediate crash on
some platforms like Wasm, so better be explicit). (Also, leave those checks out
of functions like uno_type_sequence_realloc, which would have been preceded by a
call to one of the functions creating a sequence of the given type, and which
would thus already have detected failure to obtain the relevant type
information.)
Change-Id: I36193ea837edeca451fd09a866623cf40d3cdb4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163813
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
They were dropped in 69943f33bf
"tdf#124591: Update Noto Sans to v2.012" and
96aba2de78
"tdf#124591: Update Noto Serif to v2.012"
for no apparent reason.
Re-add them since they are still available upstream
Change-Id: Ifd5eb72bd95be96f2ff965b17846cf76aacb0c7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163825
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* Update helpcontent2 from branch 'master'
to a7bbc45948d6e0e6f5ba22aa38d2587e1f4053fe
- tdf#159476 Basic IDE options are out of experimental
Change-Id: Icf6b9ff6f4cf09a185b461ba93123f0ef0dc1d61
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/163765
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
Saves the paper tray id as w:paperSrc w:first and w:other in docx
and \binfsxn and \binsxn in RTF
Change-Id: I79004f54aba3b6609d7921afacf815726f7f2678
Change-Id: Ie3c11fffa6a133250b7db69b4e845bccaa8e2280
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163654
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Remove hardcoded out-of-queue message for MessageDialog.
Now we send the messages in JSMessageDialog::run().
This prevents us from overwriting correct jsdialog window
in Online when we see messages before document was loaded
(from interaction handlers, like: macro warning, corrupted
file, etc.)
Change-Id: I364ac8460507dd6613b978230c9cf61cc5dfe91d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163679
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
(cherry picked from commit 5ee46b44d207a0416623a5c506bb2052052500a7)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163767
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
climaker_app.o : /DEBUG:FASTLINK is not supported when managed code is present; restarting link with /DEBUG:FULL
Change-Id: Ia4c8ef862999650b317629273996166908232494
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163804
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This partially reverts commit 133610669b
(windows: silence new warning for now, 2016-02-21). That commit had
disabled warnings introduced after VS 2013 (compiler major version 18).
For now, it was impossible to remove the -Wv:18 from CLR flags. Also,
some warnings in Boost were suppressed in vcl/source/window/layout.cxx:
C:\lo\build\workdir\UnpackedTarball\boost\boost/multi_array/multi_array_ref.hpp(615): error C2220: the following warning is treated as an error
C:\lo\build\workdir\UnpackedTarball\boost\boost/multi_array/multi_array_ref.hpp(615): warning C4459: declaration of 'extents' hides global declaration
C:\lo\build\workdir\UnpackedTarball\boost\boost/multi_array/base.hpp(69): note: see declaration of 'boost::`anonymous-namespace'::extents'
C:\lo\build\workdir\UnpackedTarball\boost\boost/multi_array/multi_array_ref.hpp(612): note: while compiling class template member function 'boost::multi_array_ref<T,2>::multi_array_ref(T *,const boost::general_storage_order<2> &,const __int64 *,const unsigned __int64 *)'
with
[
T=`anonymous-namespace'::GridEntry
]
C:\lo\build\workdir\UnpackedTarball\boost\boost/multi_array.hpp(153): note: see reference to function template instantiation 'boost::multi_array_ref<T,2>::multi_array_ref(T *,const boost::general_storage_order<2> &,const __int64 *,const unsigned __int64 *)' being compiled
with
[
T=`anonymous-namespace'::GridEntry
]
C:\lo\build\workdir\UnpackedTarball\boost\boost/multi_array.hpp(122): note: see reference to class template instantiation 'boost::multi_array_ref<T,2>' being compiled
with
[
T=`anonymous-namespace'::GridEntry
]
C:/lo/core/vcl/source/window/layout.cxx(905): note: see reference to class template instantiation 'boost::multi_array<`anonymous-namespace'::GridEntry,2,std::allocator<T>>' being compiled
with
[
T=`anonymous-namespace'::GridEntry
]
Change-Id: Ibf89e3d3e5a2f6a747bb7fbd214a9b27d8068901
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163717
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This fixes alg's 7.6 regression from
commit bb19817668
Found when trying to import these strung-out-linears
as real axials.
make CppunitTest_sw_rtfexport \
CPPUNIT_TEST_NAME=testTdf159824_axialGradient
Change-Id: I220f1bf689b4b219bc0ae187e95aedb1a29a7233
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163705
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
This is a follow-up from the earlier tdf#65295 clone
which removed swapping colors on IMport for axials.
Well, tdf#65295 had also removed EXport swap for the linear case,
so, now that import doesn't swap, remove the axial export swap too.
Additionally, some linear gradients are actually axials,
so identify those symmetrical gradients that have
identical start/end colors to avoid exporting as a "solid" color.
[I tried changing the import to detect it was an axial,
but got RTF export failures, chart2 false positives,
and unit-test-the-implementation failures.]
make CppunitTest_sw_ooxmlexport7 \
CPPUNIT_TEST_NAME=testTdf126533_negativeAxialAngle
The only other unit test that hit this code was
textframe-gradient.docx - which is dominated by DML import/export.
I can see with Word 2003 that this patch fixes the VML export
for this unit test file also.
Change-Id: I75e993c7c127a861617b14072a98778ddde03a08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163676
Tested-by: Justin Luth <jluth@mail.com>
Reviewed-by: Justin Luth <jluth@mail.com>
... for everything except the linear gradients (linear/axial)
Interestingly, there was nothing in make sw.check that hit this.
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf126533_pageGradient
Change-Id: Id58ed8b312ec29a10ce461ff0e032838b745b11b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163470
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Simplistic export of gradient fill.
I just used the existing docxattribute stuff that textboxes
use to export their background as VML fallback.
Note that docxattribute only knows how to export gradient,
not gradientRadial. (Done in follow-up patch.)
Lots of stuff is missing in terms properly supporting gradients.
But likely fixing page background will fix
the same problem in textboxes etc.
Given how incredibly different LO and MSO are in terms of gradients,
it makes sense to commit this change and at least get the basics
wired in.
make CppunitTest_sw_ooxmlexport21 \
CPPUNIT_TEST_NAME=testTdf126533_pageGradient
Change-Id: I2ac14fdef2fe29609bc8d5a5d8f65b3f0da71889
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163469
Reviewed-by: Justin Luth <jluth@mail.com>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
tdf#65295 already fixed one case
by removing the test for degrees > 180
for the linear-equivalent gradients.
Unfortunately the comment wasn't also removed,
so that was confusing: removed comment.
The test for degrees > 180 is not needed
for the axial-equivalent case either: removed.
The reason for that degrees > 180 case is likely due to
negative degrees, which is a documented reason
for swapping the colors: added swap if negative degrees.
All the affected, existing unit tests are improved now:
-tdf81345.docx: famous MS example: improved header gradient
-fdo78300.docx: fontworks: hard to tell without MCGR...
make CppunitTest_sw_ooxmlexport7 \
CPPUNIT_TEST_NAME=testTdf126533_negativeAxialAngle
make CppunitTest_sw_ooxmlexport7 \
CPPUNIT_TEST_NAME=testTdf77219_backgroundShape
Change-Id: I9f4d56375bb2cec28ffbd93df419d586da465b78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163417
Tested-by: Jenkins
Reviewed-by: Justin Luth <jluth@mail.com>
Regression from commit c303981cfd
(tdf#156724 sw: layout: fix tables not splitting due to footnotes
differently, 2023-08-24), the floating table in the DOCX version of the
bugdoc went from page 1 to page 2.
It seems what happens is that the first page has 2 section frames, and
we used to directly recalc the last lower of the first section frame,
which triggered a recalc of the second section frame, so the table moved
from page 2 to page 1 once the top of the second section frame was
reduced (so the table could fit on page 1). But this direct recalc was
removed because it caused problems for split tables and footnotes in
tdf#156724.
Fix the problem by conditionally restoring the OptCalc() call in
SwLayAction::FormatLayout(): only do it for the last lower of section
frames, which is enough for the DOCX version of tdf#158986, but it keeps
the old tdf#156724 use-case working (the layout of that bugdoc doesn't
modify with this change).
The RTF version of the bugdoc (which was the originally reported
problem) still needs more work, but that's hopefully not a layout
problem but an RTF import one.
Change-Id: I1134ec3a27aec8ee871b535d81dedf9d27bd6bd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163805
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
`offset` is unsigned int, so can't be negative,
causing an `--enable-werror --enable-gtk4` GCC 13.2
build on Debian testing to fail like this:
.../libreoffice-WORKTREE/vcl/unx/gtk4/gtkaccessibletext.cxx: In function ‘GBytes* lo_accessible_text_get_contents_at(GtkAccessibleText*, unsigned int, GtkAccessibleTextGranularity, unsigned int*, unsigned int*)’:
.../libreoffice-WORKTREE/vcl/unx/gtk4/gtkaccessibletext.cxx:79:16: error: comparison of unsigned expression in ‘< 0’ is always false [-Werror=type-limits]
79 | if (offset < 0 || offset > o3tl::make_unsigned(xText->getCharacterCount()))
| ~~~~~~~^~~
cc1plus: all warnings being treated as errors
Change-Id: Ib5a67c9d5948802fe269275c79f624df09712011
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163802
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Noel Grandin