https://bugs.freedesktop.org/show_bug.cgi?id=42092
--- Comment #40 from stfhell <stfh...@googlemail.com> --- (In reply to comment #36, comment #37, comment #38, comment #39) I really think you are being too harsh towards the new code. It is new and was released very early in AOO because the existing SVG code could not be used under the more permissive Apache license. But consider that Apache is working on a complete rewrite of the drawing layer of the suite (to be released next year) - I'm sure this will be a pretty exciting thing. Current support for SVG is not at all good in LO. It uses a mature external library to render it, which is why SVG renders fairly well as bitmap now. But LO does not _really_ support SVG as vector. Try to open a non-trivial SVG (like one of the Wikimedia maps) via File/Open. You get an unusable, crippled version in LO Draw, and a correct and editable version in AOO 3.4.1. AOO opens SVG as a set of vector drawing elements and gives you access to them. LO opens the SVG more as a complete whole; you need to use a different program to edit it, Draw won't do. That is why LO is a bit faster on import of SVG, it just renders it en bloc as a bitmap. (I'm saying "a bit" because on my system AOO import does not perform too badly; maybe you shouldn't base your experiments on a vectorized bitmap.) So I think it is high time to add true SVG support to LO/AOO. SVG is a much too important file format to support it half-heartedly. A vector drawing program that doesn't allow editing a standard vector graphic format is unthinkable in the long run. The current AOO code still has rendering bugs, but it will mature, and until it is mature, EPS could provide an acceptable workaround for complex vector graphics output. (I noticed that export to postscript is still possible under Linux, you can configure it in the printer properties.) Maybe LO developers will not activate the new code until it renders better. But you shouldn't consider the current behaviour of LO 3.5/3.6 as a classical bug. Conversion of SVG to SVM (the older method) is not a satisfactory solution - it provided vector output, but SVM is an old, proprietary StarDivision file format. And rasterizing SVG (the current method) is not a good solution as well - but it is a transitory step to proper SVG support, and an acceptable one because it allows embedding of real SVG instead of SVM into ODF, which means future software versions will be able to handle the same files better. I believe that the new SVG code is planned for the LO 4.0 release, but I'm not sure. If it proves not good enough for you right from the start, stay with LO 3.6 a bit longer or use EPS or high-res bitmaps for a while. It's true, Draw writes SVG as higher resolution bitmaps to PDF than Writer unless you paste it from Draw or choose "PDF/A-1a". But these are usable workarounds - if bitmaps are a usable workaround for you. I wish some of the features I'm really missing were in the LO/AOO pipeline like SVG... -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
