Re: [PATCH] Re: ftfont ISO10646-1 font bug found (was Re: 23.0.60; Heavy display problems with new font backend)

[Kenichi Handa]

Sorry for the late response on this matter.

In article <address@hidden>, address@hidden writes:

> > The ftfont_spec_pattern() function generates an FcPattern object that
> > can be used to list only fonts matching the spec.  For the purposes of
> > this discussion, there are two "interesting" ways of restricting
> > patterns: via charset (FcCharSet), or via langset (FcLangSet).  The
> > former requires the font to have each of the codepoints listed in the
> > FcCharSet.  The latter requires the font to support all the languages
> > in the FcLangSet.
> > 
> > 1. If we pass a font spec with registry ISO-8859 to
> > ftfont_spec_pattern(), then the code sets up an FcCharSet that has
> > every ASCII codepoint (but not Latin-1, that's commented out for some
> > reason).
> > 
> > 2. If we pass a font spec with a non-ISO-8859, non-ISO-10646,
> > non-Unicode-BMP registry, the function immediately returns an empty
> > pattern.
> > 
> > 3. ISO-10646 and Unicode-BMP registries are handled in a more
> > complicated manner...
> > 
> > If the ISO-10646 font spec has an associated :script parameter (or an
> > OpenType spec that refers to a script), the code looks in
> > 'script-representative-chars' for codepoints to put into a charset.
> > If the font spec has an associated language, the code adds the
> > language to the langset.
> > 
> > However, an ISO-10646 font spec without a special script or language
> > ends up with neither a charset nor a langset.  The resulting pattern
> > will match *any* characters and languages.  In partcular, it will let
> > an ISO-8859 font match the ISO-10646 spec.
> > 
> > The fix below checks for a missing charset and missing langset.  In
> > that case, we create a charset with at least one ISO-10646 codepoint
> > outside of ISO-8859.  The charset should be as small as possible,
> > since a font missing any of the charset's codepoints becomes
> > completely invalid.  I have chosen LEFT DOUBLE QUOTATION MARK, which
> > is associated with English and which I believe is pervasive.

I think it's very ad-hoc to return only such fonts that has
that specific character in that case.  Many non-English
fonts doesn't support it.

First of all, I have not that much considered about using
PCF fonts via ftfont driver because it can be used by xfont
driver if you put them in X's font-path.  On the contrary, I
was even thinking about rejecting all PCF fonts in xft
backend.

It's very unfortunate that fontconfig doesn't provide a
facility to find PCF fonts by registry.

If we still keep supporting PFC fonts in xft backend, I
think the right way is to create a FcCharSet object for each
registry (other than iso-10646 and unicode-*) that is
sufficient to avoid incorrect match.  The mapping of
registry->chars can be defined by some thing like
`registry-representative-chars' (analogus to
script-representative-chars).

And, for the case that iso10646-1 font is requested, we
should use FT_Get_BDF_Charset_ID to avoid non-iso10646-1 PCF
fonts, perhaps considering a use a cache if that is too
slow.

---
Kenichi Handa
address@hidden