Summary: | Xfont: not compatible with freetype-2.2 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Valery Inozemtsev <shrek> | ||||||
Component: | Lib/Xfont | Assignee: | Xorg Project Team <xorg-team> | ||||||
Status: | CLOSED FIXED | QA Contact: | |||||||
Severity: | critical | ||||||||
Priority: | high | CC: | boiko, cloos, dberkholz, dparsons, freedesktop, jasmin-bugfd, nickols_k, pierre42d | ||||||
Version: | git | ||||||||
Hardware: | Other | ||||||||
OS: | other | ||||||||
Whiteboard: | |||||||||
i915 platform: | i915 features: | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 6666 | ||||||||
Attachments: |
|
Description
Valery Inozemtsev
2006-05-15 00:48:42 UTC
you will need to provide much more information than this if you expect us to do anything about it. https://sourceforge.net/project/shownotes.php?release_id=416463&group_id=3157 "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." 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: 57: #include FT_INTERNAL_TRUETYPE_TYPES_H 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 :( This was posted to freetype-devel earlier this year: http://www.mail-archive.com/freetype-devel@nongnu.org/msg01062.html which references a patch at: https://www.codeblog.org/blog/mpsuzuki/20060211.html which gets part way to freetype-2.2 compatability. David Turner has posted an experimental patch in: http://permalink.gmane.org/gmane.comp.fonts.freetype.devel/4022 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). Created attachment 5662 [details] [review] Patch to fix libXfont's usage of freetype internals by Dave Turner with small mod by James Cloos *** Bug 7042 has been marked as a duplicate of this bug. *** 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 http://lists.gnu.org/archive/html/freetype-devel/2006-05/msg00034.html and continues in June at http://lists.gnu.org/archive/html/freetype-devel/2006-06/msg00002.html Drew 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? 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. 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. 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 call 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. (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! *** 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.