For one, SIL has released version 1.0 of their Open Font License, and promises to be releasing Gentium under its terms shortly. The fact that SIL is getting aware of free software licensing is very encouraging, as it promises to make their efforts considerably more relevant.

Even so, I'm not convinced that the OFL will have that great an impact. Earlier drafts tried to ban selling collections of fonts with OFL fonts included, but apparently that ran afoul of DFSG-style freedom. Now, apparently, it allows selling of collections, but not of the individual font. Was anybody actually selling free fonts individually before? Even if not, the adoption of the OFL may send a signal that the font is to be treated with more respect. As Wes Felter says, it's much like wearing a designer t-shirt. It will be interesting to see how aggressively the "free font" ripoff artists prey on Gentium - if they do back away, it might be an appealing example to follow.

I'm tracking this because I've got a few fonts in the queue that I'd like to release under some kind of free license, but am still unclear exactly what license is best. I've been in touch with Karl Berry having TUG sponsor completion of one or more of the fonts, and the choice of license is still an open issue.

Font fans might be interested in taking a look at my latest font-in-progress, Inconsolata, a monospace design. I'm hopeful that it will turn out to be one of the best available for code listings, etc., in print.

Japan

The trip to Japan was really fun. On the last evening, I had a very nice dinner with Masatake Yamato and Akira Tagoh, both now of Red Hat Japan. We talked of many things, including areas where recent AFPL releases of Ghostscript may break some of the work done by the gs-cjk team to make substitution of Japanese fonts work correctly.

We also talked about free software tools for Japanese learners, and input methods for Emacs in particular. I've been using Quail, mostly because it was easy to find since it's included in Emacs distros, but apparently SKK is better.

One question I have about Quail: is there a way to go in the reverse direction: if I have a kanji in the buffer, can I make it tell me the key sequence required to produce that?

I'm posting this from the Manboo comic library and Internet Cafe in Tokyo. It's probably the most uniquely Japanese experience I've had here. After all, cities are cities, and most name brands are global. Given a choice, I'd probably rather go to Fry's than the famed Akihabara district. But this is a concept that would probably only work in Japan, and definitely not in the States.

Basically, the deal is that you pay around $3/hr, which gets you a private cubicle with your own computer, TV, and PS2. Not only that, but you get free run of an impressive library of manga comics, free drinks, clean bathrooms, and a handful of similar perks.

Now, keep in mind, by Tokyo standards, that's an incredible deal. This glass of iced tea cost the company something around $8 at the Tokyo Hilton, a ten minute walk or so away. Refills not included.

The main reason it wouldn't work in the states, I think, is that people just wouldn't respect the space. They'd be stealing all the books and equipment (there's a decent pair of headphones hanging on the wall, no bizarre incompatible connector or other "security" mechanism to keep it there), defacing things for the hell of it, pissing in the cubicles, shooting up (although, truth be told, there rather is a distinctly herbal aroma to the cigarette smoke in here).

Meetings

We had three meetings with three Japanese companies. Two went very well, one was near-disastrous. (I won't name the companies out of discretion)

Doing business with Japanese companies is very difficult for Westerners. There's all of this culture, and what would be a straightforward comparison demo of technical skill can be interpreted as an insult to the engineering capabilities of the host. People talk about "honne" and "tatemae" in terms of great mystery, as if it's impossible for Westerners to grasp, but it's not really that hard.

Take for example, when, at the really fancy Japanese dinner we were treated to at a restaurant in Matsumoto city on Friday, they offered a shabu-shabu of the male reproductive organs of some big fish, nobody was sure exactly what kind. Everybody's looking at me to see what my reaction will be.

So here's honne: "bleaghh, this thing tastes weird, and the texture is even weirder. I'll be lucky if I can get it down."

And, in contrast, tatemae: "Thank you for offering this experience. It is a very interesting flavor!"

Note that both are, in fact, true. I'm going to get a lot of mileage out of this story, much more so than if we had just had nice steaks or what have you. But the Japanese make the distinction explicitly, and pretty much expect it in daily relations. In a way, that's actually more honest than the American way, which is to pretend that it's all honne all the time, but we do it too. (lots of other gaijin have written about this topic - this one is one of the better explanations. And, of course, for insight into how dysfunctional Japanese culture is from the perspective of an American teaching English in the schools, nothing beats Azrael's blog)

Gadgets

I spent some time walking through Akihabara and just letting the gadget-ness wash over me. In some ways, the technological progress is awesome, but in other ways I'm beginning to wonder if the engine may be slowing down.

On the plus side, digital cameras have finally really arrived. I picked up a Panasonic FX-9 (6MP compact) and am absolutely thrilled with it. Good pictures (I've linked one or two from this entry), cool funky features such as the ability to take movies, and even a rotation sensor. (neither iphoto nor yahoo photo knows how to interpret the tag yet, but I'm sure that will happen soon). It's got a 1GB flash card that looks to me just like a 3.5" floppy scaled down to an inch. I remember my first hard drive, it was 20MB and occupied a 5.25" form factor.

But on the other hand, I sense the magic has gone out of it. Sure, the pace will advance. We'll be able to stick more and more songs up our ass. But a lot of the stuff, computers in particular, lacks much in the way of fresh and new. The majority of laptops here still have 1.2GHz Pentium M chips, although of course 2GHz is still available on the high end. Displays are pretty much the same as a few years ago, just a bit brighter, higher contrast, and faster.

I was also looking for a pocket electronic Japanese/English dictionary, but didn't find a model that really appealed to me. They've got relatively pixelly monochrome LCD displays, cost around $300 for a good model with the kanji dictionary and so on, and none of them have features designed to make life easy for a Westerner trying to learn Japanese (an untapped market, perhaps?) It seems to me you'd be far better off with a Nokia 770 and some dictionary software (perhaps even wiktionary-based, which seems to be gaining momentum).

Windows Media Photo

Windows Media Photo is part of the upcoming XPS format from Microsoft. From what I understand, it basically has the advantages of JPEG2000, but without the problem of people other than Microsoft owning patents on it. We may be starting a crash project soon to implement it from scratch. It's too early to tell whether it's going to be kosher to do a true free software release, but we're in contact with the right folks at Microsoft and are pushing on them. Anyone you know have an interest in image codecs, a taste for implementing specs, and a need for some extra walking-around money?

Misc

Now that I have a digital camera, I'm missing more than ever the ability to insert inline images, so I'll want to add that.

I'm also missing the ability for people to write direct followup comments, so much so that I considered writing this as an article. Hopefully now that the trips have wound down, I'll have some time for that. Hmm, where have I heard that before?

iagorubio: sorry about that. My acm account got thoroughly deluged by spam, so I let it lapse. I've updated my contact information, so hopefully it will be easier for people to get in touch with me now.

mathrick recently pointed out that some people are trying to abuse Advogato by posting spam, and suggested that I delete or disable the idiot's account.

Of course, I'll do that if it turns out to be a real problem, but in the meantime it's a pretty good test of Advogato's trust metrics, especially the newer one for comment rating. Because of the size-0 profile bug, it wasn't being recomputed in timely fashion, but it's back online now. And, happily, the offending page has a rating of "1" so it's suppressed altogether from the recentlog view linked from the front page (assuming you're logged in).

There are some improvements I really want to make to the rating mechanism, and may be able to get to them sooner rather than later. For one, I want the un-logged-in view to have some reasonable default (maybe mine :) for the trust metric seed, rather than showing the results unfiltered. I also want to do a dynamic trimming thing, so that lower-ranked blog entries get trimmed more aggressively than higher-ranked. Same thing for <img> tags, which are sadly missing from Advo blogs.

The Advogato trust metrics really do work. I must really suck at self-promotion, because it seems the rest of the world doesn't seem to notice or care. Ah well.

Resolution-independent UI

One of the features intended for MacOS 10.4 (Tiger) was resolution-independence in the UI. What actually shipped is pretty much a baby step in that direction, as opposed to something really usable.

Overall, it looks pretty much like what I proposed a year and a half ago. What I called the "pppx ratio" (pixels per px unit) is called the "scaling factor", and is accessible as the userSpaceScaleFactor method in Cocoa, or HIWindowGetScaleMode() in Carbon. Handling of legacy apps is also very much as I propsed. I wrote last April: "If the app is not LQ-aware, then as it asks for a display surface, the OS knows to give it one with 100 dpi "pixels", so that each pixel that the app draws shows up on the hardware as a 2x2 square of pixels". This is implemented in Tiger as Magnified Mode. A Carbon app signals its "LQ-awareness" by setting the kWindowFrameworkScaledAttribute flag at window creation time.

Even so, the results, as shipped on 10.4, aren't that good. Mortal users don't have any way of setting pppx, but developers can just open -a "Quartz Debug", then press apple-U to bring up a slider. I noticed that most apps shipping with the OS have "framework scaling" set, as opposed to just drawing in Magnified Mode, but many have artifacts. A few set the window height (but oddly enough, not the width) based on pixel, rather than px, units, so the window is chopped off at the bottom when the scaling mode is greater than 1. Quite a few (Safari especially) generally work, but have artifacts. A few seem to work well right out of the box (I didn't do a careful study, but Cocoa seemed to predominate here).

Text and vector graphics scale well, but bitmaps don't. And, indeed, all the Aqua UI elements are drawn as pppx=1 bitmaps, then scaled, so things don't look all that sharp. Similarly for web pages shown in Safari - all the bitmap graphics look really fuzzy in comparison to the text. I've said this before and will say it again: the Web desperately needs good standards for providing images at resolutions greater than 96 dpi. I say "desperately" because it needs them today to provide quality printing, but of course once the problem is solved it will work just as well for LQ displays as well.

One interesting note: when pppx=1, the display dpi is nominally 72 dpi, which was true of the original 9" Mac back in 1984. Yet, today, nearly all machines Apple ships have 100 dpi LCD screens. Setting pppx automatically by dividing the actual display resolution (queryable through a protocol spoken along the video cable) by 72 will typically result in a setting 33% too large. One solution is to make sure it always gets set manually (as I wrote a year ago, "The pppx ratio should be a global configuration parameter.") Another is to fudge the calculation. I guess we'll have to wait until 10.5 to see how Apple finally deals with all the usability issues.

Japan

I'm flying to Japan again from Nov 5-Nov 16. I'll have the last few days more or less free, so that would be a good time to meet up with Advogatans in Japan. Let me know (through my gmail address) if you're going to be around then.

I got some good replies to my last post. Unfortunately, the somewhat archaic software hosting this site doesn't have any way of tracking replies and responses, so for the most part I have to work from memory. I think I need to give the author of the software a kick in the pants...

The answer to the question "what is the best approach to writing GUI apps?" depends a lot on a few basic assumptions. I didn't state those at all clearly in my last post, so I'll try to do that now.

The first big question is whether you're trying for something adequate and usable, or for a world-class app that is in no important ways inferior to professional apps designed natively for the platform. This question is especially important when trying to target multiple platforms from the same codebase.

There are lots of good approaches to "adequate" apps, including the venerable Tk (especially with the Tile improvements), wx, qt, or either of the two viable Java toolkits. But it is difficult or impossible to achieve the fit and polish of a real native app. Examples:

Seamless integration with the platform's input methods for non-English text.

Screen reading and other accessibility items.

On Mac, having the dock work as expected (drop items to it, badging).

Cut and paste with rich content.

It's not just about being able to draw widgets that look just like native; that's important, but the tip of the iceberg.

If my goal was an "adequate" app, the generic cross-platform frameworks would be appealing. But for the moment, that's not mostly what I'm thinking about.

Another very important axis is the choice of programming language for the app. If your language rocks at strings but sucks at everything else (like Tcl), then obviously having the GUI toolkit treat everything as strings is a good thing (hence Tk). But if your language has really good dynamic dispatch for objects (like Objective-C), then you clearly want your UI events to map directly to object methods, rather than having to filter through big switch statements on split strings. What you really want is Cocoa (or maybe GnuStep).

And for me, the valid assumption is that I'm writing primarily in C, but am also very interested in prototyping in Python. Unfortunately, C is neither really good at dealing with strings (you have to do handstands to get the memory management right) or objects. Other things, like exceptions, are also painful. So the constraints of trying for a reasonably good API for C is likely to warp the design to be not very good in other languages.

So I don't hold out all that much hope for the convergence of GUI toolkits, at least any time soon. Different frameworks for different goals.

A funny, well-written review

Tor found this. It made me laugh hard enough not to be considered appropriate in the presence of royalty.

Wow, it's a long time between entries. The main problem has been an incredibly busy travel schedule - almost immediately after returning from the Netherlands trip, I'm on the east coast for a day for a potential customer visit, then tor arrives this evening, then next week is our staff meeting, then maybe there's a followup trip to Japan in early November (for which I want to see if I can hook up with some Advogatans in Japan if possible).

But life goes on anyway. I'm getting some pretty darn good looking color laser output from the Konica Minolta 5430 driver. I'll have all the goodies checked into CVS soon, and hopefully there will be some people in free software land who will want to play with it.

Also, you might notice that the certifications and diary ratings are working again. With some help from pphaneuf, I tracked the problem down to some zero-length profile.xml files in the database, which happened when casper's disk became full (a consequence of having spam^H^H^H^Hmail delivered to the same partition as Advo's db, a bad idea), then some of the virgule code segfaulted on the NULL pointers that were coming back. I'm hoping to get some time to add some new features, maybe by integrating StevenRainwater's code.

I'm also continuing to hack a bit on Ghilbert, and have also been participating in some of the discussion on AsteroidMeta. Ghilbert is still very much a stealth project, but I'm feeling closer to opening up browsing and posting on the web site. At some point, I'll need to decide between adapting existing wiki/web board software or crafting my own.

Cross-platform UI's

Another long-time fascination of mine has been tools for building cross-platform UI software. I've never been thrilled with any of the alternatives available, although of course wx comes close.

My main frustration stems from the difficulty of making really good cross-platform apps, which have a truly native look-and-feel on the three most important platforms: OSX, Windows, and X. I'm convinced that the Java philosophy of "write once, run anywhere" is wrong for desktop GUI apps. You want access to the goodies that the platform provides, and you need behavior to be different on different platforms. Writing for a lowest-common-denominator abstraction layer gets in the way. There's a tremendous amount of good knowledge encoded in the Apple Human Interface Guidelines, and I think it's far more important to design to those guidelines when running on the Mac platform than to be able to run the exact same source code on all your targets.

I've been experimenting with a somewhat different approach. You have a very thin layer on top of the native GUI toolkit, which gives a common interface to all the vanilla stuff like creating menus and buttons and so on, but ultimately you're building three different apps for the three platforms, with hopefully around 90% of the code shared. Much less than that and the duplication is onerous, and much more than that you're putting too much pressure on the abstraction layer without much benefit.

One reason, I think, for such an approach to work is that the design principles behind GUI toolkits are converging, not to mention the underlying system support. In the bad old days, a native Mac Classic, Xt, and Win 3.1 app would be very different beasts indeed. These days, you can rely on Unix-style processes and memory management. More to the point, I find Carbon HIViews and Gtk+ widgets to be strikingly similar. In both cases, you have a mainloop which uses callbacks to send events into the application, you have widgets implemented as objects-in-C, and in general what's different is details.

And I've got some specific ideas for smoothing over those differences in detail. For one, I think Tk has the right idea of using strings to communicate between the app and the UI toolkit, especially for callbacks into the app. It's really easy to deal with strings across platforms, languages, and so on, while the toolkits tend to have large, nasty, and opaque interfaces.

So far, my prototype seems to work nicely and the code is fun. Is there much interest in such a thing, or am I barking up a tree?

Just after writing my last post, a trip to Japan suddenly materialized, to pitch Ghostscript to printer companies. Between dealing with moving stuff, preparing for the trip, actually going, and then going to Quaker Yearly Meeting, I haven't had much time left over for, say, blogging.

My crazy schedule doesn't wind down for another six weeks or so (I've got trips to Chicago for Print 05, and to Holland to visit Oce, lined up), but at least I've got a little break now. Well, after Linux World, anyway! I'll be at the linuxprinting.org booth on Tuesday and Thursday. If you're in the area, it'll be a good time to touch base, see my printing work, and maybe even sneak a peek at my PhD thesis work on curves.

Ghilbert

I've been continuing to work slowly but steadily on Ghilbert. This last week, I completed the proof of findes in my portable axiomatization (the axioms used in this proof are pure predicate calculus with equality plus the Peano axioms; no sets needed as in the Metamath version).

I'm finding formal logic to be deeply satisfying, but so far am happy working on it as a personal, private project. I don't find it easy to explain to people exactly why I think Ghilbert is the right approach, but it feels more and more right the more I play with it.

The web presence is very sparse now, but as the project progresses it will become primarily Web-based, with the ability to browse and post bits of proof online. Ultimately, I think Ghilbert's potential for collaboration will be its greatest strength. An ironic goal, isn't it, for a project with such a lame web page.

Wow, it's been a long time since my last blog entry. The big news is that I now have an apartment in Berkeley. I'm still not 100% moved (there are books and so on at the old pace), but all the furniture is here, and it's already starting to feel like home.

The past couple of months have been fairly emotionally demanding, and I'm still feeling behind on a bunch of things (a lot of it mundane paperwork seemingly needed for living in modern times), but I sense this period is about to end, and I'm going to become a lot more social again. This apartment is only 4 blocks west of the North Berkeley BART station, and a nice hike to campus, so the logistics of getting together with friends is going to be a lot easier than it was way out in Benicia.

One place in particular I hope to meet up with friends is LinuxWorld in SF, the second week of August. I'll be helping Till Kamppeter man the linuxprinting booth, and will be showing off some of my work with high end graphic arts-quality printing using Ghostscript and my screening technology. I'm not expecting much from the conference itself, but it should be a reasonably good place to reconnect with friends.

Looking over my last entry, there's progress on at least one front: I have a car now, so I've finally joined the petroleum-burning bandwagon. The thesis also continues to go very well. I have working code for solving sophisticated sets of constraints (especially those needed to make smooth corners and transitions between straight and curved segments), and have been steadily refining the numerical techniques. I can barely wait to release all this stuff publicly.

The primary focus of my work lately has been screening and image science. I'm currently doing drivers for the Konica Minolta 5430 and the HP DesignJet 110, with the goal of acheiving even higher quality than the vendor-supplied drivers. All of this work will shortly get checked into AFPL Ghostscript, with the GPL release to follow not long after. I really like this kind of work, not least because of the immediacy of the results.

Metro

Microsoft has announced their Metro printer language, and their beta implementation is floating around. This probably won't make much difference in the free software community for some time, as there is precious little that Metro can do that PDF can't. However, PDF doesn't ship inside many consumer printers (and probably won't, because it demands so much RAM to run), so this might revitalize the dream of device-independent page description languages started by PostScript, but then largely abandoned by Adobe due to greediness and lack of focus (their desktop apps make real money; their printer business doesn't).

If there are other people out there in free software-land working on Metro, I'd really like to hear from you.

Firefox plugin

It's not too much of an oversimplification to say that page description languages are now used in two places: printers and the Web. Unfortunately for Adobe, they've dropped the ball on the latter as well. While the PDF file format is very nice for distributing statically formatted documents, most users hate to follow PDF links, mostly the fault of Adobe's wretched browser plugin.

So there's an opportunity to do better, and tor has been hacking on a Firefox plugin based on mupdf (soon to be renamed ghostpdf). It looks really promising.

Toys

For some reason, I find myself wanting a Nokia 770. Maybe it's just the 226 dpi screen, maybe it's that it looks really easy and pleasant to develop for. Nokia seems serious about being developer-friendly, as clearly evidenced by their no-nonsense website. If they really want to stir up some buzz, they'd seed a few dozen devices to the free software community.

The energy I have for writing in this diary ebbs and flows. The last few months, it's mostly been ebbing, which is not surprising considering the current texture of my life: too much emotional energy going into trying to get an amicable and fair divorce settlement, and wayyyyy too much time schlepping around the Bay Area on various forms of public transportation to meet with assorted counsellors, lawyers, and so on.

I expect things to improve in a good many of these areas. I plan to get a car soon, and also plan on moving to Berkeley some time around June. Overall, I'm feeling a lot better than I was, and look forward to having the energy to interact more with the free software community and others.

I know Advo's trust metric is currently broken, and will fix it when I get a little time.

My thesis is going splendidly. I understand splines far more deeply than when I started. After I publish the thesis, I will find out whether the rest of the world gives a rat's ass. Either way, I'm having serious fun working on it now.

I feel brimming over with ideas for various code projects, considerably beyond my personal ability to implement them. What should I do with all these ideas? The answers are far from clear to me, and it will probably continue to be a challenge to figure out.

My thesis work is going great, although I'm now less in the mood to write about it publicly in detail, because I might seek patent protection on some of the ideas.

For one, I've started to seriously dig into the study of real splines (i.e. thin strips of wood and the like). I just got Love's Treatise on the Mathematical Theory of Elasticity and am trying to wrap my head around the math and physics concepts contained therein. I think it's possible to do as well as, or even better than, real splines, as long as you're not afraid of using advanced math to make the numerical problems tractable.

The math involved is mostly Calculus of variations. I came across it a little when I was a taking math classes over my head as a young teenager, so it feels like nice closure to actually be using it now.

Grayscale bitmaps

The response to my query on grayscale bitmap fonts was disappointing, to say the least. Hrant Papazian is working on a series of monospace grayscale fonts called Coda. He is offering to release them for free assuming the community gets its act in gear and is actually able to use them.

Why have grayscale bitmaps utterly failed to take hold? One theory is simply that they are too hard to design, but I don't think that holds water; there is now a small community of grayscale font designers producing very impressive work. A more disturbing theory is that, failing copyright or other "intellectual property" protection, the incentive to create the fonts has been missing. It's a strange quirk of US copyright law that typeface designs and bitmap images are free of copyright, while packaging a typeface design as "font software" (presumably, executable code rather than a static data structure) confers upon it the protection given to software in general. Thus, we have something of an testbed for a public domain utopia advocated by anti-copyright extremists.

And the empirical result of that testbed are devastating. The technological limitations of the early '80s created a golden era of monochrome bitmap design (most especially the work of Susan Kare for Apple and others). But as soon as technology made scalable fonts feasible (with the corresponding upgrade in copyright protection), bitmaps were abandoned as fast as possible.

Even in the scalable domain, we still have lots of effort poured into making hinted TrueType fonts as opposed to nurturing the development of unpatented font technology. It's the triumph of GIF and MP3 over PNG and Vorbis all over again.

I think there is an optimum level of copyright-style protection to serve the public interest. The current Mickey Mouse-dominated legal environment almost certainly errs on the side of too much protection. The experience with bitmap fonts provides another datapoint on the "too little" side. Who will make the case for the baby bear?