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)
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
