On 27.09.2011 10:18, Armin Le Grand wrote:
Hi *,
I wanted to keep you up to date that I started looking for a replacement
of SVG embedding functionality in the trunk version. This is needed
since cairo and librsvg are gpl/lgpl and thus need to be avoided for an
Apache release.
Hi *,
I just wanted to keep you all updated on what is going on SVG
replacement. I have now invested one week and there are three basic
possibilities:
(a) Deactivate building the SVG rendering component
vcl/source/components/rasterizer_rsvg.cxx. This would be the minimal
solution for solving the copyright problems.
Advantages:
- Quick and easy to do
Disadvantages:
- Losing some SVG functionality again
- Inserting SVG would be possible, would not be interpreted
(shown/printed/exported). It would be saved and loaded
- Loading files where SVG was inserted is possible, the alternate
visualisation in the metafile data would be used
- Other office version loading a AOO 3.4 file and having SVG support
would work
(b) Replacing the SVG renderer component to use something else (Batik
would be the best candidate with Apache licence compatibility as it seems)
Advantages:
- SVG would stay supported, as bitmap graphic as currently
Disadvantages:
- mem/speed concerns with java
- still an external renderer, screen and all outputs would use a bitmap
visualization
(c) Write an own SVG importer for AOO
Advantages:
- vector graphic stays vector graphic, esp. in all outputs. No pixel
blocks when zooming in
- future migration way to not only integrate, but also break up in
SdrObjects and edit content
- Needs to interpreted only once (to primitives), not each time an
external renderer needs to create a new bitmap replacement
- future usage of included animations possible (smil)
Disadvantages:
- Huge task, but not rocket science, well documented
- Timeframe is not clear
I experimented with (a) and (c) up to now. I invested ca. one week in
(c) to estimate the do-ability. I can already import the tiger and other
examples quite well, but still a lot has to be done. The abstract SVG
importer I started needs to be extended, but has shown the last days to
be a good base to do so. Representing SVG as primitives is also pretty
well doable, showing that this goes in the right direction.
I will spend another week and see how I can progress. If I will not be
able to advance with the necessary speed, I will probably fallback to (b).
Sincerely,
Armin
--
ALG
