summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2020-02-07tdf#108272 DOCX table-only header: fix SAX parser errorLászló Németh
Floating tables in table-only headers are imported as non-floating ones after a SAX parser error. Now we import them as non-floating ones from the beginning to avoid of the parser error. Change-Id: I0a816a7af642f402a25ed53d9766b1e8b82db789 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87874 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 213d6390a2cc59d174173f4359c161625a9c4bdc) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88097 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-01-30tdf#129237 just add content checks for Input fieldsJan-Marek Glogowski
There seems to be fields with content values, which don't use it as the presentation value. So this reverts the content handling code back to the original one and just checks the content value from Input fields in addition to the SetExpression fields. Change-Id: I2abd227883035c559b1fc3f7aacf10769b0e79a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87093 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 3a248dfe57318af57fc5df89652cb64dfa923e46) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87740 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-01-30tdf#129659 DOCX check global footnote contextJan-Marek Glogowski
Since tdf#121441 we parse custom footnotes to get at least the DOCX footnote text, even if we can't represent the formating. This might push additional contexts to the parser stack. Therefore it's now not sufficient to check the current context for a footnote, but one has to check the global parser for a footnote context. The actual bug is the unsupported footnote page break, which was not correctly ignored and added a paragraph context to the stack, resulting in the async substream input and output stack size. Change-Id: I143254e7df37a619cb4efb542b58d3eff3afffa7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87114 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit b87af9775167002d36a3bc16cb308ea7895d7ea0) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87742 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2020-01-28tdf#130214: workaround invalid state resulting from error on importMike Kaganski
Obviously the real error is somewhere else, which results in tdf#126435, and produces unexpected state with missing text append context on stack. This is just a hack to avoid crash. Change-Id: I420ac3b74f5efb9688dc764ac2ad0dcc974ba0e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87595 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit eca00082c78fddf79f247057227404738be8806c) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87634 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-01-20tdf#129452 DOCX import: fix bottom border of merged columnSzabolcs Toth
Bottom border of a vertically merged column of a table was missing if the inside borders were turned off and the merge included the last cell of the column. This happened because the first cell (topmost) in a set of vertically merged cells determines the borders of the new merged cell, and the turned off inside borders were at the bottom in this case. Change-Id: I3d3defad18a1315117a554a36ad599eb46daffe9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85988 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 0f4dd820ee433932d9d9237b676292d31c4ba913) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86430 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-01-20tdf#129888 DOCX shape import: handle o:allowincellBakos Attila
(VML) and layoutInCell (DrawingML) attributes to fix regressions caused by commit 10f29d8bf05d44ca8bc11d34d1294ec17f8ac0f1 (tdf#87569 tdf#109411 DOCX import: fix shape anchor in tables). Position of shapes anchored to tables is calculated from the cell margin only if the previous attributes allow that. Change-Id: Ifcfcb7f4959aea522dd45dff00cefd1bb9f4edda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86922 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> Signed-off-by: xisco <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86980 Reviewed-by: Attila Bakos <bakos.attilakaroly@nisz.hu>
2020-01-15tdf#129525 writerfilter: ignore GOTOBUTTON fieldMichael Stahl
The bugdoc contains nested fields for some of the page numbers: {\field\flddirty{\*\fldinst {\caps0\lang1024 GOTOBUTTON _Toc434317064 }{\field{\*\fldinst {\caps0\lang1024 PAGEREF _Toc434317064 }}{\fldrslt {\caps0\lang1024 4}}}}} The problem is that the outer field does not have a \fldrslt, only the inner PAGEREF field has one. This used to be imported incorrectly because the nested field's result ended up in the outer field's result; now it's imported correctly but then there's no field result to show, because Writer can't expand fieldmarks. As we can't do anything with a GOTOBUTTON field, just ignore it explicitly to prevent creating a generic fieldmark; the PAGEREF is already ignored inside of a ToX since commit 9679e9c23216decb5f9f25f85b04cb3f25211111. ("regression" from e511a0ca5dde6d731bb126bbfe21768867890102..d9030ad6298e2f49ee63489d6158ea6ad23c0111) Change-Id: I8135c8d14995378181ce959d22d9be5ea0cae260 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86796 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit f761059b8c8ffe4e7b6e28924898ba71ee6b9ea8) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86832 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-01-14tdf#129805 writerfilter: fix import of nested generic fieldMichael Stahl
The problem was that the end of the outer nested generic field did not call PopFieldmark(), so the end of the field was at the end of the document. (regression from f610f9b611fe9f206b872ed06f7e859d688385fc) Change-Id: If5928b14dd35f7dd509370c2b8eef4c31bd149dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86785 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit cf226535f9903a048b1c105b180ae3a50a776e68) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86797 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-01-13tdf#128207: DOCX import: fix chart positioningBakos Attila
Embedded graphic objects had got 0 values for vertical and horizontal positioning before, resulting overlapping, hidden charts, but now they are positioned according to the values in the document. Change-Id: Ia5403ac65ff7192d61072e8a9d8a7f80c7178b9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86521 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit d9c535ead688e9f156dbcf43948df08a69e218be) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86536 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-01-09tdf#129353, tdf#129402: fix node creation on index importMike Kaganski
ToC, bibliography, and index sections import code changed to closely follow what Word does, make sure that pre-rendered entries don't get imported as standalone paragraphs outside of the index sections, and paragraph count is accurate (no missing or added paragraphs as much as possible). In Word, an index may start and end in the middle of a paragraph: <w:p> <w:r> <w:t>Some text before index</w:t> </w:r> <w:r> <w:fldChar w:fldCharType="begin"/> </w:r> <w:r> <w:instrText> TOC ...</w:instrText> </w:r> <w:r> <w:fldChar w:fldCharType="separate"/> </w:r> <w:r> <w:t>First pre-rendered index entry</w:t> </w:r> </w:p> ... <w:p> <w:r> <w:t>Last pre-rendered index entry</w:t> </w:r> <w:r> <w:fldChar w:fldCharType="end"/> </w:r> <w:r> <w:t>Some text after index</w:t> </w:r> </w:p> However, normally it looks like either no runs precedig index, or no runs of pre-rendered contents will be present. When no Std elements are used, the typical situation is that there's a normal paragraph (possibly with some user text), which ends with index start marker, without any pre-rendered contents in the same paragraph; and all pre- rendered contents goes in following paragraphs. Such index normally ends with index end marker in the *first* run of a paragraph, which then might have normal text runs. When Stds are used, then no leading/trailing out-of-index runs in paragraphs with marks are usually present; and in this case, when paragraphs with index marks don't contain pre-rendered entries, they still are treated as part of the index. In Writer, indexes are node sections (and so cannot be inline with other paragraph contents). When there was some paragraph content already before the start-of-index mark, the paragraph is assumed to end before the index; in this case, when current <w:p> element ends, importer decides if a separate starting paragraph is needed or not, depending on if there was some runs after the mark. When there was no text runs before the starting mark, then the paragraph is treated as leading paragraph of the index. This allows to not miss empty paragraphs before index; and not have two paragraphs where there was one in Word. Only in cases when user had manually typed text both in and outside of the index in the same paragraph in Word, we would have the paragraph split into two in Writer. For end marks, the behaviour depends on whether it's inside Std. When inside, the ending paragraph starting with index end mark is considered part of the index. For out-of-Std case, it's considered normal paragraph (and measures are taken to make sure it's not dropped even if empty, because sometimes such paragraphs don't have other content, and have section settings, which is usually treated by Writer as "drop this paragraph" sign). A special problem is multi-column index. It's wrapped into a continuous section by Word; and in Writer, we also wrap it into a section. It would be possibly useful to detect somehow if this section is part of index definition, and in this case, drop the section and put its properties into the Writer's index section. That would avoid an explicit section in the imported document. This is TODO, for someone who figures how to detect reliably if the section belongs to index definition. See comment in DomainMapper_Impl::appendTextSectionAfter. By the way, current export code is wrong, producing an index that is single-column in Word; this change doesn't touch that. Several existing tests needed to be fixed, which used to test wrong results. Reviewed-on: https://gerrit.libreoffice.org/85089 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 5cdb14345842c07eb1a466897753da910e9488f8) Change-Id: I9597c8ab13f31ded9abcc24054d3478d3e3a3b40 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85289 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-01-08tdf#123262 writerfilter: completely ignore footnote separatorsJustin Luth
... except for processing enough to observe the separator exists. For each footnote reference, the entire footnote.xml file is parsed every time. The text in the "separator" footnote was being added to every footnote. The normal case where this is just a single paragraph was already handled, but this patch generalizes everything to handle cases of actual text or multiple paragraphs. Not every footnote has a type, so we can't depend on that to turn ignoringText ON/OFF. Every footnote has an ID, but theoretically the ID could be processed before or after the type, and it has no idea which type it is. Finally, the skipped text has no idea how many times/paragaphs it needs to skip. So a three-way control was needed to handle on/used/off. As a safeguard, finishing the footnote.xml parse (PopFootOrEndnote) ensures that ignoring won't be left on in the unlikely case that the separator is the last footnote. Change-Id: Ia30ca8d3a36417a4691e3b2e1c978720be017030 Reviewed-on: https://gerrit.libreoffice.org/82172 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit acb9d901009d026cb48e6a8b94e6200f05110504) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85734 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-01-08tdf#129450 DOCX import: fix bottom border of 1-row tablesSzabolcs Toth
Bottom border was missing in a 1-row table with disabled inside borders. This happened because LO applied the empty horizontal borders to the bottom border of the table. Change-Id: I40140bf63297189edad13088f98fc5f869969c2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85303 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 6b1bd2699b0bdad6dc42db741dea0717cf7c1d36) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86397 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-01-08tdf#129513: drop incorrect and redundant erasure of paragraph sprmMike Kaganski
It was introduced in commit 2499397cb39330dabeb8b7b3e0d7eb6213a0d8f4 "avoid sending duplicated paragraph flags", and supposedly was meant to avoid having duplicating sprms in the collected properties, when new properties were pushed back at that time. Using specific sprm id was likely a mistake (nParam should have been used instead). Now the new sprm is added using RTFSprms::set with eOverwrite having default value of RTFOverwrite::YES, which takes care to avoid dupes, so the call to erase is redundant. This reverts commit 2499397cb39330dabeb8b7b3e0d7eb6213a0d8f4. Change-Id: Ied19f6feb41bd17ef317812d4d295ca0542a5843 Reviewed-on: https://gerrit.libreoffice.org/85602 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 989043b0644354b92fd17e4194897c2eb0935031) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85742 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-01-08tdf#129442 DOCX import: fix right border of 1-column tablesSzabolcs Toth
Right border was missing in a 1-column table with disabled inside borders. This happened because LO applied the empty vertical borders to the right border of the table. Change-Id: Ib190689bf5059bfd7dbf07b07808cd761015f37e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85301 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 8a2eb40abbd52d960dd21308157186be0ca9dd3d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86261 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-01-06tdf#129475 DOCX: fix gridAfter with shape-only cellsLászló Németh
and in last row of tables, i.e. regressions caused by the following commit. This reverts commit b2c6d2d961a6113d0f111fab45ae12a40d389a23 (fdo#38414 tdf#44986: DOCX table import: handle gridBefore/After), except some unit testing. Change-Id: Icb2d65b7a0766cf8dd00511cde500af3f94d2a94 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86125 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86211 Tested-by: Jenkins
2020-01-03tdf#129205 DOCX import: handle the <w:shd w:val="nil" ...> paragraph propertyMiklos Vajna
Reading the spec, "nil" is the opposite of "clear": i.e. if the (background) color is red and the fill (color) is green, then "clear" means green. And you would expect "nil" means red, but it's just nothing in Word. Fix the problem by doing the same: don't set any paragraph property for the "nil" case and keep doing it for the common "clear" case. (cherry picked from commit fbe7612d654be9dfe1ea6f2e67900eb4eec4202a) Change-Id: I30af8a7fb55fb9bab2d12e120069a479fc7ab0a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86098 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2019-12-22DOCX table import: fix interaction of 1-cell rows and "inside" vertical bordersMiklos Vajna
The interesting part of the bugdoc was: - table style wants visible borders - table direct formatting clears left and right borders - 1st row of the table has 1 cell (2 cells in fact, but they are merged) Fix the "inside" vertical border handling, so that the first cell gets these vertical borders as a right border only in case there are multiple cells. (cherry picked from commit fd92740a86ab8e71e77d947d1d7dabc51a8d0794) Change-Id: Id847109ecfa95d1745abe62ddf36c4936b730855 Reviewed-on: https://gerrit.libreoffice.org/85574 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-12-21tdf#129247 writerfilter,sw: improve handling of CONTROL fieldsMichael Stahl
The "CONTROL Forms.CheckBox.1" field has a shape as its result. Previously this was imported as an unknown generic field by writerfilter and exported as a CONTROL field followed by a SHAPE field; the CONTROL field was discarded by Writer on a subsequent import. Now this is exported as nested fields to WW8, i.e., SHAPE inside the result of CONTROL, which is an improvement. Unfortunately the WW8 import discards the result of the CONTROL field, because its field code is written as ww::eUNKNOWN = 1, not ww::eCONTROL = 87. To fix that, set the ODF_ID_PARAM parameter in writerfilter for these fields, which is checked in MSWordExportBase::OutputTextNode(). This reveals that the field code was set wrongly on the fieldmark too, it should be set as a ODF_CODE_PARAM parameter and not as the type. Furthermore the WW8 import needs to allow nested fields in the eCONTROL field. Change-Id: If79a186ea30c3b4a933ba1d8325111215250b833 Reviewed-on: https://gerrit.libreoffice.org/85418 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 27b6c82b79f4af2ab16d53de3b2065df0acebdb8) Reviewed-on: https://gerrit.libreoffice.org/85527 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-12-20tdf#87569 tdf#109411 DOCX import: fix shape anchor in tablesBakos Attila
Import "relative from page" horizontal setting of VML and DrawingML shapes as "relative from column" in tables, just as MSO handles it. Change-Id: If71f2e52bbba324a98651e701feaeb99acfefc48 Reviewed-on: https://gerrit.libreoffice.org/85141 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> Reviewed-on: https://gerrit.libreoffice.org/85572
2019-12-17tdf#112201 writerfilter: try to apply continuous section page style...Michael Stahl
... on the last node of the previous section. This works for this particular document, but it's quite dubious that it will work in the general case; feel free to revert this if it causes problems. Change-Id: Ia03d41a1127df505c4e9da7131323b70d88a285f Reviewed-on: https://gerrit.libreoffice.org/85294 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 3f680aef65a158cfbc98c8afd1c3628d7f4f7b83) Reviewed-on: https://gerrit.libreoffice.org/85304
2019-12-17tdf#112201 writerfilter: continuous sections:Michael Stahl
always replace break with follow-page-style, not first-page-style. It looks like Word ignores <w:titlePg> on continuous section breaks, unless it's the first section, which was already handled by code above. Change-Id: If7c0fe96a1789f64f1943ece453db3dbc284ca48 Reviewed-on: https://gerrit.libreoffice.org/85293 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit d7e9daf2d21d3bcafaa6aae4aed6c9df5e0999c4) Reviewed-on: https://gerrit.libreoffice.org/85300
2019-12-17tdf#112202 writerfilter,sw: fix loss of headersMichael Stahl
There are several problems here: * CloseSectionGroup() is not only called for actual sections in the document but also at the end of every special text like comment, footnote, etc; only actual sections can set page styles. Writer comments use editengine so cannot even contain sections. * With continous section breaks, headers and footers are inherited from the previous section unless defined by the current section; SwXText::copyText() did not copy the content of the header on page 4 to page 5 correctly because it used an SwXTextCursor to create the selection, which cannot select the table at the start of the header. * For continuous section breaks, WW8 import filter has a heuristic to find the first page break in the section and set the PageDescName property on that node to apply the page style with the headers of the new section; do something similar in writerfilter SectionPropertyMap::CloseSectionGroup() Change-Id: I3ebe3d299f83197cbf8f10de46c34de98677626c Reviewed-on: https://gerrit.libreoffice.org/85213 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 08f13ab85b5c65b5dc8adfa15918fb3e426fcc3c) Reviewed-on: https://gerrit.libreoffice.org/85268
2019-12-17tdf#129242 Regression fixed for one cell table bordersSzabolcs Toth
Had to check an additional criteria before removing inside borders. Change-Id: I0828d973bd331e65ebabc1fe2e2f25f1bcaf58b0 Reviewed-on: https://gerrit.libreoffice.org/84676 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit dff3ae42d94fdf97c856c4a4d1e66234604927f4) Reviewed-on: https://gerrit.libreoffice.org/85199 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-12-16Related: tdf#115719 DOCX import: fix increased spacing vs left-aligned objectsMiklos Vajna
Commit 8b73bafbc18acb4dd8911d2f2de8158d98eb6144 (tdf#115719 DOCX import: increase paragraph spacing for anchored objects, 2018-02-14) added an import-time tweak for a problem that has been confirmed to be a Word layout bug in the meantime (and the tweak makes Writer behave the same way if the document has been created by an affected Word version for layout compatiblity). Later, commit 4883da6fd25e4645a3b30cb58212a2f666dae75a (Related: tdf#124600 DOCX import: ignore left wrap on left-aligned shapes, 2018-02-14) fixed left spacing of anchored objects aligned to the left, to be in sync with what the DOC import does. This broke the previous fix in case the shapes are left-aligned. Fix the problem by tracking what is the in-file-format and logical left margin, so the final doc model has the value necessary for correct horizontal positioning and the importer has the value that's necessary for correct vertical positioning. (cherry picked from commit 814cb2433da6bd608e935fa5531d2a2b92867985) Change-Id: I8f16cbe7bad40e243111c902bdc1ab0e8141d6b9 Reviewed-on: https://gerrit.libreoffice.org/85207 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-12-09fdo#38414 tdf#44986: DOCX table import: handle gridBefore/AfterLászló Németh
without serious regressions, ie. losing the import of complex forms with multiple or nested tables. Complete the fix for tdf#116194 (DOCX import: fix missing tables with w:gridBefore) with handling gridAfter on DomainMapper level. This consists of also rejections (except their unit tests) of commit cf33af732ed0d3d553bb74636e3b14c55d44c153 (handle w:gridBefore by faking cells (fdo#38414)) and commit 1d1748d143ab4270a2ca1b5117852b1b1bb4c526 (Related: tdf#44986 DOCX import: handle w:gridAfter by faking cells) Change-Id: I31fa1de03bcdf42424fa5507fb5a3e06aa47107d Reviewed-on: https://gerrit.libreoffice.org/84517 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit b2c6d2d961a6113d0f111fab45ae12a40d389a23) Reviewed-on: https://gerrit.libreoffice.org/84724
2019-12-08tdf#116194 DOCX import: fix missing tables with w:gridBeforeLászló Németh
Regression from the commit cf33af732ed0d3d553bb74636e3b14c55d44c153 "handle w:gridBefore by faking cells (fdo#38414)" This patch replaces the previous fix with a better solution, fixing tdf#38414 on the proposed DomainMapper level. (Note: to reject the old fix completely, its follow-up commit w:gridAfter will be handled in a similar way.) Now the related regressions, tdf#111679, tdf#120512 and the complex forms of tdf#116194, tdf120256 and tdf#122608 are fixed, too. Change-Id: Id25f5fb4d9021c87ee8c82782b2038e6fb255673 Reviewed-on: https://gerrit.libreoffice.org/84263 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit da1f71edfc72928b07a569b98e2766a8a7de9d2a) Reviewed-on: https://gerrit.libreoffice.org/84711 Tested-by: Jenkins
2019-12-07tdf#121658 Add option to not hyphenate words in CAPSSamuel Mehrbrodt
* Add checkbox to pagraph dialog * Store property in paragraph model * Move docx import/export from grabbag to paragraph model * Add ODF import/export * Add ODF unit test * Add layout test Change-Id: Id4e7c5a0ad145c042f862995d227c31ae2aa0abd Reviewed-on: https://gerrit.libreoffice.org/83979 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 72bd0df107ee47c4d54fa88b4960d32ea03e9f69) Reviewed-on: https://gerrit.libreoffice.org/84620
2019-12-06tdf#120546 fix DOCX overriding numrule formatJan-Marek Glogowski
... at least in the view. This "fixes" the import side of the exported OOXML document with multiple overridden numrule character format. This prevents the change of the shared numrule, which results in all bullets being formatted like the last overridden numrule. What is missing is a consistent way to edit the override, as the override is currently just stored in an internal attribute, the "ListAutoFormat" property. Fixing editing for good will be a larger work, as "ListAutoFormat" must be reflected in the GUI and must have a higher priority then the numrule format. Currently positioning the curser in front of the number or bullet entry lets one change the numrule format, which is applied to all bullets of the same rule. This special DOCX override mode is enabled by the import filter setting DocumentSettingId::APPLY_PARAGRAPH_MARK_FORMAT_TO_NUMBERING to true. This should also change the edit mode, so that a change of the entry doesn't modify the rule, but the override and this must also be reflected in the GUI character settings. Change-Id: I057f7a354bc3c413b114eec772e06c7063029699 Reviewed-on: https://gerrit.libreoffice.org/81878 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit 6ed12ab2d0742f86ce25defec3c776562dbfad9a) Reviewed-on: https://gerrit.libreoffice.org/84624 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-12-05tdf#128428 RTF: switch off longer space at \dntblnsbdbLászló Németh
The Word 6.0 (Japanese) compatibility option \dntblnsbdb switches off the balancing of SBCS/DBCS characters, including the longer space sequences. Note: using \dntblnsbdb, it will be possible to set normal (short) space sequences in RTF export, too, to avoid broken document layout during RTF round-trip. Fix regression from commit 24b04db5a63b57a74e58a7616091437ad68548ac (tdf#123703 RTF import: fix length of space character sequence). Change-Id: I5ade9e0a2db0bde204d1debe831058045fd8f586 Reviewed-on: https://gerrit.libreoffice.org/84397 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit cd7241e3d2892c2a115265f842f464d017d7c7e1) Reviewed-on: https://gerrit.libreoffice.org/84414 Tested-by: Jenkins
2019-12-02Related: tdf#128611 RTF import: handle vertical flip of line shapesMiklos Vajna
UI uses SdrEditView::MirrorMarkedObjVertical() to flip a line shape vertically, handle it similarly at import time as well. Also note that this flips in-place, while the naive '*= -1' for the height would have an incorrect vertical position. (cherry picked from commit f9f421b7beaf117968c0dbfd84a2dad3dc85136a) Change-Id: I42b7feb5f799b99337ddec734dcf98dd1d553755 Reviewed-on: https://gerrit.libreoffice.org/84209 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-27crashtesting: failure on import of tdf113230-1.docxCaolán McNamara
which is a favorite input document for crashes and assert apparently, this is the third time it has triggered a different problem this one is new since... commit 9fdf8c0a5cc036ea9bd1e11dd8f2c1a6e601fae2 Author: Mike Kaganski <mike.kaganski@collabora.com> Date: Sat Nov 16 16:34:25 2019 +0300 Also consider saved exceptions when terminating parse Change-Id: I394b650613e8a835fe8a9f216a48864bdbc5065b Reviewed-on: https://gerrit.libreoffice.org/83925 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-27tdf#76586 fix table width of auto-width nested tablesLászló Németh
when they have (sometimes incorrect) fixed cell widths. Change-Id: I98bf37bfce72b84eed14e354520e4741ae2ddada Reviewed-on: https://gerrit.libreoffice.org/83787 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 001e11c8f4a52a2eb308562bdee8516efb77b96b) Reviewed-on: https://gerrit.libreoffice.org/83851 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-11-22crashtesting: failure on import of tdf10306-1.docxCaolán McNamara
downgrade to warning instead of assert as per https://lists.freedesktop.org/archives/libreoffice/2019-November/083836.html Change-Id: If561930ca9733899cf0f4e3a6d8bb6609c94fc1d Reviewed-on: https://gerrit.libreoffice.org/83486 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-11-22tdf#121658 Roundtrip w:doNotHyphenateCaps via InteropGrabBagSamuel Mehrbrodt
Change-Id: I8a7efffb2866e46e978d09ca9fb5c9dec231e132 Reviewed-on: https://gerrit.libreoffice.org/83384 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit 3185ce226447fb04c530af76f799fed86672f99c) Reviewed-on: https://gerrit.libreoffice.org/83397 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-11-21tdf#119054 DOCX: fix not table style based bottom marginLászló Németh
in table cells, ie. using paragraph styles with bottom margin setting or direct paragraph formatting of bottom margin. Both of them overwrite the table style based bottom margin. Change-Id: I527b16c24fe47df8412291089ff86fadd3f9430b Reviewed-on: https://gerrit.libreoffice.org/82800 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 6100909c84550036932d031f4d2f652e158a1a0a) Reviewed-on: https://gerrit.libreoffice.org/83154 Tested-by: Jenkins
2019-11-20tdf#124399 DOCX import: don't apply inside borders to 1-cell tablesSzabolcs Toth
Extra cell borders appeared on the bottom, top, left or right of the 1-cell tables when only the "inside borders" option was selected. The extra borders were the ones that would normally have appeared as inside borders if there were more than one cells in the table. Change-Id: I05d5f2a5a0168989f220d20a95b6dacf5152f9f7 Reviewed-on: https://gerrit.libreoffice.org/82675 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 8a59f18b6eb22c43ec10cdc29ba5a13d5feba4f0) Reviewed-on: https://gerrit.libreoffice.org/83303 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-11-20tdf#128820: use wps namespace for simple text shapesMike Kaganski
Without that, simple text shapes inside groups were written in <pic:wsp> elements, with many child elements also having pic:: prefix. Change-Id: I114cf3499e03aa5ca042211d7b134aaf5b0e7fbf Reviewed-on: https://gerrit.libreoffice.org/82980 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Also consider saved exceptions when terminating parse As with previous commit 18ae77a065cb8ae6940d4067f6ab7e99a3f74047, this will start showing parse errors on invalid files which previously just opened without warnings, silently losing the invalid stream part. Any bug bisected to this commit is not a regression from this commit! The real problem was already before, and was just disclosed by this (which is the actual goal). Also simplify unit test data for tdf#128820, which will now be enough after the change. A unit test (testN779627) revealed unexpected throws when parsing; this was fixed. Change-Id: I5a21b9001874ec6e3b8273c10043ef930bf1cc82 Reviewed-on: https://gerrit.libreoffice.org/82981 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> tdf#128820: improve unit test to not depend on opening bad file failing ... also test exported XML directly Change-Id: I50237593dd111e7c7974452769c8d49c22012713 Reviewed-on: https://gerrit.libreoffice.org/83005 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Fix UBSan build after 9fdf8c0a5cc036ea9bd1e11dd8f2c1a6e601fae2 The said commit simplified a testdoc to testTdf128820, using a smallest possible SVG in it. This seems to produce the smallest possible PNG of size 8, which is passed into GraphicDescriptor::ImpDetectPNG. There its size is read into nTemp32 past the end of the file without checks, which keeps last value of the variable (which was the magic number 0x0d0a1a0a), which is then saved into the descriptor. Then that value is used in ImpGraphic::ImplGetSizePixel, and later multiplying it in lclConvertScreenPixelToHmm causes UB. Fix by checking all the reads in GraphicDescriptor::ImpDetectPNG. Change-Id: Ib4740fac2b87fbef57d5150151129b9852f3ecb8 Reviewed-on: https://gerrit.libreoffice.org/83119 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/83296
2019-11-19DOCX: clean-up paragraph bottom handling of table styleLászló Németh
Revert of commit 17e904ed66c3caf87e658b9d3a18d7b13f4a0b52 ("bnc#816593 DOCX filter: import paragraph spacing from table style), keeping only the working unit test. Change-Id: I735744aadb071ef2f0d939cb637d83cfc5716fe4 Reviewed-on: https://gerrit.libreoffice.org/82776 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 00eeb7b3f765a51f51f7911a116982fbfb83efb7) Reviewed-on: https://gerrit.libreoffice.org/83098
2019-11-18tdf#128752 DOCX: fix partial direct paragraph spacing in tablesLászló Németh
When direct formatting of a table paragraph set only top margin, but not the bottom margin, also there was no paragraph style setting for the bottom margin, the paragraph was imported using docDefault bottom spacing instead of the table style bottom spacing. Change-Id: Ib7f5f80dd2485a0fd4ab8e0645b7d730a7ec3c5c Reviewed-on: https://gerrit.libreoffice.org/82771 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit d8f3f8ecd9e6304f3a98ab03fae6bc545893f782) Reviewed-on: https://gerrit.libreoffice.org/82789
2019-11-13tdf#95374 DOCX import: reset left indentation at disabled numberingLászló Németh
Paragraphs with disabled numbering using non-existent numId=0 haven't got inherited left indentation in MSO. Keeping them resulted unnecessary indentation, moreover, missing (non-visible) text in narrow table cells. Change-Id: I46003031d36f578b0b260dea74d7d45e75905261 Reviewed-on: https://gerrit.libreoffice.org/82509 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-13tdf#127925 DOCX export: fix visited hyperlink styleTünde Tóth
Custom visited hyperlink style reset to default in Word. Change-Id: I6a36c900788bb17d4f31c60048cf65960490a46b Reviewed-on: https://gerrit.libreoffice.org/80043 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-11-12use std::move when popping stuff off stacksNoel Grandin
Change-Id: I6ba0ee8afee1a9579045643cd0118cf19599d5b9 Reviewed-on: https://gerrit.libreoffice.org/82497 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-11tdf#128428 RTF: fix for different product versionsLászló Németh
at switching off longer space sequence mode. Change-Id: I87c265ad0ff5f7b44c92b1abebeb31f68749a1e7 Reviewed-on: https://gerrit.libreoffice.org/82434 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-11tdf#128428 RTF: clean-up for longer space sequence modeLászló Németh
Fix regressions from commit 24b04db5a63b57a74e58a7616091437ad68548ac (tdf#123703 RTF import: fix length of space character sequence). It seems, longer space sequence is an obsolete RTF-only feature, eg. new RTF documents created in MSO don't use it, but old RTF documents still keep their layout (only in RTF). - Only old-style (without \stshfdbch) or compatible (\stshfdbch31505) RTF documents get longer space sequences using a one-time conversion; - because Writer always exports old-style RTF documents, to avoid of enlargement of space sequences of new-style RTF documents later, RTF import doesn't modify the RTF documents saved in Writer (checking \generator); - text in monospaced font "Courier New" doesn't get longer space sequence (despite its \prq2 (not monospaced) font setting). Change-Id: I308ab06db57a2db5deec1d4c4573da3317cad8e9 Reviewed-on: https://gerrit.libreoffice.org/82145 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-11-11tdf#128460 import SwInputField from DOCX FILLINJan-Marek Glogowski
Actually the whole FILLIN handling is not that correct, because the value can actually be formatted in any way in Word, as it's just defined as a range of runs with formating, while Writer just applies the character formatitng to the whole field. But this at least allows for a round trip of the exported Writer type input field after commit 62aaaad156ef ("tdf#125103 Writer: input fields will be exported to docx") changed this. Change-Id: I6389b4a2ff9d2b62e1e4a00f1c1e112c199377b5 Regression-from: 62aaaad156ef0daccd2680161ef8b9b99d8a7bc0 Reviewed-on: https://gerrit.libreoffice.org/81686 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2019-11-11tdf#124986: docx: remove trailing quotation marks and spaces from set fieldsbrinzing
Change-Id: I6390344b72b0148cff8e0ed5150d7abfc9490a2a Reviewed-on: https://gerrit.libreoffice.org/81892 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-09tdf124367 DOCX import: fix rounding error in table cell widthsBakos Attila
Follow-up of commit 29cbbad64088354425c606f9eb6c267bdf7731dc (DOCX import: fix rounding error in table cell widths), its revert in commit e502463fa9a601963aa9f5a8783eb1318de36c13 (tdf#123104 DOCX import: fix lack of vertical merge due to rounding) and commit 44e44239de35c1548809c96e13bfa9d64c7ca441 (tdf#120315 DOCX import: fix cells merged vertically). Change-Id: Id85e8fd25dba26af77fe2fd3024db2ae834b5052 Reviewed-on: https://gerrit.libreoffice.org/82072 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> Tested-by: Jenkins
2019-11-08tdf#128504 save DOCX as ODT: don't color not highlighted hyperlinksTünde Tóth
During DOCX import, not highlighted hyperlinks, ie. without hyperlink character styles, set the Visited/Unvisited character style text attributes to "Default Style" to avoid saving them with the default highlighted hyperlink character styles in ODT. Regression from the commit 576611895e51186d38ddefa10ed8d66075d9de37 "tdf#127741 DOCX import: format hyperlink with Default character style". Change-Id: I5ffbb107e6704b285bc3d1546e08a324c386a0ab Reviewed-on: https://gerrit.libreoffice.org/82205 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org>
2019-11-07loplugin:unusedmethodsNoel Grandin
Change-Id: I65354c7476dfaede1a607441d7c1b0c7ad038df4 Reviewed-on: https://gerrit.libreoffice.org/82186 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-11-06crashtesting: null deref on import of lp482242-3.rtfCaolán McNamara
since... commit a991ad93dcd6807d0eacd11a50c2ae43a2cfb882 Date: Tue Oct 22 12:24:43 2019 +0200 tdf#121441 improve DOCX footnote import Change-Id: I0c6b83bd1ff61b9fa3621896d59f126384530270 Reviewed-on: https://gerrit.libreoffice.org/82045 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit (git 2.34.1) at 2024-06-18 12:05:33 +0000