The Wayback Machine - https://web.archive.org/web/20170629063837/http://www.advogato.org/person/wlach/diary.html?start=43

Older blog entries for wlach (starting at number 43)

24 Dec 2005 (updated 24 Dec 2005 at 08:27 UTC) »
Burgundavia: Fooling people into believing something that just isn't true doesn't seem right to me. I dunno, maybe this whole "OpenDocument" hoopla is a useful fiction and hyperbole: after all, it seems to provide an opening for getting OpenOffice (or GNOME Office, or KOffice, whatever) into places where it wouldn't be able to otherwise. But if winning's the important thing (and I'm with robsta that it might not be), I'd rather it be for the right reasons.

For some more context, see my earlier entries on the topic.

apenwarr: A bit late replying to this one (blame you-know-what), but for what it's worth, the article you cite in your recent post deals with something pretty different from what you were talking about. In philosophical circles, idealism generally means taking "ideas" as being prior to external reality in some way (by stating that they exist independant of it, or that external reality is an idea, or somesuch variation).

This is, of course, different from the colloquial understanding of "idealism", which generally implies a focus on "how things ought to be" rather than "how they actually are".

robsta: My point was that in order to share your documents seamlessly with other people, you really need to standardize on the same creation tool. My experience has been that people using these things tend to tear their hair out over even minor losses in formatting that come from converting between document formats (image positioning, section handling, font faces, what have you).

Of course, the ideal would be that people would just produce the content of documents along with some semantic markup, and their document viewer would produce something aesthetically pleasing based on a style sheet of the user's preference. For that, a document format like XHTML is more than sufficient. And on the surface, one might think it would solve 80% of use cases (I mean, aren't people just writing documents to be read?).

Much to my despair however, people's behaviour (and feature requests) says otherwise. The model of Microsoft Office has made everyone into an amateur desktop publicist: a control freak who wants absolute control of the details of formatting. They want their TPS reports to be exactly one page, have two columns (3.53 inches apart), and an image exactly 1.62 inches from the top, center-right. And dammit, anyone viewing or editing that TPS report should see the exact same thing. Anything else would be unprofessional. (Sigh)

And so we seem to be stuck with large unwieldly document formats like OpenDocument (and RTF, and MsWord, and WordPerfect). To change this, we need something that can capture people's imaginations the same way that fiddling with margins and image positions does.. and I'm not quite sure what it is yet (if I did, I'd probably be working on it!).

robsta: While that article is quite silly, I don't think XHTML makes any more sense as a common interchange format. When it comes to sharing documents, the ideal is to lose as little formatting as possible as the document is passed around, viewed, and modified. For the average office worker, trained in WIMP document production applications, I think the following is the current set of best practices:

If you only want other people to be able to read your document, PDF is the most sensible option: it more or less guarantees a perfect reproduction of your document's formatting without placing a burden on the reader to use the software you used to create it. If you want other people to be able to edit your document, it only makes sense for you to come to a common agreement as to which editor you want to use (GNOME Office, OpenOffice, Microsoft Office, whatever). If you don't, formatting information will (almost always) be lost and people will be annoyed.

Unless and until XHTML supports a strict superset of the formatting options of all word processing applications out there (which seems rather unlikely), I don't see it having a large tangible effect. Actually, the only thing that I see changing the above set of recommendations is the outright displacement of office software (in the mold of Microsoft Office) from the software landscape.

28 Sep 2005 (updated 28 Sep 2005 at 05:49 UTC) »
Argument parsing libraries, continued

Results from my informal poll:

1. haruspex recommended using getopt. Yes, there is a Microsoft-friendly version of this routine (they actually recommend using it in lieu of argp in one of their lame Unix->Win32 porting guides).. but it really only provides a small subset of the functionality of argp / popt (e.g.: you can't use it to automagically generate help messages).

2. Jim Morrison (ex-Nitiite and free software hacker extraordinaire) pointed out that argp was, in fact, not part of glibc. It's part of a stand-alone library called gnulib. The idea here is to provide a set of tiny standalone routines that you can compile into your own program and library as needed. This sounded promising, so I played with it a little bit this evening.

Sigh. Their version of argp depends on something like 10 other gnulib modules, few of which compile out of the box on Windows (they expect a certain amount of unixism in your environment). End result is that I'd need to hack this up quite a bit-- and I'm not sure if the end result would be much better than including popt in the WvStreams distribution. The gains of a cleaner API and a "guaranteed" future seem rather marginal compared to the extra effort involved in making this thing work properly (not to mention the bloat of a huge number of otherwise unnecessary functions). If it compiled out of the box, it would be a different story.

(yes, it would be a worthwhile project to do a full port of gnulib to MSVC.. but that's frankly not a project I'm particularly interested in).

3. Fridrich Strba pointed out that Tor Lilqvist has put up a Win32-friendly version of popt here. I'm not sure how comfortable I am on relying on this as an external dependancy. Only libgnome uses it, and I understand that will be going away in the near future.

My conclusion is that statically including popt is probably the best option (which isn't really that horrible at the end of the day). I sure hope this pedantry was useful to someone.

Cryptic insights

apenwarr: You might want to go into more detail, since I doubt the average advogatan has much insight into NITI's internal development processes. :) The difference between specification and design wouldn't have been obvious to me a few years ago.

Modularity

bwh: That's a very interesting, under-engineered approach to interoperability (I mean that in a good way).

The fact that it worked out so well for you likely has much to do with the fact that SVG has become such an ubiquitous format for vector graphics. To contrast, there is no real "hub" format for word processors so you really do need to write implementation-specific importers/exporters to get the best results. Maybe OpenDocument will change this, but I'm skeptical.

libwpd's "translation format" is actually a superset of what OpenOffice and Abiword provide. It has a richer model for lists than AbiWord and expresses more semantic content for page spans than OpenOffice.

23 Sep 2005 (updated 23 Sep 2005 at 07:03 UTC) »
Return

Decided to continue using this account for random technical entries (gotta cater to an audience which cares, and all that). The techblogging muse doesn't strike me that often, so still no promises on frequency of updates..

Option-parsing libraries

WvStreams has recently acquired an argument processing class. This really makes life much easier when writing daemons and other tiny network utilities: not having to write tons of boilerplate code for parsing command line options and printing out help/usage messages is a godsend. Unfortunately, the backend library that this class uses (popt) has a number of problems, namely:

  1. It's not actively maintained in standalone form (you need to download rpm to build it these days).
  2. It's not buildable using MSVC++ as is.

As an interim solution, I patched the hell out of it to get it compiling under Windows and decided to live with it for the time being (most Linux distributions come with an obsolete version that's good enough for our purposes on that platform).

But really, that's a non-optimal approach over the long term. So I went searching for an alternative. In my travels, I found two widely-distributed libraries which seem to offer comparable functionality: argp (part of glibc) and GOption (of GNOME fame). Both have fatal disadvantages: argp does not exist as a standalone library (hence there is no easy path to distributing it in a form buildable by MSVC++) and GOption is tightly coupled to glib (which is difficult to justify depending on for such a small task).

So I'm pretty much at wits end, except for the slim hope that there might be some viable alternative that I've missed. Does anyone know of a C library for argument processing library which meets the following criteria:

  1. Actively maintained
  2. Buildable under both win32 (Microsoft VC++) and Unix
  3. Free of external dependancies
  4. Has a sane license (LGPL or BSD)

.. 'cause the alternatives (including a patched copy of popt with WvStreams or writing a new library from scratch) are looking like a whole lot more work than directly reusing something that already exists.

My journal has mostly moved here. I may still pop up on Advogato occassionally to comment on other people's postings..

Uraeus: I think a good part of TransGaming's success has to be due to the "I'm at a LAN party, and I want to run StarCraft RIGHT NOW" factor.

At least, such was my motivation for forking over $15 last night (SC didn't work right away with normal Wine and I really wasn't in the mood for tweaking). Seems to have been a pretty good investment so far. It is indeed a shame that they had to fork Wine, but is understandable given financial pressures these days. Proprietary Cedega is better than no Cedega.

5 Mar 2005 (updated 5 Mar 2005 at 19:39 UTC) »

WriterPerfect (a WordPerfect filter for OpenOffice, based on libwpd 0.8.0) has finally been merged into the OOo 2.0 release branch. I guess that makes it something like two and a half years since I made the original announcement that I had developed this functionality. Many people deserve credit for this milestone (myself included), but I would like to personally thank Fridrich Strba for ironing out the many final details and doing the legwork of merging the CWS (child workspace: think inverted branch) into the main tree. In production software, the devil is always in the details, and I don't think we would have gotten to this level of quality and integration without Fridrich's persistence.

Overall, I'm feeling pretty conflicted about OpenOffice these days. On the one hand, it's pretty exciting to see your work have such a big impact: I have no doubt that tens of thousands of people have used our WP filter by now. On the other, the amount of work that was required to integrate such a simple feature is really rather depressing. In my analysis, it's pretty much impossible to meaningfully contribute to OpenOffice without dedicating huge amounts of time to the task (e.g.: 20 hours a week or more). The codebase is so large and its idioms so non-standard (CWS, UNO, dmake, ..) that anything less just isn't going to cut it.

I have every intention of continuing to help maintain libwpd, but I have decided that any other future work on office suites is going to be devoted to Abiword and Gnome Office, where I actually stand a chance of making a constructive difference without throwing away all my free time.

4 Mar 2005 (updated 4 Mar 2005 at 16:55 UTC) »

With the exception of the first day (where I was lying sick in a bed in my hotel), had a most enjoyable week in Europe.

Fosdem was quite good, albeit a little hectic at times. Managed to meet a whole bunch of new people, and learn a little bit about a few projects which I was curious about (OpenGroupWare, Snort, Plan9) and a few which I hadn't heard of before (ProGraph, FAI, Gamin, Linux-HA, jamvm..). Thanks to everyone (especially the conference organizers) for being so friendly and generous, as always.

It would have been a bit crazy to go all the way across the Atlantic for a conference like this (not being a speaker and not having a stake in any of the showcased projects), so I planned to spend a few days travelling afterwards. In the end, I settled on visiting Bruges and Paris (these choices were mostly the result of me acting on capricious intuition), which turned out to be quite rewarding. :-)

23 Feb 2005 (updated 23 Feb 2005 at 06:47 UTC) »

So it appears that I will be going to Fosdem this year, with some time booked to travel a bit afterwards. This was a rather snap, spur-of-the-moment kind of trip, so we'll see how it works out. Hope to meet lots of interesting people and find out about what they're working on..

pcolijn: I noticed the same niggles wrt Hula (which I set up the day it came out), although I kind of brushed them off under the assumption that the current web-interface was still more or less in the prototype stage.

I was impressed with its speed and ease of build/installation, both of which seem to be extreme rareties in the "enterprise class" software world. Then again, neither of these really mean all that much if Hula doesn't provide what people need/want. Will be interesting to see how this one develops over the next few months..

34 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!