summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)AuthorFilesLines
2021-11-18tdf#81507: word content control support for w:multiLineVasily Melenchuk2-1/+7
<w:text multiLine="1"/> is now supported for import/export to DOCX. Like other content control items it is stored in grabbag. Change-Id: Id6f1aa0072dc5db980d0fa43cab4b38a0aa047fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125024 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> (cherry picked from commit 1d9ab91901398126caf61e6234d782885bda6e27) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125362 Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de>
2021-11-18tdf#145215: docx: do not initialize prefix/suffix and include levelsVasily Melenchuk1-9/+0
On DOCX import we do not need to provide prefix, suffix and included levels: these values are calculated in SvxNumberFormat out from list format. Moreover these values are incorrect and do not correspond not to DOCX data nor to internal writer representation of list level. For 7.2 backport testcase was stripped: original testcase relies on tdf#141964 changes not backproted to 7.2. Thus for test doc "Chapter Numbering" dialog still looks weird. Change-Id: I91ec9de679e67056ba3746f2e1a0bd923532d76c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124090 Tested-by: Jenkins Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124136 Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-11-09RTF import: handle \snextMiklos Vajna4-0/+89
I.e. pressing enter at the end of a heading 1 paragraph should switch to body text. Change-Id: Idde9da3e2c058869a2ae4a9c61b3b43165121f5e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124883 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 926ac3c5e4b8eb425bc2db0366594acc0cf2c1ed) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124857 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-11-04RTF import: fix too small graphic size when both picwgoal and picw are providedMiklos Vajna4-6/+98
The original document provided \picwgoal and \pichgoal, stating the desired size of the image in twips. \picw and \pich is not provided, but we write it on export. The value of \picw and \pich is ignored by Word (it can calculate both the current and the original size from picw/hgoal and picscalex/h), so it displays the document correctly. Use the same trick in our RTF import: picscalex/y has a specified default value (100%), so if we have picwgoal and pichgoal, then we can also ignore picw and pich. This is needed, otherwise the much smaller size from picw/pich is used as the original size, so the layout "zooms in" so much that only a small white rectangle of the top left area is visible, as if the images would be all lost. (cherry picked from commit 995a6b38d5b8ac8aabca54f991caaaf35e6db395) Change-Id: I924e5f8b68613c654c857a57561c8a2e3a6db2f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124708 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-20writerfilter: give up if body text is missingMiklos Vajna1-0/+5
Crashreport trace: writerfilter::dmapper::DomainMapper_Impl::DomainMapper_Impl(writerfilter::dmapper::DomainMapper&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, com::sun::star::uno::Reference<com::sun::star::lang::XComponent> const&, writerfilter::dmapper::SourceDocumentType, utl::MediaDescriptor const&) writerfilter/source/dmapper/DomainMapper_Impl.cxx:359 (discriminator 2) writerfilter::dmapper::DomainMapper::DomainMapper(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, com::sun::star::uno::Reference<com::sun::star::lang::XComponent> const&, bool, writerfilter::dmapper::SourceDocumentType, utl::MediaDescriptor const&) writerfilter/source/dmapper/DomainMapper.cxx:113 writerfilter::dmapper::DomainMapperFactory::createMapper(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, com::sun::star::uno::Reference<com::sun::star::lang::XComponent> const&, bool, writerfilter::dmapper::SourceDocumentType, utl::MediaDescriptor const&) writerfilter/source/dmapper/domainmapperfactory.cxx:34 ollaboraoffice6.4/program/../program/libwriterfilterlo.so RtfFilter::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) writerfilter/source/filter/RtfFilter.cxx:152 I.e. we end up in a situation where the insert position does not have a containing XText. It's hard to continue from that point and this is in the ctor of the dmapper, so we didn't start the import. Just throw an exception to avoid further crashes. Change-Id: Idb5c06186a82c00b838d0b3330260340eb4218b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123795 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 05f1990cbdcd99f7ba4863b91a8f1f298b56326a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123784 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-10-19tdf#144798 DOCX import: handle ZOrder of chart objectsMiklos Vajna3-0/+21
Regression from commit 10efab2b9a3cf7fc49655c90ba29db4512680c38 (tdf#82824 DOCX import: fix at-char embedded object handling, 2016-11-15), the problem was that if we start supporting anchor types other than as-char, then handling ZOrder is no longer optional. (cherry picked from commit 63007619da7e6c4a6d0c466a8fe54324252be14b) Change-Id: I605cee33180490817055978b22f3271b3c08a1c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123794 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins
2021-10-12tdf#142407 fix incorrect number of lines in vertical writing.Mark Hung1-3/+3
Wrting mode isn't read correctly. The property PROP_WRITING_MODE contans an Any of sal_Int16. When converting to WritingMode enum directly, it always get WrtingMode::LR_TB(0), hence use wrong side to calculate number of grid lines for vertical writing. The resulted number of grid lines are much smaller than expected, it ends up leaving large space between header and text. Change-Id: Ifb0ff09fe981819cc2705de8d5596190f320f79e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123223 Tested-by: Jenkins Reviewed-by: Mark Hung <marklh9@gmail.com> (cherry picked from commit 5f84c44e3d5ff19b800b6358e61228546e318d4f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123396 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-10-05tdf#144609: numbering "None" should still show prefix/suffixVasily Melenchuk2-6/+7
Unlike it was implemented in tdf#143605, prefix and suffix should be displayed anyway, we do not display only numbers. Moreover tdf#143605 did accidentally fix tdf#135164 in a invalid way. So this patch is also providing a better fix for it: untittest is already created and failing without it. Problem in tdf#135164 is inability to distingush missing level text (bullet char in given case) and empty ("") one. In first case we should use abstract level definition. In second - not. Change-Id: Ica3a714d22de4d2f14ebbcb12f0e1311dbc9b801 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122609 Tested-by: Jenkins Reviewed-by: Vasily Melenchuk <vasily.melenchuk@cib.de> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123075
2021-10-05tdf#77051 DOCX: fix user index and index entry supportLászló Németh3-12/+36
defined by field code \f. E.g. INDEX \f "user-index" inserts only the entries defined by XE "entry" \f "user-index" field codes. Revert commit a7bc9c1e4977bd3430df69287fa0a8377a686c58 "fdo#77051: Preservation of Index field flag '\f'", which added an undocumented UNO property only for round-trip support of INDEX, but not for XE index entries, so the DOCX export still resulted a broken index with lost entries, not only the import was broken because of the missing functionality in com.sun.star.text.DocumentIndex. Now the import uses com.sun.star.text.UserIndex and com.sun.star.text.UserIndexMark index and index entry fields, which support the requested user index not only during the DOCX and OpenDocument round-trip, but its run-time functionality, the multiple user-defined indices. Note: for manual testing, update the user index (the first index) of the left original unit test document IndexFieldFlagF.docx: the updated index is not empty, as before, but contains the user index entries. Change-Id: Ia6139bba88907051fd050cfd40809f5544b9a89e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122930 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/+/123071 Tested-by: Jenkins
2021-09-23tdf#143722 DOCX import: map using default TOC heading styleGabor Kelemen1-0/+1
of Writer ("Contents Heading") instead of "TOC Heading". This essentially reverts the fix to bug #83300. When that was added the TOC import was broken enough that it made no visible regression. In 6.3 the TOC import was fixed up so now it's more annoying. The unit test of bug #83300 is reused but depends on the fix to bug #143726. I checked the example file of bug #83300 and the layout problem of comment 6 that was fixed there does not come back. Follow-up to commit 5440492ff9f949ee9ed9052e8bab6f5136d78b2a "tf143726 DOCX: export default TOC Header style with correct name". Change-Id: Iaee73729ea46a0c36d08ccc6fc5fb04fdf592a1d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120092 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit e3f9170c03eb9121b0c244c0e2e60d15e6920deb) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122279 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-09-21tdf#143591 DOCX import: handle anchored objects as at-charMiklos Vajna1-5/+2
This partially reverts cc8f8ae55f681755f5da3bf64e4c30bb713f0383 (DOCX drawingML shape import: wp:anchor's behindDoc attribute, 2013-11-19), it seems to be more important to be consistent with the DOC import than with the VML import which is no longer used for DOCX shapes crated with Word >= 2010. Change-Id: I631da010bce1b4d3c392645e0ae3797a03665a42 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122367 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 7246e57216bb20c15af0ecf6a0183f5ffa81e780) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122287 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-09-14tdf#123642: keep last bookmark at the document endVasily Melenchuk1-1/+74
In some cases DomainMapper_Impl::RemoveLastParagraph() can also remove last bookmark from real last paragraph. This does never happens when we use xParagraph->dispose(), but pretty always during older way with xCursor->setString(OUString()). Unfortunately without deep refactoring of redlines, bookmarks, etc. I see no other way to avoid this removal except given hack which is trying to store last bookmark and if it did disappear restore it. Some existing unittests were adjusted: corresponding original DOCX files did contain final bookmarks not taken into account by the code. In some cases test code is modified, in some just removed final bookmark in DOCX: such multi-format tests as in ooxmlfieldexport.cxx will be more identical to RTF & DOC variants. Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport17.cxx Change-Id: Ie9948b58cda705a0b85fa8e5e08b72fbb7d682b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121409 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122015
2021-09-06tdf#143384 DOCX import: fix SAXException at header with tableAttila Szűcs3-1/+9
Regression from commit d656191ec308d4280b93c7169372e543a255d108 "tdf#119952 DOCX import: fix negative page margins". Add SwXHeadFootText::CreateTextCursor(bool bIgnoreTables = false) (modeled after SwXBodyText::CreateTextCursor) to create text cursor for copying the header/footer also started with table during fly frame creation in convertoToTextFrame(). Note: add hidden property PROP_CURSOR_NOT_IGNORE_TABLES_IN_HF to use the new feature in domainmapper (followed commit af4e5ee0f93c1ff442d08caed5c875f2b2c1fd43 "tdf#97128 DOCX import: fix frame direction"). Co-authored-by: Tibor Nagy (NISZ) Change-Id: I96e2cf2dddcecd146c53c12d7fdb44fc4d90fa0d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119549 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit c1ad429d925855c1baacbdeca1ef42f4486eb9c2) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120985 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-08-19tdf#134569 writerfilter: move tableParaProps on table endLevelJustin Luth1-0/+6
The end-level of a table only comes at the ::finishParagraph of the FOLLOWING paragraph. So for table-in-table, it is necessary to move the paragraph properties captured during the paragraph to the correct table level's collection. This fixes 7.0 regression from commit 81ce88aa80f8e7cde4fdc5b211e9500a3599643c and depends on prior commit related tdf#134569 writerfilter: negative means table end Change-Id: I83183f38e1cf68b7db09813ca1b4a2491e7b54e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120526 Tested-by: Jenkins Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 28a7fec1f6465f8bfee417d447eb2e684ffe040b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120587 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-08-19related tdf#134569 writerfilter: negative means table endJustin Luth2-2/+2
TableManager's EndParagraph uses mnTableDepthNew - mnTableDepth to identify that a positive is startLevel, and a negative is endLevel. So it doesn't make much sense to have this function return a huge unsigned int in case of a negative. As expected, an assert proves that LN_CT_TcPrBase_tcW can happen for both positive and negative, so the equivalent test is just a non-zero. An assert proves that startLevel always has a positive difference, so that clause can stay as is. Change-Id: I1b49dfae7087258e4ceed5fb45da0e62fd1f3b50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120525 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 33d588ab553652637e90ecd543c1ffa6301c762b) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120588 Reviewed-by: László Németh <nemeth@numbertext.org>
2021-08-16Resolves: tdf#137742 Workaround cheesy Google Docs writing language-only tagsEike Rathke1-1/+23
Change-Id: I2dc85abb70d53769d2e36102070e30ed71e8d888 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120495 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins (cherry picked from commit 23f17b7ea6fbd2f422c7e40192ae60e4df25224c) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120438 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-12tdf#143318 DOCX import: fix missing redlines in flying tablesLászló Németh2-2/+9
makeRedline() exceptions (in the case of already existing redlines) skip the creation of the next (not existing yet) redlines in tables inside fly frames. Here: a tracked table moving revealed the problem, with the missing rejection of the new position, i.e. the "new" (second) table of the document. Note: fix also collecting redlines within tables: IsInTable() isn't true in the first cell of the table, losing the redline here, so it's replaced with m_nTableDepth > 0. Follow-up to commit 7f3c0bbc174b9b0316991c174ca3b407c0e3d141 "tdf#143510 DOCX import: fix tracked table drag & drop". Change-Id: Icf6dd62eb950e5af6a75353dffabb9e9433c1b44 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120333 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit afc0c718ec9ca6a4fbe1324f68eb292d9a67b058) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120356
2021-08-11tdf#143583 DOCX import: fix lost empty paragraphs of footnotesLászló Németh1-1/+4
Last empty paragraphs of footnotes were removed (except in the case of the first footnote), related to the double call of RemoveLastParagraph() during footnote load and later during its copying. Regression from commit 9b39ce0e66acfe812e1d50e530dc2ccdef3e1357 "tdf#76260 DOCX import: fix slow footnote import". Change-Id: I61d9aa6765f3af1893451684dde12c199251d06b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120270 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120334 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-08-04crashreport writerfilter: findColumn(unsigned long,unsigned long)Justin Luth1-0/+6
Although the crash reports don't show getRow as a separate item in the list of functions leading to the crash, it just CAN'T be a problem with mTableDataStack.empty() or !mTableDataStack.top() because they are unconditionally used or popped later on in endLevel(). So I resisted the urge to test everything, and just verified that the row (which exists for m_aCellProperties) actually exists in the table manager - similar to getGridBefore(). Change-Id: I5a27dc40db18f05ad4656789d3e61ec1ff4de471 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119420 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 82b14219969c4f80d421015c9e89e8d3db4650d8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119616 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-07-28Revert "tdf#58521 DOCX import: enable ContinuousEndnotes compat flag"Gabor Kelemen1-1/+0
This reverts commit e35fc16969c0d0a55538733d76fc4bb03bf137b0. Reason for revert: tdf#143456 shows there are layout problems with this compatibility option Change-Id: I4f03b9a0cbc6de1d3dbf79681f7caa203a1ce59c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119451 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-07-28Revert "tdf#58521 Enable ContinuousEndnotes compat option for RTF too"Gabor Kelemen2-4/+1
This reverts commit 59c5732875c1bea619ed461a378906a2dce12b48. Reason for revert: tdf#143456 shows there are layout problems with this compatibility option Change-Id: I73cbbb73f3110bc93840b8f0de0f2fab69250ebc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119443 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: Jenkins
2021-07-27tdf#142693 DOCX import: fix zeroing huge page sizesAttila Szűcs3-2/+8
which bigger than 2^15 twips (> ~57.8 cm). Regression from commit 4d1621136c464b462a598571ecdcfe2ae119d8c7 "Fix ignoring large twips values like MSO does (cp#1000087)". Note: Writer could export page size up to 600 cm × 600 cm, and now it can import it back as well. It can even import page sizes in kilometers, and display that, but there will be other issues about its display. MS Word couldn't save page size over 2^15, but can import, and display them till up to 2^16 (that is about 116 cm). Co-authored-by: Tibor Nagy (NISZ) Change-Id: Icc1bd708d53036768a7be94cb1ebe18c1c4c8487 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118940 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit d5d9795968771651c57c661d95b6992c3c778eca) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119441 Tested-by: Jenkins
2021-07-26tdf#143510 DOCX import: fix tracked table drag & dropLászló Németh4-0/+71
Accept or reject of tracked drag & drop table (row) move weren't handled, resulting an extra empty table (rows) instead of removing the deleted or inserted table (rows). Note: tables moved by drag & drop with track changes use w:moveFromRangeStart/End and w:moveToRangeStart/End bookmark-like elements to sign the boundary of the moved text. Now moveFrom/moveTo import is handled by tracked table (row) deletion and insertion. Change-Id: Ie382645fef28f57b30d3504fb28ac08489f705c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119406 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 7f3c0bbc174b9b0316991c174ca3b407c0e3d141) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119436
2021-07-20tdf#143399 DOCX import: fix lost endnotes or footnotesLászló Németh2-8/+10
in a document containing both of them. Regression from commit 7dd8f8aace536a8e60e87e61ee1d90d61fba15eb "tdf#120351 DOCX import: fix slow endnote import". Change-Id: I0fe764f3b48dd2688afa4b7cf0ee6658737ef9fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119239 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 732b08b22eee2682351a9295be29188852fb0489) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119187 Tested-by: Jenkins
2021-07-15tdf#58521 Enable ContinuousEndnotes compat option for RTF tooGabor Kelemen2-1/+4
Now it's used in RTF, DOC and DOCX import consistently. Change-Id: I062a5fbbdf6ee0ef4d3c86a09ce50ac3d588fae5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118960 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 892488b64f09190896d5a14e3f555ca91b3449e3) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118918 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2021-07-13tdf#58521 DOCX import: enable ContinuousEndnotes compat flagGabor Kelemen1-0/+1
like Writer for DOC import and MSO do to avoid to start endnotes on a new page. Change-Id: I37d54f189e7aa1f4d0ac829b6af0c03aec64b9f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118541 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit f9982c24066d6dd2f938cc20176af0f196bc018f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118797 Tested-by: Jenkins
2021-07-08tdf#142700 DOCX: fix lost track changes of imagesLászló Németh2-1/+70
anchored to characters or paragraphs. Tracked deletions and insertions weren't imported, if they contain only images anchored to character, resulting loss of the document content: i.e. deleted images were reappeared, as not deleted images. Note: because change tracking of the OpenDocument and Writer supports only text range based changes, the fix is a workaround using zero width spaces to create an invisible text around the anchoring point of the images. This workaround is not used, if it's not necessary, i.e. if the image is part of a bigger deletion or insertion, which contains also text, not only an image. Change-Id: Iaae6aae2c01191512c71117a0c788a4147c4cae0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118557 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 8726cf692299ea262a7455adcf6ec25451c7869d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118612
2021-07-06tdf#142464: do not escape '/' is AM/PM when importing DOCX.Mike Kaganski1-26/+36
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űcs5-82/+107
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 Grandin2-27/+18
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 Grandin1-1/+1
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 Melenchuk1-6/+8
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 Grandin5-19/+58
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 Nabet1-2/+1
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 Grandin2-3/+3
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 Luth1-1/+0
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 Gelmini1-1/+1
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 Luth1-0/+5
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 Luth2-1/+1
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 Vajna4-5/+77
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 Luth1-1/+1
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 Gelmini1-1/+1
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 Vajna3-13/+38
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 Melenchuk1-1/+10
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 Grandin1-4/+1
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émeth3-0/+37
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űcs2-9/+15
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 Grandin1-1/+1
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)2-1/+5
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 Grandin1-5/+2
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-18 10:40:52 +0000