I have a small but annoying bug with Google Docs in Firefox with font rendering. Bug details fully described on Bugzilla, briefly -- in Google Docs (and Sheets) Firefox substitute two fonts: sans-serif 'Arial' and monospace 'Courier New' with one serif font (that is Bitstream Vera Serif in my case) (see picture below).
But this bug is absent in Chromium.
Temporary workariound -- disabling loading of the 49-sansserif.conf file (part of the fontconfig package) via removing symlink, fixes the bug.
So my questions is:
Does fontconfig mechanism is used by both browsers mentioned above?
Why Chromium recognized 'Arial' font as 'Arial' and 'Courier New' as 'Courier New', but Firefox not?
Yes, definitely. Bug was disappear after reinstaling ttf-bitstream-vera package, so mechanism of browsers interaction with the fontconfig is not affect to font rendering in this case.
Trivia: at this morning I decide to remove Bitstream Vera Serif font, with which Firefox substitute Arial and Courier New, I planned to see which font Firefox will use next, if Bitstream Vera Serif font will no exists in system. So I removed whole ttf-bitstream-vera package, and fonts in Google Docs began to render normally; moreover, after I installed ttf-bitstream-vera again, Google Docs works orrectly.
Related
I recently discovered this historical document, which purports to act as a test of UTF-8 encoding for whatever application displays it.
When I paste it into my terminal (iterm2), it loads the box drawings at the end beautifully (except for a couple at bottom right):
But in both Chrome and Firefox, they are crooked and clearly wrong:
It seems the difference has to do with the width of the rendered character: for example "╲" displays in my terminal as wide as other characters such as "a", but in the browser it displays wider.
Is this a deliberate choice, and if so what inspired it? If not, where is the right place to file a bug?
EDIT
Thanks to Tom Blodget's answer, I am now aware that fonts are an important consideration. I'll clarify:
In my screenshots above, Firefox and Chrome are using Courier as the monospace font, while the terminal is using Monaco. In both contexts, the font seems to apply as much to the box-drawing characters as to the ASCII ones: when I change the font, the appearance of the drawings changes as well as that of the surrounding text.
When I switch the terminal to either Courier or Courier New, it shows the box drawings equally well -- in some ways better!
When I switch either browser to Monaco, it still shows the box drawings wrong, again from characters apparently displaying at a wider-than-monospace width.
So it still seems like the browsers are doing something wrong.
When I go to dev tools, I see the entire test is one pre element. Several fonts are being used on my system. Everything looks okay except the hatch pattern on the right.
If I hack out all of the other text, the only font used is Consolas and it looks okay. I think it's down to which fonts you have, how the browser prioritizes them, especially when it has to use more than one, and (conjecture) two monospaced fonts need not have the same width.
A terminal is likely to be less adept at using multiple fonts, instead, using one fixed one or selecting one "best" match for the required characters.
[Google Chrome 72.0.3626.96 on Windows 10.]
This is likely the same as https://bugs.debian.org/981577
If you have any old fonts installed that don't cover the unicode BOX DRAWING range, it's likely that your browser is stitching them together. While each font itself might be monospace (each glyph is the same width within the font), the combination of fonts might not be monospace (because glyph width differs between fonts), which is why the alignment fails.
I found on my system that uninstalling the legacy Bitstream Vera font resolved the issue. (Bitstream Vera has been superseded by DejaVu Sans)
I need to dynamically make an SVG in my web app and to do so I'm making an SVG in Corel and modifying that template file in Node.js as needed. This works except for fonts. For this project I need my text as text, not curves, because I need to modify it. I'm using Century Gothic. I was using embedded fonts, but apparently those are no longer supported by Chrome and Edge. However, if I used linked fonts the file renders improperly if the user doesn't have the font installed. In either of these error cases the browser defaults to Times New Roman. What can I do to get Century Gothic to render in all browsers in an SVG?
You'll need a web font. Century Gothic is not freely available, so you have to either buy a license, or use an open source alternative. Muli seems to be considered as a good alternative. For how to use an external font provider, see this.
Default fonts on my site are defined in an external stylesheet as:
body { font-family: Arial; font-size:62.5%;}
This works fine in Windows and Mac.
To test my site I installed Linux Mint 13 (Mate) and loaded a selection of browsers from the Repository. I made two installations on separate PC’s. I left all browser settings as their defaults.
Firefox, Opera, Konqueror and Reconq displayed my pages as expected.
Web (Epiphany) overrides the default font style (i.e. it is not Arial) and also displays too large a font size.
Midori displays too large a font size. (installed in windows, midori displays the correct font size).
I believe Web (Epiphany) is designed principally for the GNOME desktop environment and maybe this is a factor or do I need to design differently for these two browsers to make them display the fonts correctly in Linux?
It seems that some distributions of Linux don't include the Arial font. I added Liberation Sans as an alternative font and this seems to be okay.
I don't understand however why some of the browsers didn't need this. Unless they include the font with the browser or accurately map some alternative?
I was searching through the net and couldn't find the exact answer.
How do browsers get the exact .ttf file for a font family specified in the css? Does it already have it in its code or does it pick from the user's system. I guess we can always specify the custom font files using the #font-face but what about the normal general fonts like arial etc?
The process is obviously different between browsers and operating systems, but in short, browsers pick the font from the system, and if it’s not installed, the font will be replaced with another similar font.
I am investigating the usage of SVG fonts in #font-face declaration. So far, only Safari 4 and Opera 10 seem to support it. Firefox 3.5 does not support it but there is a bug report but no fix has been supplied yet (though there are patches).
I am wondering, with #font-face support in major browsers, what is the advantage of using SVG font format in lieu of TTF/OTF/EOT formats? The only advantage I can glean from the discussion linked above was that you can add your own missing gylphs to fonts that do not support them yet.
Is there any other reason to specify SVG fonts in CSS?
It seems to be the only way to use web fonts on Mobile Safari. So that's a pretty big advantage if you're developing for iPhones and iPads. Font Squirrel's #font-face generator can create the appropriate SVG file and CSS syntax from any OpenType font.
The W3C states these advantages:
One disadvantage to the WebFont facility to date is that specifications such as [CSS2] do not require support of particular font formats. The result is that different implementations support different Web font formats, thereby making it difficult for Web site creators to post a single Web site using WebFonts that work across all user agents.
To provide a common font format for SVG that is guaranteed to be supported by all conforming SVG viewers, SVG provides a facility to define fonts in SVG. This facility is called SVG fonts.
SVG fonts can improve the semantic richness of graphics that represent text. For example, many company logos consist of the company name drawn artistically. In some cases, accessibility may be enhanced by expressing the logo as a series of glyphs in an SVG font and then rendering the logo as a 'text' element which references this font.
But the point of a common format doesn't really count because of the lacking browser support.
svg webfonts cannot work within an offline webapp. You can see an example here: http://straathof.acadnet.ca/beta2.2 Save this file to an idevice homepage, turn on airplane mode and open it. The svg fonts and the naming system used cause the font url to fail.
hopefully Apple fixes that soon.