Hilfe durchsuchen

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Many fonts don't render when Firefox opens local html file

  • 7 Antworten
  • 3 haben dieses Problem
  • 1277 Aufrufe
  • Letzte Antwort von Wizardgoat

more options

I'm using a 3rd-party program called Fontlist. It reads all fonts in the Windows fonts folder, and then uses a user-chosen line of text to generate an html file on the hard drive that shows the line of text displayed in each font. Since it's a 3rd-party program, I don't have control over it's html programming.

When the generated html file is browsed with Internet Explorer, all fonts display correctly. When browsing it with Firefox, perhaps half or more of the fonts have an ordinary-looking backup font substituted. I've not been able to discern any pattern as to what kind of font displays correctly or does not.

In researching the problem online, I saw a hint that setting security.fileuri.strict_origin_policy to false might fix the issue. I tried it, and it did not have any effect. Also, in the Fonts and Colors Advanced option, I've checked the box to let web pages choose their own fonts.

Might there be any other settings that would enable Firefox to render virtually any industry-standard font installed on the system? This can affect any html files from 3rd-party sources, not just Fontlist.

Ausgewählte Lösung

The css generated by Fontlist does not put quotes around font family names, including those with a numeric parameter. This explains part of the failures, but not all of them.

It's obvious that the html and css accepted by Internet Explorer is a lot more forgiving than FF.

The Fontlist developer would have to address this issue.

Diese Antwort im Kontext lesen 👍 0

Alle Antworten (7)

more options

In order to better assist you please update the browser to the most recent version: Update Firefox to the latest release

more options

I'd prefer to remain on FF 29 for now, unless there is a fix specifically for this problem in a later version. This is a general question about font rendering on recent FF versions.

more options

Hi Wizardgoat,

Please make sure that you are also not affected by the update that went out from Microsoft and fonts. http://windowsitpro.com/msrc/patch-tuesday-font-corruption-kb3013...

more options

Are all the fonts installed locally? Is there a CSS file used or style rules or possibly a font tag?

In that case it should work without problems provided all the fonts are a compatible true type version and not older bitmap or possible not supported Adobe fonts.

Note that on Windows fonts that belong to one font-family might be grouped and a specify font chosen based upon additional style rules like font-style and font-weight (Arial Black) and font-stretch (Arial Narrow).

more options

All the fonts in use are installed locally in the Windows Fonts folder. As it turns out, the generated HTML file causes numerous errors in the FF browser console. The HTML for each font contains a style keyword, and most of the errors are generated while parsing the font-family keyword within the style. For example, "Aldine401" parses okay, but "Aldine 721", containing a space, does not. However, that particular font is named that way in the Windows Fonts folder, so the software is just accurately picking up what's there. Apparently, Internet Explorer accommodates numerous font naming and content issues that FF does not.

more options

Do the font-family names that have a space have quotes around them?

  • font-family:"Aldine 721";

See also:

Font family names must either be given quoted as strings, or unquoted as a sequence of one or more identifiers. This means that punctuation characters and digits at the start of each token must be escaped in unquoted font family names.
more options

Ausgewählte Lösung

The css generated by Fontlist does not put quotes around font family names, including those with a numeric parameter. This explains part of the failures, but not all of them.

It's obvious that the html and css accepted by Internet Explorer is a lot more forgiving than FF.

The Fontlist developer would have to address this issue.