Steps to reproduce: 1. Open attachment 194884 [details] from bug 161720 -> Some elements like the text are not displayed. See attachment 194862 [details] for reference. Reproduced in Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: fe7fe79feef8561d1cbd731d1bd53357eef902be CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded
Hi Armin, If I bisect this issue with TEST_SYSTEM_PRIMITIVE_RENDERER=1 the bisection points me to commit e7186b49a9a0b24ddc3b1c5384b5d9facb03518c Author: Xisco Fauli <xiscofauli@libreoffice.org> Date: Fri Jan 26 15:10:58 2024 +0100 tdf#158445: support viewBox in symbol elements but if I don't use TEST_SYSTEM_PRIMITIVE_RENDERER=1 then the issue is not reproducible with that commit, which suggests the mentioned commit just uncovered a previous cairo issue. Could you please take a look ?
Created attachment 198236 [details] Linux (Cairo) vs Windows
Confirm with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cac9c7db6257b27724d90d4a355e52e456ef7e08 CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Works in Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: cs-CZ Calc: threaded
Confirm with my working version: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 99ec4b258685672c7bfad847c0abbb8b10474fc8 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Happens with e.g. new Draw/insert Image, but also when opening directly as svg. In both cases 'Break' in context menu makes the missing stuff visible, so all imported and interpreted correctly... When using DISABLE_SYSTEM_DEPENDENT_PRIMITIVE_RENDERER=1 it gets shown correctly -> very strange but *has* to be a difference in rendering - even if the primitives from the imported svg are the same...
In SvgSymbolNode::decomposeSvgNode a mapping called aEmbeddingTransform is created based on aRange that again being based on maX/maY/maWidth/maHeight. In the case of the bugdoc all these values are zero (0), thus the mapping maps whatever is there to a range with width/height zero. For all four values (maX/maY/maWidth/maHeight) mbSet is false, so these were not imported. I guess in that case such a mapping should not be created...? If I force fWidth/fHeight to non-zero all looks good (used 100 and 1 to check, seems not to really have influence...?). This mapping to scale width/height to zero happens independent of a renderer - should probably not be like that...? That something gets painted in VCLPixelRenderer seems to be the case since the test to not need to paint anything are not that strict as in CairoSDPR renderer I guess...
Since the content is scaled to width/height both zero CairoSDPR is correct in this case. Problem is that VCLPixelRenderer is rendering something that has no size and thus no area and is invisible. @Xisco: What is SvgSymbolNode supposed to do when no x/y/w/h is given? Use the ones from the imported content...? We have to fix what SvgSymbolNode::decomposeSvgNode does when x/y/w/h is *not* provided...
Also looks like SvgSymbolNode::decomposeSvgNode adds the geometry twice - it gets imported to rTarget and then the embedding which embeds rTarget is appended. That explains why it gets painted in VCLPixelRenderer. If the geometry contains transparency and a size is given it should show wrong/too strong appearance in respect to transparency in older versions due to imported/added/painted twice. It needs to be added only once and only if worthwhile. Doing changes...
Proposed fix at https://gerrit.libreoffice.org/c/core/+/179831
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6700b311310a94e0de8123b307275cd553bb0d9b tdf#164434 Correct SvgSymbolNode SVG import It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/b0323cf3a358a56a425c2d735ebc7b602b7c83f4 tdf#164434 Correct SvgSymbolNode SVG import It will be available in 25.2.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.