Posts tagged ‘web fonts’


Fixing Wordpress’s problem of fake bolds and italics

11.06.2021

I haven’t been able to find anything on this bug online, but it’s very common.
   As far as I can recall, all of our online publications that use Wordpress have themes designed or modified by yours truly. However, Lucire Rouge has a mostly bought-in theme, where my changes have been limited to a couple of CSS rules. The theme developer actually came in and helped us with a few modifications, which shows the extent to which he does follow-up for paying customers.
   But there was one thing he was never able to crack, and I don’t think it’s his fault, since it happens on a lot of websites, including Medinge Group’s (also a theme I did not design, though I did earlier ones). On both these sites, there were no bolds and italics. There still aren’t on Medinge’s.
   There are <strong> and <em> codes in there, but the bolding and obliquing are done by the browser. The font files actually aren’t loaded, so what we see are false bolds (the browser attempts to “overprint” the roman, duplicating the outline and shifting it marginally to give the illusion of a heavier typeface) and obliques, not italics (it’s the roman file pushed over 15 degrees or so). The former is particularly bad, as the outlines clash, and the result can be hollow glyphs, something that any font developer will know when one outline winds up accidentally on top of another in Fontographer or Fontlab.
   These Wordpress themes rely on Google Fonts (another sin, in my opinion) so I don’t know if the fault lies with Google or Wordpress, or the developer. If Wordpress does indeed power 70 per cent of websites, then I have to say the bug is awfully common, and I probably do see it on a very high percentage of visited sites.
   The themes allow us to select the font family, but the selection only calls a single font file from the family.


Above: A graphic clipping text from Lucire Rouge that I sent to the developer.

   The solution, as I discovered after months of toing and froing with Lucire Rouge’s theme dev, was to do your own font-linking rules in the CSS file and upload the fonts themselves to the relevant directory on the server. I must note publicly the ‘months’ were not his fault, but due to my own delay. I should not expect computer programmers to be typographers, either.
   It is something that one needs to watch out for, as the fake bolds and italics are horrible to look at, and must look amateur, even to the non-professional.



Above: Fixed at last by yours truly.

Tags: , , , , , , , , , , , , ,
Posted in design, internet, media, publishing, technology | No Comments »


Cyberfox day two, or, the day it, too, stopped displaying text

24.12.2014

Rather than repeat the story in new words, here is a draft of the post that was sent to Cyberfox’s support forum.

The short story: Cyberfox no longer displays text as of this morning after working well for its first evening yesterday after installation for the first time. Glyphs that are not from a @font-face linked font will not show, so if a page is calling fonts from the system, the browser displays blank text. Nothing happened overnight. I switched the machine off, and when I switched it on again, Cyberfox exhibits this behaviour.
   The long story: in 2011, Firefox had a bug which meant there was no backward compatibility with PostScript Type 1 fonts (https://bugzilla.mozilla.org/show_bug.cgi?id=628091). This is very similar to that except the text areas are blank, rather than filled with squares or hex codes.
   About two Firefox versions ago (I am guessing v. 32), the browser stopped showing text. I switched to Waterfox, which lasted one more version before it, too, stopped showing text. I downloaded Cyberfox last night and was truly pleased that here was a Firefox-based browser that actually worked. Text displayed as normal, and these were my Type 1, TrueType and OpenType fonts. To top it off, Cyberfox’s rasterizer and the way it handled sub-pixel rendering was superior to that of the other two browsers (see my blog post at http://jackyan.com/blog/2014/12/switching-to-cyberfox-after-waterfox-and-firefox-stopped-displaying-text/ for two screen shots of the type). Naturally, I was over the moon and made Cyberfox my default.
   Just to be on the safe side, I turned off hardware acceleration as when I posted the above bug to Mozilla Support, I was told that that could be a culprit. I made no change to OMTC.
   Today, as mentioned, Cyberfox has become just another Firefox where no text is displayed. But the really weird thing is that the typography, for the type that does show, is identical to Firefox and Cyberfox: the superior rendering is gone.
   Also, I’ve since altered the font family I use as a default for Windows displays to OpenType (I work in fonts), so there should no longer be an backward-incompatibility issue. Nvidia updated one of its drivers today, so I let that happen, and confirmed that all my drivers are up to date.
   Reinstallation (while keeping profile data) actually fixes everything: the type is back, rasterized more sharply,
   I was using Australis as the theme but have since gone back to classic.
   I’d be grateful for any light you can shed on this as I’m keen to stay within the Firefox 64-bit family. Whatever makes Cyberfox display better than the other two immediately after installation (though not after a reboot) solves this major problem of no type appearing.

   The different rendering method is the fix. The questions are: why does Cyberfox render type differently if it’s Mozilla Firefox-based? And why does rebooting my computer change this setting?

Tags: , , , , , , , , , ,
Posted in internet, technology, typography | No Comments »


Sounds familiar? Works on all browsers, except for IE8

29.12.2013

I’m sure this is familiar to anyone who has done web development. Lucire has a new home page and the tests show:

Firefox on Mac, Windows, Ubuntu: OK
Chromium on Windows: OK
IE9 and IE10: OK
Safari on Mac OS X, Iphone and Ipad: OK
Dolphin on Android: OK
A really old version of Seamonkey we had at the office: OK
IE8 on Windows XP: not OK

   All the roman text is showing as bold, and as usual this is not a bug that I can find reported (I even looked on Google). I have found bugs about italics showing instead of romans caused by installation issues, which don’t apply here as we are using webfonts. There is another common bug about faux bolds and italics, but I’m having the opposite problem: a true bold showing up where romans should (and bold italic instead of italic).
   Annoyingly, this bug may have been with us for over a month—when we changed our body type.
   Given that IE8 was never a good browser to begin with, and anyone who cared about their surfing experiences would not have touched it, it makes me wonder if we should invest any more time trying to get things to work. It does mean that just under a tenth of our readers (or is it just over a fifth? Depends who you want to believe) won’t be able to experience our website the way we intended. I realize older IEs are more commonplace in China but our readership this year in the Middle Kingdom had dipped.
   The good news, in some ways, is Microsoft’s announcement that it will cease support for the venerable XP platform in 2014. If trends continue based on the first set of stats, the well obsolete IE8 should dip below the five per cent mark this coming year.
   It’s a toss-up between leaving it and fixing it, given that we don’t know why IE8 is misinterpreting the linked fonts (theory: are the character sets of the roman and italic too large for it to handle?). If we knew, then fixing things would be a no-brainer. (Clues are welcome!)

Tags: , , , , , , , , , , , , , ,
Posted in business, design, internet, media, New Zealand, technology, typography | 2 Comments »