summaryrefslogtreecommitdiff
path: root/writerfilter
AgeCommit message (Collapse)Author
2020-04-21tdf#132185: field command does not necessarily end with spaceMike Kaganski
Change-Id: I5a5e54fb42e20855b75af7ab523465a032ab46e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92504 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> (cherry picked from commit 8c8b3a4f83f67882b284ddc3b3fe10d3fe6dedf4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92526 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org> Tested-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-02-12related: tdf#106742 sw: DOCX import/export: fix default of table indentMichael Stahl
There's a compatibilityMode in word/settings.xml in DOCX files: https://docs.microsoft.com/en-us/openspecs/office_standards/ms-docx/90138c4d-eb18-4edc-aa6c-dfb799cb1d0d If a document doesn't contain compatibilityMode, then the default is 12, but the code for table indent import/export assumed that the default is 15, so loading an ODF document and exporting as DOCX results in wrong table indent when loaded in Word. (regression from 9a31d1c83e08600507689dc18f6f0973bc7e4389) Change-Id: I3ce32286473640e5b7e12b487aef5f123bfb8d12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88408 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit d978f5d40102a098f1faf1e98aa39ad122284299) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88393 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
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/+/87635 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
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. Change-Id: I9597c8ab13f31ded9abcc24054d3478d3e3a3b40 Reviewed-on: https://gerrit.libreoffice.org/85089 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/85278 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86464 Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-01-09tdf#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> (cherry picked from commit dfd75ec6d4dcfec57607a8cf7c7a509c33bf2caa) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86344 Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-01-09tdf#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. 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> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Change-Id: Ied19f6feb41bd17ef317812d4d295ca0542a5843 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86418 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-01-06DOCX 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/c/core/+/85577 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2019-12-19Related: 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) Conflicts: writerfilter/source/dmapper/PropertyMap.cxx Change-Id: I8f16cbe7bad40e243111c902bdc1ab0e8141d6b9 Reviewed-on: https://gerrit.libreoffice.org/85223 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-12-03Related: 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) Conflicts: sw/qa/extras/rtfimport/rtfimport.cxx Change-Id: I42b7feb5f799b99337ddec734dcf98dd1d553755 Reviewed-on: https://gerrit.libreoffice.org/84230 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-11-25tdf#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 (cherry picked from commit d54bae3471e9b9529f1ac03c811c3370d9f5ed89) Reviewed-on: https://gerrit.libreoffice.org/83337 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-11-19tdf#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: I95e919a137f1ba85ca85372d5bdb23d958ef33c0 Reviewed-on: https://gerrit.libreoffice.org/82650 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-11-19tdf#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> (cherry picked from commit 5e279f175289234b91f272bbbf48e70315fff5ac) Reviewed-on: https://gerrit.libreoffice.org/83039 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2019-11-15tdf#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> (cherry picked from commit fea5c10e222b10d83e0081dc1d1b2e678689d250) Reviewed-on: https://gerrit.libreoffice.org/82629
2019-11-13tdf#124367 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 Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/82421 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-08tdf#120315 DOCX import: fix cells merged verticallyBakos Attila
Due to rounding mistake cells weren't merged vertically, when their horizontal positions are different a little bit. Change-Id: I10623719a3759b35fcd04b154590b8ac6ec3ac45 Reviewed-on: https://gerrit.libreoffice.org/81604 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 44e44239de35c1548809c96e13bfa9d64c7ca441) Reviewed-on: https://gerrit.libreoffice.org/81992 Reviewed-by: Attila Bakos <bakos.attilakaroly@nisz.hu> Tested-by: Xisco Faulí <xiscofauli@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-07tdf#121661 Roundtrip w:hyphenationZone via InteropGrabBagSamuel Mehrbrodt
Change-Id: I097afb54ff31bd1c878231b51eac5af9f27d35e9 Reviewed-on: https://gerrit.libreoffice.org/81880 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/82200
2019-11-05tdf#125038 DOCX import: fix various issues with MERGEFIELD inside IF fieldsMiklos Vajna
This is a combination of 4 commits. This is the 1st commit: Related: tdf#125038 DOCX import: fix unexpected MERGEFIELD result inside IF The problem is that DOCX supports nesting MERGEFIELD fields inside IF fields, while SwHiddenTextField only supports a single string as a condition. This means in case there are MERGEFIELD fields inside the IF field, those fields will be inserted to the doc model before the IF field, exposing their value, while Word only uses their value during the evaluation of the IF expression. Fix the problem by inspecting the parent field command before setting the MERGEFIELD result. (cherry picked from commit 7b0534cb70e96028c8525285c42a71415704cede) Conflicts: writerfilter/source/dmapper/DomainMapper_Impl.hxx This is commit #2: Related: tdf#125038 DOCX import: fix unexpected linebreak inside IF condition Writer body text is expected to only contain the result of the field. So in case both the field command and the field result contains a linebreak, we need to make sure that linebreaks are ignored in the field command for field types where the Writer field implementation expects a single string. With this, the number of paragraphs in the bugdoc is now correct. (cherry picked from commit 97f9af714ea1c46e498fa99f7ca34fc1708d38a6) This is commit #3: tdf#125038 DOCX import: fix lost MERGEFIELD result inside an IF field The problem here was that the IF field result didn't have a plain text string, rather it had a MERGEFIELD in it. Writer's conditional text field expects a plain text string, so just use the result of the MERGEFIELD for an IF parent. Do this in a generic way, it's likely that other parent-child field combinations want to do the same in the future. With this, all lost strings are fixed from the original bugdoc + all unexpected content is hidden in Writer as well. (cherry picked from commit d09336fbdceaafd9320466b660a2b32a07dcc16a) This is commit #4: tdf#125038 DOCX import: better support for linebreaks in IF fields IF fields can't contain linebreaks, so instead of just calling finishParagraph() and hoping it does something sane, explicitly handle them: remember the properties and perform the call only once the field is closed. (cherry picked from commit d40c2be38aaf56116f4dc7be9e78f4e9695407fc) Change-Id: I676aa2c83f12cb600829177a0eb25558822b1d94 Reviewed-on: https://gerrit.libreoffice.org/81982 Tested-by: Jenkins Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2019-11-04writerfilter: rtftok: filter control charactersMichael Stahl
... in RTFDocumentImpl::checkUnicode(); see ooo86460-1.xls [sic] for an example. There is another caller of text() in rtfdispatchdestination.cxx:311 but it turns out that buffered text was created by text() in the first place. This shouldn't be a problem for DOCX because XML 1.0 doesn't allow the bad control characters anyway so the sax parser should report an error in that case. (cherry picked from commit a6516c76c01b92f7d35bfb352b63af7de42b5707) Change-Id: Ice45e1c3c8c7db668a4cfb8364e42addea1777ce Reviewed-on: https://gerrit.libreoffice.org/81780 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-11-01Resolves: rhbz#1766990 starmath might not be availableCaolán McNamara
Change-Id: If2e02d8da85a2af576d9563c455487ac3463c935 Reviewed-on: https://gerrit.libreoffice.org/81838 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-10-22tdf#127741 DOCX import: format hyperlink with Default character styleTünde Tóth
according to correct hyperlink handling, avoiding various editing and layout problems; "sticky" and not easily removable character style around the hyperlink and multiple blue hyperlink colors. Set also Visited/Unvisited link character styles when the style of the hyperlink is not the requested "Internet Link". Change-Id: I3d7ba8dd225c693cc9f521b37767cf1e1e09d7c0 Reviewed-on: https://gerrit.libreoffice.org/80449 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> Reviewed-on: https://gerrit.libreoffice.org/80907 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-10-21writerfilter: sync layout-in-cell vs wrap-though behavior with ww8 importMiklos Vajna
I removed the same check in the WW8 import in commit d630f69d90f15bc652a62648b05ea515de78d16a (Related: tdf#124601 DOC import: improve fLayoutInCell handling, 2019-09-26). There is no reason the DOCX import shouldn't do the same, just for consistency. Change-Id: I9e56a3fcd0b13ba08e347fbc06b0960ac21b372c Reviewed-on: https://gerrit.libreoffice.org/80856 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit e042a83843ed2573dbce9338058b3dc545dd6898) Reviewed-on: https://gerrit.libreoffice.org/81242 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-10-17tdf#108350 writerfilter: restore TimesNewRoman as default fontJustin Luth
Followup for LO 5.4 commit 6f2ad89b33d972f9642bb53eeb91f41df3b6b0e6 which set Calibri/11pt as default. That is true if there is no style.xml file, or more specifically if there is no DocDefaults rPrDefault node. But if that node exists, then the age-old defaults are still valid. Earlier in LO 4.3, the default templates changed to use Liberation fonts by default. But in the same vein as using Calibri (and depending on LO to fallback to Carlito), set Word's default Times New Roman font and depend on LO to fallback to Liberation. That will make it better for MSWord users who share the document and who have less likelihood of knowing about Liberation/Carlito. Note that 10pt fontsize was already added to m_pDefaultCharProps earlier, so that part was already reset long ago. Change-Id: I3ba8a529fe95b05fbe2889cf1ebdbabb25963e8b Reviewed-on: https://gerrit.libreoffice.org/80854 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-on: https://gerrit.libreoffice.org/80927 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-10-15tdf#127814 DOCX: fix default paragraph margin in table cellsLászló Németh
when the table is started on a new page. Undefined w:before in w:docDefaults/w:pPrDefault resulted 0.5 cm paragraph top margin instead of 0 cm. Change-Id: I94a2aa9e9c5fcee6443b74bb261c300c6a8e1303 Reviewed-on: https://gerrit.libreoffice.org/80445 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 88ddeed17d5a7caca407f892a094a3dcb0aff501) Reviewed-on: https://gerrit.libreoffice.org/80599 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-10-15tdf#79007: PPTX: reset Contrast and Brightness when we map...Xisco Fauli
...MSO 'washout' to our watermark colormode After d151ed35ad4c4e7aa9fbb807930fcf91dea2eba7, Contrast and Brightness was reset only in writer, so do it earlier for Impress and Writer Reviewed-on: https://gerrit.libreoffice.org/79905 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org> (cherry picked from commit 727ca36e83868acbe40aaa239cefc69659b9bc39) Change-Id: Icaf2b565880e31d86e09e2f56bac25eba52c8467 Reviewed-on: https://gerrit.libreoffice.org/80003 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-10-09tdf#127825 DOCX import: fix handling for tbrl, auto-height and rel size shapesMiklos Vajna
Regression from commit ff17478e069cc82681df62514876c06365dd5cd6 (sw btlr writing mode: implement DOCX shape import for tbrl, 2019-04-25), there were two problems here: 1) Relative size currently only works properly for the lrtb direction, so disable that during import till sw core is improved. 2) When SwFlyFrame::Format() auto-grows a text frame which is the textbox of a shape, it needs to notify the shape about the physical size of the frame, not the logical one. So going via the SwRectFnSet abstraction is not correct in this case. (cherry picked from commit 9c81d0a268cca4ff36eff94c0842361b9c0287ef) Conflicts: sw/qa/extras/ooxmlimport/ooxmlimport2.cxx Change-Id: Ie185c7415d90594434eac8f459630d6a3212328a Reviewed-on: https://gerrit.libreoffice.org/80427 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-10-07related tdf#99602 writerfilter: deferredCharProps unhandled in StylesJustin Luth
...so don't add deferred properties during style import. Otherwise, the first paragraph picks up those attributes and applies them. Regression from 2012 - only affects subscript/superscript. Truly fixing this for Character Styles will be tricky, because it depends on the final fontsize - regardless of where it is set. So at the style level, the deferred property needs to be percentized based on SOMETHING, and then at appendText time the fontsize needs to be determined. If escapement is inherited from a style, then the escapement needs to be converted BACK into pointsize (based on style charsize), and then the final percentage can be calculated and directly applied. Yuck. I'm inclined to treat charstyle escapement like pre-2012, which just assigned default values and ignored the actual/given amount. Change-Id: I8e3783533ec18740e1c7d0b36c58b6c7e8ce107f Reviewed-on: https://gerrit.libreoffice.org/80178 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 8eb0d8daa526d1c53363954d4d8730cad55f1910) Reviewed-on: https://gerrit.libreoffice.org/80202 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-09-30Related: tdf#124600 DOCX import: ignore left wrap on left-aligned shapesMiklos Vajna
The DOC import does the same in SwWW8ImplReader::AdjustLRWrapForWordMargins(). This fixes one sub-problem of the bugdoc, so now the shape anchored in the header has a correct position. This made it necessary to re-visit the tdf#115719 testcases, which are minimal reproducers. The original document had from-left alignment (instead of align-to-left), but this did not matter before. Bring the test documents closer to the original large document, so the tests still pass and don't depend on LO mis-handling the above mentioned left-aligned situation. (The interesting property of tdf115719.docx, where Word 2010 and Word 2013 handles the document differently is preserved after this change.) (cherry picked from commit 4883da6fd25e4645a3b30cb58212a2f666dae75a) Change-Id: I973c13df47b0867e2c4756f0c448495257b7c9d5 Reviewed-on: https://gerrit.libreoffice.org/79834 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-09-25Revert "tdf#117988 writerfilter: IgnoreTabsAndBlanksForLineCalculation"Justin Luth
This reverts LO 6.2 commit 49ddaad2f3ba4e17e1e41e94824fb94468d2b680. tdf#127617 proves it simply was not the correct solution. I replaced the unit test document with one that clearly demonstrates that spaces/tabs should NOT be used in line height calculations. Example document tested with Office 2003, 2010, 2016. Change-Id: I2833384a017526d665adef0cae968bc4aef0dd94 Reviewed-on: https://gerrit.libreoffice.org/79473 Reviewed-by: Justin Luth <justin_luth@sil.org> Tested-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 202bee1a819de7b1e8c75dd863c4154f66419400) Reviewed-on: https://gerrit.libreoffice.org/79484 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-09-24tdf#104167 DOCX import: don't map Heading1 to Heading 1 para styleMiklos Vajna
This is nominally a regression from commit c12a78e42e1cbaaf4ea021c82acbec5ea177b1f6 (writerfilter: reset properties of reused styles, 2014-06-04), which assumed that style names are unique. They are not unique for the bugdoc, as it has paragraph styles named 'heading 1' and 'Heading1', both mapped to 'Heading 1'. The mapping for the style name without a space was added in commit 1d2af74e226bf44e1a0f1e1981ca965cffeaa0b2 (INTEGRATION: CWS xmlfilter02 (1.27.12); FILE MERGED, 2008-01-10), in the "2007/11/22 14:53:43 os 1.27.12.9: Tab stops almost perfect now" part, sadly without any indication on why that would be a good idea. The binary DOC import never mapped Heading1 to Heading 1, so it doesn't have this problem. Fix the problem by removing this mapping, it leads to formatting loss when a document has both HeadingN and Heading N styles. (cherry picked from commit a283627036c9b1c56e4b765866b8fb8a26ec87ab) Conflicts: sw/qa/extras/ooxmlimport/ooxmlimport2.cxx Change-Id: I26dd999f5a536e079ac351ba5d40d20c83b99310 Reviewed-on: https://gerrit.libreoffice.org/79429 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org> Tested-by: Xisco Faulí <xiscofauli@libreoffice.org> Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-09-18tdf#121663 DOCX import: fix missing space in line numberingLászló Németh
Auto distance of line numbering is 0.5 cm, not zero. Change-Id: Ic451424bffb3eb3fe386bcaef5a476a5679faff2 Reviewed-on: https://gerrit.libreoffice.org/75317 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit d828429f81e63d3c6beb4574fe3c52b001ea0a5b) Reviewed-on: https://gerrit.libreoffice.org/79053 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-09-05tdf#119809: FILESAVE DOCX The combo box ActiveX control is lostTamás Zolnai
The problem was with the empty combobox. The implemenation before this commit imported a combobox only when the combobox had any item. Reviewed-on: https://gerrit.libreoffice.org/78024 Tested-by: Jenkins Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit 3ceefe9abff98fc24ffb5e8e405f4999faddc351) Change-Id: I945098277d1ed34c65b43f0f6ad8eb361cf41b53 Reviewed-on: https://gerrit.libreoffice.org/78262 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-08-28tdf#103345 Import decimalEnclosedCircle correctlySamuel Mehrbrodt
Change-Id: I227d149d07ea0f7b2569e5df5a5589834374fac9 Reviewed-on: https://gerrit.libreoffice.org/77992 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> (cherry picked from commit 66576edf4e7ed26f09788fac348ea6b556ae1c47) Reviewed-on: https://gerrit.libreoffice.org/77999 Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-08-12tdf#126723 writerfilter::finishParagraph - me, not previousJustin Luth
In LO 6.2 commit 480ac84f2f5049fb4337b36f12fd6796e005761b the existing m_xPreviousParagraph was conveniently used to apply the changed properties. I never did like that choice, but despite looking at it, I failed to see that it is set in an inside loop, which means that it was NOT NECESSARILY reset to the current paragaph. So I'm happy to have proof that we should not use m_xPreviousParagraph. Change-Id: I5c7f1b0f097711d65ae0d0be1f0fbc40c8b96e9d Reviewed-on: https://gerrit.libreoffice.org/77185 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit d03c92b93d6ba1808a6641b4aa8cb4aae38058bf) Reviewed-on: https://gerrit.libreoffice.org/77218 Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
2019-08-12tdf#126590 DOCX import: fix absolute hyperlinks to documentsTünde Tóth
Absolute links in DOCX documents created with Word didn't work. Change-Id: Ie23c9ded1c88752768b925ec26df3061beeddd8e Reviewed-on: https://gerrit.libreoffice.org/76581 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/77191
2019-08-06tdf#123702 RTF/DOCX default 1" left/right page marginsLászló Németh
since MSO 2007: now 1440 twips = 2540 1/100 mm (it was 1800 twips = 3175 1/100 mm). Changing the default value fixes the layout of the documents based on RTF templates without explicit margins. Change-Id: I0395fb7cdd6ba176f266c8f0a9309ba48a047da3 Reviewed-on: https://gerrit.libreoffice.org/76812 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 2550b380e8f81528aa2dde5790c3b607c068ee1a) Reviewed-on: https://gerrit.libreoffice.org/76999 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2019-08-06tdf#126309 RTF import: fix not needed para adjust swap for bidi textMiklos Vajna
Regression from commit 4ee2a882dddb395a816cd54004b634d57cfb2446 (tdf#86182 RTF import: fix handling of \rtlpar, 2015-04-17), now that we don't ignore \rtlpar, it turned out that dmapper should not do paragraph alignment left/right swapping for RTF. It seems this is needed for DOCX, but not for legacy DOC/RTF. See how SwWW8ImplReader::Read_Justify() doesn't do this, either, so this is one of those rare cases when dmapper has to know if the token stream is generated by the DOCX or the RTF tokenizers. (cherry picked from commit 600025475630c59c53a9086ba6d95124416725b3) Conflicts: sw/qa/extras/rtfexport/rtfexport4.cxx Change-Id: Ibd52e3dc9e782e1d985418085b82b2e2628bc1dd Reviewed-on: https://gerrit.libreoffice.org/77004 Tested-by: Xisco Faulí <xiscofauli@libreoffice.org> Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-08-02tdf#126544 writerfilter: check parent style exists before assigningJustin Luth
If you set the parent style to a style that is not yet created, then it silently fails, and thus inherits from nothing! Change-Id: Ibb85235643dd5b1eb9b0bd43f701580f24b2b7fa Reviewed-on: https://gerrit.libreoffice.org/76805 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit b47a8f091ad8f9048a6b7962e9cde5d04ea0d665) Reviewed-on: https://gerrit.libreoffice.org/76824 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-07-09tdf#126173 RTF import: fix lost SHAPE fieldsMiklos Vajna
Commit 5a5d55a8a0f82406a8001015a723596f21d3562c (fdo#82860 RTF import: fix handling of SHAPE fields, 2014-10-15) already tried to handle this, but aCode is the shape command + its parameters (SHAPE \* MERGEFORMAT) for the bugdoc, while what we want is just the shape command. The field variable already contains a tokenized version, which was used previously only to decide if a field is unhandled or not. Reuse that for the shape comparison, so bugdoc's shape with parameters also appears. Change-Id: I7e044b94bcfab490c956b33c11dd6c69443939f5 Reviewed-on: https://gerrit.libreoffice.org/75243 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 9a15a75dfa7ab8c5d51c411e0e39d68d22b7587a) Reviewed-on: https://gerrit.libreoffice.org/75288 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-06-27tdf#126114 - Form fields are displayed twice (double)Tamás Zolnai
We need to make sure that IsFieldResultAsString() returns true for drop-down field, to ignore the placeholder string. Change-Id: I127800bdff78eb68e000fdbfe433bc88181ac2c3 Reviewed-on: https://gerrit.libreoffice.org/74752 Tested-by: Jenkins Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> (cherry picked from commit 8e5982d799e23bee86404f3ccb3aaed524ae9675) Reviewed-on: https://gerrit.libreoffice.org/74796
2019-06-18tdf#89991 DOCX: import Show changes from older formatsLászló Németh
w:formatting is optional, w:markup can be instead of w:insDel, too. Change-Id: Ic689499a880dcc7c97497e4381dff31610f745bf Reviewed-on: https://gerrit.libreoffice.org/73943 Reviewed-by: Justin Luth <justin_luth@sil.org> Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 8b3c861c46ae12d21b7b3a550e2daa21d2006b77) Reviewed-on: https://gerrit.libreoffice.org/74274 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-06-18tdf#89991 DOCX: import/export Show changes modeLászló Németh
handled by the optional w:revisionView OOXML setting. Using disabled Show Changes mode, exported DOCX contains <w:revisionView w:insDel="0" w:formatting="0"/> as the documents exported from MSO with disabled Show Changes and disabled Options -> Trust Center -> Trust Center Settings -> Privacy Options -> Make hidden markup visible when opening or saving (Note: this last setting needs also for opening the documents really with disabled Show Changes in MSO). Change-Id: I9f2c7df572f33838ae63185de21431102a7e139e Reviewed-on: https://gerrit.libreoffice.org/73885 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 0e27158c4f6a6a7676a77afb6b37dd30b3f6d100) Reviewed-on: https://gerrit.libreoffice.org/74254 Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2019-06-18tdf#125719 sw: rtf: refactor associated character propertiesSerge Krot
1. \rtlch, \ltrch should be placed before their properties. 2. Do not mix associated and normal character properties in output. 3. Do not output empty "\rtlch \ltrch", "\ltrch \rtlch" pairs. 4. Handle associated character properties runs instead of handling separately their parts without order of them. Change-Id: Ibbf7365d04708682a5f1eb664a579c60a47465d2 Reviewed-on: https://gerrit.libreoffice.org/72578 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit fd95fb975b754d71d3750e85431a4e596a40e659) Reviewed-on: https://gerrit.libreoffice.org/73868 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-06-05tdf#120412 char formatting UI: clean-up DFLT_ESC_AUTOLászló Németh
Default auto values must be outside of the new enlarged range of the superscript/subscript percent values. Note: the raising limit was modified to 13999 from 14400, because the RTF unit test tdf112208_hangingIndent.rtf lost its hanging from the bigger value. Change-Id: I3a7e9715a27570278ee4ee70f9fc9ad29457e100 Reviewed-on: https://gerrit.libreoffice.org/73166 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit 32262b0a537207832d7d126d8427d8949b9e821d) Reviewed-on: https://gerrit.libreoffice.org/73460
2019-06-05tdf#70234 DOCX: import tracked deletion of fieldsLászló Németh
Deleted fields in tracked changes, for example page number fields, imported as not deleted text fields. Change-Id: Id35c3ad7d293039fc8a2d0b564572dc459a25d0f Reviewed-on: https://gerrit.libreoffice.org/73397 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org> (cherry picked from commit d160bca0dcb80f1b517b79221d5c3a43bbad8639) Reviewed-on: https://gerrit.libreoffice.org/73457
2019-05-29tdf#120412 DOCX filter: fix missing superscriptJozsef Szakacs
by editeng support of large superscript raising. Maximal raising of superscript text is 1584 pt in MSO, while LibreOffice didn't import the values greater than 100% of the current font height. Using the maximal percent value of the default 11 pt font, the limit is 14400% now, fixing most of the import problems. Greater raisings will be limited to 14400% during the DOCX import. Note: the standard doesn't limit the bigger percent values, see "20.374 style:text-position" and "18.3.23 percent" in OpenDocument 1.2. Change-Id: I3d0d08f273f2067180f74fba40c47d62364fcc59 Reviewed-on: https://gerrit.libreoffice.org/69164 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-05-29writerfilter: various small cleanupsMiklos Vajna
Some parameters were passed by value for no reason, it's always a good idea to declare a variable at the point where we can also initialize it, etc. Change-Id: Ia07bbef7826132fa0326445b89fcaf48dd38b11b Reviewed-on: https://gerrit.libreoffice.org/73125 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-05-27tdf#115557 DOCX import: don't multiply charts in footnotesLászló Németh
A chart in a footnote was appeared in every footnotes, resulting fatal problems during a few import/export cycles, see tdf#115558 (MSO is unable to open the DOCX export with multiplied objects). Change-Id: Ib729e4442ed3c92e4646fa7cdf7253a963d883e8 Reviewed-on: https://gerrit.libreoffice.org/73025 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2019-05-24forgot to update commentNoel Grandin
in commit d6865e5cec34f5f521e0f9ec4ef3c7ad04503cfe Date: Fri May 24 11:52:30 2019 +0200 use std::unordered_map in RTFTokenizer Change-Id: I5197eae86c4611d1598dbb60bae4962ad0576ecd Reviewed-on: https://gerrit.libreoffice.org/72906 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-05-24use std::unordered_map in RTFTokenizerNoel Grandin
to speed up make sw.check Using a --enable-dbgutil --enable-optimised build, this takes my runtime from 6m03 to 3m43 Change-Id: I79d2345c361d99d4a1c4402a4b7008bbb59b8184 Reviewed-on: https://gerrit.libreoffice.org/72902 Reviewed-by: Michael Stahl <Michael.Stahl@cib.de> Tested-by: Jenkins
2019-05-22tdf#121784 DOCX import: fix change tracking of footnotesLászló Németh
and endnotes by creating redline data for their anchors, too. Now footnote/endnote insertions are visible, and it's possible to reject them. Change-Id: I5cd3300c0d423b8c6803b7aeb848dcc103c3b565 Reviewed-on: https://gerrit.libreoffice.org/72680 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
generated by cgit (git 2.34.1) at 2024-06-06 15:31:39 +0000