As far as I can tell, there is not circular dependency, but make
complains, and only when invoked from toplevel, not from tail_build.
Looks like gbuild problem, but do a hackish change to make
unbreak clean compilation, for now.
Change-Id: I445ba343f9eaa988c60c288bf5fc1c5d1c7b67a5
They are not exported automatically, as SvxUnoNameItemTable needs a
Which ID, and it's different for drawinglayer and Writer gradients.
Change-Id: I5dd7d828b1f0e577e26510e3c5ca74386d000f16
The services are:
document::NamedPropertyValues
document::IndexedPropertyValues
The services already existed, they just did not have IDL files
Change-Id: Ibafe9b5afb9b30785df4f66aa923f4b96ceabeed
Without this, pasting a chart object from one Calc doc to another may
occasionally incorrectly switch to range references *if* the destination
document contains the "right" set of sheet names. With this fix, pasted
chart objects always switch to internal cached data source when pasting
to another document, while retaining range references when pasting within
the same document.
Change-Id: If1dbc854c5faae62f06ece155fad470b229ca0c7
Since there are now 2 forks of OpenOffice.org, we cannot rely on a
simple total ordering of versions any more; add a new function
SvXMLImport::isGeneratorVersionOlderThan(), taking 2 reference versions.
Also extract the LibreOffice version number from the generator string,
and extend the BuildId property to store this as a third number.
This also allows removal of the "fake LibreOffice3 as OpenOffice.org
3.3 release" hack, which is not future-proof.
Change-Id: I44d8105eb537ac43fb9529a8b1b661ae0f2bba30
SvXMLMetaDocumentContext::setBuildId: check only the prefix of the
generator string, not all of it.
(regression from 17ff7b41d15ab9928e2e2706faa26234a09802cd)
Change-Id: I0cdd958d67cd13fd2368cc6958893ce3528a9e94
If all paragraph margins are 100% on import, ignore that as being the implicit
default. That avoids explicit 100% being set onto the awesome [UL|LR]Space
which takes a relative propsize of 100% as a flag that its value field is
absolute and so rejected by SwTxtFmtColl::Modify as a candidate for getting its
true value initialized relative to its parent, so it ends up as an absolute 0
Always elide the property on export because writing individual
margin-foos provides better backward compatibility with older versions
anyway.
Trigged by 3c5facfce42a0dbe362d6b9fa5ac374fd76f51a1
Change-Id: I55f6ceeae287b7d8e99befa4bd3cc06738a21299
style:table-cell-properties has new child element style:hyperlink which
will store the hyperlink info in attributes xlink:href & xlink:type
Change-Id: I184310d124c4242cd62fdabb45f9773094cfc229
This reverts commit 6eb0522395c236ae6930a300992ad092449f9592.
It does not compile and the message and contents suggest it probably wasn't
meant to be pushed.
Although this may seem consistent with remove( int, int ), it is
in fact rather misleading API. The biggest offender is most probably
buffer.remove( 'a' ) , which definitely does not do what it suggests
to do.
Change-Id: I287619cd4b953228b93fa68fb381d66c344c3865
Reviewed-on: https://gerrit.libreoffice.org/1256
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
most use of that API is to add a single sal_Unicode, it is
silly to manufacture a full OUString just to pass that via
AddToCode to then append it to a OUStringBuffer
adding AddToCode(sal_Unicode c) to simplify these case
also remove a silly iteration over a OUString's character to
re-add each character one by one via AddToCode()
Change-Id: Ia8a58551a1c24312baaa250b8d36fe21c46127e7
