Two svg import filters

classic Classic list List threaded Threaded
24 messages Options
Next » 12
Caolán McNamara Caolán McNamara
Reply | Threaded
Open this post in threaded view
|

Two svg import filters

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 ?

C.
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

Hi,

Am 04.11.2015 um 13:11 schrieb Caolán McNamara:
> 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 ?

svgio: Imports SVG as Graphic, keeps SVG unchanged, embedded in ODF, can
be exported again, can be broken to graphic objects to use/change
geometrically

filter/source/svg: New for me, seems to directly convert on XML-Base
from SVG to ODF by breaking at import time

future: Not sure, there are probably args for each. If you want to
preserve the SVG unchanged, svgio and a resulting ODF with one graphic
object and embedded original SVG might be preferred. Needs to be discussed.

>
> C.
> _______________________________________________
> LibreOffice mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

In reply to this post by Caolán McNamara
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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Tomaž Vajngerl Tomaž Vajngerl
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

In reply to this post by Caolán McNamara
Hi,

On Wed, Nov 4, 2015 at 1:11 PM, Caolán McNamara <[hidden email]> wrote:
> 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 ?

Both have its own uses. svgio is all about rendering fidelity and
supports more svg features however the "filter/source/svg" filter
tries to use standard features and attributes available in LO as much
as possible - which is useful when you want to edit the shapes . For
example you can see this with gradient shapes - svgio imports the
shape correctly but is useless if you want to change the gradient.

> C.

Regards, Tomaž
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
jan iversen-2 jan iversen-2
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters



On 4 November 2015 at 15:40, Tomaž Vajngerl <[hidden email]> wrote:
Hi,

On Wed, Nov 4, 2015 at 1:11 PM, Caolán McNamara <[hidden email]> wrote:
> 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 ?

Both have its own uses. svgio is all about rendering fidelity and
supports more svg features however the "filter/source/svg" filter
tries to use standard features and attributes available in LO as much
as possible - which is useful when you want to edit the shapes . For
example you can see this with gradient shapes - svgio imports the
shape correctly but is useless if you want to change the gradient.
But even so, it seems unwise to have 2 implementations, for sure larger parts are identical.

If there are significant differences in how the svg file is delivered into LO, it can be done with
a simple switch.

rgds
jan i.

> C.

Regards, Tomaž
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Fridrich Strba-3 Fridrich Strba-3
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

In reply to this post by Caolán McNamara
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/11/15 13:11, Caolán McNamara wrote:
> We have svgio which is being used for insert->image->from file and
> filter/source/svg which is being used for open file.

The first is renderer of the svg files. If you insert the file as you
mentioned, it will be stored as a svg file and svgio will render it
using the drawing layer.

The second is document importer. It imports the svg into Draw shape by
shape and mappable style property by mappable style property. The
result of such import (because there is no matching exporter) is
basically an odg file, since our importer API is internally using flag
ODF anyway.

> Which one is "the future", and what prevents us from using it in
> both places ?

There might be a possibility to share some code, I guess. Although, I
am not sure whether the parsers use the same approach. The
filter/source/svg one is basically constructing DOM and then several
"visitors" are running through the structure and extracting useful
information.

Cheers

F.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlY6KPMACgkQu9a1imXPdA9+lgCeL+2A2ccg/VqX8LeXGlVKoa8Q
fq8An3kNvcQz/A18dE3l33SPg4ocLd2c
=D+56
-----END PGP SIGNATURE-----
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
SOS SOS
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

In reply to this post by Armin Le Grand-2
 From a users point of view:
Inserting a SVG-image in Writer, Calc or Impress must been done
"unchanged" because users will in 99% off all cases not edit a Image.
Opening in Draw is a different game where in most cases the user has the
intention tot edit a image and  save back SVG or  as  a  other format.

A same sort of  filter who import a PDF as Graphic  in Writer, Calc and
Impress would be very nice to. Currently we need a third party app to
convert PDF to SVG  before we can insert a PDF-file into writer, Calc or
Impress

Greetz
Fernand


On 4/11/2015 13:30, Armin Le Grand wrote:

> Hi,
>
> Am 04.11.2015 um 13:11 schrieb Caolán McNamara:
>> 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 ?
>
> svgio: Imports SVG as Graphic, keeps SVG unchanged, embedded in ODF,
> can be exported again, can be broken to graphic objects to use/change
> geometrically
>
> filter/source/svg: New for me, seems to directly convert on XML-Base
> from SVG to ODF by breaking at import time
>
> future: Not sure, there are probably args for each. If you want to
> preserve the SVG unchanged, svgio and a resulting ODF with one graphic
> object and embedded original SVG might be preferred. Needs to be
> discussed.
>
>>
>> C.
>> _______________________________________________
>> LibreOffice mailing list
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>
> --
> ALG (PGP Key: EE1C 4B3F E751 D8BC C485 DEC1 3C59 F953 D81C F4A2)
>
> _______________________________________________
> LibreOffice mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

In reply to this post by Regina Henschel
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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Wols Lists Wols Lists
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

On 15/12/15 09:16, Armin Le Grand wrote:
> 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?

Why exactly are we doing (b)? Because we've got an LO editor for XML
graphics?

Then surely it makes sense to separate embedding graphics into a
document, from editing an embedded graphic. The SVG->XML converter
should be tied to the XML editor.

And could probably be deprecated as in "you should use an SVG editor if
your graphic is SVG". Yes, I know, lusers will say "I don't want to
learn another editor and I know the XML one" :-)

But imho it makes solid logical sense to tie converters to the
applications that use the conversion, and don't convert stuff that
doesn't need it, like when just embedding one document in another.

Cheers,
Wol
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Stahl-2 Michael Stahl-2
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

In reply to this post by Armin Le Grand-2
On 15.12.2015 10:16, Armin Le Grand wrote:
> 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.

the removal of code duplication sounds great!

> 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?

i don't claim to know anything about SVG, but i just noticed that
filter/source/svg uses boost::spirit, and therefore i am +1 for removing it.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Thorsten Behrens Thorsten Behrens
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

Michael Stahl wrote:
> i don't claim to know anything about SVG, but i just noticed that
> filter/source/svg uses boost::spirit, and therefore i am +1 for
> removing it.
>
That's so far the strongest case for removal here. ;)

Other than that, the two filters serve two very different purposes -
the document filter actually tries to map svg as well as possible to
ODF (it would work even better if LibreOffice's ODF filter would
support more of the syntax and semantics of SVG), to get *editable*
graphics.

As such, replacing the document importer with something that sticks
the image into a graphic object is missing the point IMO.

Cheers,

-- Thorsten

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (968 bytes) Download Attachment
Jan Holesovsky-4 Jan Holesovsky-4
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

Hi Thorsten,

Thorsten Behrens píše v Út 15. 12. 2015 v 23:46 +0100:

> Other than that, the two filters serve two very different purposes -
> the document filter actually tries to map svg as well as possible to
> ODF (it would work even better if LibreOffice's ODF filter would
> support more of the syntax and semantics of SVG), to get *editable*
> graphics.
>
> As such, replacing the document importer with something that sticks
> the image into a graphic object is missing the point IMO.

Armin wrote that svgio can "'break' to process/use the contained
geometries" - so my understanding was that it can be further editable;
is it not the case?  If not - how hard would it be to extend
drawinglayer to be able to "make something editable out of the contained
svg"?

All the best,
Kendy

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
SOS SOS
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

In reply to this post by Thorsten Behrens
+1 for Thorsten
For editing graphics there is Draw and  we need a filter who makes the original graphic editable
For publishing graphics there is Writer and  we need a filter who just imports and do not touch the original graphic
if the "one" filter can do both:  OK

Greetz
Fernand
ps. a filter who imports PDF in to Writer: +10


On 15/12/2015 23:46, Thorsten Behrens wrote:
Michael Stahl wrote:
i don't claim to know anything about SVG, but i just noticed that
filter/source/svg uses boost::spirit, and therefore i am +1 for
removing it.

That's so far the strongest case for removal here. ;)

Other than that, the two filters serve two very different purposes -
the document filter actually tries to map svg as well as possible to
ODF (it would work even better if LibreOffice's ODF filter would
support more of the syntax and semantics of SVG), to get *editable*
graphics.

As such, replacing the document importer with something that sticks
the image into a graphic object is missing the point IMO.

Cheers,

-- Thorsten


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Dennis Roczek Dennis Roczek
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi SOS,

Am 16.12.2015 um 10:54 schrieb SOS:
</snip>
>
> Greetz Fernand ps. a filter who imports PDF in to Writer: +10

We do already such. File --> open --> PDF (open in writer)


Regards,

Dennis Roczek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWcVVrAAoJEM4+Qf3OKrbZpGgQAMvDiTGxu/6WbzAObsuEZhz7
5AMhoMB+CijXmyf50Xz3YYsp5VbeAHTw1P/3rADhKpyhmKNylm33ax0OtFnLg41D
fJoQKtaEJcEcpOn0wz+1L9KMARj4OCsFpXw1Y93m1h0m14EQoROcUzNXC34JgblF
5b2Q/1dU27tB2BOGiKImHA9jJ7vGiFFEBzNJvIRIoGNvEM4LYPelw9J0JJgH1Guk
JO+S9wWC6tl7dyhjrIogz7L2q7Q16FCA3q7UH9dWYZXDg8ENl+FzUMu1eH+SlNTe
uKQRhYye1lJFnAJqELwVXLENFi7zpipZvriBxH2R8zcZS6n9PWbjPQtJVO3LVCa+
vmLWhN2I1KFGt9G1Y0tyAwKBOpukqQ2zspXcpLvTi/IrLT1HL32IE7Bu1i0pbdOo
ZcBox1Bo0r7uDI6MLbOpHpOz3hCIrLlxfRbwsYlFrgwZ4WS5oNvIxFHyuTbkXDUG
vWw3Rqd8VtGgUA4sVLVXb61qy6xciqzdM8wnKmeut35mo4PUHK9LZuMkLTh2UKCN
//vx3tBKUzWNvE49NTSPOa99c97njnzo9SlcfsBlt2nq619n202whHlZOI3ZzTbQ
LR8USESUID9FdKsLdSsLSHgYAGdiE3I53MCH7RbFoJISTtP0ZoPphjoCMy5zh8ps
dbOGyFqDfUI8Pg8oglxM
=6LGI
-----END PGP SIGNATURE-----
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
SOS SOS
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters


On 16/12/2015 13:13, Dennis Roczek wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi SOS,
>
> Am 16.12.2015 um 10:54 schrieb SOS:
> </snip>
>> Greetz Fernand ps. a filter who imports PDF in to Writer: +10
> We do already such. File --> open --> PDF (open in writer)
OK this is a filter who opens and makes a PDF "editable" in LO
what i love to have is a filter who places the PDF (1 page) unchanged as
a graphic in writer

Greetz

>
>
> Regards,
>
> Dennis Roczek
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWcVVrAAoJEM4+Qf3OKrbZpGgQAMvDiTGxu/6WbzAObsuEZhz7
> 5AMhoMB+CijXmyf50Xz3YYsp5VbeAHTw1P/3rADhKpyhmKNylm33ax0OtFnLg41D
> fJoQKtaEJcEcpOn0wz+1L9KMARj4OCsFpXw1Y93m1h0m14EQoROcUzNXC34JgblF
> 5b2Q/1dU27tB2BOGiKImHA9jJ7vGiFFEBzNJvIRIoGNvEM4LYPelw9J0JJgH1Guk
> JO+S9wWC6tl7dyhjrIogz7L2q7Q16FCA3q7UH9dWYZXDg8ENl+FzUMu1eH+SlNTe
> uKQRhYye1lJFnAJqELwVXLENFi7zpipZvriBxH2R8zcZS6n9PWbjPQtJVO3LVCa+
> vmLWhN2I1KFGt9G1Y0tyAwKBOpukqQ2zspXcpLvTi/IrLT1HL32IE7Bu1i0pbdOo
> ZcBox1Bo0r7uDI6MLbOpHpOz3hCIrLlxfRbwsYlFrgwZ4WS5oNvIxFHyuTbkXDUG
> vWw3Rqd8VtGgUA4sVLVXb61qy6xciqzdM8wnKmeut35mo4PUHK9LZuMkLTh2UKCN
> //vx3tBKUzWNvE49NTSPOa99c97njnzo9SlcfsBlt2nq619n202whHlZOI3ZzTbQ
> LR8USESUID9FdKsLdSsLSHgYAGdiE3I53MCH7RbFoJISTtP0ZoPphjoCMy5zh8ps
> dbOGyFqDfUI8Pg8oglxM
> =6LGI
> -----END PGP SIGNATURE-----

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

In reply to this post by Jan Holesovsky-4
Hi,

Am 16.12.2015 um 09:49 schrieb Jan Holesovsky:

> Hi Thorsten,
>
> Thorsten Behrens píše v Út 15. 12. 2015 v 23:46 +0100:
>
>> Other than that, the two filters serve two very different purposes -
>> the document filter actually tries to map svg as well as possible to
>> ODF (it would work even better if LibreOffice's ODF filter would
>> support more of the syntax and semantics of SVG), to get *editable*
>> graphics.
>>
>> As such, replacing the document importer with something that sticks
>> the image into a graphic object is missing the point IMO.
> Armin wrote that svgio can "'break' to process/use the contained
> geometries" - so my understanding was that it can be further editable;
> is it not the case?  If not - how hard would it be to extend
> drawinglayer to be able to "make something editable out of the contained
> svg"?

It is the case. Compare the following:

(a) Start LO, file/open, choose any SVG you want -> Draw opens, the SVG
gets represented as draw objects
(b) Start LO, open Draw, insert same SVG as graphic (D&D or
insert/graphic) -> SVG gets a single GraphicObject

With (b) you may now select, and choose 'break' in the context menu ->
SVG gets decomposed to draw objects. Compare the two results with your SVG.

Despite the quality being quite different, even when this would be
fixed, there will alwyas be slight differences. How do you explain a
user that the quality of the SVG he wants to use depends on the way he
uses it? Does anyone expect users to know the difference between opening
and inserting an SVG? How much do users like answers as 'yes, but you
added it in the 'wrong' way...'? There should be no wrong way. You
should not need expertise know-how to be able to use SVG in the best
possible quality.

Both do not allow round-trip, good-quality SVG editing, that is not the
role of LO. At least, (b) keeps the orig SVG as reusable data (context
menu, save graphic saves the *original* svg). Thus, you can edit it in
an external editor and re-add (or is there nowadays even a 'edit in
external editor', have seen that somewhere..?).

Even if someone wants to have the filter to 'edit' SVG the better
solution would be to automate (b) what means add the last step of
breaking up the object after load. I would not do that - let the user
choose if he wants to 'edit' the SVG. As long as we have no dedicated
SVG editing options, I doubbt many will use LO for that. What is indeed
useful is to re-use graphic data from SVGs for draw objects, that is
what 'break' offers.

Maybe the problem is more that only view people seem to know about
'break' - what about adding that more prominent/additionally under
'ungroup'...?

Still, I would opt for using one SVG filter/importer only.

>
> All the best,
> Kendy
>
> _______________________________________________
> LibreOffice mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

In reply to this post by Thorsten Behrens
Hi all,

Thorsten Behrens schrieb:

> Michael Stahl wrote:
>> i don't claim to know anything about SVG, but i just noticed that
>> filter/source/svg uses boost::spirit, and therefore i am +1 for
>> removing it.
>>
> That's so far the strongest case for removal here. ;)
>
> Other than that, the two filters serve two very different purposes -
> the document filter actually tries to map svg as well as possible to
> ODF (it would work even better if LibreOffice's ODF filter would
> support more of the syntax and semantics of SVG), to get *editable*
> graphics.
>
> As such, replacing the document importer with something that sticks
> the image into a graphic object is missing the point IMO.

I think, that one filter is enough and that LO should use svgio. In case
of File>Open and if you really want to make the graphic immediately
editable, then LO should insert the SVG in a new document as done by
Insert>Image and then break it automatically.

All effort and free time should be used to improve svgio and to
implement the missing ODF parts. For example the lack of the ODF
elements <svg:linearGradient> and <svg:radialGradient> is really bad. It
does not only effect SVG import but the OOXML filter too.

Kind regards
Regina

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Regina Henschel Regina Henschel
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

In reply to this post by Armin Le Grand-2
Hi Armin,

Armin Le Grand schrieb:
[..]
> Both do not allow round-trip, good-quality SVG editing, that is not the
> role of LO.

Why not?

  At least, (b) keeps the orig SVG as reusable data (context
> menu, save graphic saves the *original* svg). Thus, you can edit it in
> an external editor and re-add (or is there nowadays even a 'edit in
> external editor', have seen that somewhere..?).

The item "Edit with External Tool..." is in the context menu of the
image. In my case the browser is started to open the svg image. But LO
adds garbage in front of the svg source, so my browser shows an XML
error. Despite of the ... in the item label, no dialog opens to choose
the External Tool.

Kind regards
Regina
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Tor Lillqvist-2 Tor Lillqvist-2
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters


Why not?

Because there are better alternatives? Because we want to avoid feature creep; especially features that nobody seems to be ready to spend resources on?

(My *private* opinions only.)

--tml
 

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Armin Le Grand-2 Armin Le Grand-2
Reply | Threaded
Open this post in threaded view
|

Re: Two svg import filters

In reply to this post by Regina Henschel
Hi,

Am 18.12.2015 um 12:12 schrieb Regina Henschel:
> Hi Armin,
>
> Armin Le Grand schrieb:
> [..]
>> Both do not allow round-trip, good-quality SVG editing, that is not the
>> role of LO.
>
> Why not?

Don't get me wrong - I would love LO to be a SVG editor, in the same
sense that I would love it to be a pixel editor when a pixel graphic is
selected. Both would require much work to make it happen. In the case of
the pixel editor the pragmatic answer is to use an external tool, evtl.
triggered from the office. As long as we do not extensively add work to
get a good SVG edit roundtrip, the answer for now is the same for SVG.

>
>  At least, (b) keeps the orig SVG as reusable data (context
>> menu, save graphic saves the *original* svg). Thus, you can edit it in
>> an external editor and re-add (or is there nowadays even a 'edit in
>> external editor', have seen that somewhere..?).
>
> The item "Edit with External Tool..." is in the context menu of the
> image. In my case the browser is started to open the svg image. But LO
> adds garbage in front of the svg source, so my browser shows an XML
> error. Despite of the ... in the item label, no dialog opens to choose
> the External Tool.

The idea is good and this should be added to bugzilla as an error. This
should be possible for SVG and pixel graphics. If this runs well (and
opens the user's choosen default editor for the wnated purpose) we have
a good solution.

>
> Kind regards
> Regina
> _______________________________________________
> LibreOffice mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/libreoffice

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

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Next » 12