Age | Commit message (Collapse) | Author |
|
In some cases at import there are extra space separated
numbers at the end of the names of arrow objects.
Remove these extra numbers before they could interfere
with the choice of markers.
See commit 2d3b7a07c02c90d2d64a630ab84886ef3096edfc
(tdf#100491 fix DOCX import shape line with arrow marker).
Co_Author: Balázs Regényi
Change-Id: I2156502b0ce5cd755a731359398a40edabb603a6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91375
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 68531e459e7a922319e6bfe8b7a5282ba0320182)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92535
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Saving some arrows from ODT to DOCX scattered them around
their correct position. This happened because of a function that
recalculates the position of drawing objects when they are rotated,
according to the rotation. It turns out we don't have to do this
with lines and such.
Co-Author: Balázs Regényi
Change-Id: Iea6a34d15003cacc27a8030cb73511aba39225f6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90989
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 08a11f8fe19560b000c62da00d7425b4f500d605)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92166
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Flips along both the y- and x-axis weren't imported,
resulting wrong direction of arrow and other shapes.
Co-Author: Balázs Regényi
Change-Id: Iac222ac2a6a6110289969c32b40828b83da0aefd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90646
Tested-by: Jenkins
Reviewed-by: Balazs Varga <balazs.varga991@gmail.com>
(cherry picked from commit cb441c4d0adf698e6af9073c6c3285a66b76871e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91391
Tested-by: Xisco Faulí <xiscofauli@libreoffice.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
caused by incomplete handling of tables with 1-column
rows with merged cells.
Have to check the rows below current to see if they contain
also one cell, therefore form a column, or more than one cell,
in which case do not remove vertical borders.
Regression from commit: 8a2eb40abbd52d960dd21308157186be0ca9dd3d
(tdf#129442 DOCX import: fix right border of 1-column tables).
Change-Id: If9ca7ccd42255e78c61b6271e19262ab5cc8e439
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89081
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 111db716c23f9f8450eda58c13dd2423770fd15e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89134
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
in DOCX export of MSO 2003, 2007 and 2010, where ilvl and outlinelvl
settings are missing, based on the settings of the parent styles.
Change-Id: I01d239db505d46a89d7f3b9118ef0b55697bc7fc
CO-Author: Balázs Nádasdy (NISZ)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87328
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89216
Tested-by: Jenkins
|
|
MS formats unlike ODT have also global setting for hyphenation
params. Previous approach was to set this global value depending
on default paragraph style settings. However, if hyphenation is
enabled ony for specific other paragraphs, hyphenation in MS Word
will not work.
Let's try to set global hyphenation value to "auto" and explicitly
enable/disable hyphenation on paragraph level.
Change-Id: I199fa80eb1204930e2640dac0e90802b6b98597b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88536
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
(cherry picked from commit 4e4ae855cb9976c3ef3bfdca23a0d706a56237c1)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88681
|
|
Bottom border of a vertically merged column of a table was missing
if the inside borders were turned off and the merge included the
last cell of the column. This happened because the first cell
(topmost) in a set of vertically merged cells determines the borders
of the new merged cell, and the turned off inside borders were at
the bottom in this case.
Change-Id: I3d3defad18a1315117a554a36ad599eb46daffe9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85988
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 0f4dd820ee433932d9d9237b676292d31c4ba913)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86430
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Bottom border was missing in a 1-row table with disabled
inside borders. This happened because LO applied the empty
horizontal borders to the bottom border of the table.
Change-Id: I40140bf63297189edad13088f98fc5f869969c2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85303
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 6b1bd2699b0bdad6dc42db741dea0717cf7c1d36)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86397
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Right border was missing in a 1-column table with disabled
inside borders. This happened because LO applied the empty
vertical borders to the right border of the table.
Change-Id: Ib190689bf5059bfd7dbf07b07808cd761015f37e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85301
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 8a2eb40abbd52d960dd21308157186be0ca9dd3d)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86261
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Had to check an additional criteria before removing
inside borders.
Change-Id: I0828d973bd331e65ebabc1fe2e2f25f1bcaf58b0
Reviewed-on: https://gerrit.libreoffice.org/84676
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit dff3ae42d94fdf97c856c4a4d1e66234604927f4)
Reviewed-on: https://gerrit.libreoffice.org/85199
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
Extra cell borders appeared on the bottom, top, left or right
of the 1-cell tables when only the "inside borders" option was selected.
The extra borders were the ones that would normally have appeared as
inside borders if there were more than one cells in the table.
Change-Id: I05d5f2a5a0168989f220d20a95b6dacf5152f9f7
Reviewed-on: https://gerrit.libreoffice.org/82675
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
(cherry picked from commit 8a59f18b6eb22c43ec10cdc29ba5a13d5feba4f0)
Reviewed-on: https://gerrit.libreoffice.org/83303
Tested-by: Jenkins
Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
|
|
An unsupported character style property was causing the loss of
some properties - anything with a higher sorting value.
Another way to deal with this could be something similar
to section properties which retries properties individually
if multiset fails.
Another option is to add CHAR_SHADING_VALUE to aCharStyleMap
in unomap1.cxx, since it is already in aAutoCharStyleMap.
However, this is an area I completely don't understand.
Change-Id: I70676c7a35d0efc95222960609da039e26df8a58
Reviewed-on: https://gerrit.libreoffice.org/76875
Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
If you set the parent style to a style that is not yet created,
then it silently fails, and thus inherits from nothing!
Change-Id: Ibb85235643dd5b1eb9b0bd43f701580f24b2b7fa
Reviewed-on: https://gerrit.libreoffice.org/76805
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: Ib5de4377b22815ba718559ff6fcfd6ab5a0547a6
Reviewed-on: https://gerrit.libreoffice.org/75999
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... after commit 3f7e8ddea89f6340cd18b5b34f5a7c5f503962be
The tests are DPI-dependent, and failed on systems with DPI other
than 96, so take that into account.
Change-Id: I0297aab7988c3b78cbd3132f21e5a101bc32c1f6
Reviewed-on: https://gerrit.libreoffice.org/75302
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
This depends on commit "Make font-based unit test depend on instdir
fonts, not that it's sure that this really fixes the problem, as its
origin is really unknown.
It especially enables all the font-based tests I could find on all
archs. Same for many more test where I couldn't see any reason they
don't work generally. To get rid of even more ifdefs, it moves these
from the class to the functions, so there is actually just one needed
for any test. As a result some few tests run but do nothing.
There is still some problem with embedded fonts on MacOS and with
delayed graphics loading on Windows, so these ifdefs are kept.
Change-Id: I63f8424e9debda6cbf3e5777c93245e09f8eb0f2
Reviewed-on: https://gerrit.libreoffice.org/74719
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ia0c79c2455a3b40384332c8c35215671e257a07f
Reviewed-on: https://gerrit.libreoffice.org/70847
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
It turns out that this change revealed unit tests written incorrectly
(and untested), or maybe which became broken (not testing) because of
some previous assertXPath change? They incorrectly used 3-arg form of
it to check node content equality to passed string, while in fact, an
attribute was looked for with that name, and its empty return tested
to match default empty 4th argument.
Change-Id: If24e18518543102d115a22a6282e4cca9cf694e2
Reviewed-on: https://gerrit.libreoffice.org/70581
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I4936284bff568b6bb47e5df3821f4ddd78260e92
Reviewed-on: https://gerrit.libreoffice.org/67568
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
If a floating table was imported from docx, it will be placed in a frame.
A grabBag attribute remembers the original positioning values.
Restore this state when exporting to docx again and do not export the
surrounding frame.
This has to be done at the start of a paragraph, so remember the exported
table in a std::set and skip it later in frame export.
Change-Id: Ib62d4b228b306e5d1c4ce61fbbd4b6c3e1206603
Reviewed-on: https://gerrit.libreoffice.org/65982
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Ifb522c5488aeadc327116bef8a21adef16e3e711
Reviewed-on: https://gerrit.libreoffice.org/58300
Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Justin Luth <justin_luth@sil.org>
|
|
So far I've been fixated on paragraph properties, but styles
(both character and paragraph) also inherit the rPrDefaults.
One enhancement could be to check the styleType and skip
the paragraph stuff for character styles, but that doesn't
seem necessary or valuable at this point.
The unit test is pre-emptive.
Change-Id: I4e898f5fa573b62be4dc70512b02cdeb7b21e7c6
Reviewed-on: https://gerrit.libreoffice.org/58257
Reviewed-by: Justin Luth <justin_luth@sil.org>
Tested-by: Justin Luth <justin_luth@sil.org>
|
|
and fix the fallout
Change-Id: I15bc5d626f4d157cbc69a87392078b41e621d14e
Reviewed-on: https://gerrit.libreoffice.org/54882
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Id3da40138e86c142707e377aa897df372aacb704
Reviewed-on: https://gerrit.libreoffice.org/50947
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
|
|
Change-Id: I0e25c8950ac26b851ff42f71e1471fcbe4770d48
Reviewed-on: https://gerrit.libreoffice.org/50373
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
* 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>
|
|
Change-Id: I9a2990e49c95a01ce505f13408be8c19db1cf5d1
|
|
Fix regression from e79ef12b7a904f17d4147fa409d055c12b70f952
tdf#107033 DOCX import: fix unexpected missing footnote separator.
Initially related to tdf#68787.
If HandleMarginsHeaderFooter was called twice, then it automatically
would have disabled the separator. Clearing the HasFtn/HasFtnSep flags
also shouldn't be run when in the footnote sections.
Change-Id: I00cbd1cbc8dc86edf426f852c59c3f943e373b13
Reviewed-on: https://gerrit.libreoffice.org/40551
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I173a29fd1ee889127369d2bc2fce8e010b89ca65
Reviewed-on: https://gerrit.libreoffice.org/38633
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The unit test should only be ensuring that the footnote is actually
written in the footnote section. The fix had nothing to do with the
style of the footnote.
Change-Id: I209f1f0a8cf896916eaf7e8002c92085926b508b
Reviewed-on: https://gerrit.libreoffice.org/37907
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
cf. 1391f3702a3daaefc67a8ee4b62ac38959db283f "Make the testTdf106974_int32Crop
pass on my Mac". For some reason, on my Mac the Right value is 40474 resp.
40471 the two times the function gets called.
Change-Id: I731ff9c5cf76be9d4817ad14f296807017d10dbd
|
|
Change-Id: I95fa42f4ef0580734b605df859c1660b29adb8b2
Reviewed-on: https://gerrit.libreoffice.org/36499
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
For some reason, on my Mac the Right value is 41226, both times the
function gets called. (On my Linux box, it is 46387 and 46394.) So
compare to 41000 instead of 46000.
Or would it be better to just bypass the test on macOS, as we already
do for other tests in this file...?
Change-Id: I71e292d42a2a956fbd28eb47fc5bfe3c7d849efe
|
|
I got size sal_Int16 from the return value type of the border
spacing, but somehow failed to lookup the return value of GraphicCrop.
It now matches .doc export's sal_Int32.
Bad mistake: regression 8eff1decd91cbfb10094c25d4cf1d2b434a4da72
Change-Id: Ie149630b9da9a067de319149f23ca21f78a186cf
Reviewed-on: https://gerrit.libreoffice.org/36200
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: If0f4a6532cc255f632d88d97e6b1a9e57462f5fc
Reviewed-on: https://gerrit.libreoffice.org/35969
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia87318cb323d403cdff947da0b70e0d2aabaacd4
Reviewed-on: https://gerrit.libreoffice.org/35657
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I17b566a13b0822e39cb5852150f407c9d9c84305
|
|
Although import handled whether footnote numbering restarted
every page, chapter(section) or document, that information
was not being exported in docx.
Change-Id: If9e0a1d53c8610b18b949fd918c5dd7d7bd94682
Reviewed-on: https://gerrit.libreoffice.org/33183
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Honor the padding value even if the border is not visible.
Previously the padding information was just thrown out, and
the image scaled to fill the entire image size.
The unit test for tdf#77454 needed to be tweaked because surprisingly
it has border padding of 1 - which this patch turns into a negative crop.
Change-Id: I866d26e00f27221239d3291404f70fb57ac0896d
Reviewed-on: https://gerrit.libreoffice.org/30578
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: I1e0894f116e8288eb8b648ed3ac679be237806a3
Reviewed-on: https://gerrit.libreoffice.org/29845
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Since .doc and .docx don't have an option to "don't split table",
we emulated that. For this IMPORT case when there is only one row,
consider the entire table to be unsplitable is the row is unsplitable.
This will give the expected results if the user starts adding more rows
to the table.
Change-Id: I8a2d817ff714ba0df65b5a5e263b27df4264e848
Reviewed-on: https://gerrit.libreoffice.org/28357
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
.doc and .docx do not have a setting for "do not split table" so
it was being emulated by "keep paragraph with next" for all but
the last table-row. That means that a single-row table with
lots of content might be split.
There is a setting to prevent a row from splitting, so use
that instead in this corner case. It needs to be
separate from the other function in order to be
set in time for docx to write w:cantSplit w:val="true"
before the row contents. For some reason it did not work
to move the whole function here.
Change-Id: Idc11626e0e2cf1706b87a83f2bd4a802348cb633
Reviewed-on: https://gerrit.libreoffice.org/28352
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ic2e08245dd022555ad6308283d406d81141a9124
|
|
stage 2 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
In this stage we focus on replacing usage of the WIN macro
Change-Id: Ie8a4a63198a6de96bd158ecd707dadafb9c8ea84
Reviewed-on: https://gerrit.libreoffice.org/22393
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
|
|
Change-Id: I9a5940027423ff0791fa7da0b79b617412ce6b86
Reviewed-on: https://gerrit.libreoffice.org/21209
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
|
|
(regression from 1dac99e7ea45f90bf39eb95eb7bc01f7d79093ef)
Change-Id: Iffe3ec6c28f62b78a2b223144bfaad383d272802
|
|
Change-Id: I4a0282291c7737a981dbff0722228824904f07e4
Reviewed-on: https://gerrit.libreoffice.org/19804
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I76671a74150791e1a74ece3d5bcf40fd6c727ac7
|
|
Change-Id: Ic135382652966e80c288f3407508bdaf0c60316e
|