Rendering issue on Windows browser - counters closing

Adam Ladd

Hi All,

A client is using a few weights from one of my families on a large, consumer-facing website and the semibold weight is rendering very poorly on Windows browsers (looks fine on Mac browsers). I believe it was purchased through one of my vendors and they were using the .otf files, and then also tried woff files, but it didn't help. Here is a screenshot they sent (Mac browser on top, Windows browser with font at 22px on bottom).



I've got another thread going on the Glyphs forum https://forum.glyphsapp.com/t/rendering-issue-on-windows-browsers/12956/11 and am actively trying to apply and tweak some TTFautohinting parameter settings and testing on a borrowed Windows machine, but I can't get these same poor results.

Here is a screenshot from the Windows computer of a test of the original font on the left using the Cyreal.org testing page (tested with Chrome and IE), and on the right is the clients website currently using the font, as seen on a Windows browser. The lighter weights are ok, but the heavier one closes up in the counters (as seen in the word "features" on the right, compared to "make" in the test page on left).



They noted: "We’ve also narrowed it down a bit and it seems like the issue seems more prominent on Window browsers roughly 1366x768 resolution or lower (at 100%)." 

I've used the autohint option at export, but don't have experience in hinting beyond that, so I'm stumped right now and have not had an issue like this pop up before. So any help or advice is greatly appreciated, thanks!

Viktor Rubenko

rendering very poorly on Windows browsers (looks fine on Mac browsers)

Because Windows is trying to use your hinting information while Mac use own autohinter

using the .otf files, and then also tried woff files, but it didn't help

woff is just a compressive container in simply words, it doesn't affect rendering

The lighter weights are ok, but the heavier one closes up in the counters 

A typical problem with fonts on Windows, hinting was involved to solve this.

TTFautohinting parameter settings and testing on a borrowed Windows machine, but I can't get these same poor results.

TTFA is not so good actually, especially on weights more then 600

So any help or advice is greatly appreciated, thanks!

You can write manual delta instruction for TTFA;
make manual hinting in your font editor;
outsource hinting

Adam Ladd

Thanks very much for this breakdown and your insights Viktor. I'll consider those options. I guess I'm wondering why the Cyreal test page is presenting the font different (better) than the client website when both are viewed in the same browser on Windows? It makes testing settings difficult since it doesn't display the same.

Viktor Rubenko

Are you sure this is the same TTF font file? It looks too different. Of course, font hinting/render depends on browser and system settings, but in the general case it looks almost the same.

Adam Ladd

Yes, I'm not sure how they look so different between the test site and the actual site (both viewed on same Windows os and browser).

Inspecting the site with Safari tools appears to show that they're using .woff2.

For comparison, here is how the site looks on Mac - Safari:

Viktor Rubenko

Adam Ladd said:

Yes, I'm not sure how they look so different between the test site and the actual site (both viewed on same Windows os and browser).

Inspecting the site with Safari tools appears to show that they're using .woff2.

How exactly did they convert it to woff2? For example, fontsquirell allows to convert font to woff but it can cut exist hinting and apply autohint during convertation.

Adam Ladd

Good points... not sure at moment. I'll ask.

Thomas Phinney

Fonts looking a little bolder on Windows is not unusual, but that is a LOT bolder on the bold weight. It seems like ... more difference than is usually explained by a different hinter. This looks a bit like a faux bold effect, to me.

Of course, *either* a faux bold effect *or* a bad-rehinting effect would be more prominent at smaller ppem sizes. And that is equivalent to “same physical size on a lower-res screen” which seems to be what the client was noticing.

I'd be inclined to look at the family relationships and USweightclass, just to make sure there is nothing that might cause a problem. Specifically, I would be curious to hear:

Which font style is the regular and which is the bold?
Are they style-linked for Windows?
What is the usWeightClass value of each?
What are the values of NameID 1, 2, 4, 16, 17, 21 and 22 for each font?

Check also that the original fonts and the new WOFF fonts the client made have no differences on any of these data points. If there are differences, note them.

Alternatively or additionally, I might run the font set through Adobe’s CompareFamily tool from AFDKO.

Adam Ladd

Thanks for all this feedback Thomas. I'll have to see if I can gather up as much of that info as I can.

Yeah, it almost does appear like a faux bold effect because it's so clunky in the counters, but there is no style linking as they are using a regular and semibold primarily... so I didn't link it.

I've got the question out to them about what versions of the fonts they're using for sure and if they were generated on their end.

Here's a quick look at the settings for this instance (they wanted a custom name):

Adam Ladd

For another comparison, the bigger line of text "Contract mobile..." seen above is set in the same semibold weight as the smaller "...features..." line that looks really bad.

The bigger line is 30px and the smaller is 14px.

The bigger text also looks a little wonky (especially in the horizontal thickness), but when you look at the smaller 14px text compared to the Windows browser display of the Cyreal test page text, even the 12px size looks decent on that. So I'm confused as to why the client site looks different, unless it does come down to the fact that some auto hinting was stripped out somehow and a different file is being used, as noted earlier.

I've got that question out to them...

... another possible twist: the line that says "24 month contracts" is listed as the regular weight - 14px, but has the appearance closer to the semibold. For comparison, the line under that "All our handsets..." is also listed as regular - 14px.

Thomas Phinney

I'd also ask them exactly what browser and version they are testing on, and what Windows version.

If you can’t reproduce it at your end, need to keep asking them questions.

And of course get those converted WOFF fonts from them and see if you get the same rendering once you have their fonts....

Jens Kutilek

 I believe it was purchased through one of my vendors and they were using the .otf files, and then also tried woff files, but it didn't help.

That sounds like they converted those WOFF files on their own, possibly converting the outline format to TrueType in the process. If they did that through some service like FontSquirrel, it is likely that the TT-based fonts were autohinted, so unless you use the same autohinter with the same settings, your results will differ from yours.

BTW OTF can be packed as WOFF/WOFF2 just fine without converting to TrueType. And I would require customers to only use ‘official’ web fonts, not convert their own.

notdef

Some variables to account for: Rendering engine is determined sometimes by system settings, sometimes by the browser, sometimes by the browser changing the system settings on install, sometimes by the size the type is rendered, and sometimes by the rotation of the screen. Earlier engines will tend towards rounding to full pixels (or get very blurry), newer ones towards fractional pixels in the horizontal direction, and the latest ones toward fractional pixels in all directions. With a set of decent instructions, you can get it to cascade down nicely through the ages.

With fractional font sizes, size-specific delta instructions becomes troublesome. I had a custom project recently where the distance between two elements was controlled with delta instructions. I checked and corrected all ppem sizes, but it still came out wrong. It turned out the end user was looking at text at 15,615 px due to a combination of relative sizing & browser zoom.

Adam Ladd

Asking more questions and trying to get the WOFF files they're using from them. They did send me what they were given from their agency partner, which was only .otf. So they're unsure how the WOFF files were acquired or generated. I'm asking for those right now to look at.

So far, he said the issue has only showed up when their commerce person is looking at it on his Windows laptop... when I tested my original font files on a Windows laptop (version 10 os and both Chrome and IE) yesterday, they showed better on the testing page as seen above.

When I visited the client site on the same Windows platform, it was showing the rendering problem.

So assuming the testing site on the Windows platform is showing me accurate results, if the client were using the same files, they should have a similar display on their site. But currently it's very different, making it again seem like it was a breakdown with the files somewhere.

Malcolm Wooden

Some vendors will generate TTF's from supplied OTF's using their own conversion tools. This is done so they can full-fill any format on demand whilst only needing to store OTF's.

Mike Duggan

might be best to delete all hinting from the files, start over and go from there. If hinting is needed, and if you want the best results, try using VTT Light Autohinter, which would certainly give you better results than I see in your example, and then you can make adjustments to make it better if needs be. if you would like help with this you can send me email at michaeldug at gmail.com 

Adam Ladd

Thanks for the advice and offer, Mike, really appreciate it. I'll let you know if I move forward with that. And thanks to all so far with the feedback.

Adam Ladd

So I've got a little more info from the client and some updated screenshot tests...

From client: "the Windows and browser our ecom manager is using, he’s on Windows 10 Enterprise 64bit and Version 77.0.3865.120 for Chrome."

I've also now received the woff files they're currently using on their site. I could be wrong, but the way these are packaged makes them appear as though they were provided by a vendor (as opposed to the client doing an online generator themselves).

Below are some screenshot comparisons taken just now on my borrowed Windows 10 laptop using Chrome displaying my own exported files versus the versions the client has when uploaded to the cyreal.org testing page:

Here is the file the client is using (enlarge for actual size look and you can see the counters of /e and /a close at the 22px and 14px sizes they're using):



Here is my exported file with normal auto hinting (enlarge to see counters do not close, tight, but not closed):



Now here is another webfont test site, my font on the left and client version on right:



Again, if assuming the version the client has is straight from a vendor, then that vendor mentions that all webfonts have been auto hinted for quality rendering. So perhaps there is conflicting hinting info after the vendor generates the webfonts.

I've supplied this test file that I exported to them, but have yet to hear back if it helps. But I don't know how to replicate the issue any other way and it seems so far something was corrupted with their version.(?)

Thomas Phinney

So, just to clarify: you are supplying your client with TTF as well as OTF, right? When you are comparing "your version" and "client’s version", it is the same format inside the WOFF? (WOFF can contain either TTF or OTF, it's basically an optimization/wrapper for existing font content.)

If so, it sure seems that their vendor re-hinted your fonts and is getting worse results. That’s the point where you can wash your hands of it and politely suggest they not do that.

Adam Ladd

I actually never supplied files directly to this client. I believe (as far as I can tell because of the multiple layers of people involved at the moment) that someone on their end purchased the fonts directly from my vendor/reseller.

And if that's the case, I only supplied that vendor with OTF files (no TTF). Then the vendor would have generated the WOFF files for the client/customer that they're using.

Thomas Phinney

Aha!

So, here is a KEY thing: web folks, somewhere in this story, may have wanted TTF inside that WOFF wrapper, or just done so out of habit/default. So of course they are going to get different rendering. But the number of cases that *require* that is not that large. A few pretty old browsers, mostly.

Again, arguably not your problem. But if you have TTF that you are happy with the rendering of, you may have a solution for them. Or, you can point out that they could host both formats, and only serve the TTF-in-WOFF in cases that require it.

Adam Ladd

Ha, I hope so

I'm hoping the test file I provided displays better for them as it did for me on the Windows laptop tests here and that may take care of it.

Good suggestion too about perhaps hosting both. They mentioned they're trying to accommodate that smaller segment because this is a large commerce site.

Adam Ladd

Here are some more tests and screenshots of the Windows 10 / Chrome comparisons and their settings exported from Glyphs (click to enlarge to actual size if needed, and the 22 and 14px sizes are a good reference for these in comparing)... 

This is the client provided WOFF font that he said they're using on their site:

This is a TTF - WOFF that I just exported with autohint box checked - and no TTFA parameters were used:

This is a OTF - WOFF that I just exported with autohint box checked - and no TTFA parameters were used:

 

In my opinion, the OTF WOFF (with standard autohint) displays best and is quite different from the poor rendering of the client file.

Aside from the rendering quality, two other things I've noticed that some to point to a disconnect/file conflict is that the vertical metrics might have changed some with the files they have because the line spacing is a little larger in my versions. And the client versions have "webfont" added to the end of the font filename (which I don't do).

I'm still waiting to hear back from their devs regarding trying to test these files, but if I'm assuming the http://www.cyreal.org/Font-Testing-Page/index.php test is an accurate representation (as all this is from a Windows 10 machine), and assuming the client files were from a reseller with their own auto hinting, then these newly exported files should hopefully solve their problem if they replace the old ones with these on their site.(?) I guess it all depends on what their testing will show (will keep you posted, but any further feedback is welcome).

Robin Mientjes

These were very likely produced using FontSquirrel – especially now that you mention the ‘webfont’ suffix. I’m not sure how to educate the agency that handed the OTFs down, but your vendor hopefully has the right files?

Adam Ladd

Thanks Robin. I assume the vendor has the right files as all I provided them was the original OTFs, and when I uploaded those to the cyreal testing page to compare, they looked fine.

I'm still waiting to hear back about the client testing the new WOFFs, but am I correct in thinking that the testing I've done with the cyreal page on Windows 10 is an accurate display/rendering that should translate to their site if no other modifications are made to the files? (I understand that there are different versions, resolutions, browsers.)

My standard auto-hinted, OTF flavored - WOFF looks fine in those tests, so, as we've discussed, it all seems to point to the vendor or client having poor output from their webfont generator.

I don't want it to drag out longer than needed, so I want to eliminate any variables where possible.

Adam Ladd

Still waiting to hear back from client devs on the testing, but I've since tested it on another computer — Toshiba laptop with Windows 7 Ultimate in Chrome. Using the Cyreal.org testing page again shows same results (poor rendering of the vendor-generated, client files and crisper rendering with my OTF-flavored WOFF with standard auto hinting).

I know hinting settings/adjustments may be the other primary factor here, but it appears that the auto hinting at export works fine and nothing needs changed. I'm wondering if there are possibly any other variables that I'm not considering, because as they're asking questions, I am pushing the diagnosis in this direction (poorly generated vendor WOFF files)? In the end, I'm hoping their tests confirm this and sending these new files will solve it.