Hack font shown as "garbage" in IntelliJ IDEA

[tasso85]

Hi,

I have just updated the font on my Windows 10 machine, and now IntelliJ Idea shows a really weird behaviour.

• Font version: 3.000
• Where you obtained the fonts (e.g. repository download, package manager, another source)
  variant(s) of the Hack fonts that are affected (Regular, Bold, Italic, BoldItalic): windows installer on the official site, the IDE uses "regular" version I think
• font size at which the problem was observed and whether it occurs at other sizes within the Core design target range (see above): any
• operating system and version: Windows 10 build 10.0.16299.125
• application where the issue was observed and version (important for us to understand the renderer involved): IntelliJ IDEA
• screenshot images that visually demonstrate the problem: screenshot

Other IDE, for example netbeans, seem to have no issue with the font.

[jorgheymans]

Can you please check, with total commander (or any other tool just NOT windows explorer), what HACK related files you have in the windows/font dir ? I had a similar issue a while ago, and it was related due to having different versions of hack in the font dir - even though windows explorer will pretend there is only one. See #345 (comment)

[chrissimpkins]

This definitely appears to be the dreaded Windows caching issue with JetBrains editors/Java renderer. Agree with @jorgheymans comments. We will need the information that he requested to troubleshoot this.

cc: @texhex

[texhex]

At least for the linegap and the the regular font with the text "Regular" (that Windows does not like), this should be fixed in the windows installer.

If there are really left overs from Hack inside C:\Windows\Fonts of @tasso85 that should be deleted, we might have an issue that Inno Setup can not delete the file (because they are in use) but doesn't generate an error.

[tasso85]

After the problem, I went back and re-installed latest version 2 of the font.

I have checked with both WLS shell and WinSCP, and it appears that in my C:/Windows/Fonts folder there is an extra Hack-Bold_0.ttf file

[texhex]

Thanks, please try the following: Use the Hack-Windows-Installer (latest), execute it, restart your computer and execute it AGAIN. After the restart, does this extra file still exist? If not, does IntelliJ now work as expected?

This dual execution is needed (as of now) to get rid of any locked font files, as the current installer can not delete locked files. If the dual execution works, it means we need to find a way to delete locked files on the first try.

[tasso85]

After performing the double installation as suggested, it didn't ask to reboot after the second one, and I checked Notepad++, NetBeans and IntelliJ IDEA, all render the font correctly.

If I may ask, couldn't the double installation just be replaced with a single one right after boot?

[texhex]

Thanks @tasso85, good to hear. This means that you have proven the assumption of @jorgheymans and we finally found the cause of the Hack glyph display issues for Java! Thanks to you both!

TL;DR: I will try to update the installer so everything can be done in one step.

For documentation, this is what I believe happens here:

• Starting point is a system that already has a working Hack font installation with all four font files (Hack Regular, Italic, Bold and Bold Italic). Inside C:\Windows\Fonts there is an extra file Hack-Bold_0.ttf which is also registered in the Registry for "Hack Bold".

• The installer is executed the first time and replace all four main Hack files. It also tries to delete Hack-Bold_0.ttf but fails to do so because the file is locked by Windows. As it isn't one of the primary files (which would be named Hack-Bold.ttf) the installer ignores the error deleting the file and moves on. It requests a restart because the primary font files have changed.

• The system is restarted and from that time on, Windows uses the correct files because the installer registered those files in the registry. However, there is still Hack-Bold_0.ttf in C:\Windows\Fonts and Java based IDEs will use this file because they not only check the registry, but also all files in \Fonts.

• This means, there are now two font files responsible for "Hack Bold" (Hack-Bold.ttf and Hack-Bold_0.ttf) and this causes the IDE to freak out. Windows based programs (Notepad++) will only check the registry and won't have this issue

• The installer is executed a second time. and because Hack-Bold_0.ttf is no longer registered, Windows does not lock the file and it can be deleted by the installer. The installer doesn't request a restart because the primary Hack files have not changed.

• Now the system is back to normal with four files in C:\Windows\Fonts that match the data in the registry so Windows and Java lived happily ever after.

And there was me, thinking that I already knew all font installations issues on Windows.

[jorgheymans]

@texhex nice summary 👍 Maybe then your installer could drop a little thingy "somewhere" that is "somehow" executed automatically after the restart, deleting the extra font files ?

[texhex]

@jorgheymans That somewhere and somehow would be MoveFileEx with the parameter MOVEFILE_DELAY_UNTIL_REBOOT ; ).

[chrissimpkins]

so Windows and Java lived happily ever after.

❤️

Hack-Bold_0.ttf

Any idea how that file is getting there? Why is Win creating a new font path at some stage during installs/reinstalls? Something that needs to be reported to Microsoft? This seems like unexpected incorrect OS behavior, no?

[texhex]

Just to have all information in one place:

• This issue is also tracked as issue 16 in Hack-Windows-Installer
• The code to delete files is completely redesigned, we do no longer use the [InstallDelete] section but our own Pascal Scripting section (Commit
• The installer does now first try to delete the file "normally" and if this doesn't work, use MoveFileEx which will set PendingFileOperations so the file is deleted upon next restart
• The Log-FontData.txt and the normal setup log file contain exact data which files should be deleted and which method was used.
• Setup will now also stop/start the Font services in cases only a delete operation is executed

The new installer is available from Releases.

[texhex]

Any idea how that file is getting there? Why is Win creating a new font path at some stage during installs/reinstalls? Something that needs to be reported to Microsoft? This seems like unexpected incorrect OS behavior, no?

Well, this file is clearly created by the FONTS applet again because the original Hack-Bold.ttf was locked.

The question here is: Is it a bug? Given that Windows updated the registry to reflect that "Hack Bold" is now found inside the file Hack-Bold_0.ttf and all Windows programs should query the registry for font data, this makes the original Hack-Bold.ttf "just" a small Zombie file without purpose.

The problem begins the moment as Java queries the \Fonts folder, bypassing the registry and ending up with two files for the same variant which in turn causes the display problems. I doubt Microsoft will acknowledge this is as a bug, because from their perspective Java is not doing it the way it should work.

I'm fully with you that Microsoft should rewrite the entire Font handling from scratch, but given how many broken components they have in Windows 10 (starting from the "Start Menu" which is nearly FUBAR), I doubt they will do anything about this.

[chrissimpkins]

Thanks @texhex and @jorgheymans. Any suggestions for documentation changes here for future users who see this problem? Are we properly linked to the docs on the Win installer side so that this is evident and there is a simple path to the information that you provide @texhex?

[jorgheymans]

@chrissimpkins it's an exceptional case, not sure if you need to link it in the documentation more prominently.

[chrissimpkins]

@jorgheymans OK thanks. We good to close this now?

[texhex]

@chrissimpkins It's documented in https://github.com/source-foundry/Hack-windows-installer/blob/master/FontInstallationIssues.md and as this is an edge case as @jorgheymans said, I think that's enough documentation for now.

I'm fine with closing this issue.

[chrissimpkins]

thanks @texhex!

fantastic work on this. it's great to have your expertise here!