freetype-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]