Many fonts don't render when Firefox opens local html file
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.
Keazen oplossing
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.
Dit antwurd yn kontekst lêze 👍 0Alle antwurden (7)
In order to better assist you please update the browser to the most recent version: Update Firefox to the latest release
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.
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...
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).
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.
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.
Keazen oplossing
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.