To be used in regression testing and similar scenarios, where the output ODF
is *not* intended to be further manipulated in LibreOffice. An environment
variable LIBO_ONEWAY_STABLE_ODF_EXPORT is used to toggle this behaviour. I am
not 100% sure whether the generated ODF with the hack toggled on is even fully
correct, but correctness is not the purpose of the hack anyway.
Two classes of issues handled: 1) Automatic style names and 2) use of
randomness.
For class 1), when the hack toggle is in effect, we generate the names at
first as strings based on all the properties of the style, and sort them based
on those, and then rename them (for brevity in the output) to the "normal"
form of a short prefix plus a number (like "P12").
Sure, it would have been better to just figure out *why* the automatic style
naming currently is not stable in the first place, but outputs the styles in
different order (with some styles being assigned different numbers) in
separate invokations of LibreOffice), but I was unable to understand that.
Possibly this code could be used in all cases, except that it does break some
unit test (can't recall which right now). I don't know whether that is simply
because the unit test assumes too much knowledge of the internal workings of
the automatic style name generation, or whether the generated ODF is actually
invalid.
For 2), I found a handful of places where randomness was used to generated
various kinds of identifiers in ODF output. I changed those to just use large
(64-bit) non-overlapping integers instead. I assume there *is* a point in the
original code in each case that explains why randomness is needed, so the hack
definitely needs to be optional and used only for the above mentioned
scenarios.
Change-Id: I17b657197e38bcf24abdfe61ad4a277f4339eeae
The document itself is stupid and uses a SURROUND_THROUGH object with a number
of empty lines that make it act is if it in fact was SURROUND_NONE, rather
than actually disabling wrapping for the object and be done with it.
But the difference was that Word still managed to fit those empty lines
next to the object into the little space that was there, while LO already
considered the space too small. So keep a compatibility setting for Word
documents in order to avoid problems with such lame documents and hopefully
that's enough.
Change-Id: I7d17b90de381fd86914ce5efd9c5a29fe4850edc
It is a crude hack that is no longer necessary because the underlying
problems that caused crashes when deleting the layout have been fixed.
Change-Id: I601bdb0dc0aff5f4ddb8b8f4ba4c8d1f72c76666
CLOOK = "Compiler Limit: Out Of Keys", an error reported by Microsoft's
compiler a long time ago. No such problem in those versions we support. No
need to mention CLOOK in comments any more.
While at it, re-combine one large switch statement that was split to avoid
CLOOK.
Change-Id: Id93d973a5fb3c81b6c754eef0ba3b0bd55a649d2
Reviewed-on: https://gerrit.libreoffice.org/3640
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
...for the adjustments of certain AT_PAGE anchored objects
Addresses the underlying problem of fdo#37024 fixed by
9d32497c01
(cherry picked from commit b41eec25c2c6bc44eef55ae1c4ef57b9012fc8e6)
Conflicts:
sw/inc/doc.hxx
sw/source/core/doc/doclay.cxx
sw/source/core/doc/docnew.cxx
sw/source/core/layout/frmtool.cxx
Change-Id: I786eabdf84677e14c6f4b67d79e1e210e0532a21
The reason why a 1bpp virtual device is used in these two places in sc
and sw is unclear to me. It causes complications on iOS as such a
bitmap gets passed to CGBitmapContextCreate() which does not accept
1bpp bitmaps. But let's keep the 1bpp for other platforms.
Change-Id: Ia34927cf728d4be05a31e88b7da78200d0b799ba
In case the right margin is larger then the tab position (e.g. the right
margin of 7cm, there is a tab position at 16cm and right margin begins
at 9cm), we have a conflicting case. In Word, the tab has priority, so
in this conflicting case, the text can be outside the specified margin.
In Writer, the right margin has priority. Add a compat flag to let
the tab have priority in Writer as well for Word formats.
This is similar to TabOverflow, but that was only applied to left tabs
and only in case there were no characters after the tabs in the
paragraph.
In Word, the layer that contains a background image is behind the layer
that contains the paragraph background. In Writer, the paragraph
background is painted before the hell layer. Add a compat flag to change
the order, so the DOCX importer can trigger that.
To reproduce, create an XShape, send it to the background, set some
color for a paragraph background, and notice that the background color
is missing where the shape is behind the text.
Change-Id: I9b1fffd9ac9a6e5a1c3d1f65371440047d125b38
Word clips pictures that are bigger than a page instead of scaling them
down. This patch introduces a new compatibility option to allow clipping
a picture in Writer instead of scaling it down.
Change-Id: I4defbee05be81e23ec28a2ed272eaf4e4cc6faf5
The DOCX filter imports floating tables as frames containing a table.
Word ignores the margins of paragraphs next to such a table, Writer does
not. Add a compatibility flag the import filter can set that triggers
this weird behaviour.
Change-Id: Iaaa1d2a2e2f9d0eaea17832b2e418f9a845efffd
