Open attachment 193580 [details]. It will open in Draw, on a page roughly equal to 1x1 inch. Select the imported object (SVG), right-click, and break. The result is tiny objects in the top left corner, roughly 26 times smaller than original size (ratio is equal to (size of mm/100) / (size of CSS pixel)).
Regression in 7.5; was OK in 7.4.
Regression after commit 1fa731d03ba0f22cb9392a578124ea977eaab2e9 (tdf#150462 don't prescale dxarray before using DrawTextArray, 2022-08-22).
Confirmed, but how significant is breaking an SVG really, vs. the text spacing in a draw textbox object? Version: 24.2.2.1 (X86_64) / LibreOffice Community Build ID: bf759d854b5ab45b6ef0bfd22e51c6dc4fb8b882 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to V Stuart Foote from comment #3) > Confirmed, but how significant is breaking an SVG really, vs. the text > spacing in a draw textbox object? Not sure what is meant. If you consider any regression report as a call to revert the causing commit, then you are mistaken: most regressions are fixed by other means. Here, the likely cause is wrong handling of mapmode during metafile decomposition into Draw primitives - something that existed before the commit made use of the mapmode setting :-)
The "dancing" intra-word characters for sd text boxes (Impress or Draw) was far more annoying. So, obviously not a suggestion to revert. Just confirming the impact on what is a rare action on an inserted SVG (and then really only the text spans within it, so not a high impact regression--right?). Assumed there would be an alternative to revert.
I suspect that ImpSdrGDIMetaFileImport handles MapMode wrong. I suggest that as a possible code pointer to whoever knows enough about our metafile processing.