Document encryption and decryption uses either NSS or OpenSSL to
calculate digest. Digest class hides the implementation details
between the two implementations. Previously, functions sha1 and
sha512 were used for this, but were less generic.
Change-Id: I60119e2ab9c5c1f4a2b02bc417c3c89c53a63fda
That's apparently the only proper way (to get e.g. -j right), and
even the toplevel Makefile is so full of gmake-ism that it simply
has to be invoked using GNU make already, hence $GNUMAKE is pointless
except for usage in configure (which says to start the build by
invoking it).
Change-Id: I6060da6f1dad2afc5845ac29b8ac02348c057d3d
The change in partial_build.mk assumes all the Makefile's using it
are in builddir/<module>/ , but that seems to be the case.
Change-Id: Iddc8fa2ec0842f181780f7491cf5a2244efd014a
Rework --with-parallelism to not add any extra -j to make if 0
or --without is used. This requires explicit -j usage, which
- builds even compilerplugins in parallel
- builds 'make -C sw/' in parallel (since you don't forget the -j)
- avoids jobserver disabling if -j is explicitly passed to the toplevel make
IMO this is just a relic of the old build system and the option should
be dumped altogether, but I don't feel like arguing right now.
Change-Id: I71479391bcfc84aa5e9fd9696880702da496d45c
A table, a row or a cell might have redlines objects attached to it.
This patch makes sure than when a table\row\cell are removed -
any redlines that are attached to them are removed from the
'SwExtraRedlineTbl' object. This is to prevent any 'orphaned'
redline objects.
Conflicts:
sw/source/core/doc/docredln.cxx
Reviewed on:
https://gerrit.libreoffice.org/8726
Change-Id: I992e3fb4aadeb891ffd472b5d638d337a8609c01
The BRC (BoRder Control) structure used in .doc files to specify border
properties has undergone several revisions over time. LibreOffice
supports the WW6 and WW8 (Word '97) BRC versions, which allow the border
colour to be selected from a palette of only 16 colours.
This changeset adds support for the WW9 (Word 2000) BRC version, along
with some new SPRMs (Single PRoperty Modifiers) which use it, so that
border colours are preserved accurately in .doc import/export.
This change covers:
- page borders
- paragraph borders
- borders around a sequence of characters
- table / table cell borders (import only)
Further work is required to extend coverage to borders of pictures and
export of borders in tables.
The LO code was using the same class WW8_BRC to store the bits for either
the WW6 or WW8 BRC. This becomes a bit unmanagable when adding a third
BRC version, so I have split this into a separate class for each version.
Fixes fdo#68475, fdo#50185
Change-Id: I7ebc15236497cbab9312d8659fe7ed0bee2c59ed
Reviewed-on: https://gerrit.libreoffice.org/8646
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This test shows wrong sha1 calculation after 52 bytes of input
data. For now this test is commented.
Change-Id: Id6df40ecc4059d4a4f9e1646a2c1bb7242f4cf69
- Docx file with chart in footer/header or .bin file referred in chart
was getting corrupted.
- Embedded file for footer.xml was not grabbaged.
- .bin embedded files were not grab baged.
- Added grab bag support for both case.
- Added UT to check .bin files are grab baged properly.
Reviewed on:
https://gerrit.libreoffice.org/8674
Change-Id: I221e3867798fc2a3a42f6385d687e80b80a3678f
These controls don't have a special property, like for example
unformatted text controls have. So we use the id property as a
marker; we will grab-bag it together with other sdt properties and
use the existing mechanism to write the sdt block on export.
A grab bag that only contains an id property is for sure a rich text
control so we add it to the character props and not to the paragraph
props, like in the case of the unformatted text control.
Word doesn't allow us to write an empty <w:id/> tag, so we fill
it with a random number.
Finally, modified an existing unit test to add a rich text control and
check it is exported correctly.
Change-Id: If403a4a2393d4ee069a628645e364d21f104a859
Flexibilize the way the grab bag in SdtHelper works, enabling it to
store several children of SdtPr.
For every tag inside SdtPr, we enable the DomainMapper grab bag,
store the children properties there, and insert the full grab bag
inside the SdtHelper grab bag. In this way, the SdtHelper grab bag
becomes a Sequence of pairs "SdtPr token name" -> "Bag with children
tokens and values".
The first advantage of this implementation is that we can preserve
dataBinding sdt property plus another one of those supported; until
now the second property overwrote the first one in SdtHelper bag. In
further patches we will add support for other tags.
Some lines are incorrectly indented to make the purpose of this patch
more evident, and will be corrected in the next patch.
Change-Id: I0ec7be7b96dca455bbbeb03fc2fed230df04c52a
Used the same algorithm that we had for VML to update the position of
the DML anchor taking into account the rotation of the shape.
Complemented the unit test to check the values in the generated DML.
Change-Id: Ie0293c3cf4d1309fad58c0387f1589e69071fd9a
