fontconfig warning: “/etc/fonts/fonts.conf”, line 100: unknown “element blank” The 2019 Stack Overflow Developer Survey Results Are In“tar: unrecognized option --warning” during 'apt-get install'How to fix Fontconfig errorHow do I figure out which font file is chosen for a system generic font alias?Why are some apt-get-installed fonts being ignored by fc-list, xfontsel, etc?Reload settings in /etc/fonts/conf.dTaking 30 seconds longer to boot after upgrade from jessie to stretchHow to match multiple font names with a single <match> element?Adding a custom font to fontconfigRemoving fonts from fontconfig <match> resultsBroken fonts after upgrading Firefox ESR to latest Firefox
How to type this arrow in math mode?
Multiply Two Integer Polynomials
What do hard-Brexiteers want with respect to the Irish border?
Why isn't the circumferential light around the M87 black hole's event horizon symmetric?
For what reasons would an animal species NOT cross a *horizontal* land bridge?
Can one be advised by a professor who is very far away?
Identify boardgame from Big movie
slides for 30min~1hr skype tenure track application interview
Why do we hear so much about the Trump administration deciding to impose and then remove tariffs?
If I score a critical hit on an 18 or higher, what are my chances of getting a critical hit if I roll 3d20?
Can we generate random numbers using irrational numbers like π and e?
Worn-tile Scrabble
Output the Arecibo Message
What is the meaning of Triage in Cybersec world?
How are circuits which use complex ICs normally simulated?
Shouldn't "much" here be used instead of "more"?
Delete all lines which don't have n characters before delimiter
Aging parents with no investments
Can someone be penalized for an "unlawful" act if no penalty is specified?
Is this app Icon Browser Safe/Legit?
What is the closest word meaning "respect for time / mindful"
Is there a symbol for a right arrow with a square in the middle?
What are the motivations for publishing new editions of an existing textbook, beyond new discoveries in a field?
Protecting Dualbooting Windows from dangerous code (like rm -rf)
fontconfig warning: “/etc/fonts/fonts.conf”, line 100: unknown “element blank”
The 2019 Stack Overflow Developer Survey Results Are In“tar: unrecognized option --warning” during 'apt-get install'How to fix Fontconfig errorHow do I figure out which font file is chosen for a system generic font alias?Why are some apt-get-installed fonts being ignored by fc-list, xfontsel, etc?Reload settings in /etc/fonts/conf.dTaking 30 seconds longer to boot after upgrade from jessie to stretchHow to match multiple font names with a single <match> element?Adding a custom font to fontconfigRemoving fonts from fontconfig <match> resultsBroken fonts after upgrading Firefox ESR to latest Firefox
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
Getting this error on my vps server:
fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"
This is the file:
https://pastebin.com/VqcSgJ9x
How to fix it?
linux debian error-handling fontconfig
add a comment |
Getting this error on my vps server:
fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"
This is the file:
https://pastebin.com/VqcSgJ9x
How to fix it?
linux debian error-handling fontconfig
Getting the same error when trying to launch headless Chrome in a docker container - still digging.
– Jacob Thomason
Mar 8 at 23:05
add a comment |
Getting this error on my vps server:
fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"
This is the file:
https://pastebin.com/VqcSgJ9x
How to fix it?
linux debian error-handling fontconfig
Getting this error on my vps server:
fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"
This is the file:
https://pastebin.com/VqcSgJ9x
How to fix it?
linux debian error-handling fontconfig
linux debian error-handling fontconfig
edited Mar 5 at 7:26
Ned St
asked Mar 4 at 19:15
Ned StNed St
112
112
Getting the same error when trying to launch headless Chrome in a docker container - still digging.
– Jacob Thomason
Mar 8 at 23:05
add a comment |
Getting the same error when trying to launch headless Chrome in a docker container - still digging.
– Jacob Thomason
Mar 8 at 23:05
Getting the same error when trying to launch headless Chrome in a docker container - still digging.
– Jacob Thomason
Mar 8 at 23:05
Getting the same error when trying to launch headless Chrome in a docker container - still digging.
– Jacob Thomason
Mar 8 at 23:05
add a comment |
1 Answer
1
active
oldest
votes
TL;DR: You should probably just ignore this warning.
If you feel a little bold you might try removing the <blank>...</blank>
section from your /etc/fonts/fonts.conf
file (maybe making a back-up first if you're not feeling quite so foolhardy). When I tried this, the warning went away. However, you may have noticed a scary looking message at the top of the file saying: DO NOT EDIT THIS FILE. IT WILL BE REPLACED WHEN FONTCONFIG IS UPDATED. LOCAL CHANGES BELONG IN 'local.conf'.
So this was probably not the right solution. (If you wondering why I did it anyways: I didn't see a local.conf
, was too lazy to read the fine manuals, and figured that my hack getting overwritten was more like a feature than a bug anyway since maintainers would likely publish an official solution later anyway -- besides I wanted to learn.)
OK, let's back up now. This is (unsurprisingly) related to fontconfig
's <blank>
element, whose usage is described in the fontconfig docs as
<blank>
Fonts often include "broken" glyphs which appear in the encoding but are drawn as blanks on the screen. Within the element, place each Unicode characters which is supposed to be blank in an element. Characters outside of this set which are drawn as blank will be elided from the set of characters supported by the font.
The docs suggest that there's nothing with having these options defined. Also, they are specified in the DTD.
However, you may have noticed a related fontconfig API called FcBlanks
(emphasis mine):
An FcBlanks object holds a list of Unicode chars which are expected to be blank when drawn. When scanning new fonts, any glyphs which are empty and not in this list will be assumed to be broken and not placed in the FcCharSet associated with the font. This provides a significantly more accurate CharSet for applications.
FcBlanks is deprecated and should not be used in newly written code. It is still accepted by some functions for compatibility with older code but will be removed in the future.
This suggests to me that they are allowed in the configuration file for compatibility but are not intended to be used any more.
Without more information I'm not sure in what context you're seeing this warning, however, lately I've seen it a lot with chromium / electron / Google Chrome. Taking a peek at chromium's external/fontconfig
's commit history I noticed:
commit dc8326d3f116bb2a1425aa68660a332e351b6cb4
Author: Behdad Esfahbod <behdad@behdad.org>
Date: Fri Sep 15 01:20:56 2017 -0400
[fc-query] Remove --ignore-blanks / -b
Blanks are the new black, err, dead!
...
commit 8b46a518bda8ecb3c5e2dfb0c1e5fda99e40aa3e
Author: Behdad Esfahbod <behdad@behdad.org>
Date: Tue Sep 12 17:08:08 2017 -0400
Update documentation for removal of blanks
Patch from Jerry Casiano.
You can also see this in the 2.12.91 change log.
I suspect that the warning started appearing around the time chromium updated to this (or newer) version of fontconfig. It looks like that happened around June 2018 / chromium 69. Peeking at the DEPS
file and third_party/fontconfig/BUILD.gn
suggests that ba206df9b9a7ca300265f650842c1459ff7c634a
(a couple commits newer than 2.13.1) is used for embedded builds meanwhile ChromeOS and Linux will use "the system version." If I understand correctly that means that when building chromium on/for Linux, build/install-build-deps.sh
would have installed the latest libfontconfig1
package provided by the distribution (in my case 2.11.0-6.7+b1). At this point I looked around a little bit for more information about how my build of chromium was compiled, specifically, but then I lost interest. I assume the maintainers try to keep it in step with the rest of the distribution.
In the end, if I'm not terribly mistaken, all this message really means is that the configuration file contains some information (other than comments) that will not be used by the program that output it.
See also:
- https://askubuntu.com/questions/1018056/font-config-error-launching-google-chrome-stable-from-the-command-line-on-14-04#1018057
- https://github.com/felixrieseberg/ember-electron/issues/386
New contributor
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504335%2ffontconfig-warning-etc-fonts-fonts-conf-line-100-unknown-element-blank%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
TL;DR: You should probably just ignore this warning.
If you feel a little bold you might try removing the <blank>...</blank>
section from your /etc/fonts/fonts.conf
file (maybe making a back-up first if you're not feeling quite so foolhardy). When I tried this, the warning went away. However, you may have noticed a scary looking message at the top of the file saying: DO NOT EDIT THIS FILE. IT WILL BE REPLACED WHEN FONTCONFIG IS UPDATED. LOCAL CHANGES BELONG IN 'local.conf'.
So this was probably not the right solution. (If you wondering why I did it anyways: I didn't see a local.conf
, was too lazy to read the fine manuals, and figured that my hack getting overwritten was more like a feature than a bug anyway since maintainers would likely publish an official solution later anyway -- besides I wanted to learn.)
OK, let's back up now. This is (unsurprisingly) related to fontconfig
's <blank>
element, whose usage is described in the fontconfig docs as
<blank>
Fonts often include "broken" glyphs which appear in the encoding but are drawn as blanks on the screen. Within the element, place each Unicode characters which is supposed to be blank in an element. Characters outside of this set which are drawn as blank will be elided from the set of characters supported by the font.
The docs suggest that there's nothing with having these options defined. Also, they are specified in the DTD.
However, you may have noticed a related fontconfig API called FcBlanks
(emphasis mine):
An FcBlanks object holds a list of Unicode chars which are expected to be blank when drawn. When scanning new fonts, any glyphs which are empty and not in this list will be assumed to be broken and not placed in the FcCharSet associated with the font. This provides a significantly more accurate CharSet for applications.
FcBlanks is deprecated and should not be used in newly written code. It is still accepted by some functions for compatibility with older code but will be removed in the future.
This suggests to me that they are allowed in the configuration file for compatibility but are not intended to be used any more.
Without more information I'm not sure in what context you're seeing this warning, however, lately I've seen it a lot with chromium / electron / Google Chrome. Taking a peek at chromium's external/fontconfig
's commit history I noticed:
commit dc8326d3f116bb2a1425aa68660a332e351b6cb4
Author: Behdad Esfahbod <behdad@behdad.org>
Date: Fri Sep 15 01:20:56 2017 -0400
[fc-query] Remove --ignore-blanks / -b
Blanks are the new black, err, dead!
...
commit 8b46a518bda8ecb3c5e2dfb0c1e5fda99e40aa3e
Author: Behdad Esfahbod <behdad@behdad.org>
Date: Tue Sep 12 17:08:08 2017 -0400
Update documentation for removal of blanks
Patch from Jerry Casiano.
You can also see this in the 2.12.91 change log.
I suspect that the warning started appearing around the time chromium updated to this (or newer) version of fontconfig. It looks like that happened around June 2018 / chromium 69. Peeking at the DEPS
file and third_party/fontconfig/BUILD.gn
suggests that ba206df9b9a7ca300265f650842c1459ff7c634a
(a couple commits newer than 2.13.1) is used for embedded builds meanwhile ChromeOS and Linux will use "the system version." If I understand correctly that means that when building chromium on/for Linux, build/install-build-deps.sh
would have installed the latest libfontconfig1
package provided by the distribution (in my case 2.11.0-6.7+b1). At this point I looked around a little bit for more information about how my build of chromium was compiled, specifically, but then I lost interest. I assume the maintainers try to keep it in step with the rest of the distribution.
In the end, if I'm not terribly mistaken, all this message really means is that the configuration file contains some information (other than comments) that will not be used by the program that output it.
See also:
- https://askubuntu.com/questions/1018056/font-config-error-launching-google-chrome-stable-from-the-command-line-on-14-04#1018057
- https://github.com/felixrieseberg/ember-electron/issues/386
New contributor
add a comment |
TL;DR: You should probably just ignore this warning.
If you feel a little bold you might try removing the <blank>...</blank>
section from your /etc/fonts/fonts.conf
file (maybe making a back-up first if you're not feeling quite so foolhardy). When I tried this, the warning went away. However, you may have noticed a scary looking message at the top of the file saying: DO NOT EDIT THIS FILE. IT WILL BE REPLACED WHEN FONTCONFIG IS UPDATED. LOCAL CHANGES BELONG IN 'local.conf'.
So this was probably not the right solution. (If you wondering why I did it anyways: I didn't see a local.conf
, was too lazy to read the fine manuals, and figured that my hack getting overwritten was more like a feature than a bug anyway since maintainers would likely publish an official solution later anyway -- besides I wanted to learn.)
OK, let's back up now. This is (unsurprisingly) related to fontconfig
's <blank>
element, whose usage is described in the fontconfig docs as
<blank>
Fonts often include "broken" glyphs which appear in the encoding but are drawn as blanks on the screen. Within the element, place each Unicode characters which is supposed to be blank in an element. Characters outside of this set which are drawn as blank will be elided from the set of characters supported by the font.
The docs suggest that there's nothing with having these options defined. Also, they are specified in the DTD.
However, you may have noticed a related fontconfig API called FcBlanks
(emphasis mine):
An FcBlanks object holds a list of Unicode chars which are expected to be blank when drawn. When scanning new fonts, any glyphs which are empty and not in this list will be assumed to be broken and not placed in the FcCharSet associated with the font. This provides a significantly more accurate CharSet for applications.
FcBlanks is deprecated and should not be used in newly written code. It is still accepted by some functions for compatibility with older code but will be removed in the future.
This suggests to me that they are allowed in the configuration file for compatibility but are not intended to be used any more.
Without more information I'm not sure in what context you're seeing this warning, however, lately I've seen it a lot with chromium / electron / Google Chrome. Taking a peek at chromium's external/fontconfig
's commit history I noticed:
commit dc8326d3f116bb2a1425aa68660a332e351b6cb4
Author: Behdad Esfahbod <behdad@behdad.org>
Date: Fri Sep 15 01:20:56 2017 -0400
[fc-query] Remove --ignore-blanks / -b
Blanks are the new black, err, dead!
...
commit 8b46a518bda8ecb3c5e2dfb0c1e5fda99e40aa3e
Author: Behdad Esfahbod <behdad@behdad.org>
Date: Tue Sep 12 17:08:08 2017 -0400
Update documentation for removal of blanks
Patch from Jerry Casiano.
You can also see this in the 2.12.91 change log.
I suspect that the warning started appearing around the time chromium updated to this (or newer) version of fontconfig. It looks like that happened around June 2018 / chromium 69. Peeking at the DEPS
file and third_party/fontconfig/BUILD.gn
suggests that ba206df9b9a7ca300265f650842c1459ff7c634a
(a couple commits newer than 2.13.1) is used for embedded builds meanwhile ChromeOS and Linux will use "the system version." If I understand correctly that means that when building chromium on/for Linux, build/install-build-deps.sh
would have installed the latest libfontconfig1
package provided by the distribution (in my case 2.11.0-6.7+b1). At this point I looked around a little bit for more information about how my build of chromium was compiled, specifically, but then I lost interest. I assume the maintainers try to keep it in step with the rest of the distribution.
In the end, if I'm not terribly mistaken, all this message really means is that the configuration file contains some information (other than comments) that will not be used by the program that output it.
See also:
- https://askubuntu.com/questions/1018056/font-config-error-launching-google-chrome-stable-from-the-command-line-on-14-04#1018057
- https://github.com/felixrieseberg/ember-electron/issues/386
New contributor
add a comment |
TL;DR: You should probably just ignore this warning.
If you feel a little bold you might try removing the <blank>...</blank>
section from your /etc/fonts/fonts.conf
file (maybe making a back-up first if you're not feeling quite so foolhardy). When I tried this, the warning went away. However, you may have noticed a scary looking message at the top of the file saying: DO NOT EDIT THIS FILE. IT WILL BE REPLACED WHEN FONTCONFIG IS UPDATED. LOCAL CHANGES BELONG IN 'local.conf'.
So this was probably not the right solution. (If you wondering why I did it anyways: I didn't see a local.conf
, was too lazy to read the fine manuals, and figured that my hack getting overwritten was more like a feature than a bug anyway since maintainers would likely publish an official solution later anyway -- besides I wanted to learn.)
OK, let's back up now. This is (unsurprisingly) related to fontconfig
's <blank>
element, whose usage is described in the fontconfig docs as
<blank>
Fonts often include "broken" glyphs which appear in the encoding but are drawn as blanks on the screen. Within the element, place each Unicode characters which is supposed to be blank in an element. Characters outside of this set which are drawn as blank will be elided from the set of characters supported by the font.
The docs suggest that there's nothing with having these options defined. Also, they are specified in the DTD.
However, you may have noticed a related fontconfig API called FcBlanks
(emphasis mine):
An FcBlanks object holds a list of Unicode chars which are expected to be blank when drawn. When scanning new fonts, any glyphs which are empty and not in this list will be assumed to be broken and not placed in the FcCharSet associated with the font. This provides a significantly more accurate CharSet for applications.
FcBlanks is deprecated and should not be used in newly written code. It is still accepted by some functions for compatibility with older code but will be removed in the future.
This suggests to me that they are allowed in the configuration file for compatibility but are not intended to be used any more.
Without more information I'm not sure in what context you're seeing this warning, however, lately I've seen it a lot with chromium / electron / Google Chrome. Taking a peek at chromium's external/fontconfig
's commit history I noticed:
commit dc8326d3f116bb2a1425aa68660a332e351b6cb4
Author: Behdad Esfahbod <behdad@behdad.org>
Date: Fri Sep 15 01:20:56 2017 -0400
[fc-query] Remove --ignore-blanks / -b
Blanks are the new black, err, dead!
...
commit 8b46a518bda8ecb3c5e2dfb0c1e5fda99e40aa3e
Author: Behdad Esfahbod <behdad@behdad.org>
Date: Tue Sep 12 17:08:08 2017 -0400
Update documentation for removal of blanks
Patch from Jerry Casiano.
You can also see this in the 2.12.91 change log.
I suspect that the warning started appearing around the time chromium updated to this (or newer) version of fontconfig. It looks like that happened around June 2018 / chromium 69. Peeking at the DEPS
file and third_party/fontconfig/BUILD.gn
suggests that ba206df9b9a7ca300265f650842c1459ff7c634a
(a couple commits newer than 2.13.1) is used for embedded builds meanwhile ChromeOS and Linux will use "the system version." If I understand correctly that means that when building chromium on/for Linux, build/install-build-deps.sh
would have installed the latest libfontconfig1
package provided by the distribution (in my case 2.11.0-6.7+b1). At this point I looked around a little bit for more information about how my build of chromium was compiled, specifically, but then I lost interest. I assume the maintainers try to keep it in step with the rest of the distribution.
In the end, if I'm not terribly mistaken, all this message really means is that the configuration file contains some information (other than comments) that will not be used by the program that output it.
See also:
- https://askubuntu.com/questions/1018056/font-config-error-launching-google-chrome-stable-from-the-command-line-on-14-04#1018057
- https://github.com/felixrieseberg/ember-electron/issues/386
New contributor
TL;DR: You should probably just ignore this warning.
If you feel a little bold you might try removing the <blank>...</blank>
section from your /etc/fonts/fonts.conf
file (maybe making a back-up first if you're not feeling quite so foolhardy). When I tried this, the warning went away. However, you may have noticed a scary looking message at the top of the file saying: DO NOT EDIT THIS FILE. IT WILL BE REPLACED WHEN FONTCONFIG IS UPDATED. LOCAL CHANGES BELONG IN 'local.conf'.
So this was probably not the right solution. (If you wondering why I did it anyways: I didn't see a local.conf
, was too lazy to read the fine manuals, and figured that my hack getting overwritten was more like a feature than a bug anyway since maintainers would likely publish an official solution later anyway -- besides I wanted to learn.)
OK, let's back up now. This is (unsurprisingly) related to fontconfig
's <blank>
element, whose usage is described in the fontconfig docs as
<blank>
Fonts often include "broken" glyphs which appear in the encoding but are drawn as blanks on the screen. Within the element, place each Unicode characters which is supposed to be blank in an element. Characters outside of this set which are drawn as blank will be elided from the set of characters supported by the font.
The docs suggest that there's nothing with having these options defined. Also, they are specified in the DTD.
However, you may have noticed a related fontconfig API called FcBlanks
(emphasis mine):
An FcBlanks object holds a list of Unicode chars which are expected to be blank when drawn. When scanning new fonts, any glyphs which are empty and not in this list will be assumed to be broken and not placed in the FcCharSet associated with the font. This provides a significantly more accurate CharSet for applications.
FcBlanks is deprecated and should not be used in newly written code. It is still accepted by some functions for compatibility with older code but will be removed in the future.
This suggests to me that they are allowed in the configuration file for compatibility but are not intended to be used any more.
Without more information I'm not sure in what context you're seeing this warning, however, lately I've seen it a lot with chromium / electron / Google Chrome. Taking a peek at chromium's external/fontconfig
's commit history I noticed:
commit dc8326d3f116bb2a1425aa68660a332e351b6cb4
Author: Behdad Esfahbod <behdad@behdad.org>
Date: Fri Sep 15 01:20:56 2017 -0400
[fc-query] Remove --ignore-blanks / -b
Blanks are the new black, err, dead!
...
commit 8b46a518bda8ecb3c5e2dfb0c1e5fda99e40aa3e
Author: Behdad Esfahbod <behdad@behdad.org>
Date: Tue Sep 12 17:08:08 2017 -0400
Update documentation for removal of blanks
Patch from Jerry Casiano.
You can also see this in the 2.12.91 change log.
I suspect that the warning started appearing around the time chromium updated to this (or newer) version of fontconfig. It looks like that happened around June 2018 / chromium 69. Peeking at the DEPS
file and third_party/fontconfig/BUILD.gn
suggests that ba206df9b9a7ca300265f650842c1459ff7c634a
(a couple commits newer than 2.13.1) is used for embedded builds meanwhile ChromeOS and Linux will use "the system version." If I understand correctly that means that when building chromium on/for Linux, build/install-build-deps.sh
would have installed the latest libfontconfig1
package provided by the distribution (in my case 2.11.0-6.7+b1). At this point I looked around a little bit for more information about how my build of chromium was compiled, specifically, but then I lost interest. I assume the maintainers try to keep it in step with the rest of the distribution.
In the end, if I'm not terribly mistaken, all this message really means is that the configuration file contains some information (other than comments) that will not be used by the program that output it.
See also:
- https://askubuntu.com/questions/1018056/font-config-error-launching-google-chrome-stable-from-the-command-line-on-14-04#1018057
- https://github.com/felixrieseberg/ember-electron/issues/386
New contributor
New contributor
answered 2 days ago
iX3iX3
1034
1034
New contributor
New contributor
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504335%2ffontconfig-warning-etc-fonts-fonts-conf-line-100-unknown-element-blank%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
-debian, error-handling, fontconfig, linux
Getting the same error when trying to launch headless Chrome in a docker container - still digging.
– Jacob Thomason
Mar 8 at 23:05