On windows and linux: Capital and lowercase 'w' have size and kerning issues ($500 bounty)

[Discordius]

On windows and linux machines you get the following effect if you display the font at anything but the default size of 20px:

This makes most of the text sadly almost unreadable on windows and linux devices.

[rtm]

Thanks for your work on this font. I'm having exactly the same problem. I don't see it at 18px (1.2rem), but it's quite noticeable at 1.1rem (16px). See screenshot.

This pretty much excludes my using this font in my app. Should I go ahead and find something else, or is there any chance this could be addressed?

[adamschwartz]

This seems like roughly the same issue as https://github.com/edwardtufte/et-book/issues/19. Closing as duplicate for now.

[rtm]

@adamschwartz The root cause may well be the same--or not. This bug relates to the lower-case W, and in particular its relative size, while #19 relates to kerning issues with the upper-case W.

[skosch]

I can't reproduce this on Linux. Perhaps it's a hinting issue on Windows – try running the files through ttfautohint?

[Discordius]

I reproduced it on Windows Edge 81 on this URL http://shlegeris.com/2018/10/23/weirdest, with the font-size set to 17px.

Here is a screenshot:

[Discordius]

Just in case anyone stumbles across this, this is still a problem for me, and I am willing to send $500 via wire transfer or PayPal to whoever fixes this. And $100 to anyone who provides a pointer that helps someone else eventually fix it (or helps me fix it), up to a maximum of another $500 (i.e. up to 5 pointers).

[skosch]

What browser are you using in your screenshot from July 3? I'm going through combinations of Windows/Edge versions on Browserstack to try and reproduce the problem, but I can't find one that looks like yours above :thinking:

[skosch]

For instance, here's Edge 85 on Windows 10:

[skosch]

Ah sorry, please disregard – I didn't see your comment about 17px. I see it now

[skosch]

Ok @Discordius, as I suspected it's a hinting issue. What you need to do is take the TTFs from the source folder and run them through a webfont generator like this one. Select "Expert", and then you can choose from hinting presets.

For me, the "Font Squirrel" setting results in the wonky w on Windows, but "Keep Existing" and "TTFAutohint" doesn't. See https://www.aldusleaf.org/tufte/test.html below. As far as I can tell this is robust to font size changes, but you should definitely play around with it and make sure there's no other issues.

[Discordius]

Great! If you make a PR to this repo with the fixed .ttf files and it gets merged, then I am happy to send you $500 via PayPal (or if it doesn't get merged after two weeks or so, which can of course easily happen if the maintainer doesn't have time to double-check).

Otherwise I would do that myself and send you $100 for giving me a successful pointer to a potential solution. The $500 seems fairer, but the commitment I made was to only pay out the $500 for the full end-to-end thing.

[Discordius]

I will double check the for any errors that result from this. But thank you for your help in any case, and no matter what problems I find, I am happy to send you at least $100 in any case.

[skosch]

Yes, please do double check – and I think we should get @adamschwartz's input before creating new webfonts, to make sure they match the existing files as closely as possible, especially w.r.t. scaling. Fontsquirrel has a lot of settings!

Your bounty offer is really generous. I would like to see the money go to an effective charity, perhaps ITIF in light of the current fires?

[adamschwartz]

Thanks @skosch and @Discordius

I would be happy to see the results. I don’t have enough experience with this type of issue to say I know what the ideal solution is here, and unfortunately I don’t have a Windows machine to test this on.

My suggestion is that once we have both fonts to compare (current and proposed), we build a test page which renders the same text in both fonts placed on top of each other (z-dimension) in various font sizes (including the troublesome 17px). Make the top one black and the bottom one red, e.g. We can easily see if any red pokes out. That would be a good start.

[Discordius]

Your bounty offer is really generous. I would like to see the money go to an effective charity, perhaps ITIF in light of the current fires?

Of course, that seems great! Will send it out as soon as we settled stuff here, which will determine the amount.

I like the idea of a test page with both of them rendered on top of each other.

[skosch]

Alright, as far as I can tell, there's no significant difference between the settings, as long as we avoid the "Font Squirrel" preset; see https://www.aldusleaf.org/tufte/test.html. The metrics seem to match, and that's without me touching any of the other options. Can you try and play with it some more and see if you find any issues?

Finally, this would be a good time to set up proper OpenType lookups for both ligatures and oldstyle/lining variants. This will take me a bit of time; if you'd like to go ahead and do it yourself that's fine too.

[adamschwartz]

Thanks so much. This is a great start!

The main thing that caught my eye was a subtle change to the opening inside “e”:

I believe I actually prefer the new one, although I wasn’t 100% sure which was which in the test. Please add a key to make sure it’s clear, and please use red beneath the black as shown in this screenshot.

There are a couple of other similar changes to the curvature of “s”, e.g.

I’d love to see the test additionally render all defined glyphs in a large font-size to make these sorts of comparisons easier. (You can use https://fontdrop.info or similar to get a good table/list to start.)

Check out https://fontdrop.info/#/compare as well.

[skosch]

I've reverted the colours on the test page, red is now the original (underneath) and black the new (on top).

Here are the five files:

• Original
• Keep existing, "fix GASP table"
• Keep existing, no "fix GASP table"
• TTFAutohint, "fix GASP table"
• TTFAutohint, no "fix GASP table"

I don't see any differences on Fontdrop, at least not on my Linux machine. Do you? And I don't know how I would use Fontdrop via Browserstack, as it's not letting me download the files within the VM ...

[adamschwartz]

I tested in Chrome and Firefox on macOS and things are looking good.

To feel confident this really works, I’d love to get confirmation from one or more Windows folks, with ideally some screenshots posted here. As far as I’m concerned, the differences in the test on macOS are negligible enough that if we’re solving a real problem with the w on Windows, it’s worth it to me.

@Discordius since you’re the main driver here, would you be willing to produce screenshots of the test pages on Windows?

[Discordius]

Sure! Taken from browserstack.

100% Zoom:

125% Zoom:

150% Zoom:

200% Zoom:

[adamschwartz]

Thanks so much for these. I’m curious how you’re doing the the zooming.

The lowercase “g” seems to vary quite wildly between the size. Compare the word “gone” in the first sentence (“Over the last year or two...”) in 150% and 200% for example:

150%:

200%:

It also seems like the screenshots may not have been captured and/or uploaded in native resolution. Would it be possible to redo these that way?

As these stand I am seeing a pretty significant amount of red. The lowercased “e” and “g” both seem to have some issues, given the blurriness of the screenshots, it’s hard for me to say if those issues were already present in the original version.

[skosch]

I'm not sure what to do about the g, I agree it doesn't look great. TTFAutohint has lots of settings, and hand-hinting is always an option. I've never done either though and don't know how much time and experimentation it would take to get it right.

[Discordius]

Thanks so much for these. I’m curious how you’re doing the the zooming.

I've just been zooming in with the browser

 It also seems like the screenshots may not have been captured and/or uploaded in native resolution. Would it be possible to redo these that way?

Alas, I think this is the result of me testing on Browserstack, since I also don't have a Windows machine available. With browserstack compression plus browserstack presumably not sending the feed of a retina monitor back to me.

I have colleague with a windows machine who can probably take better screenshots. I will ask him.

On Fri, Sep 18, 2020 at 7:57 AM, Sebastian Kosch < notifications@github.com > wrote:

I'm not sure what to do about the g , I agree it doesn't look great. TTFAutohint has lots of settings ( https://www.freetype.org/ttfautohint/doc/ttfautohint.html ) , and hand-hinting ( https://fontforge.org/docs/techref/hinting.html ) is always an option. I've never done either though and don't know how much time and experimentation it would take to get it right.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub ( https://github.com/edwardtufte/et-book/issues/20#issuecomment-694917596 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/ACFLNZOVJ35YM6Y2GP4O2OTSGNYMXANCNFSM4D7TTV5Q ).

[adamschwartz]

Ah that’s right I forgot about Browserstack. Thanks

[sirinath]

Is it possible to add the full Latin, Greek, diacritic, and symbols, if there is a possibility?

[Discordius]

@sirinath: My guess is you should create a new issue for that, since this issue is about something much narrower.

[Discordius]

@adamschwartz: About the top-level issue that we were discussing. Is this currently blocked on having a good set of high-resolution windows screenshots? If so, then I am happy to get those.

[adamschwartz]

@sirinath Please create a separate issue for that as @Discordius noted. Thanks.

@Discordius yes, thank you!

[Discordius]

Here they are!

[adamschwartz]

Thank you so much for these.

As expected, the differences are somewhat clearer to see in the native screenshots.

My concerns around the “g” are unfortunately still there.

As for the “e”, I’m now able to see that similar issues are occurring in many other glyphs, e.g. “d”, “f”, “i”, “l”, “p”, and “u”.

That is to say, it seems like in general, there is a vertical stretch that seems to be occurring, exposing a horizontal bar of red in many glyphs.

That being said, these issues I think we could live with, certainly in exchange for fixing the “w”.

The lowercased “g” though is still really bothering me. I’d like to leave this open for a little bit longer, and I’d encourage us all to reach out to typographers we know to see if it can be relatively easily addressed. If within a week or two we cannot find a solution, I’m willing to merge really any of the options above to fix the “w” issue—which is more severely limiting usage on Windows and Linux. However, at that point, we’ll be closing this one and opening up a new issue to fix the “g” haha. (Still worth it.)

@skosch Do you have any other recommendations before we give up?

[skosch]

Thanks for these screenshots, I agree they're very helpful.

I'm not as worried about the black/red discrepancy; I don't think we should assume that the red is somehow the non-plus-ultra the black should aspire to match. TTFAutohint simply has different default settings than the Windows renderer. Let's compare TTFAutohint settings and judge them on their own merit.

I'm on Linux and as far as I can tell, any hints get ignored anyway. Not sure about OS X. On Windows, I get the following results for the different values of this key TTFAutohint setting:

 -a, --stem-width-mode=S    select stem width mode for grayscale, GDI 
                            ClearType, and DW ClearType, where S is a
                            string of three letters with possible values
                            `n' for natural, `q' for quantized, and `s'
                            for strong (default: qsq)

The differences are subtle; the first one I don't like because letters like "u" are stunted; the second one is like the third but a bit darker, but both have a crippled "v". The last one (no hints) seems to have no obvious issues (yay!) but the letters look pretty anemic.

I think grayscale and GDI are only WinXP and earlier? Either way, I can't test them on Browserstack, so :man_shrugging: Then there are other TTFAutohint parameters I don't understand how to use properly. Speaking of which – I have no idea what settings to use to reproduce the FontSquirrel output; again :man_shrugging: ... I'm sure someone with more experience would be able to achieve much better results!

I wonder if @davelab6 might have any font production advice for us? Or perhaps even an interest in commissioning a pro to clean this up for inclusion in GF? :)

[Discordius]

Just to follow up on this, do we want to merge any of these options?

[adamschwartz]

I would gladly accept a PR at this point. Perhaps you, @skosch, @davelab6 can work together on this?

[Discordius]

@skosch: Are you up for making a PR? I can probably figure out how to set up TTFAutohint and stuff, but seems like you basically had the files ready.

[skosch]

Yes and no. Do we have a consensus on what the best option is yet? I could certainly run TTFAutohint on the ttfs in the source folder to remove existing hints, which will solve this issue but not #21.

The right approach would probably be to modernize this whole repo, and to simply leave out the hinting in future builds, or to always run TTFAutohint with the decided-upon settings:

• convert the sources to UFO format (@adamschwartz what software did you use to make these fonts?)
• follow a standard folder structure like this one
• implement a reproducible build process (this could probably just be a fontmake invocation)
• get rid of the lining/oldstyle number file split, and use the onum OpenType feature instead

I think this would be a worthwhile effort -- this is a very popular repo, and it would make it easier for others to contribute in the future (more language support, more italic weights, etc.).

Unfortunately I've never done any of these things myself, and I only have Linux and FontForge at my disposal, so I'm reluctant to spend a lot of time on this only to risk creating new problems. @Discordius depending on what kind of work you are willing to pay out the bounty for, perhaps there are others who could do this; I could certainly ask around.

[dpk]

I’m making progress on doing something like what @skosch suggests here: https://github.com/dpk/et-book/tree/2.0