Bug 38737 - Wishlist: support FC_POSTSCRIPT_NAME
Summary: Wishlist: support FC_POSTSCRIPT_NAME
Alias: None
Product: fontconfig
Classification: Unclassified
Component: fc-cache (show other bugs)
Version: 2_1
Hardware: All All
: medium enhancement
Assignee: Akira TAGOH
QA Contact: Behdad Esfahbod
Depends on:
Reported: 2011-06-28 01:28 UTC by Paul Sladen
Modified: 2013-03-21 07:39 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Description Paul Sladen 2011-06-28 01:28:34 UTC
Truetype/Opentype files have various sets of metadata, not all of which can be directly queried/matched via FontConfig.

In particular, both the OpenStep and CSS font-matching schemes require the "PostScript name" as the canonical form of first attempt:

  "the unique name used with local() specifies a single font, not an entire font family. Defined in terms of OpenType font data, the Postscript name is found in the font's name table, in the name record with nameID = 6 (see [OPENTYPE] for more details). The Postscript name is the commonly used key for all fonts on OSX and for Postscript CFF fonts under Windows. The full font name (nameID = 4) is used as a unique key for fonts with TrueType glyphs on Windows."

Previously patch(es) were offered by Isaiah Beerbower and Evgeniy Stepanov:


but these do not appear to have been replied.  A request is made during the conversation to file a bug and attach the files.
Comment 1 James Cloos 2011-06-28 06:43:13 UTC
I also posted an RFD patch to cache and match on the postscript name.

It, too, was ignored.
Comment 2 Paul Sladen 2011-06-28 06:48:05 UTC
James: do you have a link to your version of the patch too?
Comment 3 Behdad Esfahbod 2011-06-28 07:05:21 UTC
James, feel free to fork fontconfig.  I encourage that.  If and when distros pick up your tree, I'll hand you the fdo tree.  That's what I did to Keith afterall.  Don't sound apologetic!
Comment 4 Behdad Esfahbod 2011-06-28 07:09:43 UTC
Note that any patch to add this has to address the interaction between searching by postscript name and family name.  Just adding the postscript name to the pattern and putting it in a random place in the matcher is easy.  Making sense of how this feature is to be used is something I haven't seen anyone answering so far.
Comment 5 Behdad Esfahbod 2012-09-27 15:11:46 UTC
Akira, can you update this bug with your latest plans?
Comment 6 Akira TAGOH 2012-09-28 12:25:52 UTC
Well, still thinking how to address comment#4 though, the ideas I have so far is:

For cache:
* the change in FcFreeTypeQueryFace(): in case any fonts doesn't have TT_NAME_ID_PS_NAME, generate PS-compliant name from the family name as the printing libraries do.

For match:
* the change in FcNameParse(): we could add some code to guess if the string is more likely to be the family name or PostScript name from the existence of '-', ' ', and '-H', or '-V' as the suffix etc. set it to FC_FAMILY and/or FC_POSTSCRIPT_NAME. in some case, pre-lookup for that name may be a good idea? because it would be easy to write the mathing rules if we are sure either of the values points to the correct value. otherwise one who is responsible to maintain the rule needs to write the complicated (or duplicated) rules to match either of FC_FAMILY or FC_POSTSCRIPT_NAME then. or think about the syntax to achieve the rule like:

  If pat['family'] == 'Courier' or pat['postscript'] == 'Courier' then

* in FcNameParse() or in fcstr.c and fclang.c:

 * any function to guess the language from CMap if any.

 * a special comparison mode or attribute to ignore the suffix string like CMap. or should it be done with the above idea at pre-stage?

There should be more we need to think about, but just to share current idea.
Comment 7 Paul Sladen 2012-09-28 13:01:01 UTC
Akira, thanks for the update!

One thought I'd like to add, regarding the synthesis of missing data; is that when it comes to /debugging/ font-related issue, a large percentage of the (invalid) issues relate to sythesis and substitution occuring in FC or the toolkits.  It is often the difficulty in seeing past where the sythesis (or simplification) of data is occuring, that hampers the debugging.

Thus, it might arguably be better to cleanly /fail/ if a request is made for a TT_ attribute that doesn't exist (such as TT_NAME_ID_PS_NAME), than to return something that wasn't or isn't there.

Perhaps the printing issue highlighted (where synthesis of missing attributes is needed) could be covered with a helper function of something like ReturnUniqueNameAsPostscript().  Such a function() (or ENUM) could then return the TT_NAME_ID_PS_NAME if it exists, or make something up.  But in both cases, without obscuring the ability of an application /that cares/ to uniquely query or get the raw data.

Does that make sense?  I'm happy to expand on the above if not.
Comment 8 Akira TAGOH 2012-09-28 14:30:37 UTC
Well, I know there are some request of additional APIs like FcFontMatch and FcFontSort without the substitution. we should deal with it as a separate bug or RFE IMHO.
Comment 9 Akira TAGOH 2013-02-27 07:13:29 UTC

This repo contains the initial patch to propose a fix of this issue.
I didn't implement anything about CMap this time. because dealing with it in fontconfig may be overkill. applications who wants to use this feature should knows about it well. they could set the lang into FcPattern instead.

Please test. if there are no problems or concerns, I'll merge it into master.

Comment 10 Akira TAGOH 2013-03-19 09:37:50 UTC
I'll merge this change into master shortly if there are no objections.
Comment 11 Akira TAGOH 2013-03-21 07:39:06 UTC

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.