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

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.

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Comments: 36 (9 by maintainers)

Most upvoted comments

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

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)

image

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 🤷‍♂️ 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 🤷‍♂️ … 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? 😃

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.

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.

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

@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.