Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
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>
older ms specs confused JIS and ISO "B" sizes and there
are now documented newer sizes not in filter.
some of the sizes at
https://docs.microsoft.com/en-us/windows/win32/intl/paper-sizes
are surely still wrong, e.g. Letter extra paper and I trust the
values in calc table more.
orientation of ISO B6 Envelope dimensions is still ambiguous to me, so
left that alone for now
Change-Id: I6b6beb2620fe79f03ad5068eab0657a0b65f1aa4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105521
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Unrecognized A6 paper format was converted to the
default A4/Letter previously, see Paper Format
in Format->Page...
Co-authored-by: Balázs Regényi
Change-Id: If2ea0c4137177aa8be66cb11d4732b14cbc14455
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105392
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
This reverts commit f0356b6128.
Reason for revert: There is a OUStringConcat overload for OUStringBuffer which would have kicked in here, so this is unnecessary
Change-Id: I3bafb6c30bd3a2c1912daf227554889f1e09c78a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105354
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
as a consequence of
commit 2b946d245e
Date: Mon Oct 19 09:36:04 2020 +0200
XmlFilterAdaptor: use the fastparser API when possible
re-introduce slowparser support here
Change-Id: I95470e51508f8e250f27c5af7ffdc1b737c16ab9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104975
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
Commit d75c5b3891 (tdf#136836 emfio: speed
up import of EMF import when the orig PDF is available, 2020-09-17)
improved both performance and correctness of the EMF import, in case it
had a PDF fallback.
It turns out that PDF fallback can be nominally non-transparent, and
still the EMF equivalent supports transparency.
Fix the problem by enabling transparency in the PDF-in-EMF case.
Change-Id: I4d1585a5db6f28bd9c9cb380b5f193f4d5edcc8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104849
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
part of the process of making SvXMLImport fastparser-only
Which uncovered several bugs because I end up stacking fast and
slow parsers, not once, but twice.
Specifically, we have a problem here with default namespaces e.g.
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
<semantics><mrow><mstyle mathsize="12pt">
where going from slow- to fast- parser loses this information,
because there is no way to represent this in the fastparser world,
so we end up with nastiness when we transition back to slow-parser,
and then back-again to fast-parser.
So I fixed a couple of places XMLEmbeddedObjectImportContext
and in SvXMLLegacyToFastDocHandler, and then worked around some of
it by introducing an new XImporter2 interface so I could strip out
out one of the slowparser -> fastparser transitions.
Change-Id: I491487b99271898da50dc999d3b9b9c39cbd97fd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104514
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Commit 800085d4fb (sw reqif-xhtml import,
embedded objects: handle Ole10Native stream, 2020-05-04) added support
for handling an OLE1 stream which contained something else than OLE2
data.
However, that assumed a fixed class name ("Package") and a matching
class id. Improve this, so that the class id is created dynamically,
based on the OLE1 class name.
The class id can be figured out by putting the OLE1 data in an RTF file
and converting that RTF file to DOC using Word.
Change-Id: I1623a42a8f9b1278fd69641f1ae1ee467a6f0143
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104439
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
on examining the oss-fuzz stats I see this one as...
"Created: Dec 15, 2019", "Reliably Reproduces: YES", but no bug
auto-filed for it
Change-Id: I1ddd61db2f2317827c00d601d0db513c4511f018
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104105
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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>
do more like
commit 121771e37f
Date: Mon Sep 21 09:17:54 2020 +0200
Make some OUStringLiteral vars constexpr
cause coverity can live with that
Change-Id: I9efd7f848289c4865997a44c6780373068422227
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
This reverts commit 2cb90a5c87.
Revert the change to EscherPropertyContainer, which was completely
bogus, based on pre-existing bogus code in VMLExport::Commit().
The problem is that ESCHER_Wrap values are for wrapping text *inside* a
text box, which is "mso-wrap-style" in VML, whereas VML's w10:wrap
element defines how text wraps *around* a shape, doesn't exist as an
ESCHER property and is specific to Word formats.
Instead, export the w10:wrap element in VMLExport::EndShape().
This has 2 callers, WriteActiveXControl() and writeVMLDrawing().
Furthermore the value "none" wasn't written for WrapTextMode_THROUGH,
which caused the wrap element to be omitted in that case.
Change-Id: Id4a01fcb2ea73fa9bef4ee8769b5e0680e059f15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103009
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
...from which an OUString can cheaply be instantiated. This is the OUString
equivalent of 4b9e440c51 "Turn OStringLiteral into
a consteval'ed, static-refcound rtl_String". Most remarks about that commit
apply here too (this commit is just substantially bigger and a bit more
complicated because there were so much more uses of OUStringLiteral than of
OStringLiteral):
The one downside is that OUStringLiteral now needs to be a template abstracting
over the string length. But any uses for which that is a problem (e.g., as the
element type of a container that would no longer be homogeneous, or in the
signature of a function that shall not be turned into a template for one reason
or another) can be replaced with std::u16string_view, without loss of efficiency
compared to the original OUStringLiteral, and without loss of expressivity.
The new OUStringLiteral ctor code would probably not be very efficient if it
were ever executed at runtime, but it is intended to be only executed at compile
time. Where available, C++20 "consteval" is used to statically ensure that.
The intended use of the new OUStringLiteral is in all cases where an
object that shall itself not be an OUString (e.g., because it shall be a
global static variable for which the OUString ctor/dtor would be detrimental at
library load/unload) must be converted to an OUString instance in at least one
place. Other string literal abstractions could use std::u16string_view (or just
plain char16_t const[N]), but interestingly OUStringLiteral might be more
efficient than constexpr std::u16string_view even for such cases, as it should
not need any relocations at library load time. For now, no existing uses of
OUStringLiteral have been changed to some other abstraction (unless technically
necessary as discussed above), and no additional places that would benefit from
OUStringLiteral have been changed to use it.
Global constexpr OUStringLiteral variables defined in an included file would be
somewhat suboptimal, as each translation unit that uses them would create its
own, unshared instance. The envisioned solution is to turn them into static
data members of some class (and there may be a loplugin coming to find and fix
affected places). Another approach that has been taken here in a few cases
where such variables were only used in one .cxx anyway is to move their
definitions from the .hxx into that one .cxx (in turn causing some files to
become empty and get removed completely)---which also silenced some GCC
-Werror=unused-variable if a variable from a .hxx was not used in some .cxx
including it.
To keep individual commits reasonably manageable, some consumers of
OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat
odd state for now, where they don't take advantage of OUStringLiteral's
equivalence to rtl_uString, but just keep extracting its contents and copy it
elsewhere. In follow-up commits, those consumers should be changed
appropriately, making them treat OUStringLiteral like an rtl_uString or
dropping the OUStringLiteral overload in favor of an existing (and cheap to use
now) OUString overload, etc.
In a similar vein, comparison operators between OUString and std::u16string_view
have been added to the existing plethora of comparison operator overloads. It
would be nice to eventually consolidate them, esp. with the overloads taking
OUStringLiteral and/or char16_t const[N] string literals, but that appears
tricky to get right without introducing new ambiguities. Also, a handful of
places across the code base use comparisons between OUString and OUStringNumber,
which are now ambiguous (converting the OUStringNumber to either OUString or
std::u16string_view). For simplicity, those few places have manually been fixed
for now by adding explicit conversion to std::u16string_view.
Also some compilerplugins code needed to be adapted, and some of the
compilerplugins/test cases have become irrelevant (and have been removed), as
the tested code would no longer compile in the first place.
sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template
argument deduction in unevaluated, parenthesized context". That place, as well
as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and
i18npool/source/localedata/localedata.cxx, which have been replaced with
OUString::Concat (and which is arguably a better choice, anyway), also caused
failures with at least Clang 5.0.2 (but would not have caused failures with at
least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile
been fixed).
Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Long ago, styles were read in starting in slot 1 and
slot 0 was backfilled using the last read rule.
That changed in 8a64144fdd when
stuff started at 0; unfortunately the back filling at 0
code was left in, overwritting level 0.
Remove it, fixing cases which used level 0; in particular
a shift-tab to go up a level ended up with the wrong
style.
Fixes: 8a64144fdd
Change-Id: Ic29f3fca9f1c809de69a1d83fca017bdafdd2447
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102542
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Regression from commit 8fc1b60f62 (sw SVG
export: try to reuse original bitmap data for JPG and PNG bitmaps,
2020-02-27), which generalized the code that tries to get the original
bitmap of shapes for performance reasons. Originally this worked with
SdrGrafObj, but now we try every XShape which has a Graphic property.
Add the missing check, so shapes without a graphic property just miss
the fast path, but doesn't fail the entire SVG export.
Change-Id: I6b20083110f3269337b9df6a23bd193cc6f7d13b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102187
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
(This change is a prerequisite for making the OUString ctor taking a raw pointer
explicit.)
Change-Id: I7a61a709c3a4950d067ed600a7c0441afe51043f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102088
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(This change is a prerequisite for making the OUString ctor taking a raw pointer
explicit.)
Change-Id: Ifc7450591c723223e8c696110866e8ee5e2900e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102087
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Gabor Kelemen