Instead of a hard-coded check for (effectively) one project name
"LibreOffice" (which is build-time configurable), check for the string
"LibreOffice_project", which has been produced hard-coded ever since
LO 3.3.0.
This now recognises additional downstreams "LibreOffice_Vanilla"
and "Collabora_Office", and also historic "BrOffice".
An important point here is that the build-time configurable version
numbers of any downstream that retains the hard-coded
"LibreOffice_project" *MUST* be the same as the upstream's at least
in their major and minor versions (micro and further digits are
currently not used), and that such downstreams don't backport
changes with ODF export compatibility impact further than upstream.
Add a unit test too, with a representative sample of 4372 distinct
generators in bugzilla attachments.
This revealed that StarOffice 6 and AOO 4.0.1 were falling through
the cracks and not recognised, so fix that too.
Change-Id: I8105222d3428e7b20cc4a6b8e76732c697812594
Reviewed-on: https://gerrit.libreoffice.org/51171
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
... by merging all object-using CppunitTests into uxmloff, which is
already disabled for MERGELIBS.
Change-Id: I12ad08660fd714cceba2fe9b855cdb1bbda19c2d
This generates perfect hash for odf-tokens and use them with the tokenhandler.
With added test case to check to and fro mapping between tokens.
This is taken from Daniel's work in feature/fastparser branch.
Change-Id: I7cf77c1eb6c9dd68fd78108c6e0726507c7672e1
Reviewed-on: https://gerrit.libreoffice.org/28073
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
Set to true for export, false for import. If export true, an
XMLPropertyMapEntry with mbImportOnly==true is not added to the
mappings. This to be able to have more than one mappings for import
(for example a current extension namespace and the future namespace
proposed to the ODF-TC, or corrected typos in element or attribute
names), but map only to one entry on export, of course.
Change-Id: Ia01ea949c88eda2f8a6c10f51c59e35e7abdcaf3
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
Michael Stahl