summaryrefslogtreecommitdiff
path: root/drawinglayer
AgeCommit message (Collapse)Author
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>
2022-11-08Update handling of AntiAliasing settings and processor2dArmin Le Grand (allotropia)
Currently SvtOptionsDrawinglayer::IsAntiAliasing() is used in the constructor of the VCL based processor2Ds to decide if AA is to be used or not. Using this inside the constructors makes it currently impossible to use a primitive renderer independent from these settings, except when changing these settings temporarily what may influence other renderings and is a hack. The setting SvtOptionsDrawinglayer::IsAntiAliasing() is intended to decide if LO shall use AA mode from user's perspective, this means for the EditViews of the Apps and some other occasions (previews, exports, conversions to bitmap, ...). This works currently since all visualizations for these purposes use newly constructed primitive renderers. But there is no way to use primitive renderers independent from that setting. For future renderers which might be used for other purposes this is not sufficient, there has to be a method to create a renderer using e.g. AA independent of the global setting. To allow that, move the deciding flag to the already used geometry::ViewInformation2D. To not change anything initially, use the global flag for now to init that default value at ViewInformation2D. I took the opportunity to adapt ViewInformation2D to no longer being read-only and not changeable, it uses internally an impl class based on cow_wrapper already anyways. Extending this would lead to the constructors getting even bigger, when usually only 1-3 values need to be changed and many usages want to copy an existing instance and modify it. Adapted that usages to a much smaller footprint. Up to this point this does not change anything, but move the usage of the SvtOptionsDrawinglayer to the defaults (constructors) of the involved class ViewInformation2D. Using this then in the primitive rederers should be safe and will allow to use a primitive renderer with or without AntiAliasing independent of the user setting, so also for non- EditView usages. Also already added the PixelSnapHairline setting, this will also be needed independent of user settings to have full freedom of usage. Unfortunately I cannot use SvtOptionsDrawinglayer methods ::IsAntiAliasing() or ::IsSnapHorVerLinesToDiscrete inside ViewInformation2D where I would need it. It's now in drawinglayercore and thus not linked against svtools (svt) anymore. Thus I have to do some forwarding mechanisms to get the correct values available in ViewInformation2D. Not nice, caused by creating drawinglayercore... Change-Id: I9f572ce67e5d86a242188bdc6d4ba7c9a12f6a9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142393 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-11-06Remove double functionalityArmin Le Grand (allotropia)
There was processorfromoutputdevice.cxx|hxx containing createBaseProcessor2DFromOutputDevice that does exactly the same thing as createProcessor2DFromOutputDevice in processor2dtools.cxx|hxx, so I removed one onf them to make handling of future changes easier. Change-Id: Id8d49d1572a1bc39f1d330a742d4697c8c030e75 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142320 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-11-02Fix typosAndrea Gelmini
Change-Id: I097aec3699f668c60a7cb18e2ad412a45ce43ad3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142182 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-11-02Improved code for PolygonStrokePrimitive2D::getB2DRangeArmin Le Grand (allotropia)
For extended discussion & background information please refer to the comments added to the code there. Had to handle view-dependent parts like the hairline different, do not buffer that case. It could be, but it's not expensive and would require to remember and check against the view-dependent part which was used to create the B2DRange initially. Change-Id: I10df46207990865c667d41f56aedb8f0956a1706 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142114 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-10-27tdf#123419 using glyph cache for drawinglayer renderingNoel Grandin
speeds up rendering by 5% or so Change-Id: I9feaae75cf2779adf06fcc2429be35ac88193ccf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141893 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-10-25tdf#148934 PDF/UA export: add Contents entry to Link annotationsMichael Stahl
* Specification: ISO 14289-1:2014, Clause: 7.18.5, Test number: 2 Links shall contain an alternate description via their Contents key as described in ISO 32000-1:2008, 14.9.3. These links are created all over the code, in some cases it's a bit dubious what the content/alt-text should be, but let's try to use the most suitable looking bit of text in whatever the context is. * Specification: ISO 14289-1:2014, Clause: 7.18.3, Test number: 1 Every page on which there is an annotation shall contain in its page dictionary the key Tabs, and its value shall be S. Change-Id: I7b63feb759f0c75047f854ed9997918f829a537e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141826 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-10-23tdf#151674 rotate text starting pointCaolán McNamara
Change-Id: Ibcfb4b102a58cad53c1ce5f569721e4557844b4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141673 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-10-18Added handling of transparence to BackgroundColorPrimitive2DArmin Le Grand (allotropia)
...which was missing in ::create2DDecomposition. Change-Id: I585aa884e4d19bf6f34783d254f502a4c3dd6733 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141470 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2022-10-13use OutputDevice clipping if its just a set of rectanglesCaolán McNamara
Change-Id: I249866d1aef29d256439c0437835a173d8a4c633 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141286 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-09-26tdf#151104 correct missing ColorModificationArmin Le Grand (allotropia)
Presentation still uses Metafiles as transfer for Graphic content, so uses VclMetafileProcessor2D. Unfortunately processPolyPolygonGraphicPrimitive2D does not support an active BColorModifierStack, so use the default as working fallback to create correct GraphicData for the Metafile. Change-Id: Ia439b241cb414667263ef653b507ad8b7fecde61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140550 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-23tdf#150551 for PDF export, use the decompositionArmin Le Grand (allotropia)
...for better gradient visualization, see task for details. Change-Id: Idccd569b0e95763f6dbf6ad0a2204b62460c66d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140354 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-21Fix typoAndrea Gelmini
Change-Id: I46f3ada5c155250b56ae3c8227587b741a8144dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140349 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2022-09-21tdf#151081 render rotated gradients correctlyArmin Le Grand (allotropia)
We have to use regular primitive decomposition when the gradient is transformed in any other way then just tanslate & scale. For more background, refer to the bugzilla task. Corrected some typos. Change-Id: Ic767c9fe6d14444915facc1247ba4ec1f79fd02e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140237 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-19Fix typosAndrea Gelmini
Change-Id: If33ae9acbc1ed17398584efa3574566b2d854b3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140149 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-09-19Make impBufferDevice faster againArmin Le Grand (allotropia)
When the Primitives for the Glow-Effects were added (modified ShadowPrimitive2D, SoftEdgePrimitive2D and GlowPrimitive2D) a modified version of impBufferDevice was created and used. That lowered the speed for drawing objects with transparence by about factor 2.5 and was unfortunately not only done for these Primitives, but for transprent objects in general. For the mentioned factor refer to: Patch to demonstrate former and now repaint differences https://gerrit.libreoffice.org/c/core/+/129301 After having reworked those Primitives to use another mechanism and being decomposed so they will work in all now and future renderers, it is possible to go back to that easier and faster method to render Transparency. For extended information, please take a look at the added comments, mainly in vclhelperbufferdevice.hxx Identified a still bad behaviour when objects use a TransparenceGradient. Corrected that and added (at this opportunity) a method 'createAlphaMask' along with 'convertToBitmapEx' which is now used in the GlowPrimitive2D & ShadowPrimitive2D which only need the AlphaMask to do their job anyways (I had commented there that thjis is possible before). That will be faster for visualizing those Primitives. Change-Id: Ieac880384de26960c2c4b8740a1dee1e15d7ac9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140022 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-16vcl: AnimationBitmap -> AnimationFrameChris Sherlock
The emphasis is not quite right. An animation is made up a sequence of *frames*, not bitmaps. A frame includes such things as position, size, timeout till the next frame *as well as* a bitmap. Note: had to regenerate a bunch of precompiled headers Change-Id: Ib1959452653857555f41e01ac0151d08c41a3b1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/76460 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-09-14Fix typoAndrea Gelmini
Change-Id: Ia6b1151d6a95cf797f8e13998e2ed372aaddb18f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139914 Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2022-09-14Rework of ShadowPrimitive2DArmin Le Grand (allotropia)
This is pretty much the same for ShadowPrimitive2D as the change for GlowPrimitive2D and SoftEdgePrimitive2D, so for more comments please refer to those commits: c2d1458723c66c2fd717a112f89f773226adc841 707b0c328a282d993fa33b618083d20b6c521de6 There are some needed differences due to ShadowPrimitive2D having existed longer and is used for non-blurred shadow for a long time and is used as unchanged as possible. Only for active glow of shadow is a buffering and local decompose used. Change-Id: I55e6516f59390079356ac16f24743b474e53fb05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139858 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-11basegfx: replace typedef with a class B2DSize based on Size2DTomaž Vajngerl
Change-Id: Id8b3c2bcf0bf4be5aba2812b0edda479bc20c6a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139683 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-09-10VclPixelProcessor2D doesnt need a pimplNoel Grandin
it is module private Change-Id: Ic9e648202f23e4a48e5485237c9956501e9c96da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139736 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-09-08Rework of SoftEdgePrimitive2DArmin Le Grand (allotropia)
This is pretty much the same for SoftEdgePrimitive2D as the change for GlowPrimitive2D, so for more comments please refer to commit c2d1458723c66c2fd717a112f89f773226adc841 Added suggested change of DoSaveForVisualControl mechanism Change-Id: I28901e7a0b6e1823000d2aa6a335ce2fd80e6ce3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139585 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-07Fix typoAndrea Gelmini
Change-Id: I4f4133ca077d69e3238aba809cd758455918bc39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139586 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-09-07ConvertToBitmapEx slightly too bright if transparency involvedArmin Le Grand (allotropia)
Stumbled about this error when working on re-designing the blend primitives for shapes. Using convertToBitmapEx is the base for these (also for the UNO API conversion from Primitives to BitmapEx). Use a VirtualDevice in the Alpha-mode now to solve it. This creates the needed alpha channel 'in parallel'. It is not cheaper though since the VDev in that mode internally uses two VDevs, so ressoure-wise it's more expensive, speed-wise pretty much the same (the former two-path rendering created content & alpha separately in two runs). The former method always created the correct Alpha, but when transparent geometry is involved, the created content was blended against white (COL_WHITE) due to the starting conditions of the content creation. There are more ways than using a VirtualDevice in the Alpha-mode, to do this correctly, but this is the most simple for now - and I was persuaded by the following argument: Due to hoping to be able to render to RGBA in the future anyways there is no need to experiment trying to do the correct thing using an expanded version of the former method. Change-Id: I23e005f9c3723059e2b88660fede09aa83844b38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139272 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-02tdf#136370 Very large Shape with pattern/hatch makes scrolling slowNoel Grandin
reduce some time spent in the 3-d rendering Change-Id: I5d622799bc101b5b988d382a039b5a3b03818d1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139256 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-09-01Added BufferedDecompositionGroupPrimitive2DArmin Le Grand (allotropia)
...and adapted GlowPrimitive2D to it as a preparation to use similar to BufferedDecompositionPrimitive2D, but for primitives based on GroupPrimitive2D. Change-Id: Ia1f9a09d4db09238ebbf6ad1303a4cdbdb8baedf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139099 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-09-01explicitly use BmpScaleFlag::NearestNeighbor when wantedLuboš Luňák
That is the algorithm that doesn't change colors, BmpScaleFlag::Fast works the same way only because it's mapped to this algorithm (which may not necessarily be the case forever). Change-Id: Ibebfff668eaa1da93963f8e8601fec51cfdfca34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139128 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-09-01fix limiting drawing of softedge effect (tdf#141981)Luboš Luňák
Apparently an empty viewport actually means everything should be drawn. Change-Id: I55ae453a8f264d48222ade48a2953ab7d97c7f79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139125 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-08-31Fix typoAndrea Gelmini
Change-Id: Iae97a43a18a8017e739eb2bb4275da6fa275aff3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139101 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-08-31Fix typoAndrea Gelmini
Change-Id: I18d696cbc5685778e23bf69ce99e044db25f9a55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139100 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-08-31Rework of GlowPrimitive2DArmin Le Grand (allotropia)
The new version does all needed stuff inside the GlowPrimitive2D implementation. Advantages are: - there is no need anymore to handle directly in the renderer implementations. That includes HitTest & future renderers, but also the currently existing fallback from MetafileRenderer to PixelRenderer - the buffered B2Primitive can re-use the last, potentially expensively cerated pixelation result - it checks for the possibility to do so using various aspects (see implementation, more would be possible) - it no longer uses impBufferDevice in the not wanted double-vdev/alpha-channel mode from presentation engine - it offers an example how to do all this with just a primitive (that can be replaced with another impl if needed without having to adapt any renderers). To support that, I added plenty of comments The group of GlowPrimitive2D, SoftEdgePrimitive2D and ShadowPrimitive2D use impBufferDevice in that much slower and expensive mode (two VDevs, processor-based alpha mixing). To get back to faster transparence rendering in general this is a 1st step, we also will need to re-work the other two mentioned primitives. The reworked one is now more efficient. Change-Id: I25c6fb970682b5311ce6f9ca4abf2702fb7c8862 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138973 Tested-by: Jenkins Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
2022-08-30Unify the two places dumping bimaps for debuggingMike Kaganski
Using the environment variable allows me to use a directory where no "access denied" happens on write access. Change-Id: Iffdd9b8566f2d794a6741b71d736d14d4643576c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139033 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-08-26crashtesting: avoid negative scalingCaolán McNamara
regression from commit 1fa731d03ba0f22cb9392a578124ea977eaab2e9 Date: Tue Aug 16 23:39:53 2022 +0100 tdf#150462 don't prescale dxarray before using DrawTextArray do the negative scaling checks as was done originally seen with: bugtrackers/odg/tdf35913-4.odg bugtrackers/svg/kde82509-1.svg bugtrackers/svg/fdo45001-3.svg Change-Id: I9eba78218d4676d60375fb9e9403be4e9bd5182a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138871 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-26automatically set TextRenderModeForResolutionIndependentLayout if we scaleCaolán McNamara
Always render glyphs with a mode suitable for rendering of resolution-independent layout positions if we scale the text positions. The idea being to typically continue to use the system defaults for font settings for UI elements, but where we are rendering into application canvases where there's a mapmode set then automatically use a good mode to render that. Change-Id: I0e5857e377da72ae1a2ede1d88d6408819fc9200 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138324 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-24cid#1510129 Logically dead codeCaolán McNamara
triggered by the recent flatten, but there since: commit 36f21914b31a28f75ec2195c266424a18408f747 Date: Tue Oct 29 17:40:43 2013 +0000 Resolves: i123564 corrected some aspects when working with bitmaps... with low color depth or small size Change-Id: I5f088c3f7096cc6f2efcd370943128d6667b2d0f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138762 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-22flatten logic in RenderFillGraphicPrimitive2D a littleNoel Grandin
splitting part of it out into a helper function Change-Id: I135ba5c6c823eec9f708b4652900e06fa06bbba7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138641 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-08-18tdf#150462 set mode to keep scaled glyph positions as floating pointCaolán McNamara
and match render settings to best support that Change-Id: I623f9e578ee6c3fe54a966342b3cdd16b31f219a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138450 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-18tdf#150462 don't prescale dxarray before using DrawTextArrayCaolán McNamara
setup the device scaling instead and pass in the unscaled dxarray and at least give vcl the chance to retain some accuracy Change-Id: I17660eb77adf8586be6eb54e61bded3a5bcc20a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138448 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-18Move tools/diagnose_ex.h to comphelper/diagnose_ex.hxxStephan Bergmann
...so that its TOOLS_WARN_EXCEPTION can be used in comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it, rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The comphelper module is sufficiently low-level for this immediate use case, so use that at least for now; o3tl might be even more suitable but doesn't have a Library until now. Also, for the immediate use case it would have sufficed to only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION, TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of include/tools/diagnose_ex.h into an additional new include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move the complete include file as is.) Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-08-17cid#1456603 Uninitialized scalar fieldCaolán McNamara
Change-Id: I301e6a111f63239b006d01834fb4b63f0d581b04 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138374 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-14tdf#104921: Cleanup Kashida insertion logicKhaled Hosny
Communicate Kashida insertion positions in an explicit way. Rest of LibreOffice communicate adjustments to character widths (e.g. for justification or spacing) using so-called DX array. DX array is an array of absolute character positions (e.g. DX[n] is the position after character n from the start of the lines, and its widths is DX[n] - DX[n-1]). This DX array is modified also when Kashidas are inserted after a given character for Arabic justification, by expanding its width. VCL would use this to know where to insert the Kashidas and how many ones. But because DX array is used for both widths adjustments and kashida insertion, this turns out to be a source of bugs since VCL has tosecond guess the DX array to find which is pure width adjustment and which also involves Kashida insertion, and the heuristics it uses are fragile. This change adds a second array of booleans that records where Kashida is inserted and communicates it all the way from where Kashida insertion is decoded in Writer and down to VCL layout. This change passes the Kashida array only when it seems necessary (e.g. during drawing but not when measuring text since the DX array is enough in this case). Hopefully no places where Kashida insertion needs to be passed down were missed. A couple of glyph and layout flags that were used for old heuristics and no longer needed and are removed. This also fixes: tdf#87731 tdf#106309 tdf#108604 tdf#112849 tdf#114257 tdf#127176 tdf#145647 tdf#146199 Change-Id: I4ed0850ef2fdc3e9143341afac649e7e7d463c39 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138068 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-14check SetOutputSizePixel for failureCaolán McNamara
Change-Id: If57dbbd7f04f0ee5286cf24a00480271bd4d9f76 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138237 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-07-21tdf#144916: expand range to avoid unwanted effects on viewport edgesMike Kaganski
This also allows to avoid clipping of impBufferDevice to the passed OutputDevice, because the expanded range couldn't otherwise be processed on the buffer device. Change-Id: I0d778365b09937c1a2ecee06477b0b17efcce44b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137296 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-07-21elide some makeStringAndClear() callsNoel Grandin
Change-Id: Ifd8de0042b843de0766a370fb19b9f7791974612 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137284 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-07-19Replace old png writer in converters.cxxofftkp
Change-Id: I360963c2ad36a7bce5a257c9740b1e5690efc8e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137116 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>