Fontconfig - Apr 2006 - FcFontMatch oddities

Guys,

after spending an entire afternoon reading source for fontconfig and Xft
and doing some experimenting it seems that I really need some help with
understanding what seems to be an explicit design decision.

The question is quite simple -- it seems that quite explicitly fontconfig
doesn''t let a client application request an exact set of properties for
a font and how this font is supposed to be rendered. Basically, even though,
I can do something like:

   $ xterm -fa ''mono:bgr''

and even though at a pattern level '':bgr'' gets recognized and
passes upstream,
when it comes to ''FcFontMatch'' everything that has to do with
the rendering
gets stripped.

So the question is -- why not let client tell the library *everything* why
limit the choice to ''font-lookup'' properties only ?

Thanks in advance,
Roman.

Roman Shaposhnick wrote:
> The question is quite simple -- it seems that quite explicitly fontconfig
> doesn''t let a client application request an exact set of
properties for
> a font and how this font is supposed to be rendered. Basically, even
though,
> I can do something like:
> 
>    $ xterm -fa ''mono:bgr''
> 
> and even though at a pattern level '':bgr'' gets recognized
and passes upstream,
> when it comes to ''FcFontMatch'' everything that has to do
with the rendering
> gets stripped.
You''ll have to ask keithp why this is the case, but yes, I believe that
FcFontMatch only matches on the pattern elements that are explicitly
listed in _FcMatchers in fcmatch.c, namely foundry, charset, family,
lang, spacing, pixelsize, style, slant, weight, width, antialias,
rasterizer, outline and fontversion.

pat

On Tue, Apr 18, 2006 at 02:02:05PM -0400, Patrick Lam
wrote:
> Roman Shaposhnick wrote:
> 
> > The question is quite simple -- it seems that quite explicitly
fontconfig
> > doesn''t let a client application request an exact set of
properties for
> > a font and how this font is supposed to be rendered. Basically, even
though,
> > I can do something like:
> > 
> >    $ xterm -fa ''mono:bgr''
> > 
> > and even though at a pattern level '':bgr'' gets
recognized and passes upstream,
> > when it comes to ''FcFontMatch'' everything that has
to do with the rendering
> > gets stripped.
> 
> You''ll have to ask keithp why this is the case, 
  Is he reading this list or do I have to Cc him separately ?
> but yes, I believe that
> FcFontMatch only matches on the pattern elements that are explicitly
> listed in _FcMatchers in fcmatch.c, namely foundry, charset, family,
> lang, spacing, pixelsize, style, slant, weight, width, antialias,
> rasterizer, outline and fontversion.
  It is not even that FcFontMatch *matches* based on these values
  (after all, I''m yet to see a font that has an ability to tell the
  world it wants to be rendered in bgr only) but that it doesn''t
  append or overlay what was explicitly requested on the matching
  font pattern. The biggest trouble of all is that when FcFontMatch
  is done matching in my particular case the result has ''rgba''
set
  to 0. Which means -- we don''t know, we didn''t have an
explicit request.

  At some level, I would even be happy if such an overlay functionality
  was implemented as a separate API (but I don''t seem to find it
anywhere)
  which would let me do something like:

     match = FcFontMatch (0, pattern, result);
     FcOverlayExplicitlyRequestedProperties(match, pattern);

  I guess what I''m really after is a very basic property in every
system:
  if a client has explicitly requested something -- don''t just ignore
it
  unless there''s a good technical reason for that (like the request
being
  senseless, for example). Right now fontconfig does exactly that -- it
  ignores my explicit request (as in ''mono:bgr'') and, I guess,
I''m still
  looking for somebody to explain that ''technical reason'' to
me ;-)

Thanks,
Roman.