Older blog entries for freetype (starting at number 29)

28 Jan 2006 (updated 28 Jan 2006 at 14:49 UTC) »
Auto* wars- let's keep the flames burning :-)

cinamod, did you really mean it when you wrote that "adding two lines in my configure.ac for better win32 libtool support and add a re-implementation of mmap" is trivial ? Do you understand with how much sarcasm the usual Win32 developer is going to read this ?.

Also, I believe that you missed Raph's points regarding error messages. Did you ever tried to hack Auto* scripts seriously. These tools are so brittle that the simplest error is most of the time difficult to spot and understand from the tools' output. In my opinion, Automake holds the crown for cryptic puzzles. Some of this comes from the underlying languages being used and cannot be solved easily. Of course, when they work, these things are amazing; but maybe the fact that they're so hard to program explains why there are so many bad AC_WARN_* and AC_ERROR_* macros out-there; or that most development in these scripts is done by copy-pasting protions from other projects and crossing fingers that it does what it's expected to do.

note to rilian: unfortunately, you cannot progressively get rid of m4 in the Auto-tools, this task would be equivalent to trying to smoothly get rid of C++ in KDE, i.e. it's not going to be easy nor elegant.

Apart from that, I think we call all agree that the good thing about the Auto-tools is that they contain an enormous, though badly documented, amount of knowledge regarding various existing systems and their quircks. As a consequence, they do thing that no other system does at the moment. But the costs associated are also huge and make thing hard to use for too many people, which don't need the whole enchilada.

I hope is it possible to hope for tools that make simple things trivial, and complex one possible without a Ph.D and several dozens hours reading obscure documentation and m4 script files ? And without being the target by ad-hominen attacks too !! Oh well, life's too short I guess...

  The phrase "computer literate user" really means the person
  has been hurt so many times that the scar tissue is thick enough
-- Alan Cooper, The Inmates are Running the Asylum
Life's fun

How about a fridge with integrated beer dispenser !!

fridge with integrated beer dispenser !!.

This is not a fake, you can buy this from several stores !!
I bet someone must have a patent on this thing :-)

rilian, I think you under-estimate the things Autoconf is used for. There are many basic things that simply can't be done easily with only Make and pkg-config. raph's comments were spot on, and I'd like to add that there are some alternatives to the madness that might be worth a look at:

  • iffe
    created by some mad scientists at AT&T, this open-source script is capable of performing feature detections in a way that is much more simpler than Autoconf could ever dream of. A really good document about it is there, and you can also read its man page here.

    The IFFE interpreter itself is nothing more than a portable shell script known to work on all flavors of Unix. You can put it in your CVS because it will never change. You don't need to touch it at all because it will read small "probe" files containing instructions regarding the features you want to test. The output is trivial to include in a Make-based build system, and can work with pkg-config too.

    One nice "feature" that IFFE doesn't have is the ability to select feature through switches in a "configure" script (e.g. --prefix=XXXX --disable-static --disable-debug, etc...)

  • pmk (a.k.a. Pre Make Kit)
    this is something completely different, designed by some programmers that were completely fed-up with the Auto-tools. They designed a small language and interpreter to deal with most features they needed, with 10 times less complexity. They even have some nice partial Autoconf compatibility to make transition easier. Unfortunately, they don't even support Windows (even on Cygwin !!), which sadly makes them totally irrelevant for real-world usage (IMO).

    Their page is here

While these are not perfect solutions, they prove that it is possible to make simpler tools to deal with these issues. My understanding is that people don't want to learn a new installation procedure. All they want is type "configure" with their usual parameters then launch make (and why are we still using Make in the 21st century eludes me :-).

If a viable alternative appears, it will need to provide similar commands.

16 Jan 2006 (updated 16 Jan 2006 at 12:03 UTC) »
titus: configure scripts are not as portable as you believe. A script generated on Linux won't always work correctly as-is on FreeBSD, Cygwin or Mac OS X, the same is true for scripts generated on these platforms.

Moreover, they're huge (often > 100KB) ugly beasts that can change considerably between autoconf invokations, especially when your developers are on distinct platforms. Why would you want to put that kind of poop into your CVS repository ?

you'd better rant that developers should document which versions of autoconf/automake/libtool is needed instead.

bi: the exact French word is "gouvernement" and describes exactly what I said in my previous post (i.e. the executive office designated by the President, and nothing more).

Other funny factoïds:

  • since he's the head of the "gouvernment", our "Premier Ministre" is not elected (unlike the one in the UK).

  • a "cabinet" refers in France to the specific office of a given "ministre". So you can say "le cabinet du ministre de la Culture", which is only a tiny part of the "gouvernement".

French Politics for Dummies

It seems there is confusion about what happened yesterday regarding the "DADVSI code", so here's a quick intro on how French law-making works:

First, the actors

  • The government is a set of people chosen by the President to rule the country's affair. These people are not elected and do not represent the people of France in any way; they're just chosen by the President, and can be swapped/fired at will (which happens pretty often ;-)

  • The parliament is a set of locally-elected deputies. Each one has won a local election to be a representative for a specific region/district of France. Anybody can be a deputy, but you'll need to win the election, where being affiliated to a strong political party helps a lot (especially when you're a pedantic snob that never shook hands with the populace, like someone I know who became a deputy :-)

  • The senate is a set of old-bums that are elected by the Deputies every nine-years. It is used as a sort of geriatric facility for old politicians who can't do anything else. It's really a strange oddity in our political system because most of them are aged over 70 and don't have an idea of the country's current affairs.

Then, the Rules

  • One of the government's role is to propose new laws, or amendments to existing ones. All these proposals are debated at the Parliament by the deputies.

  • The deputies can reject a proposal, accept it pro forma, or more generally request specific changes and amendments before accepting them. Each proposal must be debated for at least two sessions, except under exceptional conditions.

  • When a proposal if accepted, even in modified form, it is sent to the Senate. The senators must also debate the proposal and have the power to reject it or accept it. I don't believe they can change it however. There is only one debate there.

  • When a law has been accepted by both the Parliament and the Senate, the Government must officially publish a special document, named "Décret d'application" which states exactly when the law shall start to be applied, wether it is retro-active, etc...

    It's important to understand that if the decret is not published, the law is pending and shall not be applied by judges, even if they want to :-) Interestingly, there exist a lot of "pending" laws in France that will likely never be applied.

So, what happened here

  • The government, and more specifically the "Ministre de la Culture" (yes, we have that here) proposed a sort of super-DMCA law to "protect" the authors of copyrighted works by making DRM tempering illegal (bye bye VLC's DVD playing capabilities), providing information about DRM systems illegal, and explicitely refusing fair uses practices for the purchasers of DRM-ed products.

  • The government has invoked exceptionnal reasons to impose a single debate at the parliament, instead of two; it also planned a very late hour for the debate just before Christmas. This is usually done to "ease" the acceptance of proposals, since less deputies in the debate generally mean less debates, change requests, refusals, etc...

  • The parliament has nonetheless imposed several amendments, some of them that would explicitely make non-commercial P2P sharing a recognized "fair use", as long as a sort of global tax be paid by users on their ISP's bill.

What does it mean

The law isn't official, so P2P isn't legal in France. Not yet. That also means that we can still watch DVDs though. There is nearly 0% chance that the Senate will accept the proposal, or that the Government will publish the corresponding Decret.

Not also that the "global tax" system isn't in place yet. Even if the law was applied NOW, P2P sharing would still be illegal.

Hope this helps.


I still don't sleep enough,


To follow La Mode, I remember reading and appreciating these in 2005:

  • "Le Samouraï Virtuel", a.k.a. "Snow Crash" (N. Stephenson)
  • "Le dernier théorème de Fermat", a.k.a. "Fermat's last theorem" (S. Singh)
  • "Histoire des Codes Secrets", a.k.a. "The Code Book" (S. Singh)
  • "Dernier inventaire avant liquidation" (F. Beigbeder)


Couldn't find a lot of free time to work on it; however, I could study ZLib's latest revisions. It turns out that the authors have done great things: cleaning up the sources (no more "one-letter-identifiers-only" coding style), improving performance and reducing memory footprint. Great !!

Web 2.0

I love this, that's sooooo true :o)

21 Oct 2005 (updated 21 Oct 2005 at 09:08 UTC) »

I'm still trying to get rid of big memory eaters in FreeType. I have found the following offenders to date:

  • the LZW decompressor, used to support pcf.Z and bdf.Z font files on legacy systems (i.e. SunOS) allocates a 400 KB memory block before reading anything from a file.

  • the PCF driver copies large portions of font files into memory, when it should really re-load them on demand.

  • the BDF driver allocates a 64 Kb heap block before reading anything. It also duplicates a lot of things in memory when it should re-read them from the file.

I've started working on the first one. It seems the code we use came from the BSD "uncompress" program. Its source code is cryptic, suffers from bad design and slow read performance. I rewrote it in a few hours into something much more elegant. Try to compare this and this.

The good news is that testing with timR24.pcf.Z shows that opening is now 27% faster, glyph loading is now 63% faster, and that the new code saves 330KB of heap memory with this font. not bad for such a small change :-)

However, this is for a deprecated format that nearly nobody uses. I'll probably work on the PCF reader later. Its source code comes from the XFree86 distribution, and probably needs a good rewrite as well.

I'm also wondering if there isn't a way to optimize the zlib source code used for .gz support. Last time I checked, it was horrible as well, but it seems they've done very good thing for version 1.2.

21 Oct 2005 (updated 21 Oct 2005 at 08:40 UTC) »
Pango, Text Layout and UI Performance

Kudos to Federico for starting to optimize Pango. I know fom experience that even a small performance difference in text layout alone (i.e. without touching glyph rendering) has a huge impact on user's perceived interface speed. That's because toolkits and applications tend to draw a _lot_ of text, even when they could trivially avoid it.

When I had to add Arabic to my company's products, the text layout operation timing initially doubled due to the support of the Unicode BIDI algorithm. It was a custom solution since we couldn't use either ICU or FriBidi. I didn't think it would be a big issue since, in the graphics architecture we were using back then, the time to transfer text glyphs to the screen was very important. My own tests didn't show any perceivable difference anyway when the whole application was running.

Well, I was wrong. It turned out that the application could switch dynamically between English and Arabic presentation mode, and the client complained that scrolling lists in Arabic was slower than in English. How much slower ? Well, a really _tinsy_ bit slower, you had to scroll several pages on the list to really show the difference. But they were horrified by this and considered this to be a top-priority issue.

After a quick analysis, it turned out that:

  • the list component redraw the whole page everytime you went from one item to the next, even though it only needed to update two lines

  • due to the component's design, this required a rewrite, and there was no time to do that (different team, different planning, etc..)

I ended up rewriting the BIDI implementation and the Arabic shaper, with all kinds of tricks. It's probably a bit slower than ICU's algorithm (which is insanely clever, by the way), but at least I knew it would be manageable by someone other than me at the company ;-)

The end result was that laying out Arabic text is now only 10% slower than English in our product, mainly because we don't use OpenType fonts !!.
Problem solved. Except we're probably never going to fix the list component. Ah ah...


Alice is slowly getting better. She doesn't scream as much as she used too, and only wakes up once in the middle of the night. That's a huge improvement, and we're just beginning to recover though my brain is still terribly dizzy at the moment :-)


FreeType 2.1.10 is out, this fixes a bunch of bugs, but the memory savings I have mentioned in a previous diary entry are disabled by default. This is because this breaks several libraries on Unix that unfortunately use internal FT2 structures which changed during the optimizations.

The next version will be called 2.2.0, use a major library version number of 7 (instead of 6), and will _not_ install the internal/private headers (this was our original mistake which created this situation). Instead, they'll be replaced by files generating #errors at compile time with a message explaining the situation.

What it means is that an undecided amount of code is going to break when compiled against this version of the library, which is why I've begun writing patches for Pango, FontConfig and a few other libraries. I'm currently working on SDL_ttf and Qt.

It turns out to be a lot simpler than what I expected; my problem is that I don't know the exact list of libraries and applications that directly depend on FreeType internal structures and functions. If you happen to work at at Linux distribution company, or simply have a lot of disk space, huge bandwidth and plenty of free time (which really isn't my case at the moment), I'd be glad if you could grep for some of the lines below and report which packages contain them:

grep "FT_INTERNAL_" sources
grep "freetype/internal/" sources

Of course, 2.2.0 isn't out until we get a sufficient number of patches and make them available on our web site. I don't expect to see that much problem however once the popular libs are out.

And yes, I've used Koders Search (www.koders.com) and it seems absolutely useless for this purpose.


I've installed Ubuntu Hoary on my laptop, dual booting with XP, and I'm very impressed with it. However, trying to use it on an on-going basis is _very_ frustrating, because it lacks many of the niceties I'm used to on Windows. I'm not talking about Windows-specific items, rather about all the free cool-addons, most of them free software, that I regularly use.

Does anyone know an equivalent for the following on Gnome, or even, sigh..., on KDE:

  • TortoiseCVS
  • TortoiseSVN
  • Putty Pageant (I mean a Gnome or KDE applet)

And I can't get the damn thing to suspend properly, not even hibernate. I normally don't use the feature, because XP boots _very_ quickly on this machine, but startup is so slow on Linux that it's painful. For the record, I use this machine on the train twice a day, each trip being 30 minutes, it's not like a nearly 2 minutes boot isn't a problem for me.

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