libGD

I should also mention that using 2.0.35RC2:

$ /usr/local/bin/gdlib-config --version
2.0.34

/usr/local/bin/freetype-config –version

Use /usr/local/bin/freetype-config –ftversion to know the freetype version.

Also you may try the new ftdiff tool in the ft2demo package. As you may see the horizontal text should not be that thick. You can also tweak the hinting mode as well as some other parameters. It can to diagnose the problem (or the cause).

but doesn’t appear with the earlier version. Is GD using the FreeType API correctly?

Yes, it does (or there is a serious problem in the freetype in the same API calls can end to broken results). Please not that some options may set at compile time for their default values.

It does not sound like a GD bug, however I will keep it open as I like to understand what fails.

That's odd:

$ /usr/X11R6/bin/freetype-config --ftversion
Usage: freetype-config [OPTIONS] [LIBRARIES]
Options:
 [--prefix[=DIR]]
 [--exec-prefix[=DIR]]
 [--version]
 [--libs]
 [--libtool]
 [--cflags]
$ /usr/local/bin/freetype-config --ftversion
2.3.4

I just noticed that if I change the font size to 16 the problem goes away. Problem still occurs at size 14, though.

I've gone back and rerun the program with each FT version posted here: http://download.savannah.gnu.org/releases/freetype/

It's interesting how the text changes with each version. None of them work as well as the version installed by default on the Mac system.

Any word when the current GD is going to be incorporated back into PHP?

I've updated my install of PHP with GD 2.0.35RC2 and FT 2.3.4. You can see the image output here: http://leopold.sage.wisc.edu/test2.php The odd part is that it doesn't exactly match the results from the above test.2.3.4.png.

Some lines disappeared from my rendering engine upon upgrade. I'll get back to you on that, though.

Any word when the current GD is going to be incorporated back into PHP?

What do you mean? The version in PHP contains more fixes than the upcoming 2.0.35 (thread safety issues have been fixed already). You should use only the bundled version as the integration is better and more features are available than when you use an external library (see our PHP FAQ).

About the various freetype versions, one release is broken, 2.3.2 and should not be used at all. I will run some test and see which options default have changed between 2.2 and 2.3.x (2.1.x is out of my scope :).

A little note about freetype 2.3.x, I recommend to do not use it now. After some more tests, it looks like this branch has numerous issues (or I'm plain stupid). I'm working on tests to reproduce them, I will discuss them with the freetype developers and see what can be done from a gd point of view.

Thanks a lot for the numerous examples!

Here is the result of a comparison between 2.2.1 release, 2.2.1 Feisty (Ubuntu), 2.3.4 and CVS:

http://pierre.libgd.org/ft2/comparison.html

The code does not use any GD FT2 function (easier to catch the real sources of the problem). I also posted the results to the freetype developer mailing list. I will update this issue as soon as I get something new.

There are bug fixes in libGD which I would like to use in my PHP install. You are saying that I must choose between the bug fixes in libGD and the ones in PHP GD? I already linked PHP to libgd, and I've found one bug fixed and two bugs created so far.

There are bug fixes in libGD which I would like to use in my PHP install.
You are saying that I must choose between the bug fixes in libGD and the ones in PHP GD?

What I say is that you should use only the bundled version with PHP.

I already linked PHP to libgd,
and I've found one bug fixed and two bugs created so far.

Which are?

Ok, it looks like I found the cause of your problem, the default resolution.

Please take a look at: http://pierre.libgd.org/ft2/comparison.html

As you can see, the 96dpi results show your problem (which is used by php). 100dpi does not.

What I will do is to finally implement the missing font options for the PHP's gd function. It will be then possible to specify a custom resolution directly from a script (just like what a C user will do).

Can you try to compile php using a higher resolution?

I changed the RESOLUTION in 'ext/gd/gdttf.c' 100 and I'm recompiling. However, the aliasing still looks wrong in your examples here: http://pierre.libgd.org/ft2/100dpi/

If you look at the 'H' in 2.3.4 and CVS, the first one looks antialiased, but the other three look like they haven't been. I'm not sure if the resolution patch will fix this because it appears in one of the two horizontal strings. If vertical vs. horizontal resolution was a problem, I would expect both horizontal strings to look the same.

If I had to guess, I would say that you are making some settings when you draw the first string, but those are reset to default for the 3 additional strings.

With the changed RESOLUTION constant I'm getting the exact same result as before. Am I doing things right?

If you look at the 'H' in 2.3.4 and CVS, the first one looks antialiased, but the other three look like they haven't been. I'm not sure if the resolution patch will fix this because it appears in one of the two horizontal strings. If vertical vs. horizontal resolution was a problem, I would expect both horizontal strings to look the same.

The code I used does not use GD or PHP. The anti aliasing is not perfect either (some rounding issues). Also not that freetype works with other dimensions than pixel to perform the hinting or aliasing. That explains the slightly small differences from one mode to another. It is even more true when you have a transformation (more rounding, more approximation, etc.).

With the changed RESOLUTION constant I'm getting the exact same result as before. Am I doing things right?

Please try it in PHP, the constant is called "GD_RESOLUTION" and is defined in ext/gd/libgd/gd.h (please use the bundled gd too).

Besides the little differences, what I would like to know if it is the size (how thick are the glyphes) are correct or not.

I've updated the software. I'm running the bundled PHP-GD and freetype 2.3.4. I made the change to GD_RESOLUTION, and the difference is noticeable, but each string still has a different length. The first string is still approximately 10px shorter than the other three.

Image: http://leopold.sage.wisc.edu/test2.php

I've updated the software. I'm running the bundled PHP-GD and freetype 2.3.4. I made the change to GD_RESOLUTION, and the difference is noticeable, but each string still has a different length. The first string is still approximately 10px shorter than the other three.

The problem of the stroke thickness seems to be due to the resolution (too low and rounding problem). As your example shows, this problem goes away with a higher resolution.

The length of the rendered string are not shorter, the bbox contains relative position (to the text). I did not check how the script gets the length, but it looks like the source of the problem as the image is correct. Each text has a length between ~118px and 124px~ and that's correct. You can control it yourself using your favorite image tool.

I agree that there may be problems caused by resolution and rounding. But this does change the length of the string.

For example, using the attached font I get the attached output when I run testft2.c. The right string is 168px wide and the left string is 200px wide (one px off the edge). I'm using the command:

./a.out /Library/Fonts/Chalkboard.ttf 12 'Hllllllllllllllllllllllllllllllll'

I should also mention that I measured the string lengths in PhotoShop, so bbox calculations should be irrelevant.

The right string is 168px wide and the left string is 200px wide (one px off the edge).

There is again a hinting problem. It is sadly not a GD "bug" (but you know that already as testft2 does not use gd for the font rendeing :). You can play with the little testft2.c application, like changing the hinting mode or adding lsb/rsb as shown in the ftdiff demo (see the ft2demo package).

I will try to document as much as possible the various problems one may meet while working with different freetype versions (release or built, many distributions enable special modes or apply custom patches). This little experiment have brought some food already :)

Should I report this to the FreeType people?

Should I report this to the FreeType people?

It is not really a bug. You can try with different rendering mode to see the difference. Have you played with ftdiff and these two fonts (Verdana and Chalkboard)?

What I'm trying to find is how to determine which options are used in freetype and how to change them at runtime. The idea is to minimize the differences as much as possible.

I played with ftdiff, but they didn't have anything in there about rotating text. I suppose I can start taking measurements of ftdiff screen captures, but I don't know what the 'correct' rendering is. When I looked through the FT tutorials it looked like there was no simple way of changing drawing parameters. You simply have to use more detailed APIs, I believe.

Maybe we should make our own version of ftdiff that draws rotated text for comparisons?

It looks like it is actually a bug. I opened one in the savannah' freetype project: http://savannah.nongnu.org/bugs/?19813

Thanks for keeping me updated. Send a message if you need any help.