Created attachment 124782 [details] Testcase The attached simple SVG (no complex shapes, no gradients, rectangles circles and text), is broken when imported in writer as image. It would be nice if Libreoffice reserved first class attention to standard open future-proof formats before trying to salvage obsolete proprietary stuff.
Created attachment 124783 [details] Expected rendering
Created attachment 124784 [details] Actual rendering
Created attachment 124786 [details] Expected rendering
Also is "broken" in Mozilla Firefox, ImageMagic ImageDisplay, and has a few visual glitches in Inkview/Inkscape as well. However, confirmed as reported on Windows 10 Pro 64-bit en-US with Version: 5.1.2.2 (x64) Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US) and current master... Version: 5.2.0.0.alpha1+ Build ID: 07a641b110beee4f7c76617fcd6ed558025321a2 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-05-02_01:19:51 Locale: en-US (en_US)
Xisco, Armin, Joren A nice clean test file for you, no Inkscape crud. Of course opening it the import filter garbles it badly. But svgio does pretty well with it, but do see a few issues with anchoring locations for TSPANs, so something there. But seemingly no support for the SVG 1.2 Flowed Text <flowRoot><flowRegion><flowPara> etc. nesting. Looking at bug 50114 seems it was decided to not support Flowed Text as it was not valid to standard. Joren? A needed LO enhancement? Or, resolve won't fix?
(In reply to V Stuart Foote from comment #4) > Also is "broken" in Mozilla Firefox, ImageMagic ImageDisplay, and has a few > visual glitches in Inkview/Inkscape as well. Well, it opens perfectly there in inkscape (win 7 32bit & Linux 64bit) and almost perfectly in Firefox (Linux 64 bit, only missing the week days) Which is really impressive Firefox-side, given it's not really supposed to be a complex vector drawing viewer, I never tested it there before, and the file was created on windows 32bit
Please notice the sentence "Replacement of the previous flowing text proposal with a superset of the SVG 1.2 Tiny textArea feature." in https://www.w3.org/TR/SVG2/.
Oops, wrong link, look here https://www.w3.org/TR/SVG12/.
Thanks Regina. Unfortunately, the Inkscape project got out in front of the SVG 1.2 Full and implemented the Flowed Text proposals--then apparently skipped the SVG 1.2 Tiny handling of textArea. Meaning a lot of SVGs generated in Inkscape come into LibreOffice with the <flowRoot><flowRegion><flowPara> structures--e.g. the day of week lettering in the rectangular boxes on the calendar testcase SVG here--that for bug 50114 we simply ignore, guaranteeing broken rendering for SVGs coming from Inkscape. Is anyone plugged in to what Inkscape is considering? And we probably should have been parsing the Inkscape flowed text structure in solidarity with them (at least until they abandon it and move forward with whatever the W3C publishes as SVG 2). Seems the question now for LibreOffice becomes: should we continue to ignore the Inkscape Flowed Text images, or figure a way to parse them to canvas and convert them to SVG 1.1 text when saved or exported, or to implement Inkscape's methods and retain the source SVG. Then going forward, presumably implement the SVG 2 recommendations (either the content area & wrapping area of 10.5 [1], or figure out what to do with the the HTML5/CSS3 centric text "flows" through Exclusions or Regions [2]) and *how* to push this back out as compliant ODF. See some ugliness coming in chasing the emerging SVG "standards" =-as an aside-= Is there guidance from OASIS on where to take ODF as W3C drives content towards HTML5.1 and CSS3? It is a bit alarming in that many of the accessibility requirements (e.g. US Section 508, or European Standard EN 301 549) that apply to LibreOffice as a "user agent for authoring & media delivery" derive from the W3C's WCAG 2.0 [3] perspective--not from OASIS ODF standards. We are required by statute in many locations to be functionally compliant with the WCAG 2.0/UAAG 2.0 [4] guidelines. =-refs-= [1] https://www.w3.org/TR/SVG2/text.html#TextLayout [2] https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedback#Text_flow_to_arbitrary_shapes [3] Web Content Accessibility Guidelines - WCAG 2.0 [4] User Agent Accessibility Guidelines - UAAG 2.0
Created attachment 124808 [details] Testcase #2 BTW, apart from the "should LO support vector files created by the main current FLOSS vector app" (really? why is it a question when any obscure no longer used proprietary file must be handled), this variant of the tstfile opens perfectly in inkscape and Firefox bu not in writer
(In reply to Nicolas Mailhot from comment #10) OK sure, you've removed the majority of the flowed text (still have an L1 and an M annotation that don't show but have to be dealt with), what remains are know LibreOffice issues with positioning of SVG 1.1 text that are being worked on refining the svgio filter. The only substantive new issue with your samples was handling the Flowed Text, otherwise its a duplicate. The LibreOffice devs will decide what to do with this enhancement request for handling the filter import of Inkscape's Flowed Text--tackle it if feasible, or ignore it. Regards Flowed Text, have a read of Inkscape's recommendations to only use it internally: http://wiki.inkscape.org/wiki/index.php/Frequently_asked_questions#What_about_flowed_text.3F
still repro in LO 6.1 beta 2
Tested in Version: 7.4.0.3 (x64) / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 20; OS: Windows 10.0 Build 22000; UI render: Skia/Vulkan; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: threaded Looks better, but still wrong, see "Actual rendering 7.4.0.3".
Created attachment 182461 [details] Actual rendering 7.4.0.3
The issue with the attached document is not about how flowRoot is handled. In fact, if all flowRoot elements are removed from the sample document, the document is displayed the same way with Inskape, Firefox or Chrome.
Created attachment 188761 [details] testcase without flowRoot
(In reply to Xisco Faulí from comment #15) > The issue with the attached document is not about how flowRoot is handled. > In fact, if all flowRoot elements are removed from the sample document, the > document is displayed the same way with Inskape, Firefox or Chrome. In fact, flowRoot seems to be a Inskape only thing -> https://answers.launchpad.net/inkscape/+question/131312 The real problem with the attached sample files is about text alignment which was improved with 2795a230464aea3a792e67b5625fce2a0c01d547 but it's not perfect yet
And references to flowRoot in the codebase were removed with 2f17ce9ac89c1ad380bde39036000a1979f567bb because it was causing documents with flowRoot elements to be displayed incorrectly
The text problem seen in the sample files has been reported in bug 156616 Regarding the initial topic of adding support for flowRoot, I'm going to close this issue as RESOLVED WONTFIX, since flowRoot is not a stardard svg element