[Windows] font height inconsistency with Hack 3.001 release #377

jlanzarotta · 2018-01-23T16:53:31Z

Hello,

First off, I love the font. However, after updating my Windows machine to v3.001, the font rendering is somewhat strange for Italics and Bold... Any ideas on how to fix this? I reboot, and nothing has changed...

Thanks,

chrissimpkins · 2018-01-23T18:02:18Z

Can you confirm that you installed this with the WIndows installer that includes the new v3.001 release files?

https://github.com/source-foundry/Hack-windows-installer/releases/tag/v1.5.1

texhex · 2018-01-23T19:11:07Z

Please try the installer if you haven't so far. If you did, please post the fileC:\Program Files\Hack Windows Installer\Log-FontData.txt. That's a basic log we are generating where we maybe are able to find out what's wrong.

jdw1996 · 2018-01-24T02:13:28Z

For what it's worth, I saw a similar problem using my custom build of the font (make ttf) on my work machine (Windows 10).

chrissimpkins · 2018-01-24T02:49:11Z

We've had a number of issues related to font caching with residual previous builds that lead to rendering errors on Windows. Try the Windows installer linked above and let us know if that fixes the problem for you. We have yet to develop something simple for developers who need to install new builds, test, re-install new builds on the Windows platform.

jlanzarotta · 2018-01-24T18:16:48Z

Yeap, used the latest installer. Here is the file you requested... Hope it helps...

Log-FontData.txt

chrissimpkins · 2018-01-24T19:21:28Z

Thanks @jlanzarotta. Let's see whether @texhex thinks that there is an install issue here. If not I will have a look at the tables to confirm that we didn't modify something unintentionally.

@texhex can you confirm that you are seeing this problem on your Win install?

texhex · 2018-01-25T10:27:49Z

@jlanzarotta From my point of view, the installation is looking normally, there is nothing that is unexpected.

Idea I have to find out what is going on on your machine:

Is the program you are using Java based? Could you maybe try to replicate the problem with Notepad++ and does it show the same errors?
Could you please open a command prompt and enter the command "dir c:\windows\fonts\Hack*.*". The listing should only list four files (Hack-Bold.ttf - Hack-BoldItalic.ttf - Hack-Italic.ttf - Hack-Regular.ttf)
Would it be possible that you run the installer a second time and post the Log-FontData.txt after that? It should show that all files were already in place and no installation is required.

jlanzarotta · 2018-01-25T14:07:59Z

I am using Vim and IntelliJ.
Yes, there are only the four fonts you listed in "c:\windows\fonts\hack*.*".
I tried your suggestion and tried to replicate the problem in Notepad++. Notepad++ rendered everything just fine.

Then I noticed why Notepad++ rendered correctly. In Notepad++, the text was not italics, just plain. So I set Vim and IntelliJ to not use bold or italics, they they work fine now also. Could it an issue with just bold and italics?

Here is the fine you asked for...
Log-FontData.txt

chrissimpkins · 2018-01-25T14:26:35Z

We've had long standing problems with the JetBrains editors on Win. They all use a Java font renderer that is very finicky with our fonts on the Win platform for some reason. Thanks for testing in another editor and for helping to troubleshoot here. I will take a look at our OT tables and confirm that there were no unexpected changes in this release. Would be helpful to me if you could confirm that reinstallation of the last version (3.000) with the Win installer fixes the problem.

Let's see what Michael has to say about the new install logs.

chrissimpkins · 2018-01-25T14:27:55Z

Can you also let us know what Win version you are using?

jlanzarotta · 2018-01-25T14:34:26Z

The 3.000 version works beautifully. All applications render correctly.

I am using Windows 7.

chrissimpkins · 2018-01-25T14:49:40Z

and current releases of IntelliJ / vim?

chrissimpkins · 2018-01-25T14:51:22Z

@jdw1996 Joseph, can you let us know what editor you are seeing these problems in and confirm that the issue is that there are different vertical heights of glyphs when rendered in bold/italics, but not in regular only?

chrissimpkins · 2018-01-25T14:53:02Z

@jorgheymans Jorg, do you happen to have any free time to help us test this in the Java renderer project that you developed assuming that I can find something to modify in the build artifacts?

jdw1996 · 2018-01-25T15:08:21Z

I've seen the problem in Firefox (i.e. on webpages using my default monospace font), Vim, and Word, which makes me think it's not strictly a Java problem. I'm not having any issue using regular, but certain glyphs do appear taller than others in bold, italic, and bold italic.

chrissimpkins · 2018-01-25T15:25:28Z

Strange. OK, thanks for that feedback. Can I ask you to verify that the same glyphs appear "too short" or "too tall" relative to others c/w the image in the OP? I will need a handful of glyphs to explore and will begin there.

jdw1996 · 2018-01-25T15:35:56Z

It seems that they are the same. Specifically, I have tall: abcdeosv. Capital letters all appear the same height as each other.

chrissimpkins · 2018-01-25T15:38:57Z

Beginning to sound like a hinting issue. We bumped a couple of ttfautohint build dependencies. That may have done it. More info when I have it.

texhex · 2018-01-25T16:24:53Z

@jlanzarotta: Thanks for efforts! I checked both installation logs and they look the same, so my guess is that, after 3.001 didn't worked, you went and installed 3.0 again. The hash values of the fonts found on your machine match exactly the 3.0 release.

If this is true, I do not find any indicator that this error is caused by an installation error, I'm sorry.

@chrissimpkins: I set my Notepad++ to Hack 10pt and Bold+Italic. Here's how it looks (using the best RFC ever as example). If I'm not mistaking, this is indeed a "real" font bug:

chrissimpkins · 2018-01-25T16:27:27Z

this is indeed a "real" font bug

Thanks @texhex. On it!

chrissimpkins · 2018-01-25T16:28:07Z

@texhex do we have a decent set of docs to use FSCW for testing installs of new font changes as I produce them?

texhex · 2018-01-25T17:55:10Z

We could use the Test-Windows-Installer for that. What would be your preferred way?

Pushing the test fonts to the /Hack repo, then pushing a trigger file to the Test-Windows-Installer repo which would in turn start AppVeyor which would build and upload the new setup.exe?

Or would you like to push the new build directly to the Test-Windows-Installer repo?

chrissimpkins · 2018-01-25T18:08:52Z

Whatever is easiest for all involved. If I can push somewhere and testers can pull auto builds of a win installer that would probably be best (if I understood you correctly). short of that an approach to help them clear cache for manual installs is OK by me too. Will version according to git commit sha1 and can rename if would like to do side by side comps

texhex · 2018-01-25T18:18:37Z

Ok, then pushing to the Test-Windows-Installer repo it is then. Preparing repo.

texhex · 2018-01-25T18:33:04Z

@chrissimpkins Repository done. Put the new TTF builds in \testfonts inside the Test-Windows-Installer repo and a Setup EXE will be build and added to Releases with the comment you used for your commit.

chrissimpkins · 2018-01-27T18:44:16Z

I was able to get a Windows box to look into this issue. Looking at this at the sizes 8, 9, 10, 11, 12, 14 in Notepad, it appears that the only affected sizes are 8, 10, and 14. The others all appear to render appropriately. Can you confirm this on your systems?

texhex · 2018-01-27T18:49:48Z

Checking with Notepad++, I can confirm this. 8, 10 and 14 are affected. It happens again on 16 and 18 were it seems the "e" and "o" "shrink" too much (I believe, I'm not a designer).

chrissimpkins · 2018-01-27T19:02:24Z

Thanks @texhex. I went through bold and bold italic and they seem to be affected across a more broad range of these sizes.

This is definitely a hinting issue. For some reason we seem to have lost much of the auto in the ttfautohint :)

Let me do some testing today and will let you know if I figure this out. Remains unclear why this changed between v3.000 and v3.000 but we can safely say now that this is (1) result of instruction set differences; (2) size dependent; (3) does not affect regular set; (4) does affect bold, italic, and bold italic sets.

This points me in a direction. I have another idea. More to come...

…377, this eliminates the regular set as the blue zone reference font

chrissimpkins · 2018-01-27T20:16:39Z

I think that my hunch was correct.

This appears to fix the issue across italic, bold, and bold italic sets:

Win: https://github.com/source-foundry/Hack-Test-Win-Installer/releases/tag/v1.2.48
Linux: https://github.com/source-foundry/Hack/tree/bugfix-windows-revert-ttfadep/build/ttf

This will install test builds Version 3.002;[f1c8c7a]-dev.

We were linking vertical metrics in the bold, italic, and bold italic sets to the regular set with the ttfautohint -R flag to maintain consistency of glyph height when you switch between regular and any of these other sets. This seems to now result in incorrect renders of the non-regular sets for those whose platform pays attention to the instruction sets built into the fonts (including Windows, Linux - does not include macOS which is why I don't see it on my development machine). I will have to go back through the commit history. My recollection is that this is a setting that was present at the time of the v3.000 builds. If that is the case, then something has changed with ttfautohint behavior. The removal of this setting may mean that we need to go back through the ASCII set and determine whether any manual hinting adjustments are necessary in the bold, italic, and bold italic sets. cc @lemzwerg - this appears to be the problem here...

Please install the above build files through the Win installer on Windows. Linux users should install the builds available here https://github.com/source-foundry/Hack/tree/bugfix-windows-revert-ttfadep/build/ttf with your distro specific direct installation mechanism and a cache clear - see README).

Please confirm that the variable height issue in the lower case glyphs is eliminated at all sizes between 8 - 14. If you don't mind, can I ask you to use the following text specimen to examine these changes in all four variant sets:

ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
0123456789
~!@#$%^&*()-_=+[{]}\|/?.,<>

Based upon the appearance of all of these glyphs across that size range, we will make a decision about whether we should push a fix release as is or if we will need to manually modify the instruction sets for any of the glyphs at any of the sizes in the 8 - 14 range to make this production ready. I will review this on my end as well so that I can see what you are seeing.

Thanks all for your help here. I apologize for this issue and still don't have a good explanation for it, but we appear to have identified the root and a fix. I always perform QA testing on the OT tables before releases with a combination of tools, visually inspect all ASCII glyphs when hinting settings are modified, and obviously visually inspect all design changes (including the hinted renders) for all glyphs that change during the work for a release. This fell outside of the range of expected/possible changes and I suppose that the only way to prevent it in the future is to establish visual testing of the fonts on Win/Linux/macOS going forward. If anyone out there is willing to assist with this, we leave our release PR's open for weeks prior to merging to master. It would be extremely helpful to have a group of individuals who are willing to install these "release candidates" at that time and give these anticipated release builds a spin in text before the merge occurs so that we can try to address these issues in advance of a release. We'll come up with an approach. Feel free to let me know if there is a better way to communicate about upcoming release ready builds if you are interested in helping with this testing.

…379. Removes -R flag from ttfautohint settings to eliminate blue zone linking between bold/italic/bolditalic and regular variants.

chrissimpkins · 2018-01-27T20:42:47Z

Summary for @lemzwerg :

not macOS specific, occurred with our Linux compile testing too
occurred with our Python compile chain across Python 2 & 3 installs of the tooling
unclear whether it is related to Harfbuzz/FreeType libraries
is related to use of -R with link to regular set from italic, bold, bold italic

Original summary of the issue: #377 (comment)

Unclear whether this represents a ttfautohint bug. I can verify that we did build the v3.000 release with the same -R setting as we used in v3.001 and the glyphs did not render as shown in the image in the OP:

Hack/build-ttf.sh

Lines 171 to 201 in 706b2b2

    
           # Hack-Regular.ttf 
        
           if ! "$TTFAH" -l 6 -r 50 -x 10 -H 181 -D latn -f latn -w G -W -t -X "" -I -R "master_ttf/Hack-Regular.ttf" -m "postbuild_processing/tt-hinting/Hack-Regular-TA.txt" "master_ttf/Hack-Regular.ttf" "master_ttf/hinted/Hack-Regular.ttf" 
        
           	then 
        
           	    echo "Unable to execute ttfautohint on the Hack-Regular variant set.  Build canceled." 1>&2 
        
           	    exit 1 
        
           fi 
        
           echo "master_ttf/Hack-Regular.ttf - successful hinting with ttfautohint" 
        
           # Hack-Bold.ttf 
        
           if ! "$TTFAH" -l 6 -r 50 -x 10 -H 260 -D latn -f latn -w G -W -t -X "" -I -R "master_ttf/Hack-Regular.ttf" -m "postbuild_processing/tt-hinting/Hack-Bold-TA.txt" "master_ttf/Hack-Bold.ttf" "master_ttf/hinted/Hack-Bold.ttf" 
        
           	then 
        
           	    echo "Unable to execute ttfautohint on the Hack-Bold variant set.  Build canceled." 1>&2 
        
           	    exit 1 
        
           fi 
        
           echo "master_ttf/Hack-Bold.ttf - successful hinting with ttfautohint" 
        
           # Hack-Italic.ttf 
        
           if ! "$TTFAH" -l 6 -r 50 -x 10 -H 145 -D latn -f latn -w G -W -t -X "" -I -R "master_ttf/Hack-Regular.ttf" -m "postbuild_processing/tt-hinting/Hack-Italic-TA.txt" "master_ttf/Hack-Italic.ttf" "master_ttf/hinted/Hack-Italic.ttf" 
        
           	then 
        
           	    echo "Unable to execute ttfautohint on the Hack-Italic variant set.  Build canceled." 1>&2 
        
           	    exit 1 
        
           fi 
        
           echo "master_ttf/Hack-Italic.ttf - successful hinting with ttfautohint" 
        
           # Hack-BoldItalic.ttf 
        
           if ! "$TTFAH" -l 6 -r 50 -x 10 -H 265 -D latn -f latn -w G -W -t -X "" -I -R "master_ttf/Hack-Regular.ttf" -m "postbuild_processing/tt-hinting/Hack-BoldItalic-TA.txt" "master_ttf/Hack-BoldItalic.ttf" "master_ttf/hinted/Hack-BoldItalic.ttf" 
        
           	then 
        
           	    echo "Unable to execute ttfautohint on the Hack-BoldItalic variant set.  Build canceled." 1>&2 
        
           	    exit 1 
        
           fi 
        
           echo "master_ttf/Hack-BoldItalic.ttf - successful hinting with ttfautohint"

Is it possible that blue zones are being defined differently due to a compiler update? fontmake and many of its dependencies changed between these releases. I can verify that we did not change anything in the source files before they hit the compiler that would have modified blue zone settings in any of the sets.

Looping in @anthrotype to see if he has any feedback about the above paragraph. I don't know the answer or where to begin to explore this issue. Happy to file an issue report anywhere it is felt to be necessary if this does appear to be a new issue introduced during the compilation / hinting process somewhere.

texhex · 2018-01-28T10:51:46Z

@chrissimpkins 1.2.48 looks good for 10pt:

chrissimpkins · 2018-01-28T18:20:09Z

I reviewed across all four variants x sizes 8 - 14 x specimen linked above. We appear to be in good shape with this build.

Displayed at size 10:

texhex · 2018-01-28T20:33:02Z

Are we ready to release a fixed version or do you want to wait?

I'm asking because @jlanzarotta has most likely already muted this discussion here :-), given how many comments this issue already has. So I think only a new "normal" Hack-Win-Installer would be noticed.

chrissimpkins · 2018-01-28T21:05:30Z

I will merge this over to dev and build / version tag a new release set that contains these changes tonight. Should be able to merge these and push a new release on this repo later this evening. We've diverted desktop users away from these files but web font users who are using the URL that automatically version bumps through jsDelivr/npm are actively affected by this issue which is why I have been working to get this fixed asap.

If I only need to push the release fonts to the Hack-Win-Installer repo, I am happy to take care of the installer release. If there is other work to do to prepare the installer that differs from how the test installer worked, I will let you know when these files are ready. Let me know how you would like to approach it.

chrissimpkins · 2018-01-28T21:07:31Z

This will go out as a v3.002 bugfix release and we will push all planned v3.002 work to v3.003. I will update the milestone tagged issue reports.

chrissimpkins · 2018-01-28T21:09:41Z

As a side note, I now have two new Linux and one new Win 10 VM set up with an approach to visually proof the fonts before releases. PIA, but hopefully this won't happen again™ :)

chrissimpkins · 2018-01-29T02:12:41Z

This fix was released as v3.002. Will close this thread when the Windows installer is available for these builds.

* dev: [README.md] updated Linux font cache clear instructions and added information about font rendering improvements on Linux platform [README.md] documentation text updates (minor) [README.md] Mac OS X --> macOS in documentation 3.2.0 [README.md] updated download link to v3.002 release builds [CHANGELOG.md] updated for v3.002 [archiver.sh] updated archiver script Hack v3.002;[e813aee]-release builds + CSS builds Version 3.002;[f1c8c7a]-dev : Possible FIX build for issues #377 and #379. Removes -R flag from ttfautohint settings to eliminate blue zone linking between bold/italic/bolditalic and regular variants. removed use of -R flag in ttfautohint in an attempt to address bug in #377, this eliminates the regular set as the blue zone reference font modified build-ttf.sh script to replace -I flag and remove -n flag (adds ttfautohint metadata back to the name ID 5 record), another attempt to address hinting issue in #377 converted to compilation and hinting on Linux. hinting with ttfautohint 1.7, Harfbuzz 1.5, FreeType 2.8 [ttfautohint-build.sh] revert ttfautohint build dependencies: FreeType back to v2.8 (from v2.8.1), Harfbuzz back to v1.5.0 (from 1.7.4) # Conflicts: # build/ttf/Hack-Bold.ttf # build/ttf/Hack-BoldItalic.ttf # build/ttf/Hack-Italic.ttf # build/ttf/Hack-Regular.ttf

texhex · 2018-01-29T16:34:07Z

Hack Windows Installer 1.5.2 with Hack v3.002 is live.

@jlanzarotta: Please give 1.5.2 a try, this will fix this issue for good.

@chrissimpkins: Ready to close this issue when you are.

chrissimpkins · 2018-01-29T17:24:50Z

@texhex thanks for all of your help with testing this over the weekend Michael. I really appreciate all of your help to get this fix out.

Thanks for the report @jlanzarotta Much appreciated!

chrissimpkins · 2018-01-29T17:26:20Z

@lemzwerg Werner, if there is anything that I can do to help investigate this issue further please let me know. We are closing this issue report as we have released a fix for it.

lemzwerg · 2018-01-29T20:01:52Z

Well, I just need some time to look into it :-/

chrissimpkins · 2018-01-29T20:18:48Z

@lemzwerg No worries! Not intended to rush you. Just wanted you to be aware that I am happy to help. I just don't know how to dig into the issue further to do so. I am happy to post a ticket on ttfautohint repo if you would like so that this information is preserved somewhere.

chrissimpkins · 2018-02-02T21:22:29Z

@lemzwerg additional information on the hinting settings for the user on Linux who reported the same issue in case this is helpful:

#379 (comment)

…dds ttfautohint metadata back to the name ID 5 record), another attempt to address hinting issue in source-foundry#377

…ource-foundry#377, this eliminates the regular set as the blue zone reference font

…undry#377 and source-foundry#379. Removes -R flag from ttfautohint settings to eliminate blue zone linking between bold/italic/bolditalic and regular variants.

* dev: [README.md] updated Linux font cache clear instructions and added information about font rendering improvements on Linux platform [README.md] documentation text updates (minor) [README.md] Mac OS X --> macOS in documentation 3.2.0 [README.md] updated download link to v3.002 release builds [CHANGELOG.md] updated for v3.002 [archiver.sh] updated archiver script Hack v3.002;[e813aee]-release builds + CSS builds Version 3.002;[f1c8c7a]-dev : Possible FIX build for issues source-foundry#377 and source-foundry#379. Removes -R flag from ttfautohint settings to eliminate blue zone linking between bold/italic/bolditalic and regular variants. removed use of -R flag in ttfautohint in an attempt to address bug in source-foundry#377, this eliminates the regular set as the blue zone reference font modified build-ttf.sh script to replace -I flag and remove -n flag (adds ttfautohint metadata back to the name ID 5 record), another attempt to address hinting issue in source-foundry#377 converted to compilation and hinting on Linux. hinting with ttfautohint 1.7, Harfbuzz 1.5, FreeType 2.8 [ttfautohint-build.sh] revert ttfautohint build dependencies: FreeType back to v2.8 (from v2.8.1), Harfbuzz back to v1.5.0 (from 1.7.4) # Conflicts: # build/ttf/Hack-Bold.ttf # build/ttf/Hack-BoldItalic.ttf # build/ttf/Hack-Italic.ttf # build/ttf/Hack-Regular.ttf

chrissimpkins assigned texhex and chrissimpkins Jan 23, 2018

chrissimpkins added the Windows label Jan 23, 2018

chrissimpkins changed the title ~~Strange rendering after upgrading to v3.001~~ [Windows] Strange rendering after upgrading to v3.001 Jan 23, 2018

chrissimpkins added the bug label Jan 25, 2018

chrissimpkins added a commit that referenced this issue Jan 27, 2018

removed use of -R flag in ttfautohint in an attempt to address bug in #…

f1c8c7a

…377, this eliminates the regular set as the blue zone reference font

chrissimpkins added a commit that referenced this issue Jan 27, 2018

Version 3.002;[f1c8c7a]-dev : Possible FIX build for issues #377 and #…

e813aee

…379. Removes -R flag from ttfautohint settings to eliminate blue zone linking between bold/italic/bolditalic and regular variants.

This was referenced Jan 28, 2018

v3.002 #376

Merged

Extended the tail on Q [U+0051] and U+051A #374

Merged

chrissimpkins mentioned this issue Jan 29, 2018

Fix variable height web font issue on Linux / Windows #380

Closed

chrissimpkins closed this as completed Jan 29, 2018

chrissimpkins mentioned this issue Feb 25, 2018

Checksum script for SHA1 hash testing of OpenType tables #405

Merged

1 task

CodingMarkus pushed a commit to CodingMarkus/DockerHackFont that referenced this issue Oct 9, 2018

removed use of -R flag in ttfautohint in an attempt to address bug in s…

1dd74e6

…ource-foundry#377, this eliminates the regular set as the blue zone reference font

[Windows] font height inconsistency with Hack 3.001 release #377

[Windows] font height inconsistency with Hack 3.001 release #377

Comments

jlanzarotta commented Jan 23, 2018

chrissimpkins commented Jan 23, 2018

texhex commented Jan 23, 2018

jdw1996 commented Jan 24, 2018

chrissimpkins commented Jan 24, 2018

jlanzarotta commented Jan 24, 2018

chrissimpkins commented Jan 24, 2018 • edited Loading

texhex commented Jan 25, 2018

jlanzarotta commented Jan 25, 2018

chrissimpkins commented Jan 25, 2018

chrissimpkins commented Jan 25, 2018

jlanzarotta commented Jan 25, 2018

chrissimpkins commented Jan 25, 2018

chrissimpkins commented Jan 25, 2018

chrissimpkins commented Jan 25, 2018

jdw1996 commented Jan 25, 2018

chrissimpkins commented Jan 25, 2018

jdw1996 commented Jan 25, 2018

chrissimpkins commented Jan 25, 2018

texhex commented Jan 25, 2018

chrissimpkins commented Jan 25, 2018

chrissimpkins commented Jan 25, 2018

texhex commented Jan 25, 2018

chrissimpkins commented Jan 25, 2018

texhex commented Jan 25, 2018

texhex commented Jan 25, 2018

chrissimpkins commented Jan 27, 2018

texhex commented Jan 27, 2018

chrissimpkins commented Jan 27, 2018 • edited Loading

chrissimpkins commented Jan 27, 2018 • edited Loading

chrissimpkins commented Jan 27, 2018 • edited Loading

texhex commented Jan 28, 2018

chrissimpkins commented Jan 28, 2018

texhex commented Jan 28, 2018

chrissimpkins commented Jan 28, 2018 • edited Loading

chrissimpkins commented Jan 28, 2018

chrissimpkins commented Jan 28, 2018

chrissimpkins commented Jan 29, 2018

texhex commented Jan 29, 2018

chrissimpkins commented Jan 29, 2018 • edited Loading

chrissimpkins commented Jan 29, 2018

lemzwerg commented Jan 29, 2018

chrissimpkins commented Jan 29, 2018

chrissimpkins commented Feb 2, 2018

chrissimpkins commented Jan 24, 2018 •

edited

Loading

chrissimpkins commented Jan 27, 2018 •

edited

Loading

chrissimpkins commented Jan 27, 2018 •

edited

Loading

chrissimpkins commented Jan 27, 2018 •

edited

Loading

chrissimpkins commented Jan 28, 2018 •

edited

Loading

chrissimpkins commented Jan 29, 2018 •

edited

Loading