summaryrefslogtreecommitdiff
path: root/include/drawinglayer
AgeCommit message (Collapse)Author
2023-10-12drawinglayer,svx: PDF/UA export: put Form SE into anchor paragraph SEMichael Stahl
This is like commit d467f1aa3d028f399826c97e2eecedcd79efcf65 and commit 6e5d59c2ca6969e9491f97cd7a00d094fc62cfb3 but for the form controls, which have their own special ControlPrimitive2D. Change-Id: I4b4ac45e81f490a7b625acd9e8753300d10bf119 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157847 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-09-23tdf#146619 Recheck include/d* with IWYUGabor Kelemen
Change-Id: Ib17953b49e5035255203e33778a262211d1491f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156985 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
2023-09-21tdf#146619 Recheck include/basegfx with IWYUGabor Kelemen
Change-Id: I08dad6ceeaa9e5470491c09f06d819c4c27ec5f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156983 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
2023-09-14tdf#156808 force an alpha mask to be created even if it has no alphaPatrick Luby
We need an alpha mask, even if it is totally opaque, so that drawinglayer::primitive2d::ProcessAndBlurAlphaMask() can be called. Otherwise, blurring of edges will fail in cases like running in a slideshow or exporting to PDF. Change-Id: If03b32a8a22ed960f1475710a9831cab33799b60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156903 Tested-by: Jenkins Reviewed-by: Patrick Luby <plubius@neooffice.org>
2023-08-28tdf#143148: Replace include guards with pragma onceTobias Kokolakis
Change-Id: I24e4526c66488067f1e82320f3c921177bf668d0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156177 Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2023-08-21split to allow getting decoration on its ownCaolán McNamara
Change-Id: Ib65750245906de0852c39e4a4bdaa85a2f822282 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155899 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-07-23drawinglayer: Drop recently unused TextLayouterDevice::getCaretPositions()Khaled Hosny
Change-Id: I07255d45bc03a5f86a22d7f392c14053eec7f6ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154648 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@libreoffice.org>
2023-07-23vcl: Use GetTextArray() when drawing mnemonicsKhaled Hosny
Instead of using a different function to get the character width, use the same function used for getting the character widths elsewhere. Change-Id: I21428f34bb0f3a60fa17f5e8ecc3420545356337 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154609 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@libreoffice.org>
2023-07-21related tdf#152992: rename HitTolerance to HitTolerancePerAxisSarper Akdemir
Rename ...HitTolerance instances to ...HitTolerancePerAxis as suggested by Noel on: https://gerrit.libreoffice.org/c/core/+/154694/2/include/drawinglayer/processor2d/hittestprocessor2d.hxx#45 Change-Id: I9c5b69218a4809f795c9a6324d76b2e2c1b12343 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154716 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de>
2023-07-21tdf#152992: for Impress/Draw add horizontal hit tolerance for quick text editSarper Akdemir
Implements horizontal hit tolerance for quick text edit in Impress & Draw making it more forgiving. Previously it was required to click exactly on the glyph to get a direct text cursor. Refactors hittestprocessor2d so that it now supports pseudo per axis hit tolerance. i.e. underlying isInEpsilonRange hit check is still the same utilizing the larger tolerance of the two per axis tolerance, but the preliminary check that uses aPolygonRange.grow() and later aPolygonRange.isInside() now filters hit misses out with respect to the per axis hit tolerance. Utilizes hittestprocessor2d's new per axis tolerance to introduce hit tolerance for quick text edit, making it similar to TextEdit mode hit tolerance which only has horizontal tolerance. Fixes wrong use of BoundRect hit to determine text frame border hits. Which previously only made sense for TextFrame borders, and was mostly useless for shapes with text inside. Change-Id: I749e63752da05b01270bfcab2632c41879a848ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154640 Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org> Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-07-14tdf#154982 drawinglayer,svx,sw,vcl: PDF export: hell flys and shapes...Michael Stahl
... should be below their anchor paragraph in the structure tree. Refactor SwEnhancedPDFExportHelper (etc.) to use the new EnsureStructureElement()/InitStructureElement() functions instead of SetCurrentStructureElement() for the frames, and allow it for flys that don't have their anchor paragraphs created yet because the hell layer is exported before the document body. Change-Id: I1be3b54002e8196772e6f9d81dd0fd0c85b6e34b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154399 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-07-05loplugin:finalclassesNoel Grandin
Change-Id: I62b094a3bd9a4f630cebdf538c04391e2920ff2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154064 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-15MCGR: consolidations/cleanups for changes so farArmin Le Grand (allotropia)
Change-Id: I85cf40e4803b0485bb40349d8e81adc8123666c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151706 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-28Move all handling of AA allowing from svt to drawinglayerMike Kaganski
Commit 444bf8710d5da7b584fbcb94693e4ed8d2e29297 (Update handling of AntiAliasing settings and processor2d, 2022-11-08) moved the actual variable holding the AA state to drawinglayer, which introduced a duplication of the information. This moves all the handling from svt to drawinglayer, so that svt functions only use respective drawinglayer functions. Well, almost: the IsAAPossibleOnThisSystem function needs vcl, so stays in svt. Change-Id: I887307fbca1ca0cff1f5f32446e3599817099c3f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151163 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-21MCGR: Reduce diverse GradientStyle enums to single UNO API oneArmin Le Grand (allotropia)
Change-Id: Ie0cd26a308a75ddead9451c53e874a39cc6eeb63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150705 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-04-18tdf#150020 pptx import: handle algn for outerShdwSarper Akdemir
Introduces RectangleAlignmentItem that holds a value of the enum model::RectangleAlignment. Introduces SDRATTR_SHADOWALIGNMENT that holds alignment for a shadow. Implements import of algn for outerShdw. Makes the alignment considered while the shadow is being scaled. Also adds a unit test that covers this. Change-Id: I8f4eaed5f0d9428a7f405c65f19237f9e70ca151 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148934 Tested-by: Jenkins Reviewed-by: Sarper Akdemir <sarper.akdemir@collabora.com>
2023-04-02SDPR: Use currently added lambda to render GradientsArmin Le Grand (Allotropia)
Change-Id: I9fba920c60690f136cae956dae17e2f5e5081f19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149839 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-27tdf#152234 drawinglayer,svx: PDF/UA export: add Alt text to form controlsMichael Stahl
Specification: ISO 14289-1:2014, Clause: 7.18.1, Test number: 3 A form field whose hidden flag is not set and whose rectangle is not outside the crop-box shall have a TU key present or all its Widget annotations shall have alternative descriptions (in the form of an Alt entry in the enclosing structure elements) Form controls are weird because they have an SdrObject with the usual name/title/description plus a property "HelpText" on the control itself which is already exported as "/TU" on the /Annot unless it's empty. Exporting the SdrObject properties via ObjectInfoPrimitive2D doesn't work as tragically that is only created for form controls when painting to the screen while PDF export takes a detour that needs special handling. Change-Id: Id96f7dd13f190ab439c099cd1f4acb70c1c9fdc9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149554 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-03-23MCGR: Speedup Gradient Paint for VCLPixelProcessorArmin Le Grand (allotropia)
To do this, I re-organized FillGradientPrimitive2D and how it creates it's decompose. This provides the needed tooling to also do a more direct rendering in primitive processors if needed. The decompose no longer collects the matrices & colors as a 1st step in a helper data struecture (so I removed B2DHomMatrixAndBColor). It now uses a lambda function callback that hands over the matrix & color for each created step, so you can process it directly, in this case to create the needed primitives. NOTE: The decompositions are both tested. There was createNonOverlappingFill, but also createOverlappingFill that I am not sure is still used - and if in re-creating an old, strange XOR-using gradient paint mechanism in old metafiles (encapsulated with gradient info anyways), but I converted that and made sure it works. To do so I forced it to be used in paint. This is not really usable in paint since we need to paint using AA (else we would get staircase effects, esp. in new 'hard' color changes in multi-color gradients) and - as should be known - same edges painted in AA do *not* add up to full opacity, but leave behind awful 'jaggies' (e.g. opacity 0.5 and 0.5 create 0.75 and *not* 1.0). Still important to have the working geometry creation for this case. This already makes the decompose faster, but the main purpose is to use it as tooling for painting in own primitive renderers. Thus processFillGradientPrimitive2D now uses that instead of using the decomposition by default. This avoids one level of primitive creation, use that new FillGradientPrimitive2D tooling to directly create needed geoemtry & color for getting better performance (to partially compensate for potentially more expensive multi color gradients). It then paints directly using OutputDevice calls. NOTE: This can also be used in SDPRs as a 1st step to just directly and rapidly render filled single- color polygons, but of course there an implementation using the back-transformations (which are also adapted for MCGRs aleady and work) will be superior. Change-Id: I5079f76d6d8fe86007a098614c276447f2bfebce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149456 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-22MCGR: Corrected error with Case16 wrong gradient shortcutArmin Le Grand (allotropia)
Also simplified using the test cases, these now depend on an ENV VAR called MCGR_TEST. Fallback is no test. For seeing a multi-color gradient use 1, for Case16 use 16. If active, all gradients are replaced with the one active for the test, 2D and 3D. This is temporary but also for pro build to check for speed there. Change-Id: I90f3c7e59d9d0a3e070a849af3f9ea1c9e5462a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149316 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-22vcl,drawinglayer,svx,sw,sd: PDF/UA export: Annot StructElem for SdrMediaObjMichael Stahl
veraPDF complains: Specification: ISO 14289-1:2014, Clause: 7.18.1, Test number: 1 An annotation, excluding annotations of subtype Widget, Popup or Link, shall be nested within an Annot tag This is very similar to Link annotations, that is to say, extremely complicated to get it thought the convoluted PDF export code, with additional complication that the StructElem is produced by drawinglayer and the page annotation by sw. Put another map into PDFExtOutDevData where sw code puts stuff for the SdrObject that drawinglayer can find. The test had the problem that PDFObjectParser::parse() could not handle: <</Nums[ 0 [ 6 0 R ] 1 6 0 R ]>> Fix dropping the "1". Change-Id: If5bf7c552e26ebb7e631030b8aaecd4281e77acc (cherry picked from commit c78e90bd28cc4d6d3bde473535107784b12d9c0d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149008 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-03-19MCGR: Model data changes for ColorStepsArmin Le Grand (allotropia)
Added tooling replaceStart/EndColor to allow simple transition for code that does not immediately adapt to multi color gradients. Also added createColorStepsFromStartEndColor for the same purpose. Adapted XGradient to no longer have Start/EndColor at all, but only use ColorSteps. Adapted all usages of XGradient to no longer use Get/Set/Start/EndColor, but access the ColorSteps instead. Replaced quite some XGradient constructors that used XGradient() as Start/EndColor since this is already the default. Adapted ColorBlending to black AKA Start/EndIntens in XGradient to work now on all ColorSteps in the required linearly-scaled manner. UNO API changes: Added com::sun::star::awt::ColorStep as basic data element that holds a pair of Offset and Color. Added com::sun::star::awt::ColorStepSequence to handle an array of sorted entries. Added com::sun::star::awt::Gradient2 derived from com::sun::star::awt::Gradient, extended by the needed com::sun::star::awt::ColorStepSequence. Added MID_GRADIENT_COLORSTEPSEQUENCE to UNO API to provide access to ColorSteps directly. Adapted XFillGradientItem::QueryValue/PutValue to make use of new UNO API data structures. To do so, added tooling methods for data transition: - fillColorStepSequenceFromColorSteps - fillGradient2FromXGradient - fillColorStepsFromAny - fillXGradientFromAny and adapted - case '0' (all data) - MID_FILLGRADIENT - MID_GRADIENT_COLORSTEPSEQUENCE - MID_GRADIENT_START/ENDCOLOR to make use of these. Tested usage of these in the office. Renamed from GradientStep to GradientStop after discussions with members on the list to make this closer related to other norms/definitions. Also renamed classes and class members to better reflect to GradientStop, so grepping/finding will be easier (e.g. 'Color' just exists pretty often, but 'StopColor' is more precise). Changed the used UNO API class for reprsenting the Color to better reflect to ranges [0.0 .. 1.0] and usage of RGB. Change-Id: I1eeb3e97e81d6785967615d1ff256551fc3b882d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148849 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-03-04MCGR: ColorSteps handling moved to toolingArmin Le Grand (allotropia)
Due to the fact that handling of a vector GradientSteps will get used more often with ongoing changes I moved some handling to tooling, see sortAndCorrectColorSteps. That method sorts and corrects a vector of ColorSteps so that only valid entreis remain in a sorted order, for details please refer to the docu at function definition. I took the occasion to rearrange that to work on the single provided vector which is better for speed & ressources. Also changed the ColorStep constructor to not automatically correct constructed entries: While that is formally correct, it moves an invalid entry to 0.0 or 1.0, thus creating additional wrong Start/EndColor entries. Those may then 'overlay' the correct entry when corrections are applied to the vector of entries which leads to getting the wanted Start/EndColor to be factically deleted, what is an error. Also rearranged FillGradientAttribute to now work initially with ColorSteps, no longer requires the Start/EndColor, also adapted all usages. This securely allows start/end and in-between single-color sections in gradients. Also needed to re-formulate GradientRect & GradientElliptical ::appendTransformationsAndColors method for correct 2D mapping(s) - always incrementing from the start to end conflicts with the adaption of the start value for the inner loop mainly because increment is at start of inner loop (pre-increment). Corrected errors from clang plugin, but also some wrong initialiations for basegfx::ColorSteps. Change-Id: I292592ed9abcfa591f68a680479f4fcdda46cbeb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148196 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-02-19osl::Mutex->std::mutex in BasePrimitive3DNoel Grandin
Change-Id: I49e196885845f352c6c4cda6e3890b749d4eb0fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147263 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-02-15MCGR: Add GradientSteps to GeoTexSvxGradientArmin Le Grand (allotropia)
Move GradientSteps data to GeoTexSvxGradient and adapt interfaces. Also move tooling to more isolated place in gradienttools in basegfx. Keep everything still compatible, the work will be now to adapt all six different derivations of GeoTexSvxGradient to make use of the evtl. given GradientSteps. Change-Id: Iaa212763c603d46de0a94b1b203b979bb7ce359d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147050 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-02-12Fix typoAndrea Gelmini
Change-Id: Ia21de983bd4295f399e9753c29bc2a3cace2f250 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146835 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-02-12Fix typoAndrea Gelmini
Change-Id: I51b5c88e1d82c596b926e7074ee3a7e1395a21a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146834 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-02-12MCGR: Add/Provide GradientSteps to FillGradientAttributeArmin Le Grand (allotropia)
MCGR stands for MultiColorGRadient. This change allows/ prepares adding multiple color steps to gradient rendering. This is preparation work to allow rendering MCGRs in the future. All places are adapted in a way that currently no change of behaviour will happen. It will be the base to get MCGR rendering/decompose for Primitives and our internal/existing gradients working. Change-Id: I28bbd7d10b8670042343ada2a66b5909d3d31bbd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146748 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-01-21Fix typoAndrea Gelmini
Change-Id: I276af93573a6b56a810265ba84b83c56c96b251d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145933 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-01-21SDPR: Unified some stuff & moved to toolingArmin Le Grand (Allotropia)
Added and unified usage of a helper to create primitive sub content easily, also for visibility checking of primitives. Some smaller cleanups, too. Change-Id: I3c4cd3e98e62b8cf7984351dbb0b154470fd8e3c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145908 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-01-18SDPR: Add support for InvertPrimitive2DArmin Le Grand (Allotropia)
We urgently should get rid of XOR paint, modern graphic systems allow no read access to the pixel targets, but that's naturally a precondition for XOR. While we can do that for the office's visualization, we can in principle *not* fully avoid getting stuff that needs/defines XOR paint, e.g. EMF/WMF imports, so we *have* to support it (for now - sigh)... This makes this renderer complete from the minimal to-be-supported primitives, too. Change-Id: Ie8fa98b777de764af0babe969296a671ca5cc7ce Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145739 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-01-18Fix typoStephan Bergmann
...which happened to go largely unnoticed (the would-be additional overload, as seen when including drawinglayer/processor2d/SDPRProcessor2dTools.hxx first thing in drawinglayer/source/processor2d/SDPRProcessor2dTools.cxx, was just never defined nor used), but caused > drawinglayer/source/processor2d/SDPRProcessor2dTools.cxx(140,6): error: externally available entity 'prepareBitmapForDirectRender' is not previously declared in an included file (if it is only used in this translation unit, make it static; otherwise, provide a declaration of it in an included file) [loplugin:external] > bool prepareBitmapForDirectRender( > ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ with clang-cl Change-Id: I9f338dd998b66fe3223af045206a423b016b93f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145696 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-14Fix typosAndrea Gelmini
Change-Id: Ib698f8cde8b332487deaae459ba5ed3d3c66692b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145517 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-01-14Removed executable bits on source fileAndrea Gelmini
Change-Id: I0becfd79fe71557e7b538e7d4122374c2164fcda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145518 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-01-14Fix typos and exec bitsAndrea Gelmini
Change-Id: Ia23a7b507a8254a5d9143de055c28da9656425fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145515 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-01-13SDPR: Direct support for FillGraphicPrimitive2DArmin Le Grand (Allotropia)
Added support to directly paint FillGraphicPrimitive2D, that means object fill with multiple tiles/tiled fill. Note: This may use not only bitmap data, but also metafile or svg. The standard decompose creates one transformed bitmap/vector data primitive per tile what is correct, but has some limits (a) These may get many when tiles are small compared to mask polyPolygon (performance/ressources) (b) Correctness: when rendering in AA the common edges of tiles will *not* sum up perfectly, but due to AA multiplying when blending will leave ugly 'traces' This direct rendering avoids both. It can use the D2D Brush functionality to repeat. Additionally to the current office it can also do that when content is rotated/sheared. This may not be well known since for those fills the office always keeps the fill unrotated (for historical reasons, primitives can do that, but not vcl). To see it you may convert a SdrObject to metafile and rotate that, so the content gets rotated and shows that ugly gaps. Also added a square-pixel step value for vector fills where the default gets used starting from some size. The argument is better quality for vector data fills while only a limited number of tiles will be rendered. Also added a buffered handling of the (old and ugly) OffsetX/OffsetY to make that work, we will not get rid of that soon. Packed all of this into tooling (so started a tooling collection for SDPRs target-system independent) to be able to easily re-use all these preparations/tests in other SDPR implementations in the future. Change-Id: Iafacf4181e7c9e2d2b2e3b5cf1f7e4cdd0a43f0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145466 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-01-06SDPR: Overhauled D2DRenderer to use sal::systools::COMReferenceArmin Le Grand (Allotropia)
All stuff used from MS with names starting with ID2D1* is COM API stuff, so referenced and interface-based. I thought about making this more safe since a while (shared/unique_ptr, ...) but found no good way to do it. Also did not want to use CComPtr from MS and expand the devenv we need on win, so was short before doing an own small smartptr class. Luckily I asked sberg and he pointed me to the already existing sal::systools::COMReference which exactly does what I need here - thanks! Unluckily I now had to change a lot of code - sigh. I wish I had known earlier :-/ This change contains the renderer completely adapted to using that much safer and better ressource control. Plus I added (even more) comments to try to make more clear in many plasces what's going on, what is done and why. Change-Id: Ia2aa3223d0e5f7ec6569cde176cec1fadcd921dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145142 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2023-01-05Fix typosAndrea Gelmini
Change-Id: I49ca0e4e05420a4992acc348a3dc6e3533f4d30e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144618 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-12-22-Werror,-Wmicrosoft-extra-qualification (clang-cl)Stephan Bergmann
Change-Id: I7f0f551110d1df4e27d89ac1016fb5ff3f71151d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144736 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-21sync with latest additions to d2dpixelprocessor2dCaolán McNamara
commit 7d948d5c7edbbfd29a77b97a5101aa43917e5ec2 Date: Tue Dec 20 18:42:42 2022 +0100 SDPR: Add handling/direct rendering of some simple Primitives Change-Id: If5432ac02f51f4b9194ec5df347f93e11f58959b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144694 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-21initial Experimental System-Dependent PrimitiveRenderer for CairoCaolán McNamara
just some partial pieces export TEST_SYSTEM_PRIMITIVE_RENDERER=1 and the simple drawing shapes work Change-Id: I3e01501a1cb21ec86d6fe8f5637a23e7358ffc86 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144632 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-20SDPR: Add handling/direct rendering of some simple PrimitivesArmin Le Grand (allotropia)
(SDPR == SystemDependentPrimitiveRenderer) Make D2DPixelProcessor2D directly render the added simple Primitives LineRectanglePrimitive2D FilledRectanglePrimitive2D SingleLinePrimitive2D to use less ressources & get faster since no conversion to Polygons is done. These are Primitives that *may* be handled directly, but do not have to - I checked that the decomposes do work before adding direct handling. Change-Id: Ifa97c595c262d84a9889f92571b2c9909bcef0e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144626 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-12-20Added two simple tooling Primitives for easy/common casesArmin Le Grand (allotropia)
Added three simple tooling Primitives: (1) SingleLinePrimitive2D: Just a Line from Point A to B with a BColor, decomposes to a PolygonHairlinePrimitive2D (and to a PointArrayPrimitive2D if only a single point aka A == B) (2) LineRectanglePrimitive2D: (3) FilledRectanglePrimitive2D: Rectangles that support fill or line, gets decomposed to maybe PolyPolygonColorPrimitive2D (if filled) and a PolygonHairlinePrimitive2D (if line) or nothing if the B2DRange is empty NOTE: If using these despite being hor/ver aligned due to their nature as B2DRange(s) (aka 'non rotated/sheared') these may have to be transformed if the current transformation context you are working in is rotated or sheared, so *ensure* to handle these correctly if you do handle them yourself. This is not needed with the Polygon-based ones - that's why these are - and stay - the common case(s). Both are hairline primitives themselves, so are potentially *view-dependent* (see comment in *.cxx and *.hxx). They will be useful as very simple primitives for small renderers, e.g. to avoid conversion from rectangles or just lines to polygons. The more general Primitives are always the polygon-based ones, so these new ones get decomposed to these (decomposition direction, complex -> simpler). This assures that a processor/renderer has minimally to support the polygon-based ones, but *can* use these simple tooling ones directly if he wants to. This will come in handy for future System-Dependent PrimitiveRenderers, which I am currently working on one to offer as example - this leads to identifying helpful upstream things that will come in handy in that regard - like these ones. Change-Id: Ie5039e6cfad6c9914c165cae6f8b59abecc38302 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144543 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-12-20Example System-Dependent PrimitiveRenderer for Direct2D (Win)Armin Le Grand (Allotropia)
As promised at LiBoCon'22 I have finished an example implementation of a System-Dependent PrimitiveRenderer. It renders on Direct2D, so Win only. I chose this with no special thoughts, did not even know too much about Direct2D, so had to read quite some docu. Still managed to do this in a view days. NOTE: To make it run you need to switch off skia on Win probably due to some global extra stuff done there (?) The Renderer is in a new file (ca. 1000 lines) in the drawinglayer libary. It implements all of the needed primitives, so capable of rendering EditViews (Draw/ Impress complete, Writer/Calc in parts, interactions, overlay, selection(s), etc.). It is used completely as replacement of the VclPixelProcessor2D which is not used in the patched version *at all*. Just one primitive is missing: - InvertPrimitive2D: Not needed much (hopefully will vanish), could also be added It is not in production state, mostly intended as a demonstration how Primitives are intended: Render *without* using an OutputDevice at all, directly to the traget GraphicsSystem. It can (and should) be used as pattern for other implementations. NOTE: Inside the implementation you can do whatever you want, all is allowed. Only rule is to visualize the geometry defined by the Primitives. This version does not need any buffer allocations to render and is thus pretty fast (uses ID2D1Layer). It also has no buffering, but that could easily be added. The needed classes/implementations to buffer system-dependent representations of data exist, so doable fast for Bitmaps, Polygons and PolyPolygons. It runs stable and fast, but still has errors, so it is sometimes missing to render some stuff. I would have to debug/finetune it further, but I see this all as doable. It's far enough to be seen as POC and example. I also added a not-urgently-need-to-be-implemented primitive, the UnifiedTransparencePrimitive2D, to demonstrate how to do that: Add a handler for it and render the defined geometry if you can do that more direct/better than the decomposition. The rough to-do list would be: - add missing Primitives - InvertPrimitive2D - add buffering of - Bitmaps - Polygons - PolyPolygons - add TextRendering - using decompose to PolyPolygons currently, but looks reasonably good with PolyPolygon AA - general - polishing - bug fixing - stabilization(s) - speedups by adding PrimitiveHandlers - solve problem with TransparencePrimitive2D - had to use drawinglayer::createAlphaMask there, see comments Made handling of TransparencePrimitive2D work, some fixes and changes, too. Still not happy with processTransparencePrimitive2D, it uses drawinglayer tooling (createAlphaMask) to do it's job. It works, but there must be a better way. It's okay for demonstration/POV though Tried hard in processTransparencePrimitive2D to directly render the alpha channel to a Direct2D ID2D1BitmapRenderTarget using DXGI_FORMAT_A8_UNORM. It does work theoretically as it should, but I found no way to directly paingt to the AlphaChannel. It seems as if Direct2D *is* hard-wired to always alpha-blend, there seems to be no control or mode to *select* the BlendMode to be used. Since only that small step is missing I keep that code in (see bTryDirectPreparationOfAlphaAsBitmap). NOTE: No idea yet, but testing shows that the direct but not yet complete way is ca. 7 times faster. I have now added PointArrayPrimitive2D, so only that InvertPrimitive2D is missing. I also added MarkerArrayPrimitive2D to make it more efficient (marker bitmap gets converted only once) and better looking (not AAed anymore). With both added, grid visualization looks good and is fast. Added support for BackgroundColorPrimitive2D Added BitmapBuffering for Direct2D. This is a little bit more complicated, theoretically all ID2D1Bitmaps are specific to the ID2D1RenderTarget they get created for, so theoretically they have to be (re)created every time the ID2D1RenderTarget aka OutputDevice changes - argh. There is CreateSharedBitmap though that allows re-usage of already created bitmaps for a new RenderTaget, but this leads to needing a LO-livetime RenderTarget to create all the Bitmaps for. So I implemented that and it works and is fast. Added buffering for GeometryData, ID2D1PathGeometry. I prepared this already using the CreateTransformedGeometry functionality of Direct2D, so the B2DPolygon/B2DPolyPolygon can get buffered in an unchanged form, re-used as source for creating a ID2D1PathGeometry by calling CreateTransformedGeometry. This could also be done by manipulating the current transformation, but is not necessary. Simplified buffering by directly using derivated helper classes (from basegfx::SystemDependentData) as data holders, thus they can reliably call Release() at incarnated Direct2D instances without the need to keep record of this outside. Completely removed OutputDevice from the D2DPixelProcessor2D, it was anyways only used in the constructor. Removed the need to hand over the pixel size of the pixel target when constructing a D2DPixelProcessor2D, instead get that values from HDC directly. Also made D2DPixelProcessor2D exported from drawinglayer for further experiments. Checked if I can use higher-level Direct2D versions by using MS's QueryInterface to see if involved classes are higher-level ones. This worked and allows to paint the alpha channel for TransparencePrimitive2D now indeed using the BlendMode that is missing in the initial D2D stuff, so activated that (much faster). Aded the environment variable (for Windows only) TEST_SYSTEM_PRIMITIVE_RENDERER to allow easy tesing of SystemPrimitiveRenderer. Since Skia enabled does collide in quite some places (see above) I added hat this also disables Skia in it's central isVCLSkiaEnabled() method. That way it is easy to compare/quickly change between versions. Removed maCurrentTransformation, this is just not needed for a pixel-only renderer, see comment in VclProcessor2D's header regarding that. Added snap-to-pixel functionality. Added direct support for PolygonStrokePrimitive2D, so all lines which - are fat or thin - have LineCap - have LineJoin - use dash can be directly rendered by Direct2D. This is especially good for dash since no decompositions will be created for these cases. There is an exception for our own rarely used style B2DLineJoin::NONE, that still needs to be decomposed, but could also be added to the impl if needed. There were also quite some 'conditions' for supporting B2DLineJoin::Miter in Direct2D, but I managed to solve them all, so Miter is fully done in Direct2D in this example. I also added example debug code to demonstrate how it is possible to simply add decompose paint and the system-specific implementation to optically compare and play around in a running office to identify possible problems/differences. Improved handling of TransparencePrimitive2D massively to a more future-proof and more common methodology by using the Direct2D mechanism ID2D1Effect and the CLSID_D2D1LuminanceToAlpha effect. For details, see comment in comitted code at implCreateAlpha_Direct. As explained in refs/changes/87/141087/22 I did add now a tooling derivate of D2DPixelProcessor2D that can be used to render sub-content without having to deal with patching the current internal state of the running instance, called D2DBitmapPixelProcessor2D. It resides in the cxx file (so being safe from other usages), has and creates an own ID2D1BitmapRenderTarget to work on and will come in handy for other occasions that need to prepare a in-between result. Made stuff in the renderer itself more private and added access methods to protected section, use those in tooling. Change-Id: Ie5803f9afa3f62dbaa8fd2f1bac8fd30a23066b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141087 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-11-29New loplugin:crosscastStephan Bergmann
...inspired by 2fa426da15a12e2a63554247e3c1c3f8c0ec5c24 "Fix dynamic_cast after splitting OutputDevice and vcl::Window class hierarchies": "Find uses of dynamic_cast that cast between unrelated classes, which is suspicious and might indicate a bug. The heuristic used to consider two classes unrelated is that neither derives from the other (directly or indirectly) and they do not both virtually derive (directly or indirectly) from a common third class. Additionally, class definitions can be attributed with SAL_LOPLUGIN_ANNOTATE("crosscast") (from sal/types.h) to suppress false warnings about known-good cases casting from or to such a class." (quoting compilerplugins/clang/crosscast.cxx) This found two additional errors, 7a82ea5c79adee70eddf74ac53347544766a91b0 "Fix presumed typo" and fc6aa9e49973c845915754caf765ff57e5b0cd59 "fix assert", and one still-open case that looks like an error, see the TODO comment in sw/source/core/unocore/unodraw.cxx. In addition to that it flagged another 102 uses of dynamic_cast as suspicious, which have all been addressed, at least for now, by marking certain classes as SAL_LOPLUGIN_ANNOTATE("crosscast"), see below. (Where this commit also adds that generic SAL_LOPLUGIN_ANNOTATE mechanism to include/sal/types.h.) However, some of those annotations might benefit from further inspection and clean up similar to recent 8858962ec09478c203d43feb58f550bb36af37bb "Introduce ParagraphProeprtiesPropertyMap", 8467aa93e2038b3030e1add94e0ca6cc4ad44032 "Replace a dynamic_cast with UNO_QUERY", a534361141d69096d896e6e0552d19f3138eeeb3 "Fold OldBasicPassword into basic::SfxScriptLibraryContainer", and 589e03fb4c3b05bf3742c0cb8b366322ffdf1fa9 "[PATCH] Replace some dynamic_cast with UNO_QUERY". * canvas/source/cairo/cairo_repainttarget.hxx RepaintTarget: > canvas/source/cairo/cairo_cachedbitmap.cxx:62:34: error: suspicious dynamic cross cast from 'com::sun::star::rendering::XCanvas *' to 'RepaintTarget *' [loplugin:crosscast] > RepaintTarget* pTarget = dynamic_cast< RepaintTarget* >(rTargetCanvas.get()); * canvas/source/cairo/cairo_surfaceprovider.hxx SurfaceProvider: > canvas/source/cairo/cairo_canvashelper.cxx:301:45: error: suspicious dynamic cross cast from 'com::sun::star::rendering::XBitmap *' to 'SurfaceProvider *' [loplugin:crosscast] > SurfaceProvider* pSurfaceProvider = dynamic_cast<SurfaceProvider*>( xBitmap.get() ); * canvas/source/vcl/repainttarget.hxx RepaintTarget: > canvas/source/vcl/cachedbitmap.cxx:73:34: error: suspicious dynamic cross cast from 'com::sun::star::rendering::XCanvas *' to 'RepaintTarget *' [loplugin:crosscast] > RepaintTarget* pTarget = dynamic_cast< RepaintTarget* >(rTargetCanvas.get()); * chart2/inc/ChartModel.hxx ChartModel: > chart2/source/controller/dialogs/dlg_ChartType_UNO.cxx:82:31: error: suspicious dynamic cross cast from 'com::sun::star::awt::XWindow *' to 'ChartModel *' [loplugin:crosscast] > ChartModel* pChartModel = dynamic_cast<ChartModel*>(rParent.get()); * chart2/source/controller/inc/TabPageNotifiable.hxx TabPageNotifiable: > chart2/source/controller/dialogs/tp_RangeChooser.cxx:70:28: error: suspicious dynamic cross cast from 'weld::DialogController *' to 'TabPageNotifiable *' [loplugin:crosscast] > , m_pTabPageNotifiable(dynamic_cast<TabPageNotifiable*>(pController)) > chart2/source/controller/dialogs/tp_DataSource.cxx:171:28: error: suspicious dynamic cross cast from 'weld::DialogController *' to 'TabPageNotifiable *' [loplugin:crosscast] > , m_pTabPageNotifiable(dynamic_cast<TabPageNotifiable*>(pController)) * include/drawinglayer/primitive2d/svggradientprimitive2d.hxx SvgGradientHelper: > drawinglayer/source/primitive2d/svggradientprimitive2d.cxx:582:59: error: suspicious dynamic cross cast from 'const BasePrimitive2D *' to 'const SvgGradientHelper *' [loplugin:crosscast] > const SvgGradientHelper* pSvgGradientHelper = dynamic_cast< const SvgGradientHelper* >(&rPrimitive); > drawinglayer/source/primitive2d/svggradientprimitive2d.cxx:819:59: error: suspicious dynamic cross cast from 'const BasePrimitive2D *' to 'const SvgGradientHelper *' [loplugin:crosscast] > const SvgGradientHelper* pSvgGradientHelper = dynamic_cast< const SvgGradientHelper* >(&rPrimitive); * include/editeng/unotext.hxx SvxUnoTextRangeBase: > writerfilter/source/dmapper/DomainMapper_Impl.cxx:7645:62: error: suspicious dynamic cross cast from 'com::sun::star::text::XTextCursor *' to 'SvxUnoTextRangeBase *' [loplugin:crosscast] > SvxUnoTextRangeBase* pDrawText = dynamic_cast<SvxUnoTextRangeBase*>(xCrsr.get()); * include/embeddedobj/embeddedupdate.hxx EmbeddedUpdate: > svtools/source/misc/embedhlp.cxx:932:35: error: suspicious dynamic cross cast from 'com::sun::star::embed::XEmbeddedObject *' to 'embed::EmbeddedUpdate *' [loplugin:crosscast] > embed::EmbeddedUpdate* pObj = dynamic_cast<embed::EmbeddedUpdate*> (GetObject().get()); * include/oox/core/contexthandler2.hxx ContextHandler2Helper: > oox/source/core/contexthandler2.cxx:183:21: error: suspicious dynamic cross cast from 'const ContextHandler2Helper' to 'const ContextHandler &' [loplugin:crosscast] > ContextHandler( dynamic_cast< ContextHandler const & >( rParent ) ), * include/oox/mathml/export.hxx FormulaExportBase: > oox/source/export/shapes.cxx:2475:42: error: suspicious dynamic cross cast from 'com::sun::star::frame::XModel *' to 'oox::FormulaExportBase *' [loplugin:crosscast] > oox::FormulaExportBase *const pMagic(dynamic_cast<oox::FormulaExportBase*>(xMathModel.get())); * include/oox/mathml/import.hxx FormulaImportBase: > oox/source/drawingml/shape.cxx:1298:25: error: suspicious dynamic cross cast from 'com::sun::star::uno::XInterface *' to 'oox::FormulaImportBase *' [loplugin:crosscast] > dynamic_cast<oox::FormulaImportBase*>(xMathModel.get())); > writerfilter/source/ooxml/OOXMLFastContextHandler.cxx:2287:38: error: suspicious dynamic cross cast from 'SfxBaseModel' to 'oox::FormulaImportBase &' [loplugin:crosscast] > oox::FormulaImportBase& import = dynamic_cast<oox::FormulaImportBase&>(dynamic_cast<SfxBaseModel&>(*component)); > writerfilter/source/rtftok/rtfdocumentimpl.cxx:2973:33: error: suspicious dynamic cross cast from 'SfxBaseModel' to 'oox::FormulaImportBase &' [loplugin:crosscast] > auto& rImport = dynamic_cast<oox::FormulaImportBase&>( > writerfilter/source/dmapper/DomainMapper_Impl.cxx:3000:53: error: suspicious dynamic cross cast from 'com::sun::star::uno::XInterface *' to 'oox::FormulaImportBase *' [loplugin:crosscast] > if( oox::FormulaImportBase* formulaimport = dynamic_cast< oox::FormulaImportBase* >( xInterface.get())) * include/sfx2/Metadatable.hxx Metadatable: > sw/source/core/doc/docbm.cxx:1837:17: error: suspicious dynamic cross cast from 'const IBookmark *const' to 'const ::sfx2::Metadatable *' [loplugin:crosscast] > dynamic_cast< ::sfx2::Metadatable const* >(pBookmark)); > sw/source/core/doc/docbm.cxx:1924:13: error: suspicious dynamic cross cast from '::sw::mark::IBookmark *const' to '::sfx2::Metadatable *' [loplugin:crosscast] > dynamic_cast< ::sfx2::Metadatable* >(pBookmark)); > sw/source/core/doc/DocumentContentOperationsManager.cxx:342:21: error: suspicious dynamic cross cast from 'const sw::mark::IMark *const' to 'const ::sfx2::Metadatable *' [loplugin:crosscast] > dynamic_cast< ::sfx2::Metadatable const* >(pMark)); > sw/source/core/doc/DocumentContentOperationsManager.cxx:344:21: error: suspicious dynamic cross cast from '::sw::mark::IMark *const' to '::sfx2::Metadatable *' [loplugin:crosscast] > dynamic_cast< ::sfx2::Metadatable * >(pNewMark)); > sw/source/core/unocore/unobkm.cxx:381:12: error: suspicious dynamic cross cast from '::sw::mark::IMark *' to '::sfx2::Metadatable *' [loplugin:crosscast] > return dynamic_cast< ::sfx2::Metadatable* >(m_pImpl->m_pRegisteredBookmark); > sw/source/core/undo/rolbck.cxx:635:13: error: suspicious dynamic cross cast from 'const ::sw::mark::IBookmark *const' to 'const ::sfx2::Metadatable *' [loplugin:crosscast] > dynamic_cast< ::sfx2::Metadatable const* >(pBookmark)); > sw/source/core/undo/rolbck.cxx:713:13: error: suspicious dynamic cross cast from '::sw::mark::IBookmark *const' to '::sfx2::Metadatable *' [loplugin:crosscast] > dynamic_cast< ::sfx2::Metadatable* >(pBookmark)); * include/sfx2/digitalsignatures.hxx DigitalSignatures: > sfx2/source/doc/docfile.cxx:3999:25: error: suspicious dynamic cross cast from 'com::sun::star::security::XDocumentDigitalSignatures *' to 'sfx2::DigitalSignatures *' [loplugin:crosscast] > auto xModelSigner = dynamic_cast<sfx2::DigitalSignatures*>(xSigner.get()); * include/sfx2/sidebar/IContextChangeReceiver.hxx IContextChangeReceiver: > sfx2/source/sidebar/SidebarPanelBase.cxx:105:11: error: suspicious dynamic cross cast from 'pointer' (aka 'PanelLayout *') to 'IContextChangeReceiver *' [loplugin:crosscast] > = dynamic_cast<IContextChangeReceiver*>(mxControl.get()); * include/sfx2/sidebar/ILayoutableWindow.hxx ILayoutableWindow: > sfx2/source/sidebar/SidebarPanelBase.cxx:164:44: error: suspicious dynamic cross cast from 'pointer' (aka 'PanelLayout *') to 'ILayoutableWindow *' [loplugin:crosscast] > ILayoutableWindow* pLayoutableWindow = dynamic_cast<ILayoutableWindow*>(mxControl.get()); * include/sfx2/sidebar/SidebarModelUpdate.hxx SidebarModelUpdate: > sfx2/source/sidebar/SidebarPanelBase.cxx:189:40: error: suspicious dynamic cross cast from 'pointer' (aka 'PanelLayout *') to 'SidebarModelUpdate *' [loplugin:crosscast] > SidebarModelUpdate* pModelUpdate = dynamic_cast<SidebarModelUpdate*>(mxControl.get()); * include/sfx2/xmldump.hxx XmlDump: > svtools/source/misc/embedhlp.cxx:290:27: error: suspicious dynamic cross cast from 'com::sun::star::util::XCloseable *' to 'sfx2::XmlDump *' [loplugin:crosscast] > auto pComponent = dynamic_cast<sfx2::XmlDump*>(mxObj->getComponent().get()); * include/svl/stylesheetuser.hxx StyleSheetUser: > sd/source/core/stlsheet.cxx:294:48: error: suspicious dynamic cross cast from 'SfxListener *' to 'svl::StyleSheetUser *' [loplugin:crosscast] > const svl::StyleSheetUser* const pUser(dynamic_cast<svl::StyleSheetUser*>(pListener)); * include/svl/undo.hxx SfxRepeatTarget: > starmath/source/action.cxx:45:5: error: suspicious dynamic cross cast from 'SfxRepeatTarget' to 'SmDocShell &' [loplugin:crosscast] > dynamic_cast< SmDocShell & >(rDocSh).SetFormat(aNewFormat); * include/svx/ipolypolygoneditorcontroller.hxx IPolyPolygonEditorController: > sd/source/ui/view/drbezob.cxx:127:22: error: suspicious dynamic cross cast from 'sd::SmartTag *' to 'IPolyPolygonEditorController *' [loplugin:crosscast] > pIPPEC = dynamic_cast< IPolyPolygonEditorController* >( mpView->getSmartTags().getSelected().get() ); > sd/source/ui/view/drbezob.cxx:216:26: error: suspicious dynamic cross cast from 'sd::SmartTag *' to 'IPolyPolygonEditorController *' [loplugin:crosscast] > pIPPEC = dynamic_cast< IPolyPolygonEditorController* >( mpView->getSmartTags().getSelected().get() ); * include/vcl/IContext.hxx IContext: > vcl/source/window/builder.cxx:3650:54: error: suspicious dynamic cross cast from 'vcl::Window *' to 'vcl::IContext *' [loplugin:crosscast] > vcl::IContext* pContextControl = dynamic_cast<vcl::IContext*>(pCurrentChild.get()); * include/vcl/ITiledRenderable.hxx ITiledRenderable: > In file included from test/source/a11y/swaccessibletestbase.cxx:10: > In file included from include/test/a11y/swaccessibletestbase.hxx:22: > include/test/a11y/accessibletestbase.hxx:54:15: error: suspicious dynamic cross cast from 'com::sun::star::lang::XComponent *' to 'vcl::ITiledRenderable *' [loplugin:crosscast] > = dynamic_cast<vcl::ITiledRenderable*>(mxDocument.get()); * include/vcl/NotebookbarContextControl.hxx NotebookbarContextControl: > vcl/source/control/notebookbar.cxx:113:33: error: suspicious dynamic cross cast from 'vcl::Window *' to 'NotebookbarContextControl *' [loplugin:crosscast] > pContextContainer = dynamic_cast<NotebookbarContextControl*>(m_pUIBuilder->get<Window>(OUStringToOString(aName, RTL_TEXTENCODING_UTF8))); * include/vcl/gdimetafiletools.hxx MetafileAccessor: > vcl/source/gdi/impgraph.cxx:716:61: error: suspicious dynamic cross cast from 'drawinglayer::primitive2d::BasePrimitive2D *' to 'const MetafileAccessor *' [loplugin:crosscast] > const MetafileAccessor* pMetafileAccessor = dynamic_cast< const MetafileAccessor* >(pUnoPrimitive->getBasePrimitive2D().get()); * include/vcl/syswin.hxx VclBuilderContainer: > vcl/source/app/salvtables.cxx:7465:11: error: suspicious dynamic cross cast from 'vcl::Window *' to 'VclBuilderContainer *' [loplugin:crosscast] > = dynamic_cast<VclBuilderContainer*>(m_aOwnedToplevel.get())) * include/vcl/toolkit/field.hxx NumericFormatter: > vcl/source/window/builder.cxx:583:37: error: suspicious dynamic cross cast from 'vcl::Window *' to 'NumericFormatter *' [loplugin:crosscast] > NumericFormatter *pTarget = dynamic_cast<NumericFormatter*>(get(elem.m_sID)); * include/vcl/transfer.hxx DragSourceHelper: > svx/source/sdr/contact/sdrmediawindow.cxx:163:47: error: suspicious dynamic cross cast from 'vcl::Window *' to 'DragSourceHelper *' [loplugin:crosscast] > DragSourceHelper* pDragSourceHelper = dynamic_cast< DragSourceHelper* >( pWindow ); * include/vcl/transfer.hxx DropTargetHelper: > svx/source/sdr/contact/sdrmediawindow.cxx:126:47: error: suspicious dynamic cross cast from 'vcl::Window *' to 'DropTargetHelper *' [loplugin:crosscast] > DropTargetHelper* pDropTargetHelper = dynamic_cast< DropTargetHelper* >( pWindow ); > svx/source/sdr/contact/sdrmediawindow.cxx:145:47: error: suspicious dynamic cross cast from 'vcl::Window *' to 'DropTargetHelper *' [loplugin:crosscast] > DropTargetHelper* pDropTargetHelper = dynamic_cast< DropTargetHelper* >( pWindow ); * include/vcl/wizardmachine.hxx IWizardPageController: > vcl/source/control/wizardmachine.cxx:1274:46: error: suspicious dynamic cross cast from 'BuilderPage *' to 'IWizardPageController *' [loplugin:crosscast] > IWizardPageController* pController = dynamic_cast<IWizardPageController*>(pCurrentPage); * include/xmloff/settingsstore.hxx DocumentSettingsSerializer: > xmloff/source/draw/sdxmlimp.cxx:540:15: error: suspicious dynamic cross cast from 'com::sun::star::beans::XPropertySet *' to 'DocumentSettingsSerializer *' [loplugin:crosscast] > pFilter = dynamic_cast<DocumentSettingsSerializer *>(xProps.get()); > xmloff/source/draw/sdxmlexp.cxx:2474:41: error: suspicious dynamic cross cast from 'com::sun::star::beans::XPropertySet *' to 'DocumentSettingsSerializer *' [loplugin:crosscast] > DocumentSettingsSerializer *pFilter(dynamic_cast<DocumentSettingsSerializer *>(xProps.get())); * include/xmloff/xmlimp.hxx SvXMLImport: > sdext/source/pdfimport/sax/emitcontext.cxx:45:37: error: suspicious dynamic cross cast from 'com::sun::star::xml::sax::XDocumentHandler *' to 'SvXMLImport *' [loplugin:crosscast] > if (SvXMLImport *pFastHandler = dynamic_cast<SvXMLImport*>(m_xDocHdl.get())) > writerperfect/source/common/DocumentHandler.cxx:118:37: error: suspicious dynamic cross cast from 'com::sun::star::xml::sax::XDocumentHandler *' to 'SvXMLImport *' [loplugin:crosscast] > if (SvXMLImport* pFastHandler = dynamic_cast<SvXMLImport*>(mxHandler.get())) * reportdesign/inc/RptObject.hxx OObjectBase: > reportdesign/source/ui/report/ViewsWindow.cxx:843:53: error: suspicious dynamic cross cast from 'SdrObject *' to 'OObjectBase *' [loplugin:crosscast] > OObjectBase* pObjBase = dynamic_cast<OObjectBase*>(pObj); > reportdesign/source/core/sdr/ReportUndoFactory.cxx:30:25: error: suspicious dynamic cross cast from 'SdrObject *' to 'OObjectBase *' [loplugin:crosscast] > OObjectBase* pObj = dynamic_cast<OObjectBase*>(&rObject); > reportdesign/source/core/sdr/RptPage.cxx:62:29: error: suspicious dynamic cross cast from 'SdrObject *' to 'OObjectBase *' [loplugin:crosscast] > OObjectBase* pObj = dynamic_cast<OObjectBase*>(GetObj(i)); > reportdesign/source/core/sdr/RptPage.cxx:77:30: error: suspicious dynamic cross cast from 'SdrObject *' to 'OObjectBase *' [loplugin:crosscast] > OObjectBase* pBase = dynamic_cast<OObjectBase*>(GetObj(nPos)); > reportdesign/source/core/sdr/RptPage.cxx:116:28: error: suspicious dynamic cross cast from 'SdrObject *' to 'OObjectBase *' [loplugin:crosscast] > OObjectBase* pObject = dynamic_cast< OObjectBase* >(SdrObject::getSdrObjectFromXShape( _xObject )); > reportdesign/source/core/sdr/RptPage.cxx:184:32: error: suspicious dynamic cross cast from 'SdrObject *' to 'OObjectBase *' [loplugin:crosscast] > OObjectBase* pObjectBase = dynamic_cast< OObjectBase* >( pObj ); > reportdesign/source/core/sdr/ReportDrawPage.cxx:60:29: error: suspicious dynamic cross cast from 'SdrObject *' to 'OObjectBase *' [loplugin:crosscast] > OObjectBase* pBaseObj = dynamic_cast<OObjectBase*>(pObj); > reportdesign/source/ui/report/dlgedfunc.cxx:455:25: error: suspicious dynamic cross cast from 'SdrObject *' to 'OObjectBase *' [loplugin:crosscast] > OObjectBase* pObj = dynamic_cast<OObjectBase*>(_pOverlappedObj); > reportdesign/source/ui/report/SectionView.cxx:177:37: error: suspicious dynamic cross cast from 'SdrObject' to 'OObjectBase &' [loplugin:crosscast] > OObjectBase& rBaseObj = dynamic_cast<OObjectBase&>(*pObj); > reportdesign/source/ui/report/ReportSection.cxx:338:29: error: suspicious dynamic cross cast from 'SdrObject *' to 'OObjectBase *' [loplugin:crosscast] > OObjectBase* pObj = dynamic_cast<OObjectBase*>(pSdrObject); > reportdesign/source/ui/report/ReportSection.cxx:513:38: error: suspicious dynamic cross cast from 'SdrObject' to 'OObjectBase &' [loplugin:crosscast] > OObjectBase& rBase = dynamic_cast<OObjectBase&>(*pObject); > reportdesign/source/ui/report/ReportSection.cxx:644:33: error: suspicious dynamic cross cast from 'SdrObject *' to 'OObjectBase *' [loplugin:crosscast] > OObjectBase* pObj = dynamic_cast<OObjectBase*>(pDlgEdObj); > reportdesign/source/ui/report/ReportSection.cxx:663:35: error: suspicious dynamic cross cast from 'const SdrObject *' to 'const OObjectBase *' [loplugin:crosscast] > const OObjectBase* pObj = dynamic_cast<const OObjectBase*>(pDlgEdObj); > reportdesign/source/ui/report/propbrw.cxx:286:33: error: suspicious dynamic cross cast from 'SdrObject *' to 'OObjectBase *' [loplugin:crosscast] > OObjectBase* pObj = dynamic_cast<OObjectBase*>(pCurrent); > reportdesign/source/ui/report/ViewsWindow.cxx:843:53: error: suspicious dynamic cross cast from 'SdrObject *' to 'OObjectBase *' [loplugin:crosscast] > OObjectBase* pObjBase = dynamic_cast<OObjectBase*>(pObj); * sc/source/ui/inc/IAnyRefDialog.hxx IAnyRefDialog: > sc/source/ui/app/scmod.cxx:1607:42: error: suspicious dynamic cross cast from 'element_type *' (aka 'SfxDialogController *') to 'IAnyRefDialog *' [loplugin:crosscast] > IAnyRefDialog* pRefDlg = dynamic_cast<IAnyRefDialog*>(pChildWnd->GetController().get()); > sc/source/ui/app/scmod.cxx:1646:42: error: suspicious dynamic cross cast from 'element_type *' (aka 'SfxDialogController *') to 'IAnyRefDialog *' [loplugin:crosscast] > IAnyRefDialog* pRefDlg = dynamic_cast<IAnyRefDialog*>(pChildWnd->GetController().get()); > sc/source/ui/app/scmod.cxx:1697:42: error: suspicious dynamic cross cast from 'element_type *' (aka 'SfxDialogController *') to 'IAnyRefDialog *' [loplugin:crosscast] > IAnyRefDialog* pRefDlg = dynamic_cast<IAnyRefDialog*>(pChildWnd->GetController().get()); > sc/source/ui/app/scmod.cxx:1766:42: error: suspicious dynamic cross cast from 'element_type *' (aka 'SfxDialogController *') to 'IAnyRefDialog *' [loplugin:crosscast] > IAnyRefDialog* pRefDlg = dynamic_cast<IAnyRefDialog*>(pChildWnd->GetController().get()); > sc/source/ui/app/scmod.cxx:1813:42: error: suspicious dynamic cross cast from 'element_type *' (aka 'SfxDialogController *') to 'IAnyRefDialog *' [loplugin:crosscast] > IAnyRefDialog* pRefDlg = dynamic_cast<IAnyRefDialog*>(pChildWnd->GetController().get()); > sc/source/ui/app/scmod.cxx:1853:38: error: suspicious dynamic cross cast from 'element_type *' (aka 'SfxDialogController *') to 'IAnyRefDialog *' [loplugin:crosscast] > IAnyRefDialog* pRefDlg = dynamic_cast<IAnyRefDialog*>(pChildWnd->GetController().get()); > sc/source/ui/view/tabview3.cxx:470:30: error: suspicious dynamic cross cast from 'element_type *' (aka 'SfxDialogController *') to 'IAnyRefDialog *' [loplugin:crosscast] > IAnyRefDialog* pRefDlg = dynamic_cast<IAnyRefDialog*>(xDlgController.get()); > sc/source/ui/view/tabview3.cxx:2053:42: error: suspicious dynamic cross cast from 'element_type *' (aka 'SfxDialogController *') to 'IAnyRefDialog *' [loplugin:crosscast] > IAnyRefDialog* pRefDlg = dynamic_cast<IAnyRefDialog*>(pChildWnd->GetController().get()); > sc/source/ui/view/tabvwsh4.cxx:210:46: error: suspicious dynamic cross cast from 'element_type *' (aka 'SfxDialogController *') to 'IAnyRefDialog *' [loplugin:crosscast] > IAnyRefDialog* pRefDlg = dynamic_cast<IAnyRefDialog*>(pController.get()); * sd/source/filter/eppt/epptbase.hxx PPTExBulletProvider: > sd/source/filter/eppt/pptx-epptbase.cxx:497:74: error: suspicious dynamic cross cast from 'PPTWriterBase *' to 'PPTExBulletProvider *' [loplugin:crosscast] > maStyleSheetList.emplace_back( new PPTExStyleSheet( nDefaultTab, dynamic_cast<PPTExBulletProvider*>(this) ) ); * sdext/source/presenter/PresenterViewFactory.hxx CachablePresenterView: > sdext/source/presenter/PresenterViewFactory.cxx:218:36: error: suspicious dynamic cross cast from 'com::sun::star::drawing::framework::XResource *' to 'CachablePresenterView *' [loplugin:crosscast] > CachablePresenterView* pView = dynamic_cast<CachablePresenterView*>(rxView.get()); > sdext/source/presenter/PresenterViewFactory.cxx:274:23: error: suspicious dynamic cross cast from 'com::sun::star::drawing::framework::XView *' to 'CachablePresenterView *' [loplugin:crosscast] > = dynamic_cast<CachablePresenterView*>(iView->second.first.get()); > sdext/source/presenter/PresenterViewFactory.cxx:325:40: error: suspicious dynamic cross cast from 'com::sun::star::drawing::framework::XView *' to 'CachablePresenterView *' [loplugin:crosscast] > CachablePresenterView* pView = dynamic_cast<CachablePresenterView*>(xView.get()); * slideshow/source/inc/cursormanager.hxx CursorManager: > slideshow/source/engine/slide/userpaintoverlay.cxx:449:49: error: suspicious dynamic cross cast from 'CursorManager' to 'Slide &' [loplugin:crosscast] > dynamic_cast<Slide&>(rContext.mrCursorManager), * svx/source/inc/celltypes.hxx TableDesignUser: > svx/source/table/tabledesign.cxx:267:38: error: suspicious dynamic cross cast from 'com::sun::star::util::XModifyListener *' to 'TableDesignUser *' [loplugin:crosscast] > TableDesignUser* pUser = dynamic_cast< TableDesignUser* >( it.next().get() ); * svx/source/inc/tablemodel.hxx ICellRange: > svx/source/table/tablemodel.cxx:285:26: error: suspicious dynamic cross cast from 'com::sun::star::table::XCellRange *' to 'ICellRange *' [loplugin:crosscast] > ICellRange* pRange = dynamic_cast< ICellRange* >( rRange.get() ); * sw/inc/IDocumentUndoRedo.hxx IDocumentUndoRedo: > sw/source/uibase/shells/drwtxtsh.cxx:585:38: error: suspicious dynamic cross cast from 'SfxUndoManager *' to 'IDocumentUndoRedo *' [loplugin:crosscast] > auto* pUndoManager = dynamic_cast<IDocumentUndoRedo*>(GetUndoManager()); * sw/inc/IMark.hxx IFieldmark: > sw/source/core/doc/docbm.cxx:1415:15: error: suspicious dynamic cross cast from 'sw::mark::MarkBase *const' to 'IFieldmark *' [loplugin:crosscast] > : dynamic_cast<IFieldmark*>(*pFieldmark); > sw/source/core/doc/docbm.cxx:1437:16: error: suspicious dynamic cross cast from 'sw::mark::MarkBase *' to 'IFieldmark *' [loplugin:crosscast] > return dynamic_cast<IFieldmark*>(pFieldmark); > sw/source/core/doc/docbm.cxx:1570:37: error: suspicious dynamic cross cast from 'sw::mark::MarkBase *' to 'IFieldmark *' [loplugin:crosscast] > IFieldmark *pMark = dynamic_cast<IFieldmark*>(*aIter); * sw/inc/calbck.hxx BroadcastingModify: > sw/source/core/attr/swatrset.cxx:228:29: error: suspicious dynamic cross cast from 'const sw::BroadcastingModify *' to 'const sw::FormatDropDefiner *' [loplugin:crosscast] > auto pDropDefiner = dynamic_cast<const sw::FormatDropDefiner*>(pModify); > sw/source/core/txtnode/OnlineAccessibilityCheck.cxx:38:28: error: suspicious dynamic cross cast from 'SwNode *' to 'sw::BroadcastingModify *' [loplugin:crosscast] > auto* pBroadcast = dynamic_cast<sw::BroadcastingModify*>(m_pNode); * sw/inc/contentindex.hxx SwContentIndexReg: > sw/source/core/doc/DocumentRedlineManager.cxx:56:20: error: suspicious dynamic cross cast from 'SwNode *' to 'SwContentIndexReg *' [loplugin:crosscast] > assert(dynamic_cast<SwContentIndexReg*>(&pPos->GetNode()) * sw/source/core/inc/flowfrm.hxx SwFlowFrame: > sw/source/core/layout/frmtool.cxx:3044:35: error: suspicious dynamic cross cast from 'SwFrame *' to 'SwFlowFrame *' [loplugin:crosscast] > SwFlowFrame *pFlowFrame = dynamic_cast<SwFlowFrame*>(pSibling); * sw/source/uibase/inc/FrameControl.hxx ISwFrameControl: > sw/source/uibase/docvw/FrameControlsManager.cxx:283:15: error: suspicious dynamic cross cast from 'vcl::Window *' to 'ISwFrameControl *' [loplugin:crosscast] > mpIFace = dynamic_cast<ISwFrameControl *>( pWindow.get() ); * vcl/inc/IPrioritable.hxx IPrioritable: > vcl/source/control/NotebookbarPopup.cxx:40:37: error: suspicious dynamic cross cast from 'vcl::Window *' to 'vcl::IPrioritable *' [loplugin:crosscast] > vcl::IPrioritable* pChild = dynamic_cast<vcl::IPrioritable*>(GetChild(0)); > vcl/source/control/PriorityHBox.cxx:89:43: error: suspicious dynamic cross cast from 'vcl::Window *' to 'vcl::IPrioritable *' [loplugin:crosscast] > vcl::IPrioritable* pPrioritable = dynamic_cast<vcl::IPrioritable*>(pChild); > vcl/source/control/PriorityHBox.cxx:127:32: error: suspicious dynamic cross cast from 'vcl::IPrioritable *' to 'vcl::Window *' [loplugin:crosscast] > vcl::Window* pWindow = dynamic_cast<vcl::Window*>(pPrioritable); > vcl/source/control/PriorityHBox.cxx:142:32: error: suspicious dynamic cross cast from 'vcl::IPrioritable *' to 'vcl::Window *' [loplugin:crosscast] > vcl::Window* pWindow = dynamic_cast<vcl::Window*>(*pChildR); > vcl/source/control/PriorityHBox.cxx:186:43: error: suspicious dynamic cross cast from 'vcl::Window *' to 'vcl::IPrioritable *' [loplugin:crosscast] > vcl::IPrioritable* pPrioritable = dynamic_cast<vcl::IPrioritable*>(pChild); > vcl/source/window/NotebookBarAddonsMerger.cxx:128:19: error: suspicious dynamic cross cast from 'vcl::Window *' to 'vcl::IPrioritable *' [loplugin:crosscast] > = dynamic_cast<vcl::IPrioritable*>(pOptionalParent.get()); > ovcl/source/window/builder.cxx:3643:55: error: suspicious dynamic cross cast from 'vcl::Window *' to 'vcl::IPrioritable *' [loplugin:crosscast] > vcl::IPrioritable* pPrioritable = dynamic_cast<vcl::IPrioritable*>(pCurrentChild.get()); * vcl/inc/jsdialog/jsdialogbuilder.hxx BaseJSWidget: > vcl/jsdialog/executor.cxx:41:26: error: suspicious dynamic cross cast from 'weld::Widget *' to 'BaseJSWidget *' [loplugin:crosscast] > if (auto pJSWidget = dynamic_cast<BaseJSWidget*>(pWidget)) > vcl/jsdialog/executor.cxx:49:26: error: suspicious dynamic cross cast from 'weld::Widget *' to 'BaseJSWidget *' [loplugin:crosscast] > if (auto pJSWidget = dynamic_cast<BaseJSWidget*>(pWidget)) > vcl/jsdialog/executor.cxx:155:49: error: suspicious dynamic cross cast from 'weld::MenuButton *' to 'BaseJSWidget *' [loplugin:crosscast] > BaseJSWidget* pMenuButton = dynamic_cast<BaseJSWidget*>(pButton); * vcl/inc/unx/x11/x11gdiimpl.h X11GraphicsImpl: > vcl/unx/generic/gdi/salgdi.cxx:387:36: error: suspicious dynamic cross cast from 'pointer' (aka 'SalGraphicsImpl *') to 'X11GraphicsImpl *' [loplugin:crosscast] > if( X11GraphicsImpl* x11Impl = dynamic_cast< X11GraphicsImpl* >( mxImpl.get())) * xmlsecurity/inc/certificate.hxx Certificate: > xmlsecurity/source/helper/documentsignaturemanager.cxx:334:33: error: suspicious dynamic cross cast from 'com::sun::star::security::XCertificate *' to 'xmlsecurity::Certificate *' [loplugin:crosscast] > if (auto pCertificate = dynamic_cast<xmlsecurity::Certificate*>(xCert.get())) > xmlsecurity/source/helper/documentsignaturemanager.cxx:381:33: error: suspicious dynamic cross cast from 'com::sun::star::security::XCertificate *' to 'xmlsecurity::Certificate *' [loplugin:crosscast] > if (auto pCertificate = dynamic_cast<xmlsecurity::Certificate*>(xCert.get())) > xmlsecurity/source/component/documentdigitalsignatures.cxx:688:28: error: suspicious dynamic cross cast from 'com::sun::star::security::XCertificate *' to 'xmlsecurity::Certificate *' [loplugin:crosscast] > auto pAuthor = dynamic_cast<xmlsecurity::Certificate*>(xAuthor.get()); > xmlsecurity/source/component/documentdigitalsignatures.cxx:689:26: error: suspicious dynamic cross cast from 'com::sun::star::security::XCertificate *' to 'xmlsecurity::Certificate *' [loplugin:crosscast] > auto pCert = dynamic_cast<xmlsecurity::Certificate*>(xCert.get()); > xmlsecurity/qa/unit/signing/signing.cxx:130:29: error: suspicious dynamic cross cast from 'com::sun::star::security::XCertificate *' to 'xmlsecurity::Certificate *' [loplugin:crosscast] > auto pCertificate = dynamic_cast<xmlsecurity::Certificate*>(xCertificate.get()); Change-Id: If4f9efd8c012d0f650fe670450cf7ac0c8978036 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143458 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-25tdf#57423 drawinglayer: PDF/UA export: more Alt texts for SdrObjectsMichael Stahl
Currently /Alt texts are generated from ObjectInfoPrimitive2D, but this is only evaluated in VclMetafileProcessor2D::processGraphicPrimitive2D() so while it's created for every SdrObject, it's ignored in most cases. There doesn't appear to be a reason why this is done in processGraphicPrimitive2D() and not a more generic location, the special conditions that are checked there don't have anything to do with Alt texts, they effectively guard some optimisation done to bitmaps in PageSyncData::PlaySyncPageAct(). There is another issue in that not every SdrObject gets a StructureTagPrimitive2D, and even if there is a StructureTagPrimitive2D it may be ignored if it's in the background. The Alt text must only be produced if there is a structure element for the same SdrObject, else it would end up on some unrelated structure element. Fix all this by moving processing to a new function which checks that there is a current StructureTagPrimitive2D for a SdrObject in effect. The only problem with this is that previously Writer images produced Alt text, and now they don't - but Writer needs some fixing anyway. Change-Id: I2a362e8a9cd93e5bc817c6eed546c46b46e14980 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143189 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-11-22tdf#135638 drawinglayer,svx,sw: PDF/UA export: put SdrObjects on anchorMichael Stahl
... frame in the structure tree. The problem is that in sw, the anchored objects are painted outside of the call to paint the page frame, which is what generates the /Document structure element. For Writer fly frames, this is handled via their SwFlyDrawObj painting, where SwTaggedPDFHelper::CheckReopenTag() finds the anchor frame and temporarily sets it as the structure parent, even if it's on a previous page. But all the SdrObjects on a page are painted by 2 calls to PaintLayer() and there isn't a call back into Writer now. Somehow this even causes a spurious line like "/Document<</MCID 7>>BDC" to be emitted outside any PDF object, which looks clearly wrong. Try to extend the SdrObjUserCall to get a way to retrieve the anchor frame's structure element index. Another option would be to extend ViewObjectContactRedirector to return the PDF Id in its subclass SwViewObjectContactRedirector, and it seems possible since its only one caller is ViewObjectContact::getPrimitive2DSequence(), but Armin adivses that the ViewObjectContactRedirector might go away in the future so it's better to use SdrObjUserCall. It's annoying that the mapping is a static members of SwEnhancedPDFExportHelper; possibly it could be in OutputDevice's PDFExtOutDevData instead? Change-Id: Id61faae469aba4f0bd278ab2324aae06c1fdde64 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143027 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-11-18Turn around usage of TextHierarchyEditPrimitive2DArmin Le Grand (allotropia)
This primitive is created if a text edit is active and contains it's current content, not from model data itself. Pixel renderers need to suppress that content, it gets displayed by the active TextEdit in the EditView. Suppression is done by decomposing to nothing by default. MetaFile renderers have to show it, so that the edited text is part of the MetaFile, e.g. needed for presentation previews and exports. So take action here and process it's content. Note: Former error was #i97628# Change-Id: I32c83c0ad7883a79fc40f5a21ac6ed7b1055b7df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142910 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-11-16Use BitmapEx in BitmapPrimitive2DNoel Grandin
we no longer need to wrap it in the framework XBitmap implemenation Change-Id: I0dc56ad63364e2c5a4cedd5e70d4ae7ea7eae563 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142746 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-11-15Prepare createAlphaMask to produce mask and alpha as neededArmin Le Grand (allotropia)
Change-Id: Ica799419ed628f94f134433ca5b37518c5698909 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142730 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
generated by cgit (git 2.34.1) at 2025-02-06 15:31:50 +0000