Trained Monkey Hacking Experience

LibreOffice CorelDraw Import filter - don't despise the humble beginnings

2012-01-31T15:56:00.001+01:00

You might still remember some of my blogs about our new and shiny MS Visio import filter in the upcoming LibreOffice 3.5.0.

But what about 3.6.0? Is it going to be an exciting version too? Well, the answer depends on what kind of things excite you generally, but for sure, there will be a lot of goodness as usual to make the best free office suite even better.

In my free time, I have been working for some time already on the next graphics import filter for LibreOffice. This time it will be a CorelDraw import filter. The horse-power is a library, libcdr. In the same way as libvisio, libcdr reuses the API of libwpg and thus is easily pluggable into LibreOffice reusing all the ODG generator classes of the current writerperfect module. The importer is currently part of the git master tree.

You might be already shouting: "Where are the screenshots?" I know that a picture speaks louder then hundred words, and so here you are served:

Simple and more complex shapes in CorelDraw 7

The same shapes imported into LibreOffice Draw.

As you can see, it is an initial implementation, which cannot but get better. If you want to participate in this adventure, you can drop around at our IRC channel #libreoffice-dev channel at irc.freenode.net where a community of smart and friendly developers can direct you.

Stay tuned for more nice pictures as this project advances.

FOSDEM 2012 - How to make the best of it and become LibreOffice developer

2012-01-25T23:19:00.001+01:00

FOSDEM 2012 is just round the corner and, as you might know, LibreOffice will have a DevRoom this year too. And, as it was already publicized, your servant and Eilidh McAdam of libvisio fame will attend too. The goal of this event will be to help you to become a LibreOffice developer, by helping you to get your first contact with the code from inside.

How to prepare for the event?

In order to give as many community members the possibility to speak, the presentations will not take more then 15 minutes each. But we will be there for one-to-one contacts and hacking goodness. If you are interested in contributing to our new Visio import filter, or the upcomming Corel Draw and MS Publisher filters, here is what you can do:

Find a bug that is bothering you in the current Visio import filter, or some simple feature that the importer currently does not support
Check out the following libraries:
- master branch of libwpd (git clone git://libwpd.git.sourceforge.net/gitroot/libwpd/libwpd)
- STABLE-0-2-0 branch of libwpg (git clone -b STABLE-0-2-0 git://libwpg.git.sourceforge.net/gitroot/libwpg/libwpg)
- master branch of libwps (git clone git://libwps.git.sourceforge.net/gitroot/libwps/libwps)
- master branch of libvisio (git clone git://anongit.freedesktop.org/libreoffice/contrib/libvisio), and
- master branch of libcdr (git clone git://anongit.freedesktop.org/libreoffice/libcdr)
Build them as system libraries and install them in the same order.
Then build LibreOffice according to these instructions. The important thing is to use those system libraries that you just built. To do so, be sure you added to the configure flags
- --with-system-liwpd
- --with-system-libwpg
- --with-system-libwps
- --with-system-libvisio
- --with-system-libcdr

With this kind of build, you will be ready to make the most from your Brussels weekend. Nevetheless, you can drop around at our IRC channel #libreoffice-dev channel at irc.freenode.net for more information and ideas.

Starting to do it instead of planning to do it ...

... is the best way to enter the FOSS development. That is why your servant and Eilidh will be around to hold your hand with debugging and finding way to implement your favourite features. We will answer your questions about the library design. We will point you to the place in the code where your bug might linger. And for more complicated stuff, we will debug it with you.

Don't expect us to give you a fish, but we will certainly teach you how to catch it by yourself. And in the same token, you will become a contributor inside a community of smart people that is fun to hang and hack with.

See you in Brussels the 4^th and 5^th of February 2012.

Take a decision to enter FOSS in 2012

2012-01-02T15:19:00.002+01:00

So, the year changed again and with it come quite often new decisions. Some swear to work out the superfluous kilos, pounds, or whatever standardized measure your country uses, gained too fast during the festivals. If it is your decision, it is for sure good for your body and I wish you success that goes beyond the act of subscribing to a local gym (and never appearing there after first month).

But this could be also a nice time to take a decision that you were procrastinating with for too long. That one is good for your intellect and programming skills (even though you don't consider yourself a programmer yet). What about starting to contribute to a Free and Open Source Software project (FOSS)?

Sounds interesting? So I have one for your. It is having a big and growing community. It can accomodate all levels of skills. And the impact you will have is multiplied by the wide addoption of the product itself.

Well, you must have guessed right by now. I am speaking about the LibreOffice project, your natural entry point into the marvelous world of the FOSS.

Whether you are expert or beginner programmer or C++ is sounding Chinese Traditional for you, just find a way to join channel #libreoffice-dev channel at irc.freenode.net in order to meet other developers and visit our Easy Hacks for ideas where to start.

I promis you that a year from now, you will not regret that you have started. Although, it is quite probable that you will pour a tear over an unused year-pass from the local gym.

7th ODF Plugfest in Gouda

2011-11-15T12:34:00.002+01:00

For those that might care, your servant will be attending this week the ODF Plugfest #7 in Gouda (Netherlands).

I will have on Friday a short presentation of the best free and open source library for parsing Microsoft Visio Documents. The other exciting thing is that after more then 6 years of common collaboration I will get to meet personally one of my libwpd co-maintainers, Johannes Marcus Maurer also know as "uwog".

What an exciting time before us!!!

LibreOffice Visio Import filter: the goodness soon on your desktop

2011-11-15T01:25:00.001+01:00

It has been a long time since I last time blogged about the LibreOffice Visio import filter. My silence did not prevent a pretty cool code from falling gradually into our git repository. To the point where now we are working on the last 5% of features that normally take the 95% of development time. But, let us see what happened since my July blog:

First of all, Eilidh was busy as a bee and, in the second half of the Google Summer of Code, implemented support of stylesheets, stencils and basic text. She also debugged and fixed quite a number of imperfections that Valek found. Frankly speaking, this Google Summer of Code was by far the best from my point of view. We managed to achieve a very good fidelity of import only in about 3 and half months. Impressive.

During the LibreOffice HackFest weekend in Munich, I had a time to add a support for uniform splines in libvisio and to implement the actual import in text on the side of LibreOffice.

The next highlight was the fact that the whole team met in Paris during the LibreOffice Conference 2011. It was delight to meet in person Valek and Eilidh. There is even a photo witnessing this meeting:

Valek, me and Eilidh from left to right

This conference was not only an occasion to know each other a bit better, but also to improve and add some new features to libvisio. During boring parties full of non-developer talk, we withdrew with Eilidh to some corner and improved together the text import: paragraph and span properties, text box properties, etc. Later on, Eilidh added initial support for line markers (aka arrows). Recently we implemented emulation of the last Visio primitive that we did not handle before - Infinite Line.

For those that have big piles of Visio documents on their disks, but cannot read on their favourite Linux distribution: Your pain is coming to an end. The LibreOffice Visio Import filter will be part of LibreOffice 3.5 release, which will be the next major release early next year.

And since images speak louder then thousands of words, here are some pics to illustrate our achievements:

OrgChart.vsd in Visio		OrgChart.vsd in Draw
				You can see the achievement by comparing with the pictures from my June blog

DNetwork.vsd in Visio		DNetwork.vsd in Draw
				Compare with the picture from this libregraphicsworld.org article.

Calendar.vsd in Visio		Calendar.vsd in Draw
				This picture shows a good mix of the complicated features like stencils with NURBS, text fields, gradients, stencil text, etc.

If you are impatient and cannot wait anymore, just grab one of the daily builds uploaded by our tinderboxes here and enjoy all that goodness on your own.

LibreOffice Visio import filter on libregraphicsworld.org

2011-09-15T14:10:00.000+02:00

For those that could be interested in my shameless self-promotion, there is some news about the LibreOffice Visio import filter at libregraphicsworld.org web site, accompanied by a fine interview with two fine hackers. So, click and enjoy the wonderful screenshots in a preview of the happiness LibreOffice 3.5 will bring you.

LibreOffice Visio import filter - round shapes are beautiful

2011-07-08T15:15:00.004+02:00

Some might be wondering why the Visio import filter project is so quiet. But the answer is easy: we were busy as bees adding new features.

You might remember my blog about the bounding box of an elliptical arc. It is because Eilidh added the support of elliptical arcs into libvisio. And then we discovered that LibreOffice did not support elliptical arcs in the path at all, just ignored them. Fortunately, there was this patch of a hacker extraordinaire, Thorsten that was used to teach LibreOffice some sane behaviour.

Eilidh implemented further the conversion of gradient fill and with this and the support of elliptical arcs, this Visio document:

looks in Draw pretty well:

You will realize that we do not support text in Visio documents yet, but be assured that it is now our top priority feature. It is also worthy to note that the above-mentionned document is actually a document in Visio file-format 6 (used by Visio 2000 and Visio XP). We refactored libvisio the way that our support of both version 6 and 11 is equivalent. Moreover, we implemented two-pass parsing of Visio documents which allows us to draw shapes in a correct order and position them accurately.

In the same line, Eilidh implemented reading of NURBS, which is pretty tedious since the conversion must be done by approximation, since neither ODF, nor SVG support this kind of non-uniform rational basis splines. For the while, we are approximating them with 50 lineto segments for one spline, but it is our intention to use a serie of smooth cubic splines to achieve as much visual similarity as possible.

The libvisio library now is able to position correctly any point even if it is in a rotated shape that is part of a group rotated differently, which also might be part of another group with a diferent transformation. This allows us to load this Visio document:

in Draw this way:

You can see some graphic problems. The missing shapes are polylines that we will very soon correctly support. Nevertheless, this could be another one of my "we all love ODF, but ..." blogs, because some of the visual glitches are given by the fact that OpenDocument Graphics (ODG) file-format is suboptimal for representing more complex drawings. One is not even able to specify fill-rules or rules of polygon clipping. Clerly, this SVG inside XHTML version, converted using the vsd2xhtml tool, that is part of the libvisio library, is much closer to the original:

So, a bottom line is that the project is well alive and kicking. We even tagged the second alpha release and the tarball is now what LibreOffice master build is using. So, if you build your LibreOffice yourself, you will be able to enjoy the fruits of the work or Eilidh's hands and — why not — even start to contribute to this cool and interesting project.

Stay tuned for more news soon ...

Bounding Box of an SVG Elliptical Arc

2011-06-20T20:14:00.005+02:00

We all love ODF, the best and the most vendor-neutral file-format in the Universe and its surroundings. But for sure, we have some spots where we would prefer it to be somehow less cumbersome. My favourite spot is the need to compute the bounding box of the path element when one writes the draw:path into an OpenDocument Graphics file. Without proper svg:x, svg:y, svg:height, svg:width and svg:viewBox values the path will not be correctly placed.

Computing bounding boxes is not so complicated work when everything is a polygon (which is the case in the internal model of basegfx module), but it becomes a bit more complicated if an application wants to generate paths including elliptical arcs.

I hit this problem about a year ago when I was working during my hackweek on an improvement of libwpg. I tried first to implement the bounding box of an elliptical arc the lazy hacker way, by googling for what other people did. And to my surprise, there is a huge vacuum in what concerns computation of a bounding box of the "A" element of an SVG path. So, I settled for the lazy hacker's plan B: I abandoned the idea by saying I will handle it later, in the first moment, and by implementing a suboptimal solution in the second time. But, since Eilidh did some spectacular progress last week in handling elliptic arcs, my lazyness became the bottle-neck of the progress. So, it was time to remember those nice times when I was warming the benches of the University, dust off my knowledge of mathematical analysis and analytical algebra (or the lack thereof), and try to compute the bounding box of an elliptical arc myself.

And for the purpose of people that might be as lazy as me, I decided to fight my lazyness the second time to give Uncle Google the opportunity to spit out something meaningful, when someone asks it about "Bounding box of an elliptical arc". Here are the notes:

Compute extremes using parametric description of ellipse

Let us start from this parametric description of an ellipse:

x(theta) = cx + rx*cos(theta)*cos(phi) - ry*sin(theta)*sin(phi)
y(theta) = cy + rx*cos(theta)*sin(phi) + ry*sin(theta)*cos(phi)

where cx and cy are the coordinates of the centre of the ellipse, rx and ry are the radii and phi is the x-axis-rotation.

To compute the bounding box of the whole ellipse we need to find for which value of theta the above mentioned functions reach the local extremes. It means where the first derivatives of x and y according to theta are zero. We will get this two equations:

0 = -rx*sin(theta)*cos(phi) - ry*cos(theta)*sin(phi)
0 = -rx*sin(theta)*sin(phi) - ry*cos(theta)*cos(phi)

which give us two solutions for x:

theta = -atan(ry*tan(phi)/rx) and theta = M_PI -atan(ry*tan(phi)/rx)

and two solutions for y:

theta = atan(ry/(tan(phi)*rx)) and theta = M_PI + atan(ry/(tan(phi)*rx))

Compute the center of the ellipse

Since we know now the values of theta describing the extremes of our ellipse, we can compute the x and y values of the bounding box of the whole ellipse. Just to do that, we still need to know the coordinates of the center of the ellipse, cx and cy.

The computation of the center of the ellipse is pretty well described in the Appendix F.6.5 of the SVG standard and does not need to be reproduced here. Just note that for this we need the coordinates of the starting point of the arc that correspond to the end point of the previous path segment.

Determine the bounding box of the whole ellipse

Compute the xmin, xmax, ymin and ymax using the values of theta for the local extremes and the newly computed cx and cy coordinates. Like this not only we will know the bounding box of the whole ellipse, but we will also know which value of theta corresponds to maximum and which one to minimum. This knowledge will be later valuable for determining the tightest possible bounding box of a given elliptical arc.

Tightest possible bounding box

By calculation of the bounding box of the whole ellipse, we now know the rectangle that will contain the ellipse and thus our elliptical arc too. Nonetheless, this rectangle is too big for our arc. So, the next thing is to trim it down so that it becomes the tightest possible rectangle that will still contain the whole arc.

For this task, we will use the polar coordinates rather then the cartesian ones. The principle is that if any of the points corresponding to xmin, xmax, ymin or ymax of the whole ellipse, lie on the arc they will be be the extremes of the arc too. Nevertheless, if for instance the point ymin does not lie on the arc, the new ymin will be the minimum of the y coordinates of the starting and ending points. In the same way, if the point xmax does not lie on the arc, the new xmax will be the maximum of the x coordinates of the starting and ending points. Whether an extreme does or does not lie on our arc is something trivial to see once the arc is drawn, to determine it programatically will require some efforts.

First, we will compute the coordinates of the points where the whole ellipse touches the bounding box using the parametric description of the ellipse and the values of the theta that we found out in the previous steps. And for determination whether they lie or not on our arc we will use their position in polar coordinates. We will thus need to compute the angles with the x-axis of the lines going through the center of the ellipse and our extreme points. In other terms, we will compute the angle between vector (1,0) and vector (x_extreme-cx, y_extreme-cy).

The formula for computing the angle between two vectors is known and mentioned inter alia as formula F.6.5.4 of the SVG standard. Generally, the expression to calculate the angle between a vector (ax,ay) and a vector (bx,by) is:

(ax * by > ay * bx ? 1.0 : -1.0) * acos( (ax * bx) + (ay * by) / ( sqrt(ax * ax + ay * ay) * sqrt(bx * bx + by * by) ) ).

But since we already know that the first vector is (1,0), we can simplify it:

(by > 0.0 ? 1.0 : -1.0) * acos( bx / sqrt(bx * bx + by * by) ), which could be eventually simplified to atan(by / bx), but this expression has a potential division by zero and the code would have to handle those border situations in a special way.

Once we know the angles of the extremes, we still need to calculate the angles of the starting and the end points or our arc using exactly the same formula. So we get angle1 corresponding to our starting point and angle2 corresponding to the endpoint. It is necessary to normalize all angles so that they lie in the interval of [0.0, 2.0*M_PI).

In case the sweep flag is 0, the angles are decreasing when the ellipse is drawn. But, for the computation of bounding box the direction of rotation is irrelevant and only complicates the situation. So we swap the angles if the sweep flag is not set. In this way, we can just check for the absence of the extreme points on our elliptical arc, rotating from angle1 to angle2. Nevertheless, we have another difficulty with the fact that the angle of 0 radians is the same as the one of 2*M_PI radians. This passage through the 2*M_PI / 0 border is not very easy to handle directly. That is why we swap the points in case where angle1 > angle2 and will not look in this case for absence of the extreme points on the arc, but for their presence on the complement arc that would close the ellipse.

And as my teachers used to say: "Grey is the theory, but green is the tree of life," here is what it looks like in a plain C++:

#include <algorithm> #include <cmath> #ifndef M_PI #define M_PI 3.14159265358979323846 #endif inline double getAngle(double bx, double by) { return fmod(2*M_PI + (by > 0.0 ? 1.0 : -1.0) * acos( bx / sqrt(bx * bx + by * by) ), 2*M_PI); } void EllpArcBBox(double x1, double y1, double rx, double ry, double phi, bool largeArc, bool sweep, double x2, double y2, double &xmin, double &ymin, double &xmax, double &ymax) { if (rx < 0.0) rx *= -1.0; if (ry < 0.0) ry *= -1.0; if (rx == 0.0 || ry == 0.0) { xmin = (x1 < x2 ? x1 : x2); xmax = (x1 > x2 ? x1 : x2); ymin = (y1 < y2 ? y1 : y2); ymax = (y1 > y2 ? y1 : y2); return; } const double x1prime = cos(phi)*(x1 - x2)/2 + sin(phi)*(y1 - y2)/2; const double y1prime = -sin(phi)*(x1 - x2)/2 + cos(phi)*(y1 - y2)/2; double radicant = (rx*rx*ry*ry - rx*rx*y1prime*y1prime - ry*ry*x1prime*x1prime); radicant /= (rx*rx*y1prime*y1prime + ry*ry*x1prime*x1prime); double cxprime = 0.0; double cyprime = 0.0; if (radicant < 0.0) { double ratio = rx/ry; double radicant = y1prime*y1prime + x1prime*x1prime/(ratio*ratio); if (radicant < 0.0) { xmin = (x1 < x2 ? x1 : x2); xmax = (x1 > x2 ? x1 : x2); ymin = (y1 < y2 ? y1 : y2); ymax = (y1 > y2 ? y1 : y2); return; } ry=sqrt(radicant); rx=ratio*ry; } else { double factor = (largeArc==sweep ? -1.0 : 1.0)*sqrt(radicant); cxprime = factor*rx*y1prime/ry; cyprime = -factor*ry*x1prime/rx; } double cx = cxprime*cos(phi) - cyprime*sin(phi) + (x1 + x2)/2; double cy = cxprime*sin(phi) + cyprime*cos(phi) + (y1 + y2)/2; double txmin, txmax, tymin, tymax; if (phi == 0 || phi == M_PI) { xmin = cx - rx; txmin = getAngle(-rx, 0); xmax = cx + rx; txmax = getAngle(rx, 0); ymin = cy - ry; tymin = getAngle(0, -ry); ymax = cy + ry; tymax = getAngle(0, ry); } else if (phi == M_PI / 2.0 || phi == 3.0*M_PI/2.0) { xmin = cx - ry; txmin = getAngle(-ry, 0); xmax = cx + ry; txmax = getAngle(ry, 0); ymin = cy - rx; tymin = getAngle(0, -rx); ymax = cy + rx; tymax = getAngle(0, rx); } else { txmin = -atan(ry*tan(phi)/rx); txmax = M_PI - atan (ry*tan(phi)/rx); xmin = cx + rx*cos(txmin)*cos(phi) - ry*sin(txmin)*sin(phi); xmax = cx + rx*cos(txmax)*cos(phi) - ry*sin(txmax)*sin(phi); if (xmin > xmax) { std::swap(xmin,xmax); std::swap(txmin,txmax); } double tmpY = cy + rx*cos(txmin)*sin(phi) + ry*sin(txmin)*cos(phi); txmin = getAngle(xmin - cx, tmpY - cy); tmpY = cy + rx*cos(txmax)*sin(phi) + ry*sin(txmax)*cos(phi); txmax = getAngle(xmax - cx, tmpY - cy); tymin = atan(ry/(tan(phi)*rx)); tymax = atan(ry/(tan(phi)*rx))+M_PI; ymin = cy + rx*cos(tymin)*sin(phi) + ry*sin(tymin)*cos(phi); ymax = cy + rx*cos(tymax)*sin(phi) + ry*sin(tymax)*cos(phi); if (ymin > ymax) { std::swap(ymin,ymax); std::swap(tymin,tymax); } double tmpX = cx + rx*cos(tymin)*cos(phi) - ry*sin(tymin)*sin(phi); tymin = getAngle(tmpX - cx, ymin - cy); tmpX = cx + rx*cos(tymax)*cos(phi) - ry*sin(tymax)*sin(phi); tymax = getAngle(tmpX - cx, ymax - cy); } double angle1 = getAngle(x1 - cx, y1 - cy); double angle2 = getAngle(x2 - cx, y2 - cy); if (!sweep) std::swap(angle1, angle2); bool otherArc = false; if (angle1 > angle2) { std::swap(angle1, angle2); otherArc = true; } if ((!otherArc && (angle1 > txmin || angle2 < txmin)) || (otherArc && !(angle1 > txmin || angle2 < txmin))) xmin = x1 < x2 ? x1 : x2; if ((!otherArc && (angle1 > txmax || angle2 < txmax)) || (otherArc && !(angle1 > txmax || angle2 < txmax))) xmax = x1 > x2 ? x1 : x2; if ((!otherArc && (angle1 > tymin || angle2 < tymin)) || (otherArc && !(angle1 > tymin || angle2 < tymin))) ymin = y1 < y2 ? y1 : y2; if ((!otherArc && (angle1 > tymax || angle2 < tymax)) || (otherArc && !(angle1 > tymax || angle2 < tymax))) ymax = y1 > y2 ? y1 : y2; }

LibreOffice Visio import filter - shaping up the baby

2011-06-17T16:21:00.003+02:00

Maybe you were asking yourself what happened in the Google Summer of Code Visio Import filter project since last week. But even if you did not ask yourself this necessary question, here is some update about the baby:

The focus this week was mainly on shaping the baby up. Eilidh added to her blog a photo and an "About" line and then she got exhausted and decided to rest by coding. And it is like this that she implemented polylines, ellipses and circular arcs.

And since the images speak louder then any words, enjoy the look:

Microsoft Visio		LibreOffice Draw

For those interested in some technical details, or even for those that desire to give hand, the code of the libvisio library is living here. And as usual, for any question or encouragement, feel free to join our #libreoffice-dev irc channel at irc.freenode.net, ping tibbylickle and pat her back, if she is not lost too deep inside her Emacs.

LibreOffice Visio Import filter - first steps of a new baby

2011-06-10T13:49:00.005+02:00

The Google Summer of Code started some weeks ago and we have some nice projects at LibreOffice too.

I am having again this year the privilege to mentor a brilliant student Eilidh McAdam working on a Microsoft Visio import filter. She got up to the speed very quickly to the point that she is now very intimate with any hexadecimal number of any width. And the first results of her diving into the binary world can speak for themselves.

This Visio document : can be currently imported into LibreOffice Draw: .

For those that might be interested in such a detail as the source code of this endavour, the filter is developped as two elements, a shared library living here and an import filter based on this library living in the LibreOffice's writerperfect module.

For any question or encouragement, feel free to join our #libreoffice-dev irc channel at irc.freenode.net and ping tibbylickle (for encouragements) or Fridrich (for blames).

opensuse-mingw mailing list

2011-03-03T22:04:00.004+01:00

The windows::mingw project and its sub-project quickly gain a true community around themselves. This week, the number of source packages that we build for Windows in openSUSE Build Service reached 200 for both the 32-bit as well as 64-bit Windows versions.

In order to make the communication between contributors, developers and users easier, we got a sparkling new mailing list at lists.opensuse.org. You can subscribe it by sending a mail to opensuse-mingw+subscribe@opensuse.org and enjoy all the intelligent and edifying talk we are having there.

Voreppe Win32 Tinderbox

2011-02-26T08:07:00.004+01:00

As you can see here, we have now a working Windows tinderbox. It finished tonight its first successful build of master branch and will send you nagging e-mails for any breakages from now on. It is our hope that this tinderbox will help us to keep LibreOffice buildable on Windows much easier.

This tinderbox is running Windows Server 2008 R2 Service Pack 1 with Visual Studio 2008 Service Pack 1 and Windows SDK 7.1. The server was graciously given at the disposition of the LibreOffice community by the French town of Voreppe through the association La Mouette. I want to personally thank Laurent Godard, a long-time community member and contributor who was more then instrumental in this transaction.

GNU Make 3.82

2010-09-11T10:53:00.001+02:00

Just noticed that this kind of constructs chokes GNU Make 3.82

     test x$CC = x && CC = gcc

It can be replaced by

     CC ?= gcc

Which can be written in a long form:

     ifeq ($(origin CC), undefined)
     CC= gcc
     endif

The other thing that is making this version of GNU Make choke are leading spaces in multi-line rules. Please, use tabs when writing Makefiles.

Hackweek V - Day 1

2010-06-07T18:12:00.000+02:00

It is Hackweek V here at Novell. And as with all good things that are supposed to start on Monday, and end on Friday, the best thing is that they can start on Friday evening and go until the night becomes a dawn on Monday morning. It is in this spririt that I started to do some preparation to the long overdue release of libwpd libwpg and all projects that are depending on these two. Already during the week-end I fixed some obvious regressions in libwpg, caused by the complete API rewrite. I added some callbacks to the libwpd's API, so that we can try to support named styles during the 0.9.x series and will not have to break ABI too soon (libwpd 0.8.x were API stable for about 5 years). And today, I was playing with some more regressions and bugs found by sum1, the best QA person that I know.

The fun part for libwpg was to somehow start to support elliptical arcs so that some graphs can have nice smooth edges. This is when one converts the WPG files to SVG. Another fun was generating ODG. Although the ODF 1.1 specifications somehow allow to have elliptical arcs in a path, the reference implementation of ODF does not render them. Needless to say that it is pretty tedious task to try to compute a proper bounding box for a path that has only one elliptical element. Just wondering whether ODG can ever become so easy to use and as expressive as SVG. Never mind, just ranting!

The other thing that I wanted to work on during hackweek was the Evolution installer that I spoke about some time ago. Nonetheless, it would be not wise (the less one can say) to put that as a principal task for oneself. Unless, one is crazy in love with progress-bars and enjoys staring at them for 15-20 minutes in row. But, I can report some progress in there. It is now possible to install only the languages one wants, although that functionality must be somehow fine-tuned so that we don't publish languages where only one of the *.mo files is present. Another little work was done in order to make the installer Welcome page a bit more sexy.

For those that would like to debug Evolution on Windows, there is now a debug installer in the dummy rpm file that I mentioned in my previous blog post. This debug installer will install the debug symbols for all DLLs and EXEs in the Evolution installer and will add also a working gdb.exe as a courtesy of your faithful.

Last, but not least, I would like to announce officially that a 64-bit evolution starts and work on a 64-bit Windows operating system. It can even show some fancy blog entries. Please, don't focus on the content, or lack thereof :-P, rather enjoy the nice picture) of rss plugin using 64-bit version of webkit-gtk.

Experimental Evolution installer for Windows

2010-05-25T16:48:00.004+02:00

It is a pleasure, fun and honour to introduce to the distinguished audience our newest Evolution installer for Windows. You can find it for instance in this repository of our wonderful openSUSE Build Service. The installer is hiding in /usr/i686-pc-mingw32/sys-root/mingw directory of the mingw32-evolution-installer RPM. For people that don't know what to do with RPM packages on windows, 7-zip does just a wonderful job at unpacking RPMs even if they use LZMA payload.

As you can see from following pictures,

the functionality offered by the installer is basic for instance. Nevertheless, it does the most important job which is to install Evolution on your windows box.

On the first launch, Evolution will register itself as a mail client able to handle mailto protocol and it also registeres the necessary verbs to be able to become default mail client on Windows,

and on versions of Windows where the start menu Internet and E-mail links are supported, it can install its icon and open verb in that region:

Apart of those technicalities, it can be used to read mail:

to manage one's contacts and timetables, even to understand why one is feeling suddenly so hot:

Not to mention that evolution will in principle detect your timezone and even your online status.

The installer is for the development series of Evolution (2.31.x). It is possible to produce one for the "stable" (2.30.x) branch, but the quality of both branches on Windows is comparable and doing a "stable" installer would be slightly missleading for the user. Having said that, this version is quite usable although, I would not advise anybody to use it in mission-critical environment yet. But if you decide to adventure into this, it will be enriching endavour for all of us. The bugs can be filed in GNOME Bugzilla against evolution. Help us to make it better!

OpenSUSE Build Service

What is really really really cool with this installer is that it is produced completely inside the openSUSE Build Service, a wondeful tool, a once-in-a-lifetime innovation. All the binaries are cross-compiled from Linux and the installer is produced by a version of Nullsoft Scriptable Install System running on Linux and producing Windows installers. The installer is automatically regenerated when the rebuild of Evolution is triggered by any event: change in dependencies, change in Evolution version, etc. It requires a minimum maintainance and is a good starting point for improving further. Since such improvement can now be an incremental one building on the top of the existing infrastructure.

I will never say it enough, but openSUSE Build Service is one of the best invention on the earth since the Butterbrot

ISensNetwork based network monitor for Evolution

2010-03-29T15:39:00.001+02:00

These weeks I was using my spare cycles to prepare evolution to be buildable and running before the GNOME 2.30 freeze. One of the things that Evolution for windows was missing was an alternative for the NetworkManager network connection detection module. I crafted one using Windows ISensNetwork COM interface. The result is to be found here for those that might be interested in seeing how to implement COM callbacks in plain C.

There are some examples out there showing how to implement ISensNetwork. One of them using heavy ATL framework is to be found here. Another, one, using C++ is to be found here. Both examples have a little problem that actually prevents them from being properly used from unprivileged account, although they work well when Administrator runs them. The problem is that the registering of the event subscription will return E_ACCESSDENIED. Judging from the number of post on different fora when one querries Uncle Google, the solution is not very known. If you have the same problem, please check the plain C example that I crafted using the above-mentioned C++ code as a base. I discovered that specifying that the subscription is a per user one, by using IEventSubscription::put_PerUser(..) method allows your program to register for system events even if it is run as unprivileged user. The source code can be built with different flavours of MinGW and also with Visual Studio and the program installs an icon in the system tray that will notify you when connection status of your computer changes.

By the way, there is not a lot of sample code out there that would use COM from a plain C. Apart excellent code produced by my colleague and object of mute admiration, Tor Lillqvist, there is an wonderful serie of articles by Jeff Glatt. It is worth reading for anybody that wants to do COM the real men's way, in plain C. Here are the links to part 1, part 2, part 3, part 4, part 5, part 6, part 7 and part 8. It is worth to register and get the example code as well as a neat clean html version of the articles. It is enough to download the files linked from the part 8 since they are always cumulated with all files from all previous parts.

DBus for windows in windows:mingw repositories

2010-03-02T09:27:00.002+01:00

Last night two important new packages landed into windows:mingw:win32 and windows:mingw:win64 projects and repositories in openSUSE build service: mingw32-dbus-1 and mingw32-dbus-1-glib glib bindings for 32-bit Windows and mingw64-dbus-1 and mingw64-dbus-1-glib for 64-bit Windows. Although, they are known to work in certain setting, they might be buggy in others. So, if you build for Windows some package that needs Dbus, please use these rpms to solve that dependency. And if you find bugs, just report them against the corresponding repository. We will take care of investigating and pushing the reports up the stream.

As a nice result of this new packages would be that the development version of evolution-data-server and evolution should be buildable now on Windows too. Not tried yet though, but I know someone who did ;-)

Note that the dbus-1 package is based on the latest development tarball (1.3.0) and is brought to the level of recent git master by a patch inside the rpm package. The dbus-1-glib is basically the 0.84 tarball with a little patch allowing cross-compiling and disabling one test that hard-codes the use of Unix sockets.

So, please, use those packages, stress-test them and report all useful information.

DJGPP crosscompiler for DOS in openSUSE build service

2009-09-14T09:47:00.003+02:00

In case you need to build some binaries for some kind of DOS based bootstrap process, don't look far, the repository home:fstrba:msdos has all you need. A gcc-4.3.4 based cross-compiler for C and C++ along with the CVS HEAD version of DJGPP headers and libraries. The resulting executables running under DOS need a DPMI implementation like this one in the same directory to run.

When/If I have time, I will try to extend it to different languages supported by gcc.

Taste it and enjoy how sweet it is.

Contacts for Windows

2009-06-09T14:26:00.002+02:00

Yesterday, I saw a nice little application landing its first release on ftp.gnome.org. Its name is contacts. As I love challenges, I spent some time in my evening porting it to Windows®. You can see the result here.

It has a very basic user interface and I had to disable the bacon stuff, because I did not manage to finish its port, but it basically works and interacts with your local evolution address-book. Read and write.

When the rules apply only to some of us

2009-05-05T09:34:00.003+02:00

It is normally a rule for the community not to do any big and potentially risky changes in OpenOffice.org months before release. UI-freeze, feature-freeze are dates that if you miss them, your feature or fix will have to wait for the next release, or eventually for OOoLater tag. This is always true ...

... unless you are not the community member, but Sun employee. In that case, the rule starts to be a more flexible one.

To cut the thing short, if you are community member and are building ooo310-m11 with Windows and cygwin (and maybe only with Visual Studio 9, which is what Sun uses), you will realize that something changed and your build will consistently crash in the python module. The binary that will crash is the vcbuild.exe binary. What happened? Just our friends from Sun upgraded the python version of OpenOffice.org from 2.3.4 to 2.6.1 between release candidate 1 and release candidate 2. Theoretically, only show-stopper fixes are allowed in the RC phase, but since the rule is flexible depending on which side you are sitting, this could happen.

So, if you are on the wrong side of the flexibility, here is what can bail you out:

--- python/makefile.mk 2009-05-05 08:58:50.745625000 +0200 +++ python/makefile.mk 2009-05-05 08:59:45.261250000 +0200 @@ -117,11 +117,7 @@ # Build python executable and then runs a minimal script. Running the minimal script # ensures that certain *.pyc files are generated which would otherwise be created on # solver during registration in insetoo_native -.IF $(SYSBASE) != "" -BUILD_ACTION=$(COMPATH)$/vcpackages$/vcbuild.exe -useenv pcbuild.sln "Release|Win32" -.ELSE BUILD_ACTION=$(COMPATH)$/vcpackages$/vcbuild.exe pcbuild.sln "Release|Win32" -.ENDIF # $(SYSBASE) != "" .ENDIF .ENDIF

But given the way this was rushed through, don't be surprised if you have other problems later.

BTW, it is not like this problem was not known about beforehand.

Game, set, match for "Quality through process" approach.

UPDATE:

As pointed out on IRC, it is true that many people worked hard to make this - as agreed necessary - change possible at the late stage. I did not intend to offend them and stand to be corrected. The point here is that such changes are pretty risky at the late stage of release cycle especially because upstream does not use the same build environment as community. In the times where I was still bothering to push updates for libwpd upstream, I was often a victim of many procedural hickups. So, seeing a fast-track risky change in last moment is reminding me of all the hours fighting the bureaucracy. But, again, not intending to offend anybody.

HUNDRED (packages in windows:mingw:win32)

2009-04-28T15:42:00.001+02:00

It has been long time since I blogged for the last time and quite things changed since: My daughter and my son took one more year and my wife is every day more beautiful and younger.

It is not that I was not having things to blog about, but the main quality of many FOSS hackers, lazyness, is the reason of this relative quietness. But now there is something really really cool that pushes me to blog again: At the end of 2008 and in the beginning of 2009 I was trying to come up with a repeatable and dependable way to build GTK+ and GNOME software for Windows.

I, myself, maintain several libraries and I build their Win32 versions on my Linux box as I described it here. So, the cross-compilation came as a natural reflex. I inspired myself by the infrastructure that the Fedora mingw project used and started to go through the usual cycle of while (!tired()) { build(); debug; }. And last night, I reached a milestone. My package repository hosted by openSUSE Build Service received its package number hundred.

Why am I saying all this? In fact, these packages are not only there to be a decoration. Many times, people that know about my work ask me for packages of different libraries. All the stuff that I build (or almost all can be found there). People asking for win32 version of the GTK+ port of Webkit can be interested in the mingw32-libwebkit package. Those that would gladly try to use Evolution as their mail client on windows, can find the updated mingw32-evolution package useful. It is enough to add the repository to your installation sources and lauch zypper ref; zypper in mingw32-evolution mingw32-tango-icon-theme and the rpm dependency resolution mechanism will pull all you need for you. After that, you can just zip the content of /usr/i686-pc-mingw32/sys-root/mingw directory and you can unzip the resulting package on your windows box. As simple as that!

For developpers that would like to cherry-pick packages and use them to develop their own, it is the best to to fetch them from the openSUSE 10.3 version of the repository. For later releases, openSUSE's rpm uses lzma payload and it can be a bit more tricky to uncompress the packages on a typical windows machine, although 7zip should know what to do with them, I guess.

As a technical information for developpers, all the binaries are stripped of unnecessary sections and the debugging information can be found for each source package in a separate package typically named mingw32-%{name}-debug-%{version}-%{release}.noarch.rpm. Uncompressing them in the same prefix as the corresponding binary packages will cause gdb.exe to use their symbols and you can produce meaningfull traces.

I still contend that the best way to use those packages for developping your own software is in an openSUSE installation. And the side benefit is that in this way one gets not only nice development environment for Windows development, but also the arguably best operating system in the world as a host.

I might take some more courage and write about Windows porting of software when I rest from writing this blog entry. While waiting, it is worth to read this little collection of slides of my distinguished colleague and incontested master of win32 porting, Tor Lillqvist. Everything I know about win32 is because of sitting at his feet.

Just in case you did not see this one

2008-10-07T09:18:00.000+02:00

http://www.keatingeconomics.com/

Yes, we can!

2008-02-18T10:36:00.003+01:00

Starting to realize more and more how much different would be Obama's America from the Bushistan we know today.

Link

Happy birthday, Miriam!

2008-02-14T11:26:00.002+01:00

Happy birthday, Mirka!

Pleased

2008-01-15T12:38:00.000+01:00

Your servant is extremely pleased to see Erwin advertize a laptop that is running SUSE Linux Enterprise Desktop 10 and OpenOffice.org Novell Edition. Thanks, dudie!

Frankfurter Allgemeine hacking

2007-11-22T13:45:00.000+01:00

It was decided on Tuesday afternoon, that I should converge to Nuernberg to meet my favourite manager JPR and my dear colleague Florian, in order to complot about possible changes to Writer core in order to increase its interoperability with one competing product.

Since the decision was a little bit short notice, the only way to travel was the train. So, I took a night train from Geneva at 19:14 and passed Basel and Frankfurt Flughafen (sic) to arrive finally at 8:02 to Nuernberg.

What a wonderful journey of almost 13 hours of pure hacking pleasure. Especially that German ICE trains have electric plugs under every seat. Like that I was always able to recharge my laptop battery and use it during the long hours between trains. Especially, during the more then two hours in the empty Frankfurt Airport railways station.

An attentive reader is asking "why all this bla-bla?" And the answer is that thanks to Jaroslav Fojtik of wp2latex fame, thanks to his reverse-engineering skills, and also thanks to my dearest employer and to this long journey, I was able to touch 275 files and make the HEAD CVS libwpd support conversion of password-protected and encrypted documents for almost all supported file-formats (except WP6+ that we were not able to decrypt for the while).

I also forgot to mention, that since a week or so, the duo libwpd-writerperfect is not depending on any desktop specific library. Writerperfect can still use libgsf for the zip output if one insists by giving it a configure option --with-libgsf, but it produces nice ODTs and ODGs even without it. Thanks to Ariya's FemtoZip namely.

Happy Birthday, Darling !

2007-10-25T12:04:00.000+02:00

Happy third birthday, Patrick!

ITO, Sweet ITO

2007-10-18T13:21:00.001+02:00

I love this! I misunderstood a bit what the ITO was and at certain point I realized that I have accumulated quite a load of it. So, I had to spend it somehow. Here is the account of what it was useful for:

Finishing off what was started in Barcelona

Naturally, if you speak to me about fun hacking, I will always have the image of libwpd or libwpg coming to my little brain. As I blogged earlier, the first thing I used some time for was to finish off the work on tabulator conversion for WP 2.x - 3.5e for Mac and WP 5.x for DOS/Windows file-formats. It was started in Barcelona and the principle of release soon, release often dictated that it should not sleep on my disk for long time. I got even a very positive echo of the overwhelming part of our Mac OSX user community after the 0.8.12 release (Yes, Smokey, you are about 87.49% of our active Mac OSX community :-)). So, if you did not do it yet, throw yourselves on the binaries and sources while they are still available.

Buffered stream implementation

An old proverb says that one should try not to put off useful people. This was also one of the reasons why I deprecated in latest releases of libwpd our libgsf-based stream implementation. Understand me well, libgsf is a fine piece of software and is doing a lot of good to the world. Nevertheless, since libwpd is used by the Koffice people along with some other office suites, I did not want to keep it depending on a platform specific libraries. Moreover if the functionality that we use from these libraries is really very very very very tiny. So, we used a hacked version of Ariya's pole (one header and one source file) to provide two additional WPXInputStream implementations that do not depend on anything besides a working STL implementation.

So far, so good, but... As long as the C++ streams (as I call them) became the default for the internal libwpd tools, we came to the point where the above mentioned proverb was going to be put into task again. Suddenly, Sum1's QA run started to take several days instead of a night with the libgsf-based stream implementation. And putting off Sum1 is something that every hacker with some rudiments of sane mind should avoid at all cost.

In the same token, some other performance issues were reported from other contexts and the fact that libwpd reads at most 4 bytes in a single read started to show as a real problem. So, some time ago, inspired by Kendy's intent to implement read-ahead to WPXSvStream, I hacked something similar to the sample WPXFileStream. But, there was a problem. Very probably a hideous bug in libstdc++ is causing in some specific cases a seek backwards by 2 bytes with a consecutive read of 1kB result in a badbit being set. And this mainly on x86 with gcc 4.x (x86_64 was working well). Even x86 with gcc 3.4.x worked well as well as our distinguished competitor's Visual Studio compilers. Since I did not have much time down there to look into it, I left the idea of buffered read hanging.

Now, during my ITO, I gave it a quick second shot and by a sheer luck I found a workaround that is not really penalizing in terms of performance, and makes the buffered stream work well. The solution is simple: before the read, seek to the end of the block that we want to read and then back to the position where we want to start to read. With this incantation, the subsequent read does not set any badbit anymore and everything is nice in the best of the worlds. Nonetheless, if a libstc++ hacker is interested in investigating into this bug, I have a historical version of the stream with a sample document that always triggers the above mentioned behaviour.

Positioned objects in WP6+ and ODF reference implementation woes

The main task I was prepared to accomplish since our dear hackweek already, and waited only for an enough long contiguous free time, was to get the size, the position and the anchoring of the positioned objects (images, text boxes,...) right. The problem was in multiple places. First of all the way the box information is encoded in WP6+ files is really only remotely connected to an idea I have about a fun hacking. The box/frame style is an old good way binary encoded information (if the bit 15 is set, the following information is available... etc.). The code that is inserting the box/frame can override style and whether it does so or not is again given by some bits of a number at the begining of the code. Added to it an acquired mistrust towards the Corel provided documentations, I was not really hot to spend my week-ends on this. Nevertheless, some recent user demands and the vision of a well used ITO made me to bite the bullet. And surprisingly, the main difficulty was not where I expected it to be. This time the documentation was right (at least for the information that I currently use). This time the tool I trusted always the most, wplook.exe from the WordPerfect Office 11 SDK, got some things wrong and segfaulted on accessing the box/frame information of certain documents. But once understood where to put my trust, the information I needed was extracted and ready to be processed.

And it is there where the real problems started. On one hand the WP6+ file-format is much more expressive then ODF concerning the object position. Thinks like shifted one inch left from the center of the page text area is not mapping directly to anything in ODF. And given also the fact that in WordPerfect the page margins can be set different for each paragraph, the position is not as easy to compute as one could expect. Nevertheless, the biggest surprise came from the way the reference implementation of ODF handles page anchored objects that correspond to the second case of text:anchor-type="page" referenced at page 294 of this file as well as at the page 303 of this one. According the specifications, if one omits the text:anchor-page-number property, one would expect that the frame appears at the same page as the character immediately following the draw:frame closing element. And this is exactly what happens inside WordPerfect, so I was happy like a child. Premature happiness though. When our dearest reference implementation finds a page-anchored frame without text:anchor-page-number property, it assumes apparently that this is just a forgetful mind of the filter writer and adds a text:anchor-page-number="0" attribute. This invariably places all the page-anchored frames outside the specified range for page numbers (1..N) and thus outside the document (although they still remain in the file fortunately).

So, there are two possible workarounds that I managed to find. Although none of them is satisfactory for different reasons. The first consists in using the hints WordPerfect formatter leaves in the file for itself to improve the speed of rendering. One can use the soft page breaks and hard page breaks to count on which pages we are in the given moment positioned. It is a possible workaround, but does not do good job unless the documents are reasonably short. With long documents, font substitution and not completely correctly converted spaces between headers, footers and the text area, one will find oneself with frames drawn on completely unrelated pages. So, this solution has little of my sympathy. The second workaround is to use the text:anchor-type="char" with which the anchoring is also relative to the position of the first character that follows the draw:frame closing element. And it works well as a workaround. My principal caveat is that although our reference implementation of ODF standard accepts in such cases the values "page" and "page-content" for style:vertical-rel attribute, according to the tables on the page 660 of this file as well as at the page 672 of this one, they are not conforming to the specifications given the anchoring. So, although the files I generate using this workaround do the right thing^TM for me, they are strictly speaking not a correct ODF (although the validator is not detecting it) and other implementations might refuse them or render them completely incorrectly.

Frankly, I did not have time to dig into the code that implements this frame-related stuff, but someone who knows where to look might maybe find it rather trivial to fix. I said, "maybe", right?

The people wants screenshots!

I know, I know, and here is one.

I want hereby also thank my distinguished employer for making this possible by giving us the privilege of ITO (Innovation Time Off). It is really sweet to be able to accomplish things like this in the company time. And for those who face customer requests for converted WordPerfect documents with images and text boxes, the std::answer you will receive from me will be from now on to use the CVS HEAD of libwpd, libwpg and writerperfect to produce the wpd2odt tool that knows it all.

Password protected WordPerfect documents

2007-10-11T12:57:00.000+02:00

Because we live in very interesting times, some information might be pushed to background. Even though it is very important one. Last week-end an e-mail of Jaroslav Fojtik announced me his success in finding a way to decrypt password protected WP 3.x for Mac files. Just to precise, it is not about the protection cracking, just about the ability to read password protected documents using FOSS once you know the password. This masterpiece of reverse engineering (which is completely legal in some parts of the world) adds this file-format to the WP 4.x and WP 5.x for DOS/Windows that FOSS world was already able to decrypt.

The only file-formats that we are still not able to decrypt are WP 1.x for Mac and WP 6+. For the former, work is currently being done, for the later, it looks like it is a bit harder nut. If anybody of people reading this entry has any useful information about the encryption of the WP 6+ documents, please read here. We would like to stress that we are not interested in the password cracking and other illegal activity. We want simply to make it possible to a user of FOSS to read its own WordPerfect documents that she once protected using a password. So, abstain from communicating information whose publication could be illegal in your jurisdiction. OTOH, a genuine help with the decryption is most welcome.

The API for decrypting WP documents will most probably be part of libwpd 0.9.x series.

Barcelona no s'acaba a Catalunya

2007-10-11T12:02:00.000+02:00

libwpd 0.8.12, codename "Barcelona no s'acaba a Catalunya", left its mother's womb yesterday. Besides build fixes for the upcoming gcc 4.3, this release features initial (although not really so lame) support of tabulators for WP 2.x - 3.5e for Mac and WP 5.x for DOS/Windows file-formats, tabset conversion in WP 5.x, as well as some font ID to font name mappings for WP 1.x for Mac file-format. The cross-compilation framework was drastically updated and a compilation with Sun Studio 12 for Linux was also tested and this release is reputed to work with it.

As the name indicates, the major part of the code for this release was done during the wife-less nights spent at the OOoCon2007 in Barcelona. Although, as the name also indicates, some code was added even once outside the territory of the Paisos Catalans.

It is a free software released under LGPL and it is free as beer, so take it, taste it and enjoy it. The rpms for different SuSE and Fedora flavours can be found in my openSuSE build service home repository. The cross-compiled win32 binaries are to be found on the libwpd download page.

Besides the normal authors and contributors, the thanks for this release go to our very own Smokey Ardisson, to Rob Staudinger, Hub Figuiere and, last but not least, to my dearest employer, Novell, Inc. and its Innovation Time Off program.

Honest Broker?

2007-10-04T16:02:00.000+02:00

John, I completely agree with your point that one can assign copyrights to an entity if one can trust it. Where I don't agree is in your conclusion whether Sun Microsystems is such a honest broker. My own experience from the project is that a lot of lip service is payed to improvements of all kind, but that more the things change more they are the same. And I have a tendency to distrust entities that are full of good intentions at long term, but when the long term becomes shorter one is seeing basically no result.

Not that I am expecting anything good to happen. Between helping to build a strong developer community and trying to accumulate other people's code for proprietary licensing, Sun already decided anyway.

On the way to desktop freedom

2007-09-28T14:00:00.000+02:00

Not so long ago, I blogged about my strive to get rid of the need of running non-free operating systems while developing and maintaining my (our) different libraries. One step towards freedom was to find different emulators that could help to generate WordPerfect documents. That problem solved, one last thing was forcing me to have access to a non-free operating system. By the respect to our users and knowing that a typical Windows user is not really very good at operating compilers, for each release of libwpd, libwpg and other related packages, I was booting the win32 partition to maintain the MSVC project files and to build release binaries for Windows.

This time is over now. First to contribute to my liberation was the CrossToolChain repository in OpenSUSE.org Build Service. The MinGW cross-compiler is already successfully used to build the infamous unowinreg.dll during the OpenOffice.org build process. So, I gave it a shot and, after some modifications of the makefiles, the cross-compiling is a reality. What a pleasure to be able to run make -j9 and have the libraries built faster then their shadow! Inspired by some ingenious scripts by my distinguished colleague Tor Lillqvist, I even have a creation of release packages scripted and don't have to do much manually anymore. Some of the credits go also to an extraordinary expert in cross-compilations of all kinds, Rob Staudinger, who helped to implement some of needed configure options.

The last milestone that was remaining on the way to freedom was a need of Microsoft Visual Studio to maintain the MSVC project files in the different libraries. But, this problem is solved now too. The key of the solution is called CrossOver Linux Professional. Last night, helped by Uncle Google, I managed to install Visual C++ 6.0 SP6 in a managed bottle. The cool thing with the Professional version is that once the bottle properly installed and configured, one can create an RPM package and deploy it on other computers. And the application is basically accessible to all users of the computer.

For those who are impatient to see how MSVC running under linux looks, here is what you are waiting for!

By the way, I forgot to say that if you are running one of SuSE or Fedora Linux distributions and are keen to have the newest of the newest for libraries that I maintain or contribute to, you might find useful packages in my home project in our dear openSUSE build service. It is enough to chose your distribution and point the yum, zypper or other favourite package manager to the corresponding repository. So, pick the packages and taste how sweet they are!

WPG Import

2007-09-25T17:50:00.000+02:00

Recently in Barcelona, I was interested to hear there was some confusion over how the beautiful Word Perfect Graphics import was created. Since it is now shipping in most ooo-build based OO.o 2.3 versions, it'd be great to give full credit for all those who got over the time involved in it's creation and use in various FOSS applications.

Time-line

At certain point in 2006 I realized that because of lack of time I was neglecting one little useful library that I was also developing, libwpg and I made in my blog a call for new developers hoping that someone will bite the bullet.

Mathias Bauer (from Sun Microsystems) contacted me and proposed me work on this library could become part of OpenOffice.org SoC projects for 2006. After some e-mail exchanged, we agreed on the modalities of the participation: that libwpg will be developed as a standalone library (since it already existed as such) under LGPL because it was meant to be reused by other applications. Another agreement was that the goal was that the output of the Summer of Code will be standalone converter for wpg files to odg file format. This converter was supposed to be licensed under LGPL and its author was supposed to share his copyright with Sun under our beloved JCA terms.

Summer of Code candidate

I was contacted by several students in private and my choice was Ariya Hidayat of Koffice fame. The reason was that I knew his code and was quite sure about him being able to do good work on the library and converter. I worked (in my own free time, btw) together with him during the SoC on separable features, like reverse-engineering the WPG1 palette or implementing OLE2 stream abstraction. And it was really great to collaborate with Ariya who is an extraordinary hacker. What was promissed, that was done. Ariya's project got accepted for the Google summer of code, he signed the JCA, developed the library and added into it WPG2 support. In the same time, he developed a command-line tool called wpd2odg in a separate module. When the GSoC came to the end, the conditions for a successful accomplishment of the project were satisfied, the student got USD 4500 reward, Team OpenOffice.org e.V. got USD 500 and some Google swag like t-shirts and (paper) notebooks changed hands too. The "contract" was fullfilled and everybody was happy in the best of the worlds.

During the work on his Summer of Code, Ariya did an extensive blogging action, and one of Inkscape developers used a private copy of not yet released libwpg as a base for their WPG import.

After the Summer of Code

During the nights of the OpenOffice.org conference in Lyon, instead of sleeping, your servant was trying to implement a WPG import plugin as an add-on component for OpenOffice.org, one of those beasts that one builds using the SDK and that one installs using the Extension manager. It became clear that one had to refactor the wpg2odg command-line tool from scratch so that it generates Sax messages instead of a string in ODG file-format. At the end of conference, there was a refactored version of the wpg2odg tool and a non-working wpg import filter plugin for OpenOffice.org. Your servant's little brain managed to debug the plugin and have it detect correctly the WPG files and actually show some images only at the begining of October 2006.

Immediately, an OpenOffice.org integration was intented. It means, your servant tried to incorporate this plugin into the OpenOffice.org build-system as a new module. Nevertheless, since the implementation met some problems of locking when trying to imbue a locale into a C++ std::ostingstream, and your servant was pretty busy looking for a job that would help him feed his family, the work stopped there.

In the meantime, Dom Lachowicz of AbiWord fame modified the libwpg library adding into its API an SVG generating class so that it could be better reused by SVG supporting applications. Later, Marc "uwog" Maurer, implemented, using the libwpg SVG generation class, an AbiWord plugin enabling use of WPG cliparts in AbiWord files.

Hired in March 2007 by a nice company to work on OpenOffice.org, your servant requested permission to do some work on WPD and WPG filters in company time. The permission was granted and the whole odg generation framework used in the previous plugin rewritten to avoid having to use the problematic imbue on the stream (or the stream at all). The result is a patch that landed into ooo-build on 7th of May 2007. Since then, it underwent many changes due to the sharp eyes of Rene Engelhard and also due to an extensive QA by Sum1 whose favourite sport of trying to crash and tear down anything I produce is a great way to assure that my software is having a good quality inspite of the limited brain activity that TrainedMonkey is capable of.

This Summer, Ariya worked again on the libwpg library and added conversion of WPG bitmaps embedded in WPG files. During the Novell Hackweek, your servant wrote a BMP generator to be able to pass these bitmaps to OpenOffice.org and also added handling of embedded binary objects in alien file-formats (wmf, png, eps, ...). Again, thanks to AbiWord's Sum1, we were able to add handling of bitmaps in almost all supported colour-depths (indexed and direct). The result of this work is to be found in any ooo-build based OpenOffice.org 2.3 version.

Who did what

Libwpg library was written by Marc Oude Kotte, Marc Maurer, Fridrich Strba, and Ariya Hidayat. Some of the copyrights are owned by Novell because your servant was working on this library in his company time too. Some build patches were submitted by Robert Staudinger of AbiWord fame. The library is released under the terms of LGPL with some parts being licensed under BSD license.

Wpg2odg (command-line tool and the OpenOffice.org WPG import plugin extension) was written by Ariya Hidayat and Fridrich Strba. Sun Microsystem is joint copyright holder of some parts of Ariya's code and Novell is owning copyrights of some code contributed by your servant. This tool/plugin is released under the terms of LGPL with some parts being licensed under BSD license. One can use it as an OpenOffice.org extension, provided that one has libwpg library installed on the system. As a matter of fact, it runs even on some non-free operating systems with some non-free office suites.

The integrated WPG import filter in ooo-build is licensed under the terms of LGPL and copyright holders are Fridrich Strba with Novell for a huge majority of the code, Ariya Hidayat jointly with Sun Microsystems (for certain parts of the code). The patches from the above-mentioned links are free software and can be used by anyone under the terms of LGPL.

I would like to thank all those who contributed to making wpg import a reality on the free software desktop. And for those who are interested, libwpd 0.9.0 (whenever its release happens), will use libwpg for converting images embedded in WordPerfect documents.

Emulators

2007-09-13T11:49:00.001+02:00

Writing import filters for different WordPerfect^TM file-formats can be fun and rewarding. Nevertheless, apart one rare exception, all WordPerfect^TM versions run on non-free systems (Solaris Sparc, Mac OS, Micro$oft Windows). As a free and opensource software developer, moved by the will to be consistent with my own convictions, I develop using free operating system. But for filter development, and especially in cases where the documentation available is rather sketchy, it is a necessity to do some reverse-engineering. For this, one is really obliged to have working copies of different versions of WP. And also to run some versions of non-free operating systems. Nevertheless, having a server room in one's appartment can be considered as wife-and-kids-unfriendly act, and rebooting every five minutes to another partition is not so efficient workflow-wise. The good news is that a big part of the problem can be solved using free software.

For Windows versions, a solution was already outlined by Ariya some time ago. I modified a little bit the software installed and managed to fit all the necessary Windows and DOS versions of WordPerfect^TM on less then half GB disk image running a 98lite-modified version of Windows 98SE. The screenshot of this situation can be found here. The advantage is that such an image is fitting quite confortably on a USB stick.

Another problem was the Mac OS versions. And here it is really crucial to have a running versions. Because for some of the old file-formats, the only documentation that web is able to give you is the libwpd source code and this blog entry. And inspite of the "Mac Mini donated by unnamed on behalf of unnamed", the situation was less then optimal. Besides the fact that my KVM switch supports only PS/2 keyboard/mouse ports and a normal VGA monitor connector, it is quite difficult to use the Mac Mini when traveling. And frankly, MacOSX is quite an overkill for applications that install and work happily in a MacOS8 running on a Quadra. After looking on internet, I decided to give a ride to the Basilisk II emulator. After some time of struggling and helped extensively by Filip Molcan, Hubert Figuiere and hsfutils, I am able to run a little MacIntosh on each of my GNU/Linux computers, i386 as well as x86_64.

Although I installed all this thing on a disk image of 512MB, I realze that I have still more then 400MB of free space there. But even 512MB is small enough to back it up on a CD and put it somewhere on a USB stick. I also have to admit that I am quite impressed by the stability and speed of BasiliskII emulation. On modern processors, the emulated MacOS8 works faster than I ever have seen it running on a native Apple hardware back then when we were still young and handsome. I will not go into the details of the installation, but if the popular demand is there, I might document things that are not well documented on the web.

So, now only one little problem remains. How to run the WordPerfect^TM 5.1 for Solaris Sparc? Anybody knows about an emulator that could run the version 2.5 of this proprietary system?

Amused

2007-09-12T12:10:00.000+02:00

I was mildly amused when reading Michael's blog. Suarez-Potts had nothing else to invent to bash Novell then to start to criticise the way they spent money to bring developers to one place. In my not so humble opinion, inspite of the food served in the "World Capital of Gastronomy", there was not really anything to say against that experience. It was way better then the some-special-selected-people dinner sponsored by another company in Koper.

I was just wondering whether it is the same Suarez-Potts that did not refuse to profit of Google hospitality (flight and hotel payed) during the Google Summer of Code "Mentor" Summit. Funny enough, I don't remember suddenly what was the Summer of Code project he was mentoring last year.

But the bottom-line of this is that LSP is even criticizing the fact that people want to contribute engineering resources and try to encourage developers to contribute to OpenOffice.org. Just wondering whether Louis has an idea about what a FOSS project is. It is all about producing software and as good software as possible. As a by-product of this, there can be human relationships of other type that come to be, but the focus is still on the software.

Although it is true that OpenOffice.org project "structures" are quite efficient at producing talking shops instead of developers, this situation should be considered more as a dysfunction then as a normality. As well as it should be considered dysfunctional to have someone who is not developer representing OpenOffice.org at hacker's meetings. What is the argument such a person can have to encourage contributions? What level of understanding of everyday concerns of a FOSS hacker?

Frankly, it should be our target to fight these dysfunctions. And only if we succeed in this, there is hope that the "OpenOffice.org Community Manager" will have actually something to manage.

x86_64 tinderbox slave

2007-09-07T14:04:00.000+02:00

Just to tell you that we just added into the OpenOffice.org tinderbox build an x86_64 slave. Moreover, it builds with gcc-4.1.2 and with FSF java. So, if your build breaks in java files, check whether you did not write in an "übersetz mich" or other umlaut containing words. The other typical errors might be extra qualifications in declarations of C++ classes and/or treating of ULONG/LONG as if they were assured to be 32-bits. Keeping this in mind might prevent too frequent red status.

Thanks to Intel that provided this machine last year. And thanks to Christian Lohmaier who is guiding it and forcing it to do the right thing.

libwpg-0.1.0 - Initial release is out of the door

2007-08-08T18:25:00.000+02:00

Not without a lot of joy, I am announcing you that early this week a happy event took place and libwpg-0.1.0 official release came to be. Libwpg is a library for reading and converting WordPerfect^TM Graphics (WPG) files. In can be used by converters or renderers. A convenience tool and API for generating Scalable Vector Graphics (SVG) from a WPG file is included. A private statically linked version of this library is currently used by inkscape in their WPG import filter. The Novell Edition of OpenOffice.org 2.3 will also contain a WPG import filter based on this library, as well as the upcoming AbiWord 2.6 release.

As every initial release, even this baby might have some rough edges. Nevertheless, we are confident that it will bring joy to its parents and to all those who will have any use of it.

The thanks for this release go to many people. First of all to Mark "uwog" Maurer and Will Lachance, of multiple fames, for instigating this project. To Mark Oude Kotte (aka Foddex) for starting it, to Ariya Hidayat for doing almost all the work. AbiWord's Sum1 took his time tearing the library down and filing bugs against it before it even came out of its mother's womb. Thanks to him, we were able to catch and fix many bugs. Last and indeed least, the thanks go also partly to me who will take all the glory and to whom you can send your donations and thank-you contributions. We definitely should not forget Uncle Google who put some $$$ into this endeavor in the frame of Google Summer of Code in 2006.

The source packages and convenience binaries for Win32 platform can be found here. You are encouraged to download the, pet them, delight in them and maybe use them before they finish in the Wastebasket.

Enjoy and send your bug reports and feature requests to libwpg-devel mailing list (you'll have to register to do that though). And if you feel an urge to code, your patches will be most welcome at the same address.

Hackweek: The devil is in the details (or ODF generation woes)

2007-06-29T15:04:00.000+02:00

Yesterday, I was poluting planets with my story of converting images included in WordPerfect files. There were still some missing links and thus it is nice to give you another screenshot. Christian Lippka, a supreme intelligence of OpenOffice.org Draw and Impress fame, helped me to examine the OpenDocument Drawing objects that I was creating. The problem was that they were not scaling to the frame they were supposed to sit in. And we found the problem. (OK, he found it!) The solution is to include in the drawing document this XML snippet:

<office:settings> <config:config-item-set config:name="ooo:view-settings"> <config:config-item config:name="VisibleAreaTop" config:type="int">0</config:config-item> <config:config-item config:name="VisibleAreaLeft" config:type="int">0</config:config-item> <config:config-item config:name="VisibleAreaWidth" config:type="int">7941</config:config-item> <config:config-item config:name="VisibleAreaHeight" config:type="int">19124</config:config-item> </config:config-item-set> </office:settings>

The two magic numbers are width and height of the image in 100ths of milimeter. BTW, I am interested to see what will happen when this code starts to be used for their WordPerfect importer also by KWord. But, here I will leave Ariya the pleasure to handle possible implementation differences.

And so, thanks to the light of Christian, this is how the document looks like now. Ok, I have to confess a little cheating. The dimension of the frame is for the while not read from the file by a parser. I was quite lazy to start to parse this information. It is for the time being hardcoded in the code, but should not be conceptually difficult to parse the information,... just boring to death.

I would like to mention also another person that gave me a useful tool that I was using during this week. Far from being anything close to XSL(T) fan, I found extremely useful Svante Schubert's transforms that allow to load and export files in OpenDocument flat XML format in and from OpenOffice.org. It is a load easier like this to make little experiments with document without having to run zip and unzip zillion of time.

So, what remains to be done? Naturally, to write the parser of the box information for different WP file-formats inside libwpd. This is something I am really finding very boring and ungrateful task. So, if you want to be my personal hero, send me a patch.

For those WordPerfect users that have a load of documents with images, the documentation says that one "Graphics Filename" prefix packet can point to several "Graphics Cached File Data" packets that contain the graphic information. Nevertheless, the documentation does not say how the data is split in this case. In several full-blown WPG streams or in one WPG stream that has chunks stored in different prefix packets? I was unable to create a document with several pointers in the "Graphics Filename" prefix packet, so if you have some of them, here I am to receive them. Or even better, send me a patch for their handling in libwpd.

Hackweek @ Novell

2007-06-28T16:21:00.001+02:00

It was said, it was repeated and repeated. This week, is a hackfest week at Novell. We are hacking (programming for those who do not like the word) on different projects/ideas that are close to our heart. Naturally, TrainedMonkey(tm) could not remain behind. And guess, what projects he chose to hack on... Naturally, libwpd, libwpg and their OpenOffice.org-related filters. It is really nice to be upstream maintainer of several things, like that, when given a week of free hacking, one is likely not to lack ideas what to do with the time.

The import of embedded pictures is one of the most overdue features in our WordPerfect(tm) converter. So, I jumped on the task when this opportunity came. And fortunately, not everything had to be coded from scratch. Ariya, in the frame of a Google Summer of Code project gave a decisive push to libwpg and he has kept working on improving it. We came to the point, where standalone WordPerfect Graphics files can be nicely converted to SVG or ODG including embedded bitmaps. So, what were the steps to do?

First of all, it was necessary to port libwpd/writerperfect to generate OpenDocument instead of the legacy OpenOffice 1.0 file-format. This was needed because of the nice way, one can incorporate binary objects in OpenDocument represented as flat XML. This was accomplished on Monday, and the conversion of all documents from libwpd regression suite produces a nice ODF stream that validates against the OpenDocument 1.1 strict schema.

Next step was actually to parse the embedded image data in WordPerfect documents. A nice discovery is that in old WP5.x documents, the images are stored without the WPG header. So, one had to hack into libwpd a possibility to force the document parsing even if it does not recognize it. This was done on Tuesday.

The same day in the evening, I started to hack on passing the data libwpd gives us to libwpg and processing its output and incorporating the images into the OpenDocument text stream. This work continued on Wednesday and resulted in finally seeing an image. The scaling and anchoring was not good, but at least one could see something else then lines of cheesy C++. But it was really hard to make the generated documents (although valid according the ODF schema) load nice and display the pictures well. I poked some people whose brain should be a bit better then a brain of TrainedMonkey(tm), but did not manage to get more intelligent. And since a soup is never eaten as hot as it is cooked, I left it there for the night.

A night brought some rest for the mind and I started my day by a nice chat with the guy who is expert in pictures embedded in OpenOffice.org Writer documents. I came to the conclusion, that the best would be to include those images directly as <draw:object> inside a <draw:frame>. The advantage is that this would keep the images as editable pictures, the same way the Corel customers can edit them inside the WordPerfect Office(tm) applications. This meant to throw a big chunk of Wednesday's code in favour of a more elegant solution. For those familiar with libwp* world, the OdgExporter class was copied to writerperfect too :-) (Now it is part of Novell's WPG import filter for OpenOffice.org, of wpg2odg tool, of perfectspot graphics viewer, and now of writerperfect). There is a way of improvement, since it is likely, that it should not be very difficult to join wpg2odg and writerperfect in one source package.

I spent some time trying to debug my code, since the images were not showing. Then, by chance, I discovered that the devil was in the right office:mimetype attribute of the embedded object :-(. So, now one can see the images inside a frame. The scaling is still not correct, and I am not sure at this moment, whether I will be able to scale the image as whole or will have to scale every single shape on import, but it results in something that is editable. And that was the goal of the rewrite.

Tomorrow, I will try to code again the parser of the box information, so that we extract from the file information of the box anchoring, size and position. This promisses to be quite a boring stuff, but necessary missing link.

BTW, libwpd and libwpg will not refuse any fine hacker that would like to contribute to enhance our conversion feature-set while still keepeing our stability and document import rate.

An (almost) ideal OpenOffice.org build box :-)

2007-05-21T11:03:00.000+02:00

It was supposed to be cold this weekend, since it started by quite an abundant rain, and our central heating is not considering May as winter month anymore. So, I decided to do something to increase the temperature of our apartment. I have a little Sony Vaio PCG-SR11K laptop lying around. It used to be a nice little tiny and portable machine in its time with the cute 10.5" display with a resolution of 1024x768. But, given the Pentium III processor, running at 600 MHz, and 256 MB of memory, it is working quite well for reading e-mail, browsing web and doing some little other tasks, powered by SuSE Linux Enterprise Desktop naturally, but building OpenOffice.org does not look like a great idea.

Yes, sure, if a quick build is what one wants to obtain... Nevertheless, I gave it a try. Just for the sake of preventing the processor of being too idle during the build I tried two builds in parallel. A stock ooo-build (our dear Novell version) configured --with-distro=SUSE and a vanilla SRC680_m210 with the CWS writerfilter2 integrated. The later build was with as many system libraries as possible and also with the --without-stlport4 option.

I put the laptop in a position to be sure that the CPU fan has a lot of air circulation and fired the two builds at 19:00 on Friday. The ooo-build one (without the SDK and binfilter) was finished on Sunday somewhere between 10:30 and 13:00 (I checked it when back from Church, so I cannot give smaller time fork). The vanilla build finished partially on Sunday at about 18:00. Yes, I forgot about the damned extra qualification in sd module and was quite happy that I issued the build command with --all --ignore options. Once fixed that one and patched out some stlport-only features from the writerfilter module, the successful packaging process was announced at about 22:00.

The bottom-line is that the laptop survived it although it was nearly impossible even to read the e-mail while building. The temperature of the house was quite pleasant, partly also because the Sun (not Microsystems) decided to show up from Saturday morning. Nevertheless, the temperature of the air going out of the fan is indicating that putting that "laptop" on one's laps while building can be quite dangerous for reproductive health :-)

Qemu and kqemu on SLED10 SP1

2007-05-21T10:23:00.000+02:00

Ariya, maybe an even easier way would be to take the kqemu and qemu source packages from SuSE Factory, and run rpmbuild --rebuild kqemu-<version>.src.rpm and install the resulting kernel modules. After that, rpmbuild --rebuild qemu-<version>.src.rpm and install the result as well :-) This is the way it worked nicely on my SLED 10 SP1.

Completely agree that Qemu is a nice tool for all filter developers.

Focus on the logic behind a file-format, not on the container used

2007-03-02T11:44:00.000+01:00

Diving into the Office Open XML file-format and in the same run into all other MS Office file-formats (if one makes abstraction of the container, content is the same), one realizes the different ways that can be used to store the same thing. Unless designed with interoperability as a pricipal aim, a file-format's logic reveals nicely the way the application that produces it operates. And the fact that it be binary file, a compressed structured document composed by several xml streams, or a RTF-like file is not making much difference (apart of the difference in human-readability). And it is exactly the difference in the underlying logic that renders impossible to reach an optimal result in translation by using a descriptive tool like XSL transformations. Let's enjoy together the main difference between MS Office, WordPerfect and ODT/HTML file-formats:

MS Office

The main idea behind the MS Office word processing file-formats (.doc, .rtf, .docx and other xml-based attempts) is that the node (paragraph, section, ...) properties are "stored" in the "character" that marks the end of the node. I.e.: The paragraph properties will be all properties that the paragraph break marks finds set. And these properties will be properties of the paragraph whose end this paragraph break marks. From the point of view of the document flow, with some nuances, the paragraph properties are applied retroactively to the current paragraph. And it is similar with the section properties.

WordPerfect

The WordPerfect file-formats reflect also well the underlying conceptual model of its application: typewriter. As well as in MS file-formats, a WP file can have the paragraph or page properties defined anywhere in the document. And the codes are applied as soon as the formater is able to do it. Nevertheless (with the exception of headers/footers that appear in certain WP file-formats on the same page as the code that defines them), they are never applied retroactivelly. The properties are crossing the boundaries of hierarchically superiour elements. I.e.: If one sets direct code of "bold" somewhere in the document, this code will be valid and have effect untill another code that cancels it. The number of page, column, ... breaks between the two does not matter. If one changes a paragraph alignment in the middle of the paragraph, for instance, newer versions of WordPerfect will add a "temporary hard return" code before the alignment code to hint that a paragraph break is necessary in order to render this change. Nonetheless, older versions of WordPerfect (still using the same file-format) will leave the task to realize this fact to the formater/layout engine itself.

A direct result of the typewriter conceptual model in WordPerfect are those special tabs that disregard completely the tab-table and that contain themselves the information about their position and alignment (hard tabs, center on margins, flush right,...). A reader that did not yet get lost in this entry will appreciate how nice it is to translate these beasts into a file-format in which all tab properties are defined in a tab-table that has to be known at latest at the moment of beginning of the paragraph.

ODT/HTML

These file-formats have the particularity that the information about an element is enclosed in the element's opening tag. The alignment, indentation or spacing of a given paragraph is known at the begining of the paragraph, better said at the moment of the paragraph opening. This is the same with the tab-table for those file-formats where it makes sense (a tab-table has no sense in the html file-format although some extensions are trying to implement it in some way).

Document conversion

Given the fact that a word processing document is read sequentially, the conversion between these different formats can be quite a pain in some posteriour place of one's body. For instance, if you want to convert directly from a MS Office file-format to HTML/ODT, you will have to parse the document two times: first to collect the styles of the nodes (that become manifest at the end of the corresponding node) and second to parse the content of the nodes. For a proper conversion of WordPerfect "special" tabs and headers/footers, one has to proceed in a similar way, besided a deep magic to incorporate the "special" tabs' position and alignment into a tab-table of the given paragraph.

New OpenOffice Writer filter API

As I already mentined, the direct conversion is likely to be a pain in some posteriour place, unless...

...an import filter does not need to do the whole conversion and can feed the information into a structure where one can modify the properties of a given paragraph/section/text-run aka text-span during the content parsing. And this is exactly what the new filter API that is being implemented in the writerfilter2 CWS is designed for. Stay tuned for some more exciting adventures concerning the file-formats!

Just to add that the libwpd API gives the "node" properties in the openFoo callbacks. And it is more or less trivial to plug this logic into the new Writer API logic. Because it is much easier to have some information early and keep it for later on then the opposite case.

Work @ Novell

2007-03-02T11:42:00.000+01:00

I am owing thanks to the Lord God Almighty for being merciful and gracious with me. He extended his hand over me and my family and accompanied us through the desert of the year 2006. He blessed us abundantly and exceedingly above all we could ever hope for. I am writing this because I want to give all the honour and all the glory to The One Who deserves it in first place.

I want to thank also the Novell OpenOffice.org Team for having considered me with favour for a position of Software engineer working on interoperability issues between MS Office and OpenOffice.org. I am excited to see my hobby activity becoming my regular job. I cannot thank you enough, guys, for giving me an opportunity to work full-time on this great FOSS project.

I want to give my thanks also to other people who were ready to help me throughout 2006: Sophie Gauthier, the lead of OOo French native language project, Mathias Bauer, former framework and current sw lead (and friend), Thorsten Behrens, the gsl co-lead (and a great person and friend), Marc "uwog" Maurer and Dom Lachowitz, AbiWord admins and fine hackers (and helpful friends), and to all those people from OpenOffice.org, AbiWord and libwp* projects that were very supportive in action and in kind words: Rob, Sum1 (really SomeOne), Will, Andrew, Ariya, Pavel, Caolan, Heiner, Stefan, Eric and all those whose names I might have forgotten to put down here. Thanks, good pexcitingeople, for your willingness to put hand in fire for a TrainedMonkey and to help and encourage him. I really appreciate!

Last, but in no way least, I want to thank particulary Michael Meeks, Distinguished Engineer and "hacker extraordinaire", for injecting in me the uncurable virus of OpenOffice.org. He helped me to enter the community. Thanks, dudie, for guiding and supporting me and for being a friend inspite of my big mouth!

I am looking forward to advancing the cause of the Free Desktop inside of a company that believes and puts in practice what it preaches.

Miriam (and us) in pictures

2007-02-21T14:07:00.001+01:00

Because of high demand from the public, here you can find some photos of Miriam and associated folks.

Miriam Terezia Gladys

2007-02-14T07:28:00.000+01:00

The Lord is Good and his mercy endureth forever.

We thank the Lord God Allmighty for his goodness and abundant mercy. He blessed us in a mighty way by giving us our daughter and sister, Miriam Terezia Gladys Strba. She came to this world on 14^th of February 2007 at 4:15 AM. Both Miriam and her mother are doing great and, together with the rest of us (in the role of passive spectators), thanking God for His blessings.

Uberdedicated TrainedMonkey?

2006-12-21T16:53:00.000+01:00

For those that do not want to wait for the integration of the CWS wpsimport01, the Uberdedicated TrainedMonkey cloned the standalone writerperfect from the libwpd CVS repository and created a command-line tool alowing you to convert now your stack of MS Works documents into OpenOffice.org 1.0 file-format. The cloning was done mainly for debuging purposes, because the com.sun.star.comp.Writer.XMLImporter seems more picky than the normal document-loading process, but it is usable for converting documents too. The module is called "wps2sxw" and lives in the libwps' subversion repository.

So run there to pick it while it is hot! And do not forget to subscribe the project's mailing list and send some encouraging words to Andrew. Believe me, he does an excellent work!

One word that matters

2006-12-19T12:51:00.000+01:00

One word can change many things. And sometimes the words that one is not used to use so much might have a kind of magic in them.

Here is the problem we were facing yesterday. This piece of code was refusing to compile:

1 #include <vector> 2 template< class key , class hashImpl , class equalImpl > 3 class OMultiTypeInterfaceContainerHelperVar { 4 typedef ::std::vector< std::pair < key , void* > > InterfaceMap; 5 InterfaceMap *m_pMap; 6 inline void * find() { 7 InterfaceMap::iterator iter; 8 return NULL; 9 } 10 };

The complain was about an expected ';' before 'iter' on line 7. One can conclude by looking close that the code is correct and start to file a bug in the gcc bugzilla :-) And yet, inspite of the fact that it looks very reasonable for anybody who has a basic knowledge of C++, this code is not valid C++ and the compiler is right. For the line 7 to compile correctly, InterfaceMap::iterator has to be a type. But the compiler cannot be 100% sure about this at the moment when it is compiling the template class. It will know more at the moment of the instantiation of the template, but not before. There is still a tiny little probability that there will be a specialization for a certain class key where the InterfaceMap::iterator will not be a type. Because the compiler is not 100% sure that the InterfaceMap::iterator is a type, it assumes that it is not.

But now what? How can one make the compiler accept the code? Simply, by telling it that the InterfaceMap::iterator is a type. Here it is where a word that is not so often used (In fact, your servant never had to use it for the while) becomes handy. If you precede the statement at the line 7 by the keyword typename, everything compiles without a quirk. The presence of this keyword takes the compiler out of the uncertainty and, with its mind settled, it accepts the code.

So, the rule of the thumb is to precede the use of the dependent nested types in templates always by the magic word typename.

Having said this, I am quite happy that the long winter evenings spent with Scott Meyers were not amiss.

Microsoft Works import filter for OpenOffice.org

2006-12-18T16:05:00.000+01:00

Some sweating was necessary but the result is worth it. To avoid that OpenOffice.org be too far behind AbiWord your servant came today with a Microsoft Works import filter for OpenOffice.org based on libwps library that has been blogged about last week. I would even gladly provide screenshots, but the CWS wpsimport01, where the new filter lives, is based on milestone m196 that has some serious antialiasing issues on X11 platforms and thus the pictures would be just not nice at all. Nevertheless, it will be resynced several times as one writes the specifications, so stay tuned for the screenshots.

The integration strategy would be following: first integrate the CWS fs08 that fixes some memory problems and crasher issues with the WordPerfect import filter. Make, in the same CWS, build the writerperfect module with as little warnings as it is humanly possible and refactor it to make it much easier for other libraries reusing libwpd's public API to be plugged into it. After that, if a release of libwps happens and if inclusion of the tarball passes through all the necessary paperwork, integrate the CWS wpsimport01.

As a bottom-line, the refactoring in fs08 should make a possible shift to the use of the new filter API, that Henning blogged about, almost transparent.

So, now it is the time to study the new API in writerfilter2 and see whether the libwpd-family libraries can use it directly, or some modifications should be proposed

On clean reusable interfaces and the pleasure to see things happen

2006-12-13T12:14:00.000+01:00

As Dom wrote it already, if you are having your documents mainly in MS Works format (yes, it is normally what comes often pre-installed on a new purchased computer along with some version of Windows) you are not excluded from the free desktop any more.

Focus on libwps, a Microsoft Works file word processor format import filter library

There is a nice neat tiny library, libwps, that allows you to read those documents and convert them to other formats. A plug-in for HEAD version of AbiWord exists and its integration into OpenOffice.org should not take a lot of (coding, the QA and paperwork is other beast) time.

The library (not yet released, but ready to be soon) deserves to have some spot-lights on it. Not only it fills a gap in file-format coverage by FOSS word processing applications, it's author Andrew Ziem is an example of a hacker that your servant likes and gets encouraged by. Being one of the great applicants for Google Summer of Code with OpenOffice.org, his proposal was finally refused. It was a close call and the refusal was only due to the ridiculous number of 6 slots allocated for 69 eligible applications and 20 mentors standing on starting blocks. Many other would get discouraged and abandon the idea of contribution to the FOSS. Not Andrew! This great hacker started to code for his pleasure and libwps is the wonderful result of his work. Your servant has had the privilege to be assisting to the birth of the project and feels lucky.

The number of reinvented wheels should be (almost) zero

For a FOSS project, the beginning is often important. The hacking has to be fun and the results have to come in a tangible manner quite quickly. Otherwise, one is more likely to reallocate one's free time for other activities and the nascent FOSS project experiences a cot-death. On the other hand, to get a library design right can be quite difficult especially if one does it for the first time.

The design choice of libwps was the right one: take and reuse the interface and design of a tried and true library used by ALL free and open-source word processing applications, the libwpd. This allowed to avoid several possible iterations of bad designed interface and focus on the MS Works files conversion itself. A nice side effect of this choice is also that was super-simple to integrate a filter based on libwps into AbiWord and it will not be much more difficult to integrate it into OpenOffice.org or kWord as well. Well, from the design point of view, that is.

Clean and reusable interface design

That this was possible is a deliberate choice of libwpd maintainers. The thanks go especially to Marc “uwog” Maurer and William Lachance for the original design. The idea would be to extract the reusable interfaces from libwpd itself and provide it as a framework for developing import (and possibly export) filters from (to) binary file-formats at least. The libwps experience shows that it is possible. The advantage of the interface is that is does NOT expose STL types to user, so it is usable for applications that use different STL implementations with different signatures from the STL implementation used by the underlying system. As it is the case of OpenOffice.org that uses STLport internally. A library developed using this interface would be usable both as internal or system library for the given application. So, filter developers of all countries, unite!

Benefits of getting lost

2006-12-07T13:34:00.000+01:00

I do not know whether it happened to you to get lost only to discover a new exciting landscape of your town, parts that you have never entered before. And so, in spite of the fact that you wasted some time, you feel lucky.

A document crashing OpenOffice.org

This is exactly what happened to me last week. Everything started with the issue 71487. OpenOffice.org was crashing with the document, but the internal libwpd's wpd2raw tool was spitting out a document that was well formed. AbiWord was opening the document without shouting loud, so the quick conclusion was that the culprit would be the writerperfect code. Writerperfect is the the base of a nice tool, wpd2sxw, that uses libwpd to read a WordPerfect document and produces a SXW. The core code of writerperfect is used also in KWord's and OpenOffice.org Writer's import filters.

Nevertheless, writerperfect produced with this document a nice well formed flat XML in SXW file-format. Since the generated flat XMLs never really validated against the OpenOffice.org 1.0 DTD, the well formed-test is so far the only tool that we are able to use to track regressions.

Valgrinding writerperfect

The things started to be a little bit more tough. Gdb was giving a partially corrupted trace and the resulting crash was outside the writerperfect code. So, in a desperate attempt to get the issue fixed, I tried to use valgrind and check whether writerperfect does not have somewhere a jump or a branch dependent on an uninitialized variable. I run all documents of our regression suite through valgrind and realized that writerperfect had a lot a lot a lot of memory problems. It took me whole weekend and more to remove all the memory leaks (partially destroyed objects due to non-virtual destructor in base classes, a container of pointers going out of scope,...). This work lead to the inclusion of writerperfect valgrind test in our regression test-suite and in removal of all detected memory problems.

Problems with SXW generation on x86_64

After all this cleanup work, I tried to load the document again. And OpenOffice.org crashed again exactly like the past times. Moreover, on my home machine that runs Ubuntu Edgy amd64, the command-line tool wpd2sxw produced a clean XML in SXW format on standard output, but the content.xml in the zip file contained some garbage characters. On other machine, running Ubuntu Edgy i386, the garbage was not there.

The amazing permissivity of the WordPerfect file-format

A bit disgusted, I asked Mathias Bauer whether he cannot see anything. He took the document and confirmed that the trace (the part I could not see because of the corruption) originates from the WordPerfect importer. So, the last desperate move was to boot the Windows partition and examine the document in WordPerfect itself. I know, would be maybe the first step, but given that I have only one Windows partition and that one is on my wife's laptop... Side-by-side examination of the original document opened in WordPerfect and the converted document opened in AbiWord showed that it was true that AbiWord opened the document, but it did import only half of it. So, the time came to have some nice eye-to-eye session with ghex2. The close examination of the document using hexadecimal viewer showed that the document contains a footnote that itself contains 3 footnotes. WordPerfect reacts to such cases by ignoring completely the nested footnotes, but it leaves the functions in the stream unchanged. I am always puzzled seeing the way WordPerfect preserves user's errors for future generations. So the solution was simply to instruct libwpd to ignore foot/endnotes if it is already parsing a foot/endnote. Simple fix of some lines and the document loads correctly in OpenOffice.org, AbiWord and KWord.

gsf_output_printf and long strings on x86_64

wpd2sxw command-line tool uses libgsf abstraction for writing different streams into the the SXW zip-file. So, after having audited our code thoroughly and not finding anything that could be wrong, my attention turned to libgsf, more exactly to the gsf_output_printf function. I discovered that this function uses among others g_vsnprintf call. Knowing the woes that one can have due to different implementations of vsnprintf out there, I replaced the gsf_output_printf calls by gsf_output_puts calls and...

... the resulting SXW loaded into the OpenOffice.org without any problem. Instead of bugging Jody who should have by now enough of me for some weeks (so much I tried to suck knowledge out of his brain in my H.Opeless phase), I spoke to Dom Lachowicz about the problem and, eventually, Morten fixed it in libgsf CVS. It turned out to be the same problem that affected about a year ago the GsfOutputMemory.

Positive externalities of being lost

It is true that the real fix for issue 71487 did not take more than few lines of code, but the fact of being lost and H.Opeless for some time had nice positive externalities. Thanks to this situation, it came to my mind to start to valgrind the writerperfect code (it was not on my todo list, at this time at least) and the memory problems got solved. A bug in libgsf code was triggered and fixed.

And so, in spite of the fact that I lost quite a lot of time with this, I feel lucky when I look at the positive externalities.

On specifications, flame-wars and community building

2006-11-01T14:15:00.000+01:00

I am not really a big fan of lengthy flame-wars in mailing lists, but I have to recognize that sometimes they can be really having a positive effect in making things move. This conviction was born in me quite recently after I followed the "Specification Process" mega-thread on dev@openoffice.org. This thread was born out of a (quite legitimate, I must say) complaint about one community contribution to OpenOffice.org, then it went into some kind of criticism/defence of the current specification process and now it is heading to the core of all problems - developer community building. And that is exactly the issue that I would like to give some thoughts about in this blog.

The question is how!

The first thing that one should realize is that the question is not now whether we should or not build a developer community. The current state of 93% of all contributions done by Sun is not an optimal state and does not profit anybody. If this figure does not change in favour of community contribution, quite frankly, the fact to open-source the whole monster will mean a net loss for Sun. Since it is most likely that the 7% of community contributions simply create more than that amount of overhead in the work amount of Sun engineers/QA/UserEx/administration. So, what is the solution? Close it again and release time to time a free (as beer) version of StarOffice? I do not think so! The only option that is having any sense is to build the developer community beyond the critical mass that brings a net win. Only then we can profit fully from the advantages of open-source model.

Hunting without target?

Almost everybody will agree that it is quite unlikely (although statistically possible) to kill a rabbit, a deer or a pheasant by shooting into a forest and hoping that the target will find the bullet. It is somehow similar with community building. We have to be proactive in this task. Determine what can attract developers and do exactly that; determine what can hinder community participation and try to eliminate it as much as it is reasonably possible.

I pointed out some of the issues in my OOoCon2006 talk in Lyon. Quite frankly, I do not really believe that giving ODF talks in different conferences (although important from the marketing point of view) will bring any developer community to life. It is still in the line of what I would call marketing of the product as opposed to the marketing of the project. Maybe it is a time to have a developer speak to potential developers. Being able to understand one's target audience is not only an advantage, but a vital necessity for this task.

Waste their time, lose them

The miracle about the FOSS contributors is that they are really ready to spend their time giving out free work as long as they see that they make a difference and they satisfy their thirst of intellectual challenges. But if these intellectual challenges are hindered by a big stone laid on their chest, they are likely to go somewhere else where they will have more impact and feel more like they matter. Yes, it will require some extra work to lower the barriers for external contributors, but the discounted benefit for sure overweights the cost.

A frustrated employee might voice her frustration but will eventually STFU because her family needs the money. A frustrated FOSS contributor will voice her frustration (if the project is lucky) and eventually exit. Because the time spent fighting with the dragon means less time spent with those whom she loves and who love her. It is as simple as that.

Agile, XP vs. "Big Design Up Front"?

It has to be encoded somewhere in the human genes that when something is not giving optimal solution, a complete negation of that approach is considered as the miraculous way out. This specification discussion shows is also in a clear way. I do not really think that the two approaches are mutually exclusive and fundamentally incompatible. The truth is somewhere in the middle. A project of the size of the OpenOffice.org cannot live without any up front design. On the other hand, transposing Hamburg workflow into a normative specification process looks kind of sick too. Nobody ever can defend an idea that saving 10 minutes of his time is worth adding hours to the time wasted by others. Maybe it is now the time to gather all stakeholders and sit together as community and come up with a process that is satisfying all parts. If we are more inspired by agile principles (I speak about principles, not rules and fit-all methods), the overall quality of the product will benefit and - it is very likely, that in middle term - the developers, QA and UserEx will be less overworked too.

Open XML

2006-10-23T14:04:00.000+02:00

Erwin, it does not necessarily have to be a big problem for OpenOffice.org or other FOSS wordprocessing/spreadsheet/presentation software to support the Open XML document format. I do not say, it will be trivial (over 4000 pages of specifications is quite a long reading for sure), but the fact that M'soft is dumping into the format their internal data representation means that one would not start from scratch implementing it. The binary MS Office formats -- that FOSS applications support quite well -- are also in a big extent the dump of the Office's internal data representation and it is quite unlikely that M'soft is undertaking any significant rewriting of the MS Office's internals.

So, IMHO, the solution is to fight successfully the temptation that people have to speak without thinking about XSLT when they hear about XML to XML conversion, to look beyond the container at the content and realize that the code in the WW8 filters might be to a big extent reusable for supporting the Open XML .docx file-format at least.

Cleaning up my mess

2006-10-09T11:35:00.000+02:00

When I was a child, my mother would really try to teach me to clean up my mess before I leave a place. Not saying that she managed to train me to do it always, but I try to do the things right and, surprisingly, sometimes I even manage. So, here are the things that I really did not want to leave unfinished:

WordPerfect Graphics Import filter

That is the Google Summer of Code project that I mentored. Our contract with Ariya was that he does the hard part of implementing the library that actually reads the WPG files and converts them and that I will get all the glory by wrapping it into an import filter for OpenOffice.org.

The glory was quite costly though. Quite a hacking during the OOoCon2006 in Lyon to extract from the command-line wpg2odg the converter itself and make it produce SAX messages instead of directly writing an XML in odg format.

For those that followed my presentation in Lyon, and thus they know that there was still a little hick in the filter at that time, this is the explanation: If you have an XML based filter in OOo that produces SAX messages in OpenDocument format, the service that should receive the messages should be com.sun.star.comp.<Application>.XMLOasisImporter, where Application can be Writer, Draw,... If you try to push those messages into com.sun.star.comp.<Application>.XMLImporter, designed to receive SAX messages in OpenOffice.org 1.x file-format, it will not shout loudly, but the resulting document will be empty. I know, I should have been aware of it, but as a TrainedMonkey^TM, I am designed to have some error rate in my functioning :-)

For those that want to try it, you can fetch modules libwpg and wpg2odg from the libwpg CVS repository. Build the libwpg and install it, then configure your OpenOffice.org SDK and build the package inside the SDK shell using the Makefile.ooo-external. Your WPGImportFilter.uno.zip package will be found in LINUX.out/bin directory (yeah, I tested it on GNU/Linux, but it should be trivial to make it work on win32 and/or Solaris too). You can just install it using the Package manager and here you go with a WPG Import and a proper type-detection as a bonus.

Inspired by kendy's post about the svg import filter that he writes, I think that eventually rewriting the importer to use the UNO Drawing API would be not a bad idea. So if someone has some idle cycles and wants to change the horse that is winning, feel free to do it :-)

libwpd 0.8.7

A big thanks to William that was so nice and did the legwork for the 0.8.7 release of libwpd. He named the release "Big Apple". Thank God, we did not release it on 10/9 and not on 9/11. Given the latent paranoia everywhere, we might have a problem and my wife could eventually discover what is on my hard-disk :-)

The big feature is that now libwpd supports all existing WordPerfect file-formats. To a certain extent, naturally. The set of converted features is bigger for those file-formats where we own the underlying implementations. Because writing file-filter only using the documentation is harder that writing it not having the docs, but having the implementation. See the difference in feature-set between the WordPerfect 4.x file-format (we do not have WP 4.2, but we have the documentation) and the WordPerfect for Mac 1.x file-format (we do not have the documentation, but we have a working copy of the application).

Writely

Last week I had a quick glance at Writely, the Google web-based text editor, that allows collaborative editing. As a filter writer and libwpd developer, I am a bit puzzled that the document upload allows only .doc, .sxw and .odt files. Given that there is a nice library for reading WordPerfect^TM documents and that this library is licensed under LGPL, it should not be really difficult to add .wpd files to supported documents. If you are interested, guys, I know someone who would be able to do it :-)

Frustrations

2006-10-04T10:28:00.000+02:00

It is some months today that I am desperately looking for a job that would allow me to feed my family and provide for them a more or less decent life. The task can make one feel frustrated until the point of asking oneself about one's own value and about the value of FOSS involvement.

One of the frustrating things is that some of the most hip companies in the market, after they screen you on the phone and/or after they make you come some hundreds of kilometres during your holiday for an interview, and after even promising you that you will have their news in some days, keep silence for sometimes as long as one year. Yes, it might be that your servant is not good at all and that the interview/telephone screen showed it clearly. The point is that the courtesy of saying: "Sorry, we chose other candidate" or "Sorry, you profile is not corresponding to our needs" would be at least a feed-back.

The impression is that my FOSS involvement is welcome and appreciated when it is a free work given (I do not say I did not do it gladly and that it did not bring me joy at certain point of time), but as soon as I put a price-tag on my competences, it stops being so interesting for many. Quite frustrating discovery

OK, just trying to ventilate some of my frustrations. Sorry for eating up of your reading time.

It is finished

2006-09-20T16:03:00.000+02:00

It was really nice to be around, but the real life is stronger. TrainedMonkey^TM stops his FOSS activities. Once again, it was nice to be around and I learnt a lot.

It's a kind of magic

2006-09-17T22:25:00.000+02:00

As many of us, TrainedMonkey^TM also left Lyon and reached safely his home and rejoiced to meet again his beautiful wife and his handsome son. How long can be five days when your heart is missing someone!

As Louis rightly mentioned, each OOoCON has a special flavour. This one had a flavour of the "andouillettes" and "quenelles de poisson" ;-) For details, ask Pavel Janík!

There is nevertheless something special, I would even say something magic, about the OpenOffice.org community (and I speak with a special reference to the OpenOffice.org developer community). It disregards almost all cleavages that exist in the FOSS realm. You can see during the dinner Jody seconded by TrainedMonkey^TM discussing about the relevance of GObject framework with Éric Bischoff, a KDE developer. You can see Novell/Suse developers having nice time with the RedHat one; Ubuntu OpenOffice.org maintainer teasing (I have to confess that with a big help from your servant) the Debian maintainer. You can even find Sun developers running MS Windows on their laptops ;-) A bunch of men and women, far from petty tribal conflicts, trying to have fun hacking on a project they believe in. And this is the setting that I really love and appreciate. The only negative part is that I was not able to get the www.neooffice.org t-shirt. I do not know whether it is due to the fact that I have no car ;-)

And just to add: Charles, I may understand your disappointment with some events, but NO, I AM NOT IN WAR AGAINST ANYBODY!

Mac Mini and WP Mac file-formats

2006-08-31T17:40:00.001+02:00

Mac Mini donated by unnamed on behalf of unnamed :-)

Thank to a Mac Mini given to me for the purposes of libwpd development by a person that does not want to be mentioned, as a part of a bigger donation by a company that does not want to be mentioned either (I promised to be discrete, am I?), I was able to do some more work on the support of WordPerfect^TM for Mac file-formats inside libwpd. As from the version 0.8.6, libwpd has a support for WP Mac 2.x file-format and the CVS HEAD has an initial support for the oldest WP Mac file-format, 1.x.

Since I was looking for the specifications for these two file-formats for some time without any success, I would just want to give the information that I have:

WP Mac 2.x looks basically like the WP Mac 3.x file-format with the difference, that it does not support tables. Instead of tables, it uses parallel text columns (WP speciality?). Nevertheless, from the point of view of an import filter, this means that the code that is reading WP Mac 3.x files will work with WP Mac 2.x.
WP Mac 1.x file-format is a special one. It manifestly based on WP Dos 4.2, with some elements that one can find later in WP Mac 2.x and 3.x. Since we again do not have any documentation besides a working WordPerfect 1.0.5 (Could a company whose name starts by "M" and ends by "icrosoft" show us how functional is their word processor from 1988?), I will describe what I managed to understand from this format by reverse-engineering. Like that people who are without success looking for the specifications may find this blog and earn me some money by clicking on the adds :-)

WordPerfect for Macintosh 1.0 file-format

WP Mac 1.x is similar to WP Dos 4.2 in the fact that it has no header whatever, just a plain text with WP functions inserted. According to my observation, they are similar to the extend that a function that has certain purpose in WP 4.2, will have the same or at least very very very similar purpose in WP Mac 1.x, although the function lengths may be different between the two formats.

The block of codes between 0x80 and 0xBF are Single byte functions that are identical (at least I did not find difference until now) in the two file-formats.

The codes from 0xC0 to 0xFF (?) are codes for Multi-byte functions. They can have different sizes. A more or less accurate account of the sizes (including the opening and closing gates) can be found here and will be always updated as I am advancing in my study of the file-format. The functions where the length is mentioned as a positive number are Fixed-length functions and those ones where there is "-1" instead of the length, are Variable-length functions. It is in both subgroups of the Multi-byte functions that the difference between the WP Dos 4.2 and WP Mac 1.x file-formats exists.

One of the differences is that where WP Dos 4.2 measures the margins, positions and other lengths in “text columns” (8-bit value), WP Mac 1.x uses points as 16-bit (unsigned?) big-endian ordered number (72 points = 1 inch). This is contributing to the difference concerning the length of Fixed-length functions between the two formats.

As for the Variable length functions, the difference between WP Dos 4.2 and WP Mac 1.x is big. In the WP 4.2 file-format, to know the length of the function one needed to scan for the closing gate, WP Mac 1.x gives the size of the data as a 32-bit big-endian ordered unsigned number just after the opening gate and just before the closing gate. It means that the function length is this number plus the 10 bytes that correspond to its double occurrence as well as to the opening and closing gate. Those that are used to work with Corel documentation will find this maybe more clear:

<function code> ... 1 byte {size of data} ... 32-bit big-endian ordered unsigned integer <data> x size of data {size of data} <function code>

When reverse-engineering the function codes, it is wise to be inspired by both WP Dos 4.2 and WP Mac 3.x file formats. Certain functions follow very closely the WP Dos 4.2 specifications (with above mentioned differences in the length and position information), certain functions follow the WP Mac 3.x logic (like the Tab Set is containing condensed tab tables that follow the logic of WP3 Set Tabs function).

Help me!

I also met quite a big problem concerning the font information. The file-format is storing the font information in 16-bit number, that was identified by hub as corresponding to Macintosh fontID. According to a newer Apple documentation and also according to a sound mind (no more appropriate link here :-) ), identifying fonts by fontID is broken by design. Nevertheless, on the way towards the world domination of libwpd, it would be an error not to try to convert the font information at least. If someone of you knows about a way to get unambiguously the font name from fontID (libwpd is being used on many platforms, so the presence of Apple API is not to be assumed), I will not refuse such information. OTOH, a table mapping 0xFFFF+1 numbers to strings would bloat a bit the libwpd. But, if there is a way to place the fontIDs into groups and map the groups each one to one font that is representative of the group, it shouldn't be so difficult to convince me to try to implement it :-)

World domination under way

Having said this, it looks like libwpd 0.8.7 (whenever we release it) will probably support to a certain extent ALL WordPerfect^TM file-formats on this planet. Did WP Dos 1.x ever exist?

IZbot

2006-08-31T10:42:00.000+02:00

A cool new feature is now available at #openoffice.org@irc.freenode.net (Yes, Marc, that is where all the hip children hang :-P):

If in a conversation a string "issue <number>" or "#i<number>" or "<URL of an issue>" appear, IZbot, a dedicated bot, completes the information with the URL, number of the issue, its nature and subject line (whichever was missing in the conversation). This is saving time looking up the IssueZilla while discussing about issues. Whoever implemented it, big thank you!

Update: The thanks go to Christian Lohmaier, aka cloph. Danke!!!

Upcomming libwpd-0.8.6 - more robust than ever

2006-07-11T11:29:00.000+02:00

Your servant was working last two-three weeks together with AbiWord's QA expert sum1 extensively on improving libwpd stability. Here are the result of the work (comparison between libwpd-0.8.5 and upcomming libwpd-0.8.6)

                   libwpd 0.8.5                libwpd 0.8.6

Total tested:      46675                       46675
Unsupported:         122 ( 0.26%)                 15 ( 0.03%)
                   -----                       -----
Actually tested:   46553 (99.74% import rate)  46660 (99.97% import rate)

Parse exceptions:    660                           0
File exceptions:     555                           8
Unknown errors:        5                           0
Crashes:              13                           0
                   -----                       -----
Total failures:     1233 (2.65% failure rate)      8 (0.02% failure rate)

From the 15 unrecognised documents, some are not WordPerfect documents at all, some are corrupted to the extend that they contain only 4 or 8 bytes which is too little even for a very intelligent corruption repair utility. Some are corrupted WP 4.2 documents that we cannot repair because of reasons shown below.

The 8 documents that fail to be converted are mainly WP 6 documents with corrupted prefix area.

The improvement are due to:

Handling of impossible situations that are indeed possible with Corel WordPerfect file format, like tables with unequal number of cells in each row. Now we are completing this kind of tables to produce a valid output. Before, we would throw ParseException in such a case.
Trying to handle situation of any missing data due to corruption (i.e. prefix packet containing footnote missing, but still referenced by the text body)
A new corruption repair mechanism that manages to detect corrupted areas in document body, skip the inconsistent information and restart the normal document parsing after the corrupted area. Empirical tests showed that libwpd containing this heuristics will be able to open correctly some corrupted documents that make WordPerfect itself crash. Comparison between corrupted documents opened directly by libwpd and corrupted documents repaired by wplook.exe, a corruption repair utility from WordPerfect SDK, show that libwpd's corruption repair heuristics can add some garbage characters at the corrupted place (due to the way it operates), but does not recover less information than wplook.exe. The only document format that we are not repairing for now is the WP 4.2 file format. This format does not have anyheader or magic value to detect it as such. It is simply a plain text document that has WordPerfect functions embedded. The type detection for this file format is done by dry-run parsing of the document and determining whether it is a well-formed WP 4.2 document. Adding our corruption removal heuristic in this case would mean that virtually any document on the earth would be detected as a WP 4.2 document and this is not really the result we want to achieve.

The thanks goes to sum1 who was able to collect from the web more than 46k of real-life WordPerfect documents and ran the test loop over and over again for each of my commits. This is showing how important is a dedicated, non-bureaucratic, responsive QA for the quality of an FOSS project.

We can now proudly say to the users that if they fail to open their corrupted WordPerfect document with WordPerfect itself, it is not necessarily lost. They can try to open it with one of the fine free and open source wordprocessing software, AbiWord, Kword or OpenOffice.org Writer, and statistically they will be able to recover their information.

Subliminal message: What would be the score of the proprietary, binary, stale and unmaintained WordPerfect import filters distributed with StarOffice8?

Stress-testing

2006-06-28T15:09:00.000+02:00

Several times since last year I heard a complain about the lack or insufficience of QA in small FOSS projects. Judge yourself the example of libwpd.

Recently we had a crasher regression discovered just some days after a release and your servant was not happy at all about it. To prevent this kind of situation to arrise again, I approached sum1 of AbiWord fame and he agreed to QA the cvs head tree after a major commit and before a release. Here is his methodology:

First, he crawls the web and, using a nice firefox add-on called DownThemAll!, he downloads all WordPerfect documents he finds.
Like that, he created himself a stock of about 40k real life documents in different WordPerfect formats. He throws 10k - 15k of these documents on wpd2raw, a nice small utility that is distributed a s part of libwpd-tools package and is used by libwpd developers in their regression test suite. This QA run takes about an hour.
The documents that crash the tool and/or throw an exception are filed as bugs in AbiWord bugzilla, so that they can be dealt with.

A simple plan that has a lot of benefits. First of all, the library is stress-tested against a considerable quantity of real-life documents, so that the developers can deal with any crasher situation found. Second, this QA testing helps to find quite complicated documents in rare WordPerfect formats and renders much easier to add new features in the list of converted features; especially where the documentation is a bit fuzzy or unavailable. Third, the documents that produced crashes that were really hard to fix / not trivial to see take place in the above-mentioned regression test suite so that they do not bite anymore.

Just a little question: How much stress-tested are the proprietary, binary, stale and unmaintained WordPerfect filters distributed with StarOffice 8?

The change is urgent

2006-06-23T16:21:00.000+02:00

It is now urgent to find a new job. If you are interested in hiring me, check my resume.

Thanks in advance

Kind request towards libwpd packagers/maintainers

2006-06-11T11:57:00.000+02:00

Hello, one of the best QA guys in the known universe, Sum1 of AbiWord fame, run a lot of WP documents through the wpd2raw 0.8.5 and discovered a libwpd crash in WP5 parser in a very rare situation (if the font descriptor packet is there, but not the font list packet). Although it is really rare case, the problem exists and this patch is solving it. I would kindly ask the libwpd packagers to reissue for their distribution a new package containing this patch.

This means that I will try to push the 0.8.6 sometimes in the beginning of July just after I stuff a little bit more the WP42 parser. My apology for this regression.

libwpd 0.8.5 "reward for your patience" in the wild

2006-06-01T15:28:00.000+02:00

It has been almost 6 months without a libwpd release. So, after you waited for it patiently, the libwpd developer community has the pleasure to announce you that libwpd 0.8.5, "reward for your patience", has been released today (1^st June 2006) just to throw some shadow on the rather insignificant event of Ubuntu Dapper release.

So, what has been done:

We added some new items in the list of converted features for WP5 and WP3 formats. Font information (face, size, colour), headers/footers and footnotes/endnotes for WP5 and headers/footers for WP3 file-format.

We fixed some bugs (from which one crasher) and annoyances.
We are now having the page/section/paragraph margins right even in multicolumn sections, which allows us to know which absolute position corresponds to which column and to count the relative position from the begining of the column. This is also allowing us to count correctly tabulator positions in multicolumn sections.
We are now preventing -- inside the document body -- negative paragraph margins that were resulting from page margin change in the middle of a page which removes the ugly text border lines running across the text in some WP documents opened inside OpenOffice.org. Although, it is still possible to craft a document the way that there will be negative margins --in header and footer --, it is very unlikely to find something like this in the real life.
We are avoiding closing page spans and/or sections inside a paragraph which used to add paragraph breaks where they were not supposed to be. We defer now the page span change to the end of the paragraph.
We added to the wpd2text tool an option switch "--info"; if called with this switch, wpd2text will not convert the document in plain text, but dump the document meta-data instead. This feature could be used in a beagle WPD indexer if designed as a wrapper of wpd2text.

Future plans:

A fine hacker known from several FOSS projects, Ariya Hidayat, is sponsored by Google to work on the wpg2odg converter. Which means that the conversion of images in WP documents is not an abstract issue anymore. Welcome to Ariya and thank you to Google.
As for me, I would like to implement tabulators in WP3 and WP5 file formats for 0.8.6 as well as to try to bring all the formats to the same level of features converted. Which means add multicolumn sections for WP5 and list styles for both WP3 and WP5. In the same time, I would like to stuff a little bit the WP42 parser.
One of my other objectives would be to motivate someone with a copy of WP 5.x to do the QA of changes in this file-format. I would like to thank in the same token Smokey Ardisson for his great QA work of WP3 changes. Without Smokey it would not be possible to arrive so far in the WP3 support. Thanks, Smokey, for being my eyes :-)

Bottom-line: With this changes, the libwpd based filter is more powerfull than the proprietary WP filters shipped with StarOffice 8. A time to get rid of stale, unmaintained, proprietary binaries, isn't it?

Some precisions

2006-05-23T21:25:00.000+02:00

/me is amused to see different conjectures concerning the WordPerfect^TM Graphics documents importer. It is true that the base of this importer will be code that was written mainly by your servant for the libwpg project. I do not see any reason why not to use what was already done and extend it instead of trying to reinvent the wheel. The result will be a library reading images in WPG1 and WPG2 format and a filter built on the top of this library with an API that will be easily used for writing either a command line converter or a filter based on XFilter framework. Exactly like our writerperfect module is an importer built on the top of libwpd.

The resulting library may be used afterwards by other projects, like Inkscape or Karbon14, since the library's API will be following close the SVG properties of different objects. /me is looking forward to mentoring the student who is quite experienced in writing import/export filters for a big FOSS project.

GO STUDENTS GO STUDENTS GO !!!

2006-05-04T09:47:00.000+02:00

I am writing this blog to attract your attention to a great SoC2006 project. I encourage students to apply for it. Reasons: great and highly motivated mentor, great task, great mentoring organization, success and prosperity almost assured.

But seriously, it is a nice starting point for a wannabe OpenOffice.org contributor. So, go students go students go!

Writerperfect and KWord - reusing of code with many benefits!

2006-04-26T13:32:00.000+02:00

Writerperfect is the import filter for WordPerfect^TM Documents inside OpenOffice.org 2.x. It uses a library, libwpd, to read WordPerfect^TM Documents and converts libwpd's output to SAX messages in OpenOffice.org 1.0 Text File format (designed originally as an add-on for OpenOffice.org 1.1 and not needing any of the advanced features of OpenDocument format, the sxw output remained and works well in OpenOffice.org 2.x too).

Written principally by William Lachance (big thanks, Will), Writerperfect has an intelligent design that is not limiting it to a specific document handler. This allows us to use Writerperfect as a base of wpd2sxw command-line conversion tool, of the import filter integrated inside OpenOffice.org 2.x, of an import filter add-on for OpenOffice.org 1.1.x, and, soon, of a WordPerfect^TM import filter for KWord, the word-processing component of KDE office suite, KOffice.

In fact, your servant and Ariya Hidayat of KDE fame have been working last weeks on an integration of Writerperfect with KWord. KOffice has a nice feature that allows different filters to be chained.

Since the version 1.4.0, as all major FOSS word processors, KWord is using, the libwpd library as a base of it's import filter for WordPerfect^TM Documents. Since the use of libwpd was something new for KOffice, the existing import filter is a bit rudimentary. Reusing of Writerperfect's code allows the import filter to benefit almost instantly from all features converted by libwpd modulo those that KWord's sxw importer does not support. Along the way, as we already found bugs in the sxw importer, it benefits also from the change. And, last but not least, Writerperfect itself is likely to become more robust too.

Kendy, would you ever believe that your servant would be contributing to KDE? :-)

WordPerfect Graphics conversion WANTS YOU!

2006-04-18T12:01:00.000+02:00

I heard many times a complain about how difficult it is to join the OpenOffice.org project as a developer. Although giving credit to some of these voices, I would like attract your attention to a simple way to do some development for OpenOffice.org without having to be familiar with UNO or any other of the strange OpenOffice.org concepts. At http://sourceforge.net/projects/libwpg there is an interesting project trying to write a library for reading (and converting) WordPerfect Graphics (WPG) files. It is a nice little project written in C++ that is somehow stale now because those who contribute to it are busy with other things (like, for instance, the WordPerfect Document import).

What should be done?

IMHO, there are some things that can be interesting for someone that is beginning. In no particular order:

iostreams - Since the WPG files are not embedded in an OLE stream, it is not necessary to use libgsf for input and output stream layer abstraction. In order to reduce the list of dependencies of the library, porting the input/output operations to C++ standard library classes would be a good thing. Moreover, it could be a good starting point to understanding how the library works without needing to have an in-depth knowledge of the WPG file format.
Add conversion of bitmap parts of WPG1 files.
Add conversion of WPG2 files supporting single and double precision.
Write a small command-line tool that would use this library to convert graphics into OpenDocument Drawing file format.

What already exists?

The vector parts of WPG1 files are quite correctly converted although some attributes may be omitted. There is a command line tool called wpg2svg that can be used to convert and visualize the vector graphics from WPG files in SVG format.
If you are interested, just grab the cvs module "libwpg" and start hacking. Send your patches to libwpg-devel@lists.sourceforge.net. Your work will be most appreciated.

What is the benefit for me when doing it?

"I do not have silver or gold, but what I have I will give it to you ..." Again in no particular order:

You will be my personal hero :-)
You will learn a lot about how to design and optimize a library that will be possibly used by many applications.
You will have the opportunity to collaborate in integrating this library into Openoffice.org. You will become in fact an Openoffice.org developper. This will give you the possibility to work with people like Caolán McNamara, Michael Meeks, Pavel Janík or Jens-Heiner Rechtien ;-)

So, come! The success, glory and prosperity are waiting for you!

Back again

2006-04-03T14:44:00.000+02:00

Long time since I blogged the last time! No valid excuses coming to my mind, so not giving any.

SF.net vs. Colab.net - close call

Every time I find a bit of time, I am trying to advance in the field of converting headers and footers in older WordPerfect formats (WP 5.x for Unix/DOS/Windows and WP 3.0 - 3.5e for Mac). A nice bunch of code is sitting in my computer. The only problem is that I cannot commit it since the SF.net project CVS services are off-line (partial outrage) since Wednesday. Although the match SF.net vs. Colab.net was starting clearly bad for the later, it becomes a close call now.

WordPerfect for Mac 3.5 extended file-format

It is starting to be a bit problematic to convert documents that I am not able to see with the original application. For simple features it was OK. For headers and footers, one has to go through about 2 A4 sheets of hexadecimal garbage for every meaningful paragraph. It was really a genial idea to incorporate all formatting information into the document stream. It makes WordPerfect to be quick to render the document, but a programmer with ghex2 trying to convert it has a hard task.

mdbdriver02

Thanks to Hanno Meyer-Thurow of Gentoo phame and his skills with gdb, the M$ Access driver in mdbdriver02 CWS is not crashing any more with the Northwind.mdb Orders table. Nevertheless, there is still a bit of work to be done before it is ready for the spotlights. But, we are advancing.

Code review

It is something that is missing in OpenOffice.org, but it could really improve the quality of the code. (IMHO of a trained monkey, naturally.) I am excited about the fact that Frank Schönheit is wanting to review the code of the mdbdriver02 CWS.

libwpd-0.8.4 and others

2005-12-08T14:37:00.000+01:00

It has been a long time since I last time blogged. It is a moment to reverse the tendency.

libwpd-0.8.4

libwpd 0.8.4 has been released. This version contains fixes for building with gcc-4.1.x and for building on MacOSX. It adds conversion of tables in WP5.x file-format. The main changes are in the conversion of documents in format WP3.x for MacIntosh - conversion of tables including the colour of the cell background; conversion of font face, font size and font colour information; conversion of sections with multiple columns; and conversion of footnotes and endnotes. Being a bugfix release, libwpd 0.8.4 is binary compatible with all previous versions of 0.8.x series.

Those that build with system libwpd are encouraged to grab the tarball as soon as they can; the others will have to wait for the integration of CWS fs05.

fs03 is dead!

After months of hesitation, I decided that the solution of unicode control codes is not really a good solution for my existential problem from some time ago. The documents converted with a fs03 enabled OpenOffice.org would look horrible in any earlier version.

This means that a proper solution with visual to logical reordering would be the only good solution. Nevertheless, this is not as simple as that for different reasons:

The reverse BiDi algorithm is not defined as part of the standard. ICU implements it although it gives warnings about the actual results in the API documentation. Fribidi does not even try to implement it. If you ask the developers about their plans to do so, they will answer you that the best approximation of visual-to-logical is the logical-to-visual itself.
OpenOffice.org uses ICU while AbiWord uses Fribidi. It means that one will have to abstract the reordering inside libwpd and leave the respective applications to provide the corresponding implementations. This solution would require an ABI change and will not be considered untill such a change does not become an unavoidable necessity for several other reasons. So, for the while, the Hebrew and Arabic text will be in wrong order in converted WordPerfect^tm documents. Sorry...

mdbdriver02

I managed to resync the CWS mdbdriver02 with SRC680_m143. Thanks to Heiner for a prompt solution of my cwsresync problem. About 10 minutes after I told him about the problem, it was solved and included in CWS hr23. I call this quick and responsive action. Thanks, Heiner once again!

I created a mdbtools tarball that contains only the LGPL-ed code. I will have to come with a patch that they could commit upstream (if they decide to answer) and that would implement --without-utils in the same way they already implement --without-gmdb2. This solution would just allow us to eliminate the GPL-ed code using simple configure options as oposed to a patched configure.in.

The integration of mdbdriver02 is on a good path. Only that I have to write the specifications. It is not really a hard thing to do, but there are so many more exciting things to do in one's life.

2005-10-25

2005-10-25T09:36:00.000+02:00

The 2004 was basically about it. We thought about it, we read books in order to be prepared for it, we planned it, we were dreaming about it and even breathing with it. It was supposed to be ready sometimes in the middle of November, but the codebase became so mature that a release on 25 October 2004 imposed itself naturally. Since then we are spending almost all of our time maintaining it. We learned a lot about it and from it. It brought us a lot of new knowledge and even some new friends. It has become the main topic of our conversations. During the year, the length of code almost doubled and the resulting package is about three times the initial volume. Even though it was released under strictly proprietary terms, we love it and it brought us a lot of joy. It is highly unlikely that we will license it ever to anybody under any condition. What is it so precious?

His name is Patrick Štrba and he is the God-given son of ours. We thank God for his first year of life and pray that He protects him in the mighty way He has been doing until now.

Happy birthday, sweetheart

Děkuji, Jane!

2005-09-10T10:01:00.000+02:00

I just realized after having read my last blog entry once again that I missed out something important. More than 50% of the patches in CWS morejava are from kendy. So I take this occasion to say simply a thank you. Děkuji, Jane!

Miscellaneous

2005-09-02T17:38:00.000+02:00

libwpd

So, after about two months, we released a new version of libwpd (0.8.3). There are some nice changes that allow libwpd to convert the text formating in a more faithful way than before. It also helped to clean a bit the libwpd internals which can be quite an advantage for future development. Those who build with system libwpd are encouraged to upgrade and profit immediately. Those who use the internal libwpd have to wait untill the CWS fs04 is integrated.

more java

On another note, if you have problem building OpenOffice.org with certain version of Java^TM, please consider checking whether CWS morejava is not solving your problem. With this CWS integrated, I have built SRC680_m125 using jdk 1.3.1 to 1.5.0. Many thanks to Cyrille Moureaux and others who gave hands with this work.

chose promise chose due

In CWS mdbdriver02, we were introducing a new module in the external project. Pavel asked me to blog about the procedure and I kind of promissed it. Chose promise, chose due! So, I am doing it now.

First of all, the alias has to be created. The best way is to ask the maintainer of the external project, unless you want to know the CollabNet procedures out of curiosity. But, even then, it is good idea to have his green light.
Once the alias is created, there will be no tag on this module. So you will have to work on HEAD and mention in the comments of your CWS that it introduces a new module.
When the alias is created, there will not be necessarily the directory corresponding to your module in the external project's CVS. You will have to create one and here is the difficulty:

If you checkout from the CVS the "external" module (cvs co external), you will get actually the "util/external", the directory "external" from util project's CVS. If you create a new directory, it will be committed into the util project that you do not really want.
In order to check out the "right" "external", you must checkout one of the directories of external project whose name is not identical to a directory in "util/external". For instance, "cvs co external/libwpd". You will have to position yourselves besides the libwpd subdirectory (in this case) in external directory, create a new directory and commit it using cvsadd. After that, you can checkout your module and work on it as usual, still remembering that you are working on HEAD.

Ok, I do not know whether it was clear enough, but if you meet the problem, you will understand it for sure.

ooocon2005

I am looking forward to see you people there. I also hope to find there a short moment to hack a little bit more the libwpd.

Artmedia Petrzalka 5 - Celtic Glasgow 0 (in words: ZERO)

2005-07-28T11:58:00.000+02:00

Pleased to see that a club of Bratislava's suburb has won the Scottish football giant in such a wonderful way.

Holiday

2005-07-08T17:42:00.000+02:00

Out for 2 week. Long deserved holiday in my town of birth and childhood.

Left-to-Right Override

2005-07-01T12:55:00.000+02:00

My existential problem is almost solved. The solution is quite simple: to prepend every span with Left-to-Right Override (LRO; U+202d) code.

Yes, I said almost, because #i51400 is blocking #i51402.

That is why I did not include this issue into cws fs02, but created a separate cws fs03.

libwpd-0.8.2

2005-06-23T00:01:00.000+02:00

Just to tell the world that libwpd-0.8.2 was released today.

This release is the "bestest" ever since libwpd-0.8.1 and features mainly a huge improvement of WP5 extended characters handling. Nevertheless some other bugs were fixed in this release too. For more details, consult the release notes.

Those that build OpenOffice.org with system libwpd are kindly encouraged to upgrade, those that use internal libwpd will have to wait for the integration of CWS fs01.

N.B.: I am nowadays editing my blogs in pure html directly without using any kind of GUI help. It is my prayer and hope that this time I will not break Planet Go-OOo.

How to switch off the automatic bidirectional support ?!

2005-06-18T09:59:00.000+02:00

WordPerfect is not really a BiDi wordprocessor. At least the versions released in Europe and America. If you want to include an Arabic or Hebrew text, you have to enter it litterally backwards, so that it shows correctly.

Once the WordPerfect document converted by libwpd, the characters from the special Hebrew and Arabic character sets become normal UTF-8 encoded characters. Some logic inside OOo detects that the characters are from unicode range that normally belongs to RTL languages and renders them right-to-left by default. This means that all Arabic and Hebrew text that shows correctly in WordPerfect is reversed in OOo.

I would not mind to have someone with clue explain me how to force OOo to render ALL characters left-to-right, independently from the unicode range they belong to.

Thanks, Smokey!

2005-06-18T09:52:00.000+02:00

Thank to Smokey Ardisson of NeoOffice/J fame, libwpd is now converting Arabic characters inside WordPerfect documents.

After a bit of additional polishing of the conversion of other charsets, this improvement (and many others) is likely to land in the SRC680 tree in time for the 2.0 release.

Evolution on Windows

2005-06-09T13:01:00.000+02:00

It is nice to see that tml managed to make run evolution on Windows. It means that besides a fine opensource office suite, there will soon be a fine opensource groupware client for Windows. All this without a need to put on glows :-)

Blog Entry No 1.

2005-06-07T08:10:00.000+02:00

I was wanting to start my blog some time ago, but between the decision and the achievement is always a big gap :-) Nevertheless, it is here.

Since some time, I have been hacking on enhancing the mapping of WordPerfect character sets to unicode inside libwpd. Not really very exciting job, but quite necessary since libwpd is used by OpenOffice.org 2.0 and any problem will be seen by a huge amount of people.

After that, I will continue in some of my libwpd refactoring. Again, basically not really exciting work, but I do not see how to implement the funny WP tabs (flush right, hard tabs, etc.) without proper implementation of paragraph boundaries.

That's all folks!