Age | Commit message (Collapse) | Author | Files | Lines |
|
Having no tabs defined is the default value, so nothing generally
needs to be written. But if the paragraph style defines tabstops,
but the current paragraph doesn't have any, then those style
tabstops need to be cleared.
Change-Id: I7a818c658403cc683b0c5b7452b6c88ea00f771d
Reviewed-on: https://gerrit.libreoffice.org/44244
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
The font information should be output before field declaration.
Added unit test.
Change-Id: I147dd8956fbd8e69c3a2e86aff01dc249f4fa815
tdf#38778 DOCX output: no double output of the font info
Change-Id: Ia080f742cde88b914e146fe7a95b90bf1952c96a
Reviewed-on: https://gerrit.libreoffice.org/44160
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
FormatBackground was always returning the actual color
instead of AUTO when the color was COL_AUTO because ConvertColor
is being passed Color.GetRGBColor() instead of just Color.
There are three sections here:
-XML_fillcolor: looks like it accepts values like "green" and
"teal". Unclear from documenation whether auto is allowed.
-XML_srgbClr: only accepts rgb number, not auto
-XML_fill: needs this fix - test document available.
Since the section can't globally handle "auto", I left XML_fillcolor
alone, waiting for a proof bug report.
Change-Id: Idecb6a32fba814a6fb3aeb6cc015d793ba6f8cf9
Reviewed-on: https://gerrit.libreoffice.org/43975
Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Justin Luth <justin_luth@sil.org>
|
|
Although 2013 commit 60ec497e0e91354a616978be531d15d3efa3f559
added support for the other tcMar items, it omitted _start and
_end (perhaps because they caused unit test failures).
The document in bug 78508 proves that these are needed.
Testing whether the cell spacing matches the default table
spacing should occur before adjusting for MSO compatibility.
This fixes the three unit tests that mysteriously failed
when adding _start/_end support.
Unfortunately, these two fixes could not be committed
separately - the unit test fails unless both parts
are included. I couldn't figure out why.
Change-Id: I9507da48b629b9618c5ee790bf0088ce82fc5692
Reviewed-on: https://gerrit.libreoffice.org/43432
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
During export into DOCX all runs inside fields should
contain all character properties including character color.
Change-Id: I2a7d4fc26f1e1de1080f51de84180a19794709a9
Reviewed-on: https://gerrit.libreoffice.org/43723
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Serge Krot (CIB) <Serge.Krot@cib.de>
|
|
Change-Id: Ifc3c4c31a31ee7189eeab6f1af30b94d64f2f92a
|
|
Not all runs got their text properties written during field export -
previously only the first run had them. Adds SwTextNode param to EndRun
and EndRuby methods, implementation empty for rtf and doc though.
Change-Id: I77f39b40689feb9664044e61824ad3bb97776638
Reviewed-on: https://gerrit.libreoffice.org/43465
Reviewed-by: Serge Krot (CIB) <Serge.Krot@cib.de>
Tested-by: Serge Krot (CIB) <Serge.Krot@cib.de>
|
|
Change-Id: I63bde881507dc3c5d123bbcf96b63027522ea569
Reviewed-on: https://gerrit.libreoffice.org/43365
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: Id08998ae775c5f383edc4bf0410d16f88c70dfd6
Reviewed-on: https://gerrit.libreoffice.org/43275
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
LibreOffice will just ignore the defined style on import
(since that is statically defined by the footnote code).
Microsoft Office, however, requires the character style be
provided for the footnote number. It doesn't have any
built-in formatting for footnotes.
So, this patch is strictly for MSO's benefit.
Change-Id: I6631dd0eb697589cfd3c13d7838fe14c31a71bbf
Reviewed-on: https://gerrit.libreoffice.org/42035
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I4d3da8e057e1e6b241874d7ead0867f358ef923c
Reviewed-on: https://gerrit.libreoffice.org/42230
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I92fd035824f247dc61edfb18c54b960a7733fdf7
Reviewed-on: https://gerrit.libreoffice.org/42244
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I43ad46f95538477ad5d9fae330f1e01892cc41fb
Reviewed-on: https://gerrit.libreoffice.org/42220
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Bookmarks containing spaces are incorrectly interpreted by MS Word,
so spaces are replaced in bookmark names and bookmark references
in fields.
Change-Id: I4e23c6b8740b54e94a1ec7e3385cffbe3ba01709
Reviewed-on: https://gerrit.libreoffice.org/41954
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: Id706cf40f717005df840e7856528dd7bbc866e98
|
|
When LO control is anchored to the end of the run, it
is exported into a new run.
Change-Id: I9269fd1b34924780aad61c452d1e2094dc8e4aad
Reviewed-on: https://gerrit.libreoffice.org/41472
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
* Inline anchored VML shape had wrong vertical position
** In MSO inline shapes are positioned to the top of the baseline
* During export all shape ids were the same (shape_0)
** VML shapes used to be exported only as fallback,
I guess that's why it did not cause any issue before.
** Override the shapeid generator with a new one, which
actually generates unique shapeids.
Change-Id: I752f39d092d0b61d91824141655dae662dbeafbc
Reviewed-on: https://gerrit.libreoffice.org/41319
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
The mere presence of SvxFormatKeepItem was ENABLING it during export,
without checking to see if it was actually turned on or off.
Both DOC and RTF check the value, and set accordingly, so do the
same for DOCX.
Merely toggling the setting on and off is enough to create the
property, so this is a nasty bug that only affects inquisitive
people.
Change-Id: I02d83a255f5b4ff8c5124302a52a3126dad40b67
Reviewed-on: https://gerrit.libreoffice.org/41309
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: I39184b8fdf666676c21560d39911f6204b0afd52
Reviewed-on: https://gerrit.libreoffice.org/41257
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
* Use the same structure for export what MSO uses
** Position and size information are exported as VML shape properties
** Different handling of inline and floating controls (pict or object)
** Do some changes on VML shape export to match how MSO exports these controls
** Write out activeX.xml and activeX.bin to store control properties
** Use persistStorage storage type defined in activeX.xml
* Drop grabbaging of activex.XML and activeX.bin
* Cleanup control related test code
Change-Id: I38bb2b2ffd2676c5459b61ec2549c31348bab41c
Signed-off-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/41256
Tested-by: Jenkins <ci@libreoffice.org>
|
|
MSWord has two choices for footnotes - at page-end or page-bottom.
LO has different choices for footnotes - at document-end or page-bottom.
Since document-end footnotes act like endnotes,
convert those footnotes into endnotes during DOC/DOCX/RTF export.
No matter what happens in this situation, some compromises have to be
made. The main compromise now is that the anchor numbering for endnotes
defaults to i,ii,iii while footnotes are 1,2,3. The conversion
obviously will switch to endnote style. This is user adjustable of course
and will be retained on following round-trips. Also the (footnote)
paragraph style is retained, but future endnotes will use a potentially
different endnote paragraph style.
Remedying those perceived deficiency is left as an exercise
for the motivated reader, who of course will
take into account the possibility of both endnotes and
chapter-end footnotes existing in the same document...
The unit tests' primary purpose is to ensure that footnotes following
down the endnote export path don't cause LO to crash.
Change-Id: I219d499df7981a14f824a664b15051ad10ff6642
Reviewed-on: https://gerrit.libreoffice.org/38634
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Iec685588ef7a1d5284072ebc8fcadc07dae67364
Reviewed-on: https://gerrit.libreoffice.org/40999
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
Adds support for the new NUMBER_HEBREW numbering format to
various import and export filters.
Change-Id: I93f928f5d4d43d0cf569a85677df7eef7b088db8
Reviewed-on: https://gerrit.libreoffice.org/36645
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I0fb51270da4b8f3049f1af2c2c788e516b3641e8
Reviewed-on: https://gerrit.libreoffice.org/40821
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8a6b2647375a54720cd9fd765cc51c9ff43c8190
Reviewed-on: https://gerrit.libreoffice.org/40682
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I38d5669078308b425d8e87090ef72279de96c6c9
|
|
Change-Id: Ia96172489eec09607113d388a5b683bb6e0d2dec
Reviewed-on: https://gerrit.libreoffice.org/39290
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
- teach comphelper::containerToSequence to handle sized arrays
- also use range based for-loop where appropriate.
Change-Id: I73ba9b6295e7b29c872ee53de7a9340969e07f99
Reviewed-on: https://gerrit.libreoffice.org/38769
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Cleaned out the rest of OSL_ASSERT in docxattributeoutput, keeping
consistency with the rest of the function where they were found.
Change-Id: I87c637d11a184cb002168c5d1151a0f3112f69c1
Reviewed-on: https://gerrit.libreoffice.org/38774
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
See commit b6e62dc0dc2b284c825f1182a67bb2f9259a30ce (tdf#106492 DOCX
export: fix duplicated section break at doc end, 2017-03-21) for the
context, this is one more case where it's not OK to suppress the two
section breaks at the end of a document, since the suppressed section
break is the one that provides the headers / footers.
Change-Id: I4abd7895436e4d2e08fd7b7ff4aabbac8d65f7fb
Reviewed-on: https://gerrit.libreoffice.org/38721
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I6ed8c54c7c45931d91709cc818f2483c70197192
Reviewed-on: https://gerrit.libreoffice.org/38400
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7a420427f7be1b42907272b314cf3b864e1fe7ba
|
|
Change-Id: Iac8ccd17d9e46ebb2cb55db7adb06c469bbd4ea0
Reviewed-on: https://gerrit.libreoffice.org/37910
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Next to the existing OutlineNumbering() (which is only used for styles),
commit fd2d14d5543c82eb875e720c98b51518699a8fbc (Implement DOCX export
of paragraph outline level, 2013-10-04) added ParaOutlineLevel() to the
attribute output class that also wrote the outline level of a paragraph
(style), but worked for the cases when the style was imported by
writerfilter as well.
As a side-effect styles imported by xmloff now have their outline level
property handled twice, leading to duplicated elements.
Fix the problem by only writing <w:outlineLvl> in ParaOutlineLevel():
it covers both use-cases, so no need to do anything in
OutlineNumbering().
Change-Id: Ic982dd70a00609cdfc3744a8ab69aaa828410fd0
Reviewed-on: https://gerrit.libreoffice.org/38132
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
For one, commit f6eb92406bd366c557bc07810649e7ab3d1db614 (fdo#77812
:FILESAVE :DOCX : Extra Section Break gets added in file, 2014-04-29)
made the mistake of always preventing an empty section at the end of the
document, while having that is a feature for the case of balanced Writer
sections with multiple columns. Word can't have balanced columns at the
end of the document otherwise.
For another, commit b6e62dc0dc2b284c825f1182a67bb2f9259a30ce (tdf#106492
DOCX export: fix duplicated section break at doc end, 2017-03-21) made
the same mistake when it wanted to eliminate an unexpected additional
section break.
Fix these by restricting these changes to the case when we don't hit the
"multiple columns + they are balanced" situation.
Change-Id: I742097eb813da6d94a9669328c6a049da7a491ee
Reviewed-on: https://gerrit.libreoffice.org/38104
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I0a794e1d2a4b7e97133df0f7243817da7caaee1d
|
|
Writer only enables or disables pair kerning (autokern).
Word uses a minimum font size to determine which characters
to kern. Since these documents are round-tripping through
Writer, and every size is kerned by Writer, the minimum size is
forced to 1pt and the original minimum font size is lost.
This is a followup to commit 38b0c24fa5cbb4246e03d77ac022dfdc9fdede03
for related tdf#105454 DOCX import: fix unwanted enabled-by-default
kerning.
Tested in Word 2003, 2007, 2013.
Change-Id: I7678a544f455fd06bec5e7d864b5c27ab26bf6d3
Reviewed-on: https://gerrit.libreoffice.org/37574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Hard coded relationship URI in sd/source/,
sw/source/filter and oox/source/export/ directory has been replaced with
method calls.
Change-Id: Ie1b9542325fa4143bddea2582aa5e946094e457d
Reviewed-on: https://gerrit.libreoffice.org/37433
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: Iee48e6c77f1eb57cd8a3a245e5415051b85f4cc1
Reviewed-on: https://gerrit.libreoffice.org/37387
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I7d2a28ab5951fbdb5a427c84e9ac4c1e32ecf9f9
Reviewed-on: https://gerrit.libreoffice.org/37280
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I365d140446bd2a62cf8256acbfdd53fe72987380
|
|
Change-Id: I2018d669e4886040882c90012ad2b2c9f8a07331
|
|
Change-Id: I3ec5a60fff8577677eaa4977cddf69bec4078cec
|
|
...that had been removed with 4b788a12380518e31a9064d5839f4880d3f36874 "There
should be no need to distinguish between I32S and I64S" (which this commit
effectively reverts). I had erroneously assumed that the arguments to I32S and
I64S would only be of (signed) integer types, and that it would be irrelevant
that they are truncated to sal_Int32 resp. sal_Int64. However, at least
oox/source/export/drawingml.cxx called I32S with double values (for which there
is an OUString::number overload too), so the resulting strings could be rather
different.
Change-Id: Ib3887269fad0764740bc9ed3be91f67696a23b55
Reviewed-on: https://gerrit.libreoffice.org/37040
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia28e35ae5af4f601e9a586a3deffbcd61702b0ca
Reviewed-on: https://gerrit.libreoffice.org/36896
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: I26661684e634aa15a18f78442de15c9db832f319
Reviewed-on: https://gerrit.libreoffice.org/36886
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...if the TextObject is not available. This is perfectly valid situation in
the case when the SwPostItField was created via the .uno:InsertAnnotation API.
Change-Id: I3ae2a529ba7cc13cf5b04d57aa299d79e2044f37
|
|
Change-Id: I3fa363c8e76e6cfb297f4ec346e3f031c09d6fbf
Reviewed-on: https://gerrit.libreoffice.org/36727
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Since MS Word 2013+ if you change cell margin at the table, the border won't be shifted.
The decision is to do the same ( see https://bugs.documentfoundation.org/show_bug.cgi?id=106742 ).
Change-Id: Ia58693c44f63ed21dca2cd99591002ba68927b65
Reviewed-on: https://gerrit.libreoffice.org/36084
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
git grep -l "[ _\.]THROUGHT" | xargs sed -i 's/THROUGHT/THROUGH/g'
git grep -l -i "[ _\.]THROUGHT" | xargs sed -i 's/throught/through/g'
In ENUMs: THROUGHT = THROUGH (preserved as valid alternate spelling)
In ooxmlexport8 - unit test confirms THROUGH = THROUGHT
Change-Id: Iae0fef9a8adcb96761989f38903a24ffb1b91e77
Reviewed-on: https://gerrit.libreoffice.org/35998
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|