Hello, I edited the color of the attached "orig.svg" file with LibreOffice Draw, and the result can be seen in "edited.svg". It creates a sort of halo effect around what should be a simple filled rectange.
Created attachment 124072 [details]
original SVG file
Created attachment 124073 [details]
SVG after editing with LibreOffice draw and only changing the fill color
Hello, I doesn't see halo effect. Could you post a prinscreen? In which software do you see this effect?
Created attachment 124106 [details]
original SVG file opened in GIMP
Created attachment 124107 [details]
SVG after editing with LibreOffice Draw, opened in GIMP
Created attachment 124108 [details]
Halo effect as seen in an interface element
This SVG is for an interface element in the Cinnamon desktop environment. You can clearly see the "halo" effect created by the LibreOffice edit in this screenshot.
(In reply to S. from comment #5)
> Created attachment 124107 [details]
> SVG after editing with LibreOffice Draw, opened in GIMP
How do you open it in GIMP? It says unsupported file format.
Inkscape shows it fine.
Win 7 Pro 64-bit Version: 126.96.36.199.alpha0+
Build ID: b0e678c86136ef6d65cea66168a99217664c0278
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default;
TinderBox: Win-x86@42, Branch:master, Time: 2016-04-11_23:06:28
Locale: fi-FI (fi_FI)
Hi there, I just used the normal version of Gimp that ships with openSUSE Tumbleweed.
But then again, Gimp isn't meant for SVG. The reason I filed this bug is for a UI decoration for the Cinnamon desktop environment. It clearly looks wrong in the interface after editing it with LibreOffice. (See attachment https://bug-attachments.documentfoundation.org/attachment.cgi?id=124108)
GIMP on Linux works.
For the original, it offers import settings width: 28, height: 4.
For the modified one, if offers import settings width: 35, height: 5.
If you use 28x4 for the modified one as well, there is no problem.
In the original <svg> element there are the attributes width="28" height="4".
In the modified one there is only stroke-width="28.222".
I will ask devs.
(In reply to Buovjaga from comment #9)
> In the modified one there is only stroke-width="28.222".
I made a mistake: there are width and height, but they are given in millimeters.
It seems to me that Draw does not take given DPI information into account.
Normal screen DPI is 72, DPI in orig.svg is 90, 72/90 = 0.8.
35/28 is 1.25, which is 1/0.8: if the DPI is smaller, it means the pixels are taking up proportionally larger area.
I don't know SVG format, and how important DPI is. Considering it's a vector format, and DPI is for raster images, probably not much, but of course if it's imported in a raster editor like GIMP, then it becomes important. I'm just not sure if there's any possible kind of interfacing when it comes to conversion.
Note that there's a bug report in Inkscape for using 90 DPI when saving SVGs regardless of default units set:
(as I read, the 90 DPI comes from CSS 1 specification)
I'd tentatively say Draw could keep units in original file in mind, but that's not a huge issue.
However, there are bugs, see my next comment.
Repeat steps described in Description, and export orig.svg as a new file, in the meantime observe that position and size differs in the sidebar compared to right click -> Position and Size...:
-sidebar: 0.07 cm / 0.00 cm / 0.84 cm / 0.00 cm (horizonal position / vertical position / width / height)
-right click menu: 0.07 cm / 0.07 cm / 0.85 cm / 0.07 cm (position X / position Y / width / height)
=> issue (1)
Open exported SVG, and notice that the position and size changed (only listing numbers from right click -> Position and Size...):
-right click menu: 0.09 cm / 0.09 cm / 1.06 cm / 0.09 cm (position X / position Y / width / height)
=> issue (2)
Tester with LO 188.8.131.52 / Windows 7.
Since these are new issues, requesting confirmation.
(In reply to Aron Budea from comment #12)
> Tester with LO 184.108.40.206 / Windows 7.
> Since these are new issues, requesting confirmation.
Open orig.svg in 220.127.116.11 (LibO fresh)
0.07/0.00/0.84/0.08 (Sidebar Ho/V/W/He)
0.07/0.07/0.85/0.07 (Dialog X/Y/W/H) <- difference sidebar/dialog confirmed
Export to new.svg, restart Draw and open new.svg
Open orig.svg in 18.104.22.168 (Build ID: 7000e1a0640156645252d15d505949bff3d1eb4a)
0.07/0.00/0.84/0.00 <- Regression issue confirmed
0.09/0.00/1.07/0.00 <- Regression issue confirmed
(Not sure what this has to do with Editing single fill color in SVG distorts image, so keep it unconfirmed)
CPU Threads: 8; OS Version: Linux 4.6; UI Render: default;
Locale: de-DE (de_DE.UTF8)
Thanks for testing, Heiko!
For the issues with Sidebar's numbers, I've opened bug 100632.
Regarding the size change, what is displayed upon reopening is a regression, but I wonder about the width/height in the exported SVG, 9.88mm/1.41mm corresponds to 28px/4px at 72 DPI, which isn't correct, and it's been like that since 3.3 (though there the exported SVG was a lot different). If that was rectified, that might affect GIMP's default behavior as well.
To have the exact regression in a single comment (pruned the part that belongs to the other bug report, disregard the incorrect 0 values):
> Open orig.svg in 22.214.171.124 (LibO fresh)
> 0.07/0.00/0.84/0.08 (Sidebar Ho/V/W/He)
> Export to new.svg, restart Draw and open new.svg
> 0.07/0.00/0.84/0.08 (Sidebar)
> Open orig.svg in 126.96.36.199 (Build ID: 7000e1a0640156645252d15d505949bff3d1eb4a) <= or 188.8.131.52
> 0.09/0.00/1.07/0.00 <- Regression issue confirmed
(0.07 -> 0.09, 0.84 -> 1.07)
Export to PNG produces a blurry raster graphic ('halo effect') while the same operation done with Inkscape results in sharp edges. Renaming the bug accordingly since SVG is loaded and processed without problems.
'needsConfirmationAdvise' is only used for unconfirmed bugs. Removing it from this bug.
Bisected with bibisect-win32-5.2 to https://cgit.freedesktop.org/libreoffice/core/commit/?id=33e49a3b6655c1503dc81b583f5016fc3b2fda19
commit 33e49a3b6655c1503dc81b583f5016fc3b2fda19 (patch)
parent 49a32f4b2f1773df353bfd05af2f81d560025d18 (diff)
tdf#96046 SVG: use the same PPI as in svgio
Adding Xisco to CC
Xisco: see comment 14's "To have the exact regression in a single comment"
I don't know why Heiko changed the topic to PNG. I bisected SVG exporting.
Adding Cc: to Xisco Fauli
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!