Fontconfig - Nov 2005 - Two missing features

On Wednesday 15 October 2003 20:34, Keith Packard wrote:
> Around 10 o''clock on Oct 15, Lars Knoll wrote:
> > The biggest problem we encountered is that we have no way of knowing
> > about aliases defined in the fonts.conf files. Reason we need them is
> > that we do some font matching ourselves, and matching
"serif" would
> > always fail since we didn''t know this is a valid family name
in font
> > config.
>
> There aren''t ''aliases'' per-se in fontconfig;
fontconfig provides only a
> mechanism for modifying incoming patterns before matching.
>
> An important reason for this is a trademark issue.  With the core fonts, we
> had several font foundaries complain about the aliasing mechanism because
> font lists would include trademarked font names not actually present on the
> machine, a user selecting those trademarked names would see alternative
> fonts presented on the screen.
I agree that this is not really desirable.
> However, there are standard substitution rules which guarantee to provide
> reasonable defaults for three of the CSS2 generic names (sans-serif, serif
> and monospace).  I suggest simply placing those generic names into all of
> your font menus, perhaps separate from the ''real'' family
names.
The problem I have with this approach is what happens if you at some point 
also choose to offer "fantasy" CSS name (actually the user could do it
by
editing his own fonts.conf). That would require the user to patch and 
recompile Qt to get it in the font list.
> > The other missing feature are having access to the localized family
names
> > true type offers. This is especially important for asian people. Also
> > here I''d be happy with an additional font property
FC_LOCALE_FAMILY I can
> > pass into FcFontList to have the localized names included in the
pattern.
>
> Yes, I''d really like to offer this as well.  I''ve been
thinking about how
> this might work and haven''t really found the perfect solution. 
What I can
> do is include all of the names in the FC_FAMILY/FC_STYLE entries and then
> provide an API that selects one using an RFC 3066 language tag.  The
> existing listing API could then default to using the current locale.
If possible I''d like to get both names with on FcFontList command. The
reason
is that I''d like to have a mapping between international and localized
name.
If I understand you correctly this would be the case with your approach.

I''d guess that most fonts have at most two family names. An
international and
a localized one. In this case, the approach using RFC 3066 language tags is 
maybe overkill. It would suffice to get them both side by side with an easy 
API.

Lars
> If this makes sense, I''d like to give it a try and see if it
actually
> works.
>
> -keith

>> you want fontconfig to provide you with the XLFD name when it
>> cannot be easily derived from the fonts real name.
KP> I''m assuming you mean the XLFD-modified family name here, and
not the
KP> complete XLFD name.

Aye, aye.
>> I have no doubt that people will come up with other strange needs.
KP> XLFD is probably the strangest of them...

That''s okay, Keith.  We''ve forgiven you already ;-)

                                        Juliusz

Around 10 o''clock on Oct 15, Lars Knoll wrote:
> The biggest problem we encountered is that we have no way of knowing about 
> aliases defined in the fonts.conf files. Reason we need them is that we do 
> some font matching ourselves, and matching "serif" would always
fail since we
> didn''t know this is a valid family name in font config.
There aren''t ''aliases'' per-se in fontconfig;
fontconfig provides only a
mechanism for modifying incoming patterns before matching.

An important reason for this is a trademark issue.  With the core fonts, we
had several font foundaries complain about the aliasing mechanism because
font lists would include trademarked font names not actually present on the
machine, a user selecting those trademarked names would see alternative
fonts presented on the screen.

However, there are standard substitution rules which guarantee to provide 
reasonable defaults for three of the CSS2 generic names (sans-serif, serif 
and monospace).  I suggest simply placing those generic names into all of 
your font menus, perhaps separate from the ''real'' family
names.
> The other missing feature are having access to the localized family names
true
> type offers. This is especially important for asian people. Also here
I''d be
> happy with an additional font property FC_LOCALE_FAMILY I can pass into 
> FcFontList to have the localized names included in the pattern.
Yes, I''d really like to offer this as well.  I''ve been
thinking about how
this might work and haven''t really found the perfect solution.  What I
can
do is include all of the names in the FC_FAMILY/FC_STYLE entries and then 
provide an API that selects one using an RFC 3066 language tag.  The
existing listing API could then default to using the current locale.

If this makes sense, I''d like to give it a try and see if it actually 
works.

-keith

Around 16 o''clock on Oct 16, Juliusz Chroboczek wrote:
> I suggest a new property of FcFonts that holds an a-list of all the
> alternate names.  Naive applications will only get the primary name;
> wiser applications will get all the names.
That will complicate matching semantics quite a bit -- you''ll want to 
consider matches against either the primary name and the alternate names 
as equivalent in matching priority.  What I could do is have the existing 
FcFontList API return only one name (primary?  alternate for current 
locale?) and then provide another API to return other names (provide a 
language tag?  return all names?)
> We also need an API to get a font by another name; scanning all fonts
> and building a database of all alternate names is of course
> prohibitive.  I suggest having two variants of the font listing
> interface, one that only considers primary names, one that uses all of
> the names.
If we place all of the names in the FC_FAMILY entry, then the existing
listing code will work correctly as-is.  The only question is what values
are returned by FcFontList.  I think it would be nice if it returned
localized names  by default, but I can see arguments for having it always
return names that can be represented in ASCII (or Latin-1).
> (OT: is there any way the application can find out whether the font
> database has changed since a given date?  That would be useful for
> applications wishing to cache font-related information.)
Not directly.  You can use FcConfigUptoDate to see if the configuration
needs to be re-read, or you can use FcConfigGetConfigFiles and
FcConfigGetFontDirs to retrieve lists of filenames that encompass the whole
configuration state.  Stat''ing those will let you compute when the
configuration may have changed.
> The issue has come up already when we were trying to do all fonts
> localisation (including core fonts) through fontconfig; you want fontconfig
> to provide you with the XLFD name when it cannot be easily derived from the
> fonts real name.
I''m assuming you mean the XLFD-modified family name here, and not the 
complete XLFD name.  For the complete XLFD name, I''d like to figure out
what additional properties are necessary to accurately compute that string.
> I have no doubt that people will come up with other strange needs.
XLFD is probably the strangest of them...

-keith

KP> Yes, FcFontList returns patterns holding all of the information from the 
KP> fonts, so it will have all of the names.  One issue is that you will get 
KP> multiple entries if fonts have different sets of family names.

I suggest a new property of FcFonts that holds an a-list of all the
alternate names.  Naive applications will only get the primary name;
wiser applications will get all the names.

We also need an API to get a font by another name; scanning all fonts
and building a database of all alternate names is of course
prohibitive.  I suggest having two variants of the font listing
interface, one that only considers primary names, one that uses all of
the names.

(OT: is there any way the application can find out whether the font
database has changed since a given date?  That would be useful for
applications wishing to cache font-related information.)
>> I''d guess that most fonts have at most two family names. An
>> international and a localized one.
I think we really want to have a generic notion of ``alternate
name''''
that is not limited to localisation.  The issue has come up already
when we were trying to do all fonts localisation (including core
fonts) through fontconfig; you want fontconfig to provide you with the
XLFD name when it cannot be easily derived from the fonts real name.
I have no doubt that people will come up with other strange needs.

                                        Juliusz

On Thu, 2003-10-16 at 13:39, Keith Packard wrote:
> > We also need an API to get a font by another name; scanning all fonts
> > and building a database of all alternate names is of course
> > prohibitive.  I suggest having two variants of the font listing
> > interface, one that only considers primary names, one that uses all of
> > the names.
> 
> If we place all of the names in the FC_FAMILY entry, then the existing
> listing code will work correctly as-is.  The only question is what values
> are returned by FcFontList.  I think it would be nice if it returned
> localized names  by default, but I can see arguments for having it always
> return names that can be represented in ASCII (or Latin-1).
I think FC_FAMILY should be restricted to being the ASCII-only name
as currently, and if you want a all-localized-font names, that should
be a separate property.

Users of fontconfig have to stay aware of the distinction between:

 - Programmatic name of font
 - Name of font displayed to the user

Or they won''t behave properly when the user switches languages and
so forth.

Certainly, the two following need to stay true:

1) FcPatternGetString (pattern, FC_FAMILY, 0, &s) must return the
   programmatic name
 
2) Passing the programmatic name to FcFontSetList as FC_FAMILY
   must continue to match that font

But I think even adding the localized names to FC_FAMILY in some
way that preserves those two invariants is likely to cause 
breakage for existing programs.

Regards,
						Owen

Around 10 o''clock on Oct 16, Lars Knoll wrote:
> The problem I have with this approach is what happens if you at some point 
> also choose to offer "fantasy" CSS name (actually the user could
do it by
> editing his own fonts.conf). That would require the user to patch and 
> recompile Qt to get it in the font list.
I guess we could codify the ''standard'' generic names somehow
so that this
cannot happen.

Alternatively, we could add a configuration parameter and API to list 
these generic names.  That way people could add new ''generic''
names and
applications would still be able to tell the difference between those 
names and the ''real'' font names provided by FcListFont.
> If possible I''d like to get both names with on FcFontList command.
The reason
> is that I''d like to have a mapping between international and
localized name.
> If I understand you correctly this would be the case with your approach.
Yes, FcFontList returns patterns holding all of the information from the 
fonts, so it will have all of the names.  One issue is that you will get 
multiple entries if fonts have different sets of family names.  For naive 
applications, that will show up as multiple entries for the same family, 
which seems undesirable to me.  I''m not quite sure how FcFontList could
solve this problem.
> I''d guess that most fonts have at most two family names. An
international and
> a localized one. In this case, the approach using RFC 3066 language tags is
> maybe overkill. It would suffice to get them both side by side with an easy
> API.
RFC 3066 language tags have the advantage of already being present in the 
fontconfig API and providing a nice notion of territory and language.  
These very same tags are used in HTML and the C locale mechanism; this 
should reduce the amount of code needed in applications as they won''t
have
to translate to yet another weird naming scheme for languages.  Inside 
fontconfig, the only cost will be a small table mapping the TrueType 
language tags to RFC 3066 values.  That table should be quite small.

-keith

Around 11 o''clock on Oct 17, Owen Taylor wrote:
> I think FC_FAMILY should be restricted to being the ASCII-only name
> as currently, and if you want a all-localized-font names, that should
> be a separate property.
Let''s hold that thought; it''s difficult to imagine how the
current
matching semantics can be cleanly extended to do reasonable things with
family names split across two properties.
> 1) FcPatternGetString (pattern, FC_FAMILY, 0, &s) must return the
>    programmatic name
>  
> 2) Passing the programmatic name to FcFontSetList as FC_FAMILY
>    must continue to match that font
Both of these would continue to be true if the FC_FAMILY contained all of 
the names for the font.  The first would be true if we carefully placed 
the ''programmatic'' (aka English) name first in the list.  The
second would
be true even if the programmatic name was placed in some random order.
> But I think even adding the localized names to FC_FAMILY in some
> way that preserves those two invariants is likely to cause 
> breakage for existing programs.
I don''t see how this could break existing applications if we take a bit
of
care. I think the key effect will be on the font listing APIs, and for
those, I suggest that the localizable entries be trimmed to include only a
single entry.  I''d like that entry to be a localized name, but could be
convinced that a separate API should be used and that the existing API
return only programmatic names.

-keith

Hi,

for Qt 3.2.x we were implementing support for Xft2/FontConfig, and noticed a 
few missing features we could/would need to make our lifes (or the life of 
our users) easier.

The biggest problem we encountered is that we have no way of knowing about 
aliases defined in the fonts.conf files. Reason we need them is that we do 
some font matching ourselves, and matching "serif" would always fail
since we
didn''t know this is a valid family name in font config. Another reason
is
that IMO the user should be able to select these general families.

We could have hardcoded the three ones that are currently there, but I
don''t
think that this is the correct solution as the fonts.conf file can be edited.

One idea I had for this is an additional font property FC_SYNTHESIZED_FAMILY 
or similar one could use together with FcFontList.

The other missing feature are having access to the localized family names true 
type offers. This is especially important for asian people. Also here
I''d be
happy with an additional font property FC_LOCALE_FAMILY I can pass into 
FcFontList to have the localized names included in the pattern.

Cheers,
Lars