Age | Commit message (Collapse) | Author |
|
* Update helpcontent2 from branch 'master'
to 42b1b45509ab2fa2de686f248781468e09d3f9d8
- Use max-width in YouTube placeholder style
Change-Id: I8acaa11f8d8c11f5034cea7c4dfc247cee90d487
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/129857
Tested-by: Jenkins
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
Change-Id: I53add0bbb14e084978e3582083978924d1c11c88
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129434
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
* Update helpcontent2 from branch 'master'
to 3994c9e899323a85d4db4f9264f5dda8aae5b92b
- tdf#146847 (\) Integer Division operator help page
Change-Id: I43e82fd2038a8f557c1fcefebd1beadb2bda7184
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/129432
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Previously a long label wouldn't be broken into multiple lines
and be limited to the axis size if the chart sizing was automatic.
This would cause the label to distort the whole chart and make the
chart area very narrow. With this change the label text is limited
to the axis width and gets broken into multiple lines if this is
necessary.
BarChartVeryLongLabel.odp provides a test document which includes
automatic size and fixed size chart are. We make sure the area
that the label text occupies is not larger than the chart wall
size.
Change-Id: If58bfa3e51ab68f720f22df5416ae305401bcd34
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129814
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
If the label text is too long on a fixed size chart area, crop it
as we can't resize the chart area to accomodate for text breaking
into multiple lines.
The algorithm to determine if cropping is needed has assumed that
we need this in case the x-axis label is vertical, so there was
no check to actually make sure the text is horizontal or vertical
and in case it was horizontal, it has taken height into account
and not width, so nothing got cropped.
Change-Id: I8e73027fc51722280418c9e0be34ce487c41171e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129813
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
In the desktop case, the drag over and drag drop events are
handled external like GTK framework. In tiled rendering case,
we do not have it, so handle the drag and drop events in the
cloned ImplLOKHandleMouseEvent function.
Change-Id: Ib41232b3b9d5d6d859b2c965311b87af5d193ddd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118869
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117896
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
Regression from commit 17ec55c48082254e1f55bcfa00808e45a50a9801
("Fail on non-optional, but filtered component names").
Change-Id: Idab5b3dbf9658c03b0ec1af67d1d9b740111c6a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129849
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
The sw/ HTML export writes two <br>s for a <br> in the doc model at the
end of a paragraph, because the last <br> would be ignored by browsers.
But then the import ignores all <br>s at the end of paragraphs, so the
import and the export are not a 1:1 mapping; but at least the layout of
the exported HTML is close to the Writer layout.
ReqIF focuses on the preserving the semantics of the doc model instead:
it already doesn't open the document in "web view", and it's not
expected that the number of <br>s change on import or export.
Fix the problem by disabling both the import and the export tweaks in
the ReqIF case.
It would perhaps make sense to do this in general, but for users who
only care about the export layout (and never import the result again),
that would be probably a regression, so don't change this
unconditionally for now.
Change-Id: Iabd4a462185493c1ece0352069077e04c293816b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129820
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
Which is above the "normal" 1024 column limit. This tests my recent
commits.
Change-Id: I8ec3fcdbfef879ca0eeec4cfa3fa067378f6f57f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129823
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
The ScFiltersTest name was probably a copy&paste leftover.
Change-Id: I4b4e43e264fb5274fa4672f4db2ebbcb083e4e25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129822
Tested-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I286281c317c30e5c189747f2d4844a0d5dd0828f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129819
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
LIBREOFFICE-U78X8I5G
Change-Id: I436b4c13a4ce07f5e9e5d374163bc4de55cd2cde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129803
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
The drag starts it is only called when mouse down +
mouse move.
Change-Id: Ifadfd904c2be28bd123c17a47a82f49dd6d5a04a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118867
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117895
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
> C:\cygwin\home\tdf\lode\jenkins\workspace\lo_tb_master_win64_dbg\sc\inc\arraysumfunctor.hxx(75) : error C2220: the following warning is treated as an error
> C:\cygwin\home\tdf\lode\jenkins\workspace\lo_tb_master_win64_dbg\sc\inc\arraysumfunctor.hxx(75) : warning C4702: unreachable code
(<https://ci.libreoffice.org//job/lo_tb_master_win64_dbg/32859/>)
Change-Id: I27a66176717b293d60f98f82f06ec5ce7a28e6c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129812
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
* Update helpcontent2 from branch 'master'
to fbf1f624314ee83866d10c2b53741ac4c1d0e08f
- Document new properties/methods in SF_Platform and SF_FileSystem
This patch documents the Extensions property in SF_Platform and the new ExtensionFolder method in SF_FileSystem.
Change-Id: I4adca2d71ae9ac6d2f6a3dfc59d055e92b0ceb2d
Reviewed-on: https://gerrit.libreoffice.org/c/help/+/129757
Tested-by: Jenkins
Reviewed-by: Alain Romedenne
|
|
First, the integer function result is returned in a 64-bit register (RAX),
and truncation it to sal_Int32 breaks any pointer return value.
Second, using explicit (not vararg) first function double argument would
pass it through XMM0, without also copying it to RCX (which is guaranteed
for varargs).
Ref: https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention
Change-Id: I08212c44d8690d6910068b13c16af2ce899c94f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129808
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Jan 19 13:48:41 ip-172-31-35-149 coolwsd[23647]: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /home/collabora/online-buildscripts/staging/builddir/libreoffice/svx/source/sdr/contact/objectcontactofpageview.cxx:353:57 in
Jan 19 13:48:41 ip-172-31-35-149 coolwsd[23647]: /home/collabora/online-buildscripts/staging/builddir/libreoffice/include/svx/svdview.hxx:235:65: runtime error: member access within address 0x61c000489880 which does not point to an object of type 'SdrView'
Jan 19 13:48:41 ip-172-31-35-149 coolwsd[23647]: 0x61c000489880: note: object is of type 'SdrPaintView'
Jan 19 13:48:41 ip-172-31-35-149 coolwsd[23647]: 7c 04 80 3b 90 58 b9 3d 60 7f 00 00 30 51 96 0a 20 60 00 00 38 51 96 0a 20 60 00 00 38 51 96 0a
Jan 19 13:48:41 ip-172-31-35-149 coolwsd[23647]: ^~~~~~~~~~~~~~~~~~~~~~~
Jan 19 13:48:41 ip-172-31-35-149 coolwsd[23647]: vptr for 'SdrPaintView'
Change-Id: Ifc9177902ac834d400d6bf9f72b94e82f544b348
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129791
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
In tiled rendering case, the class GenericDragSource is
created by default, but it does not hold the transfer data
and it cancels the drag & drop.
Change-Id: Ib96f426a42e1fdae823e2412dc5280d70b59c44f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118866
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117894
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
For unknown reasons, this loops since commit
32902f66e7749b2d06d13f50416be5323a0c0ea9a
"sw_redlinehide: make layout based Show/Hide mode the default"
The problem is that when page 1 is layouted for the first time, it
splits into 6 pages, and then the SwTabFrame 47 decides that it wants
to move its follow flow line because it fits onto page 1.
Then splitting the SwTabFrame again fails, but for this
RemoveFollowFlowLine() was called a 2nd time and removed the one on
page 3.
The result is a layout with content on page 1, nothing on page 2, 3
and again content on page 4. This seems to reoccur every time page 1
is formatted.
But the first RemoveFollowFlowLine() was wrong because
CalcHeightOfFirstContentLine() returns 0 because
lcl_CalcHeightOfFirstContentLine() didn't handle the case of
SwSectionFrame containing SwTabFrame.
This is similar to commit e024cad7c1365da6a198656c3ca0c32b28938e87
doing the same thing for text frames in section.
Change-Id: I23fb4d1d56622039f461bb2d357a9c88db140605
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129800
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I045f301083767fa32fd516a4a46823b3af4a6a2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129794
Tested-by: Jenkins
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
so we're just wastefully overwriting with the same string
Change-Id: Ib03d5ae2cf48aa00f5f31256427afef58b684177
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129802
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
For example, to set a custom pixel size:
soffice --convert-to 'png:draw_png_Export:{"PixelHeight":{"type":"long","value":"192"},"PixelWidth":{"type":"long","value":"192"}}' test.odg
Change-Id: I628717ba36b6ad1ac03911eec06855c1745ef258
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129801
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
> /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/sc/source/core/data/bcaslot.cxx:647:25: error: comparison of unsigned expression >= 0 is always true [-Werror=type-limits]
> assert(slot >= 0 && slot < mnBcaSlots);
> ~~~~~^~~~
(<https://ci.libreoffice.org//job/lo_tb_master_linux_dbg/36619/>), where slot is of
type SCSIZE, which is a typedef for size_t (sc/inc/address.hxx)
Change-Id: I52cfa8b746791d4bd43be9a9d16cda992319c694
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129781
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
Change-Id: I217b46da48c662032d00e553639e985412f681ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129710
Tested-by: Jenkins
Reviewed-by: Jim Raykowski <raykowj@gmail.com>
|
|
Change-Id: I196c6cafaf0ccb6c2547ca56b0e7c48c9e0dd6ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129798
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
nothing directly extends IPropertyValueProvider
Change-Id: Ib393bd31bde7f68d8b21dc3bdeeb30b538de1488
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129797
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
(*) rename the enum to make it's purpose more obvious
(*) remove the enum header - it belongs to this class, no need to have
it somewhere else
(*) return property name by const&, no need to copy here
(*) use a o3tl::enumarray instead of a std::unordered_map - there are
only 3 entries here, and two of them are ALWAYS used, so just flatten
the data structure.
Change-Id: Ic496bd5220d55be1209a3243c095d461df0a02ae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129788
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
If global RTL flag is set, vcl-window X offset of chart window is
mirrored w.r.t parent window rectangle. This has to be undone to get the
correct chart bounding box in negative X document coordinates so that
the offset calculations for tile rendering remains the same for RTL
documents irrespective of the system/global RTL setting.
Conflicts:
include/sfx2/lokcharthelper.hxx
sfx2/source/view/lokcharthelper.cxx
Change-Id: I3e1666681af4e7ab1257bcc88d44bbdb053a7d47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129704
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
(cherry picked from commit 4fd2a14c6ee68f0574766ec7ec3dca35debe9d20)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129778
Tested-by: Jenkins
Reviewed-by: Dennis Francis <dennis.francis@collabora.com>
|
|
The remaining SCSTR_ROW wasn't used anymore at all, remove.
Rename
SCSTR_COLUMN -> SCSTR_COLUMN_LETTER "Column %1"
SCSTR_COLUMN_NAME -> SCSTR_COLUMN "Column"
SCSTR_ROW_NAME -> SCSTR_ROW "Row"
Change-Id: I1f68c8d0cc4e970ca508c8ee854f4c59a6d2f7d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129806
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
|
|
When paragraph style is disabling numbering defined in parent
style we should apply margin properties (like we already do
in other numbering cases), but we should include only properties
from styles not affected by numbering. In other words, only
styles without w:numId are used.
Unittest was extended to cover different combinations of this
situation.
Change-Id: Ic19e00fcfe16b2357cdfe763b4f969cc63122e89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129701
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Inline string is plain now in favor of the caption
Column/Row before the dopdown control
Change-Id: I7f012d38c360113b7207f19fa32437d28d90d049
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129366
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Even if what the comment says were true, 6318254d63ef5c62bbd504
already broke it by possibly passing MAXROL/MAXROW. This originates
from 64274b38f6cc50a8bb49f114f1ac9e7c1c3 (the r263929 part),
but I've checked and at least Excel2013 reads its fine. I also
don't see anything in the OOXML spec that'd say what we do is wrong.
Change-Id: I0c48beae2b54213a8b3b5e2112076a88b11e6cb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129787
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Id26c4456429d25dbf1bf97e8cac28f86cb81563d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129786
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
A comment suggests that it's the thing to do, and I'll need access
to GetRoot() from ScRangeListTabs in another change.
Change-Id: Ic0cf4b1cae7f5e1f9ad265d5a98651c51068c88c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129785
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I50d4a5c22a2b224526978e41fc7b8cb194b4bf3a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129780
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
All the tested cross builds don't build galleries, so the
cross-toolset won't contain gengal and no vcl is build.
To fix the full static build, add LIBWEBP to the list of
PERMITTED_BUILD_TARGETS and use gb_CONFIGURE_PLATFORMS to
provide the --host and --build flags.
Regression from commit 60eaa424c5e213f31227008e1ed66a646491a360
("support for the WebP image format (tdf#114532)").
Change-Id: I017c4fc72456859616d535ddfb2d568442ffa446
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129790
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
so we can avoid constantly generating new TextForwarders which
are the same as the one they replace.
The underlying problem is that of tdf#123470 but this solution should
be safe to backport
Change-Id: I742f2a9ce0024adf9bd0acc5bb8edb9372fc0af5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129775
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I65eb157b530414a7e1859af97248683ed27a23c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129776
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Not only check for characters of category Cc, but also for characters of
category Cn.
Use generic functions to check is characters belong to one of the above
categories.
Follow up of commit e38ebf0737297fe94e3128459fc25ef9259faa6b.
Change-Id: I97618dbf33db70b01b2833cf653988610b499333
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129222
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
It's possible to write AVX512 intrinsics in code compile only with
-arch:AVX . So do not require -arch for being able to do so,
especially since there is no -arch option for only AVX512F without
other AVX512 subsets (the option enables also CD, BW, DQ and VL
https://docs.microsoft.com/en-us/cpp/build/reference/arch-x64).
https://crashreport.libreoffice.org/stats/crash_details/55ef825d-c323-4df9-95e2-76672c674e60
is presumably caused by this, I can see use of registers XMM0-15
in arraysumAVX512.cxx built with -arch:AVX2 but when built
with -arch:AVX512 registers XMM16-31 are used too (I'm not sure
if that's AVX512DQ or something else, I can't find info on it).
Change-Id: I74473333a17e618327d43b920b8929d1b0e733b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129724
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
16Mx16k cells is more than 32bit, so things like cell counts
or progress -> sal_uInt64. Height/widths of complete rows/columns
-> tools::Long.
Change-Id: I8077ec0c97782310db024c20c335cfcbc3833227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129634
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
these things are never shared
Change-Id: I21c3b7cf2abf6e47a8839ac60e7bf27b7282ed76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129784
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
It's been a source of numerous problems since the beginning.
Poor separation of C++ code causing the compiler to emit some generic
code as CPU-specific, compiler optimizations moving CPU-specific
code out of #ifdef to unguarded static initialization, etc.
And it doesn't seem to even particularly improve performance,
on my Ryzen2500U for one full column (1m cells) sumArray() takes
about 1.6ms with AVX, 1.9ms with SSE2 and 4.6ms with generic code.
So SSE2 code is perhaps worth it, especially given that SSE2 is our
baseline requirement on x86_64 everywhere and x86 on Windows,
but AVX+ is nowhere near worth the trouble.
So this code removes all AVX+ code from Calc, and makes SSE2
a hardcoded option on where it's guaranteed. If we raise the baseline
to AVX, the SSE2 code may be replaced by the one removed by this
commit. Generic code is there for other platforms, if other platforms
add CPU-specific code, they should preferably follow the same rules.
This does not necessarily mean that CPU-specific code cannot
be used at all. Some externals use them, for example. It just
needs to be working, maintained, and worth the trouble.
Change-Id: I5ab919930df9d0223db68a94bf84947984d313ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129733
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I76db8dd5398628e544fdd76179046b98f76d80a8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129773
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
In tiled rendering case, there is no exists a generic
dummy to fire drag over and drag drop events.
Change-Id: I1d334df8316a09950c11bc365f12f28f0352dfc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118860
Tested-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117893
Tested-by: Jenkins
Reviewed-by: Henry Castro <hcastro@collabora.com>
|
|
Change-Id: I0937baf4dc9db222da6ba74d2b9bcea9f18627ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129782
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
Change-Id: I8b2192c1944299b92f82cc6179fcdb0842de9803
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129779
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
it's possible to know the arguments of .uno:FillSeries
using the macro recorder
Change-Id: I8e459c0ca42bd9cd0226e61b3a0b2107bdc22c75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129774
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
|
|
It turns out svl::SharedStringPool::purge() can be somewhat
expensive with larger documents. Profiling suggests it's primarily
the cost of the CPU trying to access the rtl_uString instances
scattered all over the memory, so it can't be easily optimized.
So instead delay and compress purge() calls if they come from
temporary ScDocument instances from undo or clipboard.
Change-Id: Ie26cce113025ff45ee2c473c6b06f684f453b27b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129713
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
I build a full-language WASM build and the WASM linker was
complaining about mismatching function signatures for
get_zh_zhuyin and get_zh_pinyin.
Turns out LO has two exported functions with the same name
but different signatures. For a static build, these collator
functions are renamed, so they don't clash, and this was
silently calling the wrong functions from
i18npool/source/indexentry.
Change-Id: I6afe1c3a289dfccea5a5fec41a9a6db37f4e19bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129741
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|