Age | Commit message (Collapse) | Author |
|
as demonstrated by kde246118-4.odp
Change-Id: Idf1224555e0d7be9a679862da9ff256cf7a4d128
|
|
(cherry picked from commit a8cc15c001ac76c0d320837cc4cdf65ecb7fc923)
Conflicts:
xmloff/source/draw/shapeexport2.cxx
xmloff/source/draw/shapeexport3.cxx
Change-Id: I35f7817f3ea95177dd3aa633b9cbb1b5703f08a0
|
|
(cherry picked from commit c0f65b29f8028ab750c8caac033645c3da3cf2f5)
Conflicts:
xmloff/source/draw/shapeexport2.cxx
Change-Id: Ic8da384d094ce735ecba51b282de7a697558e51f
|
|
Change-Id: I10f3dbd9513052b3bbe30ddc6523cd231f26ded3
|
|
Convert code like:
if( aStr == OUString("xxxx") )
to this:
if( aStr == "xxxx" )
Change-Id: I8d201f048477731eff590fb988259ef0935c080c
|
|
Change code like this:
aStr = OUString("xxxx");
into this:
aStr = "xxxx";
Change-Id: I31cb92e21658d57bb9e14b65c179536eae8096f6
|
|
This also means that this code now gets bounds checked in debug builds.
Change-Id: Id777f85eaee6a737bbcb84625e6e110abe0e0f27
|
|
This reverts commit 14fa5488a829936275f79a7693b13da55114220e.
Conflicts:
xmloff/source/chart/SchXMLTableContext.cxx
|
|
Change-Id: I9029bab2b0ab98a2d78166145a35792e298c9115
|
|
...from the changes to xmloff/source/draw/shapeexport2.cxx of
f15874d8f976f3874bdbcb53429eeefa65c28841 "i123433 Detect pseudo-vertices at svg
import, unify svg:d handling, correct svg:d import for relative sub-polygons in
svg import [...]," given how other changes in that file that introduce
aPolygonString use it. Found by -Werror,-Wunused-variable.
Change-Id: I915b53ed74e03f84f240f1fa1f17768148f030d6
|
|
Change-Id: Idc7e0a2651f2e0b499bbf8b8443ffb84b54a45b6
|
|
unify svg:d handling, correct svg:d import for relative sub-polygons in svg
import; changed default for moveto writes for svg:d in ODF to absolute
(cherry picked from commit f15874d8f976f3874bdbcb53429eeefa65c28841)
Conflicts:
basegfx/inc/basegfx/polygon/b2dpolygontools.hxx
basegfx/inc/basegfx/polygon/b2dpolypolygontools.hxx
basegfx/inc/basegfx/polygon/b3dpolypolygontools.hxx
basegfx/source/polygon/b2dpolypolygontools.cxx
basegfx/source/polygon/b2dsvgpolypolygon.cxx
basegfx/source/polygon/b3dpolypolygontools.cxx
basegfx/source/tools/makefile.mk
basegfx/test/boxclipper.cxx
basegfx/test/clipstate.cxx
basegfx/test/genericclipper.cxx
canvas/source/tools/surfaceproxy.cxx
sdext/source/pdfimport/tree/drawtreevisiting.cxx
sdext/source/pdfimport/tree/writertreevisiting.cxx
xmloff/inc/xexptran.hxx
xmloff/source/draw/XMLImageMapContext.cxx
xmloff/source/draw/XMLImageMapExport.cxx
xmloff/source/draw/shapeexport2.cxx
xmloff/source/draw/shapeexport3.cxx
xmloff/source/draw/xexptran.cxx
xmloff/source/draw/ximp3dobject.cxx
xmloff/source/draw/ximpshap.cxx
xmloff/source/style/MarkerStyle.cxx
xmloff/source/text/XMLTextFrameContext.cxx
xmloff/source/text/txtparae.cxx
Change-Id: I5171b4a3559ea116bea45152e1f2685666463635
|
|
...where multiple parallel calls to xmloff::token::ResetTokens or
xmloff::token::GetXMLToken can see dangling pOUString pointers. There is no
point in releasing this (bounded) amount of memory referenced from global
aTokenList, anyway.
There is still a race when parallel calls to xmloff::token::GetXMLToken write to
a pOUString pointer in parallel, but that's more harmless, and maybe calls to
GetXMLToken are synchronized by Solar Mutex? Calls to ResetTokens (e.g., via
URP remote release request -> ~ScXMLExport -> ~SvXMLExport) were definitely
/not/ synchronized via any mutex.
The xmloff::token::Inc/DecRescheduleCount functions are now pointless and have
been removed, too.
Change-Id: I85905d4de1f042ed5c9a37589f942910d8ef80fd
|
|
This is both an optimisation and a cleanup.
This converts code like
aStr.indexOf("XX") == 0
to
aStr.startsWith("XX")
and converts code like
aStr.lastIndexOf("XXX") == aStr.getLength() - 3
to
aStr.endsWith("XXX")
Note that in general
aStr.lastIndexOf("X") == aStr.getLength() - 1
converts to
aStr.isEmpty() || aStr.endsWith("X")
so I used the surrounding context to determine if aStr could be empty
when modifying the code.
Change-Id: I22cb8ca7c2a4d0288b001f72adb27fd63af87669
|
|
For Docx files, the chart series names (labels)
were rendered incorrectly and hence exported incorrectly.
In place of the correct label, the series name
for next series was displayed.
Change-Id: I988571d76d9c706ac2f7693881198bb604ec3fa8
Change-Id: I52631bc62fce46a43298c284cb11c2e8916fabe3
Reviewed-on: https://gerrit.libreoffice.org/6350
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I2bc45e4ba63f5faaee7389bcd9d7b3f563503186
|
|
Change-Id: I0e7d9daac1ad88fad8d240373e91ef323966bb47
|
|
There were only a couple of real bugs fixed, but we're a little
bit safer now.
This also fixes the assert and the comment in OUString::operator[]
about this.
Change-Id: Ibe16b5794e0ba7ecd345fa0801586d25b015974c
|
|
Conflicts:
sw/source/ui/inc/content.hxx
Change-Id: I58d81881271fc6e3320bf3b5f1321594b28614a6
Reviewed-on: https://gerrit.libreoffice.org/6388
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Convert places that call
aStr[aStr.getLength()-1] == 'x'
to use the shorter form
aStr.endsWith("x")
Change-Id: I1b3a19c0e89b8989cdbeed440f95fc76f9a4b6b6
|
|
They are practically always useless, often misleading or obsolete.
Change-Id: I2d32182a31349c9fb3b982498fd22d93e84c0c0c
|
|
Change-Id: I4c688a4aeedcae56ed6404574bd1bb392d4190cb
Reviewed-on: https://gerrit.libreoffice.org/6311
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I7bfd221f89718ba8634417c93a26b3a199178694
|
|
Change-Id: I475bee35ca5d24903d85e7f2427fab0e47d8db4d
|
|
Change-Id: I44cee32e256e0767bb3b40bdba93e15b717c9ba6
|
|
Change-Id: Ifa5b522603a0ea592d873ae79b266091163e993f
|
|
Change-Id: I3db66690f9eaa809bcbf2257804d319aaec0f975
|
|
Change-Id: Iea42dc54c6d3b81142939b920d932d4cf83dc6e1
|
|
Change-Id: I43df9a5458cb87145a3492e1a0c97ceb8c8a3b90
|
|
Change-Id: I55c9f2d0d7a7c03dd9960a32a415398a194f8265
|
|
Change-Id: I683c0d30c3286ed5d725d4eefe8b3977b82ee316
Reviewed-on: https://gerrit.libreoffice.org/6035
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0a463c38214b95582db2c7b3979367255426c14e
|
|
Change-Id: I5e70926bba93045528d6bea319ea31ed4d72ecf4
|
|
(avoids warnings about std::auto_ptr ctor being deprecated)
Change-Id: I39d2d155c0bc62ca77a30c02428ea39102213f42
|
|
Change-Id: Ibb7988e0b9a63dc952ebf99463b11a3a5ba42162
|
|
Change-Id: I348b73fec1823379a1bf49e9d645627ccdb76a47
|
|
Change-Id: Id76f56ca86ef22fbee59387cda0832984dda5358
|
|
Change-Id: Iec2cf62c1d691b3229a37bcb952553b3424b081e
|
|
Change-Id: Ief9d3dc339df3f22d4774d0fc27a128d4519ab27
|
|
Change-Id: Ifbc7fb710397c4f5a365e2a78775c417e352ff98
|
|
Change-Id: I977c092248bdbfab33ff4d0c3a748a61d29ff745
|
|
Change-Id: Idc6f30e7331a5b7621b45c4242406e3cbe3c5d75
|
|
Change-Id: Ib7be15303ebaedbfe68f68fa1fe032e39e1eb32a
|
|
Change-Id: I87429f4d03d89599faae6276e173707b464eae6b
|
|
Change-Id: I141d1a6ea99132309dbe77f542055d6c6db31d7c
|
|
Change-Id: I593c6c3236172f33b3e58fb44a41e079c3c8b0c4
|
|
|
|
Hopefully helps a Gentoo tinderbox.
Change-Id: I2e83b867113ba04a708c9fbb46c728368c4328c0
|
|
To be used in regression testing and similar scenarios, where the output ODF
is *not* intended to be further manipulated in LibreOffice. An environment
variable LIBO_ONEWAY_STABLE_ODF_EXPORT is used to toggle this behaviour. I am
not 100% sure whether the generated ODF with the hack toggled on is even fully
correct, but correctness is not the purpose of the hack anyway.
Two classes of issues handled: 1) Automatic style names and 2) use of
randomness.
For class 1), when the hack toggle is in effect, we generate the names at
first as strings based on all the properties of the style, and sort them based
on those, and then rename them (for brevity in the output) to the "normal"
form of a short prefix plus a number (like "P12").
Sure, it would have been better to just figure out *why* the automatic style
naming currently is not stable in the first place, but outputs the styles in
different order (with some styles being assigned different numbers) in
separate invokations of LibreOffice), but I was unable to understand that.
Possibly this code could be used in all cases, except that it does break some
unit test (can't recall which right now). I don't know whether that is simply
because the unit test assumes too much knowledge of the internal workings of
the automatic style name generation, or whether the generated ODF is actually
invalid.
For 2), I found a handful of places where randomness was used to generated
various kinds of identifiers in ODF output. I changed those to just use large
(64-bit) non-overlapping integers instead. I assume there *is* a point in the
original code in each case that explains why randomness is needed, so the hack
definitely needs to be optional and used only for the above mentioned
scenarios.
Change-Id: I17b657197e38bcf24abdfe61ad4a277f4339eeae
|
|
Change-Id: Ib88b9e5533e56bb8b0b05c4e668299b033f17ffb
|