Created attachment 122362 [details] screenshot Steps: 1) Open Writer 2) Insert https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/circles1.svg 3) Parts of the 3 overlapping circles are cropped When opening the svg in inkscape, all of the 3 circles are outside of the canvas area, but as LO isnt following this and is showing the circles, it should show them correctly. Version: 5.2.0.0.alpha0+ Build ID: 513d5c5781ec14f8512432f31290a3d54c8d57df CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-02-01_10:25:20 Locale: en-US (en_US.UTF-8)
Tested 4.3.7 and all of the shape appears and in 4.4.7.2 the crop is there.
I can confirm with Version: 4.5.0.0.alpha0+ and Version: 5.2.0.0.alpha0+
Another example of content being cropped is https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/DroidSans.svg as 'SVG Open 2009' isnt being displayed.
Created attachment 122491 [details] expand the canvas if needed The example has neither width/height attribute nor a viewBox attribute on the outermost svg element to define the size of the canvas. Therefore the content is taken to define the size of the canvas. I agree, that the result would be nicer, if we expand the canvas, so that the complete object is visible. We can add the amount given by left/top of the content. A negative value there would then result in the same kind of clipping, you see in the browser. I have attached a patch, so that you can already test my proposal. Today it is to late in the night for me to work with Gerrit.
(In reply to Regina Henschel from comment #4) > The example has neither width/height attribute nor a viewBox attribute on > the outermost svg element to define the size of the canvas. Therefore the > content is taken to define the size of the canvas. Yes the problem is with the missing viewBox attribute. > I agree, that the result would be nicer, if we expand the canvas, so that > the complete object is visible. We can add the amount given by left/top of > the content. A negative value there would then result in the same kind of > clipping, you see in the browser. I dont see nay clipping in any browser i use (Opera, Firefox, Chromium) > I have attached a patch, so that you can already test my proposal. Today it > is to late in the night for me to work with Gerrit. Pushed: https://gerrit.libreoffice.org/22267 We also have instances when the viewBox is cropping the image, when it shouldnt, like the below SVGs, so what should be done then? https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/mail.svg https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/msft.svg
Example of an SVG which only has a height attribute and it gets cropped. https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/tiger.svg
Yes, we need to have a closer look at all those cases, where the needed information is not complete. So this issue needs to keep open. Abandon the patch?
Some further references https://lists.w3.org/Archives/Public/www-svg/2013Dec/0093.html https://svgwg.org/svg2-draft/single-page.html#coords-IntrinsicSizing https://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width
(In reply to Regina Henschel from comment #7) > Yes, we need to have a closer look at all those cases, where the needed > information is not complete. So this issue needs to keep open. Abandon the > patch? I had been pondering what would be a good scenario to tackle this problem and think that browsers do maybe the best solution - show everything. The beauty of this is that a user can crop out stuff that they dont want to see in the image. Then if the viewBox or width/height attributes are larger than the bottom right cropped area, they would be used.
Created attachment 122641 [details] proposed patch version 2 Next version of patch. Test files will follow. I do not think, that browsers are appropriate examples, because browsers do not insert but open the file. I agree, that it is more user-friendly to insert the image without cropping in case width and height are missing. But I think cropping should be down if e.g. the height is given. Another problem is, what LO should do, if the file is opened. It is possible to do not crop at all, but take the size of the contained drawing elements. That is around "bool bDoCorrectCanvasClipping(true);" But I don't know, whether it will be possible to get the information "file is opened" to the method in svgsvgnode.cxx. Further problem: The attribute "overflow" is not implemented yet for the svg element.
Created attachment 122642 [details] Examples for missing width, height, viewBox The container has eight examples. My ideas are: If viewBox is given, then it determines an aspect ratio of the image. This is used to calculate a missing height/width based on the given width/height. Then map the image to the viewport same as in case both height and width are given. In case width and height are both missing, but viewBox exists, show the whole content and expand its bounding box, so that the intended ratio is fulfilled. If viewBox is missing, then a given height/width is respected. For the unknown direction the content is used. So the image is cropped to the given height/width but shown completely in the other direction. In case all is missing, the bounding box of the content is used.
Created attachment 122643 [details] Test cases for additional bug The release version has a bug in case the height is missing and a viewBox is given. It uses the wrong ratio of the viewBox. Use the test file in a release version to see the error. The patch contains a fix for that in addition.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a2d8a9873deb5b39198c346cf637a9a8cb9e5105 tdf#97538 no cropping if width, height and viewBox missing It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c465c259c617e30b01c5ea25b5203a605cd4269 tdf#97538: SVGIO: Add unittest It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Faulí committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=af46264bccbc16bf1edf9c5cbe944a4b883a1353 Revert "tdf#97538: SVGIO: Add unittest" It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Version: 5.2.0.0.alpha0+ Build ID: ed51d4293dd919a03edca11ec48c607bbfa31076 CPU Threads: 2; OS Version: Linux 4.2; UI Render: default; TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2016-03-07_00:33:34 Locale: en-US (en_US.UTF-8)