Box drawing characters don't fit together in WOFF2 version

[nubok]

I decided that I wanted to draw some boxes using the box drawing characters (https://en.wikipedia.org/wiki/Box-drawing_character) that Source Code Pro has to offer (this to be working is necessary for my intended application). Unluckily it looks like the box drawing characters "don't fit together" in the WOFF2 version of Source Code Pro, see the rendering of the following codepen:

http://codepen.io/nubok/pen/mPKMNw

I tested this in Google Chrome 49.0.2623.112 m and Mozilla Firefox 45.0.2 EME-free (here the artifacts are particularly marked). Note that Internet Explorer 11 does not support WOFF2 fonts.

In the WOFF version the rendering is correct in Mozilla Firefox and Internet Explorer 11. In Google Chrome there are still small artifacts even in the WOFF version of Source Code Pro. It is thus not clear whether this is a bug in Source Code Pro or Google Chrome.

[frankrolf]

This seems to be about the space glyph – could it be narrower in the WOFF2 version?
If it is, it is definitely a bug (but not one involving Box Drawing Characters).
About rendering artifacts in Chrome: this has to do with the rasterization engine, unfortunately there is nothing the font can do about that.

[nubok]

I created a new codepen that contains all five format versions of the Source Code Pro font: http://codepen.io/nubok/pen/VadyRj

The three browsers that I tested are again IE11, Firefox 45 and Chrome 49:

EOT version (will only work in IE11): contains bug!
WOFF2 version (will only work in Chrome and Firefox): contains bug!
WOFF version: no bug
OpenType version: no bug
TrueType version: contains bug!

Now the naming (SourceCodePro-Regular.ttf.woff2, SourceCodePro-Regular.otf.woff) implies that the WOFF2 version is derived from the ttf version, but the WOFF version is derived from the OpenType version (the latter is free of this bug). I hope this helps you to track down this bug...

[miguelsousa]

@nubok could you be more specific about what you mean by artifacts?
I'm using Chrome Mac 49.0.2623.112 (64-bit) and as far as I can tell everything is rendering fine. Firefox Mac 45.0.2 renders the same.

The WOFF(2) files are basically wrapped OTF/TTF fonts. If you're seeing differences between these they have to be caused by browsers' bugs and/or lack of support for some of the formats.

[nubok]

OK, I created some screenshots in Chrome and Firefox, Windows 7: I marked the "obvious" artifacts in red (which this bug is about). Additionally I added markings in blue that for artifacts are non-obvious (this could be a bug in the font file or in the font rendering code). Zoom to 400% in an image processing software and you'll see these "blue" artifacts clearly. I also added a purple marking for an artifact that is somewhere between.

First screenshot is from Chrome, second from Firefox

[miguelsousa]

I created some screenshots in [...] Windows 7.

That explains it all. Windows rendering uses the hinting information in the fonts, whereas Mac doesn't, and the glyphs circled in red will need some tweaking to their hints. The issue is more pronounced in the TrueType font (and the WOFF2 font which is made from it).

[nubok]

This doesn't seem to be a Windows-only problem: The following screenshot were created using browsershots.org, documenting that font hinting is also used under common GNU/Linux distributions

Debian 6.0, Chrome 45.0:

Debian 6.0, Firefox 44.0:

Ubuntu 12.04, Chrome 49.0:

[yurikhan]

On Fontconfig/X11/GNU/Linux, font hinting can be configured as None, Slight, Medium or Full. In screenshots above, Debian 6.0 seems to be configured for full hinting while Ubuntu 12.04 seems to use slight hinting. The artifacts are much less pronounced with slight hinting.

[frankrolf]

We have identified a hinting bug in various of the Box Drawing Characters, to be fixed soon.
This concerns the issue marked red by @nubok.

About the pink/blue marks: those visual glitches are caused by the decisions the rasterization engine makes for overlapping glyphs. There is nothing that can be done to the font to fix that (other than using different rasterization).

Thanks for reporting!

[miguelsousa]

@nubok we're working on a new release that will fix this issue in the TTF fonts (and WOFF/WOFF2 TTF-based files). In the meantime, there are WOFF2 files made from OTF fonts that don't have this issue. Their file size is a bit larger, but not by much. Their functionality is the same.