Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
F
fontconfig
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 153
    • Issues 153
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 19
    • Merge Requests 19
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • fontconfig
  • fontconfig
  • Issues
  • #273

Closed
Open
Opened Jan 13, 2021 by Jacko Dirks@jacko.dirksContributor

Why is there an internal FcConfig?

This discussion was probably held before somewhere, but I cannot seem to find it.

I am reading into this code, and I keep wondering: why is there an internal FcConfig (src/fccfg.c:41, static FcConfig *_fcConfig;)? If I understand correctly, there are currently two ways to work with a FcConfig. You can either do it explicitly, by doing something like

FcConfig* config = FcInitLoadConfigAndFonts();
...
FcBool success = FcConfigSubstitute(config, pat, FcMatchPattern);

Or implcitly

...
FcBool success = FcConfigSubstitute(NULL, pat, FcMatchPattern);

And the NULL will make sure that the internal FcConfig is created. I feel there are two problems with having both an internal and an external state. First of all, I feel it might be confusing to the user (it was confusing to me). Say, he has its own, custom config and at some point (due to copy-pasting or whatever) accidentally calls a function with config == NULL. Now, Fontconfig silently creates its internal state and finishes correctly. All code works like a charm, but the user gets unexpected results, which might be quite hard to debug.

My second feeling is with the complexity. Because the internal state needs to be checked, managed and threadsafe, fccfg.c is pretty complex. If the user has to handle the FcConfig*, this complexity would probably reduce.

Removing this internal FcConfig will break compatibility, that I understand. Are there other reasons why keeping the internal one is preferred over removing it?

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: fontconfig/fontconfig#273