which was introduced in
commit adf0738d2d
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Wed Jan 3 14:25:15 2018 +0200
long->sal_Int32 in BigInt
presumably to make the conversion easier.
Instead just fix the call-sites to select a better
conversion, BigInt only returns 32-bits of precision
anyway.
Change-Id: I2e4354bcfded01763fe3312a715ef37800297876
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105602
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which was added in
commit 331e2e5ed3
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Thu Sep 14 08:49:52 2017 +0200
long->sal_Int32 in Fraction
presumably to make the change impact less code.
Instead, update the call sites to reflect the actual bitwidth
of the data we will be receiving.
Change-Id: If2a678b1cf534f39cb8cb249757462be53658309
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105607
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Color.hxx has now documentation ( even if it is quite obvious if you know RGB standar ).
Color.hxx has been reordered in more coherent order, but kept format.
Some changes on Color.hxx dynamics.
Color.hxx starmath colors list
Now colors are managed by starmathdatabse.
The path is open for simple addition of colors, there are no more infinite switches with color tokens here and there.
To add a color, just put it in Color.hxx and register it in starmathdatabse.cxx. Do not forget to change array size in starmathdatabase.hxx.
Now mathml supports RGB colors in #RRGGBB format ( import and export ).
New colors have been added. Only the HTML Css1 are available via UI.
New colors will be added. I intend to finish Css2 and dvipsnames ( latex colors ) on posterior patches.
RGBA command has been unlocked for compatibility reasons. However will be displayed as RGB.
Added color #RRGGBB.
Improved qa color test on mathml to test RGB on mathml.
TODO for someone on the UI team:
- Add a color picker.
- If it is a color with name:
- It will add in the code "color " + starmathdatabase::Identify_Color_DVIPSNAMES( colorvalue ).pIdent +" "
- If not:
- It will add in the code "color " + starmathdatabase::Identify_Color_DVIPSNAMES( colorvalue ).pIdent +" "+ colorvalue.getRed() +" "+ colorvalue.getGreen() +" "+ colorvalue.getBlue() +" "
- Note that those will habe eType with value TRGB or TRGBA.
Change-Id: I47af37bd191b3099e8e6e08e7a5fb1a8a227bbf2
Change-Id: If971473ddcc34739439818dba9a62ca3494a4473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105526
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is only for the 64-bit windows platform.
I don't see the point in messing with the 32-bit platforms, they are
(a) become more and more rare
(b) unlikely to even have enough available process memory to load extremely large calc spreadsheets
The primary problem we are addressing here is bringing
Windows-64bit up to same capability as Linux-64bit when it
comes to handling very large spreadsheets,
which is caused by things like tools::Rectangle using "long",
which means that all the work done to make Libreoffice on 64-bit
Linux capable of loading large spreadsheets is useless on Windows,
where long is 32-bit.
The operator<< for tools::Rectangle needs to be inside
the tools namespace because of an interaction with the cppunit
printing template stuff that I don't understand.
SalPoint changed to use sal_Int32, since it needs to be
the same definition as the Windows POINT structure.
Change-Id: Iab6f1af88847b6c8d46995e8ceda3f82b6722ff7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104913
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
A 0-byte ("empty") pptx file is obviously junk input, so it's not
surprising if the catch-all generic_Text filter is chosen to open it in
Writer at the end.
But we can do better: if we really get an empty file URL with an
extension we can recognize, that we can fake the filter type / filter
name, so the empty "presentation" opens in Impress, and also a re-save
works as expected.
This builds on top of commit 8a201be240
(fdo#68903 Import .tsv and .xls plain text files in Calc by default,
2013-10-27), just the new way works for all supported file extensions
and also with filters which would not handle empty input (e.g. pptx
refuses the import if the ZIP storage is broken).
Change-Id: Ie01650a5eb6ca42c35e090133965467b621bb526
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104939
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
This reverts
commit 0cabffc05f
tools::PolyPolygon -> basegfx in canvas
and
commit 2c5d5a6d55
tools::PolyPolygon -> basegfx in filter
Comment from quikee:
The interpretation of integer polygons and floating point polygons
(or any other float vs. int drawing primitives) are different,
so you have to be really careful when changing, that the result
after the change is still the same. A big problem is that we still
have the metafile in OutputDevice, which is completely integer based
- so there will be conversions that go from int representation to
float representation to int again and to float (because backend is
in floating point) and I really fear that because of this there will
be regressions and even if not, it could make changing later more
painful. This is the reason I wouldn't change these things without
having tests that would show when there is a difference in rendering.
Change-Id: I54addca4e5a72196b5f77f6c7689eb716451c1dd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103483
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which needed an extra method on OutputDevice.
Also add some utility methods to make future conversion work easier.
Change-Id: I57c5bc7505e656a014f2e723fea2aa79271e6515
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103415
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is a prerequisite for making conversion from OUStringLiteral to OUString
more efficient at least for C++20 (by replacing its internals with a constexpr-
generated sal_uString-compatible layout with a SAL_STRING_STATIC_FLAG refCount,
conditionally for C++20 for now).
For a configure-wise bare-bones build on Linux, size reported by `du -bs
instdir` grew by 118792 bytes from 1155636636 to 1155755428.
In most places just a u"..." string literal prefix had to be added. In some
places
char const a[] = "...";
variables have been changed to char16_t, and a few places required even further
changes to code (which prompted the addition of include/o3tl/string_view.hxx
helper function o3tl::equalsIgnoreAsciiCase and the additional
OUString::createFromAscii overload).
For all uses of macros expanding to string literals, the relevant uses have been
rewritten as
u"" MACRO
instead of changing the macro definitions. It should be possible to change at
least some of those macro definitions (and drop the u"" from their call sites)
in follow-up commits.
Change-Id: Iec4ef1a057d412d22443312d40c6a8a290dc6144
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101483
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
It had been documented as "the macro OSL_THIS_FUNC is intended to be an office
internal macro for now", so take the liberty of removing it, even if technically
that can be considered an incompatible API change.
Change-Id: I7580a932e1da54845934378a650e894f3f3a9062
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101406
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Recheck after 7-0 branchoff
Also drop the now unused file include/vcl/field.hxx
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: I9e54c82f50d1e02a0f99858939cac999fc66f7de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99261
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Also makes sure that if the CPU dataction or compiler detection
doesn't work correctly, the test could potentially crash.
Change-Id: If0862c0a736c8e1f5ba1117b248918e4c1fb2f4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96779
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
and fix bug in buffer reallacotion where mPos pointing
at the beginning of the new buffer instead of at the
correct index inside it.
Change-Id: Ie1ffaa176f6165e2cec85c93adc945312eff38e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96650
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
because the LOK API expects memory returned from those calls to be
malloc'ed
Change-Id: If6fbfb60c433bd6e58bc90a9a90a90663e2e1c60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96676
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In ViewIteratorImpl::Reverse we std::move a reference, to a local
variable, however the reference was not reset correctly, which
caused a crash.
The issue is that a mpWeakConnection in WeakReference always
needs to be non-null as shown in reset(reference_type* pReference)
method. In the move constructor of WeakReference, we just std::move
the reference like:
mpWeakConnection = std::move(rWeakRef.mpWeakConnection);
This means rWeakRef.mpWeakConnection will be reset to null, which
is not what is expected, so what is missing is to instantiate
rWeakRef.mpWeakConnection by calling reset(nullptr) or using the
added reset() method.
This also adds a test for LOKit PDF search as this is the case
where the crash has been reproduced. It happens because of a
call to:
... std::move(maPosition.mxObject);
in the method ViewIteratorImpl::Reverse()
Change-Id: I43692554ba4f6231d00091269b7c902ab5cbc11f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95995
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Integer conversion throws away percision, which is problematic
when we work with floating point values.
Change-Id: Ib34e46bd59aa67e933d49bc800e96cc6426414e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95260
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Import/export the paragraph tabs without any text offset,
tabs are relative to the text box anyway.
Change-Id: Ife3b762e7581548e65500c16259a4481cc07a88f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94101
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Turns out we can save about 500Mb of preprocessor input if we use
rtl_math_approxEqual from rtl/math.h instead of its C++ wrapper
rtl::math::approxEqual from rtl/math.hxx
and manage the fallout accordingly.
Before:
bin/includebloat.awk | head
sum total bytes included (excluding system headers): 19017296671
After:
$ bin/includebloat.awk | head
sum total bytes included (excluding system headers): 18535432672
Change-Id: I1691171f3a309405a7099882ad9989d147f59118
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92508
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
which fixes warnings from
commit ef37ab245b8095895f715217236e8e2fb90613c6
Date: Thu Mar 19 09:21:45 2020 +0200
loplugin:redundantpointerops add some more smart pointer types
which I pushed earlier, where I added tools::WeakReference to the list
of smart pointer types, but of course the conversion it recommended is
not possible without an operator*
Change-Id: I9433b7aba46a3a15f9d833847ae3659367388109
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90735
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...plus --enable-assert-always-abort: ShapeManagerImpl::checkForImageMap in
slideshow/source/engine/slide/shapemanagerimpl.cxx in Library_slideshow calls
SvxShape::GetSdrObject, which calls tools::WeakBase::get
(include/tools/weakbase.hxx), which contains
> assert(dynamic_cast<reference_type *>(pWeakBase));
requiring RTTI for tools::WeakBase. See e.g.
<https://ci.libreoffice.org//job/lo_tb_random_config_linux/2281/>.
Change-Id: I9598c14bf74eb5a28332d0beecfbe8201b39451e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90697
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Noel Grandin