Even if current fill is not "use background" we should reset useBgFill
explicitly, since this value could be set from master slide and was
nested in current shape.
It is somewhat confusing to have fillStyle as none and using slide
background at the same time. So better to clean it explicitly.
Change-Id: I0d817dc295785be7a6cb8f884d5023d316cd2ebf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165994
Reviewed-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
Tested-by: Jenkins
Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de>
And a demo implementation for these features as a taskbar window
will become red once LO is displaying any error message.
Change-Id: Ifc04026c699059da2e457de2c69e7363e756109c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166740
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
FlashWindow() can be used to bring user attention to application
in background. Right now in LO it has implementation only for
Windows. Here some new cases were added when flashing is used:
* dialog window did open
* document loaded
* LO started
Some redesign of previous solution is also performed: no manual
search for top window, let's reuse existing code.
Changed behavior for bringing LO window to foreground: it is made always and not depending on current value of NewDocumentHandling:ForceFocusAndToFront. It has no sense to tweak this behavior: if user clicks on document in file explorer, LO should came to foreground, no exceptions.
Change-Id: I22b5b4e2b170cd25632083a55b3e9f0358bcae03
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166615
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
To improve LibreOffice UX it will be great to have possibility to
signal user on some event did happen, but without capuring focus
and bringing LO to foreground, like it is happenings sometimes. It
can be annoying.
For example, if dialog window is opening slowly and user did switch
to another application, this is used to inform user that there
are some updates in LO window: dialog finally alive.
There are somewhat confusing implementation of this feature: VCL dialog
window became visible and actual Windows window should use
::FlashWindow() are very different in hierarchies, so it is somewhat
challenging to find window to flash or even decide shoud we flash window
or not.
Change-Id: I6ca6706d2dda8902aea273ebe6e318ec9bf4beda
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158472
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Fields import was not using current run properties causing
fallback to used style or default style what is wrong for RTF.
Change-Id: I0189c6122b703a23ff910ee38da78aa05ac4d9f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160387
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
This table is not standard extension to RTF format. It is not
described in RTF specification and even is not used by Writer
on import these days.
Change-Id: I52f27dfd30877d461ad535b7847f40dd4c6f4ea5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158986
Tested-by: Jenkins
Tested-by: Gabor Kelemen <kelemeng@ubuntu.com>
Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
- these days hard to find a reader not able to read shapes
- RTF file will became compact without pictures duplication
- WordPad nowadays is able to display shape pict, no reason
for fallback
- Fixing possible rtf file bloat on exporting some WMFs
Change-Id: Icc8b60da6541acef939f42021d8d5e81bbcd1ae4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158507
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
Since long time IF field was converted to ConditionalText, but no
parameters were given. So condition, then text and else text were
lost during import.
Change-Id: I9b45e8ab394f3c53bb34370bf3ea15a939a400fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154101
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Properties applied to document shoudl be a case only for new doc,
but DomainMapper can be called during pasing of RTF and cause
modifications to props in already open document.
Tested only for "NoNumberingShowFollowBy" but I assume this is
a case for all compatibility props.
Change-Id: I4558d809ca477918373b15fa05500ed985e170a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151069
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Writer does insert document variables only if they are in
document body as DOCVARIABLE fields. But ones given in
settings.xml (w:docVars/w:docVar) were ignored.
Moreover variables in settings should have priority and
overwrite ones in fields. Word by default does show only
field results, but refreshing field values will override
values with ones from settings.
Change-Id: I7103c90eef59ab18f8a25e616dcf8a8b1c6dcb08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149646
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
If cell width is not given or zero lets not confuse it with too
narrow cell. Lets keep zero to allow domain mapper define some
width.
This patch does not solves autofit issue completely, but finally
tables with autofit are visible somehow and do not contain cells
with minimal almost invisible width (41).
Change-Id: I640228ed117f1d65dde9753a00b8403dda45dd40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145148
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
Table shift based on cell lect margin should be applied
for DOCX (earlier compat options) but not actual for RTF.
Maybe earlier RTF version did behave this way, but nowadays
this behavior does not match MS Word 365.
Change-Id: Icdc4fa6298167fe5f263c85164d7c4c4176be25f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145088
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
If numbering is not explicitly mentioned in para properties
it should not be used from referred paragraph style. So
default value of 0 (no numbering) is used by default.
Change-Id: If8e8f2aaf19190f64a557444188f67b24a699b54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144839
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
In Windows, files get assigned security zones (local, from intranet,
from internet, etc) after download via browser or email client. This
is used by MS Word to decide in which mode it is safe to open file.
This patch implements basic support for similar feature: by default
there are no changes in macro behavior. But it is possible to use
expert configuration options to tweak default behavior, and for
example disable macros automatically, if a file is downloaded from
Internet or other unsafe locations.
Change-Id: I0bf1ae4e54d75dd5d07cab309124a67a85ef2d4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143680
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
If referred paragraph style is not found or it is not a paragraph
style, this can lead to exceptions in writer core and thus current
paragraph can be not corretly initialized. For example, numbering
can be not applied because of exception of not found style earlier.
This is not a critical error, we should just not apply a style
we could not resolve.
Of course such documents are invalid but bit more tolerance to errors
will not harm.
Change-Id: I9150786e6357a7d6098440bac29ec501fc6aa802
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144852
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Failure in XPath processing during retrieving fresh value from
data source is not a critical problem and should not cancel
document loading.
Just put warning in log and continue to eval further.
Change-Id: I76ecf0e0e227f46a270db3e77d86c19f7e9ad21a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142428
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
In case of unicode used there can be tokens, replacements, etc.
So it is better to collect and join all received strings, not
overwrite with just last received.
Change-Id: I2b6ce465d87db4ee30987cbe0ecce1470386242f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141007
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
We need to identify XML document to use by storeid in sdt block
and in properties of external XML file. Otherwise are possible
content collisions when same xpath can evaluate successfully
absolutely unrelated custom XML.
Change-Id: I6d201a539130b110046deb1818340513cc47a061
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139771
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
If RTF shape contains pib (embedded picture) we should override
any picture sizes by values from shape. Values provided inside
\pict are ignored by MS Word; only shape values matter.
To achieve this we need to know shape dimensions so it's
calculation is moved to earlier step before internal picture
eval.
Change-Id: I99c1af7ba62c343b64b3db734b837ff101483ad8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139043
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Usage of INetURLObject makes sense only in case of full URLs,
but once relative one is provided it will contain invalid data.
Change-Id: Icc5e191e2337a3dd9a76c660b1c7709551099a1a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138875
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Previously generated name was assigned only if not in doc
reading mode. But there is no guarantee that it will be assigned
later. Better to insert any name in SwDoc::MakeFlySection_() and
later it can be overwritten, but fly will definitely have
any unique name.
* Some test failed because GraphicImport_Impl::applyName() overwrote the
name with a different generated one.
* This breaks chaining of VML shapes, see test testTDF87348.
The code introduced in commit 091fe76b63
in DomainMapper_Impl::ChainTextFrames() breaks if the text frame
already has a name; it's a bit confusing which names there come from
the file and which come from the API, and it also mixes 2 different
cases of VML chaining and DrawingML chaining that look like they
should be using different data.
* This also breaks moving flys anchored at-char in flys into them in
SwXText::convertToTextFrame(), see ooxmlexport13 testFlyInFly.
This kind of worked by accident before: the fly is copied and then the
original deleted, keeping the same name (with help of
SwDoc::mbCopyIsMove); with no name it would compare the SdrObject
pointer, which is different for the new copy, now the name is the
same.
Fix this by only moving flys anchored at the edge of the selection
back inoto the body; it turns out that Word actually supports at-char
anchors in text frames, but only if it's a VML shape or Compatibility
Mode or whatever; i wasn't able to do it in a document created from
scratch.
This is a bit tricky to ignore the nodes added for floating tables as
seen in ooxmlexport10 testFloatingTablesAnchor.
* Another change is required in SwDoc::SetFlyName() because of
testTdf127732, as it would rename a frame named "Frame1" to "Frame2"
when called to rename it to "Frame1".
* Some tests failed because after MakeFlySection_() assigns a name it is
immediately unconditionally overwritten; replace that with asserts
Change-Id: I46752a4413ba3a9e981eccd1e153b3aaf8053781
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127556
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
...even if numbering is empty.
Since this is a core change to avoid impact on other formats
(mostly ODT) it is implemented as a new document setting.
Change-Id: I35e1cec97eb40f9f3411e3ba74cb553bd8afac59
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134989
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
...and in this case file name will be not parsed and --attach-name
parameter will be empty. This leads to missing file name of
attachment. In case of Thunderbird it is not a big problem,
but Outlook does not want to attach .tmp files: it is "potentially
unsafe attachment".
Change-Id: I7c2f696391e1183211a169b08004c6668771f288
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137480
Tested-by: Gabor Kelemen <kelemeng@ubuntu.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Quite complex conditions to define if current paragraph can be
removed for document were forcing to keep paragraphs after page
break with only section definition. Usually these pars are removed,
but since tdf#103975 fix they were kept.
It looks like to resolve that problem will be enough to ensure
current break is a column break: they are bit different and
processed in a different way unlike other break types.
So this condition part instead of "do not remove par with section
info after any break" it is right now "do not remove par after
column break".
Change-Id: Ib6290dc6254430883a598bef3ecd1f7ab7063922
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135969
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
If there is no color value we should not also try to write
transparency information: otherwise w:srgbClr will have no
parameter value and MS Word won't open such documents.
Change-Id: Id67f174c5ae9aadf90ae54c126aef9a43ff3ba17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134945
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Seems original problem is no longer reprodicible with recent builds
but ovewriting of numbering style params with inline values leads
to another problems.
Removing this mechanics do some impact on RTF filter: it tries to
modify numbering styles, so this was also corrected. It is not ideal
yet but looks better in support numbering char properties different
from paragraph ones.
This reverts commit 2123ede032.
Change-Id: If8c79d6191de13b2f09c128b59d17efcfdb1a4ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133877
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
On save LO was just emitting w:lvlOverride to actual level
where override does happen. But MS Word won't accept override
for next level if there are no overrides for previous ones.
For example, if we are overriding level 3 we should also emit
empty lvlOverride for levels 0-2.
Provided fix did cause some problems on DOCX import: overrides
were applied to current level, but in this context current !=
actual level where override did happen.
Change-Id: Ia00dd9a5990f7f122027e8126f411642c32da189
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134411
Tested-by: Jenkins
Tested-by: Gabor Kelemen <kelemeng@ubuntu.com>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Inernal hyperlinks to bookmarks should not contain spaces. This
is not required for RTF or DOC: MS Word is okay with spaces there
(unlike in DOCX). But since we are replacing spaces in bookmark
names we should do this also in links to these bookmarks.
Change-Id: I7a3e530817572ed53032c2be1ad96f8e8498bac3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133590
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
During deduplication of table row (when nStyleType == 0) we should
not deduplicate character properties against default style: this
leads to invalid default settings for table rows/cells.
Attempts to do so are already made during \pard processing when
default style is checked if it is paragraph style. But this is
not enough: style definition can contain paragraph and character
properties as well.
Change-Id: If520c5a248897728b7de08a017136ca1a01a5f13
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132943
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
RTFValue in most cases contain only one value: either num, string,
picture, etc. No reason to allocate all of them in the same time.
RTF filter should became faster and consume less memory, however I
did not made any measuremets.
Change-Id: Ic12a941ce774b9066d7c57b38139af07851ac7b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131720
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Previous fix for tdf#146257 was not complete and was not able to
take care of disabled numebering started just at beginning of the
numbering string.
UI test test_tdf144439_outline with modifications is covering this
situation. No need in extra testcases.
Change-Id: Id17838cec7fb4fb039f9b457b7ee9ad3ab345678
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133124
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
My previous implementation was changing current format selection
only for field edit dialog. However it should be initialized also
for insert field dlg. It is not always first element. Instead of
older confusing approach right now there is a switch to set
defaults: it is less confusing IMO.
Change-Id: I189339ba66effc49267004a42345a28892cb693c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132980
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
While font name in font table should end with semicolon
({\fonttbl{\f42 Arial;}}) it is not always true and
MS Word is tolerant to it: it still able to parse this
correctly. Seems LO also should not require strict spec
conformance.
So idea of font parsing is changed: instead of inserting
font on semicolon, it is done on next \fN or destination
end. All collected text to this moment is a font name.
Change-Id: I6b41951217442a71fd2ebbfc58a3fc79f6f913db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132686
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Font names like "Arial CE", "Times New Roman Cyr" are not special
fonts. They are classical Arial, Times New Roman... And these
suffixes can be used to detect encoding used for RTF text.
Most interesting: for MS Word these suffixes have priority:
{\f34\cpg1253\fcharset161 Arial Baltic;} will have cp1257
and not cp1253.
Looks like compatibility issue came from dark ages.
Change-Id: Ife8e781d5d04c3f6a8c11fcf604357c74bf33055
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132584
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Writer does not support border in between available in all MS
formats. Since this feature is missing in core it will be
better to emulate it with top borders than to ignore it
completely.
Change-Id: I4e5a99cde5908066c4bb483136cfe9a1316df53c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132429
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Like in DOCX for RTF there is exactly same behavior for paragraphs
inside cells. They do affect table breaking over the pages.
So:
1) Enable "TableRowKeep" doc setting for RTF documents.
2) Do not ignore \keepn token for paragraphs in tables.
Change-Id: I11e45ca9114c792b8cdbeb77dd51359717129651
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132305
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
It is quite unexpected Word behavior: if data source for sdt field
exists but contains empty string it is not used. Placeholder is
inserted instead.
In general behavior is more complex: logic of replacement is defined
by <w:showingPlcHdr> property and results can vary (see testcase).
But LO does not support this property correctly yet.
Change-Id: I2ec8efe05f79a01af5d74d21bfcd05f3b19e3970
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132096
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Unlike in DOCX in RTF token \clshdngN can represent much more
transitional cell shade values from 0 (white) to 10000 (black).
So we should not match these values strictly but use ranges
instead.
Change-Id: I4e0066e2b79e73cf6fbc3dd773047be8dab2b907
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131931
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
If first document element is buried deep in destinations and thus
deep in state stack (m_aStates) initialization of default font
is very local and will be lost after closing these destinations.
So let's initialize entire states stack with default font if none
is provided istead of initialization just a top element.
Change-Id: I966c282f43b84baece909a4c3cd359cbcd317e63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131906
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Here are two related fixes in one patch:
1. By default current style index is 0, not -1. Due to this we
can assume usage of default "Normal" style during deduplication.
Seems there is no difference in case of no style mentioning in
run or mentioning "Normal" one (\s0), so value -1 looks
unnesesary.
2. During header/footer "substreams" processing StyleTableEntires
was not reused in new domain mapper impl instance. So deduplication
did not work well.
2a. To avoid copying of whole StyleTableEntries between instances
it is stored as pointer in domain mapper impl.
Change-Id: Id003d35554e9b43186238920d9a6373452095121
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131899
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
There are much more character attributes should be applied
wth default values if style contain them, but they were
not mentioned in current run.
These are obviously not a complete set yet, but most common
ones are included.
Change-Id: Ide52245bc98628febc2f3bd2e25166f0dcdf35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131853
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Text node containing a numbering rule with numbering format
with SVX_NUM_NUMBER_NONE is still a numbering: it will display
prefix, suffix and other numbering properties.
Change-Id: I52077824b4a1db2e9220701fdd514670490a59db
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131410
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
AddLevel() can be called on w:lvl and on w:lvlOverride. But if
we have level override and some extra level definition level is
recreated and override information is lost.
Change-Id: I6f1b9b50bdd3410b4ae2d403e760e4d6df5677d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131304
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
It looks like in cross-references ending with dot (".") one last
dot is removed in case of MS Word. This is not a true for any other
suffixes after numeration.
Change-Id: I554e62cf45e643bf27823df5344e1689b5b6ae54
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131254
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
When paragraph style is disabling numbering defined in parent
style we should apply margin properties (like we already do
in other numbering cases), but we should include only properties
from styles not affected by numbering. In other words, only
styles without w:numId are used.
Unittest was extended to cover different combinations of this
situation.
Change-Id: Ic19e00fcfe16b2357cdfe763b4f969cc63122e89
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129701
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
If paragpraph has list defined somewhere in styles and right
margin defined in current style this margin was overriden with
older value from parent styles.
Change-Id: Ic0a2e9a1ce5f77b9ef38c549a62f1494c050982c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129595
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
In some cases when we have combo linebreak, endparagraph and
end section at very bottom of page, MS Word does ignores linebreak
to avoid empty page with same section and lonely end paragraph mark.
With defered linebreak we could simulate and ignore such linebreaks
during import.
Change-Id: Ie6ee4c0990ee1c2e853691a76953c83191664e43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119709
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
If LockSave attribute is applied, docs with it are not affecting
File->Save All menu item: these documents are not enabling this menu
and also not saved during this process.
Change-Id: I00bcd251fccfab3f13cb42c20ccb61b54ab49346
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128650
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
If there is no dxf reference to color filter (for example if selected
color is not in range of available colors for current range) Excel
is not able to show color filter correctly: it is not marked as used
filter, no ability to reset, etc.
Change-Id: I65378ddd6f8f8233cda147ff9dcd28f455a58225
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127745
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
For SdtHelper we need to keep valid reference to main document
(in our case first call), not to any of substreams like header,
footer, etc.
Change-Id: Id9d99c1a9bff9a3392eea4cc6e2abe774e5868d2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127672
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
Previously during refactoring were lost some corner cases with
some level having disabled numbering. In this case LO should
strip useless delimiters up to next level.
For example, if second level has disabled numbering, third level
should look like "1.1", but not "1..1".
Change-Id: I259a16b456f51bc76d5c8360974d0acadfc36776
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127517
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
This is a squashed commit containing set of changes:
* Create a input field from sdt text block.
* Advanced support for reading field data from data bindings
which can point to custom xml or properties xml. For this
XOOXMLDocumentPropertiesImporter idl interface was extrended
with extra getterrs to get properties as xml dom elements.
* Support for exporting of this feature back to docx. For this
some extra parameters for sdt block are kept in newly introduced
grabbag for input fields. If field does not contain grabbag it
being exported as before (FILLIN or whatsoever), otherwise
sdt block is counstructed based on data from grabbag.
* Basic support for updating custom xml values back into
custom xmls with usage of xslt transformations. To achieve
this extra parameters were introduced to XXSLTTransformer:
now it is able to support in-memory transformation stylesheets.
Some unittests were corrected: since sdt plain text edit area is
a field located inside paragraph in outout corresponding sdt is
also located inside paragraph (instead of Word's approach with
paragraph inside sdt). Seems this is not critical.
Change-Id: I1a73ef300db3619804f7adf18579bea708764c14
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127015
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Word Control Field with datepicker is implemented with LO datepicker,
but during this conversion we lose some field data, like control
color, data mapping, etc. This data is already retrieved and stored
in grab bag, so we need just to keep this grabbag in field and use
it again on export.
Change-Id: I6af8204fe1a7d2f9081d83372a6786b2f86260d8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125486
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
There is much more different controls which must be supprorted
in future. So approach with isInsideDropDownControl() and
validateDateFormat() is not sufficient. Use enum to determine
and store control type.
Change-Id: Ibea7fde117c059053195be213a3ae821644f277c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125471
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
MS Word is putting spaces between field mark and field instruction
text. Writer preserves these spaces, but without xml:space="preserve"
they are not displayed by Word later.
Change-Id: I480e6febf0ee278b56e9dfc6e0430c5fd5bdfd71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125875
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Previous approach with almost duplicate storage and processing
for paragraph-level and run-level sdt blocks was very bulky.
Especially this became visible once supported std elements list
start to grow.
Paragraph-level sdt block and run-level sdt block data are almost
identical, so they can be kept in one standard class
(SdtBlockHelper) and use the same methods for collecting data
from grabbags and writing to output without passing huge amount
of parameters.
Change-Id: I4e1183eddf20317e954cb8aca72e97a4fc45ac68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125372
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
Content controls in Word can contain some other elements which
are not supported by Writer. Put them into grabbag and write
back to DOCX on save to avoid losing quite sensitive data.
Test testSimpleSdts is modified: testcase is actully containing
4 sdt elements with ids in input and output.
Change-Id: I1f9addd03ed828bf375ccac5188a004f011e8a0d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125271
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
<w:text multiLine="1"/> is now supported for import/export
to DOCX. Like other content control items it is stored in
grabbag.
Change-Id: Id6f1aa0072dc5db980d0fa43cab4b38a0aa047fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125024
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Unlike its name, this variable stores *total* amount of levels
to includes, so during conversion even empty list format to
prefix/suffix/includeupperlevels we should keep last one above
zero so list even in future will not have issues with levels
to display.
Change-Id: I4992c1ac0194f381df9f7b965ecdb2d688892b30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125022
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
Oldr approach with populating ListLabelString with some predefined
values and than replacing them by placeholders is not so good. It
can lead to collisions if we use numbers in format string.
Anow with support of list strings in core we do not need this: it
is enougth to replace LO placeholders %1%, %2%, ... by MS binary
placeholders \0, \1, ...
Additionally added support for list level initialization in DOC
import: that case was still setting just prefix/suffix leaving
list level uninitialized.
Change-Id: Ia85551f46b4e229dea93c663459ec1a8715c8a23
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124326
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
On DOCX import we do not need to provide prefix, suffix and included
levels: these values are calculated in SvxNumberFormat out from list
format. Moreover these values are incorrect and do not correspond
not to DOCX data nor to internal writer representation of list level.
Change-Id: I91ec9de679e67056ba3746f2e1a0bd923532d76c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124090
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
In some cases (described in task) dialog is not closed.
This is happens due to not delivered request to
SwTextShell::ExecField(). So we could just close dialog
explicitly, if Execute() action did fail.
Change-Id: I1c712295a21037bc8bb28e2a97e750299b41250c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123059
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Changed values for included upper levels should cause
generation of new list format string.
Same applies to outlines editing.
Change-Id: I90e19d6b5169f68c83ae3e55ec41b9016623d8ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122590
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
In spite of used list format in ODF for UI we still need to
show prefix/suffix (already was there) and included upper
levels (done in this patch) for correct visualization of
level properties.
Moved initialization of ListLevel to later steps to avoid
overriding of generated values for prefix, suffix and
IncludeUpperLevel by some invalid values.
Change-Id: I5d132426c06021ed526d16fb09276523105aa7b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122686
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
Unlike it was implemented in tdf#143605, prefix and suffix
should be displayed anyway, we do not display only numbers.
Moreover tdf#143605 did accidentally fix tdf#135164
in a invalid way. So this patch is also providing a better
fix for it: untittest is already created and failing without it.
Problem in tdf#135164 is inability to distingush missing level
text (bullet char in given case) and empty ("") one. In first
case we should use abstract level definition. In second - not.
Change-Id: Ica3a714d22de4d2f14ebbcb12f0e1311dbc9b801
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122609
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
Since all dxf records are stored in one place it is required
from color filter and conditional formatting to use continuous
numbering for dxf structures to avoid id collision.
Change-Id: I91146e34d462d812b480db137cda522f6db7ef8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122915
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
1. In XLSX filter colors are always stored in dxf as foreground
colors, so Calc should keep them, if possible. So practically
use only one color during import.
3. On export we need to distinguish type of filter, this is done
with cellColor=0 or cellColor=1 attribute of <colorFilter>.
4. Since p.1 there is no need to keep on export separate dxf
structures for fg and bg colors: we always use only foreground
color for color filters.
Co-authored-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Change-Id: Iacd352ae46bf84859dc15ee695b6dc63240afe7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122593
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Upper call to aParam.RemoveAllEntriesByField can invalidate
pEntry, making further calls to pEntry->SetQueryBy* illegal.
Anyway at this branch we are disabling color filter, so this
is not required.
Change-Id: Ia595649975b659d28056ba3f3658c306e63088f5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122822
Tested-by: Jenkins
Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
According to multiple reports border line width selection will be
more intuitive with some predefined values. Here is an implementation
of this proposal: line width can be selected from combobox from
predefined values (thin, medium, thick and custom). Classical spinner
is right now hidden unless custom line width is selected.
Change-Id: I87a6237335b79a5f5b63e109360e1ea8f12ae071
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114709
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
In some cases DomainMapper_Impl::RemoveLastParagraph() can also remove
last bookmark from real last paragraph. This does never happens
when we use xParagraph->dispose(), but pretty always during older
way with xCursor->setString(OUString()).
Unfortunately without deep refactoring of redlines, bookmarks, etc.
I see no other way to avoid this removal except given hack which is
trying to store last bookmark and if it did disappear restore it.
Some existing unittests were adjusted: corresponding original DOCX
files did contain final bookmarks not taken into account by the code.
In some cases test code is modified, in some just removed final
bookmark in DOCX: such multi-format tests as in ooxmlfieldexport.cxx
will be more identical to RTF & DOC variants.
Change-Id: Ie9948b58cda705a0b85fa8e5e08b72fbb7d682b2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121409
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Usually hyperlinks are processed by TextBodyContext, but
for grouped shape we accidentaly gone into TextParagraphContext
It has almost all possibilities to process txbxContent,
but not hyperlinks.
Additionally some hyperlink char attributes (color and underline)
can expand to follow up ordinal text. Additional small hack applied
to avoid this.
Unfortunately this is not a final solution: such document fails
roundtrip and hyperlinks are lost after saving to DOCX.
Change-Id: Ie954f53696bd872cb1f59cb586fb55f6cd7c73bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121172
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Same as in e08fba90 for tdf#143858: zero for SetIncludeUpperLevels
has no practical sense, since actually this value is amount of levels
to display. Default and minimal value is 1 (current level), zero
used only in cases when there should be no numbering.
Change-Id: I303386339a9e13944e11d0287c933523c7410b6b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120863
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
SvxNumberFormat::nInclUpperLevels (matches text:display-levels in ODF)
bit incorrect in its name: is counts total amount of levels to display,
including current level. So value "0" seems have no sense: display 0
levels in total?
In UI you can't select less than 1 level and ODF standard (19.797)
using 1 as a default. This looks plausable.
Change-Id: I596386c7b3cc4370910cd0ff6e927e501179fbdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120458
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Current list level (RES_PARATR_LIST_LEVEL) is initialized
before, but current value can overwrite it with invalid
in given context. So we could have mismatch of outline
style (which are not overwritten) and actual list level.
Change-Id: Ibf34a6f35b922493c4a1477326ea6c1599b4938f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120212
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Previously during refactoring this condition was lost. And it
is possible practically that we have all format for numbering
(prefix, suffix, format string, etc) but numbering is disabled.
Change-Id: I0c8ab446753308ad80b8d133824a936dacf6cc82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120082
Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
In such case anchor position depends on LastCharRect which can be
invalid because of happened frame movement, resize, etc.
Change-Id: I3d3c6318ee1ce5f4043e21ab091417d283c4260c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120059
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
When Chapter field with format "Chapter number and name" is used
it does not insert any delimiter between number and name. Best is
to use outline/list property LabelFollowBy.
But since it is done inside field we are limited with supported
characters, so practically only space and nothing are correctly
supported. Tab and newline are replaced by space.
Change-Id: I4583b7051ae5ad963132980443fa70b5a19354e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119428
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Instead of "Reset attributes" new undo id is "Apply attributes". Seems
less confusing when modified numbering rule is appled.
Change-Id: I0bad38475363d6e0af01597271720d71aca7722c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119401
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
During selection of used field format do this after list
is initialized. Otherwise selection can be lost during
further treelist filling.
Removed ancient hack which was trying to select at least
something in field format list: it is incorrect and does
not cover all possible fields/formats. It is just hiding
any potenial initialization problems.
Change-Id: Ibbbdd1e9a3436fec37cc49c11e6e235e8afcf4ac
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119341
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
If LO is using list format strings (this is default behavior since
aa5c6d12) it was not able to show just numbering without all formatting,
as it used in some fields.
Change-Id: Ib4695b8e1c2d7a451522c7e04af2216d16aceefe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119309
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Tested-by: Jenkins
Instead of style:num-prefix and style:num-suffix new list format
is much more flexible for storing list multilevel numberings.
Now it is possible to have not just prefix/suffix but any random
separators between levels, arbitrary levels order, etc.
Internal LO format for list format is changed: instead of placeholders
like %1, %2, etc we right now use %1%, %2%... Reason: for ODT documents,
having more than 9 levels there is ambiguity in "%10": it is "%1"
followed by "0" suffix, or "%10"?
Aux changes:
* removed zero width space hack: since format string is always defined
this hack is interfering with standard list numbers printing
(see changes in ooxmlexport14.cxx, ww8export3.cxx tests)
* changed cross-references values to lists: they are now including full
list label string: previously this was bit self-contradictory (see
changes in odfexport.cxx and check_cross_references.py tests)
Change-Id: I9696cc4846375c5f6222539aeaadbca5ae58ce27
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117156
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Since internally LO is able right now to use list level format strings
and prefixes/suffixes only for backward compatibility, there is a need
for conversion from format string (like "%1.") to prefix ("") and suffix
(".") still used by ODT.
Change-Id: If4b459e1b25b7f0ce511e6ac2de0824bb2c43d05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116288
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
As far as I see, Word is using lists with id=0 and no list definitions
to reset list numbering used in this paragraph. At the same time Word
is still using some of default list properties. For example in this
scenario parent style has defined first line indent, but in paragrath
it is overwritten by "not existing" list=0 without definitions.
To this moment I know about only first line indent behavior, but
probably some other properties are also affected.
Change-Id: I344c907bb7a7b83a91f5727e13ad184fb44137b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115795
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Vasily Melenchuk