Month: October 2017

While implementing GSVG, I had to add DomDocumentType to a DomDocument, so your renderer will recognize it is a SVG document, so I use following:

class GomNode : DomNode

class GomDocumentType : GomNode, DomNode

Note GomNode is implementing DomNode, so yo don’t need to add that interface in its derived classes GomDocumentType.

Hours after a set of debugs, I found you should don’t do that, because it produce a infinite cycle, leading to a crash.

So, your GomDocumentType should be:

class GomDocumentType : GomNode

Now GomDocumentType is a DomNode too.

At least for me, no SVG API is available as GObject API, so you have to deal with libxml2 library. On the other hand renderers are librsvg, but lacks API for SVG creation and Edition.

W3C has published an API specification version 1.1 for SVG and describes how renderers should interpret this XML document. W3C SVG depends on DOM as API to access XML documents.

While developing PLogic, I realized to have no way to create graphics for it, so take a look at GXml to dinamically generate SVG based on a logic diagram, using a GObject API to access XML documents. But no GObject API exists for SVG creation and edition.

Implement W3C API, is a matter to use OOP, like Java or C#, but a pain if you want to use pure C and GObject. So I choose Vala, because its syntaxis is very similar to W3C API and C#, making really easy to implement the API in a set of interfaces first and then in classes implementing those interfaces.

GXml lacks a good DOM support, due to liminations on libxml2 it relays on. So I started to implement a new pure GObject based set of classes, using libxml2 just for parsing and writting; they simple overcomes libxml2 limitations and now implements most DOM4,  whitout transformations.

GSVG now uses GXml’s GomNode classes series, improving time to implement features in W3C specifications.

GSVG have pushed GXml ahead, by exposing bugs and requesting new DOM4 implementations in order to provide useful SVG documents.