openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <>
Subject Re: Solve SVG visualization without cairo and librsvg
Date Tue, 04 Oct 2011 09:57:38 GMT
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 

(a) Deactivate building the SVG rendering component 
vcl/source/components/rasterizer_rsvg.cxx. This would be the minimal 
solution for solving the copyright problems.

- Quick and easy to do

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

- SVG would stay supported, as bitmap graphic as currently

- mem/speed concerns with java
- still an external renderer, screen and all outputs would use a bitmap 

(c) Write an own SVG importer for AOO

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

- 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).


View raw message