summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-12-18sw reqif-xhtml import: add a new AllowedRTFOLEMimeTypes parameterMiklos Vajna9-1/+1087
The HTML import is an old-style filter, so it has no XFilter implementation where filter() would get custom parameters out of the box. One way would be to fix by adding one more entry to the aFormalArgs table under sfx2/, but doing that with a random parameter of a random import filter feels dirty. So instead make SfxMedium store all arguments as-is, this way accessing other keys is as easy to accessing the already available FilterOptions (string) key. Regarding the actual filter change, don't require "text/rtf" as a mime type for embedded objects in the reqif XHTML import, so that in case the file has e.g. application/rtf, then that works as well. In case an (UNO) client wants to still limit the accepted set of MIME types, that's possible via the new parameter. (cherry picked from commit e0f20211a8048a87b078aa4cf0f28c0c847487ad) Conflicts: include/sfx2/docfile.hxx sw/qa/extras/htmlimport/htmlimport.cxx sw/source/filter/html/swhtml.cxx [ Backport note: master uses std::set for m_aAllowedRTFOLEMimeTypes, here we use std::vector, as comphelper::sequenceToContainer() can't handle sets on this branch. And given that the elements in this container will be small, it does not matter in practice. ] Change-Id: Ia60da44d692f550d8ad5bbf374171cac67d9e04f
2019-11-25cui: add UI for semi-transparent shape textMiklos Vajna6-2/+150
- Make font color only work with the RGB color, otherwise the preview would be white for e.g. half-transparent red. - Add label and widget to see already set transparency. - Add a flag to show these only for Draw/Impress and leave Writer/Calc unchanged. - Update returned item set to contain transparency in case the widget changes. Conflicts: cui/source/inc/chardlg.hxx cui/source/tabpages/chardlg.cxx cui/uiconfig/ui/effectspage.ui Change-Id: If77771076ff4b10a4a5d468a6583809a94deb57e
2019-11-25oox: add PPTX import/export for semi-transparent shape textMiklos Vajna7-2/+167
And start a drawingml test suite in oox, so the test and the tested code is close to each other (just like how it's done in chart2/ already). (cherry picked from commit 1e64d9ebaa231caef5fb062009b8f76465e415f4) Conflicts: oox/Module_oox.mk Change-Id: I9a2810691f12604d240e4394e6a5ff4e7f52f1c1
2019-11-25xmloff: add ODF import/export for semi-transparent shape textMiklos Vajna3-0/+90
Test this from sd, so that SdModelTestBase::saveAndReload() calls BootstrapFixture::validate() for us. (cherry picked from commit 4dbb33a1c21948bebcf890c2f8ceb56b15a87936) Conflicts: schema/libreoffice/OpenDocument-schema-v1.3+libreoffice.rng sd/qa/unit/export-tests.cxx Change-Id: I6c90a3a71a5603604e69f9b45137bc8e4388dc0f
2019-11-25svx: add rendering for semi-transparent shape textMiklos Vajna1-0/+10
The color's alpha is normally lost when we roundtrip SvxColorItem's tools Color via TextSimplePortionPrimitive2D's basegfx::BColor. One way would be to add an extra transparency member to the primitive, like BackgroundColorPrimitive2D does that. However, a much easier way is to go via UnifiedTransparencePrimitive2D, that way we handle transparency in drawinglayer::impBufferDevice::paint(), rather than platform-specific code like CairoTextRender::DrawTextLayout() in the Linux case. (cherry picked from commit 81b0d5393ca4cf2ff0954e53b05928cde047c2e0) Conflicts: svx/CppunitTest_svx_unit.mk svx/source/svdraw/svdotextdecomposition.cxx Change-Id: Ie7aebe77ad9ac776dd27fc50538a5045200c8010
2019-11-22editeng: add UNO API for semi-transparent textMiklos Vajna4-2/+14
Keep the type internally as sal_uInt8, to be used as an alpha channel. Keep the type externally as sal_Int16, so it's consistent with the fill area transparency. (cherry picked from commit 6fafae4d109f5768621a11deb394b1b0c4dc5606) Conflicts: offapi/com/sun/star/style/CharacterProperties.idl Change-Id: I5138a6b73526f20a40f93df4cff4951e2b11bd6d
2019-11-22editeng: add doc model for semi-transparent textMiklos Vajna2-8/+42
tools Color can handle the alpha just fine, but add a separate member ID for transparency to be consistent with the existing border and fill color API. (cherry picked from commit 543a0658f961f24db6804b90c5389aee15ba2ce4) Conflicts: editeng/source/items/textitem.cxx include/editeng/memberids.h Change-Id: I8466da9fb40ab1d0c97b06a0594f89719ccc1959
2019-11-08sw XHTML export: <blockquote> can't have character childrenMiklos Vajna2-7/+38
Fixes the following reqif-xhtml validation error: ERROR at 214: [XSD] cvc-complex-type.2.3: Element 'reqif-xhtml:blockquote' cannot have character [children], because the type's content type is element-only. But this is probably useful in the general xhtml case as well. [ Also add a way to not load a document when we want to cover "store" behavior in a test. ] (cherry picked from commit f2eae41e9a85cd1df4190160b7453d3e12b8ccbd) Change-Id: I88795271475863b9560ac1cb99636c507746f1e9
2019-11-08vcl PDF export: fix re-exporting PDF images with page-level rotationMiklos Vajna1-2/+30
PDF images are effectively 1 page PDF documents. The page object may have a /Rotate key, which was simply ignored before. We turn page objects into form XObjects on PDF export, such rotation can be expressed with a /Matrix key. Add support for the 90 degrees rotation case, this can be generalized later if wanted. (cherry picked from commit bd520b177637d4b7d9d93733103cff17a3c91b0a) Conflicts: vcl/qa/cppunit/pdfexport/data/pdf-image-resource-inline-xobject-ref.pdf vcl/qa/cppunit/pdfexport/pdfexport.cxx Change-Id: I55a4f63e0b986637ccdeba0b783f1db9a85c4d93
2019-11-08vcl PDF export: fix re-exporting PDF images for dict obj resource sub-keysMiklos Vajna1-1/+16
Re-exporting PDF images works by tokenizing the PDF image, identifying which PDF object is the page object and then copying that over to the PDF output, together with the dependencies of that object. This involves copying the resources of the page object. Previously we assumed that the sub-keys of the resources are always inline dictionaries, but the bugdoc shows that they can be references as well, which point to dictionary objects, so add support for this scenario. (cherry picked from commit adcdd56471f1cc10ff4135975ecadb3a703db6ad) Change-Id: I78ee1c726e6ecd958232e9fab64773595e5b9c86
2019-10-11vcl, BitmapEx transformed draw: special-case simple rotationsMiklos Vajna2-5/+55
In case OutputDevice::DrawTransformedBitmapEx() has to do both shearing and rotation, then recording to a metafile is unchanged. But if we need to do rotation, then it's not necessary to go via transformations. This has the additional benefit that 90/180/270 degree rotations don't introduce an off-by-one error, where the first row and col of the transformed bitmap is transparent. (At the moment it's not clear what introduces the unwanted translation, but at least the direct Rotate() way resolves the visible end-user problem, see the test.) (cherry picked from commit 68549e00d5e23aa22bc974a8151d93cd948444b3) Conflicts: vcl/source/outdev/bitmap.cxx Change-Id: Ie1adbdb2221b086c19cc66f69308b6b7256fe29a
2019-10-11vcl: only smooth bitmap transform when neededMiklos Vajna1-0/+33
If you have a very small bitmap and you rotate it by 90 degrees, then smoothing is not needed, but the result will be blurry. So in case scaling / shear doesn't need it and we do 90/180/270 rotation, avoid smoothing. (cherry picked from commit 55b4d5ea9e1a42edf71d2eef6028830983dbc11c) Conflicts: vcl/qa/cppunit/BitmapExTest.cxx vcl/source/gdi/bitmapex.cxx Change-Id: I4b8fad4b0b70516d35eaecfa70a707e6e8362d18
2019-10-11vcl: avoid downscale && upscale in DrawTransformedBitmapEx()Miklos Vajna3-1/+48
If we rotate a bitmap and put it to a metafile, we'll create a MetaBmpExScaleAction. But just because we need to store a transformed bitmap for rotation purposes, it doesn't mean we also need to scale it. This helps in case later the metafile is upscaled and the downscaled bitmap would look blurry. (cherry picked from commit dd4a67084853a030bf4b9f1f85d728620e0604a5) Conflicts: vcl/qa/cppunit/outdev.cxx Change-Id: I7d64a88af460e80dffde8052186888eddbb440fe
2019-08-16embeddedobj: allow controlling if PDF documents are converted to Draw or notMiklos Vajna8-2/+104
This is a bit custom, since it's not a Microsoft filter. At the moment this affects only Insert -> Object -> OLE Object -> from file. Reviewed-on: https://gerrit.libreoffice.org/77520 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit bdfa6b678bc0cc22f983a0c23187a8ba9d2e6730) Conflicts: cui/inc/strings.hrc cui/source/options/optfltr.cxx cui/source/options/optfltr.hxx Change-Id: If79602742a533db1b04e11a90890f8768186046d
2019-08-16embeddedobj: allow controlling if Visio documents are converted to Draw or notMiklos Vajna10-5/+90
At the moment this affects only Insert -> Object -> OLE Object -> from file. Reviewed-on: https://gerrit.libreoffice.org/77489 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 5827e30109b683cb74efa21d154e5219fe9e2a0c) Conflicts: cui/inc/strings.hrc cui/source/options/optfltr.cxx cui/source/options/optfltr.hxx include/unotools/fltrcfg.hxx officecfg/registry/schema/org/openoffice/Office/Common.xcs unotools/source/config/fltrcfg.cxx Change-Id: I8d1c6456481610491916e3be3766b0bb04dfa296
2019-08-16embeddedobj: add initial CppunitTest_embeddedobj_generalMiklos Vajna4-0/+140
Fails with commit 88afec70112c95a016e92e26c1d06d7dd002e4e8 (embeddedobj: respect config for Insert -> Object -> OLE Object -> from file, 2019-08-14) reverted. Change-Id: I64f81642260f6eab5a86219d94553f09b67b3555 Reviewed-on: https://gerrit.libreoffice.org/77461 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 85a7bc13fed5020441d772816d73a932f67ad377)
2019-08-16unotest: backport CPPUNIT_TEST_FIXTURE macro from cppunit.gitMiklos Vajna1-0/+15
Added upstream as <https://cgit.freedesktop.org/libreoffice/cppunit/commit/?id=48145587c4c2dc4f1e07d83073e136336c81ce79>. Reviewed-on: https://gerrit.libreoffice.org/62975 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit 20f84aa139e122733f215fc539dcbcdcfce18c81) Change-Id: If3adbad3187e3d2b4319be7b295b41d5b7e9c08d
2019-08-16embeddedobj: respect config for Insert -> Object -> OLE Object -> from fileMiklos Vajna2-0/+43
Tools -> Options -> Load/Save -> Microsoft Office has config options to decide that Word/Excel/PowerPoint formats are loaded into our doc models (default) or handled via external OLE applications instead. This is used in the MSO import/export filters, but in case the UI is used to insert a new file as an embedded object, then we ignored this setting, and the embedding type depended on if we found an import filter for the data or not (if yes, load it; handle externally otherwise). Fix this inconsistency by checking for the usual MSO import filter names and respect the existing configuration in those cases, so the user can choose to not handle these formats internally if wanted. Reviewed-on: https://gerrit.libreoffice.org/77449 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 88afec70112c95a016e92e26c1d06d7dd002e4e8) Change-Id: I6bce8b5467768ef3f21d97b4e0fe3f4d18d9466b
2019-08-16sw doc model xml dump: improve OLE node handlingMiklos Vajna3-3/+31
So it's possible to see if we have a dummy, common or OLE embedding. Reviewed-on: https://gerrit.libreoffice.org/77403 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit abf05ba7fc625d87190759d927f8776594840ea1) Change-Id: I8c241211a149ca5261fdf8171cd2814fced8de79
2019-08-06sw XHTML export: <sdfield> and shading is not relevant for ReqIFMiklos Vajna3-3/+25
See commit 4cd3c436923bfba281b1bf16d9785208a2119cea (sw reqif-xhtml export: limit values of the style attribute, 2018-04-11) for motivation. Reviewed-on: https://gerrit.libreoffice.org/76986 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 3166209cca8c8c76d4605eead12431fed2f1e306) Change-Id: I28aa239a1b02c8021879159e5591880804aa0825
2019-07-19sw: fix missing OLE preview for actively edited OLE object on saveMiklos Vajna3-0/+46
Regression from commit 74844277cc2194c9e43f5bd7a6f78a9603da32f3 (disable generation of ole previews in ODF format until after load, 2016-09-13), if the user started an OLE edit in a Writer document, and saved without ending the OLE edit, then svt::EmbeddedObjectRef::UpdateReplacementOnDemand() removed the old replacement image, but no new one was created. Given that save is always an explicit user action (auto-save does not kick in for unmodified documents), restore the permission to update OLE replacement images during save. Do this check in SwDocShell::CalcLayoutForOLEObjects(), as that's OLE-related and is called from all the relevant save code paths (save, save-as, convert to alien formats). Reviewed-on: https://gerrit.libreoffice.org/75867 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit d33cc4f7edc2ce21a9c5a01a7f5e85cfd324c6d9) Conflicts: sw/qa/extras/uiwriter/uiwriter2.cxx sw/source/uibase/app/docsh.cxx Change-Id: Idaad43909cd744a379e713efd70ffd000e2692bc
2019-07-19lok - chart - state switch issue triggers an OLE general error msg boxMarco Cecchetti1-15/+19
Reviewed-on: https://gerrit.libreoffice.org/50368 Reviewed-by: Jan Holesovsky <kendy@collabora.com> Tested-by: Jan Holesovsky <kendy@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/50482 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Marco Cecchetti <mrcekets@gmail.com> (cherry picked from commit a3646b25ac4c976b891d69759035345630c4f1a2) Change-Id: I6addd95d1ad3461b6e21328512cbd1301a36cd19
2019-07-19lok - add support for in place chart editingMarco Cecchetti1-1/+3
This commit add a minimal support for editing chart embedded in a spreadsheet or a text document or a presentation. Graphic objects can be moved and resized, text objects can be edited. Reviewed-on: https://gerrit.libreoffice.org/39342 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Marco Cecchetti <mrcekets@gmail.com> (cherry picked from commit eba883c8a2ce045fc7bd3848d796ca10b7f4ba51) Change-Id: I8e637dabf328a94bd6bb0e309a245302cff421d8
2019-05-31ODT export: fix lost <text:user-field-decl> for fields in frames in headersMiklos Vajna6-0/+31
This is similar to commit 6bb241ccc61c6904efec95978fa17e33c0eb1df3 (ODT export: fix lost <text:user-field-decl> for fields in tables in headers, 2019-05-29), but here the container we want to ignore (between the header and the field) is a text frame, not a table cell. (cherry picked from commit 6f179ce5c5469d1c53e4bb7736384b2d9ce51926) Conflicts: sw/inc/unoframe.hxx sw/source/core/unocore/unomapproperties.hxx Change-Id: I6e8006fbd666802070cfeb88ca4528c66cc6d559 Reviewed-on: https://gerrit.libreoffice.org/73205 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2019-05-30ODT export: fix lost <text:user-field-decl> for fields in tables in headersMiklos Vajna10-1/+71
The problem was that XMLTextFieldExport::ExportFieldAutoStyle() assumed that the text of a field anchor is always the toplevel XText, which is true in case of body vs header text, but false in case header text vs text-in-table-in-header. So add an UNO property which exposes the parent of a table cell, this way text in header (regardless of it's in a table or not) will have the same XText, leading to writing the necessary <text:user-field-decl> element for the matching <text:user-field-get> definition. (cherry picked from commit 6bb241ccc61c6904efec95978fa17e33c0eb1df3) Conflicts: offapi/com/sun/star/text/CellProperties.idl sw/inc/cmdid.h sw/inc/unoprnms.hxx sw/source/filter/xml/xmlfmte.cxx Change-Id: I077b8d7e9dfae4062539894318637e266b925382 Reviewed-on: https://gerrit.libreoffice.org/73176 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2019-05-30tdf#124503: Support JRE installations with unknown java.vendor propertyStephan Bergmann11-356/+190
After recent additions of 61c4f96d6ae6a80370774e53287edb27cbce8067 "Support AdoptOpenJDK" and 41507db590b24e1b9b45d95cad55c71ba2e4091d "Support Amazon Corretto" to our hard-coded list, there is now reports that at least Debian and Ubuntu tried to distribute versions of OpenJDK with the java.vendor propety set to string like "Debian" or "Ubuntu". Instead of trying to catch up with an ever-growing hard-coded list, it is probably better to stop relying exclusively on such a hard-coded list, and for unknown vendor values, try out whether the SunInfo backend (which supports the "generic" OpenJDK) would be able to handle the given JRE. (For simplicity, assume that any versions of such JREs are supported. Our baseline is Java 6, and there are unlikely any older versions of JREs from unknown vendors out there. If this turns out to be problematic, we could include information about problematic vendors after all, or add a general check that JREs from unknown vendors are at least Java 6.) Many functions in jvmfwk/inc/vendorplugin.hxx that used to take a set of sVendor/sMinVersion/sMaxVerison/arExcludeList paramters had to be revised to take a vendorSettings parameter instead, and VendorSettings::getVersionInformation has been changed to return a boost::optional, so that unknown vendors can be handled gracefully. Reviewed-on: https://gerrit.libreoffice.org/70460 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 3d27b2fa9c5a03f78e5145377402f8a88e3da1be) Conflicts: jvmfwk/plugins/sunmajor/pluginlib/vendorlist.cxx jvmfwk/source/framework.cxx (cherry picked from commit 90aa1f6e8070cadb26132e7187b47241004f26f8) Conflicts: jvmfwk/inc/fwkbase.hxx jvmfwk/inc/vendorplugin.hxx jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx jvmfwk/plugins/sunmajor/pluginlib/vendorlist.cxx jvmfwk/source/elements.cxx jvmfwk/source/framework.cxx jvmfwk/source/fwkbase.cxx solenv/clang-format/blacklist Change-Id: Ibf915f2ddd59e09b77e2c03be688cac0547b9ac9 Reviewed-on: https://gerrit.libreoffice.org/70587 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-05-30Silence bogus -Werror=clobbered (GCC 7 --enable-optimized)Stephan Bergmann1-0/+7
> In file included from gcc/include/c++/7.1.1/vector:69:0, > from jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx:39: > gcc/include/c++/7.1.1/bits/vector.tcc: In function ‘javaPluginError jfw_plugin_startJavaVirtualMachine(const JavaInfo*, const JavaVMOption*, sal_Int32, JavaVM**, JNIEnv**)’: > gcc/include/c++/7.1.1/bits/vector.tcc:407:15: error: variable ‘__new_finish’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered] > pointer __new_finish(__new_start); > ^~~~~~~~~~~~ Change-Id: Iefabac65871ed79bcfa333f0193fcbbd1369f7f1 Reviewed-on: https://gerrit.libreoffice.org/66714 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> (cherry picked from commit 58f30cf1fe401452c0297703fe08a9aa14bd55f3)
2019-05-30Use loop ranges in jvmfwkJulien Nabet4-71/+47
to simplify and avoid all the typedefs (cherry picked from commit 2ea531c0578bb7f0a34ec7de0aaea595e0387928) Conflicts: jvmfwk/plugins/sunmajor/pluginlib/gnujre.cxx jvmfwk/plugins/sunmajor/pluginlib/util.cxx Change-Id: Ia14337dd71b55fc24f162b5436af76aeeb8d2575 Reviewed-on: https://gerrit.libreoffice.org/43346 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-05-30clang-tidy modernize-use-emplace in hwpfilter..lotuswordproNoel Grandin3-8/+6
(cherry picked from commit 7ca4ea54b4d610104df1b88ae5b04c2081a4a429) Change-Id: Ic11634ca28396fd156390c511087bae03bd5fb70 Reviewed-on: https://gerrit.libreoffice.org/42156 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-05-30use more OUString::operator== in forms..salNoel Grandin4-12/+12
(cherry picked from commit 3697b87b70c69e17e1d0398e0192a11dab179fe3) Change-Id: I70d7e50f8c1e019524ccad915f0cca912c5035dc Reviewed-on: https://gerrit.libreoffice.org/39899 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-26sw: sync UNO API default for ToC link start char style with UIMiklos Vajna3-0/+125
The UI default is in the SwForm ctor, where the content type sets the link start char style to STR_POOLCHR_TOXJUMP. Have the same default in the UNO API in case the import filters don't set it explicitly, since that breaks clickable hyperlinks on PDF export. This also fixes the OSL_ENSURE() failure for missing character formats in SwTextINetFormat::GetCharFormat(). Reviewed-on: https://gerrit.libreoffice.org/71366 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 9c3e5875e827c04e6dc029bba1ac179eb2484c29) Conflicts: sw/source/core/unocore/unoidx.cxx vcl/qa/cppunit/pdfexport/pdfexport.cxx Change-Id: Ifff354d56a569614ca7f5a89dd75f41817300078
2019-03-25svtools: double the limit of max drawing page sizeMiklos Vajna2-6/+6
When I load an ODG document page, which is 5080 mm wide, then the UI told me that it's 300 cm wide, which was misleading. There is no real reason why the limit can't be higher, the draw page size is sal_Int32 and the unit is either twips or mm100s: in both cases sal_Int32 is more than enough to store the new limit still. Change-Id: Ifb501eed4e288281bcc73dce71bdb03ac213b0c1 Reviewed-on: https://gerrit.libreoffice.org/69673 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 9eb111333b7440fd166057a1c62840187aaf35a8)
2019-03-21sw: make ODT export of paragraph auto-styles deterministicMiklos Vajna7-16/+152
If a complex enough document is loaded into Writer and saved as ODT, then the content.xml's automatic paragraph styles (P<num>) are re-ordered on each save, which leads to unnecessary noise. The actual random order is created during import by the time we convert direct formatting (e.g. from HTML import) to autostyles, as StylePoolImpl::maRoot stores autostyles in a map that orders autostyle parents based on their pointer address. This has benefits like automatic ordering of item sets and fast comparison, so don't change that, but extend the svl API to also track the name of those parents. This way by the time StylePool::createIterator() would iterate over those autostyles, it can order the parents by their name, so two import->export runs will result in the same autostyle ordering. (This appears to be the only indeterminism in content.xml for a test HTML input, while meta.xml and settings.xml still changes all the time.) (cherry picked from commit eb128a7d6bbc27b4dbbf9461c81c90e40203b114) Conflicts: svl/source/items/stylepool.cxx Change-Id: I1cfcae2c664a5c5c3dee48be733046979c1593ed
2019-03-13sw HTML export, field shadings: give text portion background priorityMiklos Vajna5-2/+23
If the user explicitly gives a background color to the field portion, then respect that, don't overwrite with the field shading (the UI does the same). Change-Id: I7c35618f82a37ef1dd16c03b82651268767813af Reviewed-on: https://gerrit.libreoffice.org/69127 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit ce01727e4d6779ea128aa1be09f4af8cad4e1854)
2019-03-13sw HTML export: handle field shadings view optionMiklos Vajna5-9/+44
Regardless of the value of the View -> Field Shadings option, shadings were always lost when saving to HTML. Implement handling of this in the HTML conditionally, so in case that UI option is on, then shadings are preserved in the HTML result; disabling that option results in the old behavior, though. Reviewed-on: https://gerrit.libreoffice.org/69081 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 507ac9b8c20926de7479213cf2d890bbb5952a1d) Conflicts: sw/source/filter/html/htmlfldw.cxx Change-Id: I1bd19f4c6e22aff2f84fac25f0a506ad0127cc3c
2019-03-13sw doc model xml dump: show text node's field hintsMiklos Vajna1-2/+16
Change-Id: I17927231da389ce54d2fb8ade0091c7e7033a808 Reviewed-on: https://gerrit.libreoffice.org/69049 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 99f25bc344e931e66366e20664a23dc263fe3113)
2019-02-05sfx2: allow storeToURL() on the main threadMiklos Vajna2-6/+21
This is similar to commit f1e775470e68fb1ca1fee390c10064c55932180d (framework: allow storeSelf() on the main thread, 2019-01-30), just this handles "save as" instead of "save". The result is that combining this commit with the previous OnMainThread ones allows all of document load/save/save-as/command-dispatch on the main thread even when the action is invoked via remote UNO, which would run on a non-main thread by default. Change-Id: I7d50cceb66ecc6619fe25734107a2524ca872c2a Reviewed-on: https://gerrit.libreoffice.org/67412 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit b030e83fccbff8d82a4c84462075baa8442cde54)
2019-01-30framework: allow storeSelf() on the main threadMiklos Vajna1-2/+21
This is similar to commit 22aa6508e0a65e65a6f9410b498fe4fd6c236639 (framework: allow dispatching a command on the main thread, 2019-01-29), except it addresses the scenario where save is performed with an UNO API call, not with a dispatched command. This way both load and save is possible on the main thread, providing a safe way to interact with documents containing OLE objects on Windows. Reviewed-on: https://gerrit.libreoffice.org/67109 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit f1e775470e68fb1ca1fee390c10064c55932180d) Conflicts: sfx2/source/doc/sfxbasemodel.cxx Change-Id: I3516c944ece8ed0e26aa13fc9def5857b8344404
2019-01-30framework: allow dispatching a command on the main threadMiklos Vajna1-1/+23
This is similar to commit 2dc3a6c273cb82506842864481d78df7294debbf (framework: allow loading a component on the main thread, 2018-12-19), just it allows saving (via .uno:Save) and other commands operating in a similar environment. The use-case is that once a document is loaded on the main thread (see commit message of the above mentioned commit), then saving also has to happen on the main thread, or OLE objects on Windows may be lost. Reviewed-on: https://gerrit.libreoffice.org/67089 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 22aa6508e0a65e65a6f9410b498fe4fd6c236639) Conflicts: framework/source/services/dispatchhelper.cxx Change-Id: I7321659550b556e96085ac20f197a87d5d13f1ed
2019-01-25sw paste listener: expose pasted images as wellMiklos Vajna3-22/+84
Do it similar to SwXTextView::getSelection(), so that SwView::GetShellMode() determines when an image is selected (and otherwise assume text selection). Reviewed-on: https://gerrit.libreoffice.org/66879 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 2a054445f09e8ba66e7cfb9f1d598554b555772d) Conflicts: sw/qa/extras/unowriter/unowriter.cxx Change-Id: I717e1358428daba842309260b54f82b62a0aaec1
2019-01-24sw: make it possible to listen to paste eventsMiklos Vajna11-9/+328
The use-case is that the user pastes content and custom postprocessing is necessary for the pasted content. This is not easy by default, since the cursor is at the end of the pasted content, so the start is not known -- even if you intercept the paste UNO command. Precisely tracking the start is possible when using the internal API, SwReader::Read() does something similar already to track the undo range. Only expose the text selection after paste (as a start), but design the API in a way so that other pasted content type (e.g. image) can be added in a backwards-compatible way later. Reviewed-on: https://gerrit.libreoffice.org/66807 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit e14fafaafb3500d65be9c1b69fcb86b31d36468c) Conflicts: sw/qa/extras/unowriter/unowriter.cxx sw/source/uibase/dochdl/swdtflvr.cxx Change-Id: If35bda4244cc417e4858124fb75f7608b95fc556
2018-12-20framework: allow loading a component on the main threadMiklos Vajna1-1/+12
The user-visible problem was that embedded (OLE) objects contained in a document that was loaded on a thread were not editable. This works in the loaded-with-UI case because the Windows version of the SalData constructor in vcl calls CoInitialize() (which sets the concurrency model of the main thread to STA) and then later the OleComponent constructor in embeddedobj calls OleInitialize(), which just realizes that the concurrency model is already set, and OLE editing works. However, if the document is loaded on a thread, things are different. The concurrency model of the thread is set to MTA in oslWorkerWrapperFunction() in sal, so the later OleInitialize() will fail with RPC_E_CHANGED_MODE, as it's not possible to set the concurrency model of a thread once it's set. Solve the problem by providing in opt-in way to execute the actual import on the main thread, since remote UNO clients always invoke Desktop::loadComponentFromURL() on a thread. Change-Id: I94f2721b599c3ae3e2ebc1c90dea649a69d51ef7 Reviewed-on: https://gerrit.libreoffice.org/65453 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 2dc3a6c273cb82506842864481d78df7294debbf)
2018-12-12sw: fix paragraph enumeration going past a selected tableMiklos Vajna2-0/+72
Writer has the internal invariant that if a text (non-table) selection starts outside a table, it should end outside a table as well. This means if you start your selection before a table and you try to select till the end of the table, your selection will end at the start of the next non-table node in fact. This is especially confusing if you turn the selection into a paragraph enumeration, where the last paragraph's 0 -> 0 character range is "selected" (i.e. none of the paragraph content is selected) and still the paragraph is included in the paragraph enumeration. Special-case the "selection ending at para start after a table" situation when it comes to turning this selection into a paragraph enumeration to avoid the unexpected empty paragraph at the end. Reviewed-on: https://gerrit.libreoffice.org/64972 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 42dffe7b135c0680a8e20e4170a5f1176afc908e) Conflicts: sw/qa/extras/unowriter/unowriter.cxx Change-Id: I51432dee9e5d76971533c8059edab1cd9683434b
2018-12-04sw: fix paragraph enumeration going past selection endMiklos Vajna4-0/+57
SwCursor::MovePara() may move the uno cursor past the end of the selection range, check for this explicitly. In practice this makes sure that in case a 1-paragraph cell text is selected, we never jump to the next cell for a selection created from the previous cell. Reviewed-on: https://gerrit.libreoffice.org/64509 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit a4b67dbccb4f376ac3a75f8f602ea84b8c4d00ea) Conflicts: sw/qa/extras/unowriter/unowriter.cxx Change-Id: Ibe2d00cfa75ed0c32b9c89d86cfae3b51d70ddc6
2018-11-27tdf#121723 vcl: leave popup mode on focus loss of toplevel windowsMiklos Vajna1-0/+5
This way it can't happen that we open a menu or context menu, the user switches away (loosing focus) and a leftover floating window is still there. Handle this at the same place where we stop blinking the cursor on focus loss. Reviewed-on: https://gerrit.libreoffice.org/64053 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit f21d2b48bd68424a96aa6cd5572e368208378291) Change-Id: I4321e8e3fa1d3f8976c0a1fa29c6a182972023bf
2018-11-21sw reqif-xhtml export: write graphic of OLE object at OLE1 levelMiklos Vajna3-15/+96
[MS-OLEDS] 2.2.5 EmbeddedObject actually has a last Presentation field, and we didn't write it so far. Luckily all the info can be extracted from the OLE2 container, so we can roundtrip the OLE1 wrapper around OLE2 nicely. Reviewed-on: https://gerrit.libreoffice.org/63667 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 1ca409292272632f443733450313de5a82c54a9c) Change-Id: I8d4922428dd5beeaae8b6cd4da0575db7014e4a2
2018-11-16sw reqif-xhtml export: write graphic of OLE object at an RTF level as wellMiklos Vajna4-4/+84
An embedded object have have its replacement graphic at 3 levels in reqif-xhtml: PNG at HTML level, WMF at RTF level and as a stream in the OLE2 storage. Some reqif readers depend on having the replacement graphic at an RTF level, so write that variant, too. Reviewed-on: https://gerrit.libreoffice.org/63419 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com> (cherry picked from commit e807d6158e5bb030e2f884571493f65b285875f8) Conflicts: sw/source/filter/html/htmlreqifreader.hxx Change-Id: I3391303248d2792a4c370e8fc84db0f22185312e
2018-11-15sw: fix modification of ole obj native data during HTML importMiklos Vajna5-3/+50
It is expected that if you load an OLE2 storage (from reqif-xhtml) and you save it as ODT, the OLE2 data is not modified. This was almost the case, but we insisted on removing the OLE2 preview from the storage. Add a new flag to OleEmbeddedObject, so import filters can opt in for not modifying the OLE2 data. [ The nice situation is that we already had a test file which had a preview stream in the OLE2 storage, so we can easily assert there that the size doesn't change. ] Reviewed-on: https://gerrit.libreoffice.org/63381 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins (cherry picked from commit 72e6269b88a32a672e00d2c25f0d0400038d1360) Conflicts: sw/source/filter/html/htmlplug.cxx Change-Id: I9b8b29f015dd4f2513e51a1066767218580cb5d8
2018-11-08embeddedobj win32: avoid owning a lock while calling out to event listenersMiklos Vajna1-3/+8
The deadlock happens from time to time, when converting documents containing OLE objects via remote UNO (from Java) -- after the conversion, when closing the document. The relevant stacktraces are: >Debug.ListCallStack /ShowLineOffset /AllThreads Callstack for Thread 8 (Thread Id: 32912 (0x8090)): ... 6 sal3.dll!osl_acquireMutex(_oslMutexImpl * Mutex) Line 75 7 [Inline Frame] emboleobj.dll!osl::Mutex::acquire() Line 56 8 [Inline Frame] emboleobj.dll!osl::Guard<osl::Mutex>::{ctor}(osl::Mutex &) Line 129 9 emboleobj.dll!OleComponent::OnClose_Impl() Line 1399 10 emboleobj.dll!OleWrapperAdviseSink::OnClose() Line 119 Callstack for Thread 11 (Thread Id: 21088 (0x5260)): ... 11 ole32.dll!00007fffc5e44e83() 12 [Inline Frame] emboleobj.dll!OleComponent::CloseObject() Line 1012 13 emboleobj.dll!OleComponent::Dispose() Line 484 14 emboleobj.dll!OleComponent::close(unsigned char bDeliverOwnership) Line 1463 15 emboleobj.dll!OleEmbeddedObject::GetRidOfComponent() Line 239 16 emboleobj.dll!OleEmbeddedObject::Dispose() Line 275 17 emboleobj.dll!OleEmbeddedObject::close(unsigned char bDeliverOwnership) Line 497 ... 26 swlo.dll!SwXTextDocument::close(unsigned char bDeliverOwnership) Line 617 OleComponent::OnClose_Impl() taking a lock is fine, but OleComponent::close() takes a lock and then later it still calls out (via OleComponent::CloseObject()), which is a no-go. Fix the problem by making sure that callers of Dispose() own no lock at the time of the function call, and taking the lock in Dispose() only after the CloseObject() call (which invokes event listeners). Change-Id: I53befee21478188c7f79723b7d7596e66077d1c2 Reviewed-on: https://gerrit.libreoffice.org/63014 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit fe83001574b4c8dbab166d8abb8014f78424278a)
2018-10-31sw: fix import of OLE object preview bitmapsMiklos Vajna1-1/+27
xmloff sets these using package URLs (on this branch, LO >= 6.1 got rid of URLs for setting graphics), but SwXFrame::setPropertyValue() only expects graphic object URLs, so the preview is lost on import. Normally this is not noticeable as a fresh preview will be created, but in the situation described by commit 13162d054d628380bf488acd7971170212af005e (svtools: fix lost replacement grpahic when updating it via OLE fails, 2018-10-30) this leads for the loss of preview on export (e.g. HTML). Fix the problem by explicitly looking up the graphic stream (of the OLE object) in the embedded object container, so the preview from the input (ODT) file is kept during conversion. Change-Id: I91fd23e4db9e39be6153748207b3c0bfb9f58901
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-09 05:58:10 +0000