<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi List, this issue needs to be discussed. I put Regina and Xisco on direct CC to reach them. Xisco is so kind to fix errors on the SVG filter in the filter module and asks me for reviews (which I am happily ready to do), but this shows that eventually double work is done and we need to discuss. <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> As you might know, we have two SVG importers, (a) the one in filter which you are working on, and (b) one in svgio.<o:p></o:p> While (a) converts SVG to XML as input for loading it as ODF in the office, (b) loads a single SVG as graphic and adds/embeds it as such as content to a GraphicObject in any application. E.g. (a) is used when opeing an SVG, while (b) is used when D&D or insert graphic is used. Both have their usages, but there are differences. Let’s try to collect some:<o:p></o:p> <o:p> </o:p> (a) Is<o:p></o:p> - Less capable than (b)<o:p></o:p> - More generic than (b)<o:p></o:p> - Does not keep (a) internally and unchanged<o:p></o:p> - Can support multiple-pages SVG docs (i guess?)<o:p></o:p> <o:p></o:p> (b) Is<o:p></o:p> - More capable<o:p></o:p> - Converts to Primitives<o:p></o:p> - Further usable (paint, print, PDF export, 'break' to process/use the contained geometries, usable as FillStyle, generally in all office processing where GraphicObjects are used<o:p></o:p> - Better integrated to the office ((everywhere where GraphicObjects are)<o:p></o:p> - Keeps the orig SVG, can be saved anytime using context menu on GraphicObjects<o:p></o:p> - Keeps the orig as graphic embedded in ODF (as all other graphics)<o:p></o:p> <o:p> </o:p> It makes from my POV no sense to develop two SVG filters. It is extra work and users will be irritated when in one case the SVG looks different from other cases using the same SVG in te same program. It is also good to have a generic SVG filter like (a), but it culd use (b). Imagine (a) creating a draw doc with one page and placing the SVG as GraphicObject there, all done. For MultiPage SVGs that should be changed to create one page per SVG page with the adapted single-page SVGs as GraphicObject content. That would allow fast conversion, keeping generic and use a single SVG filter.<o:p></o:p><o:p> Due to this situation I would propose to: - work on changing the SVG importer (a) to creating simple docs with GraphicObjects containing the SVG as gereric format, not do own SVG conversion any longer - put thus created free time in improving/fixing (b) </o:p> ...What do you think?<o:p></o:p> <meta name="ProgId" content="Word.Document"> <meta name="Generator" content="Microsoft Word 15"> <meta name="Originator" content="Microsoft Word 15"> <link rel="File-List" href="file:///C:%5CUsers%5CArminL%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml">  <link rel="themeData" href="file:///C:%5CUsers%5CArminL%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx"> <link rel="colorSchemeMapping" href="file:///C:%5CUsers%5CArminL%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">  <style>  </style> <div class="moz-cite-prefix">Am 04.11.2015 um 15:30 schrieb Regina Henschel: </div> <blockquote cite="mid:563A1699.8010102@t-online.de" type="cite">Hi Caolán, Caolán McNamara schrieb: <blockquote type="cite">We have svgio which is being used for insert->image->from file and filter/source/svg which is being used for open file. Which one is "the future", and what prevents us from using it in both places ? </blockquote> I suggest to use svgio in both cases (as Apache OpenOffice does) for following reasons: - It is double work to maintain two import filters. The filter used for File > Open has a lot of bugs, and no one has fixed them. - The file-open filter automatically converts the svg-file, but ODF is not able to describe all features of svg. If the svg-file is only rendered as svg, then it is possible to show it more correctly. - The svgio filter keeps the svg-file, therefore no data is lost. - Because converting a svg-file to ODF will loose information, such converting should not be done automatically, but only on explicit user request. Kind regards Regina _______________________________________________ LibreOffice mailing list <a class="moz-txt-link-abbreviated" href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/libreoffice">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a> </blockquote> <pre class="moz-signature" cols="72">-- ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)</pre> </body> </html>