summaryrefslogtreecommitdiff
path: root/vcl
AgeCommit message (Collapse)Author
2020-09-24Fix typoAndrea Gelmini
Change-Id: Ieb59e035d6454536db44a1aeb3ffdbb25e6bba08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103226 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-24Revert "Directly acquire m_aMutex, instead of looping on m_condition.wait()"Stephan Bergmann
This reverts commit e9a16702ba025ca340bcded4fda37235d22410a1. My understanding that the code was pointless was apparently wrong (the relevant part being hidden in m_condition.wait() internally doing the call to MsgWaitForMultipleObjects; I've improved the relevant comment now). (And my fears that the code using osl::Condition might be broken by design were hopefully unfounded.) Change-Id: Icb244ec9df8a2b0dacf115700ed850d471446f3a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103310 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Tested-by: Jenkins
2020-09-24tdf#136678 crash in collectUIInformationCaolán McNamara
since... commit cdb9c24b45ce7c35cf507430bd5ee1d9c3d5ea72 Date: Fri Aug 28 05:35:22 2020 +0200 Change-Id: I28f621a601daa2ccc6c893561c9de402f22c8657 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103303 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-24More fixes of PDFium-provided strings, in test codeStephan Bergmann
...similar to 08705b75ff8b5a10dc039a9aa1042e04a281729a "These PDFium-provided strings are always in UTF-16LE". Change-Id: Ic2945470db12a50e90b0feb3bbc6b63449fc39ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103289 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-23Directly acquire m_aMutex, instead of looping on m_condition.wait()Stephan Bergmann
The code had been introduced with 9c9970952b0adec4a8c6de9a4cd54d0980cd47ec "tdf#96887 enhance SolarMutex AcquireWithWait for Windows", which mentions MsgWaitForMultipleObjects in multiple comments as if it had intended to make use of it somewhere, but no such use can be found in that commit. (I had come across this code when on Windows some CppunitTest had deadlocked for me during DeInitVCL when re-acquiring the released SolarMutex at the end of > #if defined _WIN32 > // See GetSystemClipboard (vcl/source/treelist/transfer2.cxx): > if (auto const comp = css::uno::Reference<css::lang::XComponent>( > pSVData->m_xSystemClipboard, css::uno::UNO_QUERY)) > { > SolarMutexReleaser r; // unblock pending "clipboard content changed" notifications > comp->dispose(); // will use CWinClipbImpl::s_aMutex > } > #endif at vcl/source/app/svmain.cxx:490--498, and SalYieldMutex::doAcquire was waiting in m_condition.wait() for an m_condition.set() from some other thread that would never come---there were not even any other relevant threads left. At first I thought this might be an issue with broken-by-design osl::Condition, where some other, meanwhile gone thread's m_condition.set() had been cancelled by this thread's m_condition.reset() in SalYieldMutex::doAcquire, but then its m_aMutex.tryToAcquire() should probably have succeeded so that it wouldn't have ended up in m_codition.wait(). But even if the use of m_condition might not be broken after all and the deadlock I observed would be caused by something else, it nevertheless looks pointless, so better clean it up.) Change-Id: Ia6c1aa133c14e19224d0f24c810f43363cb5898c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103253 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-23Correctly read PNG into bitmaps N32BitTcA... formats (where alpha comes first)Stephan Bergmann
This appears to be a regression introduced with 86ea64f216819696cd86d1926aff0a138ace2baf "Support for native 32bit Bitmap in VCL and SVP (cairo) backend". It caused CppunitTest_vcl_png_test to fail on (big-endian) Linux s390x with > vcl/qa/cppunit/png/PngFilterTest.cxx:176:PngFilterTest::testPng > equality assertion failed > - Expected: c[ff000040] > - Actual : c[0000ff40] where eFormat happens to be ScanlineFormat::N32BitTcArgb, vs. ScanlineFormat::N32BitTcBgra on e.g. Linux x86-64 (and which thus didn't notice the lack of support for N32BitTcA... formats where alpha goes first instead of last). Change-Id: Id6030468718f6ef831b42f2b5ad7ba2c4c46a805 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103240 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-23These PDFium-provided strings are always in UTF-16LEStephan Bergmann
...see the documentation of FPDFTextObj_GetText in workdir/UnpackedTarball/pdfium/public/fpdf_edit.h and of FPDFAnnot_GetStringValue in workdir/UnpackedTarball/pdfium/public/fpdf_annot.h. This appears to be broken ever since the code's introduction in 440cb3fb80d9fd356871eac410b9797f23433722 "pdf: add PDFiumTextPage and PDFiumPageObject + test" resp. 7e4dc3b1eabcb1993d4143c046a2f32fedc852ed "vcl: Add annotation reading to PDFiumLibrary c++ wrapper". It caused vcl_pdfium_library_test to fail on (big-endian) s390x with > vcl/qa/cppunit/PDFiumLibraryTest.cxx:141:PDFiumLibraryTest::testPageObjects equality assertion failed > - Expected: The quick, brown fox jumps over a lazy dog. DJs flock by when MTV ax quiz prog. Junk MTV quiz > - Actual : 吀栀攀 焀甀椀挀欀Ⰰ 戀爀漀眀渀 昀漀砀 樀甀洀瀀猀 漀瘀攀爀 愀 氀愀稀礀 搀漀最⸀ 䐀䨀猀 昀氀漀挀欀 戀礀 眀栀攀渀 䴀吀嘀 愀砀 焀甀椀稀 瀀爀漀最⸀ 䨀甀渀欀 䴀吀嘀 焀甀椀稀  and > vcl/qa/cppunit/PDFiumLibraryTest.cxx:192:PDFiumLibraryTest::testAnnotationsMadeInEvince > equality assertion failed > - Expected: quikee > - Actual : 焀甀椀欀攀攀 Change-Id: I6fb5bea43646d544b8c3bdf06a63a1ed3df9c07e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103243 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-23These PDFium-provided string sizes must always be multiples of 2Stephan Bergmann
...as both FPDFTextObj_GetText (see workdir/UnpackedTarball/pdfium/public/fpdf_edit.h) and FPDFAnnot_GetStringValue (see workdir/UnpackedTarball/pdfium/public/fpdf_annot.h) return UTF-16LE strings but measure their sizes in bytes. So half the returned sizes early, which avoids over-allocating double sized sal_Unicode arrays, and is a prerequisite for a follow-up endianness-issue fix. Change-Id: I4565819044a44ca9435f9bffdea083d5807cfe4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103242 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-23tdf#102967 Hide surrounding border frame at left panelsandreas kainz
Change-Id: I155f20ee8f5c73bbb09bdd82b4a9da81967912e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103227 Tested-by: Jenkins Reviewed-by: Andreas Kainz <kainz.a@gmail.com>
2020-09-23ofz#25868 Timeout, encoding conversion only sane in 0..SAL_MAX_UINT16 rangeCaolán McNamara
so ignore points outside that range to avoid ludicrous ranges that aren't possible in the input encoding Change-Id: Ifb7b9b389d4a31b8820a7da661249223fe1e110c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103237 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-23clarifications on the use of SKIA_USE_BITMAP32Luboš Luňák
Change-Id: Ia2f80c3dc6ac3e0b16993dde588a4987ce98aa81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103235 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-23nicer codeLuboš Luňák
Change-Id: I391fee76b86bb3fed2f8e840f8b469b6aff3ac2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103234 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-23Removed duplicated includeAndrea Gelmini
Change-Id: I3f672cbf7fa6c92580abb629575d2eb46700bd4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103225 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-23tdf#135303Tomoyuki Kubota
"Color", not "Colors", is correct Change-Id: I042c23224c4ae684976f1c165b2742dc100d9c73 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99914 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2020-09-23abort if Skia code detects problems with VulkanLuboš Luňák
The document from tdf#136244 in low memory conditions (32bit Windows) may be sometimes rendered without the alpha channel, i.e. Skia/Vulkan apparently render just the data bitmap but not the alpha bitmap. So check the status of the GPU context and abort if there's a problem. I've considered trying to recover by switching to Raster, but e.g. in this specific case something has already been drawn and it can't be done. Another problem in this specific case is that the whole app is running low on memory and copying the data from the GPU would fail anyway. So just fail hard to avoid silent data loss. Change-Id: If05f9c65b160ad5e7b9407b9f809606a1392d740 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103206 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-23detect and fail immediately on failed Skia allocations (tdf#135952)Luboš Luňák
The problem with tdf#135952 is that the PNG export dialog can lead to requesting an absurdly large image, which leads to allocation failures. Some VCL backends such as headless try to cope with this and bail out, but they often crash anyway, since at higher levels of LO code nothing checks for these corner cases anyway. And even if nothing would crash, this can lead to silently losing data. So I've decided to directly detect such cases and fail hard and early. Change-Id: I5277a65c794116206de8280faf22ff897daa2f56 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103171 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-23if allocating Vulkan surface fails, fall back to Skia raster surfaceLuboš Luňák
Occassionally there may be very large surfaces, such as in tdf#135952. Try to fall back to raster, which is more likely to succeed, given that it uses system RAM instead of video RAM. Change-Id: I81994b174e5e52066eacc5f8778e9469b042f9c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103170 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-23assert that SkiaSalBitmap mImage is not deleted if it's the only dataLuboš Luňák
Change-Id: Idec2e0f3e852c37b37e220ac5059ef0b6accc77a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103205 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-23createSurface() should be enough if the surface doesn't exist yetLuboš Luňák
Change-Id: Ic390b94e6140169d878b428c782e03c29cce0ea2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103184 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-23WIN merge CWinClipbImpl into CWinClipboardJan-Marek Glogowski
Get rid of the already minimal pImpl. Change-Id: Ida6fedab6e779b649e546bae2cda5f14fd4090d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103211 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-22Move MimeContentTypeFactory into vclJan-Marek Glogowski
The code is just used in vcl from LO's POV. This way we can drop the dtrans directory and get rid of yet an other library. Change-Id: Id77568e63a6fef4af30b49e035a9d76211b127a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103210 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-22WIN move dtrans code into vcl/win/dtransJan-Marek Glogowski
There is nothing abstract about either the clipboard or data transfer code in that directory and it's just used on Windows. All other backends implement this code in VCL, so this moves almost all code, except for the common MimeContentTypeFactory, into the vcl Windows backend / vclplug_win. This also drops four DLLs: sysdtrans, dnd, dtrans and ftransl. Change-Id: I7018f50768bf221447b40487cc1f8a8586da33c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103209 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-22ofz#25855 overflow in nTmpOffsetCaolán McNamara
we already know nLength is >= 24 so just move the calc to the other term Change-Id: Ic52f1686ccf81e6b13d7eb7e74dbd9cb51c8ea01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103183 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-22do not use SkShader if not neededLuboš Luňák
Change-Id: I9913673c889e605d608e25dad9a36b05912447be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103153 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-22fix parsing of Vulkan version numbersLuboš Luňák
The Windows+OpenGL handling pads the numbers so that .98 > 0.978, but Vulkan uses "normal" numeric ordering for versions. Change-Id: I766baf50e3505a96aa85163962400bb69c0acea6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103118 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara
do more like commit 121771e37f7e2de41cd5643475861062bf25627b Date: Mon Sep 21 09:17:54 2020 +0200 Make some OUStringLiteral vars constexpr cause coverity can live with that Change-Id: I9efd7f848289c4865997a44c6780373068422227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21update pchesCaolán McNamara
Change-Id: I41a204fbc5e2c9b819fb948c5288f8d7b4195489 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103117 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21weld infobarsCaolán McNamara
note: "pushed" status listener case dropped. Doesn't seem to be an expectation for it to something in infobars, and there doesn't seem to be a working case anyway. Change-Id: I7869cc05de9918f0dd70e28b0087205db6c9506c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101945 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21set properly font X-scale for Skia+X11 (tdf#136891)Luboš Luňák
Change-Id: I715453f6729363e6bf803f8493d91bb260fb808a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103097 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-21do not try to merge polygons if they do not share a point (tdf#136222)Luboš Luňák
If two polygons do not share a point, then they do not share an edge, so they cannot be adjacent polygons. As a side-effect this avoids the problem with tdf#136222, as it turns out basegfx::utils::mergeToSinglePolyPolygon() is broken with polygons that are almost but not quite adjacent. Change-Id: Ibf290cc886d7c337fd04c925b551b2e7773a6b70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102985 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2020-09-21add some more thaw/freeze usesCaolán McNamara
to try and squeeze out a little more performance. Its plausible that disconnecting the model from treeview with gtk_tree_view_set_model(..., nullptr) no longer improves times. If we didn't do that, then we could thaw/freeze without losing what nodes are expanded and the current scroll pos. Change-Id: I3f7da6e4873b37d53441abdb7e9e0b946b956ad4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103077 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21Missing includeStephan Bergmann
(for std::max, since f8474367449a1b6b54918d2753e3a36798761839 "ofz#25774 keep ParseCMAP within legal area") Change-Id: I873c788577e9ec3bd54d9e637d2cf86be7c1f6e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103089 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-20tdf#136559 We can get a performance boost from using a ListStoreCaolán McNamara
instead of a TreeStore if we only need a list see: https://gitlab.gnome.org/GNOME/gtk/-/issues/2693 Change-Id: I03d03f2364ccc75b87d3f7c31d21ac9993fb384b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103036 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-20cid#1466875 Dereference null return valueCaolán McNamara
Change-Id: I6208d2d6e6592db89223c8a8705f7f1ba066f16e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103068 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-19fix non-pdfium buildNoel Grandin
Change-Id: Ic1e30a412927748ba58a21cf2ee922cd1a490aa4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103040 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-19Fix crash from broken font CMAP subtableJan-Marek Glogowski
ParseCMAP crashes on a broken CMAP subtable of a font used by the bugdoc of tdf#119074, which returns a negative offset (technically it's large positive offset turning into a wrong negative integer, which is still out of bounds of the CMAP overall size - you get the point). This simply ignores that broken subtable, checking for other existing ones. Regressed-by: c7482bc2904401e7d975b5721ec861b8589253f9 Change-Id: I95820fe3bb6bd2fe2e0cf9d4c3536abce31fd497 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103033 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-18ofz#25774 keep ParseCMAP within legal areaCaolán McNamara
Change-Id: Ic68fadd3d63631cbccda76e7679d95bb89452d25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103017 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-18[API CHANGE] tdf#136836 emfio: set size hint on inner PDF if used as shape fillMiklos Vajna
The bugdoc has a shape, its bitmap fill is an EMF, which is actually a PDF. The PDF is has a height of 5cm, but the shape has a height of 14 cm. Inform vcl::RenderPDFBitmaps() about the size of the shape, so the result won't be blurry. This approach makes sure that we don't unconditionally render at higher resolution, i.e. the "load a PDF of 100 pages into Online" use-case won't use more memory than before. API CHANGE, because the EMF reader is only available via UNO, though it's likely that no actual external code would ever invoke it directly. Change-Id: If1d8def0136d408a31a0cc54777a7f26430a0ff3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102996 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-09-18Fix typosAndrea Gelmini
Change-Id: I382bac84126095950a1d3932665c36fb16f1383b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101100 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-18Related: tdf#136559 set multiple columns in model at the same timeCaolán McNamara
reduces time from 40s to 13s Change-Id: I01d6a4fcaa5a868f9b9f9292f4a7e99e216ea23b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102988 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-18jsdialog: use window only if visibleSzymon Kłos
When there is a name conflict we should take currently visible window. Change-Id: Iaccf03a78b083ecaca0ee6aa538674a6de093a4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102903 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102983 Tested-by: Jenkins
2020-09-17tdf#133690 Hide surrounding border frame at sidebarandreas kainz
Change-Id: I6daff0ae587232b4b31d02aeb2529eff3fba36a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102967 Tested-by: Jenkins Reviewed-by: Andreas Kainz <kainz.a@gmail.com>
2020-09-17Revert "remove border line from sidebar"Andreas Kainz
This reverts commit 1349e66ef629bfc8aed23434108339bdba5013bb. Reason for revert: <INSERT REASONING HERE> Change-Id: I2430718556745aa60e56f4c25b9dc8cb86644b2d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102925 Tested-by: Jenkins Reviewed-by: Andreas Kainz <kainz.a@gmail.com>
2020-09-17qt5: Pass QStyleOption by reference instead of pointerMichael Weghorn
Change-Id: I12c88016740d94d4f2fcf0e1f83658dd2c3922a1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102912 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-09-17tdf#136094 qt5: Handle bg color in drawNativeControlMichael Weghorn
This adds handling for the background color when drawing controls in the qt5 VCL plugin, as was done in the following commit for the gtk3 VCL plugin: commit 2c9052802ea411dffbf5906c4914611fcbfbc6a5 Author: Michael Weghorn <m.weghorn@posteo.de> Date: Mon Aug 24 17:18:03 2020 +0200 tdf#136094 Handle background color in drawNativeControl For some reason, the proper background color is not passed to 'Qt5Graphics_Controls::drawNativeControl' for the multiline edit in the sample document ('rBackgroundColor is 'COL_AUTO' instead), while it works as expected for the gtk3 case. Setting a color inside 'Qt5Graphics_Controls::drawNativeControl' for testing purposes made that one show up, so the problem is elsewhere. I'll create a separate bug report to keep track of this and reference it in tdf#136094. Change-Id: I4df0d803c017422e0a2f5c05c6b4d2d8a8fa68c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102911 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2020-09-17Add schema comment to XML namespaced blockJan-Marek Glogowski
Just for reference, like all other namespaces. Change-Id: I1931063039e90c37ba54debb89d4e8994054f745
2020-09-17tdf#136805 PDF export: re-add XMP basic meta dataJan-Marek Glogowski
VeraPDF complains about: <rule specification="ISO 19005-1:2005" clause="6.7.3" testNumber="1" status="failed" passedChecks="0" failedChecks="1"> <description>If a document information dictionary does appear at a document, then all of its entries that have analogous properties in predefined XMP schemas, shall also be embedded in the file in XMP form with equivalent values.</description> <object>CosDocument</object> <test>doesInfoMatchXMP</test> <check status="failed"> <context>root</context> </check> </rule> The regressing commit dropped the XMP Basic schema meta data (http://ns.adobe.com/xap/1.0/"). FWIW: xmp is the referred prefix, so we'll continue to use it. Regressed-by: d016e052ddf30649ad9b729b59134ce1e90a0263 Change-Id: I11b06fdafcb07732b92f0bd99b18afa3a9e498ef Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102888 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-16jsdialog: export tooltip for drawing areasSzymon Kłos
Change-Id: I22a4eb9a74a81bbd2a26d5bae6b875a78a63acf9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102163 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Szymon Kłos <szymon.klos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102862 Tested-by: Jenkins
2020-09-16remove border line from sidebarandreas kainz
Change-Id: I520b6a5eaec5db065dc122b3e97861548347791e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102825 Tested-by: Jenkins Reviewed-by: Andreas Kainz <kainz.a@gmail.com>
generated by cgit (git 2.34.1) at 2025-01-04 11:52:41 +0000