SVG Compositing

Had another go at compositing an SVG onto a plain pixbuf. This time with more success. Here's the outcome:

I read something in the online docs about edge pixels being repeated 'to infinity'. This might be what's going on in some of my earlier tests. It's not that there's a bug, I'm misinterpreting the results.

SVG rotation

There might be another way of handing this. Perhaps its possibe to simply 'grab' a copy of the resultant pixmap of this graphic. Then it can be treated like any other. But then, this is how I expect Gdk to handle the SVG graphic in the first place.

gnocl::pixBuf #4

This morning got the composite function working. The relevant snippet from the test script shows how it is to be used. The values passed to the actual library call are dummies at the moment and so the numeric values are just to aid the development process.

# composite images

set dest [gnocl::pixBuf new {100 100 8} \
   -alpha {255 255 255} \
   -foregroundColor red \
   -backgroundColor white \
   -baseFont {Sans 10} \
   -name LXY \
   -data {Jane & Georgia} ]

$dest fill red

set src [gnocl::pixBuf new {50 50 8} \
   -alpha {255 255 255} \
   -foregroundColor blue \
   -backgroundColor white \
   -baseFont {Sans 10} \
   -name LXY \
   -data {Jane & Georgia} ]

$src fill white

$dest composite $src \
   -destX 1 \
   -destY 2 \
   -destWidth 3 \
   -destHeight 4 \
   -offsetX 5 \
   -offsetY 6 \
   -scaleX 7 \
   -scaleY 8 \
   -interpType 9 \
   -alpha 10

$dest save testSave.png

This is what is produced:

Issues arising from this is that svg files, perhaps due to these being vector files, are not handled well by the gdk library calls. Perhaps this is why the Cairo is suggested as the best choice. The free rotation of the svg didn't work at all, besides which, the current algorithm used results in a very clear sawtooth edge around the resultant operation.

gnocl::pixBuf #3

Another busy and productive day. With the help fo Tadej at GtkForum I solved the problem of setting the fill colour values. The resulting function used to convert the colour values to the right format is:

static guint32 convertRGBtoPixel ( gchar *clr )

{

GdkColor color;

guint32 pixel;

/* Conversion factor from 16-bit color to 8-bit color (0xff / 0xffff) */

const gdouble f = 0.00389105;

/* create the colour from the supplied string, added by WJG */

gdk_color_parse ( clr, &color );

/* fill with colour */

pixel = ( ( ( guint ) ( color.red * f + 0.5 ) ) << 24 ) | /* R */

( ( ( guint ) ( color.green * f + 0.5 ) ) << 16 ) | /* G */

( ( ( guint ) ( color.blue * f + 0.5 ) ) << 8 ) | /* B */

( 0xff << 0 ); /* A */

return pixel;

}

Of all the obscure things that I've had to work through, the above bitshuffling and base alterations leaves me dumfounded. 

The key functionality added today then includes:

pixbuf commands
   turn
   flip
   rotate
commands
   load

Which will sorta have the following options:

   turn <(int) 0 | 90 | 270 | 180 | -90 | -180 | -270>
   flip -orientation <(str) horizontal (default) | vertical>
   rotate -angle <(dbl) angle> -backgroundColor <(str) colour>

The code for producing the arbitrary rotation is taken from zfuncs. The edge appears aliased and there may be better implementations but this should be sufficient for screen opts.

Other things that I acquired was a pdf of Phillips (1994) Image Processing in C. Gosh it is old. There's a Tcl/Tk front end to the library. Tell it was the published in the days before Python, Ruby and the rise of Perl. Tcl/Tk was 'hot' in those days. Today.....

Also got a nice new desktop today, an Acer Aspire X1301. Its largely to replace my old tower box which, with its many whiring fans sounds like a washing machine on full spin. The new machine, apart from being much higher spec is almost silent -magic! I haven't tried it myself yet but my daughter Georgie has been using it for most of the evening. She unpacked it, set it up and completed the OS installation. Not bad for a nine year old!

gnocl::pixBuf #2

Spent some time, too much time, today and yesterday working on this module. Its not so much the final C code that takes the time but getting to grip with how Gtk+ does things (or rather doesn't do them). The lack of clear, working examples is a bind although the contributions made to the Gtk Forum wiki are great help. The past couple of days has seen me working on getting the framework in place to construct pixbuf commands. These are the one's that I've been working on.

pixbuf commands
   save filename 
   fill colour
   class

The key code itself it running well and is bug-free but I haven't yet quite cracked how to complete the fill command. Here's the relevant snippet from my test script:

$pb1 fill red

$pb1 fill  #aaabbbcccddd
$pb1 fill green
$pb1 fill blue
$pb1 fill white
$pb1 fill black

$pb1 fill  #fff000000fff
$pb1 fill  #000fff000fff

All the named colours are working well, ie not causing errors, but the resultant saved files are not of the right colours. It must be something to do with converting colours to a guint32 number. Tadej at Gtk Forum recommends others to use Cairo to complete such drawing operations, perhaps that's the route I might eventually take. Peter Baum produced a few support functions for colour manipulaiton which are found in the parseoptions.c module. These, however, don't handle the guint32 format. I've had enough of it for today and so will leave it for the next time.

gnocl::pixBuf #1

Had a busy day, decided to relax with a bit of gnocl coding. The last post was about a basic spec for the next pixbuf module and, sure enough, that's what I worked on today. The original bones for the module were put together using the code development wizard which will ship with the next release. This worked compiled fine and so I set about adding some of the simpler functationality based aroung obtaining file information. The resultant commands added today were:

types
description
license | licence
extension
scaleble
writable
fileInfo

Here's what they do:

types
    - returns a list of supported image file types.
description
    - returns a scription of the specified file type.
license | licence
    - returns abbreviated form of the licence terms under which the specified filetype is released.
extension
    - returns a list of extensions associated with the specified filetype,
scalable
    - returns boolean specifying whether the file type is scalable (ie v ector).
writable
    - returns boolean specifying whether the system is capable of saving a pixbuf in the specified file format.
fileInfo
    - returns a list of key information obtained after parsing the specfied file. The information is in the form {width height name}.

gnocl::pixBuf

Put the basic spec together to day for a new module 'pixbuf' which would allow the manipulation of off-screen drawables using the core Gtk/Gdk libraries. Rather than starting off myself, I thought that I'd post this to the Tcler's wiki to see if there's any interest for others users to contribute to this package. Such input might be the addition of ideas as to what the features list might be or even to add code themselves! Well, lets see how its goes.