Older blog entries for raph (starting at number 399)

Advogato spam

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.

More thoughts on GUI tools

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.

Still under water

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?

On coming up for air

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.

Almost ready to emerge from my cocoon

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.

Maybe I'll see you there!

Update

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.

Checking in

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.

The weather is absolutely beautiful here, and I feel pretty good.

Thesis work

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?

Just testing

Not sure what happened to the recent diaries. I tweaked the db by hand and hopefully it will work now.

More later.

Grayscale bitmap fonts

Hand-drawn grayscale fonts have been an interesting idea for some time, but have never really caught on. They certainly take a lot more skill and patience to do well than ordinary bitmap fonts.

That said, I think they can fill an interesting niche in the 100-130 dpi resolution range, which is of course where the vast majority of all users live today. At lower resolutions (in particular 72dpi, which was standard for a long time), the grayscaling is quite visible, which can be distracting. At much higher resolutions (say, 200dpi), hand-tuning is a waste of time because outline fonts can deliver somewhere around 95% of the optimal contrast levels even without sophisticated hinting techniques.

And, indeed, grayscale bitmap fonts are starting to come into existence. Check out this thread on typophiles about Firefox text rendering, and this one about monospaced fonts for programming. Also see the bitmap critique forum for some striking examples of grayscale (and monochrome bitmap) work.

Can we use grayscale bitmap fonts on our free software platforms? In theory, we should be able to, because Freetype2 supports the grayscale bdf format, as I was able to verify with the ftview demo program and a hacked-up font. However, if I put that bdf file in /usr/local/share/fonts (with a corresponding <dir> tag in .fonts.conf), then "xterm -fa Graytest" bombs quickly with a floating point exception. I don't really feel like debugging that right now.

So, I want to know a few things. Is it possible, by hook or by crook, to get fontconfig-enabled apps to load grayscale bitmap fonts out of the box? If there are stupid bugs keeping that from happening, how do we get those fixed?

I sense there is something of a chicken-and-egg problem here. If there are no good grayscale bitmap fonts out there, then there isn't a strong motivation to build support into infrastructure and apps. Conversely, if it's nearly impossible to deliver grayscale fonts, why spend the time drawing them?

But it may well be the case that the energy barrier is not that high, and that with a little directed force, we can break through it. Does the community have the collective will to make this happen, or is this just yet another of my crazy ideas that nobody cares enough to do anything about?

390 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!