Loud ramblings of a Software Artisan

Hack week, day 3:

• polished the Nautilus patch
• modified the EOG patch to be reconcile data in the same place (not finished yet)
• tried to learn RPM packaging to provide packages for libopenraw, exempi and raw-thumbnailer
• raw-thumbnailer code is on gitweb.fdo, at least temporarily.

I just released exempi 1.99.2 so that my patches for EOG and Nautilus can be applied and built.

Get it .tar.gz - GPG sig

Changes:

• better exception handling in the C++ glue code
• new API xmp_get_property_and_bits() and the macros to manipulate the option bits
• new API xmp_set_property2(), xmp_set_array_item() and xmp_get_error()
• new API xmp_copy()

Some of the new API may look ugly, but that's my fault, and I don't want to break the ABI now. I will by the final release.

Day 2 of hack week: XMP support in nautilus. Today I did:

• filed 2 bugs in Nautilus to were blocking me. With patch attached. Bug 451242 just prevented the build as Nautilus has to be build with -Werror. Bug 451344 was IMHO a problem loading the metadata that occur when there is a bit too much data in the APP1 markers, which is triggered by JPEG with XMP embedded.
• filed the third bug, bug 451380 as a feature request with patch attached, and this is the core of the work. Nautilus will show the XMP metadata if they are available. This only works for local files (Exempi cannot read off gnome-vfs) and only JPEG (the later is Nautilus limitation, related to libexif). Screenshot:

OLS 2007 is being held in town starting this Wednesday. I won't attend the conference, but I was wondering if I should join one of the out-of-conference beer BOFs. If you are in town and owe me a beer, leave a message here :-) (not obligated if I owe you one).

This week is Hack Week at Novell. Work on the Linux and Free Software project of your choice.

I choose to work on bringing digital camera RAW and metadata.

Several defined goal reached today:

• Thumbnailing digital camera RAW for Nautilus. The current solution I know and packaged a year and a half ago for Ubuntu was based on dcraw. Mine is based on libopenraw, and is faster. It just handle less format, but this will be solved in the future. In the mean time I discovered that the Debian package of UFRaw was setting UFRaw to produce the thumbnails (using the provided mime-info). So why reinventing the wheel? Because I believe that a solution based on libopenraw is much better integrated and probably much more efficient^[1]. Other alternative hacks I have seen require the use of ExifTool (with Perl) or dcraw command-line tool. I have a raw-thumbnailer working, to be released.

• XMP support in EOG - bug #451101. Patch is attached. This one make use of Exempi 1.99.2 (that I have not released soon). The support is a bit rough in the UI, and only works for JPEG as it is currently a limitation of EOG. I also think that the metadata should be reconciled in one set for clarity.

To be done:

• XMP support in Nautilus. Same strategy as for EOG. Possibly add it for digital camera RAW files.

• See if the metadata in EOG can be reconciled (see above).

• See how to provide support for editing.

Nothing was lost in the browser and in the last years, Firefox has taken back some point in the browser market. So interestingly that after disbanding the team and not doing anything on IE for 5 years but plugging security holes, Microsoft decided to release IE 7, solely for XP SP2 and upward, in the hope to regain some market.

But this is not without counting on Safari.

Safari by itself made Microsoft not develop IE Mac anymore a by itself took a good chunk as the Mac market is somewhat growing a bit. The interesting part is that it is not based on Gecko, but on KHTML, turned into WebKit. Lars Knoll interview gives us a brief overview of the past and the future of KHTML and WebKit development, notably how Apple collaboration ended up working well and how KDE4 will have KHTML coming directly from Apple's repository^[1]. Now the WebKit for Windows is about to disturb the source: Apple's Windows port did land in the repository, and that port has apparently no relation with the non contribution from Adobe for WebKit + Cairo on Windows^[2]. I'm still unsure of the direct benefit of the port source code for Free Software, as it apparently use a mix between Windows native GDI and Apple own proprietary CoreGraphics (delivered as a non-free DLL^[3]), but nonetheless.

Now how will that still matter for Free Software?

It brings a standard compliant Free Software web rendering engine a broader audience, on that it is different from Gecko. Competition is good, and diversity is good. This engine is at the heart of KDE4, and is being brought to Gtk by the work put in by various contributors, including Alp's port to Maemo (Alp, you rock dude) making it valuable for GMAE and Gnome in general. Nobody will argue, Gnome is in dire need to something better than Gecko for its HTML needs: DevHelp, Yelp, Liferea, Evolution, etc would all benefit from it. All the enhancements made to the main engine, including support for new standards will directly serve the purpose of any Free Software using it.

Even more, being the browser inside the iPhone (and actually Apple's blessed development platform for the iPhone^[4]), this could leverage enough market share to make WebKit a major browser and have actually enough power to convince the Web 2.0 developers to ensure their development are compatible^[5] with it. And that is something noticeable. Remember when IE was the only browser tested and that developer didn't care to fix their mistake or standard conformance because anything else was too small for them?

I forgot, but Thursday night I released Exempi 1.99.1. The ChangeLog is probably not very obvious be the 2 notable changes are xmp_register_namespace() and NS_CC. The first is to register a new namespace to add to a metadata block. The second is actually the constant for the Creative Commons XMP namespace.

This release is brought to you especially for our friend at Creative Commons.

Download .tar.gz - GPG sig

One of the good things with being employed to work on a Free Software project like OpenOffice.org is that you can blog about it, since the code is publicly available. My day to day work is current PowerPoint 2007 import for Impress. This is a joint work between Sun and Novell.

A few weeks ago I implemented the text import from PresentationML (actually from DrawingML). It is far from perfect, but it is getting there. See the example:

It imports the text, the characters and paragraph properties, etc.

I went ahead and solved the problem on my own with planet OpenOffice.org: I changed the RSS template files to escape their content. I don't know why the behaviour is different between two Python installation, and actually I don't wanna know ;-)

It looks like grep is still one of my best friends.

People aggregating the planet should no longer have issue. Sorry for the mess.

Dear Lazyweb,

Since I moved planet OpenOffice, it generates invalid RSS feed because it does not escape the content of <dc:creator>. The planet version is the same, but the Python version likely is different. I have no power on the version of Python that is installed.

This invalid feed cause problems for people aggregating planet in a feed reader (like I do).

Oh Lazyweb, do you have a magical solution? Your friend Google seems to not have been helpful.

Thanks, love,

Hub

Update: I meant <dc:creator>. Silly me. Oops

I just migrated Planet OpenOffice.org to a new ISP. Nothing should be changed for you readers, but if you notice any problem, feel free to contact me.

We will also be moving the rest of go-oo.org progressively, there might be disturbances. We will try to minimize them.

Thanks.

Last night I reached a new milestone in libopenraw: being able to decompress the RAW data from CR2 files using Lossless JPEG. The lazyweb has been helpful in finding code for it (libjpeg does not support it) code that I ported from old K&R to C++. I'm still not completely statisfied with the port but it works much better than my attempt to port some MIT-licensed Java code.

Above is the PGM I generated, that contain the RAW data, viewed in eog. The look is due to the fact that we have a GRBG 2x2 color filter array diplayed as a graymap, and that eog does sone dithering. This is the data I should be passing to the demosaicing code. The picture is one of the random sample I took from my own photo library, taken around the corner from where I was living in Montréal.

DNG support should come The code is in the git repository.