openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Solve SVG visualization without cairo and librsvg
Date Wed, 05 Oct 2011 16:05:48 GMT

On Oct 4, 2011, at 2:57 AM, Armin Le Grand wrote:

> 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

Yes, it is still external, but it seems to support SVG-> EPS and PDF.

> (c) Write an own SVG importer for AOO
> Advantages:
> - vector graphic stays vector graphic, esp. in all outputs. No pixel blocks when zooming
> - future migration way to not only integrate, but also break up in SdrObjects and edit
> - 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).

In Apache POI we've had success writing Java2D engines that output PPT, PPTX, and Microsoft's
"Escher" drawing layers.


> Sincerely,
> Armin
> -- 

View raw message