Older blog entries for freetype (starting at number 31)

24 Feb 2006 (updated 24 Feb 2006 at 12:32 UTC) »
Guillermito versus TEGAM

Sad things on the French legal front: the appeal court has decided to confirm the first judgement, on the following grounds:

  • Guillermito did, and admitted to, use a warez copy of VIGUARD, since he was in the USA, and the program was only sold in France. This, however, is clearly copyright infringement.

  • Guillermito is accused of having disassembled the binary (even though he always denied it), which is only allowed under French law for purposes of interoperability, which wasn't the case here. He also replicated some parts of the original software (an 80 bytes very weak encryption key) which was distributed with his weakness analysis tool on the Internet. And this is considered as another copyright infringement by the judge !

A detailed explanation of the text is available here (French only).

I don't have any problem with the first point, but the second one is simply scary, because it is difficult to understand what kind of legal ramifications it could have in the future. I also don't know if the situation would have been different, would Guillermito had a valid VIGUARD license. I'll try do document myself on the details of our own IP laws before making more comments on the topic.

Apart from that, Guillermito has been sentenced to pay about 15.000€, which is a lot, even if this is several order of magnitudes less than what TEGAM was asking for. Talk about chilling effects !!

If you want to cheer him up a bit, you can help him buy a new but expensive anti-virus though. I just donated 100€.

Note that this software promises to protect your PC against voodo, black eye, and other bad lucks. I guess it's what they call truth-in-marketing.

DVD Backup - XVID Rules !!

My daughter recently scratched to death her second copy of Shrek 2 (the former one died 8 months ago, she had to wait until X-Mas to get it replaced), I decided that enough was enough, and that I wasn't going to buy it a third time.

So, I did:

  • grab my sister-in-law copy of the DVD

  • install the necessary software on my computer, and after several hours of frustration, get a new shiny CD-R with an XVID avi of the movie on it

  • Go to my local supermarket, and buy a "MPEG-4 compatible" DVD player for 30€, including VAT.

Tada !! Here it goes, and it doesn't have these unskippable and annoying "warnings" and adverts. Plays like a charm in the new player, with superb quality, and the kids are happy. They can break the disk if they want, I have a backup of the AVI to burn new CDs when they'll do.

My mother saw it the other day and was very impressed. She's the kind of person that is really annoyed by any DVD menu, and she sees any way to get rid of them as progress :-)

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.

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