Age | Commit message (Collapse) | Author |
|
Change-Id: I78f837a1340be0ca5c49097f543a481b7b43a632
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108367
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I044dd21b63d7eb03224675584fa143009c6b6008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108418
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for
details.
(Turned some affected variables in included files into inline variables, to
avoid GCC warnings about unused variables.)
Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I0c80ce6efbbc950ce975e55663a5643ea8fb37f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108215
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
to make it more obvious when we are constructing heap OUStrings
code and potentially inadvertently throwing away performance.
And fix a handful of places so revealed.
Change-Id: I0cf390f78026f8a670aaab53424cd31510633051
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This fixes 6.1 regression e24e2d2fb02239753c1520a0458b44683ea4cc2e.
Starting in 7.0 (tdf#131321), paragraph styles kept their
numbering property. But even before that, non-paragraphs
marked by bNoNumbering we having their direct numbering
removed, and then finishParagraph applied para-style
numbering since there was no direct numbering.
So, we need to pass the bNoNumbering to finishParagraph
so that it can cancel out a style-assigned numbering.
Change-Id: I0c24af4e9bd0ea3712179a47ed3550f91c8f44b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107738
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|
|
Change-Id: I280dea8fe5f346a5555f4bf479896877579d63e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107748
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
well, at least not at the beginning of the document.
The problem with specifying is that it becomes a property
of the paragraph - and so if the paragraph is copied or moved,
the page break comes along with it and the user has to remove
the unnecessary page break wherever it lands.
Since the default will be applied anyway,
there is no value in specifying it.
I'm not sure how, but at least one test document started
with a Converted1 style, so I had to explicitly confirm
that the stylename really did match the default
for a first section.
A unit test also indicated that
it needs to be specified if an explict page number is assigned
because RES_PAGEDESC contains MID_PAGEDESC_PAGEDESCNAME
as well as MID_PAGEDESC_PAGENUMOFFSET.
Change-Id: I0d0f6b70767f7daaf300e09c0d31ac4b17b91ed1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107555
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
...for LIBO_INTERNAL_ONLY. These had been missed by
1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take
std::u16string_view parameters" because they did not match the multi-overload
pattern that was addressed there, but they nevertheless benefit from being
changed just as well (witness e.g. the various resulting changes from copy() to
subView()).
This showed a conversion from OStringChar to std::string_view to be missing
(while the corresponding conversion form OUStringChar to std::u16string_view was
already present).
The improvement to loplugin:stringadd became necessary to fix
> [CPT] compilerplugins/clang/test/stringadd.cxx
> error: 'error' diagnostics expected but not seen:
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd]
> File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd]
> 2 errors generated.
Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...similar to cbe944e323edb20f958bb46ea644de659b75382e "Catch inadvertent uses
of OUString(sal_Unicode) ctor". The existing few places did mean to use that
ctor after all, but this clean-up should come in handy when single-character
instances of OString are replaced with OStringChar, which already rejects non-
char arguments.
Change-Id: I9dbd85b85c3be653c5e8084aed39689f8c6c3bb8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107557
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
I wonder if the test != 0 is what was really intended here, but
keep that legacy logic anyway
Change-Id: I4b39a2130e961c6f2ca97695e4625df5a95e00b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107460
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Regression from commit b7ae863efeb082816cc4fe660527a9650d90e186
(tdf#117503 DOCX import: fix out of sync first/later top margin,
2018-05-28), which adjusted the import so that the export can pair
first/follow page styles and write them into a single Word section.
But changing the import for pairing purposes is not a good idea after
all, as it also affects the layout of the imported document.
In the meantime, commit 51534ac2b9747975945acb6a1e1ba5cc6d73f5c2
(tdf#127778 DOCX import: fix unexpected heading on non-first page when
the first page has a heading, 2020-05-11) already fixed the export side,
so this is not even necessary, just remove it.
Change-Id: I94c02517ae1e0804547f81c43bb5890327d32376
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107363
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
by removing unnecessary rewriting of cell properties
during import of w:tblPrEx.
Regression from commit da8ea444b004a0be36964ae9a778f73e752b2673
(tdf#133455 DOCX import: fix table border regression)
Change-Id: I93ce36991437644db439c8cf02e1a8503fbdfba7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107239
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: I3e22c2000da03f6f3345353846213203993aa865
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107192
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Id6e36a4acf34a6b8d5b7202231650066ae6cb6cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107170
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
MS Word ignores w:highlight in character styles,
so don't import it.
RES_CHRATR_HIGHLIGHT only exists in LO in order
to support Microsoft's terrible idea of allowing
two different attributes to define char background colour.
So it should be safe to remove it from UNO.
Change-Id: Ia2ee0bd61ee59dfa864e946024c8184747aa2b40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106183
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
and
cid#1401334 Uncaught exception
Change-Id: I0d489a487c4c8148da4978cb613829b9cf69d14d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106985
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6800e23ead2767d245d5da71d2d40e0f8a6d7e1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106859
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I8ba1214500dddaf413c506a4b82f43d63cda804b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106559
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Importing a charHighlight of NONE is critical,
since charHighlight can be set on a higher para-style,
and so there needs to be a way to cancel it with
direct formatting.
DOC already imports NONE. This adds it for RTF and DOCX.
(None of the formats EXPORT it though. So that needs to
be done, but try not to spam NONE settings where
they are not necessary, please.)
Change-Id: Ic5d03ceb81a3a079c827b81561deb9068ae8259e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106314
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
in ww8filter/RtfAttributeOutput and treat \dbch as
CJK and \hich Western in order to roundtrip the
RTF document.
ww8filter mix all the associated style, including
properties for CJK and CTL scripts.
Both RtfAttributeOutput::CharFontCJK and
RtfAttributeOutput::CharFontCTL output \dbch,
that result in incorrect assocation.
CharFontCTL should use \rtlch, but it was already in
RtfAttributeOutput::MoveCharacterProperties.
To make the order correct, I separate the
associated character properties that were
stored in m_aSyltesAssoc into m_aSyltesAssocRtlch,
and m_aSyltesAssocDbch by their script types.
Note that it is not clear what associated character
properties that we should adopt for \hich and \ltrch.
In theory RTL scripts can output high ANSI chars too,
so \hich may get properties from either Western or
CTL scripts. However, examining Hebrew RTF documents,
I didn't see any sign that \hich is used in that way.
Use RTL as CTL might be a problem for Mongolian,
Manchu and Xibe. They are CTL but top-to-bottom (aka LTR)
. But I don't think they will be expressed
as high ANSI chars either.
Change-Id: I214edbb00a67c2ffe19c5a37254c8988a0828f40
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106355
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
which means that some call sites have to change to use
unicode string literals i.e. u"foo" instead of "foo"
Change-Id: Ie51c3adf56d343dd1d1710777f9d2a43ee66221c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106125
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I35d20d65b607d6441b001c7d839a793349ef3b1f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106425
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
CustomShapeGeometry does not exist for a text frame. Getting
the property throws an Exception and cause a general IO error.
Change-Id: I0e31780292d45211bfd1250d0d359c72def50583
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105834
Tested-by: Jenkins
Reviewed-by: Mark Hung <marklh9@gmail.com>
|
|
Change-Id: Ia60e7c5e2d3be0baa0496a6bd99c6ae98cd4ff96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105730
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
not just functions
Change-Id: Icca295dd159002b428b73f2c95d40725434f04d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105789
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
" IF " and "IF " is the same, but "IFF " is something different.
Change-Id: Ieb2d128d28ed3daa3df73128804bcc40dda9878d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105783
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This builds on top of commit d09336fbdceaafd9320466b660a2b32a07dcc16a
(tdf#125038 DOCX import: fix lost MERGEFIELD result inside an IF field,
2019-10-31), and extends it for more cases.
We know that DOCVARIABLE, FORMULA and IF fields inside an IF fields is
not something Writer is capable of, so make sure we keep the cached
result.
Change-Id: I20004f97c2073309c33594e5da6f8ba89ba278ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105639
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
This reverts commit 48b667a7e7d25f835f95df89162a7849d6972531.
Reason for revert: some discussion required
Change-Id: Ia0990d280837fb68b7ddc9f472ec78b1467b4311
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105540
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This patch is based on testing results, since I couldn't find anything
in the documentation that indicated a change between Word 2010
and Word 2013. But the evidence is fairly clear I think.
To quote from MS documentation on relativeHeight:
> This attribute shall only indicate the Z-order with respect to other objects
> in the document which have an identical behindDoc attribute value.
> _All_ objects with a behindDoc value of false shall be displayed
> above elements with a value of true.
But only wrapNone makes mention of being affected by behindDoc,
so apparently MS decided to ignore it for some reason starting
in Word 2013. By simply changing the compatibiltyMode value to
one lower, Word 2013 again starts to honour the behindDoc setting.
Change-Id: I7ef40387707ab5376cf8fa4d8a208c5b6a8b37ed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105486
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
which was added in
commit 331e2e5ed3bf4e0b2c1fab3b7bca836170317827
Author: Noel Grandin <noel.grandin@collabora.co.uk>
Date: Thu Sep 14 08:49:52 2017 +0200
long->sal_Int32 in Fraction
presumably to make the change impact less code.
Instead, update the call sites to reflect the actual bitwidth
of the data we will be receiving.
Change-Id: If2a678b1cf534f39cb8cb249757462be53658309
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105607
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Add new methods "subView" to O(U)String to return substring views
of the underlying data.
Add a clang plugin to warn when replacing existing calls to copy()
would be better to use subView().
Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iefe922c2e0d605114d54673d63eccc5e4abd545d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102143
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Regression from commit af313fc149f80adb0f1680ca20e19745ccb7fede
(tdf#105143 DOCX import: enable DoNotCaptureDrawObjsOnPage layout compat
option, 2017-01-06), this now uncovered a deeper problem that paragraph
top margin import goes through ConversionHelper::convertTwipToMM100(),
which ignores values larger than 0x8000. Previously this problem was not
visible as we (incorrectly) captured draw objects inside the page frame.
Word does not ignore values larger than that constant for paragraphs, so
fix the problem by using convertTwipToMm100() directly to just do the
conversion, without any checks on the input.
And now that the paragraph margin is not lost, it'll have the correct
horizontal position, so the position of the triangle in the bugdoc will
be correct, too.
Change-Id: If664ad055f1916b7e7fb2fb85d1afa977c2d03aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105496
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Previous exception (std::out_of_range) was not catch in case
of invalid RTF imported: wrapping code checks only for
uno::exception. This is not a case for loading file, but
for parsing of clipboard containing invalid RTF it was causing
fatal error, freeze and/or LO crash due to unhandled exception.
I think there is no reason to add generic processing for
std::exception in RTF filter: this can complicate diagnosing
other potential problems. Instead let's throw UNO exception,
like in other parts of RTF filter code.
Change-Id: I064bbdc1559cc7700c96dbbeaf2911a2c8e0421e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105285
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
There can be a number of things that can set PROP_BREAK_TYPE,
and thus an un-inheriting value of PageBreakBefore should not
cancel a w:br for example.
There are two ways to approach this. One would be to never
overwrite, and that should be safe in practice, since I don't
see anywhere else that would specify a NONE value.
However, if PageBreakBefore is true, it ought to override
a theoretical NONE, or potential COLUMN break I would assume,
so in that case a "yes" page break should probably override,
but a "no" page break should not. Basically, if anything
specifically requests a page break, they should get it.
(Actually, I'm not sure how, but column and textWrapping
breaks seem not to be affected by this - which is good.
Only the page break seemed to be lost when PageBreakBefore=false.
I tested by changing the w:br type to column,
textWrapping, and the invalid value of none.)
NOTE: If there is both a w:br and a PageBreakBefore=true,
then MSWord 2003 treats both as a valid page break,
but neither Word 2010 nor 2016 add the empty page.
See bug report for two proof unit tests.
Change-Id: I279874c60cc4cc572e0d190dc2afad0ad3431c43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103223
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Idb6dbb7ccb9a254def6029bb9ba84a3b02015d70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105196
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
* Implement text::XTextField in SwXFieldmark
* That requires overriding XTextContent, just forward to SwXBookmark
* Also override XServiceInfo implementation in SwXFieldmark
* Add a PropertySetInfo for SwXFieldmark, which doesn't support "Hidden"
or "Condition" properties of SwXBookmark
* in SwXFieldmark::setFieldType(), only allow sensible new types
* fix DomainMapper_Impl assumptions that if it implements XTextField
it can't be a fieldmark, which caused CppunitTest_sw_ooxmlexport10
testTdf92157 to fail with a SAXException caused by some disposed
SwXTextCursor
Change-Id: I1ae2e9cb99ea784040874517e4d1af7e59d24405
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105083
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I8b4527c8e40687918b3d5193f6c14ee86addab53
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105132
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ib5ffb2b8a31f237d5d2e465bf3f777590e0bfade
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104947
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Somewhat similar to copy&paste, the altChunk mechanism drops styles from
the inner document by default. A surprising consequence of that is
sections in the inner document have the default page size. This leads to
a page break when the content of the outer document ends and the content
of the inner document starts.
Fix the importer to support this:
1) Ignore the page size and number in DomainMapper::lcl_attribute().
2) Pass the start of the current section to the sub-importer, so that it
can insert the starting page break at the right place.
Change-Id: Id3955f2b35a139692254c4ac1233e96eef2620e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104821
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
and text boxes. Auto top margin value of the first table cell
paragraph is zero. Paragraphs of shapes and text boxes
anchored to this cell paragraph don't matter here, so keep
m_bFirstParagraphInCell=true in shapes and text box paragraphs
to avoid extra top margin of the anchoring point.
Regression from commit 5c6bce38a01b21403a603acd3148cf3bbb4c685f
(tdf#104354 DOCX import: fix paragraph auto spacing in tables).
Change-Id: I22c4ae230bc0192f06d3d155217887c471c67b67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104816
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
(*) create a rewriting plugin to do most of the work, heavily
based on the fakebool plugin
(*) but there are still a number of "long"s in the codebase
that will need to be done by hand
(*) the plugin needs lots of handholding, due to needing to
add #include and update macros
Change-Id: I8184d7000ca482c0469514bb73178c3a1123b1e9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104203
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I6cf543bd7052f7664b4d674e70c0d8a64cd1f734
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104739
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
This refers to a self-contained full DOCX file inside a DOCX file.
Change-Id: Ic9451833db30231f08ff2e2493da678edbc9a4c6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104654
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
|
|
...properties, not cell properties.
What is supposed to happen here, afaict:
1. \trpaddfr3 either has an effect on the left margin too (despite being
defined for right), or \trpaddfl3 is the default, 0 is not the
default
2. \trgaph600 should be ignored if the \trpaddfl3 is in effect
3. \trpaddl0 should be in effect, overriding both the value from
\trgaph600 and the built-in default of #define DEF_BORDER_DIST 190
CellMarginHandler::lcl_sprm() needs to distinguish between \trpaddfl0
and \trpaddfl3 cases, but its not possible currently because a)
\trpaddfl is processed after \trgaph/\trpaddl, and b) both \trgaph and
\trpaddl produce the same srpm-id.
This fixes \trpaddl handling just enough to import the bugdoc properly,
for more fixing a new sprm-id for \trgaph would be needed at least.
At the other end, there is a line in DomainMapperTableHandler.cxx:
m_aTableProperties->getValue( TablePropertyMap::GAP_HALF, nGapHalf )
... but nothing that would initialize the GAP_HALF there.
That this bugdoc looked right before commit
c2a5346b19c57f93f210b76c15cdba64f6871203 appears to be entirely
accidental.
Change-Id: I80dc34bdd5dadb7d7d7f5ec595907035d621a656
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104638
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
This is just the tokenizer, the domain mapper part still has to be done.
Change-Id: Iba171edeac42f1fa62b49dd0d188d41a539bb0c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104640
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Allow relative alignment to the top page border (the area
over PAGE_PRINT_AREA) by adding constant PAGE_PRINT_AREA_TOP
to com::sun::star::text::RelOrientation.
Fix DOCX shape import of <wp:positionV relativeFrom="topMargin">.
Follow-up of commit 6788133b3bdf02097d66a99047aa7bcba3a99a66
(tdf#135720 sw: fix PAGE_PRINT_AREA_BOTTOM alignment with footer)
and commit 79107d3f8d10aa0f38641775c5eb47dcfd4fd37e
(sw from-bottom relative orientation: add UNO API).
Co-authored-by: Balázs Regényi
Change-Id: I3a3f7324c0ef8d448526982d3e2f09b67f5fd4d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104113
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
Change-Id: Ib9fd7e3ffbe8760edf4a108342aa5ed03c453b01
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104487
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
|
|
A comment can also cause a missing footnote separator.
Found by doing a code read.
Change-Id: I42296f2e9406ad144c6e45873fac0f2cb8d11839
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104282
Tested-by: Jenkins
Reviewed-by: Justin Luth <justin_luth@sil.org>
|