Skip navigation

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
      collection of inserted svg cliparts
    • 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…
Advertisements

8 Comments

  1. “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.”

    True, but you will admit that FLOSS also means parallel developments for the same target. Anyways keep up the good work. I like and use the SVG stuff you do.

  2. “not yet 100% production ready”

    so whats missing to be production ready?

    • Missing for example is support for the platform-specific code to sneak the cairo-.rendered bitmap into vcl, for Mac & Win32. Similar code exist at other places, so shouldn’t be too hard.

  3. Quote: “not yet 100% production ready”

    Yeahhh, that seems to be absolutely right and is definetely the experience I had with quite some code from you/some of your other Novell guys and many other people more, looking at some other code you and some of your colleagues left behind for the Evil(TM) Oracle Engineers to fix from time to time. I’d rather like to offer a 100% feature to our customers from the beginning, and that really doesn’t need any discussion with you.

    And BTW: is Novell’s “Hacker (sic!) week” what I should read as ‘developing in stealth mode’, too? For myself, put Your thinking of FOSS wherever you want to and have fun.

    BTW: Let’s wait and see, we didn’t reach code branch off by now…

    • Interesting anonymous comment. To dispute one particular nonsensical claim: there are (at least) daily dents from me about the topic to be found here: http://identi.ca/thb

  4. Quote “If my interpretation of the (very sparse) information is accurate, this must have been developed in stealth mode ”

    Of course my knowlegde on the development process is very limited, but we have been communicating about the very work on svg back in Autumn 2009…

    So the tone of your remark may sound funny for some, it does not sound ok to me.

    • Cor,

      indeed there has been talking about svg for some extended amount of time – but no visible action, quite the contrary – if you look into EIS, there’s a bunch of deleted CWS with svg in their name. Myself and others asking resulted in no useful answer, at least not in one that would make me assume there’ll be anything for 3.3. See also the history of http://wiki.services.openoffice.org/wiki/Features (and the changes made). So the announcement in the quoted issue was exactly that for me – a nasty surprise. If this is all a simple misundertstanding, fine – but not, or sparsely, communicating tends to lead to situations like this. And that’s bad for a FLOSS project, as it is annoying, and sometimes even demotivating.

  5. I cannot easily judge all the (efforts for) communication. I just can not imagine that it was a surprise. If your experience was nasty, than of course that is a pity.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: