-
You install a shiny new GNOME desktop. You boot it for the first time, and you think the fonts are a bit too large or a bit too small for your taste. As a new user, what do you do?
- Find and launch the control center.
- Find the fonts capplet and launch it.
- Hopefully figure out that "Application font" is what you see in menus and other "normal" elements on the screen; figure out that "Desktop font" is for desktop icons only. (What is "Terminal font"? Is that the font they use on your tombstone when you die?)
- Click on one of those buttons. Pick one of the meaningless sizes: 10 units of what? 12 units of what?
This is atrociously bad.
To make it even worse, those units do not mean points at all. What does the "Size" field really mean?
For a long time now, gnome-control-center has had a GConf key, /desktop/gnome/font_rendering/dpi, whose default value is 96 dots-per-inch. This was done because many X servers are broken and don't report the physical dimensions of the screen correctly. So we added a GConf key to say, "most screens are about 96 DPI, so this is a reasonable default". Then we picked a default font size of "10". So a line of text ends up being about 10×96/72 = 13.3 pixels tall. This is a nominally good size on standard CRTs, and a nominally bit-to-small of a size for fancy laptops with high resolution displays.
So, that's what the "Size" field means: it means nothing. It is a meaningless number, which gets converted through a senseless operation into a number of pixels, which may or may not be a good size depending on which display you are on.
Of course, people have no idea about all of this. They don't know how many pixels tall their fonts should be for them to be legible comfortably. They have no idea that we are not paying attention to the real resolution of their screens (remember, we hardcode 96 DPI). They don't have the faintest clue of what the real resolution is! I mean, who cares?
When you look at a computer screen, you intuitively know whether the fonts are too small or too big for your liking. Everything else is irrelevant.
People who know a bit of typography may know a few factoids:
-
Printed books generally use fonts which can be from about 9 to about 12 points in size.
-
A point is roughly 1/72 of an inch. For people in civilized countries, this translates to "I have no idea what the fuck a quarter pounder is".
And since we GUI programmers are armchair typographers (I mean, we have to deal with baselines and ascenders and descenders and all that garbage all day long), we decided that the right and obvious way to set your font size would be a bureaucratic little process composed of bureaucratic little steps:
- What is the screen's DPI?
- What is the appropriate point size?
- What is your viewing distance to the screen?
- What is the air-speed velocity of an unladen swallow?
And our answers were these:
- Uh, we don't know. So we'll make it configurable, instead of fixing the X server to actually understand the hardware on which it is running. And since this never works anyway, we'll hardcode 96 DPI as a default.
- Uh, we don't know. Probably 10 points, since that's what books use, or something.
- Uh, we don't know. More than a centimeter, less than an astronomical unit.
- Aaaaaaaargh!
At Novell, people started filing bugs complaining that GNOME hardcodes 96 DPI for the display's resolution. "This does not let me use the full power of my hardware!", they said. So I wrote a patch that makes GNOME pay attention to the DPI value which the X server gives us. The patch does some sanity checking to deal with broken X servers: if the reported DPI is too small or too big, we fall back, again, to that beloved 96 DPI.
Sounds good? It should be good, right? Here is what happened after that.
People started installing their systems with that patch in place, and now they started complaining that their fonts are bigger than what they expected. Not too big, but bigger. What happened?
What happened is that they installed their shiny new laptops with 120 DPI displays (1400×1050 pixels on a 14" screen gives you that). Since GNOME is now paying attention to the actual DPI of the display, instad of pulling a (default) number out of its ass, people started getting fonts that are 10×120/72 = 16.6 pixels tall. And they didn't like them, since they appeared "too big" for their taste.
So, even though we pay more attention to the hardware and everything, we still suck for users.
People seem to be divided in three camps:
-
Those who think that a higher-resolution display means more visible text, and who think that that's a good thing.
-
Those who think that a higher-resolution display means the same amount of visible text as before, but with less jaggies, and who think that that's a good thing.
-
People who just don't care. They just pray that the computer will display fonts at a legible size.
The first camp is that of young, strapping hackers with pefect eyesight, and graphic design nerds who are happy to get more pixels for the thousand floating toolbars they use all day.
The second camp is that of frustrated people like myself who just can't read small fonts for too long a time.
The third camp is the majority of the population. These people are just happy that hardware prices are dropping fast.
There's a fourth camp, probably a tiny intersection of the Venn diagram of the above three — so small as to be irrelevant — who will complain: "but how about page layout programs and word processors! Don't you want to hold up a printed piece of paper to your screen and see the fonts match up exactly?" Oh, shut up. Nobody does that, because they are used to the fact that this never ever works. "Zoom to 100%" never means "I want to hold up a piece of paper to the screen", because it's always misconfigured anyway.
So, what do we programmers have to do? We have to give people an easier way to set their preferred font size, using examples instead of meaningless numbers.
Nothing more except for a typeface selector, perhaps. No DPI bullshit or meaningless units. This needs to be available as soon as a new user logs in for the first time, as well as in the control center.
Dear Lazyweb, who will write this for GNOME? :)
-
The file chooser in GTK+ 2.10.x and trunk is messed up again. I've started triaging the file chooser's bugs to see where we stand. My plan for the file chooser:
- Write tests for recurring bugs which are easy to test automatically.
- Document manual tests for recurring bugs which are not easy to test automatically.
- Fix the bugs.
- Clean up the file chooser code.
- Document the code well.
- Add urgent features like Beagle searching and integration with GtkRecent.
- Pass the maintainership to someone else.
But hey, at least the competition isn't doing any better ;)
-
Sabayon 2.17.90 "Soup for the troops"
I've just released Sabayon 2.17.90; it's available here:
http://download.gnome.org/sources/sabayon/2.17/
The release notes are in the full announcement for sabayon-2.17.90. There are many interesting bug fixes in these release, so check it out!
-
Sayamindu Dasgupta has been kicking ass in Sabayon. He recently fixed a bug about having better descriptions for changes to the Panel. This is before the patch; you can see generic changes like "Panel applet 'applet_1' added".
And this is after Sayamindu's patch, which provides better descriptions.
Sayamindu also started writing documentation: API reference for Sabayon, Python scripting with Sabayon. I'm pretty excited about this. Sysadmins hate tools that cannot be automated via scripts or whatever. They also don't have time to learn all the myriad ways in which GNOME applications can be (pre)configured. Since Sabayon is supposed to know about that myriad ways, it makes sense for Sabayon to provide scripting facilities with which you can automate administration tasks.
-
Oh, yeah, Alex has passed the Sabayon baton on to me. Mwahahahaha. If you are a sysadmin, get ready for some hot love.
-
Federico: They now make dildos from exotic hardwoods.
Oralia: I don't know what to say...
Federico: ... about tearing down the rainforest ...
Oralia: ... to stick it up your ass.
-
Both Juanjo and Jdub link to the fantastic "Study on the economic impact of open source software on innovation and the competitiveness of the Information and Communication Technologies (ICT) sector in the EU". This is an incredibly useful document!
-
Para mis colegas mexicanos: regístrense para BarCampMexico, el 17 y 18 de febrero en el D.F.
-
Slowly getting there; still not perfect...
-
This is the belly of Penélope Dorra — the spider that lives under the the shingles of our roof, just by the garage. Since she settled in our house about six months ago, she has been pretty consistent about her timing and location: most days, at dusk, she starts building her web by hanging a silk thread from the roof and then hooking it from the tip of the anthurium that lies on the floor, directly under the lamp on our front door. Today she went crazy and instead decided to span the whole garage. The circular part of the web ended up being about 60 cm in diameter.
Evidently, she was hungry. Oralia and I caught a moth that was fluttering by the lamp on our front door, and fed it to Penélope. You can see her pulling silk out of her rear and wrapping the moth. This is like wrapping a sandwich and leaving one of the sides uncovered, so that you can eat the sandwich without all the ingredients spilling out.
Things learned during this session of low-tech nocturnal macro photography:
-
Cheap digital cameras are notoriously bad at focusing in low light. So, set them to manual focus, and take a bunch of shots moving closer and farther to your subject. You'll nail one of them eventually.
-
Cameras have very coarse flash compensation. So, you can cover part of the flash with your finger. If you feel that your shots are coming one stop overexposed, cover half of the flash. Two stops overexposed, cover 3/4 of the flash, etc.
-
Since you are using flash anyway, you can set the camera to a low ISO sensitivity. This will give you less grain on the dark areas. I learned this a few shots after the first picture, which is much grainier than the second one. The flash also lets you use a small aperture, which will give you more depth of field for your small object.
-
Our spider definitely doesn't look hairy at normal viewing distance. Who knew.
-
