summaryrefslogtreecommitdiff
path: root/oox
diff options
context:
space:
mode:
Diffstat (limited to 'oox')
0 files changed, 0 insertions, 0 deletions
generated by cgit (git 2.34.1) at 2025-01-15 13:41:28 +0000
ld never fail; in fact, that used to always return an empty graphic. The problem was filed as tdf#163064, and the test was modified accordingly. Commit 5d997c029e53c31a3651a08f5012645097cec48f (sw XHTML export: improve dummy OLE object handling, 2018-08-30) made ReqIF export handle missing replacement graphic. However, it had assumed that SwOLENode::GetGraphic always returns a valid pointer even for the missing data. That is fixed here in OutHTML_FrameFormatOLENodeGrf. Other places, where the pointer was dereferenced unconditionally, were fixed (keeping current behavior). Change-Id: Ica97a691ecc11b856bdb003f89467ea3392684bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173716 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2024-06-01loplugin:ostr in sw/../filterNoel Grandin Change-Id: Ia1a96f966324e37cea55bd093f8fdbd9d9f99c07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168330 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins 2024-03-11Use weak reference to SfxObjectShell in SfxEventHint to avoid use-after-freeMike Kaganski The events may be processed after the shell has been destroyed. This is happening reliably after commit e2bfc34d146806a8f96be0cd2323d716f12cba4e (Reimplement OleComponentNative_Impl to use IGlobalInterfaceTable, 2024-03-11) when controlling LibreOffice from external Java scripts; but obviously, it could happen before as well. Now SotObject inherits from cppu::OWeakObject, instead of SvRefBase. Change-Id: I73a3531499a3068c801c98f40de39bdf8ad90b2b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164458 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2023-11-29Extended loplugin:ostr: swStephan Bergmann Change-Id: Ie3ceb8d4b939a652d09cc9cf02b78e65093c8fcf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160099 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> 2023-11-19Extended loplugin:ostr: swStephan Bergmann Change-Id: I210f61f6d90776b086b7058fb1a831d235699fb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159670 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2023-04-10Drop SvStream::WriteCharPtrMike Kaganski WriteOString is a better replacement Change-Id: Ic431b9aeb98d19fe61cff71360eee555105cc2bf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150192 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> 2022-08-30sw reqif/xhtml export: fix invalid pixel formats of graphics exported as OLEMiklos Vajna When exporting a Writer document to reqif-xhtml in ExportImagesAsOLE mode with something like: soffice.bin --convert-to 'xhtml:HTML (StarWriter):{"XhtmlNs":{"type":"string","value":"reqif-xhtml"},"ExportImagesAsOLE":{"type":"boolean","value":"true"}}' test.odt images are exported as ms paint ole objects instead of plain images. This happens in WrapGraphicInRtf(), using GraphicConverter::Export() where we just specify we want a BMP output. This usually works, but not when the bitmap format is something exotic where we try to keep that format in BMP, but ms paint can't handle it. When this happens, we get an RPC_E_SERVERFAULT error from OleRun() in OleComponent::RunObject(), which doesn't say much, except that ms paint failed to read the byte array we handed out. Fix the problem by ensuring that if a graphic is exported as OLE data, then it always has the 24bit pixel format. Interestingly a 8bit BMP can be opened in ms paint manually, but not when embedding it as OLE object. Change-Id: I2285bf67c4528cde208ae9fba42ece56822f5403 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139044 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2021-09-07Avoid repeating the return type from the declarationMiklos Vajna Change-Id: I0dce02d10b8c74e80f5672e2dd580b6837ba3291 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121732 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2021-06-14sw XHTML/reqif export, OLE data for transparent images: avoid black backgroundMiklos Vajna Once a semi-transparent images is exported to reqif in OLE mode, the native data is 24bit BMP. This needs some solid color as a background for the transparent pixels. The OLE presentation data had white, the OLE native data had black, so this was inconsistent. Fix the problem by going with white for the native data as well. Change-Id: I1b5e9ed37369b541425cfcd7f690e1b0bba97ddc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117144 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> 2021-05-28sw XHTML / reqif export, RTF markup of images: write OLE1 presentation dataMiklos Vajna With this, images are exported as PBrush OLE objects, to please some consumers (e.g. IBM Doors). Change-Id: I89805cd66709d96cbe71853d65671f76a3fc871f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116348 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2021-05-27sw XHTML / reqif export, RTF markup of images: write objdataMiklos Vajna The native data is BMP, presentation data is not yet done. Change-Id: I30ef9f0c3b4dc7801e600ac751c32179372d5e4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116266 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2021-05-27Fix typosAndrea Gelmini Change-Id: I9a4ba6b6369da0bac489718230880b04912bd1d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116214 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr> 2021-05-26sw XHTML / reqif export, RTF markup of images: write WMF in \pictMiklos Vajna Some consumers (e.g. IBM Doors) can only consume the RTF snippet if it's an OLE object and can't deal with plain images. Wrap \pict inside \object and unconditionally use WMF as the RTF-level preview format. The actual \objdata is not yet written. Change-Id: I203fcd8709b25a4dd543047bd804af8181df9940 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116207 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2021-04-29sw html/reqif export: fix size of presentation data for "real" OLE2 embeddingMiklos Vajna InsertOLE1Header() can either take its OLE1 presentation data (preview) from OLE2 or from RTF (SwOLENode). The presentation data size we wrote was incorrect in the OLE2 case case: nPresentationData is the RTF size, nBytes is the actual buffer size. In practice this made the embedded object non-editable in Word (when trying to edit the RTF fragment). This went wrong in commit 0d027abbc5609b096d2a954e77aa7354a55928ab (sw reqif-xhtml export, embedded objects: take OLE1 pres data from rtf if needed, 2020-09-02). Change-Id: I89019202c9a8b40c1b9a21f611f1190fd50073a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114889 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2021-04-16sw html/reqif export: fix size of embedded objectMiklos Vajna We used to write the size of the underlying OLE object, which may or may not match the user-configured size. The PNG preview was correct, which works with the size from the SwFormatFlyCnt ("as-char formatting"). Do the same when writing the "object size" (i.e. \objw and \objh in the RTF snippet). Change-Id: I7e240c1e115846c17b0945376b0de02d19769100 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114197 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2021-04-08embeddedobj: fix lost native data when updating it via OLE failsMiklos Vajna How to reproduce the problem: 1) Create an ODT file which has an OLE object, where the native data is an OLE2 container, containing a Package stream, containing a DOCX file. 2) Install some external application on Windows which registers itself as a handler for the DOCX CSLID [ this is where writing a testcase for this bug is challenging ]. 3) Open this document via Java, using URP. Load the document with Hidden=true and OnMainThread=true. 4) Dispatch .uno:UpdateAll 5) Save the document using XStorable.store() Expected result: the native data is there. Actual result: the native data is sometimes missing (0 bytes). Typically happens at least once if you perform the steps 4 times in a row. The root cause is that GetUserClassID() Win32 API fails in some cases, and re-trying a few times after a small sleep doesn't help. Handle this error better by detecting this situation in OleEmbeddedObject::SwitchOwnPersistence() and reusing the old native data, similar to how svt::EmbeddedObjectRef::GetReplacement() updates the preview image in a transactional way (only delete the old one when we have a one one). Finally, detect a broken OLE2 preview during reqif export, this way the reqif export result's embedded object is editable in Word, while \objdata was simply empty previously. Change-Id: I4dd34ebe6ad892a14cdcfb82acc82d9edf790fb3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113814 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2021-03-17sw reqif-xhtml export: make sure OLE1 preview is WMF-onlyMiklos Vajna reqif-xhtml has previews for embedded objects at 4 levels: - png preview - RTF preview - OLE1 preview - OLE2 preview The OLE1 preview has to be a WMF one, and in case our WMF export tries to inject EMF into it, Word will refuse to open the embedded object. So add a new flag to allow opting out of the EMF embedding for reqif-xhtml export purposes. The other option would be what Word does to just omit the OLE1 preview, but then this would break reqif-xhtml consumers who take the preview from the OLE1 data. Change-Id: Ia8d4626aefb6309743c9f4023f289c9a7b872035 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112648 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2021-01-20ofz#29691 revert throw SvStreamEOFExceptionCaolán McNamara reasonably sane code like s.ReadUInt32(a).ReadUInt32(b).ReadUInt32(c).ReadUInt32(d); if (s.good()) // use a, b, c d; stopped working. FWIW on a short read we retain whatever was in the variable before the read, rather than overwrite it with new random data, so sal_uInt32 a(0xdead); s.ReadUInt32(a); assert(s.good() || a == 0xdead); the msoffice ppt/escher/xls/doc filters especially speculatively parse and rely on a variables preinit value in the case of a short read. commit b345a2bab0d6f981049951a86b172ce49ce7d4c2 cid#1470786 Uncaught exception commit 71aec4726a94dcde1169fd293dbecfeb0e840e6d ofz#29528 uncaught exception commit bed03603f6cae264abb9e5b58aa2ab00448d92ff ofz#29414 uncaught exception commit 684885a99a1eb7ad943e9736166d4bb1468663be ofz#29443 uncaught exception commit 93574ac7768d247ed754ecda322e54e4bd447e43 ofz#29251 Abrt commit 413db68d95bd39d34e6a6b81a7c5c9478ced0514 ofz#29152 short read commit f400e883044143f999c460375a293647b4a57244 ofz#29151 short read commit 96ea80a725dfe4ef38993f78917c243f13e3beb5 ofz#29129 Abrt on uncaught exception commit 646a635efe6eecbc3d1dd3a7cbb02a278c6f3be5 ofz#28931 Indirect-leak commit b0e573f18629d28fe3179c12d0d434653f92fc93 ofz#29030 Abrt in xlsfuzzer commit 95407c39168d186ee44e67b1a6a4bcf592c58b84 ofz#28902 uncaught exception commit 45175d655ad3773df1c006182108cf25e87b1091 oss-fuzz: tgafuzzer doesn't pass sanity check commit b82fc702bae9d6190bda1b4818a47cfa197df6d8 oss-fuzz: psdfuzzer doesn't pass sanity check commit e7c76d604a4694e6568bf10c2a06a786f1096319 oss-fuzz: epsfuzzer doesn't pass sanity check commit 901e5e7c9170184e286ea3e46fce406136aa9572 oss-fuzz: xlsfuzzer doesn't pass sanity check commit 127bfab61c297df06fd8e71e709bc4362cb89d21 oss-fuzz: pngfuzzer doesn't pass sanity check commit 77387ae00ae27e3f8bcdf7bccf97fb2db8f196b7 oss-fuzz: mtpfuzzer doesn't pass sanity check commit 974ffa79b0fef4ca76558bb8b16bce84af3aaf6c oss-fuzz: xlsxfuzzer doesn't pass sanity check commit 6d6d104cbb382d0045e1f04b12d268992fa5c624 oss-fuzz: bmpfuzzer doesn't pass sanity check commit a7d1d107ec58d3b00b4019c89edddcff71ca6ff3 oss-fuzz: qpwfuzzer doesn't pass sanity check commit 898993aa62276f59480df8af1da4bad530829b56 oss-fuzz: pcxfuzzer doesn't pass sanity check throw/catch parts of commit 8c9a4ff511a3b1d84a7a6d08a1b153c07f164abb throw exception in SvStream when reading past end of file Change-Id: Ic49c249768b17b64d8e868655dbc05b31906c2e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109621 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Caolán McNamara <caolanm@redhat.com> 2020-12-27ofz#28918 Direct-Leak in SotStorage::OpenSotStreamCaolán McNamara Change-Id: I2d99a13822b07d98e03d7e7de91ca44ab4f8599d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108266 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> 2020-12-18throw exception in SvStream when reading past end of fileNoel to avoid chasing weird problems where we read past the end of file, which leads to random data in the variable we read into. I expect a couple of possible regressions from this change (1) memory leaks caused by non-exception-safe memory handling. Of which there should not be much because we're pretty good about using smart pointer classes these days. (2) Broken files which used to load, will no longer do so. These will have to be debugged by putting a breakpoint on the SvStreamEOFException constructor, and examining the backtrace to see where we should be catching and ignoring the exception to make the code continue to handle such broken files. Change-Id: I351be031bb083a3484a9a1b650a58892700e6fb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105936 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2020-10-20sw reqif-xhtml export, embedded objects: handle non-package Ole10Native streamMiklos Vajna Commit 1392fd6a7eaf9f507639096984c2a0108f254795 (sw reqif-xhtml export, embedded objects: handle Ole10Native stream, 2020-04-30) added support for handling an OLE1 stream which contains something other than OLE2 data. However, that assumed a fixed class name ("Package") and a matching class id. Fix this, similar to how the import side was fixed with commit 247b247dadc8f0133a8eb94f1423a29315cf998a (sw reqif-xhtml import, embedded objects: handle non-package Ole10Native stream, 2020-10-16). Change-Id: If2ec9434c802e23e395cf2a6eaf63ad5b1db9c1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104531 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2020-10-06loplugin:const* make some params and methods constNoel Change-Id: I3c8ca72b2b41a4f82ee20cbe025b41425f32e715 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104028 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2020-09-02sw reqif-xhtml export, embedded objects: take OLE1 pres data from rtf if neededMiklos Vajna Next to the native data of an embedded object, the presentation data / replacement is included at several layers: - the OLE2 container may have it - the OLE1 container may have it - the RTF container may have it - the PNG file next to the RTF container may have it Given that various consumers pick one of the above, we try to provide presentation data in all layers. We already had code to generate the OLE1 presentation data from the OLE2 container, but we gave up for OLE1 in case the OLE2 container didn't have it. This means that in case the RTF container is wrapped in a proper RTF file, Word refuses the edit the embedded object. Fix the problem by taking the presentation data from RTF for OLE1 purposes, in case it's missing from the OLE2 container. Change-Id: I158db1c87044a3895d0c64a6e5a5384686627d96 (cherry picked from commit 5c37f5713a5b9e14fcc378d91e5ed8d40edc40a4) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101946 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2020-09-02sw reqif-xhtml export, embedded objects: prepare pres data earlierMiklos Vajna If an embedded object has some native data, we provide presentation data (replacement graphic) for it in the OLE1 container. We usually take this from the OLE2 container, but it's OK to omit the presentation data there. So refactor to have the presentation data available from the OLE node (already used for RTF purposes) earlier, that'll allow taking the OLE1 presentation data from RTF if it's missing from OLE2. Change-Id: Ib6b1b5e843308b0f7af04499de5a1ef5461f7b00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101840 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2020-04-30sw reqif-xhtml export, embedded objects: handle Ole10Native streamMiklos Vajna Normally the embedded object has some OLE2 native data, and we insert our OLE1 header before that. But in case the OLE2 data already has an Ole10Native stream, then don't create an OLE1-in-OLE2-in-OLE1 output: it's pointless and some consumers have trouble parsing that. Change-Id: Ifc8b37494f97da89ce66a147e08a49eaa2f7ae1e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93200 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins 2019-10-10convert WriteCharPtr..getStr to WriteOStringNoel Grandin and improve the WriteOString method, we can avoid the strlen here, we already have the length One change in behaviour to be noted - if the string contains trailing zero bytes, which ARE INCLUDED IN THE STRING LENGTH, i.e. I'm not talking about the normal terminating zero, then this patch changes behaviour because we will now write those zeros to the stream. Change-Id: I4668b9b9eb877f820b1dc70d6cd10ba2623bc0a2 Reviewed-on: https://gerrit.libreoffice.org/80597 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2019-10-10fix zero at end of string in ExtractOLEClassNameNoel Grandin this only worked by accident, because the only use of the string was to pass it to SvStream::WriteOString, which stops at the null byte Change-Id: Ief06db7b9c79943826da7bf377144e5244d328ee Reviewed-on: https://gerrit.libreoffice.org/80617 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>