Last OCRFeeder‘s release had an important new feature which was the detection of changes in the configuration of OCR engines. However, I was very busy the last couple of months developing other cool stuff for Igalia, so, I ended up not testing this feature thoroughly (and I even warned users about that in my last post).
Fortunately, OCRFeeder has some users and contributors who did test it and warned me about some issues, which should be solved in this release.
Take a look at the short list of changes if you wanna see what’s solved and enjoy OCRFeeder.
That’s right, one more release of OCRFeeder. If you’re wondering why so much time for apparently so little changes, it has to do with some super cool things I’ve been working on at Igalia, but you’ll know about that really soon.
This new release brings a few bug fixes such as:
* Fix recognition after using the Unpaper tool;
* Fix an Unpaper issue due to an nonexistent variable
* Prevent the version of Tesseract OCR engine from appearing in the recognized text
This last issue happened after an update in Tesseract which made it print “Tesseract Open Source OCR Engine v3.02 with Leptonica” to the standard output. Since the default way that the Tesseract engine is configured wasn’t discarding the text printed to the standard output, it would appear as part of the recognized text.
After a bit of discussion in the bug report, the conclusion was that OCRFeeder needed a way to detect the changes in the OCR engines’ configuration. This means this new version includes a way to check the needs for these updating the configuration and will warn the user about it once (on start-up). If it can update the engines’ configuration automatically it will say so and ask for confirmation, otherwise it will ask the user to change it manually and offer a way to open the OCR Engines Manager dialog.
The pictures below show what I just wrote:
(note that the first time you use this new version and since this feature wasn’t extensively tested, it might warn you even for engines that do not need a change; still, if it happens, it’ll be only once)
To see the entire list of changes and the amazing work of the GNOME i18n team, check out the NEWS file.
As mentioned in my last post, Edu the mighty Cuban and I have been playing with the Kinect and developed an interactive installation for Igalia‘s 10th anniversary party using OpenFrameworks. (By the way, some people asked me for that application’s code so yesterday I cleaned it and it’s available on Gitorious)
OpenFrameworks offers a number of functionalities either from its core libraries or by means of add-ons and indeed there is an add-on that wraps libfreenect, the Free Software library that allows to control the Kinect.
Using OpenFrameworks was easy, it makes it fast to start developing with it but in many aspects it’s completely different from the way we’re used to work on GNOME. We are used to have single, independent libraries that do one thing and do it well and are used as needed by application developers, for example, do not include a sound library if my application is never going to use it.
Having modules such as GTK+, Clutter, Cairo, GStreamer, etc. already gives us flexible ways to develop certain parts of applications similar to the demo mentioned before: we just had to draw the fish using Clutter/Cairo, implement their behavior and show the Clutter stage. Of course we also would need a way to control the Kinect and it would be really nice if it could offer us an easy to use API for those familiar with GLib…
Ladies and gents, we give you… GFreenect
GFreenect is a wrapper for the Freenect library written using Glib in order to control a Kinect device and make it easy to use with GNOME technologies.
It doesn’t simply wrap the Freenect library but also offers ways of using it that are familiar to you if you have developed something using other GNOME libraries.
One example of this enhanced functionality is that we focused on offering an asynchronous API (although there are some synchronous alternative methods as well). Another example is that when setting the device’s tilt angle, a signal will be emitted when it has finished setting the angle, since it might be useful for some applications.
One of the purposes of having it written with GLib is the GObject Introspection capability. This allowed us to include an example application that controls the various features of the Kinect and was written in Python effortlessly. A screenshot of this app is shown below:
And that’s it! You can find the code for GFreenect in Gitorious (including documentation for this 0.1.2 version). Bear with us if you find some bugs, it is fresh out of the oven.
We hope you find GFreenect useful for your projects and please give us feedback if you find some issues or have any good suggestions.