https://bugs.freedesktop.org/show_bug.cgi?id=42092

--- Comment #37 from [email protected] ---
...and, please, before moving to the AOO code to manage the svg, consider that
it does not work well at all.

1) When you insert an svg file in draw, if the svg file is complicated, the
operation takes ages.  With libreoffice now it is a snap.

To see how this goes, take a BW bitmap (e.g. the logo of a university). Let
inkscape trace it to svg. Try to use it. LO can manage it. But current AOO gets
horribly slow.

I may be wrong, but I think that this is because LO stores the svg, asks a
library to render a bitmap at an adequate resolution, caches it and uses that
for display. AOO converts the svg to its internal graphical object format,
which slows everything down a lot if the SVG is complicated.

In my opinion what LO does now is right. What AOO does is wrong. Indeed, there
should be the 'option' to convert svg to the internal object format for
editing, but that should not be done by default.

Most often you do not want to edit the svg. You want it just because it prints
well and scales well.

And using vectorized bitmaps so that they can be scaled is a *real* usage case.
IMHO it should not be broken.


2) When you insert an svg file in draw, if the svg file must be rendered at a
size that is smaller than the original one, with AOO it looks orribly. With
current LO it looks fine.

Basically this means that if you want to make presentations, that both display
and print fine, LO is currently an option, AOO is not.

If you have a presentation with an svg image, with LO the presentation looks
good and exports to PDF fine. With AOO it exports to PDF fine, but it looks
horrible in presentation.

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to