Web fonts are gone and new TTF files have old vertical metrics

rainerschuhsler commented 10 years ago

I commented on the last issue but I'm opening a new one just in case my comment wasn't seen.

The last commit was more destructive than constructive.

The web fonts should not have been removed. The TTF web fonts aren't meant to be installed as desktop fonts; they were generated to have a basic subsetting for browsers to download them faster and to have an adjusted x-height to match Georgia. Font Squirrel did not touch the settings for hinting, so the differences in hinting between the web TTF files and the new desktop TTF files weren't caused by the generator.

It looks like ttfautohint improved the hinting of the TTF files on Windows, but I fail to see why this is necessary at all, when the OTF files are technically superior. The reason the TTF files appear to render "better" on Windows (at least at small point sizes) is the way they're aliased. As you can see by the 72pt size type, the OTF characters appear smooth while the TTF characters appear jagged. I'll concede that Windows desktop users should have to option to install TTF files if they prefer them over OTF fonts, but these files shouldn't outright replace the web versions.

Further, it appears the new TTF files were generated by the SRF files, which retain the issues with vertical metrics that are fixed in the OTF files, so new web fonts can't be generated from the new TTF files because the baseline will be inconsistent among different weights. See http://uh.edu/~jrschuhs/crimson/December-2013/baseline-test.html and http://uh.edu/~jrschuhs/crimson/May-2014/baseline-test.html to compare.

skosch commented 10 years ago

Thanks for checking in Rainer, you are right. I didn't check the subsetting (or lack of it) and the scaling in the new TTFs when I should have. I'm running Linux, and I knew (from unrelated email complaints) that not everyone was happy with the TTFs' rendering on Windows, so I blindly trusted Adrien (as a Windows user) to know what he was doing.

Before I revert the changes, do you have any more suggestions?

rainerschuhsler commented 10 years ago

A couple things, and I can help out with them if needed.

For Windows users that want them, build TTF versions of the fonts based off the OTF versions, and run ttfautohint on them. These fonts will then have consistent vertical metrics with the other files and won't perpetrate the baseline issues if someone generates web fonts from these files.
Re-generate web fonts with WebOnly Protection checked. This will prevent the web TTF files from being installed as desktop fonts.

I'm not very familiar with using GitHub to fork repositories and request commits, so I can email you new web fonts if needed.

adrientetar commented 10 years ago

I expressed my opinion on the original PR. Should SRF files be updated beforehand? – I don't see why source files would have metrics that are not considered valid in the end-product.

rainerschuhsler commented 10 years ago

Yes, SRF files should be updated, but I only have software to update OTF files.

skosch commented 10 years ago

Rainer, that sounds reasonable to me. I would be grateful if you could generate those TTFs, as I have no way to test the files on Windows and Mac. The WebOnly flag for the webfonts is a neat idea.

Adrien, what are SRF files? Do you mean the SFDs? The source files have inconsistent vertical metrics, which Rainer fixed (using Fontlab, IIRC) when he generated the OTFs currently in the repo. In other words, the source files are broken and out of date. That's my fault; I'll fix them when I get back home in June.

Thanks to both of you for caring about this project :)

adrientetar commented 10 years ago

Oops, yes I meant SFD. Ah FontLab, I think it is compatible with FontForge through the UFO source format. Any thoughts about UFO?

So we have two separate issues:

fix the SFD/TTFs, maybe try generating TTF from OTF it there's no conversion cost?
do we want webfonts in the standard distribution? (otherwise, the WebOnly flag can be cleared up e.g. in the README)

Thinking back about it, it's true that digits 5 and 7 were smaller in the source provided.

skosch commented 10 years ago

About 3 out of 4 emails that I get about Crimson are people trying to use it on their website (since Google's version is ancient, and they're not updating ...). It's great to be able to link to github, instead of requiring these non-font-savvy people to go through the Fontsquirrel hassle themselves. So yes, webfonts are a good idea. And we should clarify what's what in the README.

PS./Edit: Fontsquirrel's generator is a script running FontForge, sfnt2woff and ttf2eot. No black magic involved.

adrientetar commented 10 years ago

(answering here instead of on the PR)

@skosch Right, what you outlined on the PR sounds good. Yea I'm personally a bit leery towards that generator, plus different users probably want different settings (why should we match Georgia in height, for instance?) but I definitely see the need for webfonts.

@rainerschuhsler Once you fork the repository from the GitHub button and install git, these steps should work:

git clone https://github.com/rainerschuhsler/Crimson.git
cd Crimson
git checkout -b patch-1 # create a feature-branch called `patch-1` (this is optional but better for reusability of the repo)
# now, do the changes
git add . # track all changes in the working folder
git commit -m "Commit message" # create a new commit
git push origin patch-1 # upload the local patch-1 branch to the remote repository

Then if you go on the GitHub page of the repo, you can now initiate a pull request.

rainerschuhsler commented 10 years ago

@adrientetar

Yea I'm personally a bit leery towards that generator, plus different users probably want different settings (why should we match Georgia in height, for instance?) but I definitely see the need for webfonts.

The web font files previously included with the repository were generated by me following the same configuration file as the kit previous to that. If someone wants to generate web font files using different settings to fit a different need, there's nothing stopping them. I believe @skosch was the one to originally decide to match the x-height of Georgia, and I agree with that decision. Without x-height matching, Crimson is rendered relatively smaller than other fonts set at the same size. I believe this has something to do with the size of the emsquare Crimson characters are created on. Matching the x-height with Georgia decently normalizes the type size on the web.

The web font generator at Font Squirrel seems to be the standard. Do you recommend an alternative? I have tested many alternatives and Font Squirrel with the right settings under expert mode produce the best WOFF, EOT, and web TTF files. The hinting settings you have a problem with can be ignored as part of the expert configuration. Furthermore, I don't think we should hold the web TTF files to the same standard as the desktop TTF files. The web TTF files generated by Font Squirrel exist only as a backup for modern web browsers that don't support EOT or WOFF, which at this point is iOS 4 and below and Android 4.3 and below. Firefox, Chrome, Safari, IE9+, iOS 5+ and Android 4.4+ fully support WOFF and only load TTF if WOFF fails to load. Older versions of IE load EOT. See http://caniuse.com/#search=font for the details.

To reiterate, I understand the need for some users to have desktop TTF files for Windows even though the OTF files are superior for desktop publishing software, but we should make sure the desktop TTF files are not confused with the web TTF files. Using the WebOnly protection setting should fix that.

@adrientetar If it's possible, could you produce TTF files from the OTF files and run ttfautohint on them? I can create the web fonts from the OTF files and with the help you provided, will figure out how to do the Git stuff.

adrientetar commented 10 years ago

PS./Edit: Fontsquirrel's generator is a script running FontForge, sfnt2woff and ttf2eot. No black magic involved.

Well I've seen some odd things with it, like once when I was converting Fira Sans from TTF to WOFF, resulting letterforms were mashed and compressed for some reason... then tweaking the settings it was happening back and forth, was really odd. I have never seen this happening when using FontForge locally, which is why I like local tools (through I've yet to find a way to restrict charset easily).

Without x-height matching, Crimson is rendered relatively smaller than other fonts set at the same size.

I see.

only load TTF if WOFF fails to load

WOFF is just a compressed TTF or OTF, so if you choose to generate it from a TTF it remains the same.

Personally, I prefer to use TTFs since they look good on platforms other than Windows and they look better on Windows. Since 90% of market-share (incl. myself, in part) is held by Windows, I prefer to use TTFs personally. BTW I will provide a screenshot comparison with the DirectWrite renderer once I've generated the TTFs.

orjanb-ne commented 5 years ago

This seems like it is still an issue. I downloaded the latest webfont and get this: helvetica-alignment

skosch / Crimson

Web fonts are gone and new TTF files have old vertical metrics #3