Re: Two svg import filters

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.

As you might know, we have two SVG importers, (a) the one in filter 
which you are working on, and (b) one in svgio.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:


(a)Is
-Less capable than (b)
-More generic than (b)
-Does not keep (a) internally and unchanged
-Can support multiple-pages SVG docs (i guess?)


(b)Is
-More capable
-Converts to Primitives
-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
-Better integrated to the office ((everywhere where GraphicObjects are)
-Keeps the orig SVG, can be saved anytime using context menu on 
GraphicObjects
-Keeps the orig as graphic embedded in ODF (as all other graphics)


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.

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)

...What do you think?

Am 04.11.2015 um 15:30 schrieb Regina Henschel:
> Hi Caolán,
>
> Caolán McNamara schrieb:
> > 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 ?
>
> 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
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

--
ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)