http://opengrok.libreoffice.org/xref/core/sw/source/core/unocore/unosett.cxx#1884
Modifies the refernced style of the numbering rule to use the current numbering rule.
Actually the refernced style is not supposed to be modified.
As the numbering level formatonly uses that properties particular style,
which may or may not be a numbering style
For this Particular document the numbering format refers the "Default Style" (Normal).
Almost all of the styles in style.xml are based on it. Normal was modified,
and as a result the whole document was bulletized; Which caused the hang while opening
Removed the addition of style as a PARA_STYLE, as the properties of the
refernced style are already added in ListLevel::AddParaProperties
Conflicts:
sw/qa/extras/ooxmlimport/ooxmlimport.cxx
Reviewed on:
https://gerrit.libreoffice.org/9668
Change-Id: I8cc143805a38613908d2e2cb4827882d4cf40a78
It's shorter and f9bf15e19ec823a58ee32bf94da81f3bb1a147bc (writerfilter:
initial strict DOCX support, 2014-03-07) shows it's a pain to do anything
non-trivial with XSLT 1.0 -- in that case black magic was needed to do a simple
unique sort.
Change-Id: Icf4e7b580ce1db6826989500dbf4a012d79acdb9
by attaching adjustments to them. This restores pre-ui behaviour,
as without proper initial minimum value, one can't enter values < 0
into the dialog
I just copied the numbers as they were in .src file, but they were
prolly completely made up (and they're adjusted later anyway
according to size/position of workspace)
Change-Id: Ic09fdd9e947f04d6f2151e9d7a8714f4f1d29552
Always quote the passed string; this cannot handle arbitrary strings
like $(file) can, but everything that is needed currently.
Also, try to ensure that output does not start with a space.
Note: there needs to be a newline at the end, otherwise helpex
ignores the last item on the line.
Change-Id: I51a4058591cc4f12dd878c2d113bd5cfc8c22d61
It looks like what works is to give the source file names with
backslashes but everything else with forward slashes?
Change-Id: Iaf910ab5fc41984d1315a30b164a334d28344c16
When building with Win32 make, the xcopy at the end of the build fails
with "Invalid arguments" error, which is clearly wrong, since the
arguments are exactly the same as before, and furthermore curl is not
built with GNU make at all, but with nmake! W-T-F?
Change-Id: Idc0b362202e1d14722573662bebeda0bc7070660
This much ugly complexity, generating a header on every gbuild startup
etc. is really not warranted for 6 callers of the generated macros.
Also, the Win32 make has problems with the quoting.
Change-Id: If945e09c1730e52174a6084677842dc611d66b2f
Try harder to handle app bundles with space in name. (Not sure if this
version yet does that 100%.)
Include the directory names in the "ids" to make them unique. There
are lots of files with the same name (in different directories, of
course), especially in an app bundle that includes help in multiple
languages.
Change-Id: I424c539f6389ac6f7c9cef96aeb873ddac459f78
The LinkTarget command builds the LinkTarget's dep-file as well as an
optimization so the next make does not restart; in this case the
dep-file is not the target so it will not be deleted by make in case the
build is interrupted, and the next make can choke on the partially
written .d file.
Change-Id: I13b1884f1a974b7ce10b00e1df1d0f30222f4790
This has been broken since 3.3(!), when the old XSLT based import/export
was replaced by a library.
Change-Id: Id335f296c5a0e2c15d1748f8a14ac8d4001e1d15
