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>
