With LibreOffice again being part of this year’s Google Summer of Code, I was very lucky to have Marco returning to his nice svg export improvements from last time. Three weeks into the project, progress is lovely – here are two demo presentations, showing
(Page up/down navigates between slides, i shows slide index etc.)
Marco has been exemplary in minuting his progress, you can find his daily logs here, for
If you want to play with this, go grab the code, checkout the feature/svg-export branch, build according to the build guide, and check the Tools->Options->General “Enable experimental features” box. Enjoy!
Last week was Hackweek here at Novell, and I had a shot at improving svg support at two places inside OOo (I somehow keep returning to that topic):
- made up my mind earlier that any attempt to convert svg to OOo’s internal vector format is a waste of time
- made up my mind earlier that any attempt at implementing an own svg renderer on top of OOo’s graphic subsystem is of no practical value and a duplication of existing functionality
- made up my mind earlier that plugging librsvg is the way to go:
- added librsvg 2.26.3 and libcroco 0.6.2 to OOo source tree (mostly for windows builds), made it buildable inside OOo’s build system
- hacked up a drawing layer primitive to render svg to a bitmap, everytime zoom or output device changes
- made OOo treat svg as a ‘native’ graphics format, i.e. no longer converting it to internal vector representations, but keeping the original svg file inside the odf package (that actually took the longest time, due to several internal bugs I hit)
- the final patch for the change is here – not yet 100% production ready, but feature complete
- down the road, would be nice to use cairo’s ps, and especially pdf export, when detecting a suitable export operation
- below is a screenshot of some awesome openclipart samples (from the always-brilliant Chrisdesign), both rendering fidelity and render speed are lightyears ahead of the internal import I once did, that maps to OOo’s internal vector format
- The upstream feature request for the above is this issue, in which, after I had implemented this, an Oracle engineer announced something apparently similar – which, after several deleted cws, and a question about what’s going on remaining basically unanswered, was kind of a nasty surprise. If my interpretation of the (very sparse) information is accurate, this must have been developed in stealth mode – something inherently incompatible with FLOSS, I guess.
- switched OOo’s internal svg:d parser from an ad-hoc old implementation to a slighty better ad-hoc shared new implementation, that is able to interpret elliptical arc segments (a somewhat longstanding feature request). Patch for this change (needs to be hoisted to dev300 code line, which is ~trivial) is here. It seems the corresponding issue got closed a bit prematurely…