/gbreve in current events

Craig Eliason

I'm seeing these ugly substitutions everywhere on the web. Is this because the type designs themselves neglected to include /gbreve, or is some character-set optimization for the web to blame?

Khaled Hosny

It is likely a mixture of both. Some fonts might not have this glyphs, or some websites might be using a limited glyph subset of the fonts to improve page load.

That is one of the problems with web fonts, you either include glyphs for characters you don’t need most of time and have worse page load speed, or include the common subset you need most of time and have bad fallback when you encounter the occasional character outside of the subset.

There is unicode-range thing, that allows one to load different fonts fo different characters and had the browser download the font only when it encounter a character in its range, but it is not supported in all browsers and some browsers or browser versions will load all the fonts regardless of actual use, and they are separate fonts so you can’t have any OpenType features across them, so no kerning for example.

James Puckett

It depends. Many news sites have style guides telling their staff which accents to use and normally they spell Erdoğan without the breve. But when the staff are just copy/pasting from twitter during a big news event mistakes happen. And there are many older fonts used on news sites that just don’t have glyph coverage beyond Western Europe because no client has come forward and paid for an expansion.

Ray Larabie

I wish font distributors would provide language options for their auto-generated web fonts. I often hear from customers asking why certain glyphs are missing from my web fonts and it usually ends up with me making them a custom subset using Fontsquirrel.

What if a web font converter, in the process of subsetting, replaced omitted accented letters with injected calt substitutions. In the case of ğ, it could inject an empty glyph sub by g followed by uni0306. Not as good as a proper ğ but maybe better than a fallback.

I have a feeling this might be a terrible idea.

Simon Cozens

Another potentially terrible idea would be for the JavaScript inserted into each web page by the web font hosting service to audit the page after load, and gather analytics on missing glyphs. (Email to user: "You just served up 3.6 million ğ's on page http://blah.blah.blah but the font Infill Sans didn't contain that glyph. Perhaps you need to change your subsetting options?" Alternatively: "...so I fixed it for you.")

Khaled Hosny

Google fonts supports subsetting fonts on the fly for a given string of text:
https://developers.google.com/fonts/docs/getting_started#optimizing_your_font_requests_beta

Jens Kutilek

Ray Larabie said:

What if a web font converter, in the process of subsetting, replaced omitted accented letters with injected calt substitutions. In the case of ğ, it could inject an empty glyph sub by g followed by uni0306. Not as good as a proper ğ but maybe better than a fallback.

I have a feeling this might be a terrible idea.

It’s all a question of doing the math ... a composite with 2 components takes up 24 bytes in the glyf table. Plus a loca entry, hmtx entry, kerning etc., amounting to 88 bytes of data that is saved by omitting the precomposed ğ. Introducing a ccmp feature to produce the ğ adds 212 bytes to a font, i.e. 124 bytes more than if we had just left the precomposed letter in the font.

(There is some overhead when a new feature is added, so if more letters were added in the ccmp feature, it would not take 212 bytes per each letter.)

Mike Duggan

was surprised at http://www.newyorker.com/news/news-desk/the-purge-begins-in-turkey

Hrant Հրանդ Փափազեան Papazian

Not to mention TypeDrawers itself...