Created attachment 125387 [details] SVG graphic of a simple plot that is displayed incorrectly in DRAW and IMPRESS When importing the attached svg-file (written by python's matplotlib), the file is displayed differently in Impress and in Draw (but both are wrong): - The clipping of the graph is wrong - labels seem to be missing (Draw only) The attached png-file shows how it should look as rendered by matplotlib and firefox.
Created attachment 125388 [details] Correctly rendered graphics
Yes, there is a clipping issue, which is known. But what label is missing? It would be helpful if you add your LibO version. And what's wrong with the 'order of layers'?
LibO version is (as specified in the version combo box above) 5.1.3.2 The bug bit me under Windows 7 and Linux Mint 17. When I import the SVG file in DRAW, all labels are gone (i.e. axis labels, title lables, tick labels). When imported into IMPRESS, there is only the clipping issue. Maybe my bug title is misleading - I assumed the bug had something to do with a wrong order of the SVG layers: The unclipped plot data has to be in the SVG file (otherwise it couldn't be painted by DRAW :-) ). However, clipping works in Firefox, so I thought there might be some masking layer that is not displayed in the correct order. Of course, it could just be a problem with the <path clip-path= ...> commands ...
Depends on if you are inserting or opening the SVG... Here "import" is a rather imprecise term, and understand there are two completely different filters for handling SVG. One filter for when you open the SVG into Draw, and another for when you insert an SVG as an image into Draw, Impress or Writer. When inserted -- the filter fidelity is higher, but to edit the result, you must "break" the resulting image (from image context menu, or the main menu Modify -> Break). When opened -- the filter process breaks SVG elements into individual Draw element objects, handling of text and labels has poor fidelity. Work is ongoing to merge the two--eventually eliminating the separate opening filter. For now its use (e.g. opening into Draw) is not ideal--personally I avoid it. With this image, when inserted, the needed mask/clip-path handling for the trend line does not occur--but it is simple to break the image and adjust or clip the line ends.
Ah, thanks for the explanation - it was not a difference between DRAW and IMPRESS but between opening and inserting. The attached example has a very reduced complexity; the effort for manually clipping the graphs as a workaround (which I've done in the past) in real world cases is much higher for me.
Actually, I've added an opaque layer in most cases to hide data points instead of deleting them.
Created attachment 130901 [details] svg - no text (labels) shown on insert image 5.1.4.2 another example of text not being displayed with insert image svg.
*** Bug 109256 has been marked as a duplicate of this bug. ***
@Xisco, labeling seems OK now, should this be duped to one of the earlier SVG clip path issues? E.g. bug 97657 or bug 90168
Created attachment 142890 [details] svg in LO Draw 6.1 beta 2 looks good, but red line are too long and out of area =(
Dear mail, 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! Warm Regards, QA Team MassPing-UntouchedBug
it looks like a duplicate of bug 115017 *** This bug has been marked as a duplicate of bug 115017 ***
Reverting 5903235d57acb13d9d5286d23b443a01aeab9a3c would fix this issue. thus, duplicate of bug 97539 *** This bug has been marked as a duplicate of bug 97539 ***