[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Devel] Problems with font naming and Xft
From: |
Owen Taylor |
Subject: |
Re: [Devel] Problems with font naming and Xft |
Date: |
Tue, 26 Mar 2002 12:05:09 -0500 (EST) |
User-agent: |
Gnus/5.0807 (Gnus v5.8.7) Emacs/21.1 |
David Turner <address@hidden> writes:
> Hello Owen,
>
> Owen Taylor a écrit :
> >
> > It's been reported to me (http://bugzilla.gnome.org/show_bug.cgi?id=68113)
> > that GTK+-2.0, when using Xft has problems with some Japanese fonts of
> > not displaying any name at all.
> >
> > The problem seems to be that Xft is simply using the family_name field
> > of FT_Face and this field is initialized in a rather haphazard way.
> >
> > From reading the code in FreeType, it looks like what it does is it
> > picks a (more or less) random Unicode name from the font, which could
> > be for any language, and then converts that from Unicode to "ASCII"
> > by assigning each character of the result to one byte of the Unicode
> > character. (If there is only an Apple Roman name, and no unicode names,
> > it similarly assumes that Apple Roman is ASCII.)
> >
> > Now, I can probably figure out some way of using FT_Get_Sfnt_Name()
> > directly, bypassing Xft, but it seems to me that that freetype could
> > do better on a couple of counts when setting the family_name field:
> >
> > - If there is a name for the English language ID, it should use
> > that. Yes, this is English-centric, but, it can't be less useful
> > to pick the English name than a completely random name, and it's
> > much more likely that the English name is going to be in the
> > ASCII subset of Unicode.
> >
> > - When converting from a different encoding into ASCII, if there
> > characters with values greater than 127, replace them with
> > ? or some other substitute character rather than the low byte.
> >
> Agreed.. Actually, the font name selection code was pretty buggy
> before 2.0.9, though it worked for most fonts. It got better in
> 2.0.9 to deal with broken fonts that include invalid name table
> entries.
>
> I've just commited a more general fix to the STABLE branch of the
> code on the CVS. Could you please download it and report problems with
> it.. ?
I don't have access to the problematical fonts myself; I've asked
the reporter of the problem if he could try out your fixes and see
if they resolve his problem.
Reading through the code, it looks plausible; my one question would be
whether, if there are no names for the English language ID, should it
then pick an arbitrary name?
That is, change:
if ( (rec->languageID & 0x3FFF) ) == 0x009 )
to:
if ( found_win == -1 ||
(rec->languageID & 0x3FFF) ) == 0x009 )
Even a bunch of ???? is probably better than returning NULL for the
font name, and if the font only has, say, a French name, then
truncation to ASCII will probably produce something identifiable.
Regards,
Owen