Fixed sized graphics
Fixed size graphics
The irony of using fixed size graphics is that they appear as a different size depending on the users screen resolution. What I would like to be able to do is specify in my code the physical size of how graphics will appear. To this end I created an Eiffel library which will enable distribution of graphics in SVG format and render them as PNG to an exact size regardless of the screen resolution. The images are nicely anti-aliased and it's possible to specify the background. Rendering a dozen or so images can take a noticeable amount of time so the library caches the images for the next application session in a user data area.
Creating SVG
I use the InkScape vector graphics editor to create SVG graphics. You can of course build them from scratch but a handy shortcut is to take a large sized PNG or other fixed size format and covert it to SVG using the "Trace bitmap" facility. Ideally you should use a PNG with a transparent background and specify the background color when rendering the SVG in your app.
librsvg
The library makes use of the C component librsvg which does a pretty good job and is better than the Java batik-rasterizer which sometimes has a problem of introducing color streaks not to mention the time waiting for the JVM to load.
Monitor size
A technical hurdle to scaling the graphics correctly is being able to query the physical dimensions of the monitor to calculate the size in pixels to render the PNG. This is not available in Vision2. In Linux this was relatively easy using the xrandr API. Windows was a problem as surprisingly the Windows API does not provide any means to query the physical size of the monitor. The best solution I could find is to query the registry for the EDID data associated with the current display monitor driver. EDID is an industry standard describing display properties. It's only accurate to the nearest centimetre but good enough.
Scons build
The library also includes a scons based build process. Under Linux the process builds both librsvg and the Eiffel bridging code. Under Windows with the MSVC compiler only the bridging code and import library for librsvg is built. All other dependencies are automatically downloaded from ftp.gnome.org/pub/GNOME/binaries. The 32 bit or 64 bit versions are downloaded depending on the value of ISE_PLATFORM.
Class EL_SVG_PIXMAP
The interface for the top level class in the library, EL_SVG_PIXMAP, is shown below. The location for the SVG is specified as relative to a standardized application images location using platform neutral path steps. The image is scaled either width wise or height wise keeping the aspect ratio of the original. Procedure 'update_pixmap' caches a new PNG if either the background color or dimension changes.
This library will be available with the release of the Eiffel Loop libraries.
svg-vision library
Note that another way of generating your SVG graph is to use the svg-vision library (should you be starting from a graph drawn via vision2).
See https://svn.eiffel.com/svg-vision/
From what I read, it is parsing the SVG data (XML), and draw the SVG using Vision2 routines on EV_DRAWABLE
It generates SVG data
I ought to know, as I wrote it.
Basically it implements an EV_DRAWABLE as an SVG file.
Parsing SVG files to produce Eiffel Vision graphs would be a nice complementary project, but much more difficult, I think.
It might sound weird, but probably producing Eiffel Vision graphs might help covering more of SVG since I am not sure with Vision2 EV_PIXMAP or EV_PIXEL_BUFFER have features to rotate and so on (however I am not an vision2 drawing expert)
In any case, this sounds a nice library to use and to extend.
SVG Vision
I am very curious to see how it matches up to librsvg. Will be giving it a try.
Correction
Sorry I misunderstood the purpose. It doesn't render SVG but I can see how would be very useful for exporting to other applications or saving drawing actions input by the user.
Further enhancements
The DLL dependencies on Windows add up to 11 mb. To reduce the memory foot print I have made the module dynamically loadable. If the PNG output is already cached there is no need load it.
The library has now been tested on Window 7 (32 + 64 bit), Ubuntu 64 bit. Testing on XP 32 tonight.