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!
Comments
make manual hinting in your font editor;
outsource hinting
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:
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.
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):
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.
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....
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.
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.
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.
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.(?)
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.
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.
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.
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.
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).
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.
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.