[cairo] Editing SVG content with Cairo

[影月 零]

Replying inline:


2014/1/5 Simon Sapin <simon.sapin at exyr.org>

> On 05/01/2014 12:11, 影月 零 wrote:
>
>> OK, that sort of clears things up for me. It still confuses me how an
>> SVG can be loaded with this:
>> http://cairographics.org/documentation/cairomm/reference/classCairo_1_
>> 1SvgSurface.html
>>
>
> It can not. Cairo’s SVG surface only *writes* SVG files. It does not know
> how to read them or render them.
>
> That makes waaay too much sense now that I look at my code again. I was
loading with rsvg...

>
>
> What I need isn't necessarily a scene graph in whole as I need no actual
>> rendering capability. I really just need to be able to manipulate the
>> SVG data and I would like to do that in an object-oriented and
>> language-native way, rather than hacking through XML with an XML library
>> like Nokogiri.
>>
>
> SVG is fundamentally XML. SVG’s DOM is XML’s DOM.
>
That is true but it's a common construct to re-implement the DOM natively.
EG the HTML DOM is easy to access and manipulate with JS native constructs,
even more so with tools/frameworks/libraries like jQuery. COLLADA (which I
absolutely hate with a f*ing passion GOD DAMN WHAT AN AWFUL AWFUL FORMAT)
has a few libraries which convert the DOM into native C++ objects or C
structs. There's many many more examples of course.

>
> On top of that there are a few things like parsing a path, but not much
> really. Every renderer I know of implements those ad-hoc.
>
> Again, SVG is implemented in XML as a saved format, but programatically it
is great to have a re-implementation. Manipulation with Cairo would of
course be the best scenario because let's face it, Cairo is where it's at
with vector graphics. If there was a library to just parse SVG and just
have a collection of objects Cairo can deal with and manipulate directly
that would be awesome.

>
>
> That no library like this seems to exist surprises me. I
>> was really expecting to find something like COLLADA DOM (but hopefully
>> easier to use) for SVG.
>>
>
> I’ll be looking forward to you making it :)
>
> I really really hope someone else does that. I may end up writing a small
sample to just parse the objects and change color, but the fact of the
matter is our company is in the red and we really don't have any free time.
We're the guys who are doing the new apngasm btw., check the kickstarter.
We've been looking at doing SVG and SMIL tools after that but with the pace
apngasm is going (our partner has a day job other than apngasm/we've
already gone through the funds with extra work to make the library more
usable) I absolutely do not want to think about running another kickstarter
and having to deal with that responsibility.

If I do decide to make a little sample DOM to Native Object library is
there a specific SVG spec reference that I should look at?

-Rei


2014/1/5 Simon Sapin <simon.sapin at exyr.org>

> On 05/01/2014 12:11, 影月 零 wrote:
>
>> OK, that sort of clears things up for me. It still confuses me how an
>> SVG can be loaded with this:
>> http://cairographics.org/documentation/cairomm/reference/classCairo_1_
>> 1SvgSurface.html
>>
>
> It can not. Cairo’s SVG surface only *writes* SVG files. It does not know
> how to read them or render them.
>
>
>
>  What I need isn't necessarily a scene graph in whole as I need no actual
>> rendering capability. I really just need to be able to manipulate the
>> SVG data and I would like to do that in an object-oriented and
>> language-native way, rather than hacking through XML with an XML library
>> like Nokogiri.
>>
>
> SVG is fundamentally XML. SVG’s DOM is XML’s DOM.
>
> On top of that there are a few things like parsing a path, but not much
> really. Every renderer I know of implements those ad-hoc.
>
>
>
>  That no library like this seems to exist surprises me. I
>> was really expecting to find something like COLLADA DOM (but hopefully
>> easier to use) for SVG.
>>
>
> I’ll be looking forward to you making it :)
>
> --
> Simon Sapin
>
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20140106/e8556971/attachment-0001.html>