Bug 6918 - Xfont: not compatible with freetype-2.2
Summary: Xfont: not compatible with freetype-2.2
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xfont (show other bugs)
Version: git
Hardware: Other other
: high critical
Assignee: Xorg Project Team
QA Contact:
: 7042 7787 (view as bug list)
Depends on:
Blocks: xorg-7.2
  Show dependency treegraph
Reported: 2006-05-15 00:48 UTC by Valery Inozemtsev
Modified: 2006-08-08 14:50 UTC (History)
8 users (show)

See Also:
i915 platform:
i915 features:

Patch to fix libXfont's usage of freetype internals by Dave Turner with small mod by James Cloos (7.81 KB, patch)
2006-05-18 04:15 UTC, James Cloos
no flags Details | Splinter Review
Patch based on Dave's patch with some bug fix (8.72 KB, patch)
2006-06-25 01:50 UTC, Jie Luo
no flags Details | Splinter Review

Description Valery Inozemtsev 2006-05-15 00:48:42 UTC
Comment 1 Adam Jackson 2006-05-16 03:59:06 UTC
you will need to provide much more information than this if you expect us to do
anything about it.
Comment 2 Valery Inozemtsev 2006-05-16 04:06:27 UTC

"Version 2.2 no longer exposes its internals, this is, the header
files  located in  the `include/freetype/internal'  directory of
the source package are not  copied anymore by the `make install'
command.  Consequently, a number of rogue clients which directly
access  FreeType's  internal   functions  and  structures  won't
compile without modification."
Comment 3 Gustavo Pichorim Boiko 2006-05-16 05:52:07 UTC
ftfuncs.c:57:10: error: #include expects "FILENAME" or <FILENAME> 
ftfuncs.c:59:10: error: #include expects "FILENAME" or <FILENAME> 
ftfuncs.c:60:10: error: #include expects "FILENAME" or <FILENAME> 
naming the lines: 
59: #include FT_INTERNAL_SFNT_H 
60: #include FT_INTERNAL_STREAM_H 
It seems there won't be that easy to make Xfont work with freetype 2.2 :( 
Comment 4 James Cloos 2006-05-16 14:19:50 UTC
This was posted to freetype-devel earlier this year:


which references a patch at:


which gets part way to freetype-2.2 compatability.
Comment 5 James Cloos 2006-05-17 23:18:51 UTC
David Turner has posted an experimental patch in:

Comment 6 James Cloos 2006-05-18 04:13:35 UTC
I had to change one line in David's patch to avoid a NULL dereference, and now
it does not crash, but does not work properly for 16bit glyph encodings (such as
10646-1) of ttf fonts.  Oddly, the odd glyphs display fine but only the
rightmost column or two of the even glyphs do.  (Ie, glyph 0x33 displays but
glyph 0x32 does not.)  Type1 fonts also workd fine with 10646-1.

I'll attach the patch (Dave Turner's patch as earlier referenced with my change
to one line).

Comment 7 James Cloos 2006-05-18 04:15:11 UTC
Created attachment 5662 [details] [review]
Patch to fix libXfont's usage of freetype internals by Dave Turner with small mod by James Cloos
Comment 8 Alan Coopersmith 2006-05-27 02:07:51 UTC
*** Bug 7042 has been marked as a duplicate of this bug. ***
Comment 9 Drew Parsons 2006-06-13 02:15:12 UTC
That permalink.gmane.org link to the discussion at freetype-devel is painfully
slow for me. 
http://lists.gnu.org/archive/html/freetype-devel/2006-05/msg00037.html works
much better.

The thread starts at
and continues in June at

Comment 10 Drew Parsons 2006-06-13 21:54:38 UTC
I applied James' patch to lib/Xfont from cvs. I get a segfault trying to test
Xfont by printing with Xprint from git, but I'm not sure if that's because most
of my libraries are still back at X11R7.0 (using Debian unstable), so I can't
confirm or deny if the patch works yet, at least from the point of view of Xprint. 

On screen, at least, everything looks fine.  James, I can't reproduce the glyph
errors you saw. Could you provide more detail on how you tested your patch?
Comment 11 James Cloos 2006-06-13 23:03:25 UTC
I compiled xfs(1x) against the patched lib and used first fslsfonts(1x) with
various options, and then added that xfs instance to my font path with xset(1x).
At that point I used xfd(1x) to look at some fonts that were in the xfs's search
path but not (otherwise) in the xserver's fontpath.

Looking further, I see that I did patch the libXfont ebuild to use the no
internals patch and installed that (as x11-libs/libXfont-1.1.0-r2), and since I
have had to reboot since then, my current X server instance is linked against
that version of libXfont.  And it does seem to be working fine.

There may, then, be a bug in xfs rather than libXfont.  Or maybe something else
has also changed in the interm.  If no one else sees missing glyphs that part of
 this bug entry probably should be ignored.
Comment 12 Drew Parsons 2006-06-16 00:06:27 UTC
We've observed the glyph glitch in the bitstream-dejavu fonts.  Supplied in
Debian by the ttf-dejavu package, others could grab them from
http://debian.planetmirror.com/debian/pool/main/t/ttf-dejavu/ Viewing with "xfd
-fn -bitstream-dejavu*-iso10646-1", every second glyph is only half-formed.  

The problem is seen in xfontsel too.  In fact xfontsel makes it easier to test
other fonts. Many of them show the problem in the iso10646 registry, including
freeserif, bitstream vera, thyromanes.  Others, such as lucida, new century
schoolbook, do not seem to suffer from the bug.

Comment 13 Jie Luo 2006-06-25 01:50:13 UTC
Created attachment 6033 [details] [review]
Patch based on Dave's patch with some bug fix 

This patch is based one the patch of Dave Turner, and fix a type error when
tt_get_metrics. This fix glyph broken with dejavu and other truetype font. This
patch add a deal with glyph with zero height control box which freetype 2.2.1
thinks it is invalid and freetype 2.1.9 just ignores it. This fix warning about
FreeTypeRasteriseGlyph() return error on glyph that has zero height. And also
some fix to let it behave as the original.
Comment 14 Adam Jackson 2006-07-06 13:07:49 UTC
(In reply to comment #13)
> Created an attachment (id=6033) [edit]
> Patch based on Dave's patch with some bug fix 

Applied, will push out libXfont 1.2 shortly.  Thanks!
Comment 15 Alan Coopersmith 2006-08-08 14:50:19 UTC
*** Bug 7787 has been marked as a duplicate of this bug. ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.