Since my fix for blurry text in Google Chrome 37 relied on an experimental feature I didn't expect it to permanently solve the issue, but I'm still enjoying crisp browser text a few months and versions later thanks to disabling DirectWrite support. Annoyingly, one part of the original problem returned in the latest major update. I suppose this at least means the developers are working on the font rendering code.
A change in Chrome 41 causes some user interface text to be rendered (most blurrily) using DirectWrite even when this renderer is disabled through chrome://flags. The blurry text is visible on tab titles as well as in the address and bookmarks bars. This is certainly less of a usability nightmare than when all text was affected, but unnecessarily ugly and difficult to read.
There's no "Disable DirectWrite (I really mean it this time)" or similar option to be found in chrome://flags. However, some digging around will reveal another poorly documented and likely equally experimental tweak: the --disable-directwrite-for-ui command line switch. Having to disable DirectWrite twice like this seems rather arbitrary and inconsistent but it does work.
Command line options are considerably less convenient than the feature flags on Windows; modifying the default browser shell open command requires nontrivial registry wizardry. First you need to find out what your local shell URL associations are. I did this on Windows 7 by inspecting protocol keys below
These all pointed towards
ChromeHTML, which leads us to the following key:
Inserting --disable-directwrite-for-ui there and similarly updating any browser shortcuts you may have should get rid of the blurry user interface text. Until everything breaks in a future update, obviously.
17 March, 2015 | feedback (1)
Google recently released version 37 of their web browser Chrome, which delivers a number of features and bug fixes. I'm particularly happy to see that a 64-bit Chrome browser for Windows is now fully supported and considered stable. Users of both 32- and 64-bit versions on Windows may be less pleased with another feature: text rendering via DirectWrite, a DirectX API.
According to MSDN, DirectWrite is a
device-independent text layout system that improves text readability in documents and in UI. In other words, this is Microsoft's latest take on the difficult problem of rendering high-quality text on computer screens. I have yet to use this particular API (and judging from the documentation I'm not eager to try, it's a small jungle of COM interfaces) but it looks capable. If the text rendering problems in Chrome 37 is not a result of DirectWrite limitations, Google should be able to improve on the situation in a future version.
What text rendering problems, you say? Here's a screenshot of some text in the Chrome user interface using the previous (GDI) method of text rendering:
...and here's the same text with the new DirectWrite feature enabled (both images at 200% magnification to make pixel boundaries easier to see):
What's immediately obvious is that the new text engine lays out text differently: Chrome is able to fit slightly more of the DirectWrite text in the same area. The two renderers also appear to use different antialiasing methods. Neither rendering is wrong, technically speaking, but the DirectWrite version has more grey pixels and I hope you'll agree that it appears less sharp. Less edge contrast is a problem for small (body or UI) text because it is much harder to read when our eyes struggle to find character and word edges.
I suspect there are those of you out there who prefer the new, smoother text. Perhaps my severe myopia makes me more sensitive to these issues. Rendering text on low resolution displays has always been a trade-off: too much aliasing will distort glyph and word shapes, but attempting to remove aliasing through interpolation will smooth out visually important edges. We will be living with ugly compromises like this until high resolution displays becomes available. (No sign of them so far.)
If you prefer the previous text rendering method in Chrome you may still revert to it by going to chrome://flags in the browser, click Enable to disable the use of DirectWrite, and restart Chrome:
Yes, that's how the option looks when DirectWrite is disabled. I'm not sure what to say about this interface and will update if I come up with something sufficiently snarky.
27 August, 2014 | feedback (1)
I'm passionate about science fiction and I keep hoping for good science fiction movies but let's face it: Hollywood's track record is absolutely terrible. With Prometheus I was expecting a mediocre "sci-fi" movie with a shallow story and perhaps some good visual effects. Had that been the case I would not be writing these words.
I was on some level aware that the director of this movie was Ridley Scott, known for the classic science fiction and horror masterpiece Alien. The 1979 movie remains a favorite of mine. It wasn't perfect but its flaws weren't many and I can forgive a lot when the story is interesting, coherent, and convincingly conveyed.
Unfortunately, it quickly becomes obvious that Prometheus is desperately trying to be a prequel to Alien while failing to emulate any of the elements that made the original movie great. The premise is ludicrous. The characters have less depth to them than cardboard cut-outs, appear slow-witted, and keeps making irrational decisions. For two hours the implausible plot stumbles on in an anti-scientific and technophobic way with overtly religious tones to an unsatisfying end.
I'm trying very hard to come up with some redeeming quality to Prometheus and I can't find any. It is monumentally stupid on every conceivable level and an insult to all sentient creatures in the known universe. If you haven't already had the misfortune of seeing this movie, avoid it like you would an Ebola virus sprinkler.
17 November, 2012 | feedback (1)
Occasionally while messing around with a *nix system you'll find yourself with a big directory containing symbolic links, some of which are broken. A typical example would be links to shared libraries, but for me this also tends to happen fairly regularly with a collection of SSL certificates. What's a quick way to find the problematic links and remove them?
There is in fact a utility created specifically for situations such as this: symlinks. It was written by Mark Lord, who is perhaps more known for his work on the Linux kernel IDE subsystem. To recursively (-r) delete dangling (-d) links in the directory /etc/ssl/certs you would write:
symlinks -dr /etc/ssl/certs
This command can perform several other nifty symbolic link maintenance tasks, like converting absolute links to relative ones. However, when symlink is not available – and let's face it, it probably won't be installed unless the need to purge broken symbolic links comes up a lot on a given system – you can use find instead:
find -L /etc/ssl/certs -type l -delete
The way this works is somewhat unusual. The -L option causes find to follow symlinks while the -type l test matches symlinks. This combination may seem contradictory at first, but the effect is that only symbolic links find is unable to follow (i.e. dangling links) will match.
As usual with find and recursive directory processing in general, be careful. You may want to omit the -delete part until you're sure it's not recursively deleting everything in the world.
28 September, 2011 | feedback (4)
The last few years we have seen an increased proliferation of software product "editions": the same version aimed at different user segments. A somewhat recent example is the latest version of Microsoft's operating system, Windows Vista, which comes in no less than six different editions.
People often ask me what differentiates editions of particular products. I could direct them to the manufacturer's web site, which invariably offers "comparison matrices" outlining the differences, but there's really no need to do so once you understand the general pattern. The names of editions for specific products may differ, but the following should serve as a useful guide whenever you are faced with a choice of editions:
- The Home edition
- This relatively affordable edition is for people who have no idea how to use the software and have no intention of ever learning. It's functionally identical to last year's version of the product but features a colorful and horribly user-unfriendly interface with big shiny buttons to push and "wizards" that helps you do the wrong things fairly quickly.
- The Professional edition
- The Pro edition is for people that will actually use the software. It is expensive enough to make professionals and small businesses think twice before investing in it, but at least it has a semi-usable user interface and includes all features that matter. This is the edition trade magazines will review and the one always meant when a particular product is recommended.
- The Standard edition
- The edition for people who want to use the software but can't afford the Professional edition. Basically the same as the Home edition except that you can turn off some of the more obnoxious elements of the user interface, which unfortunately only serve to make its severe limitations all the more obvious. The price point is somewhere between Home and Pro.
- The Premium edition
- This edition is for people who probably should have bought the Home edition but have more money than common sense. It combines the user interface of Standard with the features of Professional and includes five additional "multimedia" applications, none of which have any practical use. This edition costs a bit more than Professional.
- The Enterprise edition
- This edition has a price tag one or two magnitudes over that of the Pro edition. It is similar to Professional but has a number of nebulous enterprise features, most notably a suite of poorly designed and buggy multi-user programs and support for machines with ridiculous amounts of RAM and CPUs. Presumably for scalability reasons, its performance while doing common tasks is considerably lower than any other edition so you really need such a machine to run it.
5 May, 2007 | feedback (1)