summaryrefslogtreecommitdiff
path: root/drawinglayer
AgeCommit message (Collapse)Author
2023-01-25tdf#153092 text appears missing with font sizes < 1Caolán McNamara
where the size is scaled up, so restore use of scaling up when necessary. But continue to use unscaled supplied values when provided integer sizes to avoid scaling down. Change-Id: I8de268d1c9ac8f0a75aa84e231812b12310db76a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146140 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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-17SDPR: use correct Viewport for sub rendererArmin Le Grand (Allotropia)
Change-Id: Ia10731fbe44c812120ed6594959ddee909568187 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145666 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
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-14Fix non-PCH buildThorsten Behrens
Change-Id: I70c82cece35585b7021c8adef835cc76112c68a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145512 Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-01-14tdf#152990 set the font after the MapMode is (potentially) setCaolán McNamara
Change-Id: I64617a5c85e7e6b444aac705ebbfdd777b4ea55a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145487 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
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-12loplugin:unnecessaryoverride (clang-cl)Stephan Bergmann
Change-Id: Ib0f721cb0bb7ebfd3b422cfb9e93804a70e1270b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145381 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-01-12drop internal support for 1-bit imagesNoel Grandin
on modern hardware, these are less efficient than regular alpha channels. Also, this greatly simplies the range of stuff that vcl needs to deal with, which will make the upcoming transparency->alpha patch easier to deal with. Enhance vcl::CreateFromData to convert incoming 1-bit data to 8-bit image. Change-Id: I35829da750029fe373d0d2911a669d10bab6ad23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145321 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-11rename BitmapEx::GetAlpha to GetAlphaMaskNoel Grandin
to ease the reading of code related to an upcoming patch to convert transparency to alpha, since there is already a GetAlpha in Color. Change-Id: I1af0f8f6dd94acfe4673c8556c7aff6c20da3f7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145209 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-01-06Fix typosAndrea Gelmini
Change-Id: Ia565446bab6436940954bc1af10f612cb9a9ad9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145152 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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-06Removed executable permission on source fileAndrea Gelmini
Change-Id: Ida56746e5f2442ceff86e19cf52467dc766a95ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145113 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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>
2023-01-04SDPR: sync with "Corrected some transformations in Direct2D renderer"Caolán McNamara
Change-Id: I19a652390e803f4c60466ce7796ddfeda2ef27c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145023 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-01-03SDPR: Corrected some transformations in Direct2D rendererArmin Le Grand (allotropia)
Change-Id: Icd478d61e0941edb6f3420267fe425ba1d5b8dc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144988 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-12-29cid#1518242 Logically dead codeCaolán McNamara
Change-Id: Ie0a426c207746cca19b652a51b6f567e4b9a0752 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144860 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-23SDPR: Add rendering of BitmapPrimitive2D for CairoCaolán McNamara
pretty nasty copy of bitmap data for split alpha and so on, head scratching for a while to figure out to scale the pattern matrix, but it seems to render ok Change-Id: I6c82953e3646556ece6b1a5a6b12b7f76b0d41c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144774 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-22-Wc++11-narrowing (clang-cl)Stephan Bergmann
("non-constant-expression cannot be narrowed from type 'double' to 'FLOAT' (aka 'float') in initializer list") Change-Id: I079ec4b6cc5e757e4082ebc6b9ae6d06065542eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144738 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22loplugin:redundantstatic (clang-cl)Stephan Bergmann
("salhelper::SimpleReferenceObject subclass being directly stack managed, should be managed via rtl::Reference, const primitive2d::PolyPolygonColorPrimitive2D") Change-Id: I53246ac9f1af1eb1d1ad91ef4d5f59dc19fd2825 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144742 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22loplugin:redundantstatic (clang-cl)Stephan Bergmann
Change-Id: I2bc5a6231c78e8a38dd65ec0310b0b2b68f6fb22 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144741 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22-Werror,-Wshadow (clang-cl)Stephan Bergmann
Change-Id: Ib73b837ea23c2292877e77772ac80ea88f99a713 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144737 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22loplugin:redundantfcast (clang-cl)Stephan Bergmann
Change-Id: Ie8fab41974392ddd3774b95ddee6c28e41cb5c36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144739 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-12-22Added names for new Primitives to idToString (II)Armin Le Grand (allotropia)
Change-Id: I43aa64afdd6b92beddc8484daa97babf4d6a6745 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144690 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-12-22Corrected errors when Blur effect was re-used in shadowArmin Le Grand (allotropia)
For GlowPrimitive2D and SoftEdgePrimitive2D I had to correct the view-dependent decomposition in the case where shadow was activated for the shape that was used. That creates an extra transformation, e.g. shadow offset, that needs to be taken into account, here by operating in discrete view- coordinates to solve the problem. NOTE: This is not needed for ShadowPrimitive2D itself when ShadowBlur is used due to the primitives this is based on are already handled with the needed offset. Change-Id: I87dd8db9467fbd27008d6154b78599f28057ce45 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144693 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-12-22Fix typoAndrea Gelmini
Change-Id: I996d18f76a04f822712687755b0ad51aa287d354 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144713 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
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-20Fix no-pch buildMike Kaganski
Change-Id: I913760fe4cb479ae1396512beed3b04e9275825f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144607 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.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-12-19remove dependency from drawinglayer to frameworkNoel Grandin
to try and untangle the dependency mess a little. This means (*) tunneling a piece of information from VCLXWindow via the XWindowPeer::getProperty method, so we do not need to directly call VCLXWindow. (*) moving some formpdf code from framework "down" to vcl, where the drawinglayer code can use it Change-Id: I2c1ff3e34941b3147e66cf0a2d0fdb13293e3aa2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144341 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-12-02tdf#152094 retain more accuracy from RefDevMode::MSO1Caolán McNamara
do it like this to avoid adding another mapmode and to keep things "the same" as much as possible Change-Id: I1965aa545646f2d27b950d6335b2f608c3e4e04b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143475 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-01drawinglayer: add StructureTagPrimitive to XML dumpMichael Stahl
Turned out to be unnecessary but why not add it. Change-Id: I8dac0f0d6ec47f98d540eb4f8c42830cd652f344 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143536 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-12-01tdf#135192 drawinglayer,svx: PDF/UA export: also tag TH for SdrTableObjMichael Stahl
There isn't really an indication of anything being a header row, but the table template application has a flag to apply special formatting to the first row, so let's use that as indication that it's a header row Change-Id: Ic361c84d9a1a4e91109d6f9d2cd626c9633b311f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143500 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-12-01OutputDevice::GetTextArray will always set the size of the vector anywayCaolán McNamara
Change-Id: I52f24e50455c0d480f8976ee63e442008c05c192 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143520 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-12-01Handle PolyPolygonGraphicPrimitive2D with used DefinitionRange correctlyArmin Le Grand (allotropia)
If the range which defines the bitmap fill is defined and different from the range of the defining geometry (e.g. used for FillStyle UseSlideBackground) this cannot be expressed in a SvtGraphicFill data package. Thus, just use decomposition here directly. See also tdf#149754 in drawinglayer/source/processor2d/vclpixelprocessor2d.cxx and the comment there for more info. Change-Id: I8e1b26fb2bf523e6fd7af1040166f8197747e7ea Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143503 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.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-23loplugin:unusedfields make some fields privateNoel Grandin
this is one of the secondary analyses this plugin performs Change-Id: Iaa4424c2396470c6f1df85b0290fbffdda35fa08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143177 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
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-22tdf#135638 drawinglayer: PDF/UA export: add BBox to FiguresMichael Stahl
PAC3 complains: "Figure" element on a single page without bounding box Also add Placement while at it. Change-Id: I3db11f5b38c46bc274e496c7ce6f0cde9dd11b01 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142902 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>
2022-11-13Fix typosAndrea Gelmini
Change-Id: Ic1fb0ea483954f2994a87e05f33b320da3795227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142661 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-11-13Adapted convertToBitmapEx to simpler BitmapEx creationArmin Le Grand (allotropia)
As long as not all our mechanisms are changed to RGBA completely, mixing OutDev with Alpha (2x VDev) and RGB target rendering is just too dangerous and expensive and may to wrong or deliver bad quality results (see comments in code for details). Nonetheless we need a RGBA result for convert to BitmapEx. Luckily we are able to create a copmplete and valid AlphaChannel using 'createAlphaMask'. Based n that we know the content (RGB result from renderer), alpha (result from createAlphaMask) and the start condition (content rendered usually against COL_WHITE). Tht makes it possible to calculate back the content, quasi 'remove' that initial blending against COL_WHITE. That is what the helper Bitmap::RemoveBlendedStartColor does. Luckily we only need it for convert To BitmapEx, not in any other rendering. This gives good results, it is in principle comparable with the results using pre-multiplied alpha tooling, also slightly reducing the range of color values where high alpha vlaues are used, but in areas that are highly transparent anyways. Also important is that this will work with RGB-based system-dependent renderers, too. The method before could only work with the VCL-based primitive renderers by principle (only there - by coincidence - OutputDevice with Alpha worked). NOTE: Had to re-add usage of *unused* alpha channel in convertToBitmapEx due to test SdPNGExportTest. It somehow creates an Alpha in Bitmap size when I *remove* Alpha in convertToBitmapEx, so I just keep it for now, it is created anyways, just wanted to make it sleeker. Change-Id: I12e47327f5793d6ed87e217a2355c608f528246f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142547 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-11-09ofz#53151 AbrtCaolán McNamara
Change-Id: I2ccc6cbee28da9f91698b470449fb76b7729f634 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142475 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit (git 2.34.1) at 2024-12-26 07:38:07 +0000