summaryrefslogtreecommitdiff
path: root/sw/source/filter/ww8
AgeCommit message (Collapse)Author
2020-12-23tdf#138953: use original (cropped, but unrotated) object size in spPrMike Kaganski
This not only fixes the regression from b226383a83e41bbced9fc2a02dc09a449401ec97, but also makes the written size more correct than before, when it was slightly larger compared to original object size. Corrected unit test for tdf#116371 reflect that: the object in ODT is 241.78 mm x 240.61 mm. It previously was exported as 241.88 x 240.70; now the exported size is closer: 241.79 x 240.63. This backport introduces getShapes from 36e62098c8c541c4a3fb63eced591cf29ac56e4a to make backporting easier. Change-Id: Ibfe85c7cd98c089e58af8d7f3848990af8e1100f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107957 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108227 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2020-11-16DOCX export: handle conditional fieldsMiklos Vajna
At least the subset where the condition syntax matches between Writer and Word. (cherry picked from commit 5d839ff8a81ade6453a239a258b2a2571e32001e) Change-Id: I107f2b4caeda6f7777696af8d5c5b455854cfa92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105947 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-11DOCX: fix memory leak of cell formula exportLászló Németh
clean-up of commit cf596c43315bb96b5e7256a82256f1ccb8c9c4d0 (tdf#133163 DOCX: export formula cell). The problem was reported by Miklós Vajna. (cherry picked from commit b0b5812bc6b74369c7909313fcb7fd86c535aea3) Conflicts: sw/source/filter/ww8/wrtw8nds.cxx Change-Id: Ia636a6ffe8386e58e31e37c0d8afc283e6f2fc4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105580 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-11tdf#133163 DOCX: export formula cellsLászló Németh
as formula fields instead of exporting only cell text content. Only unmodified formula fields were exported from commit d42776e01b87f12fddbcf78101bca1e10a6e4f97 (tdf#118682 DOCX: export formula fields). Now newly added Writer formula cells or modified table formula fields imported from DOCX (which are converted to formula cells after formula editing) are exported. (cherry picked from commit cf596c43315bb96b5e7256a82256f1ccb8c9c4d0) Conflicts: sw/source/filter/ww8/wrtw8nds.cxx Change-Id: Iecec75b2a36b94c2d3aa998603ac10ea2f2b8d4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105576 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-11-10tdf#118682 DOCX: export formula fieldsLászló Németh
Convert also cell references by removing parenthesization: =<A1>+<B1> -> =A1*B1 =SUM(<A1:ZZ99> -> =SUM(A1:ZZ99) See tdf#133647 for fixing import of cell references. (cherry picked from commit d42776e01b87f12fddbcf78101bca1e10a6e4f97) Change-Id: I5082198aaf8230989f99984f8129b54867b77859 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105520 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-10-27tdf#136983 partial revert NFC ww8 cleanup: remove unused variablesJustin Luth
This is a partial revert of LO 6.2 commit 2ec0cf500222aef55d02df80154b47fbb92970c9 I can't think of any excuse for how I possibly missed that xDocProps was being defined/used outside of this clause. Just plain stupid and blind. The good news is that the create and modified date still seem to be getting saved somehow/somewhere. So it isn't the disaster that it looks like it could have been. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103565 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 1086654d6e8cc22f1f99195668db3f305437e570) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104495 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 19b8ded3ae18dd4070a3e21d7b980782a27e5547) Change-Id: I72ef56fa50b9e92e4ce687b132b1919cfae6c1f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104497 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-25docx export: Use checksum as key to cache graphic, not Graphic*Tomaž Vajngerl
The problem is when we have multiple identical images in the document and try to export. Without this change, the images will be duplicated because the cache is using Graphic*, for which the instance changes all the time (is not unique). Using the checksum will make sure that all the images with the same content will be saved as one image into the document. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103132 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com> (cherry picked from commit 8679bf3ec608aec277fd677082aa5c38e63a65ce) Change-Id: I980af2dba51060ce4320571aca14d21e26ed8976 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103406 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-25tdf#134782 sw: split AddParaSpacingToTableCells flag in 2Michael Stahl
commit 3cccdabf19a99fd3f657985c1822436d7679df2b "extend AddParaSpacingToTableCells with line spacing" changed how the ADD_PARA_SPACING_TO_TABLE_CELLS compat flag works, to improve interop with Word. This commit splits out the change as a separate new compat flag ADD_PARA_LINE_SPACING_TO_TABLE_CELLS ("AddParaLineSpacingToTableCells"), to preserve compatibility with ODT documents that were produced by LO < 6.4 (via SwXMLImport::SetConfigurationSettings()). New documents and WW8/RTF/DOCX import have both flags enabled. The combination false/true is invalid, and treated as equivalent to false/false. Change-Id: Ida20df8fe4a8192a714f91da95345f9726fd7d98 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103317 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 38aa699f265c17548769aaa4f20e1ae35d18f202) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103359 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-08-31tdf#131801: sw: support of style references in ListAutoFormatVasily Melenchuk
ListAutoFormat property did support char attributes, but not style references ("CharStyleName"). It is important for correct formatting of pilcrow symbol or list format in some DOCX scenarios. Export to DOCX already works, but not to RTF/DOC. Change-Id: I1bf23d1e45fcc213adcf9aa6f404be803919fbee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100893 Tested-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit c77b9c349f0a48392d8cb7a49532844b2cafb5ba) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101560 Tested-by: Jenkins
2020-08-31tdf#135973: DOCX export: improved list override supportVasily Melenchuk
Removed remains of old override support which are not working now. Partial refactoring and fixing for listid and overrides detection. Change-Id: I1f94a09b7d51fcc3300b056d6d9e8ea6367a4446 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101238 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101438 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-25ofz#25169 insertion into set might find a duplicateCaolán McNamara
in which case pImpRec is deleted and pImpRecTmp is invalid Change-Id: I2a273a436ebd88cb53e329bbcb4f171dda6ed840 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101155 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-18sw: MS Word export: don't insert section breaks in field instructionsMichael Stahl
MSWordExportBase::NeedTextNodeSplit() simply uses the soft-page-break positions to potentially insert section breaks - but now that Writer can display field instructions, it's quite silly to insert section breaks inside them. Change-Id: Ie57e6281a0287aac36984e5467920852db19a8ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100661 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 68cc91cd2c461b7062c3f3b89b2c677e41c9a8d4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100690 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-07-22tdf#134618 sw: DOCX export: fix order of as-char and at-char fly...Michael Stahl
...at same position. The problem is that in this case the as-char fly was written before the at-char fly but the positioning of the at-char fly can be relative to its character position, i.e. before the as-char fly. Apparently as-char flys are written in DocxAttributeOutput::EndRunProperties() via WritePostponedDMLDrawing(), wheras at-char flys are written earlier, in SwWW8AttrIter::OutFlys() via DocxAttributeOutput::OutputFlyFrame_Impl(). So this undoes the swap that these undergo via the magic of the mark stack. Change-Id: I83a72bb2affbf321fc4dea4e7fb37bdb43cea2e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98543 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 7b156d37cfc92292323694ec064fe51ae57b3257) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98633 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-22tdf#134618 sw: WW8 import: don't insert fieldmark for SHAPE fieldMichael Stahl
Follow DomainMapper_Impl::CloseFieldCommand() and just don't waste effort creating a fieldmark that doesn't provide any benefit. This should avoid any fieldmark related problems introduced in e511a0ca5dde6d731bb126bbfe21768867890102..d9030ad6298e2f49ee63489d6158ea6ad23c0111 Change-Id: I6688dcda1e3b41ac648f3d69740f05d34bb46191 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98542 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 4e0aa38afd674f5ad16b4bc3222dc393543ad915) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98469 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-22tdf#77962 ww8import: 0x4xxx sprms are always 2 byteJustin Luth
SPRA(bytes) | SGC (property type) | A | ISPMD XXX X XX X X XXXX XXXX Focusing on the SPRA meaning: 0 is Operand is a ToggleOperand (which is 1 byte in size). 1 is Operand is 1 byte. 2 is Operand is 2 bytes. 3 is Operand is 4 bytes. 4 is Operand is 2 bytes. 5 is Operand is 2 bytes. 6 is Operand is of variable length. 7 is Operand is 3 bytes. Thus every 0x4xxx and 0x5xxx are 2 bytes sprmCIcoBi = SPRM_CHR(0x60, 1, spra::operand_2b_2); // 0x4A60 and thus it must be defined everywhere as 2 bytes. Wrongly "fixed" from 0 to 1 by commit bf24cca78e3c95d7a07e2073802c1540faec6920 Author: Caolán McNamara on Wed Dec 4 08:56:32 2002 +0000 #105926# some bidi properties with incorrect cached len Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98911 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> (cherry picked from commit 56b04e40ab72b6333ce278ba2980650f5272025f) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98845 Change-Id: Ic30df735ed325a508ef3c7220d9b06878af248a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98932 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-07-11ofz#23961 pad back to original lengthCaolán McNamara
in case of multi-byte input encoding resulting in a shorter output string than input Change-Id: Ieb4bb7b5f4551ca22e87c573233f083901f3d3c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98273 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98516 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2020-07-10tdf#134264 writerfilter: fix DOCX->DOC of ADDRESSBLOCK fieldMichael Stahl
... and other unsupported ones; the problem was that the field got exported with ww::eUNKNOWN = 1, which can't be imported again. Move the ww8 eField enum to include/ so it can be used from writerfilter. (regression from e511a0ca5dde6d731bb126bbfe21768867890102..d9030ad6298e2f49ee63489d6158ea6ad23c0111) Change-Id: I19193392d62fdf0bba01fac2516bafe9fdfa5a99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98221 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit ae2e8202407e82c9b14f0cc307742561f8c6e530) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98244 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98510 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2020-06-15tdf#83309: docx import: allow for lists tabstop at zero positionVasily Melenchuk
Zero position is valid value for tabstop, but previously it was treated as "no tab stop defined". Right now writer distinguishes tab stop at zero postion and no tab stop. Change-Id: Ie32da3d36a263644ba85a882029a8b29ae0501c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95132 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit d2e428d1abb9f2907c0b87d55830e8742f8209b9) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95561 (cherry picked from commit a380a06c1872091e8fa8c810e95a8e1d5dfe1820) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96178
2020-06-15tdf#128195 Keep spacing below last paragraph in header (docx)Samuel Mehrbrodt
Add a layout compat option to keep the spacing below the last paragraph in the header in doc/docx files (cherry picked from commit 9b5805d1ef2b9e9c4e8f389c069807bf4489ea95) Conflicts: sw/inc/IDocumentSettingAccess.hxx sw/source/core/doc/DocumentSettingManager.cxx sw/source/core/inc/DocumentSettingManager.hxx sw/source/core/layout/flowfrm.cxx sw/source/filter/ww8/ww8par.cxx sw/source/uibase/uno/SwXDocumentSettings.cxx writerfilter/source/dmapper/DomainMapper.cxx Change-Id: I259511183a8252e04d9951357dbdd4f4832523ec
2020-06-12tdf#120394: DOCX list import: simplify zero width space hackVasily Melenchuk
Since introducion of list format string hack with creation of zero-width-space can be much more simple. It was being used to indicate existing, but empty list label suffix to avoid stripping down numbering. Change-Id: I9a0c6047f806b2c656ef5dbab0c6b38200818bd2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94383 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95346
2020-06-11tdf#133604 sw: DOCX export: put CH_TXT_ATR_FORMELEMENT in its own runMichael Stahl
Commit b03fefcc4dbdfee3b9eeb5fa0e586dd12ddcd3d2 ought to have fixed this but didn't; the run following the CH_TXT_ATR_FORMELEMENT still ended up inside the field result. But when importing that into Writer, it appeared correct; Word shows the problem. (regression from 94e0b8407b02d76b27324b8b08012eb024aca9e9) Change-Id: I1fc1328223353422a83d403e8f790d156dbec4e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95843 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de> (cherry picked from commit 7f2908b83a39bbb6fa648d6815265ad203f86ddc) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95882 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-06-06tdf#120394: list format string can be emptyVasily Melenchuk
We need to distunguish when we have list format string, but it is empty (no level text will be diplayed) or it does not exist at all, so we need to fallback to old prefix-suffix syntax. Change-Id: Ifd4ccd5a676db86c39d2ef48e91d191d92b9b2a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94322 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> (cherry picked from commit d8329149394e4e5758a9e293b0162db050379a4e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95413
2020-05-27Revert "tdf#104017 DOC export: be less aggressive with merging page styles"Justin Luth
This reverts LO 6.3.4 commit 5d1709a7c4184eb31cfc4c2d3acadff3a4a68189, which tdf#133334 shows is wrong. How this made it past QA is a mystery to me. There should be lots of examples. Change-Id: I17be6e4bab44057f4535d4728825e12d068b65d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94782 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit 42a37f8ce27ad8fca222f50b712a8fed52dbda95) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94683
2020-05-20tdf#127778 DOCX import: fix unexpected heading on non-first page ...Miklos Vajna
... when the first page has a heading Regression from commit 17e51f427b3f0cec74ac8e0a1b3f51189006ae6f (DOCX import: first page header should always set default headers as well, 2014-11-21), the problem is around how to split a first + follow page style on import, and then do the opposite on export. This is described using a single section in OOXML, but Writer has 2 page styles for this (unlike in case of the DOC filter). This means the header margin has to be taken from one of these page styles. The above commit tweaked the import, so the follow page style has the wanted header margin, but this leads to incorrect layout. Fix the problem by tweaking the export instead: it has random access to the doc model, so it can take the header margin from the first page style if needed, and then the import side can be reverted, leading to correct layout. Also remove some leftover debug code in test/, which was added in commit 5352d45dd4a04f8f02cf7f6ad4169126d3b3586a (convert AnimationImport to fast-parser APIs, 2020-02-18). (cherry picked from commit 51534ac2b9747975945acb6a1e1ba5cc6d73f5c2) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport6.cxx Change-Id: I4bbf7271f3a437e8432399bd1e32e9d24190a501 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94193 Tested-by: Jenkins Reviewed-by: Xisco Faulí <xiscofauli@libreoffice.org>
2020-05-20sw: add pad-to-5 numberingMiklos Vajna
This is the last padded numbering type that is supported by Word but was not supported by Writer. (cherry picked from commit 8540c7b18bae9c9b46e6feb7658198a7fc62e811) Change-Id: Ica1a0843897c61a4b569105fd21e5bfe7b5012cb
2020-05-20sw pad-to-4 numbering: add DOCX filterMiklos Vajna
Now that style::NumberingType::ARABIC_ZERO3 is already handled, this is much easier. (cherry picked from commit d7b6269bd5414ca0aa502a2fef7a838bcfbc1161) Change-Id: Ibe76d90253a5bfad84560395502590a380d559d2
2020-05-19sw pad-to-3 numbering: add DOCX filterMiklos Vajna
There is no NS_ooxml::LN_Value_ST_NumberFormat_foo code for this on the import side, rather the number format code is set to NS_ooxml::LN_Value_ST_NumberFormat_custom, then a separate NS_ooxml::LN_CT_NumFmt_format contains the number format string. Declare w14 as an XML namespace on the export side, even if we write no <w14:something> elements. This is needed by <mc:Choice Requires="w14">, which refers to an XML namespace in the OOXML markup. (Interestingly officeotron doesn't check for this, though.) (cherry picked from commit 52ed1091be05d5a07a021403095c52f0f3986ed6) Change-Id: If5fbcea4f163bd4d1a1ed820e15ceb61dc9c0519
2020-05-19sw chicago numbering: add RTF footnote exportMiklos Vajna
Chicago numbering is not supported for paragraph numbering (same as DOC), so focus on footnote/endnote export only. There is markup in RTF to store doc-global footnote/endnote numbering type and the same for per-section. DOC writes both, then Writer only reads the global setting and Word only reads the per-section setting. This means only export is needed here, import already handled the doc-global markup, and that's enough. (cherry picked from commit 4ba09be7e260ce2a79a23465db7b2837422cde30) Change-Id: I3590560ca913e04078988fe4784e50fa5cbf17bf
2020-05-18tdf#98409 doc export: export (non-default) cell marginsJustin Luth
Previously, the only cell margins that were being exported were the row defaults from the last column. These cell margins are tricky, because multiple cells and multiple sides can be combined together into a single definition. A previous commit for tdf#73056 was needed to import these sequences - instead of only the first instance. Change-Id: I513c432ec11a78c7bb52ac6fb628851192e88023 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93638 Tested-by: Andras Timar <andras.timar@collabora.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-05-18tdf#73056 doc import: table margins - unknown byte is EndCellJustin Luth
The problem was that the cell margin that overrides the table defaults was only being applied to one cell, while a range of cells might be defined. a sprmTCellPadding is specified by a CSSA. The CSSA starts with an ItcFirstLim, which consists of a start and end cell. The end cell is NOT included. Change-Id: Ia90bc28451d39d60ce343d24b02fd3661b05d950 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92628 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93637 Tested-by: Andras Timar <andras.timar@collabora.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2020-05-18sw chicago numbering: add DOC footnote exportMiklos Vajna
Note that chicago numbering can't be used for paragraph numbering. It would be possible technically, but the spec && bffvalidator && Word agrees on forbidding that. Change-Id: Ic3de51f9724d399542f4fe6ac48e70e94c6ea4ba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90080 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 9a1dd2e242794b4f26d207efc80a2f5bc088ab7c)
2020-05-18sw chicago numbering: add DOCX footnote exportMiklos Vajna
Only this was missing, paragraph numbering import/export and footnote numbering import was already working. Change-Id: Ia5966cc7f1308ba81bebc1bf628d8efb17acb713 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90075 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit ddbad5612e4322665bc70f4a026e5b052bcaf344)
2020-05-17Remove some redundantly user-declared copy ctors and assignment opsStephan Bergmann
...that trigger -Werror,-Wdeprecated-copy ("definition of implicit copy {constructor, assignment operator} for ... is deprecated beause it has a user-declared copy {assignment operator, constructor}") new in recent Clang 10 trunk (and which apparently warns about more cases then its GCC counterpart, for which we already adapted the code in the past, see e.g. the various "-Werror=deprecated-copy (GCC trunk towards GCC 9)" commits) Change-Id: Ie37bd820e6c0c05c74e1a862bb1d4ead5fb7cc9c Reviewed-on: https://gerrit.libreoffice.org/83698 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93694 Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-05-15tdf#132766: DOCX export: always try to set bullet font for listVasily Melenchuk
There are some problems with bullet if we use MS Wingdigs bullets and do not specify Symbol font for it. It shiuld be either UTF-8 or Symbol, but not mixture of both. Change-Id: Ie4a6f7e8fee6cfab21a18fc080f33d1bff455dd9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93846 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94158
2020-05-15DOCX export: fix interaction between the crop and the wrap polygon of imageMiklos Vajna
If the wrap polygon is influenced by crop at import time, we need to do the opposite at export time. Do this for RTF and DOCX, where there is matching import code in writerfilter/, leave DOC alone for now. Test this by changing testFdo76803 into an export test, then seeing how the first point's Y position fails and fixing up the exporter, so we get back the old good value. (cherry picked from commit c68b458514b35cae70c9a6630e06f46a867aa3b9) Change-Id: Ieef18aad3c76f7945c7348201b07bcb27a4cd48d
2020-05-15sw padded numbering: add DOC footnote filterMiklos Vajna
Import side: remove the duplication between SwWW8ImplReader::CoreLoad() and WW8ListManager::ReadLVL(). The CoreLoad() version did not support reading 0x16 as it did a "& 0xf" on the value before parsing. Export side: Writer supports footnote numbering type per-document, Word supports it per-section. So next to the per-document export add a per-section one, that's what Word actually reads. Similar code was there already for DOCX. (cherry picked from commit 5c7d0c5bafd244f1bfb3930e0229f1f3f2371c82) Conflicts: sw/source/filter/ww8/ww8par.cxx Change-Id: Ic94e953cfee4514aabe507a8bcf75445bf05f401
2020-05-15sw padded numbering: add DOCX footnote exportMiklos Vajna
This is mapping separate from paragraph numbering. I'm not exactly why; perhaps because this is modeled after DOC, where certain numbering types are not allowed for paragraph numbering (but are allowed for other numbering types). (cherry picked from commit 3ea32f2b6cbe515353218bc1f3d5746ca66f6a5a) Change-Id: I06503389da520bd3bfd39252c4dcef39bac03eee
2020-05-15sw padded numbering: add RTF exportMiklos Vajna
RTF import was working already. (cherry picked from commit dc05428405fb96f28b2d7c7bcfa9033f3f5248a3) Change-Id: Ifa71035645d4738138790e72c3f9dee640833d0c
2020-05-15sw padded numbering: add DOC filterMiklos Vajna
[MS-OSHARED] 2.2.1.3 MSONFC says msonfcArabicLZ / 0x16 should be used for this. (cherry picked from commit a8a5fc175a8af2bf3750497d7ebe2c8ea9176981) Change-Id: I6bdf460d77acabf54cecc2ec2d2bca91bc814518
2020-05-14sw padded numbering: add DOCX filterMiklos Vajna
DOCX uses <w:numFmt w:val="decimalZero"/> for this. (cherry picked from commit 5435ea2afc5da5633a440f2f06d79265bcbb040c) Change-Id: I12a4a88f472af42a04244d30f9e59fc0b8b4855c
2020-05-13tdf#130812 DOC import: fix unexpected transparency of textMiklos Vajna
DOC can have black with transparency set to 0xff, and that is meant to be just black. Allow COL_AUTO, though; the rendering will not consider that as transparent anyway. Other than that, DOC does not support text with transparency, it's a DOCX-only feature. (cherry picked from commit 634a9ba15d65b6fdc506326e6b49b4b957c5cfcb) Change-Id: I33f61b54b8ebd7958845063ae61900182d6f5e80
2020-05-12sw: add DOCX export for semi-transparent textMiklos Vajna
This is the case when the value is not in the grab-bag, that was already supported. (cherry picked from commit 6f6a64952d9aa4826e83ad94c2a6de2344cbe2de) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport14.cxx Change-Id: I334333ec441644229540a358d7bf8811373618c7
2020-05-06tdf#116883: sw: support for lists level format stringVasily Melenchuk
Multilevel lists are more flexible in case of DOCX. There is supported custom format for any level in DOCX unlike in LO and ODT where we are limited only with prefix and suffix for hardcoded list levels separated by dot. At the same time DOCX can have lists not only "1.2.3.4", but "1/2/3/4" or even "1!2>3)4" and such format can vary on each list level. Here is basic implementation for list format as a core feature for all documents and old way (prefix-suffix + ".") is left as fallback. Practically its usage is currently implemented only in DOCX import/export. Some RTF/OOXML unittests were redesigned: since we are not creating prefix/suffix for these formats conditions should be checked in a different way. Change-Id: I1ec58bcc5874d4fa19aee6a1f42bf1671d853b14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92106 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93125 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Change-Id: Ia8f066913a2565559d81f3caabeba24b29c09052 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93456
2020-05-06tdf#108496: DOCX: redesign of override in listsVasily Melenchuk
List level overrides are not just about numbering, it is about numbering restart. Thus some changes to DOCX import/export were added. Improved support for several lists referring the same abstract list, especially in situation when one list have overrides. In addition some export cleanup is made: less unnecessary list duplications, less level overrides when no properties were changed. Change-Id: Ic7a69bc2e3080b39f5205cb90b46d14247abf305 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92412 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Change-Id: I35937449bd563eacceb3753e62b9ff7245f12b89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92739 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93455
2020-05-06sw from-bottom relative orientation: add DOCX filterMiklos Vajna
The OOXML equivalent is <wp:positionV relativeFrom="bottomMargin">, and the position is typically a negative number (i.e. the position is the offset between the top of the shape and the top of the top or bottom margin; not the distance and it's always the top of some margin). (cherry picked from commit fc620901ddd134f644a56ed4ea4a9b5446cc5675) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport14.cxx Change-Id: Ia979bc8bfaa37d29b0947c4408335e0a80c05880
2020-05-06DOCX export: fix handling of section starts that originally had page marginsMiklos Vajna
This is similar to commit 26f2a9e1a10a22e864e71ee7c94934821703e021 (DOCX export: fix handling of section starts that originally had headers, 2020-02-06), except here the top margin has to taken from that follow page style, not the header. Without this, it can happen that the page number in the original Writer doc model and the exported Word result do not match. This required reworking WriteNextStyleHeaderFooter(), which assumed that the header/footer status is already calculated by the time its called. But the page margin code runs earlier, so we need to make that decision earlier, even when the header/footer status is not yet calculated. Change-Id: Ife7396603702d2048d544aa46f96acfa337a041a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88211 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit f0decd9c932b50eddeecd49a6ee44182e78be938)
2020-05-06DOCX export: fix handling of section starts that originally had headersMiklos Vajna
Both the DOC import (in wwSectionManager::InsertSegments()) and DOCX import (in SectionPropertyMap::CloseSectionGroup()) have a mechanism to try to attach changed headers/footers from a continuous section break somewhere, so they are not lost. This means that even if the rendering of such documents is OK, explicit code is needed to undo the effect of the importer at export time, or those headers will be lost. Start doing this for the DOCX export case when the headers/footers are placed at the "previous-in-practice" paragraph, more cases (handled at the import side) can be added later. (cherry picked from commit 26f2a9e1a10a22e864e71ee7c94934821703e021) Conflicts: sw/source/filter/ww8/wrtw8sty.cxx Change-Id: Ic2304a74919d18da3ba9cb4afe301e0247a50dc2
2020-05-06DOCX export: fix table style config handling wrt nested tablesMiklos Vajna
The bugdoc had 2 tables: both using the TableGrid table style, but one had a direct formatting to disable all borders. The second was in the A1 cell of the first, and given that the table style config state was not separated for nested tables, the border settings of the inner table affected the settings of the later cells of the outer table. Change-Id: Ie7897bc661d9f47ca9f5c1b3ed1c439ef0406037 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87899 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 2d87b09e6e675dd593e26cb266deb4ea91f0e7a7)
2020-05-05DOCX export: write document variablesMiklos Vajna
This means that in case a user field is exported to DOCX and the user updates the field, the result will be still correct, not empty. (cherry picked from commit ae5f469d3893de73850ccc369dbf426a4acd8f15) Conflicts: sw/source/filter/ww8/docxexport.cxx Change-Id: I2b52292c70aa6f597f92af95e16c773839247efa
2020-05-05DOCX export: implement support for user fieldsMiklos Vajna
Updating the field doesn't work yet, that'll need additional markup in settings.xml. (cherry picked from commit 676862bb8aa043f116615e5d0dac59254eaa8138) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport14.cxx Change-Id: I562ae62cebcbd5ca474bd0f7a181773f8e515f5e
generated by cgit (git 2.34.1) at 2024-07-20 02:54:36 +0000