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 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). In Apache POI we've had success writing Java2D engines that output PPT, PPTX, and Microsoft's "Escher" drawing layers. Regards, Dave > > > Sincerely, > Armin > -- > ALG >
