SVG support for Shoes

[IanTrudel]

Cairo supports SVG rendering through libRSVG.

https://wiki.gnome.org/action/show/Projects/LibRsvg?action=show&redirect=LibRsvg

From http://cairographics.org/examples/

• librsvg is a SVG rendering library supporting a large subset of SVG 1.1.
• Mozilla is using cairo to render SVG content as of Firefox 1.5 and 2.0. As of Firefox 3.0 it uses cairo for rendering all content and UI.

[IanTrudel]

Shoes::SVG should allow reading data from a string rather than a file and render its content on screen. It would still be possible to load a file in any event, such as in the example below. Or, perhaps, it should check whether a file or a string is passed and load data accordingly.

Shoes.app {
   svg(File.read("bunny.svg"))
}

[ccoupe]

What does svg(File.read("bunny.svg")) return? A bit map image like png and jpg or a new Shoes widget class with svg specific methods and event handling to be written in C and Objective C?

[IanTrudel]

This is something to think about. Ultimately it should become Shoes::SVG but we could implement the features incrementally for which the svg is rendered as a Shoes::Image, can be displayed, responds to normal image related methods. This should be easy to implement. The additional features can come as time goes.

For now I only need to be able to render svg on screen anyway. This would avoid me a whole lot of troubles converting files for different configurations using external tools. This enhancement will allow me to simplify and streamline the production of commercial software based on Shoes. My very next project will use it. So it's not wishlist as in wishful thinking...

[IanTrudel]

The following will be required to add SVG support to Shoes: librsvg, libxml2, libcroco. These can be found on http://www.gtk.org/download/win32.php for Windows related libraries. The binaries should do fine and the PC files can be obtained from the source files.

[IanTrudel]

Shoes.svg method could have the following styles:

• left, top for positioning
• width, height to define rendered image size
• ratio to set aspect ratio (true, false)
• dpi to define the rendered image dpi

Equivalent methods may be considered for manipulating the svg at runtime.

REFERENCES
https://developer.gnome.org/rsvg/2.40/rsvg-Using-RSVG-with-cairo.html
http://cairographics.org/manual/cairo-SVG-Surfaces.html
https://developer.gnome.org/rsvg/2.40/RsvgHandle.html
librsvg source code contains examples in tests directory.

[ccoupe]

I've got a minor concern over libxml2. We already include an XML dll. Is there a choice of parsers when building libsvg from source?

[IanTrudel]

Expat XML (libexpat) is an overly outdated, slow and complicate library. Might not be alive anymore as the last update is in 2012. Is libexpat used anywhere in Shoes? It is mostly included in GTK+ Bundle to ride along and compatibility. So librsvg does not support libexpat.

A good simple example how to use librsvg in Cairo: http://blog.mathieu-leplatre.info/static-build-of-cairo-and-librsvg.html

[ccoupe]

I believe libexpat is used by our old friend, fontconfig to parse the font.conf file.

[IanTrudel]

The good news is that fontconfig can be configured to use libxml2 using ./configure --enable-libxml2.

[IanTrudel]

An interesting experiment on Windows: removed libexpat-1.dll and ran cshoes.exe, checked manual and cobbler — working.

[IanTrudel]

There is no libexpat-1 on MacOS X and probably not on Linux. Recommended to remove this unused library on Windows. It would be a good idea to list and compare libraries on all platforms.

[ccoupe]

@backorder - since I'm redoing the dependencies for OSX , now would be the time to add librsvg to Shoes 3.3. Glancing at the API https://developer.gnome.org/rsvg/2.37/ it seems like a Shoes API is reasonable - make a class out of rsvghandle with some property getters and setter and init with a filename. Add a few methods for the GIO and Cairo calls and ??. Would that be sufficient for your needs?

[ccoupe]

One other note. libexpat is included in OSX 10.6 and 10.9 in /usr/lib/ and it is used by Shoes - attempts to build libxml w/o homebrew have failed so far.

[IanTrudel]

It sounds reasonable to me. Loading and displaying images, basic manipulations would be a great start.

[ccoupe]

There is an existing rsvg gem (part of ruby-gnome project). I have no idea what it's api but it depends on Gtk so it should be understandable code.

[IanTrudel]

rvsg2 seems to have a decent implementation with frequent and recent contributions. I don't know how it would integrate with Shoes. My understanding is that it would be best to roll up our own to fully integrate to Shoes. What are your thoughts?

https://github.com/ruby-gnome2/ruby-gnome2/tree/master/rsvg2

[ccoupe]

There is a problem. From 10.9, attempt to configure:

configure: error: Package requirements (    gdk-pixbuf-2.0 >= 1.3.7     
glib-2.0 >= 2.12.0  gio-2.0 >= 2.24.0   libxml-2.0 >= 2.7.0     pangocai
ro >= 1.32.6    cairo >= 1.2.0  cairo-png >= 1.2.0
        libcroco-0.6 >= 0.6.1) were not met:

No package 'gdk-pixbuf-2.0' found
No package 'libxml-2.0' found
No package 'libcroco-0.6' found

gdk-pixbuf is a show stopper if it can't be configured away. libxml can be done if one is very careful in osx. That's for the older librsvg-2.39.0. The Changelog for the very recent 2.40 says it won't work with gtk2 and ours Shoes/Windows version of Gtk3 isn't high enough. I haven't looked at libcroco yet. Just a warning that this may be hard to do or even impossible.

[ccoupe]

Of course, for all I know, cocoa has the svg handling inside it and we really just need to create a native widget (for gtk and cocoa) that can handle what ever the Shoes API is. Quick google says cocoa/Shoes would need an svg/xml to core graphics importer & exporter. If true that's a lot of code to write and test so I would need some major help (aka some one else writes the code).

[ghost]

There is a cocoa project https://github.com/SVGKit/SVGKit that is active although they say it might be broken for OSX. It's also huge. If I was doing this, I'd look into getting librsvg working w/o a gtk requirement. Shoes really can't handle a completely different imaging model (vector vs pixel) in a general purpose way. We can already create and svg from an image but loading an svg into image seems very unlikely. Loading into a new widget might be possible but its going to be a lot of work and I'm not inclined to do it.

[IanTrudel]

Loading into a new widget might be possible but its going to be a lot of work and I'm not inclined to do it.

It would just need some kind of wrapper class in Shoes C-level code with basic functionalities. We can extend it as time goes, as need goes. As a side note, it would be great to have some kind of wiki article on how to extend Shoes with new features, what a new class requires to be fully accessible in Shoes, etc.

[ccoupe]

Yes, a better description is needed in the wiki if only to help me remember how and where (app.h, app.h, ruby.h, ruby.c, plus a few others)

I've almost got librsvg built on 10.9 but I am running into a problem with gobject-introspection versions building (some) but not working with librsvg. It turns out you can build gdk-pixbuf with out Gtk.

[ccoupe]

Update:
librsvg is built on 10.9 and gem install rsvg2 also installs (along with pkg-config.gem, cairo.gem, and glib2.gem). So the dependencies are good enough for now. I'll do the windows build next - I've peeked at the extconf.rb of rsvg and it's impressive (and possibility cross compile problem but the gem comes with prebuilt mingw binaries so maybe not.

[ccoupe]

Windows is being a problem. Gobject-introspection won't cross compile because it tries to run linux python and there is confusion about which include files to use. That's during the configuration phase - a nasty place in autoconf to be mucking about. Of course I don't have python-dev on my Win7 system.

The rsvg2 gem does install on Windows (prebuilt .so's) and it does use libsrvg inside so it can be built, somehow. The link above to prebuilt Windows dlls doesn't work as given but http://sourceforge.net/projects/ezwinports/files/ does have librsvg-2.40.1-2-w32-bin.zip which includes the dlls and headers but may create some version number mis-match for Shoes. A good place to start, though because the README.txt is very useful.

[ccoupe]

(beware when retrieving style if the svg was opened with :content style !!! might be huge,

Yes. There are many Shoes "style" things you do not want to do with an Svg. I'm OK with svg being the stray dog at the doorstep of Shoes consistency. I'm going to write some more scripts/samples to test and demonstrate all that code that is stubbed out. If someone figures out the ruby/nokogiri query for all groups/layers that returns a hash of ?that would be helpful.

[passenger94]

@ccoupe for the nokogiri search, this one works for me :

require 'nokogiri'

Shoes.app width: 500 do
    doc = File.open("#{DIR}/samples/paris.svg") { |f| Nokogiri::XML(f) }
   ids = doc.css("g").each_with_object("") { |tag, str| str << tag["id"].inspect << "\n" }

    para ids
end

search for nodes "g", then get the attribute "id", i think it's possible to go directly to the id attribute
EDIT ids = doc.css("g[id]").each_with_object("") { |elem, str| str << elem.attributes["id"].value << "\n" }

still, we must find a way to filter the result adequately

[ccoupe]

@passenger94 - we need a way to skip the defs section.

[passenger94]

yes !

    ids = doc.css("g[id]")
    def_ids = doc.css("defs g[id]")
    groups = ids - def_ids
    groups.each_with_object("") { |elem, str| str << elem.attributes["id"].value << "\n" }

but that's not the end of the story ....
we also have layers above "target groups", and sub groups inside "target groups", add to this the cryptic names...
Maybe the best is to present the result of the query in a tree view, so one can at least see the hierarchy : top ones, if few, probably are layers, then comes hopefuly groups/id of interest and leaves are sub groups
it could also easily, as we all expect, be more complicated, (i don't know the svg specifications) :-D

[ccoupe]

I think we've discovered why librsvg2 doesn't have a similar C function. So, if you're going to work with groups you need to know the names before you start coding. bonded.svg is another card deck from Klondike and the code above doesn't work as well. I've modified samples/good-svgview.rb to do the nokogiri query so it isn't lost knowledge. I should probably file a bug about list box items size - too much vertical space.

Try drawing the jokers in paris.svg - something is not right.

[ccoupe]

Ian's deck that I claimed is malformed, svg-cards.svg almost works.

[passenger94]

Try drawing the jokers in paris.svg - something is not right.

i'm aware of this, it's the reason why i created offset_x, offset_y methods. Unfortunately there is nothing we can do : the svg file has a problem and rsvglib fetch wrong dimensions : x,y, width and height have nonsense values for the jokers ... (i even upgraded librsvg to the latest 2.40.12)
I took me a while to figure out what's going on ; the group "jokerpip" described in the defs section has wrong placements (at least for librsvg) and are creating a mess once used in the joker groups ! (remove the "jokerpip" elements, in the joker groups, and all is good again)
i fixed the problem in inkscape and have now a working version

[passenger94]

list box items size - too much vertical space.

what is the problem ? did you mean the popup window is too big ?

[ccoupe]

when clicking on the list box (gtk3) with a long list there is a lot of vertical white space between list items. At first, I thought it had extra `\n in the entries. It could be be my theme vs your theme.

[passenger94]

you mean gtk3, right ? svg branch is using gtk3 ?
it's ok by my side ... probably a theme thing ...

[passenger94]

we have 2 group? method now, one for svg_handle one for svg, is it intended ?

what is the plan for save method ? is it useful as we don't modify the file/xml ? incidentally what about dpi, if we don't save to a file ?

[ccoupe]

We don't need group? method for svghandle. That's the problem for me with creating API - you don't really know what you'll need until you start write the test scripts or an app.

save() would be a lot like snapshot - render the svghandle to an svg/ps/pdf surface (ie file) and use the given dpi setting. I think that'ss what @backorder wanted. in the long discussion above.

[passenger94]

ok, so save() would be a way to convert an svg to a rasterized image ,say png, at some specified dpi ?
why not export() ?
For vector files ps or svg the only possible change is to embed a new dpi useful elsewhere in another program ?

[ccoupe]

export() is a better name. Like the code comment says, no one know what its supposed to do. I would not bother with it until every thing else is cleaned up and working.

[IanTrudel]

I agree with @ccoupe : export() makes more sense. Save() might be used later on, i.e. imagine saving a group into its own svg.

[ccoupe]

Closing #54 for Shoes 3,3,0. If there are bug/enhancements please create a more specific report.