Font Forum

Short version: A font that works in cmd.exe and powershell (Consolas), and is then loaded and then saved in FontCreator, is changed in some way that prevents it from working in cmd/powershell.

I'm trying to figure out how to make a modified Consolas font which will be accepted by Windows console cmd.exe and powershell. Only fonts meeting certain requirements will load into that software. Details:
http://support.microsoft.com/default.as ... US;Q247815

Because I was having difficulty getting this to work at all, I tried a test case where I simply load consola.ttf into FontCreator, make NO edits, then export it to the same-name file (different directory), using settings Open Type Features: No; Kerning: No; Hinting: Keep original.

I then uninstall the original Consolas font from Windows, and install this newly saved one. This is not accepted by cmd.exe nor powershell (does not appear in their font lists). It does work fine in Notepad or Word.

One suspicious oddity is that this saved consola.ttf appears in Explorer (and the Font control panel) with an icon that displays three asian characters, as do other fonts that really are asian fonts, as though Windows now thinks consolas contains asian characters or should be treated as such. Oddly, consolas's icon shows these three characters despite not containing the glyphs for them.

This is especially germane because the rules noted above are special for Asian fonts... so I don't want this detected as an Asian font!

Bottom line: When FontCreator saves the unmodified-by-me consola.ttf, it's doing something that violates the requirements shown at the link above... and I'd like to know what and how to fix it!

I'm using paid Font Creator 7 Home, downloaded today.

Thanks!

-- Graham

[Edited for clearer title and add version info]

As a further data point, if I load original Consola.ttf into FontForge, save it ("generate fonts"), and then install that in place of the original Consolas, this does two things right:

1. It appears as a choice in cmd.exe and powershell

2. The icon shown for consola.ttf in Windows Explorer and Fonts control panel is Abg, not the three asian characters.

So... by contrast Font Creator is doing something different from this that's not working properly.

-- Graham

So the thing that FontCreator was doing that messes things up is to "Automatically update (Code Page) character ranges".
These are settings on the Font > Properties dialog > Ranges tab. There is a Code Page Character Ranges section, and a checkbox to disable auto updating.

For Consolas, FontCreator auto adds ranges:

• Arabic (864)
• Hebrew (862)
• Arabic; ASMO 708

In short, this completely fills in the bottom right 16-bit pattern.

This can be easily tested by dropping consola.ttf into FontCreator, opening the Font Properties > Ranges tab, and hitting the "Calculate" button for Code Page Character Ranges. (Obviously don't export the font after doing this test!).

There is some chance that the calculation that FontCreator is doing is erroneous. For example, I saw no Hebrew characters in Consolas. Or perhaps these additional "code ranges" are being triggered by one or two characters that happen to be part of the full code range.

Anyhow, when this auto behavior is disabled, the font exported from FontCreator:

• does NOT show an icon in Explorer/Fonts with asian characters
• DOES appear as an option in cmd.exe and powershell.

Yay!

You solved it before I could even provide support, but I'm glad you've found your way into FontCreator!

The reason why FontCreator detects the font contains characters from Windows Codepage: 932 (Japanese Shift-JIS) is because numerous Greek and Cyrillic characters are part of that codepage. Actually the font contains 126 characters as defined in CP932:
http://www.unicode.org/Public/MAPPINGS/ ... /CP932.TXT

We might need to rethink the way we decide whether a code page is functional.

We will most likely release another maintenance release later this week, which will be more strict, to ensure code pages are only considered functional when most of the relevant characters are actually located in the font.

Erwin:

What would be especially helpful is a way for users to see, and to control, the degree to which Font Creator is going to change data of a font.

I will write this up as a "feature request".

-- Graham

We've finally released a new maintenance release which solves the issue. In FontCreator do update through the Check for Updates feature within the Help menu.

Erwin Denissen wrote:We've finally released a new maintenance release which solves the issue. In FontCreator do update through the Check for Updates feature within the Help menu.

Thanks! I'll try it soon.