Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for
operator call arguments. (The "rather than copy, pass subView()" diagnostic is
already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly
for operator call arguments.)
(And many call sites don't even require an explicit [u16]string_view, esp. with
the recent ad48b2b02f "Optimized OString operator
+= overloads". Just some test code in sal/qa/ that explicitly tests the
O[U]String functionality had to be excluded.)
Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
LO without commit 519d96fd8b makes a mess
when storing form documents it has loaded from ODF 1.3 documents: the
XML parts are stored as ODF 1.2, but the storage (and therefore manifest
entry) keeps version 1.3.
To avoid this, store form documents as ODF 1.2 extended by default.
Unfortunately a bunch of ODF export code accesses the global
SvtSaveOptions variable; with this version override, only
SvXMLExport::getSaneDefaultVersion() must be used.
Change-Id: I5fa8e286f5103c578ed0d93da07a8a6cbe2f0ddd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115357
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
I was wrong, the Concat framework already optimised appending
numbers by stack-allocating small buffers, so include
them in the plugin
Change-Id: I922edbdde273c89abfe21d51c5d25dc01c97db25
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115037
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
when calling a function, and passing only one arg, but the
function has defaulted args, we were ignoring this case.
Change-Id: I86517f18e30531127664088ddc09ef96dbd8bdf5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115033
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Optimise LocaleDataWrapper for reads by initialising the
data we in the constructor, so we don't need any kind of
locking
Reduces load time from 34s to 28s.
Change-Id: I4bd3bddb30b70ba015fe5b1372534f9507762b74
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114960
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
which can use the more efficient *StringConcat
Also fix a crash in stringview plugin which
started happening while I working on this.
Change-Id: I91a5b9b7707d1594d27d80b73930f5afac8ae608
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Interestingly at least on Linux, our click handler doesn't know how to
open "test.pdf", but "test.pdf#page=2" works. If these URLs are normal
hyperlinks (and not biblio source URLs) then both work.
It turns out the hyperlink case works because the doc model deals with
absolute URLs and only ODF import/export converts to relative ones. Do
the same for
<text:bibliography-mark text:url="...">
and that way the click handler gets an absolute URL even for "test.pdf",
which then works.
Change-Id: If8282f444d0f6e6defe4282e2753ae8b37b5b09a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114266
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
to O[U]String from char array literals, we can convert the char literals
to O[U]StringLiteral and avoid a runtime allocation
Change-Id: I15d8dddb2cd428b90740e39f20daf98e0941aa6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
7ea1bbe712 had abused the C-style strings,
and relied on the names containing zero byte to be truncated on the byte.
However, that would only work for names with zero bytes, not with other
control characters. Additionally, that prevented the initial names from
correct round-trip.
This reverts the older fix, and makes sure to handle the attributes with
zeroes correctly (using memcpy instead of strncpy).
It also removes several similar unneeded uses of getStr.
Change-Id: I6c52874d99fe9eb9ccbe0c9a9b57e3b51c45a19f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114040
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
For example ja-JP Gengou calendar.
NN/NNN always worked because ja-JP Gregorian calendar defines the
same day of week names so it never was apparent.
Change-Id: Ief0d7ce7532b7ed7d58910bf150b190b7872db28
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113900
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
Also keep the control layer distinct from the foreground, as a follow-up
to tdf#133487.
Try to improve the detection of already sorted indexes a bit to avoid
unnecessary sorting.
Hilariously the test docs require adding 3 additional items to the
extension schema.
Change-Id: I629d5b09294f679717677b9d89537d905ac4c404
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113696
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This reverts commit 2bf8c1e0e2.
Reason for revert: tdf#141268 LibreOffice uses -135deg skew angle as internal default. If a user does not touch the direction, the value is not written to file, although that would be necessary because it is not ODF default. With the patch applied the missing value will be interpreted as 45deg on opening. So the first step is, to write -135deg to file. And then after some time, when wrong files are unlikely, the patch can be applied.
A suggestion for writing -135deg is from Julien Nabet in https://gerrit.libreoffice.org/c/core/+/113257. From code it looks good to me, but I have not tested it yet. I would only add some comments to explain the situation.
Change-Id: I71673ad2e5376c2a78fa74900e95117b8543e268
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113538
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
See <https://issues.oasis-open.org/browse/OFFICE-4105>, the proposal is
to include the gutter in the left/top/right margin to have better
backwards compatibility, at the price of more complex xmloff code.
This works by increasing the left/top/right margin on export (so even if
gutter margin is ignored at import time, the layout will look fine, just
the editing will be poor) and decreasing on import.
Change-Id: I852e5c7366e8641abd61e136f9390466585953fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113464
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
See <https://issues.oasis-open.org/browse/OFFICE-4105>, the proposal is
to not map this to a new attribute of the <style:page-layout-properties>
XML element, rather only write writing mode on export and infer
RtlGutter from that writing mode in import.
This is similar to how FillBitmapOffsetX and FillBitmapOffsetY are two
UNO properties, but there is a single draw:tile-repeat-offset attribute
for them.
This has the benefit of simpler ODF markup, at the cost of more
complicated xmloff code.
Change-Id: I189a7ec62d4e5624e20252b7259a36133594fe40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113405
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
This is annoyingly complex because LO 6.3 changed the way backgrounds
are painted in an inconsistent way.
Use the generator version to guess what the document should look like,
which of course will give the wrong result if it was created before LO
6.3 and then round-tripped with LO 6.3.
Since LO 7.0 at least a hard-coded draw:background-size was written.
Change-Id: If9c5d2b32bfa50cbe4fb166132f7223763af850f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112770
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
* add BackgroundFullSize property to PageProperties
* add a checkbox on the SvxPageDescPage
* marshal the item via SfxGrabBagItem to avoid changing svxids.hrc
* add RES_BACKGROUND_FULL_SIZE item, pool default is "true" which is
appropriate for Word import filters
* ODF export: remove hard-coded export in
XMLPageMasterExportPropMapper::ContextFilter()
* use it in SwFrame::PaintSwFrameBackground()
* fix painting of bitmaps by also using the page frame area in
SwFrame::GetBackgroundBrush(), which was the reason why
f006b6339e painted things inconsistently
* force repaint in lcl_DescSetAttr()/SwFrame::UpdateAttrFrame()
Change-Id: I4cb64f87c01d17c051936e9b8128395fbb8b4fe5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112594
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
The default value for extrusion skew angle is 45 in ODF and -135 in
binary MS Office. LO had used -135 in case the draw:extrusion-skew
attribute was missing on import. This could be fixed in GetSkew() in
EnhancedCustomShape3d.cxx#92. But that would break import of ppt files.
So I have decided not to search, were the binary import would need to
be tweaked, but I set the default values directly in file open in case
the attribute is missing.
Change-Id: Ieeffa64099fdbdbe0ba9d4dab7ed2f19d397a6e3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112819
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
... so background shapes have lower z-index than foreground shapes,
as is recommended by ODF 1.3.
Also let SdrObjList::sort() record Undo actions, because earlier Undo
actions could expect the previous sort order.
Change-Id: Idbecf0a2acd525d42efc0ac92677b1c7987cc6ad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112180
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Other implementations may have different opinions about default
calendars and the context here is to switch to Gregorian.
Change-Id: I14a27826e627f890911adaf01935c58b43ad766a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112354
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins
m_pFontAutoStylePool is already sorted, but sorting ignores
XMLFontAutoStylePoolEntry_Impl::sName, and changing
XMLFontAutoStylePoolEntryCmp_Impl would affect how find() works in
XMLFontAutoStylePool::Add(), so just extend
XMLFontAutoStylePool::exportXML() instead.
With this, the order of <style:font-face> elements is meant to be stable
in content.xml and styles.xml, helping use-cases where a document is
converted to ODF multiple times and an integration test wants to assert
that the output is the same.
Change-Id: If0dbfa40a1b204aebe5e141fe64f71ac2ca92405
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112339
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Not sure how old the bug that caused this and which filter it was
originally but currently the Word import filters don't do that any more.
This causes an exception since commit
dd24e21bb4 so try to fix it up.
Change-Id: I087586054ebd5698ed8e8a4054869df202226e92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111345
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Regression from commit bc886f5238
(tdf#98584 Correct import draw:transform values skewY and matrix,
2020-01-02), then problem is was that now we handle the transform matrix
for path objects the way ODF likes it, but this breaks UNO API clients
with existing code.
In an attempt to make everyone happy, revert the default to ignore
scaling from the transform matrix, but add a way so that xmloff/ can opt
in to handle it. This way the ODF import result doesn't regression and
UNO API compatibility is not broken, either.
Change-Id: I8d525e56954bf68c42d3629eca87fe9b513de507
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111340
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Stephan Bergmann