Age | Commit message (Collapse) | Author | Files | Lines |
|
Fix the issue caused by wrong assumption about symbol chracter
and symbol font attributes order in writerfilter. Also allow
symbols to be displayed if user's language is not Western.
Reviewed-on: https://gerrit.libreoffice.org/16543
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Conflicts:
writerfilter/source/dmapper/DomainMapper.cxx
Change-Id: I602d9fbfa79c33c90f655dbf5ee22738b6391ae6
Reviewed-on: https://gerrit.libreoffice.org/17457
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Commit 0208ead70a9412ccd554fcef3e9308f8ca17037b (DOCX import: improve
btLr table cell support, 2013-02-22) made any table row that has at
least one btLr cell fixed height. This causes problems in case a table
has a minimal height with lots of content, where the fixed height gives
wrong layout, but the minimal height is correct.
Fix the problem by only making the row fixed height if <w:cantSplit/> is
set (as seen in the old bugdoc), and revert to setting the height type
to minimal in any other case.
Change-Id: Ibaf91f542e64e5caa7904df97eb6eb52618e0023
(cherry picked from commit 233a634a112e6dae07dca5fb1296764cb0001503)
Reviewed-on: https://gerrit.libreoffice.org/17338
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Avoids crashing with empty context stacks.
Change-Id: I0ee8b457fdbb19b55f5c15876b7253680cde6e23
(cherry picked from commit a61fd02c819433a1206b3b3e61017ba2d0d3d467)
Reviewed-on: https://gerrit.libreoffice.org/17334
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Commit c1f8437dbed0e8b989e41a345ef7e658a6e8a4cd (fdo#83465 RTF import:
handle font of numbering, 2014-09-25), changed the "get the me character
style of the current numbering's current level" member function to be
successfull even in case we're inside a DOCX run, not when we're inside
a DOCX paragraph, but outside runs.
While this is necessary for RTF, the side effect of this was that
unwanted run properties started to affect the above mentioned character
style in case of DOCX.
Fix the problem by enabling the "in paragraph and run" looking for RTF
only.
Change-Id: I610bfce6cec15b918fe547402360f5a894401f7e
(cherry picked from commit fc7c1a07d0d5e21a4e1533a0e5b0ac256763f973)
Reviewed-on: https://gerrit.libreoffice.org/17323
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
One one hand, a problem since commit
330b860205c7ba69dd6603f65324d0f89ad9cd5f (fdo#68787 DOCX import: handle
when w:separator is missing for footnotes, 2013-09-04) was that the type
attribute from <w:footnote w:type="separator"> resulted in two
ooxml:CT_FtnEdn_type tokens, ignoring too many paragraph ends for
footnotes, which resulted in missing paragraph style on footnotes.
On the other hand, fixing the first problem showed that it wasn't
correct that commit 9389cf78e304a5a99bcf1745b9388e14ac36281a (cp#1000018
RTF import: empty para at the end of footnote text got lost, 2013-11-15)
unconditionally removed the RemoveLastParagraph() call in
DomainMapper_Impl::PopFootOrEndnote(). It turns out that RTF and DOCX
have different semantics here, the footnote is always within a <p></p>
pair in DOCX, while in RTF a \par at the end of a
footnote means an empty paragraph. Fix that by conditionally restoring
the removed RemoveLastParagraph() call.
(cherry picked from commit 519b34300f73b1e08f6194d6ba49d4fc010cf186)
Change-Id: I33020ac761c94addfec8164a17863565e4453b07
Reviewed-on: https://gerrit.libreoffice.org/16810
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
cherry picked from commits 976add10b35e482251ed4c75957baeb6811e6e2c and
091fe76b6329b4bb974987554369cbfadd8f2401
Change-Id: I017049a8f3578ad4c2a1f549be1c683f98c20318
Reviewed-on: https://gerrit.libreoffice.org/16692
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
(cherry picked from commit ffc7b671e213d366e59d39ddbbef66544ebf01e5)
Change-Id: I1af1d6bc150c16a2c6b0fe788a41c8c18caee6c6
Reviewed-on: https://gerrit.libreoffice.org/16785
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Reading SwWW8ImplReader::CoreLoad()'s "update graphic bullet
information" block, it turns out that the numbering picture bullet's
height should be independent from the supplied bitmap, and only its
aspect ratio should be respected.
(cherry picked from commit eab89b7f024a8c86decdcb3362c40c40a7df37df)
Change-Id: I1300aa0397a8098df2a3170af795fbba47fd2a9e
Reviewed-on: https://gerrit.libreoffice.org/16502
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Commit 3d7e168a2a43c2414b0633379102ddb29437e75b (n#783638 DOCX import of
wp:inline's distT/B/L/R attributes, 2012-10-11) was about a picture that
had non-zero spacing in LO, but zero in Word. The hope was that the
problem is just that the value is not imported.
Then commit a88ac708403c03d0f950f09ec29c0d5a1e5a85b4 (fdo#63685
wp:inline's distT/B/L/R is in EMU's, not twips, 2013-04-19) was about a
picture that had so large spacing that the picture become invisible.
Fixing the unit of the spacing value made the picture visible again.
What was missed is that this value is just stored in the doc model, but
layout in Word doesn't use it at all till the anchoring is as-char.
Given that in LO as-char anchoring supports real spacing, just don't
import these values to have the same layout. That's what the WW8 import
does, too.
Change-Id: I1244269e06c5d190e8340349ddc12ae7b0572a4d
(cherry picked from commit 9781a8786da5c32e2250cbe1ae97bd10f84f39bb)
|
|
Writer doesn't support foot or endnotes in TextFrames, so they are not
supported in OOXML floattables, either. In the past, floattables were
imported as normal tables, that's how this worked. Restore the old
situation till the core limitation is there, so we at least don't
regress.
Change-Id: I4eb62617e3131176f7371e9ca69f11bc9e948a0b
(cherry picked from commit 2fe248f2b36d541c0d243a620c217058a50a9d5d)
|
|
Since there might be arbitrary rtf markup inside, we rather
shouldn't act upon.
Reviewed-on: https://gerrit.libreoffice.org/16206
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
(cherry picked from commit 63fbd90099098218994899ca7da3eb5e1656e4e7)
Change-Id: Ia782d89cb4ce8f34df64a3e0cba16de2db7b7ccf
|
|
A missing seek in the \footnote handler could result in a situation that
the missed text contained a "{" but not its matching "}", which resulted
in the parser terminating earlier than the end of the document.
(cherry picked from commit 7b08304b55cf2284a3c583426c60baef618ba206)
Conflicts:
sw/qa/extras/rtfimport/rtfimport.cxx
Change-Id: I6df476b2d6397dfa918111b33854dc2f95fbe81d
|
|
Change-Id: I7a3a233a34453153b3e1c0fe3d60bb0ede65dc86
(cherry picked from commit 292ec5fe8d01af6119325f1a426422bb42e58615)
|
|
Floating tables may or may not be converted to table-in-textframes
during import, depending on if we guess that it'll be a multi-page table
with minimal wrapping or a real wrapped table.
If the floating table is in a header or footer, then it won't be a
multi-page one, so can do the conversion right away.
Change-Id: I8d5ff8c5fe00037d5cef92dea6b54de6806214bc
(cherry picked from commit 81ef96a2417c7843dfed0558c920ad3064e58921)
|
|
Change-Id: Ie779e78fc3c7ccf717117513d9187697c22cc51a
(cherry picked from commit 0123bbbc4d07fd7d6c233f67139984ab3cd4555d)
|
|
(regression of commit ab81e3bff2a1844be67209bc8947d539edbaf8e6)
Change-Id: Ie78f8be059b18cdd81c83a8d01f2d865ac3fec2b
Reviewed-on: https://gerrit.libreoffice.org/15916
Reviewed-by: Joren De Cuyper <jorendc@libreoffice.org>
Tested-by: Joren De Cuyper <jorendc@libreoffice.org>
|
|
Change-Id: I92de8fa6a48dac9a0a09e6ebda4af9b8e4c3a1d7
(cherry picked from commit a30886283f50f4e05f70175d110a1c55e02037f0)
|
|
See SectPageInformation::mnColsx on the libreoffice-3-6 branch + the
spec agrees, too.
Change-Id: I6f70a125f8d962621f319e3e75e2865e5f126859
(cherry picked from commit e18adb7369d140f33b947668a69da2fa78738e7b)
|
|
Fix the situation for OOXML import filter:
a) While handling DocGrid type, SnapToChars was treated as
None. Now it is implemented as described in the article:
http://linpeifeng.blogspot.tw/2007/02/text-grid-enhancement.html
Both LinesAndChars and SnapToChars will be translated to
Writer grid type "lines and characters", and set SnapToGrid
property to false or true accordingly.
b) All the imported paragraphs snap to grid because SnapToGrid was
appended to grabbag, now it allows SnapToGrid property in
paragraph and paragraph styles to be imported properly.
Change-Id: I446b4c64c0ed86960896bcd61a1006c9173a757a
Reviewed-on: https://gerrit.libreoffice.org/15732
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: I6dbc972c1d6e05667ac5f354703a77db4266aea0
|
|
since we only ever instantiate one of them
Change-Id: I48b3b976b4f33044c4bf6542ac5cce58f26e6244
Reviewed-on: https://gerrit.libreoffice.org/15759
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Just pass over an std::vector instead of getAsConstPropertyValueList()
and comphelper::sequenceToContainer().
Change-Id: I584c44918b526cbed99abdbbf069c4bbf27ac887
|
|
Change-Id: I5ce8b00736fed6d4fb307c6384deca4718e770a3
|
|
The problem was that commit 76c0d0abc89cd8948706083c2660b71a2dad670c
(RTF import: adapt getProperties() to createStyleProperties(),
2014-09-07) only made the character style sprms/attributes a flat list,
but not the paragraph style ones. Fixing that inconsistency avoids the
tokenizer adding unwanted default sprms, which cause the bold sprms go
away in the bugdoc.
Change-Id: I86bd1b26af18cd968375c9b39be9c8e71d51271f
|
|
Change-Id: I9df4b1e04178b99d40aa3e08297b5bc5a30a9bce
|
|
Change-Id: I1e4cf3241bee20677f61ea334efc3aa4e490a016
|
|
sw core is not yet adapted, will be done in the next commit.
Change-Id: If8da12427e0cdaced4c1c1776b9f0b8cbde5c57c
|
|
The eColorMode and other graphic attributes were never checked due to this statement.
This statement is last altered by 0f0a22ade666d33a10d9c83c0f636be9acf1ed39
This only fixes the import.
Change-Id: I9ba7e745582faf37898f284600d638aa4806a362
Reviewed-on: https://gerrit.libreoffice.org/15710
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
RTFSdrImport::resolve() already had the logic to use the relevant API
depending on if the shape is a text frame or not -- extract that to a
separate member function and use it from RTFDocumentImpl::popState(),
too.
Change-Id: I663b372244f09f002447ece62587143b2a575795
|
|
Change-Id: I4c684903952fbfdaad52cabc135625a89b55c75a
|
|
Change-Id: I64fdb27a7f83f6417a9cd67ed5d2c44072ec7f2e
|
|
Change-Id: I674eadb84fc870031244a61f5c07d2cdf18a8dd1
|
|
Change-Id: I4195fc8a7736a29a6f08d0745f39a0907a5545e8
|
|
Change-Id: Iebfbeab422b7a0ef19981e146db0e7b7508e80c0
Reviewed-on: https://gerrit.libreoffice.org/15594
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
These were added by commit cfc4650c8594334edecc3b50ca54461f6bee2d43
(Added some teaks to 'model.xml', 2014-09-16), but the matching dmapper
part is missing, so they aren't useful in practice, and cause a crash on
import of crashtest's File_953.docx.
Change-Id: I3d1c138534a37dc9ba500f1134ca4bb9ebae0e96
|
|
it has no subclasses and no state, so it doesn't need
locking or reference counting or even an instance
Change-Id: I1e0f883946cb0e9bd26b49d12e58d813ce90a3b8
Reviewed-on: https://gerrit.libreoffice.org/15532
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: I634402fb0739b8d42d43264c57340dd030f86d78
|
|
Change-Id: I577db0bcb4c9fd45530132409fabf1a422f3d2cb
|
|
Change-Id: Ia52a2e3d6d98cfcc33a307ddcfc218a8426058dd
Reviewed-on: https://gerrit.libreoffice.org/15538
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: I61d1907a8c3a53c526992cc615478ee57a097fb6
Reviewed-on: https://gerrit.libreoffice.org/15528
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Ifb3431a50f92b95dfc1e851f9584533271e69324
|
|
Change-Id: Ie145292074b39fae5da40a7337737dd753b4d2ea
|
|
Commit e789c7f0f15a6b571de95b81e77e3a323e9f540e (RTF import of
d{x,y}WrapDist* shape properties, 2013-04-09) added support for wrap
distance of shapes, but that was ignored for shapes, as dmapper later
overwrote the set margins.
Fix this by generating the expected tokens in case of pictures, then
dmapper will take care of the rest.
Also add testcases for the original shape wrap distance feature that was
missing.
Change-Id: I6f219ee6fef71328368409d142897dbae77a0f2f
|
|
Especially the 'using namespace std' is scary, now that we have
std::shared_ptr and boost::shared_ptr, too.
Change-Id: Ibb584281f1b9d56103ab5984473eb484157c12d5
|
|
Change-Id: I2a1d0e194af6eb5fb865d3ed26712eed09a3b28f
|
|
Change-Id: Ie15422d7936cd84d5c4a07a5b75fdb02efc6ea1e
|
|
Change-Id: I399b389d4bd54357c6578417d2983017a60f0f51
Reviewed-on: https://gerrit.libreoffice.org/15383
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Icda809faf315dac5953d38781b2b401d51f7a40a
|
|
Change-Id: Ibbd0404c88a4086b9583a430e8c6fa4d0bc558eb
Reviewed-on: https://gerrit.libreoffice.org/15377
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
"Automatically Hyphenate Document Contents When Displayed"
Change-Id: I832eed60511b332a3f936b8239fd0a56a84879f1
|