Although LO could round-trip the files, MSO didn't open
them properly, indicating both import and export differences.
There are two table justification codes: sprmTJc and sprmTJc90.
LO appears to treat sprmTJc90 as the WW8 version, but actually
both are valid. TJc is the LOGICAL justification - meaning that
it is affected by RTL/LTR settings. TJc90 is the PHYSICAL
justification, regardless of BiDi.
https://msdn.microsoft.com/en-us/library/dd951612(v=office.12).aspx
Based on testing results, it appears that MSO REQUIRES TJc codes.
If it isn't defined, MSO uses the default value of TJc:LEFT, and
ignores TJc90 code. It appears that MSO always writes out
both codes if they aren't the default values.
This patch only deals with the export difference.
Change-Id: Id722261acab7ae6c0b7d808be75fc3452c2255d8
Reviewed-on: https://gerrit.libreoffice.org/41584
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
The code that this comment documented was /* ... */ commented out
in 2004 commit ed9a3e51ef
That dead block of code was removed in 2010 commit
6eb5f64fd8
but they didn't take the comment out with it.
Change-Id: Id0ef75c09bd060e2621400492fb404eebbee6385
Reviewed-on: https://gerrit.libreoffice.org/41581
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
AppendRedline() has a boolen return value which is rather
unclear and confusing: most callers don't even check it, but
SaveMergeRedline::InsertRedline() expects "true" to mean that
its redline hasn't been deleted, whereas makeRedline()
expects "true" to mean that the redline was somehow "valid",
even if it has been deleted and merged with an existing one.
The "bMerged" variable in AppendRedline(), which is the source
of the confusion, was introduced with commit
81286906d0 "docx import fixes
for: redlines".
Split these differing expectations into different return
values of a new enum type.
Change-Id: If81631bde49ee52a249f5ba1dd64ab8e92fffaf7
The assumption in using std::size_t is that every acquisition can be associated
with a unique memory location in the local address space, so the counter cannot
overflow.
Change-Id: I0d004a81d9bf52cf07d13481d9024fcc10b6db6d
Reviewed-on: https://gerrit.libreoffice.org/41580
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
On a tinderbox, CppunitTest_chart2_export crashed in
basegfx::B3DHomMatrix::isEqual(), with other threads in other basegfx
code.
The UnsafeRefCountingPolicy on the global IdentityMatrix is likely the
problem.
Change-Id: Ib142c6f286453d61bd948fb0c184cd68fd313b0f
In the Java UNO bridge, UnoRuntime.generateOid() generated the
object-specific part of the OID using java.lang.Object.hashCode(),
which is only 32 bits long, and is commonly overriden and could thus
return values from an even smaller range, so OID collisions were quite
likely.
This changes UnoRuntime.generateOid() to use 128 bit UUIDs for the
object-specific part of the OID, and store these in an object => oid
java.util.WeakHashMap, making OID collisions almost impossible.
Patch by: me
Suggested by: Stephan Bergmann (stephan dot bergmann dot secondary at
googlemail dot com)
(cherry picked from commit 6dd83d1c6c5c580d14ca3d0458be4020603ba118)
Change-Id: I8e851a7a69ac2defefa15e9a00118d8f9fc0da95
Reviewed-on: https://gerrit.libreoffice.org/41576
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Turns out that XErrorHandler can throw SAXException too, which isn't
derived from RuntimeException.
Change-Id: Ib853805259b5b32a979e4f9a20297975431dee08
EPUB_SPLIT_METHOD is still hardcoded to HEADING, so while we send the
page break info to librevenge now, it's ignored on that end.
This requies basic infrastructure for automatic styles.
Change-Id: Ibafead0dedd9dbfa6223a9c701a62611ba2671fd
Reviewed-on: https://gerrit.libreoffice.org/41573
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
By parsing the FilterData key of the media descriptor, similar to how
the PDF export does it.
The default is still EPUB3, but this now exposes the ability of
libepubgen to emit EPUB2 if wanted.
Change-Id: I23834fa28db9b01ef4cce4a142331b1cc9ecb3c2
Reviewed-on: https://gerrit.libreoffice.org/41566
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
Create an ScColumnsRange class that returns a pair of (start,end)
iterators to go through the list of currently allocated columns.
This is a fairly thing wrapper around the underlying std::vector,
so it should be fairly efficient (two pointers, and pointer increment
for iteration).
If this style of iteration is acceptable, I'll go through the rest
of the code that does:
for (SCCOL nCol=0; nCol<MAXCOLCOUNT; nCol++)
type stuff, and change it to use ScColumnsRange.
Change-Id: I81501c69b7f5566c6204dde0d87a6fe0deb9743c
Reviewed-on: https://gerrit.libreoffice.org/41413
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Rename the global opencl namespace to openclwrapper. Its public API is
after all declared in a file called openclwrapper.hxx. The confusion
started when part of the OpenCL code was moved out from sc some years
ago.
Change-Id: I98ebd8498b2244804411e5de9169eb619f86070b
Test for this comment in d59ef5b2dd
// We should bring it to front, even if wp:anchor's behindDoc="1",
// because otherwise paragraph background overlaps the graphic
// TODO: if paragraph's background becomes bottommost,
// then remove this hack
Actually, the proper fix for this would be that the paragraph
background also "wraps" around the picture (just like the text),
not that the paragraph background becomes bottommost.
The main concern in forcing to the foreground would be if
wrap_THROUGH text would become hidden. However, testing suggests
that cannot happen in this code. In that case, the worst
would be that this shape now overlaps another shape - a
rather unlikely situation. So this hack should be safe and
maintained since it visually fixes a compatibility problem.
Change-Id: I96495cd08a580afbca71a7f6d6dfd85652ff021b
Reviewed-on: https://gerrit.libreoffice.org/41487
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
In documentbuilder.cxx added code to call XErrorHandler::warning and XErrorHandler::error functions (from DOM::warning_func and DOM::error_func)
In domtest.cxx added try {} catch () block to BasicTest::validInputTest, BasicTest::warningInputTest and BasicTest::errorInputTest and to SerializerTest::serializerTest. Also uncommented lines CPPUNIT_TEST(warningInputTest); and CPPUNIT_TEST(errorInputTest);
Unit tests are now working
(FatalError test removed, as lib2xml doesn't distinguish between error and fatal error and counts everything as error).
Change-Id: I27c5036df6a1cc5bef5dbb8171c201d81bae2ccd
Reviewed-on: https://gerrit.libreoffice.org/41376
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
When opening a file that triggers Dialogs (e.g. cannot
read/repair/FileType) the Frame from which it was
initialized gets blocked. This irritates quite some
people. Changed this to a non-modal Dialog so that
the user can continue to work with all opened docs,
open new ones, close and print/PDF/export these.
Change-Id: I048d3de3369527cec20d26396b87439254764b8a
Reviewed-on: https://gerrit.libreoffice.org/41534
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@cib.de>
The second cTn tag needs to have a dur="indefinite" attribute, otherwise
the last element is hidden immediately after being shown. Also the value
of all fill attributes with the value freeze needs to be hold, otherwise
only one animation node is shown at a time.
Change-Id: Ie4ecf69f5a3a1c56d8b3b489351dc2882efd6328
Reviewed-on: https://gerrit.libreoffice.org/41463
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Relative links were saved as:
file:///a/file.odt
instead of:
../a/file.odt
Relative path was based on source document, not target.
Unit test contains spreadsheet with relative link
to the "../xls/bug-fixes.xls" file.
Change-Id: I803b7b8936bde9644ae5760756ee7249677f2641
Reviewed-on: https://gerrit.libreoffice.org/41500
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Szymon Kłos <szymon.klos@collabora.com>
