SVG images incorrectly scaled (sometimes)

[kolalok]

I ran into a problem that images inserted by OOoLilypond are smaller than they should be.
(I was editing an older document and the reworked snippets shrunk by approx. 25% compared to those generated two years ago.)
After some trial and error it turned out it only happens when SVG is involved, PNG or EPS behave as expected.
I was using the "pdf to svg" route using the pdf2svg tool when I discovered the problem.
When I changed the conversion tool to Inkscape, the problem disappeared.

Here's a document that hopefully illustrates the difference in size between the various outputs.
ooolilypond.odt

I did some more checking and found this difference:
Inkscape's SVG has dimensions with units, e.g.:
<svg width="190pt" height="41pt" viewBox="0 0 190 41">

whereas pdf2svg (and lilypond -dbackend=cairo) produces the same numbers for the same input, but formats them without units:
<svg width="190" height="41" viewBox="0 0 190 41">

I believe the "pt" unit corresponds to a pixel at 72dpi.
In my understanding, if no unit is specified, LibreOffice Writer interprets the image within the environment DPI, which in my case happens to be 96dpi - and that's why the result is smaller, because it assumes smaller pixels.

I suggest at least adding a topic to your troubleshooting section with an advice to try inkscape as conversion tool when experiencing a problem with unexpected scaling.
Maybe a solution could be to preprocess the generated svg file and add the "pt" unit when none is specified?

Thanks.

My environment: Gentoo Linux, Sway (wayland), LibreOffice 7.5.6, OOoLilyPond 1.1.8, Lilypond 2.24.0, pdf2svg 0.2.3, Inkscape 1.2.2

[KlausBlum]

Thanks for your report and for the detailed analysis.

I'm on an Windows system and don't have this problem. But I remember a similar issue when I was experimenting with importing PDF graphics into LibreOffice - the result was depending on the system's DPI settings.

I'll care about the troubleshooting section.
Pre-processing the SVG files is probably beyond my abilities. But I could imagine an option to apply a scaling factor.

[KlausBlum]

Interesting...
I've checked under Windows 10, and both "svg [cairo]" and "pdf to svg" have the pt unit in the resulting svg file.
Looks like it's a Linux-specific problem.

Windows 10
LilyPond 2.24.3
poppler-0.68.0_x86

[KlausBlum]

Maybe it's not that complicated to add the missing "pt" unit to an svg file.
I'll see what I can do.

[kolalok]

Interesting...
I've checked under Windows 10, and both "svg [cairo]" and "pdf to svg" have the pt unit in the resulting svg file.
Looks like it's a Linux-specific problem.

I was intrigued, why exactly the tools would behave differently on different platforms.
It turns out that the difference might actually be related to the version of the Cairo library used.
Originally, the pt unit was hardcoded.
Sometimes around version 1.14 they made the unit configurable. But it had no effect on the output yet, because pt was initially kept as the default unit.
Then, quite recently with version 1.17.6, they changed the default to "user unit", i.e. only the number without a physical unit.

Some projects responded to the change (Inkscape did), some did not.

Sorry for the long story, my point is:

• an explanation why you still get the "pt" in your svg files, could be that perhaps you're lucky not to have the latest cairo dll
• more people may experience the problem in the future when the newer Cairo becomes more widespread

[KlausBlum]

Here is a new branch for an experimental version:
master...add_missing_unit

In short: Before inserting an svg file, this version checks for the presence of the "pt" unit and adds it if it's missing.
On the long term, I could imagine an option in the config dialog to switch this behavior on/off to prevent eventual troubles with that feature and to save unnecessary read/write operations that could take additional time.

OXT download:
https://github.com/OOoLilyPond/OOoLilyPond/releases/tag/v1.1.8%2Bdev01
Would you like to try and report back if it works for you?

[KlausBlum]

Sorry, I've uploaded the wrong OXT file... it's updated now. ;-)

[kolalok]

Impressive.

I tried it, works perfectly.
I agree it would be safer and future-proof to make it an optional feature.

[KlausBlum]

Should be solved by v1.1.9:
https://github.com/OOoLilyPond/OOoLilyPond/wiki/News#new-release-oly-119

Please feel free to re-open if any problems persist.

Cheers,
Klaus

[kolalok]

Brilliant, thank you.