-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
font-patcher: Improve 'Mono' compatibility with Windows #695
Conversation
Here is a list of what some of the Mono patched fonts have in their Panose-Propotion: A value of '9' (= Monospaced) helps Windows to detect monospaced fonts. Some fonts like Noto set other Propotions there (like 'Condensed'), which are technically correct but do not help terminal users. So we overwrite them. Not all of these fonts might have a problem to be detected as monospaced by the Windows CMD font chooser, but at least some are affected. I guess fixing this globally is the easiest solution. The panose propotion field is unfortunately not bits or so, the font designer needs to select ONE of 'modern' 'condensed' 'monospaced' ... :-(
|
[why] Some of the patched Mono fonts do not turn up in the font chooser of Windows CMD and PowerShell (and probably more). [how] For some reasons Windows does not identify the fonts as being strictly monospaced, so they are hidden in that font choosers. For the monospaced fonts we set now the Panose proportion 'monospaced'. Windows seems to honor the Panose properties. It is not clear why we need to set the old Panose props, especially as Cascadia Code does not (!) set them and is still detected as monospaced. Anyhow, the way Windows detects if a font is monospaced is a mystery (at least for me), and this works, so ;-) Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
8da5a32
to
5170911
Compare
Hey other than the small syntax/typo this does seem to do the correct thing however it still isn't showing up for me when I tested in Windows 10 BUT I was able to get it to show after trial and error of several things that did not work: shortening the family name, changing the IBM family, embedding bitmap fonts in the TTF. What did finally work was adding to the charsets (I'm thinking the missing languages?)
|
Just a hint for PowerShell, when you enter something, extended chars are always replaced by question marks, I believe to help preventing you entering something that looks like A but is B. Once it outputs it, it is ok, like here (I just stuff the chars in the prompt): For the Panose fix ... I tried (alas) Cascadia, and there it seemed to be enough. Fini |
A hunch of mine is that
|
Checked on my Windows box (Windows 10 Enterprise 20H2). Open in Is visible in PowerShell. (Of course before installation all PowerShell Windows must be closed) |
It is always good to write stuff down here, as ... one works more concieously on it then, at least me.
|
I guess
Just examining Cascadia 2111.01 release and freshly patched from that:
I would also conclude ... not monospaced (anymore). And it is not the powerline things:
Obviously our mono scaling has a flaw? |
I believe there is a misunderstanding what the What it doesThere is on 'master glyph' and then a list of glyphs that are scaled with the same factor as the master glyph (keeping the relative sizes of all (master and other) glyphs the same) while only the master glyph is scaled to fit out destination font. What would make senseThere is no master glyph. There is a list of group lists. All glyphs within one of the group lists are scaled to the same factor, keeping their relative size the same. The factor is taken from the biggest glyph in that group. All individual group lists are scaled independently. Take these original glyphs from FontA: The selected glyphs (volume off, middle, high) should be scaled together. They would form a group list. But they have nothing to do with these glyphs, that would form other/independent group lists: I guess when the list has been created the windows glyph, that is used as master glyph for FontA, was the biggest of all, and thus there is just one list and someone manually selected the biggest char. But that will fail of course when the upstream symbols are renovated, i.e. changed in dimensions relative to each other. |
If FontA would be fixed there are still issues:
The Powerline (Extra) Symbols are scaled to 101% or 102% on purpose to avoid ugly gaps ( |
This works which is strange because if I take the unpatched font from the repo and run it through the font patcher on this branch it sets the same Panose proportion but it doesn't show up 😮 |
Hmm, the patched fonts are different??! The fresh patched font does not show up on my machine also. Will have a look later today. I also prepared (yesterday) a new way to handle the |
Thank you!
Nope! I am not, have at it. I'm working on other things 😅 Also, I may be inclined to merge this anyway since this changes does seem like the right thing to do regardless if it specifically fixes the windows monospace fonts not showing in |
In a case of perfect being the enemy of good I am satisfied with this change even if it doesn't solve completely the issues with mono fonts in windows. |
I guess I would hold this back, check if #732 works instead on the typical candidates. Darkly I remember that I checked a font patched with just If i remember correctly, then this PR should be pulled. If it works without I would close it. Interestingly for Cascadia has no Panose at all, and it works in CMD. Maybe it is our |
😆 yeah, i did see your other PRs though. I guess we can always revert the changes in the PR too. I will see if I can get some time to try out #732 changes and see if the panose makes any difference. But from various sources I did see setting panose proportion to be a recommended solution |
…aced font-patcher: Improve 'Mono' compatibility with Windows
Description
[why]
Some of the patched Mono fonts do not turn up in the font chooser
of Windows
CMD
andPowerShell
(and probably more).[how]
For some reasons Windows does not identify the fonts as being strictly
monospaced, so they are hidden in that font choosers.
For the monospaced fonts we set now the Panose proportion 'monospaced'.
Windows seems to honor the Panose properties.
It is not clear why we need to set the old Panose props, especially as
Cascadia Code does not (!) set them and is still detected as monospaced.
Anyhow, the way Windows detects if a font is monospaced is a mystery (at
least for me), and this works, so ;-)
Requirements / Checklist
./font-patcher Inconsolata.otf --fontawesome --octicons --pomicons
./gotta-patch-em-all-font-patcher\!.sh Hermit
What does this Pull Request (PR) do?
Only for
font-patcher --mono
:Set/overwrite
OS/2
-Panose
-Propotion
toMonospaced
WHEN
OS/2
-Panose
-Family Kind
isAny
orLatin-Text
Set
OS/2
-Panose
-Family Kind
toLatin-Text
WHEN it was
Any
beforeHow should this be manually tested?
Try to select font in MS-Windows
cmd
application font chooser.Any background context you can provide?
Cheat sheet for Panose: https://forum.high-logic.com/postedfiles/Panose.pdf
What are the relevant tickets (if any)?
For example #586
Screenshots (if appropriate or helpful)