RFE: Adjust the XLFD font code (GTK+/Xlib/Xprint) to support glyphs outside the Unicode BMP (Basic Multilinguar Plane), e.g. glyph values > 0xFFFF Counterpart is http://bugs.xfree86.org/show_bug.cgi?id=1046 ("RFE: Enhance the encoding map code to support chars outside the Unicode BMP") to add server-side support to Xfree86 encoding map processing code (this is for TTF/PT1 fonts, BDF/PCF fonts don't need that).

jshin: Can you take this bug, please ?

How can I when there isn't even a standard XLFD 'convention' for non-BMP fonts? Anyway, bug 162431 has to be fixed first.

Jungshik Shin wrote: > How can I when there isn't even a standard XLFD 'convention' for non-BMP fonts ? Making a bunch of encoding map files for Xfree86 isn't much the problem... or do you mean something different here ?

Sure it's not a problem (once some consensus is reached), but there's none except for cns11643-*. And, that's exactly the problem of XLFD-based fonts. We have to know names, mappings and repertoire a priori and _hard-code_ them. (compare that with the way Windows/Xft/Mac OS fonts are handled.) Anyway, with bug 162431 fixed, this bug will automatically be fixed for known existing non-BMP-covering XLFD registry-encoding pairs (cns11643*)

Jungshik Shin wrote: > Sure it's not a problem (once some consensus is reached), but there's none > except for cns11643-* There is currently some work going on to add a new XLFD encoding scheme to cover the full unicode range (this will also solve the disaster caused by the *-iso10646-1 encoding). > And, that's exactly the problem of XLFD-based fonts. We > have to know names, mappings and repertoire a priori and _hard-code_ them. In theory we could have support for mapping files like Xfree86 and Solaris/Xsun does - instead of hardcoding them. > (compare that with the way Windows/Xft/Mac OS fonts are handled.) Anyway, with > bug 162431 fixed, this bug will automatically be fixed for known existing > non-BMP-covering XLFD registry-encoding pairs (cns11643*) We still have to cleanup nsFontMetricsGTK and nsFontMetricsXlib and do some adjustments since some functions and structs still use 16bit integers instead of 32bit ones... ;-( jshin: Wanna take this bug, please (for 1.7b) ?

Is this bug still relevant for thebes/cairo?

As far as I know, we no longer use Xlib fonts at all, so I'm going to go ahead and close this bug. Please file a new bug in Core:Graphics if there is still something that should change.