summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-02-28Fold InternalUnoApi_embindtest into UnoApi_udkapiStephan Bergmann
80d3f33876a2ad4ce32d3c6183131984e8c6b5da "Library_embindtest should use comprehensive InternalUnoApi_embindtest" was an attempt at making type information about that library available at runtime. Which worked for cases where code directly called one of the types' cppu_detail_getUnoType function. But it would still fail for cases where code indirectly wants to obtain one of the types' information by type name---which is what upcoming code will do that changes the Embind'ing of UNO sequences. So InternalUnoApi_embindtest would need to become a UnoApi_embindtest whose instdir/program/types/embindtest.rdb would be available at runtime. But I'm too dumb to convince gbuild to create that new UnoApi_embindtest. So instead just tack the embindtest UNOIDL entities onto the existing UnoApi_udkapi for the EMSCRIPTEN-ENABLE_DBGUTIL case. (Which requires that the single embindtest.idl is split into individual per-entity files, sigh.) Change-Id: Ie189b17213ac5b2de7a61ac5f97a143fa097337f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164057 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-28tdf#149714 BitsPerPixel property of Graphic has Boolean UNO typeAdam Seskunas
- vcl change UNO type of UnoGraphicProperty::BitsPerPixel to sal_Int8 instead of sal_uInt8 which maps to BOOLEAN causing Basic to convert non-0 values to True - basic add CppUnitTest since thats where the problem was occuring Change-Id: I0111199151fb5e001b6362e1359ad90bb039f064 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163899 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-28tdf#157135 workaround: restore and update windows-no-utf8-locales.patch.0Mike Kaganski
This partially reverts commit ed259e5efe432386b54c553cbc644b3b64976852 (Upgrade external/boost to latest Boost 1.81.0, 2023-01-05), which had dropped the patch previously introduced with commit f046fed2782f0d4244aff719ba70a56399a2583a (Don't ever attempt to initialise a std::locale with a UTF-8 locale on Windows, 2018-05-17). It seems that there is a nightmare going on in MSVCRT, and tdf#157135 is caused by dome MS bug. The problem happens in a deeply nested call to mbstowcs_s (several levels deep from std::locale constructor with name of "en_US.UTF-8"), which gets a non-null wcstr and sizeInWords equal to zero, which generates an invalid argument handler, resulting in a failed assertion "(pwcs == nullptr && sizeInWords == 0) || (pwcs != nullptr && sizeInWords > 0)" in _mbstowcs_internal from minkernel\crts\ucrt\src\appcrt\convert\mbstowcs.cpp:245, and a crash. The crashreporter initiates, but since it tries to use CRT itself, which is in fastfail mode, it hangs. The patch that is restored here was intended for something different; but it happily workarounds the nightmare. Until the proper fix found, let it be. Change-Id: Ic978f87e2e7b81fc2e1cd182a4247084ad016a9f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164068 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-28tdf#159927 unit test for impress date/time language detectionJustin Luth
make -srj1 UITest_impress_tests \ UITEST_TEST_NAME="tdf159927_dateTime.tdf159927.test_tdf159927" \ SAL_USE_VCLPLUGIN=gen Change-Id: Ic0f13fd7f7f427cc85f8f7c4d144ecfb5b722291 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164070 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-02-28Make the code tidier & stop event handling during destructionKohei Yoshida
This is a follow-up to 25ffb54c6d8a5b52dca6b782282962766e7791de. Change-Id: Ifc87323dd5085cdac08efac5fd9d22ae8b94d641 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163997 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2024-02-28tdf#159927 sd headerfooterdlg: detect existing date/time languageJustin Luth
Sometimes it was hard to change an existing foreign language to your own language for Impress' header/footer fields. The function was only checking the first master slide for the date/time language. If it didn't have one, then the default locale was selected. However, although all pages share the same date/time language, it is not necessary for all (or even the first) master slide to have a date/time field. So check through all the master slides until one with a date/time is found. Obviously if none have one defined things still work OK, because that is effectively how it was working beforehand. I don't have much hope for a successful unit test. I'll try to develop it as a follow-up to this patch. Change-Id: Ida44957013978720ad12fadc9b4ebc88bc10ea40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164045 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-02-27Add python code for ChartInCalczeph
Change-Id: Ia7f4cbd539919e88f735c13bdd1dae3533b1163a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163037 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2024-02-27tdf#42982 Improve UNO API error reportingAhmedHamed
Change-Id: Ia27365b3e5539cdf0f96f01a96bbe58653eb46c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163788 Reviewed-by: Hossein <hossein@libreoffice.org> Tested-by: Jenkins
2024-02-27Fix typoAndrea Gelmini
Change-Id: I53e801cd4688c8495deecfb7a67a4ce39bdda978 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164054 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-02-27ofz#67046 fix build failureCaolán McNamara
Change-Id: I8f48bf930f20d19a8b20e7e3ae825923bc014c31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164052 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-27save a few bytes per columnCaolán McNamara
Change-Id: Ia0f6dfdf671703476b9b068d1dbe9076689d0690 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164032 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-27address shortcoming: document why I avoided axials for transparencyJustin Luth
Hmm, I like to complain when other people don't comment on why certain situations are excluded, and yet I did the same thing here. Thanks vmiklos for pointing that out. Change-Id: I4c5ddeaeee078f036fc31149fc29bc6acb277ab3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164040 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com>
2024-02-27tdf#159910 sw a11y: Set a11y names for Navigator itemsMichael Weghorn
Set accessible names for the items (mostly toolbar items) in the Navigator. This makes the Orca screen reader with the gtk3 VCL plugin announce these as expected when they receive focus. For now, take over the existing tooltip text for the accessible name. This can be further tweaked if necessary. With the previous commit Change-Id: I45b87839dda90083ceba1c43fdb4d4ec460fce3d Author: Michael Weghorn <m.weghorn@posteo.de> Date: Tue Feb 27 13:12:43 2024 +0100 tdf#159910 a11y VclBuilder: Apply tool item's a11y name to itself , these a11y names are now also used for the VCL implementation (s. `VCLXAccessibleToolBoxItem::implGetAccessibleName`). The accessible name there remains the same for now, as the previous fallback was the tooltip name, which at least currently still has the same text. It seems reasonable to align the gtk3 and VCL implementation more with each other and support the default mechanism of explicitly setting an accessible name on the corresponding widget in the .ui file. Change-Id: I852503e849651bb7be4daa419ec2379568623f0f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164035 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-02-27tdf#159910 a11y VclBuilder: Apply tool item's a11y name to itselfMichael Weghorn
For the VCL `ToolBox` implementation of a toolbar, the items are not represented by own widgets (`vcl::Window`s), but handled by the `ToolBox`. As a consequence, the `vcl::Window` passed to `VclBuilder::applyAtkProperties` cannot be the tool item itself (e.g. a `GtkToolButton` in the .ui file), but is the `ToolBox`, i.e. the (VCL builder implementation of the `GtkToolbar` parent widget in the .ui file). So far, the ATK properties set for the tool item were just applied to the parent instead. For example, with the upcoming Change-Id: I852503e849651bb7be4daa419ec2379568623f0f Author: Michael Weghorn <m.weghorn@posteo.de> Date: Tue Feb 27 11:51:55 2024 +0100 tdf#159910 sw a11y: Set a11y names for Navigator items , this would result in the toolbars getting the name of their last item (one of the toolbars in the Navigator would get the a11y name "Show Up to Outline Level") and the toolbar items would only have an a11y name set because they still fall back to the tooltip text for the a11y name. Adjust that to set the accessible name for the actual toolbar item when a toolbar item is processed. (Add a bool param to indicate that). See also `VclBuilder::applyPackingProperty` which already had a similar way to determine and handle that case. With this in place, the accessible name set in the .ui file is now applied to the toolbar item as expected. (The accessible description could be handled similarly, but I'm a bit more hesitant to add that right away because the accessible description is currently also used for the extended tooltip text and the NVDA screen reader on Windows announces the description in addition to the name by default.) Change-Id: I45b87839dda90083ceba1c43fdb4d4ec460fce3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164034 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-02-27tdf#159910 vcl a11y: Allow explicitly setting toolbar item a11y nameMichael Weghorn
Add `ToolBox::SetAccessibleName` (and corresponding getter) to allow explicitly setting an accessible name for a toolbox/toolbar item with the VCL toolbar implementation. In the a11y class for a toolbar item, use any explicitly set name if it's non-empty, otherwise fall back to the previous logic. This will be used in an upcoming commit to take into account the accessible name set in .ui files and align the VCL ToolBox more with the gtk implementation using native GtkToolbar and native widgets for the toolbar items. Change-Id: Ib0255e2741a7ab2489a857ac120fb87f680fa775 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164033 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-02-27Fix typoAndrea Gelmini
Change-Id: I30bd7ed93eedf241fde23b35ac674d010c9e6575 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164043 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-02-27Fix UBSan build's RTTI needsStephan Bergmann
...after 3ba92b5f1eaf7d4447a0943ea260db515ca799dc "hide more symbols" had caused CppunitTest_sw_uiwriter to fail with > DynamicLibraryManagerException: "Failed to load dynamic library: workdir/LinkTarget/CppunitTest/libtest_sw_uiwriter.so > workdir/LinkTarget/CppunitTest/libtest_sw_uiwriter.so: undefined symbol: _ZTIN2sw11UndoManagerE" Change-Id: Ia17fd3c9d8f4e227cdd9ca3a5aa6f94f51c46168 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164028 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-27Online: Prevent hiding tooltips due to other users action.Gülşah Köse
Other user's actions like reloading reopening or refreshing document causes hiding other user function tooltips. Signed-off-by: Gülşah Köse <gulsah.kose@collabora.com> Change-Id: I0aeb0aeb98182398e4740c71cfd65c4df2c51ba6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164027 Tested-by: Jenkins
2024-02-27lok: don't hide tooltim on every actionSzymon Kłos
Signed-off-by: Szymon Kłos <szymon.klos@collabora.com> Change-Id: I62f69071a4857f7413a995da1ff9fc6ba2f942d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163977 Tested-by: Jenkins Reviewed-by: Gülşah Köse <gulsah.kose@collabora.com>
2024-02-27Simplify a bitMike Kaganski
Change-Id: Ib13dab2b57a5ca0d477783887c637d4cabbebcf7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164029 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-27tdf#141728 follow up: don't expand spin control when sidebar is resizedJim Raykowski
Change-Id: I9b231fd67f089e6fcd02329e255e22152e3ed3f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164003 Tested-by: Jenkins Reviewed-by: Vernon, Stuart Foote <vsfoote@libreoffice.org> Reviewed-by: Jim Raykowski <raykowj@gmail.com>
2024-02-27remove hsqldb from mergedlibsNoel Grandin
regression from commit ae17922b7d0f797129dd5fbd5514d691ac9ebeaa Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Wed Feb 14 09:33:05 2024 +0200 add more libs into --enable-mergelibs=more build sberg is seeing This breaks e.g. dbaccess_hsqldb_test with java.lang.UnsatisfiedLinkError: java.lang.UnsatisfiedLinkError: likely because the jar file is trying to load libhsqldb.so instead of libmerged.so Change-Id: I9f42aea6471dbe35b27a584465b333a1d30caf5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164022 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-27GPGME: upgrade to release 1.23.2Taichi Haradaguchi
Change-Id: I56c419fbbe615ef57b7d8117ccdc32f0daddf95f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163840 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-02-27cid#1592377 Uncaught exceptionCaolán McNamara
Change-Id: I61320896ddeeabed9f21798919bac0e0fecf32e5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164015 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-27related tdf#33603: do not register NotesChildWindow for DrawSarper Akdemir
Draw doesn't need the notes panel introduced in c4c1ca58bb587a56a30c7f4817c346054ce37f2a, so don't register that for it's shell (GraphicViewShell). Change-Id: I062a54e806058f352721b89d7cffff10cece8612 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163775 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-02-27cid#1592378 Logically dead codeCaolán McNamara
Change-Id: I4cab1e22f61113dd84b9ce77c639be5572ff9c77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164014 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-27cid#1592379 Logically dead codeCaolán McNamara
Change-Id: I99de3457d0775da860ca8b1727a3ed120a2b28ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164013 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-27cid#1592375 COPY_INSTEAD_OF_MOVECaolán McNamara
Change-Id: I9d110911504832d7a8a6725ca3f9040a4fd0c4c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164010 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-27android-viewer translated using WeblateWeblate
Czech currently translated at 54.2% (64 of 118 strings) Change-Id: Ie43869edb7fffb61603b1a00cf3d2d01397c634e Co-authored-by: raal <raal@post.cz> Translate-URL: https://translations.documentfoundation.org/projects/android-viewer/android-strings/cs/ Translation: android-viewer/android-strings Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163900 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-02-27cid#1592381 silence Out-of-bounds readCaolán McNamara
Change-Id: I437af59b956753eaadea61db12500e5e7b45d9b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164008 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-27cid#1592376 Uninitialized scalar fieldCaolán McNamara
Change-Id: I8f62faac5a1170b9932afe08f03145e4ca7b1be1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164009 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-27Simplify a bitMike Kaganski
Change-Id: Id9640825e117531ed1b67db9e83349c556f291c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164004 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-27Typo: alredy->alreadyJulien Nabet
Change-Id: I67fa846c71cf91563c3457cec98195b1886e3fa9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164025 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-02-27cid#1592380 COPY_PASTE_ERRORJulien Nabet
Change-Id: Ib5c57ba2118531449908600b22fd49f52277159b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164005 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-02-27tdf#158190 Fix Calc ROUND in floating-point calculate result very close to X.5Po-Yen Huang
Location: if (nDecPlaces == 0) { switch (eMode) { case rtl_math_RoundingMode_Corrected: return std::round(fValue); Because the functions are the same as the following related codes, they are respectively: if (nDecPlaces >= 0 && (fValue >= 0x1p52 || isRepresentableInteger(fValue))) return fOrigValue; as well as: if (fValue < 0x1p52) { switch(eMode) { case rtl_math_RoundingMode_Corrected: fValue = rtl::math::approxFloor(fValue + 0.5); break; : : : Because some double-precision floating point numbers cause std::round(fValue) and rtl::math::approxFloor(fValue + 0.5) to produce different results. For example, enter 10614.4999999999876 in Calc's A1 cell (or any operation that will produce a long decimal number such as .499999999999xyz after the decimal point). We expected it to be 10614.4999999999876, but it was automatically rounded to 10614.5 (note: this result is also the result of ubiquitous handheld computers, OpenOffice.org and Excel) Then, entering =ROUND(A1,0) in B1, we will see 10614, A1 and B1 clearly don't meet expectations. (My boss or tax collector might be unhappy :-p) Although A1's 10614.4999999999876 is still faithfully recorded, the rendering of 10614.5 is confusing. Now, there are two views: 1. According to the established convention, B2 displays the expected answer 10615. or 2. True to the laws of mathematics, A1 displays 10614.4999999999876 or at least 10614.49 Although the second point of view is correct (and I completely agree with it), when opening spreadsheets generated by other software (such as OpenOffice.org or Excel), the results will be different, which people do not like to see. So when nDecPlaces == 0 is removed, use std::round(fValue) and let the existing code below it do the rounding: if (fValue < 0x1p52) { switch(eMode) { case rtl_math_RoundingMode_Corrected: fValue = rtl::math::approxFloor(fValue + 0.5); This is consistent with the first point. By the way, in nDecPlaces == 0 case rtl_math_RoundingMode_HalfEven: This piece of code can be checked to see if it is really necessary, because rtl_math_round() also has the same purpose code. If it is not needed, the entire nDecPlaces == 0 can be removed. Co-authored-by: Firefly <firefly@ossii.com.tw> Co-authored-by: Franklin Weng <franklin@goodhorse.idv.tw> Change-Id: If32cdb18c70ec0025c83ba25a99e5d135d66aec9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159193 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-27Check Windows SDK versionHossein
Because of a regression in Windows SDK version 10.0.19xxxx which is now fixed in 10.0.20348, it is good to check that the required SDK version is installed: More information https://developercommunity.visualstudio.com/t/std:c17-generates-warning-compiling-Win/1249671 It is important to know that both Windows 10 and Windows 11 SDK should work. Change-Id: Ia42843cac4f94c4db9ef429714f1b9d46ba3fd09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163770 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-27tdf#159908: return early to avoid nullptr dereferenceMike Kaganski
When aLvalue is not a variable, its GetRealVar() returns nullptr. That was dereferenced unconditionally later in the check of the variable after NEXT. Change-Id: Ia46f23a7e720431bf62ace998848b684aa8449e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164002 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-27tdf#67347 pptx import: stacked + horz/vert aligmentAttila Szűcs
In case of Stacked, PP calculates in the vertical direction with the horizontal alignment. We simulate it by setting TextVerticalAdjust at import time (from PPTX) based on the ParagraphAdjust of the 1. paragraph It is not perfect, because we have 1 TextVerticalAdjust / 1 shape, and it does not support justified, while we can have many ParagraphAdjust / 1 shape (if the shape have more paragraphs) For a better solution we should re-implement the entire stacked thing, but that is a much bigger task. Change-Id: I4011be0f118b870ab7f9e2ddc15c6dc5a21f8a89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163934 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Attila Szűcs <attila.szucs@collabora.com>
2024-02-27Related: tdf#150408 DOC filter: handle legal numberingMiklos Vajna
The bugdoc's 2nd para started with 'Sect I.01', while Word rendered this as 'Sect 1.01'. The reason for this difference is that there is an "is legal" boolean property on the numbering that we ignored from [MS-DOC] during import/export. Fix the problem by WW8ListManager::ReadLVL() and WW8AttributeOutput::NumberingLevel() to handle this, building on top of the existing DOCX work. RTF still needs doing. Change-Id: I57ec402c1dd829251afa639ddfa7fc6620da1125 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164000 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-02-27use getCommandValues instead of adding a getViewRenderStateCaolán McNamara
Change-Id: Ib6db5dd8ef1db2745cb3c616bb81b1ac2baf6504 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163812 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163931 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-02-27Fix typoAndrea Gelmini
Change-Id: I48f1487f11ba35b61327b148d51f8ecb4f36b78e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163992 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-02-27Fix typoAndrea Gelmini
Change-Id: Id1e21804fb2bc93887892192e38b655c8654ed7e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163991 Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp> Tested-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-02-27sw: document SwFormatEditInReadonlyMiklos Vajna
What it is, which item set can contain it, where is the UI. Change-Id: I470b057418c551da78b174dd02a22206a18dd03f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163999 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2024-02-27address nit: use boolean flag instead of minor copy/pasteJustin Luth
Change-Id: I380ca73047fecefd9b7ff508eb6f8bf8202b1b62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163969 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-27address nit: use oox::drawingml::PER_DEGREE instead of 60,000Justin Luth
Change-Id: Ie3ca5a76376a3c26f0d3079b6e819ec29afd2c17 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163968 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-27address nit: create separate WriteDocumentBackgroundFill functionJustin Luth
Change-Id: I4e204dfee51987112f1a4a4a052a11349ae3f373 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163966 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-27related tdf#126533 dml/vml import: import radials as radialsJustin Luth
... and not as symmetrical linear gradients. The benefit is that our export code will be able to intelligently export it. Apparently RTF export code does not intelligently export axials, (now fixed - tdf#159824) but VML and DML (and doc) do it well. Unfortunately charts can be badly affected, (avoided by ignoring when transparent) and unit tests are implementation-tested... This affects existing unit tests: -tdf128345_Legend_CS_TG_axial.pptx: label imports fine: lost on export (no change) -tdf128345_ChartWall_CS_TG.pptx: wall gradient now looks axial: lost on export (no change) -textframe-gradient.docx: still round-trips OK: no change -textframe-gradient.rtf: round-trips as linear: lost axial-ness (now fixed: tdf#159824) -fdo78663.docx: textbox font fill: still exports as solid: no change I ran the assert check against chart2, oox, and sw Change-Id: Ib16e9488a76b006bf335ff01a38acf7cde69cccb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163675 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-27Remove unused gb_CppunitTest_localized_runStephan Bergmann
...that appears to be unused ever since it got introduced in d8a8ed04b14390d4469ea19b079778fa6f074bb2 "gbuild allow unitest to run once per lang in WITH_LANG_LIST" Change-Id: Id43b8498ca68c274902dfb3dfd4b035e199cb9b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163993 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-27tdf#145538 Use range based for loopsAhmedHamed
Change-Id: I62ed915f3ac398ffdffb0a47e40ce23f0a893b3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163885 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2024-02-27Make ScColumn::HasCellNotes() less expensiveKohei Yoshida
It's essentially the same idea as checking if the column has formula cells; by keeping track of the block creation and deletion events to count the number of cell notes block instances at any given moment, and use that information to see if the column has any cell notes. Change-Id: I95c5186bf1f21f23f85fa10ff3c2135388949c72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163996 Tested-by: Kohei Yoshida <kohei@libreoffice.org> Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
generated by cgit (git 2.34.1) at 2025-01-11 00:42:37 +0000