summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2021-07-06tdf#142464: do not escape '/' is AM/PM when importing DOCX.Mike Kaganski
See also commit a2e964afc5187fc1e3b38720ec10ad9856b87020, doing the same for DOC. Change-Id: Ib0ddb36de8589f9264fe857b20a6ef2aa2607c52 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118369 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit cd0ab69d4afee0c77884ae17ab9410216695b58b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118413 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-07-05tdf#119952 DOCX import: fix negative page marginsAttila Szűcs
DOCX body text can overlap with header/footer, if top/bottom page margin is negative. To support this, convert header/footer text content to textbox anchored to header/footer, if needed. Note: possible improvements: 1) Skip this hack, if the header is small enough to not overlap with the body, calculate only the height of the header at the import time. 2) This hack does not fix the case when the top of the header is under the top of the body. (A problem in DOC import, too.) This could be achieved by repositioning the dummy header to the top, and lower the textbox by the same amount. (This would still not resolve the extreme situation, when the body start from 0 mm (in LibreOffice, header must be at least 1 mm). 3) Import of VertOrientation::BOTTOM property seems to be bad, or at least the footer loses this property after a DOCX round-trip, resulting bad footer position. 4) after a round-trip, the 1 mm height of the dummy header increases to 1 line height. Also the "Autofit height" and "Use dynamic spacing" settings are changed, likely related to their missing DOCX export. Co-authored-by: Tibor Nagy (NISZ) Change-Id: I8319c93c6c5a980878ee9956c8ab2953da60409e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117842 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit d656191ec308d4280b93c7169372e543a255d108) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118295 Tested-by: Jenkins
2021-06-30tdf#135316 store stylesheets in a mapNoel Grandin
for faster lookup. Shaves 3% off my loading time Change-Id: I075b42db52914988be4adef303825c211b02353f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117848 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit ab5ac64bdd3205ba2ba9ac038719826f703a09a3) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118110
2021-06-30tdf#135316 make regex object static constNoel Grandin
so we only compile it once, shaves 1% off load time Change-Id: I8e6e20205659582901ffb8d4496ce44906146204 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118157 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit 5ba64bba76ca1d23191300d1b5080cc091d432de) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118174
2021-06-29new ODF numbered list parameter loext:num-list-formatVasily Melenchuk
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) Conflicts: sw/qa/extras/odfexport/odfexport.cxx Change-Id: I9696cc4846375c5f6222539aeaadbca5ae58ce27 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117156 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118040 Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
2021-06-18tdf#135316 docx open performance, cache next character style nameNoel Grandin
so we don't have to scan the list repeatedly, which is O(n^2) This takes my load time from 37s to 22s Change-Id: I0df2f2ace82f5cd6287c7ded796b02c5242269ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117396 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> (cherry picked from commit ecbdb403d16f6b0aeb8b543e069e9d82adf10437) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117308
2021-06-11Simplify Sequences initializations (writerfilter/writerperfect/x*)Julien Nabet
Change-Id: I1bd31fe6cf0f8aaf4f2cfe1d3d49e61a0633f361 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117057 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-06-10loplugin:unnecessaryreturn FontTable::addEmbeddedFontNoel Grandin
Change-Id: Ib64799f06ee1fbcc43132df6ad44975a0dff347e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116973 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-09NFC compat cleanup: no need to specify default TabOverflowJustin Luth
This really confused me because it lead me to think that this was something done for MS compatibility. Well, that is only true in an off-handed way. LibreOffice itself was changed to work similarly to MS Word. So there is nothing special about how DOC or DOCX/RTF are handled. Since the compat settings are not saved or loaded into MS Formats (i.e. it just takes the default value), and since on an ODT save it also will just save with the proper default value, there is no need to specify "TabOverflow = true" in non-ODT import filters. Only ooxmlexport16 has a unit test that reacts if tabOverflow is false. That one is mine and it indicates that the document would be better if tabOverflow was off, so there are no examples of how tabOverflow improves a doc. Change-Id: I97c25154108bc1ca0fcd3dfcff66fea0ea2bca7e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116741 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2021-06-09Fix typosAndrea Gelmini
Change-Id: I3539edf26a793f89d38f3df376002f4ed4295343 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116869 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-06-08tdf#142404 DOCX c15: add compat flag TabOverSpacingJustin Luth
DOCX in 2013 (compatibilityMode 15) no longer supports TabOverMargin (i.e. the text margin), but it does a similar kind of thing if the tab goes into the spacing-after of a paragraph. So add a compat flag to handle this in-between kind of situation. I grepped -i "tab_*over_*margin" to see if I was missing anything. Decimal/Center proved to be only tabOverMargin. IsInSect shouldn't matter since it fits inside the printing range. The other places where I didn't insert TabOverSpacing didn't seem relevant based on a code read. Tab-after-tab still doesn't work great, but what we have is already a massive house of cards that will just collapse if changed. No real provision for handling tabs-over-paragraph-end. -auto-tabs are created instead of "beyond nMyRight" tab, unless it is the first tab defined. -doesn't allow auto-tabs to fill the remaining space. But on the other hand, MS Word's implementation of tabs follows some kind of incomprehensible bizarre logic, so just ignore the tabs completely, please. Change-Id: I3723107b29ec3e287ea8661544711c13eee3ca48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116667 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-06-01tdf#142404 DOCX c15: TabOverMargin no longer true in 2013+Justin Luth
When compatibilityMode is 15, TabOverMargin no longer seems to apply. This is a dramatic visual change in docx that I didn't find any documentation about, but the visual change is obvious enough proof. LibreOffice started saving DOCX as c15 mode in 7.0. [P.S. related TabOverflow also seems to be false with c15, but it acts differently than what LO's tabOverflow code does. That was discussed in a different patch and seems to be a dead end, so I'm ignoring that aspect. Way too many complications and effects on LO native mode.] Change-Id: I5a0a6d695d6825444cf6a362a81803f306e6c6e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116337 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-06-01tdf#142325 RTF import: tolerate invalid hex markup like "\'3?"Miklos Vajna
The RTF spec says \'hh is the expected form, where both "h" are 0-9, a-f or A-F. But Word accepts the bugdoc, so don't reject this input, handle \'<number><junk> as \'0<number>. At least the current case ignores the actual value, as it's a single character to provide a non-unicode value after \uN for old readers that don't support Unicode. Change-Id: Ib61247ab08278ca5012cc887cee26c7571c29fc6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116499 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-05-27tdf#94628: sw: allow setting for bullet style for outline paragraphsJustin Luth
Since LO 7.0 commit cad788328ec6ef4b3071cf9002dfac12347562da allowed bullets in the outline, I think you also want to be able to set the character style, wouldn't you? In any case, isOutlineNumbering is basically a meaningless and inaccurate concept anyway, so just get rid of that ancient clause. Change-Id: I2e40a3749b4a18864585c309349ea0e4ba73a9da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115613 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2021-05-27Fix typosAndrea Gelmini
Change-Id: I9a4ba6b6369da0bac489718230880b04912bd1d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116214 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-05-26tdf#139915 DOCX import: fix anchored obj position with to-char and TEXT_LINEMiklos Vajna
There were multiple problems here: - commit 8f1a1092d47947847e1d888b0284e8364c663d1f (tdf#97371 DOCX import: fix text covered by shape, 2016-01-28) disabled to-char anchoring for TEXT_LINE (e.g. "alignment top, relative to line") because changing the anchor type of a TextBox could not be changed, but this has been implemented in sw/ in the meantime, so it can be dropped - Now that the anchor type is to-char, we can set the vertical relation to TEXT_LINE, but Word's positive value is "below line", and ours mean "towards the top of the page, from the bottom of the line", so we need to drop the workaround of commit 3303a4c5f21874453e634d84408c50e7a0055a4d (tdf#135153 DOCX import: avoid line-of-text relation with to-para anchoring, 2021-01-18) Once these are in place, we can fix the remaining problem by inverting the vertical position of the shape, which instantly fixes the overlapping textboxes in the bugdoc. Change-Id: I895abb76d3bd3bbe3a84e5c27a77df722b96226a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116182 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-05-25tdf#132752: docx import: improvements for first line indent in listsVasily Melenchuk
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>
2021-05-13inline some typedefsNoel Grandin
Change-Id: I1608e03ff9f6fbc55987010e88897e034b690b3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115552 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-06tdf#128913 DOCX: import track changes of inline imagesLászló Németh
Deleted images were imported as not deleted part of the document. Both deleted and inserted images lost their change tracking. Change-Id: Ia273d307d01c5ea535889bc9951084e96cd7fc50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115178 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-05-06tdf#121659 DOCX import: fix lost column break at shapesAttila Szűcs
The column break was moved into the neighboring shape during the first import, and eliminated during the second import, losing the 2-column text layout. As a workaround, split the paragraph moving the column break into a new paragraph. Based on the patch written by Justin Luth. Co-authored-by: Justin Luth and Tibor Nagy (NISZ) Change-Id: Id4042a92b09aa55952bc0ea02319d5e588f77d3b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114904 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-05-05loplugin:constmethodNoel Grandin
Change-Id: I7913fd8144d521b8293ac43036d0fad82e457cd1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115145 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-04tdf#138782 DOCX import: fix frame positions of old docsAttila Bakos (NISZ)
by limiting AddFrameOffsets compatibility option for docs created by MSO 2010 or older. Likely regression from commit 355d25eac764713f4d52eac801ade6e2ff1deab0 (n#779627: added quite some compat options from the ww8 filter on writerfilter). This patch fixes several bugs, which were collected as duplicates by Gábor Kelemen. Change-Id: I106e90c4bf00bb0b6a8986615cb3ad9c4828d5b3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114476 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-04-29loplugin:stringadd simplify some *StringBuffer operationsNoel Grandin
pulled from a larger patch which I created with a more permissive variant of this plugin Change-Id: I7abf1f3f09e84703b6e0e52fe9587dff691b2187 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114875 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-22no need to create temporaries when appending number to O[U]StringBufferNoel Grandin
Change-Id: I36d82423b5f75010552696a66cec7e53ee265ce4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114395 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-22Fix typosAndrea Gelmini
Change-Id: Id06dc8750b735ecdba26ac607394c6e7dee16db2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114470 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Dante DM <dante19031999@gmail.com> Tested-by: Jenkins
2021-04-22tdf#141540 fix docx import of group or line with rotationRegina Henschel
... and fix case wrap 'Square' and 'in Line' with them. Non-uniform scaling of a rotated shape might produce skew. Such had happened, when setting group or line to the size contained in GraphicImport. Avoid it. Writer has special rules for shape position and marging in case of wrap 'Square' and 'in Line', depending on rotation angle. The patch adds the needed margins. The patch changes some unit tests where we now get slightly different values. The patch fixes the wrong skew in sample document of tdf#73022. Change-Id: Ic743790c3fc8b8b10a4324d9e0184ad945cdceb6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114193 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-04-20Document the new classes added in d8c0b63355af6caf3f0145dd1c10a93d63134a88Mike Kaganski
Change-Id: Ib7421dd9dfe9245f3b6d98b772c74f22ab7f983f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114333 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-19tdf#141548 DOCX import: fix lost text after endnoteRefLászló Németh
First run of the endnote (footnote) can contain not only the footnoteRef/endnoteRef, but endnote (footnote) text, too. This text was lost as a regression from commit 7dd8f8aace536a8e60e87e61ee1d90d61fba15eb "tdf#120351 DOCX import: fix slow endnote import", and in the case of the footnotes, from commit 9b39ce0e66acfe812e1d50e530dc2ccdef3e1357 "tdf#76260 DOCX import: fix slow footnote import". Change-Id: I9964ee47f456a7632a21ab3b0588d3cb70388011 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114300 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2021-04-16tdf#122222: add DOCX import of resolved comments as "done"Mike Kaganski
Change-Id: Id596d18965de2d8c98853c281188fe8d749055f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114204 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-16Small refactorMike Kaganski
Change-Id: I5fb506986e650cde1d6be7e4cfb2360335ab625b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114175 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-15We already have dynamic_casted the valueMike Kaganski
Change-Id: If9303af8a75f3bb82ad34d66e6838f2dd0ac8e8f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114010 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-15tdf#141660 DOCX import: fix footnotes of deletionsLászló Németh
Footnotes of tracked deletions resulted exception during import. They don't need redline copying, because the anchor point (the footnote index) is already part of a redline. Note: handle also remaining unhandled w:footnote type "separationNotice", which could result shift of the footnote numbering. Regression from commit 9b39ce0e66acfe812e1d50e530dc2ccdef3e1357 (tdf#76260 DOCX import: fix slow footnote import). Change-Id: I01e06fb25aba4f97cca31b5da34f5a7a3f18a54a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114137 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2021-04-14static const char[] -> OUStringLiteralMike Kaganski
Change-Id: I77fcd3260fd0f3d4c1a05624a9e9ea1dfad3792f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114004 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-14Use mpStream consistentlyMike Kaganski
I had to check above that pStream indeed points to same object as mpStream, which is dereferenced in all other cases. Change-Id: Ib31fad9c163ae828afbcf657b0922bae1b1ed16a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114002 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-14tdf#100961 rtf import: fldlock is FIXEDFLDJustin Luth
This depends on another fix in this bug report for exporting. I'm not sure why I even bother trying to work on RTF stuff. I'm not really into black magic. Change-Id: If596cae011a261a80ca13962932bf25561c0f63f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114062 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org>
2021-04-10-werror=maybe-uninitializedNoel Grandin
Change-Id: Iaa1905d181bc6dc86988c68a145d5d8fce11cda9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113904 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-04-07tdf#141341 docxexport: consolidate conversion of NumTypesJustin Luth
so that one comprehensive function is used for Page and Footnote numbering types (which was already being used by list numbering). I also added support for CHARS_ARABIC_ABJAD <=> arabicAbjad, which was my trigger for consolidating all this. OOXML has one definition (ST_NumberFormat) that specifies the valid values for pgNumType, numFmt (list numbering), numFmt (Endnote and Footnote numbering), so use the same conversion function for all of these. [Also used for caption, but I haven't noticed that yet in export.) In the previous code, there was no possibility for fmt.isEmpty() [despite repeated checks for that situation]. However, I thought it made sense to not specify anything if the conversion didn't match something known (because perhaps the locale could take over then?). In any case, that is a slight change, but for pgNumType we were specifying "none" instead of decimal, which didn't make much sense either. So I don't expect anyone crying 'regression' over that. Change-Id: I90037eb25a0f71d22d6ad1848f43761eb6b9fe00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113351 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-04-06Fix typosAndrea Gelmini
Change-Id: I64d32773984a3ab06e809fcaeff8f95b910e127b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113700 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-04-06update pchesCaolán McNamara
Change-Id: I835c8fcc237ece5cf9d7a3b261645139d022e9b4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113652 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-04-06tdf#136740: reimplement the fix using existing m_bIsNewDocMike Kaganski
This reimplements the fix from commit d7c4d0d4ea83481693af3645a03b03b53e456f60. The unit test from commit a90a324aa590a94a4091fbfadea67e0b0203767c still passes. Change-Id: I84c61fa68b9bee679a8e82ef7b8f164297bacb5a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113665 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-05tdf#136740: Do not initialize document settings when pastingMike Kaganski
When pasting from clipboard, the document already has the defaults set, and pasted text must not change those defaults. When pasting RTF, RTFDocumentImpl::outputSettingsTable does the document settings initialization, and is called from RTFDocumentImpl::checkFirstRun when m_bFirstRun is true. Other defaults are set in the latter function, too. This makes m_bFirstRun false when RTFDocumentImpl is created in the context of a paste operation. Alternatively, checking the context could be made when deciding if to apply specific settings. Change-Id: Ide1eabbef1d04a4fa2f1ca14846b8e404f2a0cb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113613 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-05crashtesting: assert in fdo6872-1.docx in CopyImplImpl after SAXError exceptionCaolán McNamara
sw/source/core/doc/DocumentContentOperationsManager.cxx:5040 assert(pStt->nNode != pEnd->nNode); presumably due to the error the positions are wrong when CopyImplImpl is called in popping the context where the exception occured, so skip the asserting operation if the document failed to load and will be thrown away fixes fdo68738-1.docx, fdo46060-6.docx, fdo55725-1.docx, fdo68721-1.docx but similar ooo127821-1.docx remains Change-Id: I09aca7a6884f7806c74797466522bb489260da51 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113572 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-04-01tdf#141341 writerfilter: use all NumberingTypes for pgNumFmtJustin Luth
We have a nice conversion function to translate from OOXML to writer's numbering formats, so lets use that for the page/section's numbering format too. Change-Id: Ibf2aaae5d66c971b54440862b1156c00202663e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113350 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-04-01tdf#140343 sw page rtl gutter margin: add RTF filterMiklos Vajna
Map to the \rtlgutter section flag. This means that now rtl gutter is handled for all Word formats. Change-Id: I4c2c12b7df2ce2109d4d638df71e6b7f322afe52 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113439 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-03-31tdf#141158 DOCX: import discarded headers/footersAttila Bakos (NISZ)
Before the inactive DOCX headers/footers lost during import time. Now it can be restored by disabling the options “Same content on left and right pages” and “Same content on first page” on the Header and the Footer panes of the Page style. This is for improving the interoperability with other Office programs, e.g. supporting DOCX text document templates better. Follow-up of commit f5dc6b11d2218d94c9effe7a1ab418d0133da5e3 (tdf#140117 sw UI: keep headers/footers when inactive). To start the py-UItest run: $ make UITest_writer_tests7 UITEST_TEST_NAME="tdf141158.TestTdf141158.test_tdf141158" Note: In spite of this patch implements the left/first/first_left page header/footer stash at import time, the left one works correctly at now. This is because the first pages have different page styles so changing the right page style will restore the hidden header/footer content. For this problem further improvements are planned, exactly in the filter part. Number of unit tests had to be modified, because before these headers and footers were dropped. Co-developed-with: Daniel Arato (NISZ) Change-Id: I3dd452a648bc465710698707c083734dc762ed94 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112580 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-03-31Make RTFKeyword and RTFControlType scoped enumsMike Kaganski
Change-Id: Ifae0afd1468ab162b8d815e8b614afc1442169a6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113406 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-31tdf#140343 sw page rtl gutter margin: add DOCX filterMiklos Vajna
Map to <w:rtlGutter> inside <w:sectPr>. Change-Id: Iaa1d9da8c1585ec31c7cbe539f49643eb972c327 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113398 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2021-03-28tdf#95806 tdf#125877 tdf#141172 DOCX: fix tables in footnotesLászló Németh
and endnotes by converting them to floating tables during the import, and removing floating at the DOCX export. Writer core doesn't support non-floating tables in footnotes and endnotes officially, (flowfrm:cxx: "Tables in footnotes are not truly supported"), so their DOCX import resulted serious problems: – missing table paint (tdf#95806); – table loss during saving to ODT (tdf#125877); – table loss during copying them or their footnotes and endnotes in the document (this resulted the regression of the optimized footnote and endnote import: tdf#141172); – table loss during changing the order of the chapters in the Navigator. Change-Id: Ife8af41936ae3ab003a3a9ad33b98c1d813e9c82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113162 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2021-03-25const OUString -> const OUStringLiteralMike Kaganski
Mostly automated rewrite Change-Id: Ie020a083f898bc126b8fb039d4ecb2e687172da1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112965 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
generated by cgit (git 2.34.1) at 2024-06-26 03:54:38 +0000