Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Solution: Making it work with the Windows console #75

Open
GeographicCone opened this issue Dec 9, 2023 · 4 comments
Open

Solution: Making it work with the Windows console #75

GeographicCone opened this issue Dec 9, 2023 · 4 comments
Labels
Issue Something to look into

Comments

@GeographicCone
Copy link

Thank you for releasing Commit Mono! I really like the focus on ergonomics without compromising consistency and the great-looking design. The website with the documentation and customization workflow is excellent and deserves a separate praise. Easily one of the top three monospace fonts available now, and the most promising by far. Keep up the good work!


I ran into an issue where the font was not being offered as a choice with the (legacy) Windows 10 console using the latest version 1.142 (downloaded December 5, 2023). Here is how I fixed it:

First, I noticed some of the metadata was missing or incorrect:

​1. The PANOSE table was filled with zeroes. In particular, within that table, the Proportion field should have been set to 9 (= PAN_PROP_MONOSPACED) to mark the font as monospace. Other PANOSE fields shouldn't be empty as well, according to the specification.

I was using the custom version but this also seems to be the case with the latest release 1.142. Using fonttools's ttx I edited these to:

<panose>
  <bFamilyType value="2"/>
  <bSerifStyle value="11"/>
  <bWeight value="4"/>
  <bProportion value="9"/>
  <bContrast value="2"/>
  <bStrokeVariation value="2"/>
  <bArmStyle value="2"/>
  <bLetterForm value="2"/>
  <bMidline value="2"/>
  <bXHeight value="4"/>
</panose>

​2. I also set <isFixedPitch value="1"/> in the CFF section since it was 0 there while at the same time 1 in the <post> section.

​3. I then noticed the <fsSelection value="..."> seemed wrong as well, so I edited that too. Bit 0 should be set for italic, bit 5 for bold and bit 6 for the regular variant. This likely resolves a a separate issue I encountered where the regular font would be obscured by the bold variant, possibly depending on which of these was installed first. Seems this was also reported previously under #59.

​4. Concurrently, since these should also be reflected in the setting for <macStyle value="..."> with bit 0 set for bold and bit 1 for italic, I edited that too.

These three latter issues are apparently limited to the customized version, the release files seem to have these set correctly already.

​5. I also changed the <namerecord [...]> entries for the base font to Regular instead of 400Regular since that's what they should be per the specification, to eliminate the possibility that this somehow confuses GDI font enumeration. For the record, I also edited other metadata while at it, such as changing 700Regular to Bold and the like, but these are purely cosmetic changes.

Finally though, the necessary step to make the font work with the Windows console was also to convert it to TrueType. As per an issue comment by a Microsoft employee in their terminal repository:

It looks like we're asking GDI for FIXED_PITCH, FF_MODERN, and TrueType fonts that match the charset associated with whatever codepage you have the console set to. See LOGFONT documentation and TranslateCharsetInfo documentation.

The above steps and converting the font to .ttf with otf2ttf.py solved the problem for me with the font not being listed for selection the Windows 10 console:

Commit Mono: Windows Console

@stlee42
Copy link

stlee42 commented Dec 11, 2023

Thanks!

I should think macStyle would have been set correctly here: https://github.com/eigilnikolajsen/commit-mono/blob/main/src/js/download_wizard.js#L314

I believe the fsSelection bits are the most important part for getting Windows to recognize the four style family set. Definitely possible to get that working with opentype.js being used here.

@eigilnikolajsen
Copy link
Owner

  1. I think there's an issue with OpenType.js here. The PANOSE is not in the file when exporting using OpenType.js and I don't know how to fix this.
  2. Same issue as 1., I set these in code but they're not in the exported .otf file.
  3. Same thing...
  4. You get the point.
  5. There are TrueType versions available in the releases, but I suppose these suffer from the issues described in 1.-4.

Thank you for this issue, I hope it helps others.
And please, tell me if you think there's something I can do about it:)

@eigilnikolajsen eigilnikolajsen added the Issue Something to look into label Dec 27, 2023
@stlee42
Copy link

stlee42 commented Dec 28, 2023

I hadn't noticed that the v1.142 on the GitHub releases page has a set of .ttf files that has the fsSelection bits correct so that it works on Windows right out of the box.

I think you should just leave a note for Windows users to use the .ttf files in the ttfautohint directory of the GitHub releases.

@GeographicCone
Copy link
Author

I've just posted the modified files in another issue (mentioned above), since they might also workaround the problem described there, so for completeness I am adding the same link here as well:

They're based on Commit Mono version 1.142 of 2023-12-09. The weights are 400 (Regular) and 700 (Bold). Hope it's OK with the author to share it like that, if not please feel free to delete. I can also post the .ttx diffs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue Something to look into
Projects
None yet
Development

No branches or pull requests

3 participants