Age | Commit message (Collapse) | Author |
|
Change-Id: I03f24e61f696b7619855e3c7010aa0d874e5a4ff
|
|
Change-Id: I9dfe4557a471f1b33cc4cad879bec1797e03f8d1
|
|
It doesn't do anything useful yet, though.
Change-Id: Ib6574f79996cfc7b09596f8aba21aaf106ee7c79
|
|
BAILS says the document metadata must mention this, BAF says that the
BusinessAuthorization has a policy name, but the published XSD doesn't
give a way to express this in the XML instance. Use this markup till we
figure out if there is a better way.
Change-Id: I8e3550c0445b2d143a1f7e0c69b39b6c759f468e
|
|
Change-Id: I23c0227ee304a6b756ff3d474866609d95e6a071
|
|
This one has 4 choices, it shows how a category can trigger a specific
header, footer or watermark. Also validate the XML file against the XSD
as part of the build.
Change-Id: Id6cf3de63e7fadd16366465c7721d6052c7c60ed
Reviewed-on: https://gerrit.libreoffice.org/22615
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
The classification infobar loads the classification value from the
document metadata. In order to add metadata to a document from the UI,
it's necessary to know what are the possible choices. Those choices can
be described in an XML file. The format of that XML is described using
this XSD schema. baf.xsd is the main file from
<https://www.tscp.org/wp-content/uploads/2013/08/TSCP_BAFv1.pdf>, the
rest are just the dependencies.
Change-Id: I6b22c0279031799cafa4fd6edd20ed1cdb09c8cc
|
|
...WebDAV elements.
WebDAV UCP provider maps UCB 'Size' property to 'DAV:getcontentlength'.
DAV:getcontentlength property is defined in Section 15.4 of RFC4918.
<http://tools.ietf.org/html/rfc4918#section-15>
Change-Id: Ie91d1f2aed417002f4d1ecae3e1188123c04d35b
Reviewed-on: https://gerrit.libreoffice.org/22511
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
|
|
Change-Id: I07e22f16cfa0229f609e7fc406e98e9f0c843153
|
|
Change-Id: I25ca238931da039c244c2af6171d69c9875f95ff
Reviewed-on: https://gerrit.libreoffice.org/22501
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I0f83939babacf92485420ee63f290a297d7cb717
Reviewed-on: https://gerrit.libreoffice.org/22498
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I43c6537290aa5ce8a9dcc034d4ff6776668cde0c
|
|
Change-Id: I73151a78d1b396179776847d6fbb2da1dd8755e8
|
|
Change-Id: I32bb73dfd8ecb78bb2eb9907b0c008e84fd2233a
|
|
It would be easier to set these after the infobar is created, but the
infobar is shown right after creating it, so that way the infobar would
be always yellow for a short period of time -> annoying flashing.
Change-Id: Ie23efd2fd1bba624cf2921f11a6fc40014ac4215
|
|
Change-Id: Ia32492965a0802a848215c86fdc07e14648d3d58
|
|
stage 2 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
In this stage we focus on replacing usage of the WIN macro
Change-Id: Ie8a4a63198a6de96bd158ecd707dadafb9c8ea84
Reviewed-on: https://gerrit.libreoffice.org/22393
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: If8fe5b145014055639a9a2eadd8fded7ebf7c2b3
|
|
Change-Id: Idd4b886e246cb41d3a3b871eeb368c0620b110ae
|
|
A document's metadata has predefinied keys like title, and has
user-defined ones as well. The BAILS specification at
<http://www.tscp.org/wp-content/uploads/2013/08/TSCP_BAILSv1.pdf>
describes a mechanism to use the generic user-defined key-value pairs to
embed classification-related (read: is it public? is it internal only?
etc) information in a standard way.
One approach in handling these in LO would be to let code here and there
parse these user-defined key-value pairs again and again. An other one
would be to handle these as first-class properties, even if the majority
of the users would never need them. A middle between the above two
approaches is this class: all these properties are still just
user-defined properties, but if the document has them, then all related
code is supposed to be implemented in this central class.
Change-Id: Ib0297a5e91779b330c310a153f1a1628759dd028
|
|
This helps reading document metadata with more than a few characters.
Change-Id: Ia9f5bc4a05835ef5512bf6f4a4ec2b2e4274c41d
Reviewed-on: https://gerrit.libreoffice.org/22398
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
stage 1 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
Change-Id: Iece73abdee530937e0737190b1aa97a46cd3075f
Reviewed-on: https://gerrit.libreoffice.org/22390
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ibdeec746e9664f8bfe4e2af9afb8e5ec0142bd08
|
|
After the import some of these are kept in RUNNING state. For Math
objects imported from MathType3 OLEs in particular, first a new
Math object is created and stored to the XStorage, only then is the
MathType3 stream imported. This means the Math object is modified and
contains data that must be stored.
The problem is then that SfxObjectShell::ImportFrom() simply calls
setModified(false), clearing the flag without storing the object.
For Flat ODF export we lose all the objects that are cached in sw's
SwOLELRUCache; for the bugdoc something more inexplicable happens for
ODT export where we lose "Object 214" (which is the first one in the
cache) but no other ones.
(The main difference is that for ODF there is an optimization to copy the
embedded object's storage without loading the object, but for Flat ODF
every object must be loaded and exported.)
(regression from 83777cd6e0f3f1a4458af896fd13344c696ecb1e)
Change-Id: Id1474fba9f4da2d5247c7ff4dc6819ddb9829fe8
|
|
Change-Id: Ia18c3044aba82f935b13f22ba98aff42e9d5098f
|
|
this is useful now that we are storing UNO structs in std::vector
Change-Id: Ic558bcd669bd2b3cdf9eb8393269eb906ac52369
Reviewed-on: https://gerrit.libreoffice.org/22257
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
+ Removed comment cruft
+ Tab formatting in number of files
+ Some commented out code removed
+ Tab characters replaced with spaces
+ Newline cleanup in quite a few files
+ Tweak header guard #endifs
Change-Id: I3208ff2f047da890edcc49b73389aca22442f5fc
Reviewed-on: https://gerrit.libreoffice.org/22221
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Also included .uno:InsertPage, .uno:DeletePage and
.uno:DuplicatePage
Change-Id: I91dd2609d6a48be75005a44490614bcf8bcf62e9
Reviewed-on: https://gerrit.libreoffice.org/22195
Reviewed-by: Henry Castro <hcastro@collabora.com>
Tested-by: Henry Castro <hcastro@collabora.com>
|
|
<sberg> noelgrandin, just happen to look at b14224fe again; looks a bit scary to remove == or != from cases where both where declared
<noelgrandin> sberg, ok, I can revert that part
<sberg> noelgrandin, I guess that would be safer (there could be cases where now a different overload could kick in)
Change-Id: I5dc41c05dc4439d5adee0e5b3e0a9e1dfb9de3af
Reviewed-on: https://gerrit.libreoffice.org/22211
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ic42f7218bda81effe870d950f666ba7653d60c66
Reviewed-on: https://gerrit.libreoffice.org/22177
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I742e83bd455bc0efa4ad5a34575d3255c3a9a16f
|
|
Change-Id: I21bcf66c552cd38eaae1bdc85626aa9bd1782ebd
|
|
Change-Id: I78784abc1031027d69bbe31d150bc78c8bfbfcf4
|
|
Change-Id: I4586168d3af81f047a4ded59fc6d257f17554885
Reviewed-on: https://gerrit.libreoffice.org/22194
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: jan iversen <jani@documentfoundation.org>
Tested-by: jan iversen <jani@documentfoundation.org>
|
|
found with a bunch of grepping
Change-Id: I920609fb7df5a5e55ecbf5c2bf4880ff972cfbed
|
|
using an idea from dtardon:
<dtardon> noelgrandin, hi. could you try to run the unusedmethods clang
plugin with "make build-nocheck"? that would catch functions that are
only used in tests. e.g., i just removed the whole o3tl::range class,
which has not been used in many years, but htere was a test for it...
<noelgrandin> dtardon, interesting idea! Sure, I can do that.
Change-Id: I5653953a426a2186a1e43017212d87ffce520387
Reviewed-on: https://gerrit.libreoffice.org/22041
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
.uno:CharBackgroundExt is supplementary to .uno:BackColor.
When .uno:BackColor is set, Writer turns into a 'watercan' mode, where the
user directly marks parts of the text with the wanted background color.
.uno:CharBackgroundExt then controls this watercan mode - dispatching it
toggles the watercan mode on/off, and also the StateChanged events reflect the
on/off mode accordingly.
Change-Id: I6472eb39129d1b1517fba14bad584cbd125e826a
|
|
A 'signatures relation' is kind of a pointer that says where is the list
of signatures. When adding the first signature, this has to be created,
in addition to the actual signature relation.
This is yet another difference to ODF signing, where the signature is
just another additional stream in the package, while OOXML signing first
modifies the package to add the signatures relation, and then signs the
streams, so the input storage of the OOXML signing can't be a read-only
storage.
Change-Id: I81a976c945b28ddf7f347c4a7bfd51f98a1fc225
|
|
Change-Id: Ic78ae8ce5bf396f55fdc847d6b70476c9dab4ee9
|
|
Change-Id: I29f039c2fec8433fa062c603b64afffa60e7b0d0
|
|
Change-Id: Ice72f8d9971e15dd6ef365e64cd567b8581a92d3
Reviewed-on: https://gerrit.libreoffice.org/21797
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
Change-Id: I1e893afcd33bf9a5cf934a021fe40548ddc33699
|
|
Change-Id: Ieb3e47c10c497a6f642f28a6741ac0fd2ecfd419
|
|
Change-Id: I179200ad65492c517ef5e986fd05758896d38813
|
|
Change-Id: I65e1ca6e022dc76ac96ed75da2c5e78e9356a3e9
Reviewed-on: https://gerrit.libreoffice.org/22107
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Instead just pass an empty stream, xmlsecurity knows how to look up its
signature storage from the root one.
With this, opening the digital signatures dialog, clicking on add, and
then OK in both dialogs no longer results in an (empty) META-INF storage
written to an OOXML file.
Change-Id: I7e4a93687465ec19be307917ec00cde08ed8092f
|
|
Change-Id: I74404d72e9146950a9881d2a59323c2bf08c9742
Reviewed-on: https://gerrit.libreoffice.org/22100
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
File -> digital signatures looks like a way to view and modify digital
signatures, internally it's a sign action, that at the end may not modify
signatures after all. For this to work, SfxObjectShell::ImplSign() calls
GetMedium()->CloseAndRelease() to release the document's lock file, invokes the
signing dialog, then DoSaveCompleted() creates the lockfile again.
When signing OOXML documents, the lock file is not re-created, as
DoSaveCompleted() only creates the lockfile in case
IsPackageStorageFormat_Impl() (== own format) is true. Fix this by adding a
mode that creates the lock file, even in case of a foreign format.
With this, closing the digital signatures dialog for OOXML documents no longer
results in a confusing "Document in Use" dialog after closing the signatures
dialog.
Change-Id: Ie9e56b88768825e61765669b27a89082cdc1981f
|
|
Change-Id: I26f2cef48fcc7a6c4a6b93668b836879254f3eb0
Reviewed-on: https://gerrit.libreoffice.org/22098
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|