summaryrefslogtreecommitdiff
path: root/writerfilter/source/ooxml
AgeCommit message (Collapse)AuthorFilesLines
3 daysSimplify a bit, and use more o3tl::convertMike Kaganski1-25/+12
Change-Id: I30f619b81d831db9c1e212a1588d5696b9ad3dd0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166048 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-28tdf#158803 test for membership should be 'not in'LeSasse1-2/+2
Change-Id: I9ed1a2cb83cfd0be8298e7a90c7b4fb931c33528 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165369 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-20tdf#126533 docx import: page background vml fillJustin Luth1-1/+2
This patch imports bitmaps/tiled textures (primarily), but also somewhat for gradients (because of a gradient2 -> gradient mismatch somewhere) and somewhat for patterns (because patterns are not well imported in general). Note that the imported fill likely will NOT match MSO, because their background CHANGES BASED ON THE ZOOM LEVEL. For example, my primary testing file (A6 landscape) has a logo which is only 25% visible in Word 2003 at 100%, but shows 90% of the logo at 200%, and many tiles of logos when exported as PDF. The same is true for gradients etc. Changing background on zoom is an absolutely bizarre implementation, and naturally LO could only accidentally look identical (and should never try to do so). make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf126533_noPageBitmap make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf126533_pageGradient This is slightly ugly, but I don't know how to make a COPY of the XPropertySet UNO junk. All I have is references, and dispose deletes everything, even the references. I took some inspiration from RTF which just disposes the shape after grabbing the background color. Thus, just change the page style known to exist and be used, and then simply remove the fill if it isn't needed in the end. Any new page styles can just copy the default page style fill. Change-Id: Id3ea002c685642ff4c289982d0108247a6e9bb8d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162958 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2024-02-14tdf#145539 convert const char[] in files to constexpr OUStringLiteralvarshneydevansh1-8/+8
OStringLiteral represent read-only memory for string literal while OUString is a dynamic string class with reference counting hence use OUString when you need reference counting, string manipulation along with _ustr suffix. Change-Id: Ib566df156d81c7527f5650bcc6bd5db6509128cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162911 Tested-by: Jenkins Reviewed-by: Hossein <hossein@libreoffice.org>
2024-01-20tdf#153909 docx import: wrap through shapes shouldn't FollowTextFlowJustin Luth1-1/+13
This resolves a NISZ 6.4.0 regression from commit 27d04f6dbf38aa28fb7215590d578c4567db5770 tdf#119038 DOCX: fix FollowTextFlow handling MSO is all over the place in how they implement layoutInCell (aka FollowTextFlow in LO). There are lots of compat15 differences for this, but I don't notice compat coming into play with this bug. For reference, see commit e993638d5ecd33783f2eebdccfa87a81e5a8a2c5 Author: Miklos Vajna on Mon Jan 24 12:53:25 2022 +0100 DOCX import: fix <wp:anchor layoutInCell="1"> with <wp:wrapNone> I'm sure this is the WRONG code spot for handling FollowTextFlow, but anywhere else and we lose the "it came from a vml shape" limiting information, so I'm not going to try to relocate this code. Inline (as-character) shapes ignore layoutInCell, so the type of anchor (floating or inline) shouldn't matter and therefore doesn't need to be part of the if () clause. The header can be special (in compat14 it means everything is wrap through), but at least in this case it is not limited to IsInHeaderHeader. Using a non-header as the unit test. make CppunitTest_sw_ooxmlexport21 \ CPPUNIT_TEST_NAME=testTdf153909_followTextFlow The first patchset contains a list of all of the unit tests that were impacted by this patch: nothing interesting. Change-Id: I0c4c7924833550533ad1b0b7609840a666d4d589 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162324 Reviewed-by: Justin Luth <jluth@mail.com> Tested-by: Jenkins
2024-01-19tdf#159254 import paper bin/paper source from rtf/docx filesOliver Specht1-0/+4
Imports \binfsxn and \binsxn from RTF and w:paperSrc from docx files and applies paper tray to the page style if the printer supports the imported tray value. Works only on Windows. Change-Id: Ie1170c58f7114f0dbf6bdd2721d4e077886cbe16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162236 Tested-by: Jenkins Tested-by: Gabor Kelemen <gabor.kelemen.extern@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-01-13cid#1546354 COPY_INSTEAD_OF_MOVECaolán McNamara1-4/+4
and cid#1546319 COPY_INSTEAD_OF_MOVE cid#1546286 COPY_INSTEAD_OF_MOVE cid#1546283 COPY_INSTEAD_OF_MOVE cid#1546191 COPY_INSTEAD_OF_MOVE cid#1545953 COPY_INSTEAD_OF_MOVE cid#1545874 COPY_INSTEAD_OF_MOVE cid#1545857 COPY_INSTEAD_OF_MOVE cid#1545781 COPY_INSTEAD_OF_MOVE cid#1545765 COPY_INSTEAD_OF_MOVE cid#1545546 COPY_INSTEAD_OF_MOVE cid#1545338 COPY_INSTEAD_OF_MOVE cid#1545190 COPY_INSTEAD_OF_MOVE cid#1545272 COPY_INSTEAD_OF_MOVE cid#1545242 COPY_INSTEAD_OF_MOVE cid#1545229 COPY_INSTEAD_OF_MOVE Change-Id: I88813d9dbd87ce10375db8198028f8b70e23f0fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162027 Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-12cid#1546222 COPY_INSTEAD_OF_MOVECaolán McNamara3-5/+5
and cid#1546154 COPY_INSTEAD_OF_MOVE cid#1546120 COPY_INSTEAD_OF_MOVE cid#1546115 COPY_INSTEAD_OF_MOVE cid#1546111 COPY_INSTEAD_OF_MOVE cid#1546096 COPY_INSTEAD_OF_MOVE cid#1546016 COPY_INSTEAD_OF_MOVE cid#1545980 COPY_INSTEAD_OF_MOVE cid#1545942 COPY_INSTEAD_OF_MOVE cid#1545902 COPY_INSTEAD_OF_MOVE cid#1545869 COPY_INSTEAD_OF_MOVE cid#1545853 COPY_INSTEAD_OF_MOVE cid#1545769 COPY_INSTEAD_OF_MOVE cid#1545742 COPY_INSTEAD_OF_MOVE cid#1545735 COPY_INSTEAD_OF_MOVE cid#1545689 COPY_INSTEAD_OF_MOVE Change-Id: If93debe8b00991761cf1876b3fce27b09906749e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161966 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-08cid#1545370 COPY_INSTEAD_OF_MOVECaolán McNamara2-4/+4
and cid#1545364 COPY_INSTEAD_OF_MOVE cid#1545363 COPY_INSTEAD_OF_MOVE cid#1545344 COPY_INSTEAD_OF_MOVE cid#1545299 COPY_INSTEAD_OF_MOVE cid#1545287 COPY_INSTEAD_OF_MOVE cid#1545267 COPY_INSTEAD_OF_MOVE cid#1545256 COPY_INSTEAD_OF_MOVE cid#1545226 COPY_INSTEAD_OF_MOVE cid#1545500 COPY_INSTEAD_OF_MOVE cid#1545538 COPY_INSTEAD_OF_MOVE cid#1545618 COPY_INSTEAD_OF_MOVE cid#1545681 COPY_INSTEAD_OF_MOVE cid#1545750 COPY_INSTEAD_OF_MOVE cid#1545778 COPY_INSTEAD_OF_MOVE cid#1545785 COPY_INSTEAD_OF_MOVE cid#1545799 COPY_INSTEAD_OF_MOVE cid#1545847 COPY_INSTEAD_OF_MOVE cid#1545958 COPY_INSTEAD_OF_MOVE cid#1545963 COPY_INSTEAD_OF_MOVE cid#1545990 COPY_INSTEAD_OF_MOVE cid#1546013 COPY_INSTEAD_OF_MOVE cid#1546029 COPY_INSTEAD_OF_MOVE cid#1546079 COPY_INSTEAD_OF_MOVE cid#1546104 COPY_INSTEAD_OF_MOVE cid#1546127 COPY_INSTEAD_OF_MOVE cid#1546133 COPY_INSTEAD_OF_MOVE cid#1546155 COPY_INSTEAD_OF_MOVE cid#1546190 COPY_INSTEAD_OF_MOVE cid#1546216 COPY_INSTEAD_OF_MOVE cid#1546273 COPY_INSTEAD_OF_MOVE cid#1546315 COPY_INSTEAD_OF_MOVE cid#1546326 COPY_INSTEAD_OF_MOVE cid#1546387 COPY_INSTEAD_OF_MOVE accept some reasonable suggestions Change-Id: I7b004086d490c7618d8fe7a21a53cfa8ac1f8408 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161748 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-11cid#1545577 COPY_INSTEAD_OF_MOVECaolán McNamara2-2/+2
and cid#1545679 COPY_INSTEAD_OF_MOVE cid#1545691 COPY_INSTEAD_OF_MOVE cid#1545697 COPY_INSTEAD_OF_MOVE cid#1545711 COPY_INSTEAD_OF_MOVE cid#1545730 COPY_INSTEAD_OF_MOVE Change-Id: Ic0777a8ba532b00b021ffed81243505fbb7250f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160568 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-29Related: tdf#104718 Use package repair request and behaviorMike Kaganski1-4/+2
Same as in other places handling that: * SfxBaseModel::load (sfx2/source/doc/sfxbasemodel.cxx); * StorageFilterDetect::detect (filter/source/storagefilterdetect/filterdetect.cxx); * TypeDetection::impl_detectTypeFlatAndDeep (filter/source/config/cache/typedetection.cxx) In these cases, the same handler is used (RequestPackageReparation); when the user approves an attempt to repair the package, the media descriptor gets "RepairPackage" property set to true (this produces a "(repaired document)" appended to the document title); also, the document is opened in template mode (so saving it doesn't simply overwrite the original broken document, but asks for a new name). Re-using this logic, and checking if the "RepairPackage" is already set, allows to unify the behavior, and to avoid duplicate warnings when the user already approved repair of a broken package. The request won't contain the details of the XML problem; but it will be shown if rejected anyway, so OK for the diagnostics. Change-Id: Ic997f89272212227479d14236f5e7788298a904a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160001 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-11-28tdf#158348 Treat wordprocessing canvas like group shapeRegina Henschel1-2/+2
getFullWPGSupport() is always false for mrShapeContext in case of a shape on wordprocessing canvas in table cell. On the other hand we do not need the test, because a wordprocessing canvas only occurs in docx and thus the replacement group always has FullWPGSupport. Change-Id: I0e7a9cf1c1c91a893ad7411fda7607947f053e05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159979 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
2023-11-16writerfilter: fix utext()'s dumb sal_uInt8* parameterMichael Stahl1-16/+12
This removes all but 4 reinterpret_cast in the module! TableManager::utext() even assumed that the bytes are little-endian. Change-Id: I12031336cabedfd6c0fb614ee0e3400810f98e2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159486 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-11-15Import Wordprocessing Canvas, wpc:wpc elementRegina Henschel2-3/+52
Currently LibreOffice uses the VML fallback, when a docx document has a wpc:wpc element. This patch implements to use the choice part with the wpc:wpc element. That is often called 'drawing canvas'. The patch uses a similar approach as for SmartArt. The drawing canvas is imported as group shape and for the background an additional rectangular shape is inserted as first in the children vector. Not using VML has the advantage, that the custom shape import is used for preset shapes. VML import produces problems because some properties are not available in VML or the current VML import has deficits. The test suite shows examples, what is better without using the VML fallback. Affected bug reports are e.g. tdf#104671 or tdf#154828. A drawing canvas must be used in Word for connector shapes. A connector in Word on the drawing canvas is not written as cxnSp element, but as ordinary wsp element with additional wps:cNvCnPr child element. The patch generates a connector in such case. Unsolved problems: The path of a curved connector in OOXML is basically incompatible to the path which LibreOffice generates. This patch uses the default path for a curved connector. Same is done in import in Impress. Using the VML fallback had generated a custom shape with the current path and handles, but the connections to the target shapes were lost. Export to docx is missing. The drawing canvas is not recreated, instead a group with the additional background shape is exported. That is no regression, using VML has produced a group too on export. I don't know whether XML_graphicFrame can occur in WordprocessingCanvasContext. At least charts and math equations are not possible on the drawing canvas in Word. Import of WordArt shapes does not work. That is not regression. It works neither in the VML import. Change-Id: I04bf8407efd1939cdf3137775f8afad420b74014 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156629 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-10-21Extended loplugin:ostr: Automatic rewrite O[U]StringLiteral: writerfilterStephan Bergmann2-11/+11
Change-Id: I6d566f7d7d2ef3d7d5efdd3cc94f129c6b4dbbb3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158292 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-16sw floattable, wrap on all pages: add DOCX filterMiklos Vajna2-1/+3
- map DocumentSettingId::ALLOW_TEXT_AFTER_FLOATING_TABLE_BREAK to <w:compatSetting w:name="allowTextAfterFloatingTableBreak"> on export - do the opposite on import - this requires a bit of rework, to avoid routing <w:compatSetting> via a grab-bag when we want to actually read it during import - also expose GetBooleanValue() from the OOXML tokenizer, so dmapper can know when the value of the compat flag is a true-like string. Note that it seems DOC and RTF don't have a matching compat flag for this. Change-Id: I0cb1230ee40994f59b816c42f8e7d2ac658b3212 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158013 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-10-07loplugin:ostr: automatic rewriteStephan Bergmann1-2/+2
Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2023-09-18tdf#55160 sw floattable, nested DOCX imp: fix inner tables at cell startMiklos Vajna1-1/+3
The trouble was that in case two floating tables start at an (outer) cell start, then everything up to the end of the first inner table ended up in the body text, not in the outer table. This happens because the table depth of the inserted dummy character was incorrect. Fix the problem by comparing what model.xml does at <w:p> start and what OOXMLFastContextHandlerTextTable::lcl_startFastElement() did in the dummy paragraph case, and sending the table depth in the dummy case as well. With this the bugdoc has the expected 19 floating tables in Writer and is of 1 page, both matching Word. Change-Id: I604956f28fdc01943ab913c5aa30365376c4d2b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157006 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-06-27loplugin:stringstatic look for more stringsNoel Grandin1-6/+6
that can be initialised at compile-time instead of runtime Change-Id: I08d516fdc13a3a79f93c079f89ac44cbc7a1ed71 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153620 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-26new loplugin:constexprliteralNoel Grandin1-39/+39
OUStringLiteral should be declared constexpr, to enforce that it is initialised at compile-time and not runtime. This seems to make a different at least on Visual Studio Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-11oox: fix theme data in model.xml to use a correct typesTomaž Vajngerl1-6/+6
Change-Id: Ifaa725d8a3e6c4cfefc92a6c5fcdb581610d3ce6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152832 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-06-05sw floattable: fix lost tables around a floating table from DOCXMiklos Vajna3-0/+46
The DOCX file has 3 floating tables: the first one is immediately followed by a second one, and the second one also has an inner table. The problem is that somehow dmapper thinks it's fine to merge the two outer table together, than the inner table invalidates some of its cell start/end references, so at the end the outer table conversion fails, which means we only have 1 table, not 3. This is a bit similar to commit 1c99616f86f7d5b83b91edc225fc95fec227d710 (sw floattable, crashtesting: fix PDF export of forum-mso-en3-26783.docx, 2023-05-02), but here fixing the problem at the dmapper level sounded too complex. Instead inject the text node that'll serve as an anchor point at a tokenizer level. With this, the DOCX version of the bnc#816603 bugdoc (the one that started all workarounds in 2013) has one less overlapping table, but it still has problems. Change-Id: I54307b4c554da51bb55287e61bca700d8343d11c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152599 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-06-01Revert "Convert XFastParser into a normal C++ interface"Noel Grandin3-9/+9
This reverts commit 5e68d6cfade45f40b1ad46025a81afe4cb8dd337. Reason for revert: Seems like outside users have been using this API Change-Id: I8814cf1eb4f000eeb4cbbb5db9c282d001465993 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152441 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-01Convert XFastParser into a normal C++ interfaceNoel Grandin3-9/+9
There is no need for it to be an UNO interface anymore (ever since we started supporting dynamic_cast on UNO objects). Which means that XImportFilter2 also needs become a C++ interface. Change-Id: Ice2db0f098271bba32b199bd083b08cb8410ce93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152388 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-24loplugin:unnecessarygetstr extend to more std::string checkingNoel Grandin1-1/+1
suggested by mike kaganski Change-Id: I5f5f254142767aca45a6101abdd84a0163ca6a34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150936 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-10Use more *string_viewMike Kaganski1-2/+2
Change-Id: I1172febd45da4dba006f8495427fe45c6d9b9fa6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150187 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-08oox: add model::Theme to oox::Theme and remove createSvxThemeTomaž Vajngerl2-2/+3
This is the start of the change where oox::Theme is only a holder of model::Theme and not a oox structure. This is probably the easiest way how to refactor that. In this commit only prepare that and make the code work the same as it did before. Change-Id: I926a35fd0db383ddb182dc83b36411b2d40b8530 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147692 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-03-31tdf#150542: DOCX import: support for document variblesVasily Melenchuk1-0/+3
Writer does insert document variables only if they are in document body as DOCVARIABLE fields. But ones given in settings.xml (w:docVars/w:docVar) were ignored. Moreover variables in settings should have priority and overwrite ones in fields. Word by default does show only field results, but refreshing field values will override values with ones from settings. Change-Id: I7103c90eef59ab18f8a25e616dcf8a8b1c6dcb08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149646 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-03-29tdf#124472 DOCX import: fix broken field command by skipping delInstrTextCzeber László Ádám1-3/+36
Process only inserted and not tracked parts of the (partially) tracked field commands to avoid of broken fields, e.g. hyperlinks with bad URLs. For example, instead of the previous bad URL 'https://www.libreoffice.org/"HYPERLINK https://bugs.libreoffice.org/', now the hypertext field of the test document imported with the correct URL 'https://www.libreoffice.org/'. Field commands have change tracking in OOXML, but not in ODF/Writer. OOXML delInstrText, i.e. deleted part of the field commands was imported as part of the actual command, resulting broken fields, e.g. hyperlinks. FieldCommand was splitted into two parts, deleted and non-deleted elements. This way the commands do not get mixed up if the order is changed and no fragmentation of deleted items occurs (otherwise it could fail on the test of tdf#150086). Change-Id: I97d22e5ee1fe647715206f86c4160ebcc4b9cca0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148528 Tested-by: László Németh <nemeth@numbertext.org> Reviewed-by: László Németh <nemeth@numbertext.org>
2023-03-23mutex in OOXMLFactory_* is unusedNoel Grandin1-13/+1
Change-Id: I55cf235919df3c19019ca5d280f10f6720cc4f15 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149416 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-03-06writerfilter: prefix members of OOXMLStarMathValueMiklos Vajna2-4/+4
See tdf#94879 for motivation. With this, writerfilter/ is done, I think. Change-Id: Ia2ae5394e41688049b0a639aa5ad922980928cf9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148293 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-03-01oox: import directly into docmodel's Theme and ColorSetTomaž Vajngerl2-2/+4
This changes the import to directly fill values of a model::Theme and model::ColorSet, without filling the oox structs first. The goal is to get rid of the oox in the long run, but for now it is necessary to keep reading into both, which is a duplication. The next step is to also fill the FontScheme and FormatScheme structures. Change-Id: I488ec096cbc184bc70d24510ac9091a488540422 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147571 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2023-02-27sw: prefix members of OOXMLDocumentImpl, OOXMLFastContextHandler, ...Miklos Vajna6-37/+37
... OOXMLFastContextHandlerLinear and OOXMLParserState See tdf#94879 for motivation. Change-Id: I65f1b98918da40d9e3dbc27af54dadd38aaba8be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147854 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2023-02-16Drop 'using namespace ::std' in dirs [u-x]*Gabor Kelemen3-24/+21
Change-Id: I8c044369826b00241496cfc7ba2463e507c0d1a6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147077 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
2023-01-18tdf#119229 docx: Preserve w15:paraIdParent attribute in commentsExtendedParis Oplopoios3-3/+9
w15:paraIdParent attribute indicates that the comment is a reply to the value id Change-Id: I9e6eca6a656594c956629c1434b8e5c3aa573c60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145314 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-01-05Revert all the recent loplugin:unocast changesStephan Bergmann1-2/+1
...as obsoleted by ef533553559fe09b4afab651fc692885d1acf4ed "Rudimentary support for dynamic_cast on UNO proxy objects". This reverts all of: 4cfcc9ac37b90ce64c8402a41eb4638adb185b5c "loplugin:unocast (framework::Desktop)" 03efbf72f4ddf7a84aa8aabef348331bd4b75e8a "loplugin:unocast (vclcanvas::TextLayout)" 80099fdd51a69eaa6c36ca88ef772810e4a777fa "loplugin:unocast (SalGtkXWindow)" cc147f576d8687fb79c77d47d41dc4ba1678a469 "loplugin:unocast (sdext::presenter::CachablePresenterView)" 40db42be1d8fd0f9c6c8c5ba3767ddb9ee2034c2 "loplugin:unocast (vclcanvas::CanvasFont)" 2d1e7995eae29e2826449eb5179f5fae181794a5 "loplugin:unocast (CairoColorSpace)" 4c0bbe4bd97636207cf71a6aa120c67698891da9 "loplugin:unocast (canvas::ParametricPolyPolygon)" 89803666621c07d1b1ac9d3bd883f0ca192a91a0 "loplugin:unocast (vclcanas::CanvasBitmap)" d5e0c2c8db71878d21c2a7255af08cf5f9a6dd04 "loplugin:unocast (sfx2::DigitalSignatures)" c0c4519e0d5b555f59bbc04cc616454edfd1f4ce "loplugin:unocast (VCLXAccessibleComponent)" feb8b833a6245d42400f42a0bc789dc84594ee6f "loplugin:unocast (VCLXDialog)" 1fa58cc6cc9c3849753342a5d9a6ddfa461b5e66 "loplugin:unocast (VCLXMultiPage)" f481f036deb1b1b46f3038074c4659f3a91b9c6c "loplugin:unocast (DocumentSettingsSerializer)" 73df933f5fa5932f94e5a1b338a3eda00a9ce354 "loplugin:unocast (css::embed::EmbeddedUpdate)" 420165ab0ef03c0467f9d17f504de2d2fc78f0e6 "loplugin:unocast (canvas::tools' StandardColorSpace, StandardNoAlphaColorSpace)" 9abe8ee067e6c00f19d8a13346d53c4641c27166 "loplugin:unocast (MutableTreeNode)" 9f3022ceb036f23b4b0994c3e2fbd1001bff225a "loplugin:unocast (VCLXTabPage)" 1be70dda02c12a60778b7607cff2520ae1aa611e "loplugin:unocast (vcl::unotools::VclCanvasBitmap)" d6a70bb641b96e8e5616448c2378131ed62658b4 "loplugin:unocast (basegfx::unotools::UnoPolyPolygon)" 5a14f009e6782c077463c8cbb8e9cea3d7950107 "loplugin:unocast (xmlsecurity::Certificate)" 99009c9535dfa3e0d838989ccc7d84bfa2320ff4 "loplugin:unocast (sd::Annotation)" 0c7585c5fa78887e5459885ed744e8044fd76137 "loplugin:unocast (sd::TextApiObject)" 24e14afd1bfcaed6c200ab081973fba7e47267ca "loplugin:unocast (SignatureVerifierImpl)" 1a7ad0c10d286ce9ae2700ceb2fd50eed1fb43a4 "loplugin:unocast (pcr::PropertyEventTranslation)" a97e2d2702d9a6f37775ccee2c08c4f3b2479c4b "loplugin:unocast (RangePageBreaks)" 19dfdf86ad1f5b08041d8b7a9f196caf881231ab "iloplugin:unocast (pcr::OFormattedNumericControl)" f9785ea595fd8e911f6370e836fa579225b9e571 "loplugin:unocast (frm::OInterfaceContainer)" 5e5f40a4a92a31b0932c690219d002fcf18598cf "loplugin:unocast (ScVbaShapes)" 27b35b2c215b4832d4378ec3a7ecbba926552d06 "loplugin:unocast (ScVbaShapeRange)" cb3108f860065928552a86cf8acc4b3a95718ecf "cid#1517812 Dereference null return value" feba0ddb1521d1142560fe54b7d7696ee910237f "loplugin:unocast (weld::TransportAsXWindow)" 4d6c23216559eb48f9943bb49d6e475a6d64ba15 "loplugin:unocast (oox::ForumlaImExportBase)" 4844c096a8ab6a9a620c410a0949d4499f12a504 "loplugin:unocast (cairocanvas::SurfaceProvider)" 9a0b523e0a84d403b9092176ccec4b3e3efe42d0 "loplugin:unocast (cairocanvas::CanvasBitmap)" 8a5648d8e59b4b007dbbf3824777c19a21efc61e "loplugin:unocast (cairocanvas::TextLayout)" 28c27a0623bc78a0590858f97d03b620985bc84c "loplugin:unocast (cairocanvas::CanvasFont)" 53bc223cb3288e32a417696ee61c29e5f01f209d "loplugin:unocast (cairocanvas::RepaintTarget)" 5f70b0b9f6bc4ab145ddbd9155590ed4a3b1b9ec "loplugin:unocast (SvXMLImport)" 068187a898cdd2e26e9b16c348ecc1ed2dee3f29 "loplugin:unocast (VCLXWindow)" 88b4f966202717cd4ad38a30a8eda22c3e69ed35 "loplugin:unocast (sfx2::sidebar::SidebarController)" f1b7a69b280aefe2f1b3b0f32193494fd765f2bd "loplugin:unocast (SvxLineStyleToolBoxControl)" ba76f0ba7e8de4d2953739c952004b7d9af47197 "loplugin:unocast (i18npool::Calendar_gregorian)" 840154daf934d8df52ead1cb7acd798c4d30f007 "loplugin:unocast (framework::AddonsToolBarWrapper)" b0e9c4c5f063cefa9557810e3349bdb9c7493091 "loplugin:unocast (GrammarCheckingIterator)" 8ee6cfc9655ce9de4617cea1a0d9cb9d7a4fbfac "loplugin:unocast (ucb::ucp::ext::Content)" 5b8cd77c112bc8c0e92b8fec215c3c8e802bbc0a "loplugin:unocast (basic::SfxScriptLibraryContainer)" 9e73ff9fce12e102bb3c3cea8d8bb96c88f2c9ad "loplugin:unocast (sdext::presenter::PresenterNotesView)" a98acca8fbc38d3fd5600ae5056a8e42b6d8a40d "loplugin:unocast (SelectionChangeHandler)" c0b59ad6e35b0cb0dea0821e95f95569739078c1 "Consistently use comphelper::getSomethingImpl<I>(aIdentifier, this)" 276e3ccbdd3259ec3daf8a1a98fa7f406b14e21c "loplugin:unocast (vclcanvas::RepaintTarget)" Change-Id: I37c73e3422a5154bf6cb647640d2d3f23db8bc34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145063 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-03docx: Preserve w15:appearance SdtPr attributeofftkp1-0/+12
Now roundtrips the w15:appearance value which dictates whether there's an effect when hovering a placeholder. Change-Id: I3c911a0cfe31e235b9d981bbff0c1bb5827a85ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144845 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-01-01sw: read theme from OOXML file and set it to the draw pageTomaž Vajngerl6-3/+139
This change extends writerfilter to use oox::ThemeFragmentHandler to read the theme properties, and sets that to the one and only draw page of a Writer document. This change also removes ThemeTable and replaces it with the ThemeHandler, which takes theme font data from svx::Theme instead. In addition, a test has been writen, which loads a document with a theme, and asserts the draw page has the theme and the theme properties currently supported. Change-Id: Iff0048cd21ea030ac55287707852acc463ec3cb0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143699 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-12-19loplugin:unocast (oox::ForumlaImExportBase)Stephan Bergmann1-1/+2
(See the upcoming commit introducing that loplugin:unocast on why such dynamic_casts from UNO types are dangerous.) Change-Id: I11bc363447c44319bc47f7eebb7084f64ea85511 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144400 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-18Combine oox::FormulaIm-/ExportBaseStephan Bergmann1-2/+3
The original classes were both only used as base classes of SmModel, and combining them will make it easier to replace the existing dynamic_casts to those classes with XUnoTunnel. (And see the upcoming commit introducing loplugin:unocast on why those dynamic_casts are dangerous.) Change-Id: I4b1e0594fb202e3423d57db6457aa0e1b1b0b612 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144353 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-16Revert "fix math export/import in docx/rtf"Stephan Bergmann1-5/+2
This reverts commit 2b5953a19e36a02040f2ff08bc87efe4785f80bd. Whatever that "gcc4.4 (and 4.3 and possibly older) have a problem with dynamic_cast directly to the target class" issue actually was: For one, our GCC 7 baseline presumably would no longer have such an issue. And for another, the added asserts that the results of the dynamic_casts must be non-null were presumably all bogus (and have in part been reverted again in the meantime), as all the sources are UNO interface types that can presumably point at implementation objects of other than the expected C++ class types. (Those dynamic_casts from UNO interface types will be addressed in a follow-up commit. See the upcoming commit introducing loplugin:unocast on why such dynamic_casts are dangerous.) Conflicts: sw/qa/extras/ooxmlexport/ooxmlexport.cxx sw/qa/extras/rtfexport/rtfexport.cxx sw/source/filter/ww8/docxattributeoutput.cxx sw/source/filter/ww8/rtfattributeoutput.cxx writerfilter/Library_writerfilter.mk writerfilter/source/ooxml/OOXMLFastContextHandler.cxx writerfilter/source/rtftok/rtfdocumentimpl.cxx Change-Id: I0c330a3541e64ce08bfe30ff15d51a2fd8a243b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144336 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-14tdf#151548 sw content controls: preserve tabIndexJustin Luth1-0/+4
This has to be vital to keyboard navigation. Certainly it is good to have it imported before we start to consider tab-movements for form controls. All tabIndex 1's are processed (in placement order) and then the 2's etc. 0's are to be done last. XML_TAB_INDEX already existed in include/xmloff/xmltoken.hxx and "tab-index" already exists in xmloff/source/token/tokens.txt make CppunitTest_writerfilter_dmapper CPPUNIT_TEST_NAME=testSdtRunRichText make CppunitTest_sw_ooxmlexport17 CPPUNIT_TEST_NAME=testDateContentControlExport make CppunitTest_sw_core_unocore CPPUNIT_TEST_NAME=testContentControlDate make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlExport make CppunitTest_xmloff_text CPPUNIT_TEST_NAME=testAliasContentControlImport No existing unit test found containing blockSDT with tabIndex. Change-Id: I8a958844e6192b079a2b22a62dedfd8739021f4a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143603 Tested-by: Jenkins Reviewed-by: Justin Luth <jluth@mail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-12-10tdf#152203 DOCX import: fix mixed footnotes/endnotesLászló Németh1-0/+1
Footnotes (like endnotes) were imported in the order of their w:footnote elements in footnotes.xml, resulting mixed footnote text content during loading documents exported from Google Docs. Import them in the order of their w:id attributes. Regression from commit 9b39ce0e66acfe812e1d50e530dc2ccdef3e1357 "tdf#76260 DOCX import: fix slow footnote import". Change-Id: I7d9ed36fe96b2b90c4d62fb1ca7201318581775d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143824 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2022-12-09Fix typoAndrea Gelmini1-1/+1
Change-Id: I96297815043ea213f67d0ccc4224b12d7bcf7d36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143887 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-12-09tdf#143311 offapi,oox,writerfilter,xmloff,sw: decorative flag on flysMichael Stahl1-3/+29
* sw core RES_DECORATIVE as a FRMATR * sw API SwXFrame property "Decorative" * UI checkbox "Decorative" * ODF import/export as loext:decorative on draw:frame * DOCX export * DOCX import - very non-obvious how to get it from model.xml to dmapper * PDF/UA export: tag flys with this flag as Artifact * test for DOCX filters, ODF filters, PDF export Change-Id: I1ceb67fdd4e1cfa212aafdeb1c5f4ccd873d433e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143815 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-11-30tdf#152289: implement external glossary relations roundtripMike Kaganski2-84/+83
Change-Id: I20f4439abfbf73485734fd8373fffb2916d390f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143470 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-11-24tdf#151954 DOCX import: fix text moving before paragraph endLászló Németh1-0/+2
Tracked text moving before paragraph end was extended to the paragraph end, too. Follow-up to commit 11071d95f4f3cbe578c3393729c42b7cce011b45 "tdf#149711 sw_redlinenum DOCX: import moveTo paragraph mark" and commit d32d9a2b3c5e3963f4a18f6c7bbf50fab2e9b2be "tdf#123460 DOCX track changes: moveFrom completely". Change-Id: I668a3ef83482bded9ab94dcd0111f8ed05e8471c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143231 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2022-10-13tdf#149840 Use actual outer size for SmartArt in WriterRegina Henschel1-1/+37
SmartArt import needs the outer size of the diagram for to define a background shape in the correct size and calculate the size of the diagram shapes relative to the outer size. The patch passes the values read from wp:extent in writerfilter to DiagramGraphicDataContext in oox. Change-Id: Ib39227bc645ac353336bab2c558d041974188f6f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141223 Tested-by: Jenkins Reviewed-by: Regina Henschel <rb.henschel@t-online.de> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-10-11Deduplicate O(U)StringConcatenationMike Kaganski1-1/+1
And use an overloaded helper function with a better (?) unified name to show that the result is not an O(U)String. Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-08-18Move tools/diagnose_ex.h to comphelper/diagnose_ex.hxxStephan Bergmann1-1/+1
...so that its TOOLS_WARN_EXCEPTION can be used in comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it, rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The comphelper module is sufficiently low-level for this immediate use case, so use that at least for now; o3tl might be even more suitable but doesn't have a Library until now. Also, for the immediate use case it would have sufficed to only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION, TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of include/tools/diagnose_ex.h into an additional new include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move the complete include file as is.) Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-16 12:44:03 +0000